Nghiên ứu kỹ thuật xây dựng phần mềm chịu lỗi áp dụng cho hệ thống nhúng

Một trong số các khó khăn khi thực hiện các kỹ thuật chịu lỗi là sự thiếu hụt h cỗ trợ ủa hệ điều hành.. Mục đích nghiên cứu Mục đích ủa luậ c n văn là nghiên cứu tìm hiểu các phương phá

TRƯỜ NG Đ Ạ I H C BÁCH KHOA HÀ N I Ọ Ộ

-LUẬ N VĂN TH Ạ C SỸ KHOA H C Ọ

L ỜI CAM ĐOAN

Tôi – Đào Ngọc Kiên, học viên lớp Cao học CNTT 2006 2008 Trườ- ng Đại

học Bách Khoa Hà Nội cam kết Luậ– n văn tốt nghiệp là công trình nghiên c u cứ ủa

bản thân tôi dưới sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng, Viện CNTT TT, Trường Đạ ọi h c Bách Khoa Hà N i ộ

-Các kết quả nêu trong Lu n văn tốt nghiệp là trung thực, không sao chép ậtoàn văn của b t k công trình nào khác ấ ỳ

Hà Nội, ng y 30, th ng 10, năm 2009à á

Học vi n: Đào Ngọc Kiênê

ớp : Cao Học CNTT 06 08L -

L Ờ I CẢM ƠN

Tôi xin bày tỏ lòng bi t ơn sâu sắ ớế c t i th y giáo, PGS.TS Huỳnh Quyết ầThắng, Việ Công Nghệ Thông Tin và Truyền Thông, trường Đại h c Bách Khoa n ọ

Hà Nội, đã khuyến khích và rấ ật t n tình hư ng dớ ẫn tôi trong suốt quá trình thực hiện

luận văn Nhờ ự s quan tâm chỉ ả b o và nh ng ý kiữ ến đóng góp quý báu của thầy, tôi

mới có thể hoàn thành luận văn này

Tôi xin chân thành cảm ơn t p th ậ ểcác t y, cô giáo trư ng Đ i h c Bách Khoa hầ ờ ạ ọ

Hà Nội nói chung và Viện Công Nghệ Thông Tin và Truyền Thông nói riêng đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghi m quý báu trongệ suốt những năm họ ừc v a qua

Tôi cũng xin cảm ơn các đồng nghiệp ở công ty đã t o điạ ều kiệ ề ờn v th i gian

để tôi có th h c t p và hoàn thành luận văn ể ọ ậ

Cuối cùng, tôi xin chân thành cảm ơn gia đình, người thân đã hết lòng giúp đỡ

h v vỗ trợ ề ật chất lẫn tinh thần giúp tôi yên tâm học tập và nghiên cứu trong suốt quá trình c thọ ập và thực hiện luận văn

M Ụ C LỤ C

L ỜI CAM ĐOAN 2

L Ờ I CẢM ƠN 3

M Ụ C LỤ C 4

DANH M C CÁC HÌNH V Ụ Ẽ 6

DANH M C CÁC B NG Ụ Ả 8

DANH M C CÁC T VI Ụ Ừ ẾT TẮT 9

M Ở ĐẦ U 10

1 Tính c p thi ấ ế t của đề tài 10

2 M ục đích nghiên cứ u 11

3 Nhi ệ m vụ nghiên c u 12 ứ 4 Ph m vi nghiên c u 12 ạ ứ 5 C u trúc lu ấ ận văn 12

6 Phương pháp nghiên cứ u 13

CH ƯƠNG 1 - TỔ NG QUAN V XÂY D Ề Ự NG PHẦ N M M CH U L Ề Ị Ỗ I 14

1.1 Độ tin c y ph n m m 14 ậ ầ ề 1.2 Tư tưở ng “D phòng” trong xây d ng ph n m m ch u l i 19 ự ự ầ ề ị ỗ 1.2.1 D phòng ph n m m 19 ự ầ ề 1.2.2 D phòng d u 19 ự ữ liệ 1.3 Bi n pháp ph ệ ụ c hồi phầ n m ề m khi lỗ i 20

1.3.1 Ph ụ c hồ i quay lui 20

1.3.2 Ph ụ c hồi tiế n 21

1.4 Các hướ ng ti p c n trong k thu t xây d ng ph n m m ch u l i 21 ế ậ ỹ ậ ự ầ ề ị ỗ 1.4.1 K thu ỹ ật đa thiế t kế 22

1.4.1.1 K thu ỹ ậ t lậ p trình N phiên b ả n NVP (N -version programming) 23

1.4.1.2 K thu t kh i ph ỹ ậ ố ụ c hồ i RcB (Recovery Block) 24

1.4.2 K thu ỹ ật đa dữ u 26 liệ T Ổ NG KẾT CHƯƠNG 29

CHƯƠNG 2 – T Ổ NG QUAN VỀ Ệ THỐNG NHÚNG THỜI GIAN THỰC 30 H 2.1 Khái ni ệ m thời gian thự c 31

2.2 Cơ chế ng t 32 ắ 2.3 Các tác v task ụ 33

2.4 Cơ chế ậ ị l p l ch 36

2.4.1 L p l ch có chu k 37 ậ ị ỳ 2.4.2 L p l ch không theo chu k 37 ậ ị ỳ 2.4.3 L p l ch theo ki ậ ị ể u chiế m quy n th c thi và không chi m quy n th c thi 37 ề ự ế ề ự 2.4.4 Phương thứ c x lý các task có cùng m ử ức ưu tiên 39

2.4.5 L p l ậ ịch ưu tiên deadline sớ m nhấ t 39

2.5 Cơ chế truy n thông 40 ề 2.5.1 Semaphore 40

2.5.2 H ộp thư mailbox 41

2.5.3 Hàng đợi và đườ ng ng (Queues và Pipe) 42 ố 2.6 Khác bi t gi ệ ữ a hệ thố ng nhúng th ờ i gian thực so với hệ thố ng nói chung 42

2.7 Các l ỗ i thư ờ ng g p trong h ng nhúng 43 ặ ệ thố T Ổ NG KẾT CHƯƠNG 45

CHƯƠNG 3 – K Ỹ THUẬT XÂY DỰNG PHẦN MỀM CHỊU LỖI ÁP DỤ NG CHO H Ệ THỐNG NHÚNG 47

3.2 L ỗ i trong hệ thống nhúng và cơ chế ử x 49 lý

3.2.1 X lý l ử ỗ i thời gian (Deadline error) 49

3.2.2 X lý l ử ỗ i lậ p trình (Programming error) 50

3.2.3 X lý l i ph n c ử ỗ ầ ứ ng (Hardware error) 51

3.3 Mô hình ch u l ị ỗ i cho hệ thống nhúng đơn nút 51

3.3.1 Mô hình h ệ thống chị ỗi ở ức task u l m 52

3.3.2 Mô hình h ệ thống chị ỗi ở ức ứ u l m ng d ng 53 ụ 3.3.3 Chuy ển đổ i chế độ ứ ng d ng 54 ụ 3.4 Ki ế n trúc chị ỗi cho hệ thống nhúng đơn nút u l 55

3.4.1 B u khi ộ điề ể n ftcontroller 57

3.4.2 B ộ giám sát ứ ng d ng ftappmon 58 ụ 3.4.3 Tương tác cơ bả n gi a các thành ph n 59 ữ ầ 3.4.4 Lu ng x lý c a các thành ph ồ ử ủ ầ n chị ỗ u l i 61

3 4.5 Tương tác dướ i góc nhìn thread 62

3.5 Mô hình ch u l ị ỗ i dự phòng cho h ệ thống nhúng đa nút 63

3.5.1 Mô hình ch u l ị ỗ i dự phòng 63

3.5.2 Các lo i hình d phòng 64 ạ ự 3.5.3 L ự a chọ n lo ạ i hình dự phòng áp d ng cho h ng nhúng 65 ụ ệ thố 3.6 Ki ế n trúc chị ỗi dự u l phòng cho h ệ thống nhúng đa nút 66

3.6.1 Ki n trúc ph n m ế ầ ề m chị ỗi trên mộ u l t nút 67

3.6.2 Ki n trúc ph n m ế ầ ề m chị ỗ u l i trên nhi u nút 67 ề 3.6.3 B qu n lý d phòng FTRedundancy 69 ộ ả ự 3.6.4 B qu n lý b ộ ả ả n sao FTreplicamngr 69

3.6.5 Tương tác cơ bả n gi a các thành ph n ch u l i 70 ữ ầ ị ỗ 3.6.6 Cơ chế đả m b o tính nh t quán v ng c nh c a task 72 ả ấ ề ữ ả ủ T Ổ NG KẾT CHƯƠNG 75

CHƯƠNG 4 – THỬ NGHIỆ M VÀ ĐÁNH GIÁ 77

4.1 Th nghi ử ệ m ứ ng d ng áp d ng mô hình ch ụ ụ ị u lỗ i 77

4.1.1 Gi ớ i thiệu bài toán vệ tinh do thám không gian 77

4.1.2 Th nghi ử ệm và đánh giá kế t quả 78

4.2 Th nghi ử ệ m đ ộ tin cậ ủa hệ thố y c ng 86

4.2.1 Mô t ả chương trình 86

4.2.2 Th nghi m và nh n xét k ử ệ ậ ế t quả 88

T Ổ NG KẾT CHƯƠNG 90

K Ế T LUẬ N 91

1 Các n ội dung đã hoàn thành trong luận văn 91

2 Các đóng góp khoa họ c 92

3 Hướ ng phát tri n lu ể ận văn 93

TÀI LIỆU THAM KHẢO 95

TÓM TẮT LUẬN VĂN 96

THESIS SUMARY 97

DANH MỤC CÁC HÌNH VẼ

Hình 1.1 K thu ỹ ật nâng cao độ tin cậ y ph n m m trong các pha phát tri n 16 ầ ề ể

Hình 1.2 M i quan h ố ệ giữa fault, error và failure 17

Hình 1.3 M i quan h ố ệ giữa fault, error và failure 18

Hình 1.4 C u trúc và ho ấ ạt độ ng c ủ a kỹ thu t N phiên b n l ậ ả ậ p trình (NVP) 24

Hình 1.5 C u trúc và ho ấ ạt độ ng c ủ a kỹ thu t kh i ph ậ ố ụ c hồi (RcB) 26

Hình 1.6 Mô hình k ỹ thuật đa dữ liệ u 27

Hình 1.7 Mô hình k ỹ thuật đa dữ liệ u 27

Hình 1.8 Mô hình k ỹ thuật đa dữ liệ u 28

Hình 2.1 Vòng l p pooling 32 ặ Hình 2.2 C ng t 33 ơ chế ắ Hình 2.3 C u trúc m ấ ộ t task 34

Hình 2.4 C u trúc mã l nh c ấ ệ ủ a một task 35

Hình 2.5 Mô hình tr ạ ng thái của task 37

Hình 2.6 L p l ch có và không có chi m quy n th c thi 38 ậ ị ế ề ự Hình 2.7 C ơ chế truyề n thông qua semafore 41

Hình 3.1 Gi ản đồ trạng thái của task chị ỗ u l i 52

Hình 3.2 Mô hình task ch u l i 53 ị ỗ Hình 3.3 Chuy ển đổ ng d ng khi có l i 54 chế độ ứ ụ ỗ Hình 3.4 Ki ế n trúc chịu lỗ i cho h ệ thống nhúng đơ n nút 56

Hình 3.5 B u khi n ftcontroller 57 ộ điề ể Hình 3.6 B ộ giám sát ứ ng d ng ftappmon 58 ụ Hình 3.7 T ng tác c b n gi ươ ơ ả ữ a các thành phần chị ỗ u l i 59

Hình 3.8 T ng tác c b n gi ươ ơ ả ữ a các thành phần chị ỗ u l i 60

Hình 3.9 Lu ng x lý c ồ ử ủ a các thành phầ n ch u l i 61 ị ỗ Hình 3.10 T ng tác c ươ ủ a các thành phầ n ch u l ị ỗ i dướ i góc nhìn thread 62

Hình 3.11 Đặ ả c t tri n khai ng d ng trong mô hình d phòng 64 ể ứ ụ ự Hình 3.12 Ki n trúc ph ế ầ n mềm chị ỗi trên mộ u l t nút 67 Hình 3.13 Ki n trúc ph ế ầ n mềm chị ỗ u l i trên nhi u nút 68 ề

Hình 3.14 B qu n lý d phòng FTRedundancy 69 ộ ả ự Hình 3.15 B qu n lý b n sao FTreplicamngr 70 ộ ả ả

Hình 3.16 T ng tác c b n gi a các thành ph ươ ơ ả ữ ầ n chị ỗ u l i 71

Hình 3.17 X lý thay th b n sao d phòng khi có l i nút 72 ử ế ả ự ỗ Hình 3.18 C ho ơ chế ạt độ ng trong ki ế n trúc chịu lỗi dự phòng 73

Hình 4.1 Các thành ph n trong ng d ng ch u l ầ ứ ụ ị ỗ i mô phỏ ng 79

Hình 4.2 C ác task trong ứ ng d ng ch u l i mô ph ng 80 ụ ị ỗ ỏ Hình 4.3 Mô hình ng d ng ch u l ứ ụ ị ỗ i với hai chế độ 81

Hình 4.4 Quá trình chuy ển đổ i c ế độ chị ỗ h u l i khi có l i 82 ỗ Hình 4.5 Giao di n c ệ ấ u hình hệ thống 83

Hình 4.6 K t qu ế ả chương trình chạy (1) 84

Hình 4.7 K t qu ế ả chương trình chạy (2) 85

Hình 4.8 C u trúc và ho ấ ạt độ ng ch ng trình mô ph ng k thu ươ ỏ ỹ ậ t RcB 87

Hình 4.9 Giao di n ch ng trình mô ph ng k thu ệ ươ ỏ ỹ ậ t RcB 88

Hình 4.10 S l i không phát hi ố ỗ ện đượ c trong chươ ng trình mô ph ng k thu ỏ ỹ ậ t RcB 89

DANH MỤC CÁC BẢNG

B ng 1.1 Các khái ni ả ệm liên quan đến độ tin cậy phầ n m m 17 ề

B ng 3.1 B ng chuy ả ả ển đổ i chế độ ứng dụ ng khi l i 54 ỗ

9 RTOS Real-time operating system

10 EDF Earlest deadline first

11 ft_task Fault tolerant task

12 ftcontroller Fault tolerant task controler

13 ftappmon Fault tolerant application monitor

14 ftredundancymgr Fault tolerant redundancy manager

15 ftreplicamngr Fault tolerant replica manager

16 FTAppli Fault tolerant application

M U Ở ĐẦ

1 Tính c p thi ấ ế t của đề tài

H ệthống nhúng được sử ụng rộng rãi trong nhiề d u lĩnh vực, chẳng hạn như

điều khiển ện tử ự độđi , t ng hóa nhà, văn phòng, và công nghiệp ô tô Mặc dù không tồn tại mộ ịt đ nh nghĩa chính xác v thuật ngữề nhưng nói chung h th ng ệ ốnhúng được xem mlà t h th ng ph n cứng, phần mềộ ệ ố ầ m th c hi n m t ch c năng c ự ệ ộ ứ ụ

thể, thường là một phần của m t hộ ệ ống lớth n hơn i u này ngụĐ ề ý gi i thích cho ảchữ "nhúng" trong thuật ngữ này (là một phần được nhúng vào hệ ố th ng lớn hơn) Ngoài ra h thệ ống nhúng đượ thiết kc ế để ự th c hiện một chức năng c ể ợụth đư c xác

định trước, trái v i m c đích chung ớ ụ chung a h th ng máy tính bình thường củ ệ ố(mainframe, máy tính đểbàn, máy tính xách tay, vv…)

Hầu hết các hệ thống nhúng thời gian thực phải thỏa mãn các ràng buộc thời gian M t sộ ố ệ ố h th ng nhúng có yêu cầu v ề độ tin cậy, tính s n sàng và sẵ ự an toàn cao bởi m t hộ ỏng hóc củ ệ ống có thể ẽa h th s gây nguy hi m cho tính m ng con ể ạngười hoặc làm t n h i đ n hoạ ộổ ạ ế t đ ng chung của toàn h th ng Những hệ ốệ ố th ng này được phân lo i thành h th ng an toàn cao (safety-critical) ho c h th ng quan ạ ệ ố ặ ệ ố

trọng (mission critical) Ví d- ụ ề v nh ng hệ ống critical system các hữ th là ệ ống thtrong công nghiệp ô tô, điện tử hàng không, điều khi n quân sể ự hay không gian vũ trụ

Các hệ thống critical có độtin cậy cao hơn nhiều so với các hệ thống thương

m i ạ thông thường Ví dụ các thiết bị ận chuyể v n hành khách hàng không được thiết

k vế ới ít hơn 10-9 lỗi trên 1 giờ hoạ ột đ ng (tương đương với 1 lỗi sau 114.000 năm) Yêu cầu tương tự như v y cũng đượậ c áp dụng trong hệ thống điều khiển đường sắt Ngoài ra h ệthống điều khi n v tinh không gian ể ệ lại càng yêu cầ ộu đ tin cậy cao hơn

n bữa ởi hầu hết các hệ thống này phải hoạ ột đ ng trong điều kiện không có quá trình

bảo dưỡng nào cả

Vì hệ thống nhúng critical được kế ợp bởt h i phần cứng và phần mềm nên một nhu cầu rất cấp thiế giảm thiểu hỏng hóc liên quan đến cả hai lĩnh vực đó t làMặc dù độ tin c y c a ph n c ng đang ngày càng phát tri n tuy nhiên các l i nh t ậ ủ ầ ứ ể ỗ ấthời v n có thẫ ể ả x y ra, đặc bi t trệ ong các môi trường năng lượng cao hay có bức xạ lớn chẳng hạn như các hệ ố th ng không gian V l i ph n mềề ỗ ầ m, s gia tăng không ựngừng các chức năng của hệ thống đang làm tăng lên độ ứ ph c tạp của phần mềm và

đây thường là nguyên nhân chính gây ra lỗi trong ph n m m B t ch p nhi u n l c ầ ề ấ ấ ề ỗ ự

tồn tại không đoán trư c đư c và không tìm ra đướ ợ ợc Do vậy kỹ thuật chịu lỗi được đưa ra áp dụ đểng có th duy trì hoể ạt động h thốệ ng cho dù có l i xảy ra ỗ ở phần

cứng hay phần mềm

Một trong số các khó khăn khi thực hiện các kỹ thuật chịu lỗi là sự thiếu hụt

h cỗ trợ ủa hệ điều hành Hệ điều hành thư ng không đườ ợc thiết kế ớ v i tư duy chịu

lỗi từ trước Ngay cả ới một số ệ điề v h u hành được mở ộ r ng để b ổ sung thêm cơ chếchịu lỗi thì cơ chế đó cũng không hỗ ợ ị tr ch u lỗ ội m t cách đ y đ ầ ủ

Trong nhiều h ệthố chịu lỗng i người phát triển phải giải quyết c các vả ấn đềlogic của ứng d ng và vụ ấn đề ch u lỗi Điều này khiến h ệ ống chịu lỗ ốn nhiều ị th i tchi phí và gặp nhiều khó khăn trong phát triển và b o trì Do vả ậy m t nhu cộ ầu sinh

ra là cần cung cấp một cơ chế ỗ ợ h tr ch u lỗi có tính trong suốt vớị i người dùng ở

một mứ ộc đ nào đấy và có thể áp dụng với nhiều dạng ứng dụng khác nhau mà không phải ch nh s a nhiỉ ử ều

Một vấ ền đ khác là việc áp dụng chịu lỗi ảnh hưởng khá lớ ến đ n ứng xử thời gian th c (ự real-time ủ ứng dụng Một cơ chế ịu lỗi thường bao gồ) c a ch m các hoạt

động dò tìm l i, thay th phương án x lý khi có l i, h p tác gi a các b n sao ỗ ế ử ỗ ợ ữ ảNhững hoạ ột đ ng này thay đổi th i gian ờ ứng xử ủ c a ứng dụng và có thể vi phạm các ràng bu c ch t chộ ặ ẽ ề v thời gian th c ự củ ệ thống a h Ngoài ra c áp d ng các kviệ ụ ỹthuật chịu lỗ có thểi gây nh hư ng đ n tài nguyên của hệ thống ch ng hả ở ế ẳ ạn như năng lượng điện tiêu thụ, kích thước b nhộ ớ, kích thước v t lý ậ

2 Mục đích nghiên cứu

Mục đích ủa luậ c n văn là nghiên cứu tìm hiểu các phương pháp kỹ thuật nhằm cung cấp khả năng chịu lỗi cho hệ thống nhúng thời gian thực Trư c tiên tư ớtưởng và các k thu t ch u l i nói chung s đư c đào ỹ ậ ị ỗ ẽ ợ sâu nghiên cứ tìm hiểu.u

Tiếp theo, vì mục tiêu là áp dụng cho hệ ố th ng nhúng nên luận văn cũng tìm

hiểu v các cơ ch ạ ộề ế ho t đ ng trong hệ điều hành nhúng thời gian Luận văn cũng đưa ra các điểm khác bi t so với hệ ềệ đi u hành thông thường

Luận văn sẽphân tích và đưa ra một mô hình ph n mầ ềm ch u l i áp d ng cho ị ỗ ụ

h ệthống nhúng ựa trên kỹ thuật chịu lỗi nghiên cứu Mô hình này cần được thiết d

k ếchịu lỗi ớv i lưu ý vềràng buộc thời gian và tài nguyên của hệ thống nhúng thời gian thực Mặt khác cần thiết k ếmô hình sao cho việc ch ỗi phải trong su t vịu l ố ới người dùng đểquá trình phát tri n và b o trì h th ng không quá khó khăn ể ả ệ ố

Một ứng dụng mô phỏng trên hệ điều hành thời gian thực RTLinux ẽ được s xây dựng để th nghiệử m tính khả thi c a ủ mô hình Ngoài ra cũng cần thử nghiệm

đánh giá độ tin c y c a h thống khi áp dụậ ủ ệ ng các k thu t ch u l i ỹ ậ ị ỗ

3 Nhi ệ m vụ nghiên c ứ u

• Nghiên cứu các tư tư ng và các k thu t ch u l i nói chung chẳng hạn như tư ở ỹ ậ ị ỗ

tưởng d phòng, bi n pháp ph c hồi khi lỗi, kỹự ệ ụ thuật đa thiết kế, kỹ thuật đa

d ữliệu

• Tìm hiểu cơ chế ho t đ ng c a h đi u hành th i gian th c ch ng h n như cơ ạ ộ ủ ệ ề ờ ự ẳ ạ

chế ng t, mô hình hoạt động dựa trên task, cơ chế ậắ l p lịch, cơ chế truyền thông Đưa ra các điểm khác bi t giữa hệ ềệ đi u hành thời gian th c và h đi u ự ệ ềhành thông thường

• Đề xu t và áp d ng k thu t ch u l i vào xây d ng m t mô hình ch u l i áp ấ ụ ỹ ậ ị ỗ ự ộ ị ỗ

dụng cho hệ thống nhúng thời gian thực

• Thử nghi m đánh giá các k thu t ệ ỹ ậ và mô hình đó trong môi trư ng nhúng ờ

thời gian thự c

4 Ph m vi nghiên c ạ ứ u

Phạm vi nghiên cứu nằm trong vấn đề nâng cao đ tin c y của hệ ốộ ậ th ng phần

mềm, cụ thể là kỹ thuật chịu lỗi cho hệ thống nhúng thời gian thự c Đây là một vấn

đề ộ r ng l n b i b n thân h th ng nhúng th i gian th c là lĩnh v c khá ph c t p đòi ớ ở ả ệ ố ờ ự ự ứ ạ

hỏi nhiều kiến thức sâu rộng Ngoài ra các ỹ thuật chịu lỗi cho phần mềm còn là k lĩnh vực khá m i mẻ ở ệớ Vi t Nam Chính vì vậy m c tiêu củụ a luận văn là đặt phạm

vi nghiên cứ ở ứu m c tìm hi u và đưa ra nh ng ki n th c n n t ng cho vi c áp d ng ể ữ ế ứ ề ả ệ ụ

k ỹ thuật chịu lỗi vào hệ thống nhúng thời gian thực chứ chưa đưa ra đượ ầ ủc đ y đtoàn diện đượ ấ ảc t t c các v n đ , giải pháp liên quan ấ ề

5 Cấu trúc luận văn

Với mục tiêu như trên lu n văn s đượậ ẽ c trình bày theo bố ục như sau: c

• Chương 1: Tổng quan về xây dựng phần mềm chịu lỗi Chương này đặt vấn

đề và trình bày một số khái niệm và các phương pháp, kỹ thuật chung trong xây dựng phần mềm chịu lỗi chẳng hạn như tư tưởng dự phòng, kỹ thuật NVP, RcB…

• Chương 2: Tổng quan về hệ thống nhúng thời gian thực Chương này trình bày về các cơ chế hoạt động trong hệ thống nhúng thời gian thực, cụ thể là

hệ điều hành thời gian thực RTOS Chẳng hạn như về mô hình các task, cơ chế ngắt, cơ chế lập lịch và truyền thông giữa các task…

• Chương 3: Kỹ thuật và mô hình phần mềm chịu lỗi áp dụng cho hệ thống nhúng Chương này nghiên cứu, phân tích và đề xuất một mô hình kiến trúc phần mềm chịu lỗi, mô tả các thành phần và cơ chế hoạt động Chẳng hạn như bộ điều khiển task, bộ giám sát ứng dụng, bộ quản lý dự phòng, bộ quản

lý bản sao …

• Chương 4: Thử nghiệm và đánh giá Chương này sẽ xây dựng một ứng dụng

để thử nghiệm tính khả thi của mô hình chịu lỗi và các kỹ thuật trong đó Ngoài ra một ứng dụng thử nghiệm khác được xây dựng để đánh giá độ tin cậy của hệ thống trong đó liên hệ với số phiên bản trong kỹ thuật chịu lỗi Đưa ra một số đánh giá nhận xét các vấn đề cần quan tâm nghiên cứu ở các giai đoạn tiếp theo

Phương pháp nghiên cứu là tìm hi u rộng tấ ảể t c các nghiên c u đã có trên th ứ ế

giới về ệc áp dvi ụng kỹ thuật chịu lỗi vào h th ng nhúng thệ ố ời gian th c Vớự i những

kiến thức đóta sẽ ổ t ng hợp, phân tích và đưa ra các đề ất cxu ụ thể Những đề ất, xu

k ỹ thuật đó s đượẽ c kiểm nghiệm bằng cách xây dựng ứng dụng thử nghiệm chứng minh tính khả thi và đúng đ n của nó.ắ

CHƯƠNG 1 - T Ổ NG QUAN VỀ XÂY DỰNG PHẦN MỀM CHỊU LỖI

1.1 Độ tin cậy phần mề m

Độ tin c y là m t thu c tính có th đánh giá m t cách đ nh lư ng Đ tin c y c a ậ ộ ộ ể ộ ị ợ ộ ậ ủ

h ệ thống là xác suất mà dịch vụ ủa hệ thố c ng được cung cấp một cách chính xác như đặ ảc t Đ tin c y là m t trong nh ng thuộộ ậ ộ ữ c tính quan tr ng nh t đ đánh giá ọ ấ ểchất lượng phần mềm

Một cách chính xác thì khái niệm độtin cậy phần mềm đư c đ nh nghĩa là [7ợ ị ]:

“Độ tin c y là xác su t ho t đ ng không l i c a ph n mề ậ ấ ạ ộ ỗ ủ ầ m trong m t kho ng th i ộ ả ờ gian nh ấ ị t đ nh ở trong m ộ t môi trư ng cho trư ờ ớ c, v i m t m c đích c thể ” ớ ộ ụ ụ

Nhận xét:

• Khái niệm độ tin c y đây đã xem xét c khía c nh môi trư ng và m c đích ậ ở ả ạ ờ ụ

s dử ụng của hệ thống Chúng ta không thể giả đị nh rằng độ tin cậy của một

h ệ thống coi là bằng nhau ở các môi trường khác nhau với những mục đích

s dử ụng khác nhau ột ví dụ minh hoạ là độ tin cậy của phần mềm gõ văn M

bản được sử ụ d ng trong môi trư ng văn phòng, nơi mà ngườ ời dùng không quan tâm đến hoạ ột đ ng của ph n mềầ m như thế nào (h ch t p trung làm ọ ỉ ậtheo hướng d n đ t đư c hi u quảẫ ể đạ ợ ệ công vi c) cao hơn r t nhiều so với khi ệ ấ

s dử ụng phần mềm này trong môi trư ng đờ ại học nơi mà các sinh viên có – thể tìm hi u ra các gi i hể ớ ạn biên của phần mềm và sử ụ d ng hệ thống một cách không mong đợi nh m tìm ra l i ằ ỗ

• Độ tin c y b nh hư ng b i các h ng hóc h th ng Các h ng hóc có th x y ậ ị ả ở ở ỏ ệ ố ỏ ể ả

ra là hỏng hóc khi cung cấp dịch vụ, hỏng hóc cung c p dấ ịch vụ không như yêu cầu, hỏng hóc cung cấp dịch vụ không an toàn hay không bảo mật Một vài h ng hóc là kỏ ết quả ủ c a lỗ ặi đ c tả hoặc do các hỏng hóc xảy ra ở các hệ thống liên kết Tuy nhiên, đa số các hỏng hóc là hậu quả ủ c a hành động lỗi

h ệthống, được gây ra bởi các sai sót trong hệ thống

Các biện pháp để nâng cao đ ộtin cậy của phần mềm được chia thành hai nhóm chính: nhóm thứ nhất áp dụng trong quá trình xây dựng phần mềm (biện pháp tránh lỗi, biện pháp chịu lỗi); nhóm thứ hai đư c áp dụng sau khi phần mềm đã được xây ợ

dựng xong (biện pháp loại bỏ ỗi và biện pháp dự đoán lỗ l i) Do đó có bốn kỹ thuật thông dụng sau được áp d ng đ xây d ng phần mềụ ể ự m có độ tin c y cao [19]: ậ

K ỹ thuật loại bỏ ỗ l i

K ỹthuật này được thực hiện tại giai đoạn kiểm tra, kiểm soát phần mềm sau khi nó đã được phát tri n Nó ti n hành tìm kiếm các l i vể ế ỗ ẫn còn t n tồ ại thông qua các biện pháp kiểm tra, ki m soát rể ồi sau đó tìm cách loại bỏ chúng ra khỏi hệ

thống Một số phương pháp được sử ụ d ng đ ại bể lo ỏ ỗ l i phần mềm như: phương pháp kiểm thử (testing) phần mềm, phương pháp kiểm tra lại mã nguồn của phần

Hình 1.1 K ỹ thuật nâng cao độ tin cậy phần mềm trong các pha phát triể n

Hình trên mô tả quan h giệ ữa bốn phương pháp, giai đoạn th c hi n nhằm ự ệ

đạt đư c đợ ộ tin c y ph n m m L i có th t n t i sau quá trình phát tri n và ki m tra ậ ầ ề ỗ ể ồ ạ ể ểNhững lỗi đó cần phải chú ý trong quá trình hoạ ột đ ng b ng kằ ỹ thu t chịu lỗi Kỹ ậthuật dự đoán l i có thể ỗ áp dụng ở ấ t t cả các pha trong vòng đời phần mềm bằng cách dự đoán và ư c lư ng lỗi ớ ợ

Như trên đã nói, việc xây dựng ph n m m khó tránh khỏi l i x y ra trong ầ ề ỗ ảquá trình hoạt động Cho dù ần mềph m đó được thi t kế ế và phát triển bởi các nhà khoa học, các nhà l p trình su t s c nhậ ấ ắ ất và được sử ụ d ng các công cụ trợ giúp hiện

đại nh t thì cũng không th kh ng đ nh r ng ph n m m không có lỗi Thêm nữa, ấ ể ẳ ị ằ ầ ềtăng cường tính tin c y c a ph n m m là m t thách th c r t l n n u so sánh vớ ệậ ủ ầ ề ộ ứ ấ ớ ế i vi c làm đó đối v i phầ ứớ n c ng Thông thư ng l i phầ ứờ ỗ n c ng là các lỗi vật lý mà con người có th bi t rõ đ c đi m ho c có th nhậể ế ặ ể ặ ể n bi t trư c đư c l i ph n c ng khi nó ế ớ ợ ỗ ầ ứ

xảy ra Trái lại, lỗi phần mềm không phải là lỗi vật lý, nó không bị cháy, nổ hoặc méo mó như phần cứng, rất khó để nhìn th y, nh n th c đư c và quan tr ng nhất là ấ ậ ứ ợ ọ

rất khó đểkhắc phục lỗi phần mềm Lỗi phần mềm xảy ra trong nhiều trường h p ợkhác nhau, có thể ph n mềầ m được xây dựng theo đúng yêu c u đầ ặt ra nhưng bản thân yêu cầu đó đã được hiểu sai so v i bài toán th c t , có thớ ự ế ể ph n mềầ m được thiết kế và phát triển sai so với yêu cầu, có thể do l ậỗi l p trình của người phát triển, hoặc cũng có thể do môi trư ng tác đ ng Có mộ ềờ ộ t đi u cần lưu ý rằng, không giống như lỗi do phần cứng, quá trình thay đổi ho c s a ch a l i ph n m m có th sinh ra ặ ử ữ ỗ ầ ề ểcác l i mỗ ới khác Để kh c phục phắ ần mềm có lỗi không chỉ đơn gi n như ph n cứng ả ầ(thay thế ph n cứầ ng khác), vì vi c này có th làm phệ ể ần mềm càng bị lỗi nhi u hơn ề

Để hiểu rõ hơn về vấn đề này, chúng ta sẽ xem xét ba khái niệm quan trọng liên quan đến hoạt động không đúng của phần mềm đó là lỗi (error), sai sót (fault) và hỏng hóc (failure)

Khái niệm Mô tả

c ụ hay thông tin đểgiải quyết vấ ền đ

B ng 1.1 Các khái ni ả ệm liên quan đến độ tin cậy phầ n m m ề

Mối quan hệ giữa fault, error và failure được mô tả như sau [8]:

Hình 1.2 M ố i quan hệ ữ gi a fault, error và failure

Fault kích hoạt Error lan truyền Failure gây ra Fault

Hình 1.3 M ố i quan hệ ữ gi a fault, error và failure

Việc phần mềm bị ỗ l i có thể xuất phát từ nhi u nguyên nhân khác nhau: có ềthể ầ ph n mềm được xây dựng theo đúng yêu c u đ t ra nhưng bảầ ặ n thân yêu cầu đó

đã được hi u sai so vớể i bài toán th c t hoự ế ặc cũng có thể ph n m m đư c thi t k và ầ ề ợ ế ếphát triển sai so với yêu cầ ặu đ t ra Tuy nhiên, chúng ta cần phải lưu ý rằng: không giống như lỗi do phần cứng, đối với lỗi phần mềm thì quá trình thay đổi hoặc sửa chữ ỗa l i có th sinh ra các lể ỗi mới Việc khắc phụ ự phát sinh lỗc s i ph n m m ầ ềkhông chỉ đơn gi n như phả ần c ng (bứ ằng cách thay th các phế ần cứng khác), b i lở ẽ

nếu thay thế phần mềm bị ỗi bởi phần mềm khác có thể ẽ gây ra càng nhiều lỗi l s hơn

Ngoài ra, theo các nghiên cứu gần đây thì trong phần mềm tồn tạ ộ ại i m t lolỗi gọi là lỗi phần mềm chuyển tiếp (transient fault) [9] Đây là các lỗi không dự đoán được trong quá trình thi t k phần mềế ế m mà chúng ch xu t hi n khi hệ ốỉ ấ ệ th ng

đư c đưa vào hoợ ạt động, do đó mục tiêu xây d ng phần mềm không lỗi càng trở ựnên khó khăn hơn Để giải quyế ất v n đ này, ngưề ời ta bu c ph i nghĩ đ n hư ng ộ ả ế ớ

tiếp cận khác để xây d ng hệ ốự th ng có độ tin c y cao Đó là: thay vì cố ắậ g ng xây dựng phần mềm không có lỗ ới v i các chi phí cao và m t nhi u th i gian, ngư i ta ấ ề ờ ờ

đồng th i phát tri n h th ng v i các k thu t phát tri n ph n m m nhanh (rapid ờ ể ệ ố ớ ỹ ậ ể ầ ềsoftware development) cùng v i vi c áp d ng các kớ ệ ụ ỹ thuật phần mềm chị ỗi nhằm u lnâng cao hiệu năng củ ệ ốa h th ng.[10]

T ừ đó, phần mềm chịu lỗi (fault tolerant software) đượ ị- c đ nh nghĩa là phần mềm

có khả năng ho t đạ ộng và cung cấp các d ch vị ụ ngay c khi g p lỗả ặ i Khái niệm này

thống ph n mầ ềm để ệ h ống này có thể ựth th c thi được với những dữ ệ ầli u đ u vào lỗi

và đồng thời ngăn ngừa vi c hệ ệ thống đưa ra kết quả ỗ l i hay tiến hành điều khiển sai [11]

Để ả gi i quy t v n đ này bu c ngư i ta ph i nghĩ đ n vi c nghiên c u các gi i ế ấ ề ộ ờ ả ế ệ ứ ảpháp kỹ thu t đ phục vụ ậ ể cho việc xây dựng phần m m có khề ả năng ch u đư c lỗi ị ợHơn thế ầ c n nghiên c u xây d ng m t mô hình phứ ự ộ ần mềm chị ỗ ểu l i đ áp d ng các ụ

k ỹthuật chịu lỗi trên từ đó phát triển ứng dụng tuỳ theo từng nhu cầu riêng biệt

Ý tưởng chính c a việc xây dựủ ng b t kỳ ộ ệấ m t h thống ch u l i nào là có sẵn ị ỗ

một số tài nguyên để làm dự phòng cho hệ thống Có thể là dự phòng về phần cứng,

d ự phòng về phần mềm, dự phòng về ữ liệu hoặc dự phòng về thời gian [12 d ] Chẳng hạ ể ộn đ m t hệ thống máy tính hoạ ột đ ng với r i ro ít xủ ảy ra, ngư i ta thườ ờng

s dử ụng các phần cứng dự phòng Trong trường hợp nếu hệ thống máy tính đó bị

hỏng hóc thì phần bị ỏng lập tứ h c được thay thế hoặc bổ sung bởi các phần khác tốt hơn Đối v i ph n m m, d phòng bao g m d phòng các chương trình, các ớ ầ ề ự ồ ựmodule, các đ i tư ng đưố ợ ợc ph n m m đó s d ng hoầ ề ử ụ ặc cũng có thể ử ụ s d ng th i ờgian để ự d phòng cho h thốệ ng V i trọng tâm nghiên cứu vớ ề ấ v n đ ềxây dựng phần

mềm chịu lỗi thì các tài nguyên dự phòng chính cho một hệ thống phần mềm đó là

d ự phòng các chương trình và dựphòng dữ liệu

1.2.1 Dự phòng phần mềm

Phần mềm ở đây bao gồm các chương trình, các module, các hàm hay các

đối tư ng đượ ợc s d ng trong h th ng V m t ý tư ng nó đư c mư n t ý tư ng ử ụ ệ ố ề ặ ở ợ ợ ừ ở

d ựphòng phần cứng Tuy nhiên, không như phần cứng là chỉ ầ c n thay thế ộ m t phần

cứng khác tương đương thì hệ thống sẽ hoạ ột đ ng tốt trở ại, nếu phần mềm cũng l

được d phòng như v y thì nó ch làm cho h th ng l i sinh ra lự ậ ỉ ệ ố ạ ỗi như trước mà thôi Do vậy thông thường những phần mềm dự phòng được xây dựng theo cách khác hẳn so với ph n mầ ềm chính th c Các phứ ần mềm dự phòng khác v i phần ớ

mềm chính thức cả ề phương pháp tiếp cận bài toán, về cách thiết kế bài toán, khác v

v ề ngôn ngữ ập trình và thậm chí khác cả ề độ l v i ngũ nhân sự phát triển hệ thống

cho hệ ố th ng thì ngay l p t c nó phậ ứ ải thay đối giá trị ủ c a dữ liệ ầu đ u vào với hy

vọng giá trị ới của dữ liệ ầ m u đ u vào sẽ không làm cho hệ ố th ng bị ỗ l i như trư c.ớ

Phục h i sau khi l i là m t phồ ỗ ộ ần quan trọng trong quá trình xây dựng phần mềm chịu lỗi bao gồm phát hiện lỗi, chẩn đoán nguyên nhân, thực hiện cô lập hay cách ly lỗi và phụ ồi phần mềm lạc h i tình trạng mong muốn Quá trình ph c hụ ồi phần mềm khi gặ ỗi là mộp l t dãy các hành đ ng đưộ ợc thực hiện nhằm mục đích loại

b ỏcác trạng thái lỗi phần mềm (errors) trong quá trình hoạ ột đ ng của phần mềm Có hai dạng phụ ồ ỗc h i l i đó là phục h i quay lui (backward recovery) và ph c h i tiồ ụ ồ ến (forward recovery)

K ỹ thuật này luôn mặ ịc đnh rằng trạng thái của hệ thống trư c đó không có lớ ỗi Ta

gọi đó là điểm phục hồi hệ thống (checkpointing) đã đư c xác đ nh trượ ị ớc Trạng thái c a hủ ệ thống tại điểm phụ ồi này không bc h ị ả nh hưởng bởi các l i v a xỗ ừ ảy ra

K ỹthuật phục hồi quay lui có một số ưu điểm sau:

 Áp dụng t t đ i v i các l i chưa th d đoán có th x y ra trong quá trình ố ố ớ ỗ ể ự ể ảhoạ ột đ ng c a phủ ần mềm

 Nguyên lý hoạ ột đ ng c a k thu t này cho phép áp dủ ỹ ậ ụng rộng rãi mà không cần phải sử ổa đ i nhiều khi ứng dụng cho các phần mềm khác nhau

 K ỹ thuật này được áp dụng mà không cần biết nội dung lỗi khi nó xảy ra Yêu cầu duy nhấ ủa kỹt c thuật này là biết được trạng thái an toàn trước trạng thái l i hiỗ ện tại

 Được áp d ng m t cách trong su t đ i v i ngư i s d ng v i b t k l i ph n ụ ộ ố ố ớ ờ ử ụ ớ ấ ỳ ỗ ầ

mềm nào

Áp dụng kỹ thuật phục hồi quay lui có thể ạ lo i bỏ ớ b t một số ỗ l i mà có thể sau khi được ph c h i l i s b m t đi, có nghĩa là n u chương trình th c hi n mà không ụ ồ ỗ ẽ ị ấ ế ự ệ

xảy ra lỗi như trước

Tuy nhiên kỹ thu t phụ ồậ c h i quay lui cũng có m t s như c đi m nhấ ịộ ố ợ ể t đ nh:

 K ỹ thuật này tiêu tốn nhiều tài nguyên hệ ố th ng (thời gian, sự tính toán, sựlưu trữ )

 Thông thường h th ng t m th i d ng l i trong khi th c hi n ph c h i ệ ố ạ ờ ừ ạ ự ệ ụ ồ

 Nếu trong một hệ thống có nhiều tiến trình, một trong số đó sử ụng kỹ thuật d

phục h i quay lui thì hi ứng domino có thể ảồ ệu x y ra đ i v i toàn h th ng ố ớ ệ ố

1.3.2 Phục hồi tiến

Như đã nói ở trên, khi có l i x y ra trong h th ng phần mềỗ ả ệ ố m, các k thu t ỹ ậphục h i sồ ẽ tìm cách đưa h thệ ống về ạng thái không có lỗi Ktr ỹ thuật ph c h i tiụ ồ ến thực hiện việc này b ng cách bằ ỏ qua bước phát sinh ra lỗi hoặc tìm một con đường khác để ệ h thống ti p t c hoạ ộế ụ t đ ng v i hy v ng con đư ng m i không sinh ra l i ớ ọ ờ ớ ỗ

K ỹthuật này có một số ưu điểm sau:

 K ỹ thuật này áp dụng khá hiệu quả cho các hệ thống thời gian thực, tại vì khác v i kớ ỹ thuật phục hồi quay lui, nó không làm t n th i gian chung c a hố ờ ủ ệ

thống khi được kích hoạ t

 Đố ới v i các l i đư c đoán bi t trư c, s d ng k thu t này s r t phù h p ỗ ợ ế ớ ử ụ ỹ ậ ẽ ấ ợ

Một số nhược điểm của kỹ thuật phục hồi tiến:

 Với nguyên lý hoạ ột đ ng như trên, kỹ thuật này chỉ được áp dụng cho từng

h ệthống cụ thể ới các yêu cầu cụ thể v

 K ỹ thuật này chỉ loại bỏ đi các lỗi đã được nhận biết trư c Do đó yêu cớ ầu tiên quy t c a hế ủ ệ thống khi áp dụng kỹ thuật này là ph i hiả ểu biế ột cách t mchi ti t các l i có th gây ra cho hế ỗ ể ệ thống khi hoạ ột đ ng

Có một s cách giố ảm bớt tính r i ro trong quá trình thi t kủ ế ế ph n mềm, do đó ầtăng cường tính n đ nh c a phầổ ị ủ n mềm đó là sử ụ d ng các kỹ thu t xây dựậ ng ph n ầmềm có khả năng chịu lỗi Với việc sử ụng các kỹ thuật này, khi có lỗi xảy ra dtrong hệ thống, nó sẽ cung c p cho hệ ống các cơ chế ị ựấ th ch u đ ng được l i c a hỗ ủ ệ

thống Trong thực t các kế ỹ ậthu t như v y đã đượậ c nhắc đến và nghiên c u tứ ừ trên

20 năm nay Hiện nay tồn tạ ấi r t nhiều kỹ thu t xây dựậ ng ph n mềầ m ch u lỗị i được chia thành các nhóm như sau:[12]

 Nhóm các kỹ thu t s d ng m t phiên b n ph n m m (Single Version ậ ử ụ ộ ả ầ ềSoftware): Đây là các kỹ thu t cổ ểậ đi n, luôn được áp dụng trong khi phát triển bất kỳ ph n mềầ m nào, ví dụ như k thuỹ ật b t l i, kắ ỗ ỹ thu t quản lý ngoạậ i

 Nhóm các kỹ thu t s d ng nhi u d li u làm đ u vào cho ph n m m (Multi ậ ử ụ ề ữ ệ ầ ầ ềData): Các kỹ thu t này sử ụậ d ng cách biến đổi từ một dữ liệ ầu đ u vào duy

nhấ ểt đ cung cấp cho hệ ố th ng, nhằm hy vọng r ng mằ ột trong số ững dữ nhliệu đ u vào sau khi đã đưầ ợc biế ổn đ i sẽ cho kết quả đầ u ra như ý muốn Các kỹ thu ậật l p trình chịu lỗi được thi t kế ế nh m mụằ c đích cho phép hệ thống vẫn hoạ ột đ ng bình thường kể ả c trong trường hợp có lỗi phát sinh sau quá trình phát triển hệ ống Tuy nhiên các kỹ th thuật l p trình chậ ịu lỗi ch có tác dỉ ụng với giai

đoạn mã hoá các yêu c u ph n mềầ ầ m ch không th có tác d ng nứ ể ụ ếu người thi t k ế ế

và xây dựng hệ thống không hiểu yêu cầu bài toán thự ế ẫ ếc t d n đ n mã hoá sai so với yêu cầu thực tế Dư i đây sớ ẽ giới thiệ ổu t ng quan một số ỹ k thu t nằm trong nhóm ậ

k ỹthuật đa phiên b n và đa dả ữliệu

K ỹthuật đa thiết kế thực hiện xây dựng nhiều bi n th ph n m m khác nhau ế ể ầ ềnhằm phục vụ ộ m t công việc được bài toán đặt ra Nguyên tắc cơ bản của kỹ thuật

đa thiết kế là xây d ng nhi u thành ph n ph n mự ề ầ ầ ềm (software components) để ả gi i quyết cùng một bài toán Với giả định các l i c a các thành phỗ ủ ần phần mềm cấu thành hệ ố th ng hiếm khi trùng lặp nhau và nếu gi s có trư ng h p này x y ra thì ả ử ờ ợ ả

kết quả ủa các thành phầ c n cũng khác nhau đ đểủ phân biệt được kết quả nào đúng

hoặc đúng nhất Với việ ử ục s d ng kỹ thuật này, người thiế ế ần m m hy vt k ph ề ọng

rằng xác suất phần mềm bị ỗi sẽ giảm xuống l

Cần phải lưu ý rằng các bi n th ph n m m ph i đư c thi t k và phát tri n ế ể ầ ề ả ợ ế ế ểhoàn toàn khác nhau, chứ không ph i chỉả đơn thuần copy thành nhiều biến thể cùng

một cách thiết kế và phát triển Bởi vì nếu thực hiện như vậy thì không những làm giảm tính tin cậy của phần mềm mà còn có thể làm tăng s lưố ợng lỗ ủi c a phần mềm hiện tại M i nhóm phát triỗ ển đều có trách nhi m triệ ển khai và đưa ra kết quả như bài toán đã yêu cầu Trong toàn bộ quá trình h th ng hoạ ộệ ố t đ ng thì ít nhất phải có

một biến thể hoạ ột đ ng kèm theo Mục đích của phương pháp đa thiết kế là làm sao

để các bi n th chương trình làm d phòng l n nhau và ho t đ ng đ c l p v i nhau ế ể ự ẫ ạ ộ ộ ậ ớnhất có th V i mể ớ ục đích đó người xây dựng hệ ố th ng hy vọng rằng các l i phát ỗsinh ở ộ m t biến thể ần mềph m này có th không x y ra v i bi n th ph n mềm khác, ể ả ớ ế ể ầ

do v y hậ ệ ố th ng vẫ ến ti p tục th c hiự ện một cách bình thường.[12]

D ữliệ ầu đ u vào được cung cấp cho các bi n thế ể để các bi n thế ể ho t đ ng ạ ộ

Do có nhi u biề ến th cho nên cũng có nhi u k t qu u ra, các k t qu u ra đư c ể ề ế ả đầ ế ả đầ ợ

tổng hợp lạ ểi đ đưa qua một bộ quyế ịt đ nh, bộ quyế ịt đnh sẽ xác định biến thể nào cho k t quả đúng đ r i sau đó chuy n tiếp cho ph n x lý ti p theo Trong thực tế

có rất nhi u thuề ật toán sử ụ d ng đ xây d ng bộ quyế ịể ự t đnh, tùy thuộc vào đ c điặ ểm cũng như tình huống cụ ể ủ ừ th c a t ng bài toán để ch n lựọ a gi i thu t b quy t đ nh ả ậ ộ ế ịcho phù hợp

Phương pháp đa thiết kế có th ểáp dụng cho nhiều l p trong mớ ột hệ thống, có thể áp dụng cho phần cứng, ph n mầ ềm ng d ng, ph n m m h th ng, h đi u ứ ụ ầ ề ệ ố ệ ềhành Những trường hợp đó người ta gọi là đa thiết kế nhi u mức ề

Trong thực tế có nhi u kỹ thuật áp dề ụng nguyên tắc này, chẳng hạn như kỹ thu t ậRecovery blocks (RcB), kỹ thu t N-ậ version programming (NVP), kỹ thu t ậDistributed recovery blocks (DRB), kỹ thuật N self-checking programming (NSCP),

k ỹ thuật Consensus recovery blocks (CRB), kỹ thu t Acceptance voting (AV) Mỗi ậ

k ỹ thuật trên đều có những điểm mạnh, điểm yếu riêng Tùy theo t ng bài toán cừ ụthể mà nên ứng d ng kụ ỹ thu t phù hợp Dưới đây ta xem xét 2 kỹậ thu t chính là ậNVP và RcB

K ỹthuật lập trình N phiên bản (NVP) là một trong những kỹ thuật đa thiết kếphiên bản Tuy được g i là k thu t thu c môi trưọ ỹ ậ ộ ờng đa thiế ết k nhưng NVP là kỹthuật tĩnh (khác với RcB là kỹ thu t đ ng), có nghĩa là bài toán sậ ộ ử ụ d ng kỹ ật thuNVP được th c thi trên nhi u ti n trình ho c phiên b n (bi n th ) chương trình khác ự ề ế ặ ả ế ểnhau và kết quả cuối cùng chỉ ợ đư c chấp nhậ ến n u nó đã được chấp nhận bởi bộ quyết định Kỹ ật NVP sử ụthu d ng ít nh t hai (haấ y nhiều) phiên bản chương trình (variants) khác nhau để cùng gi i quy t mộả ế t bài toán đư c đợ ặt ra thông qua một thành phần được g i là bọ ộ phận quyết định (Decision Mechannism - DM) để ự l a chọn đưa ra kết quả ố t t nh t cho bài toán tấ ừ nhi u kếề t qu khác nhau a các phiên ả củ

bản chương trình khác nhau Do vậy, dễ dàng nhận thấy rằng: điểm mấu chốt của kỹthuật NVP là các phiên bản khác nhau của ph n m m và b ph n quy t đ nh Đ ầ ề ộ ậ ế ị ểgiảm thiểu khả năng trùng lặp sai sót giữa các phiên bản chương trình, mỗi phiên

bản chương trình thông thường được thiết kế và phát triển bởi các nhóm phát triển khác nhau, bằng các ngôn ngữ ậ l p trình khác nhau [4]

S ựhoạ ột đ ng của kỹ thuật NVP được mô tả như sau:

run Version 1, Version 2,…, Version n

if (Decision Mechanism (Result 1, Result 2,…, Result n ))

return Result else failure exception

Các phiên bản trong kỹ thu t NVP đư c thực thi song song trên nhiều hệ ậ ợthống phần cứng khác nhau Kết quả ủ c a từng phiên bản chương trình được xác

định tính đúng, sai thông qua bộ ph n quy t đ nh N u m t trong các phiên b n cho ậ ế ị ế ộ ả

kết quả đúng thì thuật toán sẽ có lời giải, ngược lại thì lỗi sẽ ả x y ra Trong trường hợp có nhiều phiên bản cùng cho k t quế ả đúng thì b phận quyộ ế ịt đ nh có nhiệm vụ tìm ra kết quả nào là k t quế ả đúng nhất Trong th c t có rự ế ất nhiều phương pháp đểthiết kế ộ b quy t định, tùy từng trườế ng h p c thể ớợ ụ v i từng bài toán cụ thể để có th ểchọn lựa được phương pháp xây dựng b quy t đ nh thích hợp nhất ộ ế ị

Sơ đồ ấ c u trúc hoạt động c a k thuật NVP: ủ ỹ

Hình 1.4 C ấ u trúc và hoạt động ủ ỹ thuật N phiên bản lập trình (NVP) c a k

K ỹ thuật khối phục hồi (RcB) là một trong những kỹ thuật xây dựng phần

mềm chịu lỗi cơ bản nhất Bên cạnh tính chất đa thiết kế, RcB còn có thể được xem như là kỹ thu t xây dựậ ng ph n m m ch u lầ ề ị ỗi đ ng, có nghĩa là viộ ệc chọ ự ến l a k t qu ả

của các khối thay thế được điều chỉnh phụ thuộc vào bộ kiểm tra chấp nhận kết quả(Acceptance Test AT) Th c t- ự ế cho th y r ng bấ ằ ấ ỳ ột k m t hệ thống nào cũng có thểđược thi t k và phát tri n theo nhiềế ế ể u cách khác nhau V i m i cách thi t k và phát ớ ỗ ế ếtriển khác nhau, hệ ố th ng sẽ có đ tin cộ ậy hệ ố th ng, mức độ ố t i ưu trong qu n lý bộ ảnhớ, th i gian th c thi hờ ự ệ thống khác nhau Kỹ thu t RcB sậ ẽ ưu tiên thực hi n các ệgiải pháp có mứ ộ ốc đ t i ưu hoá hệ ố th ng l n nh t trư c sau đó l n lư t đ n các gi i ớ ấ ớ ầ ợ ế ảpháp còn lại để nh m đằ ạt được k t quả ốế cu i cùng

Mô hình kỹ thu t RcB bao gồm các thành ph n chính sau [4ậ ầ ]:

• B ộ kiểm tra chấp nhận kết quả (Acceptance Test AT): Mục đích chính -

của AT là xác định kết quả đầu ra của các khối chương trình thay thế Chức năng của AT không nhất thi t phế ải kiểm tra tính đúng đắn củ ết a kquả đầ u ra mà trong một vài trường hợp có thể ch cỉ ần kiểm tra tính hợp

lý của nó

• Khối chương trình chính (Primary Alternate): Đây là kh i chương trình ố

được th c hiự ện đầu tiên c a m t chu trình k thu t RcB K t qu c a kh i ủ ộ ỹ ậ ế ả ủ ốchương trình chính cũng được ki m tra b ng AT, nếể ằ u được ch p nhận thì ấthuật toán k t thúc và thoát khế ỏi chu trình RcB Nếu kết quả không đư c ợchấp nhận thì thuật toán sẽ ụ ph c hồi quay lui (backward error recovery)

và các kh i thay th (alternate modules) số ế ẽ ầ l n lư t đượ ợc thực hiện dưới

s ự kiểm tra của AT Quy trình cứ tiếp tục cho đến khi có một module vượt qua đượ ực s kiểm tra c a AT ủ

• Các khối chương trình thay thế (Alternate modules): Các module c a ủkhối này được thi t kế ế hoàn toàn khác nhau, độc lập nhau mặc dù chúng giải quyết cùng m t yêu cộ ầu bài toán đ t ra Đặ ể đả m bảo tính đa thiết kế, thậm chí m i module có thỗ ể được thi t k và th c hi n theo các cách tiế ế ự ệ ếp cận khác nhau

Nguyên tắc hoạ ột đ ng của các khối (n khối thay thế) được mô tả ổ t ng quát như dưới đây:

Như đã được mô t , việ ầả c đ u tiên mà RcB th c hi n là b o đ m tho mãn các ự ệ ả ả ảđiều kiện của AT b ng cách s d ng chương trình chính, n u kếằ ử ụ ế t qu không đư c ả ợthoả mãn b i AT thì (n 1) cách th c hi n bài toán khác tiở - ự ệ ếp theo sẽ ợ ử ụ đư c s d ng

lần lư t cho đợ ến khi nào kết quả ủa th ật toán thoả mãn AT Trong trường hợp c ukhông có mộ ết k t qu c a chương trình thay th nào th a mãn thì l i s x y ra ả ủ ế ỏ ỗ ẽ ả

Sơ đồ kh i củ ỹố a k thuật RcB như sau:

Hình 1.5 C ấ u trúc và hoạt động củ ỹ thuật khối phục hồi (RcB) a k

Ta có khái niệm failure domain, t c là tứ ập các đầu vào gây ra lỗi phần mềm Còn failure region là biểu diễn hình họ ủa khái niệc c m failure domain, nó mô tả tính phân tán của các đi m trong failure domain và thông qua đó nó s xác để ẽ ịnh tính hi u ệ

nó thực hiện biến đ i đ u vào x thành đổ ầ ầu vào mới y=R(x) Đầu vào y có thể ấ x p xỉ

x hoặc có thể nó chứa thông tin x ở ộ m t khuôn dạng khác Và ta có chương trình con P và R sẽ xác đ nh một m i liên k t giị ố ế ữa P(x) và P(y) như hình vẽ minh hoạdưới đây:

Hình 1.6 Mô hình kỹ thu ật đa dữ ệ li u

Trong thực tế, kỹ thuật đa dữ ệ li u t n tồ ại với nhiều cấu trúc khác nhau Chẳng

hạn như hình v dướẽ i đây mô t sơ đồả khối của kỹ thuật đa dữ ệ li u khác, ngoài vi c ệbiến đổi dữ liệu đầu vào trước khi th c hiự ện chương trình con P cấu trúc này còn thực hiện việc điều ch nh trên k t quỉ ế ả P(y) nh ng sai lệữ ch có thể xuất hiện sau khi biế ổ ữ ệ ần đ i d li u đ u vào trư c đó như đượớ c minh ho trong hình sau ạ

Hoặc có thể xây dựng mộ ất c u trúc khác c a kủ ỹ thu t đa d liậ ữ ệu Dữ ệ ầli u đ u vào

được phân tích thành nhi u mẩu dữ ệề li u nhỏ, chương trình sẽ ợđư c th c hi n với ự ệ

từng mầu dữ liệu nhỏ nay rồi sau đó kết quả ẽ được tổng hợp lại từ nhiều kết quả s

“nh ”.ỏ

Hình 1.7 Mô hình kỹ thuật đa dữ liệ u

Hình 1.8 Mô hình kỹ thu ật đa dữ ệ li u

Ta thấy rằng, đối v i kớ ỹ thu t đa d liệậ ữ u thì điều quan tr ng nhọ ất là làm sao đểthiết kế được bộ ế bi n đổi dữ ệu (Data re expression algorimths) Tuy nhiên trong li -

thực t , vi c thi t kế ệ ế ế ộ b DRA ph thuụ ộc rất nhiều vào đ c điểặ m dữ ệ ầli u đ u ra của các bi n thế ể chương trình [3]

Khác với các kỹ thu t đa thiậ ết kế, nguyên tắc chung của kỹ thu t đa d liệu là sử ậ ữ

dụng nhiều bộ ữ liệ ầ d u đ u vào để phát hiện cũng như để “chịu lỗi” những lỗi phát sinh trong quá trình hệ thống hoạ ột đ ng

Các biện pháp xây d ng phự ần mềm ch u l i d a trên tư tư ng v tính “d ị ỗ ự ở ề ựphòng” trong hệ ố th ng Có nghĩa là người xây dựng hệ ố th ng sẽ xây dựng một số thành phầ ể ựn đ “d phòng” nh m sử ụằ d ng khi cần thiết D ựphòng ở đây có th là d ể ựphòng phần mềm mà cũng có thể là d ựphòng dữ li u ệ

Dựa trên những tư tưởng ền tả n ng đó ngư i ta đưa ra mờ ột số ỹ thuật xây k

dựng phần mềm chịu lỗi:

 K ỹthuật đa thiết kế: Dựa trên ý tưởng xây dựng nhiều biến thể ầ ph n mềm dự phòng cùng gi i quy t chung mả ế ột bài toán đặt ra Có hai kỹ thuật chính là kỹ thuật NVP và RcB

 K ỹthuật đa dữ uliệ : Thực hiện giải quyết bài toán với nhiều dữ liệ ầu đ u vào khác nhau bằng cách biến đổi dữ liệ ầu đ u vào sao cho vẫn giữ ợ đư c ý nghĩa cũng như không làm sai l ch đi kệ ết qu ảtính toán

Ngoài ra các phương pháp phục h i tr ng thái hồ ạ ệ thống thường sử ụ d ng bao gồm phương pháp phục h i quay lui và phương pháp ph c h i ti n ồ ụ ồ ế

 K ỹthuật phục hồi tiế : T ực hiện việc này bằng cách bỏ qua bước phát sinh n h

ra lỗi hoặc tìm một con đư ng khác đờ ể ệ h thống ti p t c hoế ụ ạt động với hy

vọng con đường mới không sinh ra lỗi

 K ỹthuật phục hồi quay lui: Thực hiện điều này bằng cách đưa hệthống quay trở ạ l i trạng thái trư c đó, khi chưa có lớ ỗi x y ra.ả

Mỗi phương pháp, kỹ thuật chịu lỗ ềi đ u có ưu đi m, như c điể ợ ểm riêng Phụ thuộc vào từng bài toán cụ ể th người thi t kế ế có th s d ng phương pháp nào mang lại ể ử ụhiệu quả cao nh t ấ

Mục tiêu ủa ta là nghiên cứu ỹ thuật xây dựng phần mềm chịu lỗi áp dụng c k cho hệ ố th ng nhúng Do vậ hương tiếy c p theo s ẽtrình bày tổng quan về ệ h th ng ốnhúng thời gian thực, ác c cơ chế hoạ ột đ ng cụ ể th Chẳng hạn như về mô hình các task, cơ chế ngắt, cơ chế ậ ị l p l ch và truy n thông gi a các task…ề ữ

CHƯƠNG 2 – T Ổ NG QUAN VỀ Ệ H TH Ố NG NHÚNG TH Ờ I GIAN THỰC

H ệthống nhúng được sử ụng rộng rãi trong nhiề d u lĩnh vực, chẳng hạn như điều khiển điện tử ự độ, t ng hóa nhà, văn phòng, và công nghi p ô tô Mệ ặc dù không tồn tại mộ ịt đ nh nghĩa chính xác v thuật ngữề nhưng nói chung h th ng ệ ốnhúng được xem là m t hộ ệ thống phần c ng, ph n mứ ầ ềm thực hiện một chức năng cụ

thể, thường là một phần của m t hộ ệ ống lớth n hơn Điều này ngụ ý giải thích cho chữ "nhúng" trong thuật ng này (là m t phữ ộ ần được nhúng vào hệ ố th ng lớn hơn) Ngoài ra hệ thống nhúng được thiế ế để ựt k th c hiện một chức năng cụ thể ợ đư c xác

định trước, trái v i m c đích chung chung c a h th ng máy tính bình thư ng ớ ụ ủ ệ ố ờ(mainframe, máy tính để bàn, máy tính xách tay, vv…)

H ệthống nhúng thường có một số đặc đi m chung như sau:ể

• Các hệ th ng nhúng đượố c thi t k th c hi n mộ ốế ế để ự ệ t s nhi m v chuyên dụng ệ ụ

chứ không ph i đóng vai trò là các hệ ống máy tính đa ch c năng Mả th ứ ột số

h ệ thống đòi hỏi ràng buộc về tính hoạ ột đ ng thời gian thự ểc đ đảm bả ộo đ

an toàn và tính ứng dụng; m t s h th ng không đòi hỏộ ố ệ ố i ho c ràng bu c ch t ặ ộ ặchẽ, cho phép đơn giản hóa hệ ố th ng ph n cầ ứng để giảm thiểu chi phí sản xuất

• Một hệ thống nhúng thường không p ải là một khối riêng biệt mà là một hệhthống phức tạp n m trong thiằ ết bị mà nó đi u khiển ề

• Phần m m đư c vi t cho các h th ng nhúng đư c g i là firmware và đư c ề ợ ế ệ ố ợ ọ ợlưu trữ trong các chip b nh ch c (read only memory) hoộ ớ ỉ đọ - ặc bộ ớ nh flash

chứ không ph i là trong mộ ổ đĩa Phần mả t ềm thường chạy với s tài nguyên ốphần cứng hạn chế: không có bàn phím, màn hình hoặc có nhưng với kích thước nhỏ, bộ ớ ạ nh h n chế

Hầu hết các hệ thống nhúng thời gian thực phải thỏa mãn các ràng buộc thời gian M t vài ví d là các các hộ ụ ệ thống điều khi n ô tô, thiể ết bị quân sự, y tế Việc

đảm b o ràng bu c th i gian là r t nghiêm ng t trong các h th ng hard real time ả ộ ờ ấ ặ ệ ốtuy nhiên các hệ thống soft real time có thể cho phép một vài sai số ề v thời gian

2.1 Khái niệm t ời gian thự h c

Thời gian th c rự ất khó định nghĩa Ý tư ng cơ bảở n c a th i gian th c th ủ ờ ự ể

hi n ệ ở ch , một hỗ ệ thống phải có những phả ứng thích hợp, đúng thờn i điểm với môi trường c a nó Nhi u ngư i luôn nghĩ r ng, thời gian thựủ ề ờ ằ c có nghĩa là th c sự ựnhanh, càng nhanh càng tốt, điều này là sai lầm Thời gian thực có nghĩa “đủnhanh” (fast enough) trong một ngữ ả c nh, một môi trường mà hệ thống đang hoạt

động Khi chúng ta đề ậ c p đ n máy tính đi u khi n đ ng cơ ô tô, chúng ta cần nó ế ề ể ộchạy càng nhanh càng tốt Thực chất c a vi c tính toán th i gian thủ ệ ờ ực không chỉ ở

việc phả ứn ng đủ nhanh mà còn phải đáng tin c y và chính xác Như vậ ậy, nghệ thuật c a l p trình th i gian th c chính là vi c thi t kủ ậ ờ ự ệ ế ế ệ h ống sao cho nó có thể thtiếp nhận một cách chính xác các ràng bu c vộ ề m t thời gian trặ ong suốt quá trình các sự ệ ki n ngẫu nhiên và không đồng bộ ả x y ra

V ề cơ bản, chương trình có tính thời gian thực phải có khả năng phản ứng lại các s ự kiện trong môi trường mà hệ ống làm việc trong khoth ảng thời gian nhất định cho trước Những h thốệ ng như v y đư c gọi là hệ thốậ ợ ng “điều khi n s ki n” (hay ể ự ệ

h ệ thống lái sự kiện event driven) và có thể được mô tả ằng thời gian trễ ừ khi – - b t

mà sự ệ ki n xảy ra cho t i khi hệ thống có hoạt động phản ớ ứng lạ ới v i sự ện đó ki

Thời gian thực, mặt khác, đòi hỏi một ới hạn cao hơn về ờgi th i gian trễ, được

gọi là “thờ ạ ậ ị i h n l p l ch” (scheduling deadline) Một hệ thống thời gian thực có thể

được chia làm 2 lo i “Thạ ờ i gian thực cứ ” và ng “th i ờ gian thực mềm” (hard time và soft real- time Trong hệ thống hard real- e, hệ ống phải tiếp nh n và tim th ậ

real-nắm bắt được scheduling deadline của nó tại mỗi và mọi thờ ểi đi m Sự sai sót trong việc đảm bảo deadline có thể ẫ ế d n đ n hậu quả nghiêm trọng thậm chí chết người

Lấy ví dụ, máy hỗ trợ nhịp tim cho bệnh nhân khi phẫu thuật Thuậ t toán điều khiển phụ thu c vào th i gian nh p tim cộ ờ ị ủa người bệnh, nếu thời gian này bị ễ tr tính m ng ạ

của người bệnh sẽ ị nguy hiể Đối với khái niệm soft rea time, scheduling b m deadline có bớt chặt chẽ hơn chút ít Chúng ta mong mu n hệ thống phản ứng lại ốcác sự ệ ki n trong thời gian cho phép nhưng không có gì thực s nghiêm trự ọng xảy

l-ra nếu hệ thống thỉnh tho ng bả ị ễ ỗ ề ặtr L i v m t th i gian có thờ ể chỉ đơn gi n là dẫn ả

đến h u qu gi m đ tin c y c a đ i tư ng đ i v i h th ng mà không gây h u qu ậ ả ả ộ ậ ủ ố ợ ố ớ ệ ố ậ ảnghiêm trọng Mạng lưới thu ngân tự độ ng của ngân hàng là ví dụ rõ nh t cho soft ấreal-time Mạng rút tiền tự động ATM là hệ ống thời gian th c? Khi th ự người dùng đưa thẻ ATM vào máy, người dùng mong là máy sẽ phản ứng lại trong vòng 1 hay 2

giây Nhưng nếu nó lâu hơn thế ề ồ ệ ấ, đi u t i t nh t có th x y ra là… ngư i dùng s t ể ả ờ ốruột và thấy khó chị ốu đ i với cái máy đó

Trên th c t có rự ế ất nhi u hề ệ thống phố ợp cả i h 2 loại trên, trong đó, một phần nào đó của h th ng làm vi c d a trên hard real-time, m t s phần khác lạ ựệ ố ệ ự ộ ố i d a trên soft real-time

ứng l i s ki n đó đư c kích ho t ạ ự ệ ợ ạ

Hình 2.1 Vòng l ặ p pooling

Tiến trình thực hiện của vòng lặp trên tỏ ra khá đơn giản và thích hợp với những hệ thống nhỏ không đòi hỏi quá gắt gao về mặt thời gian Tuy nhiên có một số hạn chế như sau:

 Thời gian phản ứng lại sự kiện phụ thuộc rất lớn vào vị trí mà chương trình đang thực hiện trong vòng lặp

 Tất cả các sự kiện được chương trình đối xử một cách bình đẳng và không có

sự ưu tiên nào cả

 Khi có một đặc tính mới, do đó là dịch vụ mới, được thêm vào chương trình, thời gian phản ứng lại dài thêm ra

Ý tưởng c a phương pháp ng t rất hữ ụủ ắ u d ng và cũng gây không ít khó khăn cho ngườ ậi l p trình Ý tư ng c a ng t như sau: s xuấ ệở ủ ắ ự t hi n của m t s kiện có th ểộ ự

“ngắt” ti n trình thế ực hiện của chương trình, “nhồi” thêm và th c hiự ện mộ ến t titrình khác vào như hình dưới Khi ti n trình nh i thêm đư c th c hi n xong, ế ồ ợ ự ệchương trình chính lại được th c hi n ti p từ ờ ểự ệ ế th i đi m b ngắị t Ti n trình c a s ế ủ ựkiện ngắt được th c hiện ngay lập tức mà không phảự i quan tâm đ n chương trình ếchính

một vấ ền đ con sub problem trở thành một tác vụ task Mỗi mộ task chỉ làm – - - t

một việc đơn gi n Sau đó, chúng ta giả ảthiết rằng các task này chạy song song với nhau Trên thực t , các ế task không bao giờ chạy song song nếu chúng ta không có

một hệ thống đa vi x lý Trong trườử ng hợp đang xét, các task ẽ chia sẻ ột bộ vi s m

x ửlý

Cũng giống như các chương trình khác, một task bao g m mã lồ ệnh để ự th c

hiện các chức năng mà task ải th c hiph ự ện (do người lập trình đã thiết k ) Mã lế ệnh

được ch a trong m t hàm tương t ứ ộ ự như hàm main() trong ngôn ngữ ậ l p trình C Điều làm nên s khác bi t c a task chính là ng c nh – context ch a trong ngăn x p ự ệ ủ ữ ả ứ ế– stack của nó

Hình 2 3 Cấ u trúc m ộ t task

Mỗi một task bao gồm :

 Mã nguồn ch a các ch c năng c a task ứ ứ ủ

 Một ngăn xếp stack để chứa ngữ ảnh của task– c

 Một hôp thư – mail box (tùy chọn) đểphục vụ cho việc truyền thông với các task khác

Chú ý rằng, đôi khi (nhiều khi khá hữu dụng) ta có thể ạ t o ra nhiều task t mừ ột hàmchung Như đã nói, điều làm cho m t task có th tách bi t và khác bi t v i các task ộ ể ệ ệ ớkhác chính là ngăn xếp c a nó Đây th c t chính là kiểu lậủ ự ế p trình hướng đ i tưố ợng

c ổ điển Ta có thể nghĩ rằng hàm task chính là việc đ nh nghĩa mị ột class Và một task tạo ra từ hàm đó chính là mộ ể ệt th hi n của class

Mặc dù có thể thấy các task là khá độc lập, nhưng v cơ bản thì chúng cũng ề

cần phải hợ tác vớp i nhau để thực hiện một mục đích chung đã được thiết kế ẵ s n cho hệ ố th ng Vì vậy, mỗi một task ần phải có mộ c t cơ chế truyền thông mà thông qua đó, chúng có thể ế ố k t n i, đ ng bộ ớồ v i các task khác Trong trư ng hợp này, ta ờ

gọi cơ ch đó là Hộp thư ế – mail box

Hình 2 4 Cấ u trúc mã l nh c ệ ủ a m t task ộ

Hình trên miêu tả ấ c u trúc mã nguồn của một task Đố ối s data dùng đ tham ể

s ố hóa mộ task Vai trò củt a nó cũng giống với các đối số argv và argc trong hàm main() với ngôn ngữ C Đố ố i s này th c sự ự quan t ng trong trư ng hợp nhiều task rọ ờcùng đượ ạc t o ra t m t hàm S duy nh t c a task đư c th hi n b i giá tr c a đ i ừ ộ ự ấ ủ ợ ể ệ ở ị ủ ố

s ốnày

Một task có thể được khở ội đ ng với một vài khởi tạo (có thể bao gồm khởi tạo

đố ối s data) Sau đó, thông thư ng, task s đi vào m t vòng l p không gi i h n T i ờ ẽ ộ ặ ớ ạ ạ

một vài điểm trong vòng l p, nó sặ ẽ đợ i "m t sộ ự kiện nào đó xảy ra", có thể, sự ện ki

đó là một bản tin được g i tới mailbox hoặử c ch đơn gi n là tràn bộ địỉ ả nh th i Trong ờkhi chờ các s kiệnm task s ẽkhông làm gì c và không ự ả s dử ụng bộ vi x lý M t vài ử ộtask khác nếu đã sẵn sàng hoạ ột đ ng hoặc đang hoạ ột đ ng s s d ng b vi x ẽ ử ụ ộ ửlý.Khi sự ệ ki n mà task đang chờ ả x y ra, task "th s ẽ ứ ậy" và ví dụ, nhận lấy bản c dtin, giải mã b n tin và hoả ạ ột đ ng theo các yêu cầu đặt sẵ ựa trên m t hn d ộ ệ thống các yêu cầu đư c phân đợ ịnh bởi câu l nh switch() Sau khi th c hiệ ự ện xong yêu cầu, task

lại quay trở ại trạng thái chờ ự kiện l s

Có thể ấ th y rằng tất cả các task đều dành ph n lầ ớn thời gian cho việc ch m t ờ ộ

s ự kiện nào đó x y ra Đây cũng chính là lý do đả ể h ệ thống có thể hoạ ột đ ng đa nhiệm

Trong hệ ố th ng nhúng thời gian th c, sự ự công b ng trong việằ c chia sẽ thời gian thực hiện giữa các task là không quan trọng lắm Thay vào đó th i gian đáp ờ ứng

mới là yếu tố đặc trưng quan trọng cho ệ thống nhúng thời gian thự Một task h cđược giao cho 1 deadline thì nh t đ nh ph i hoàn thành nhiệm vụ ủấ ị ả c a nó trong

khoảng thời gian deadline đó Nếu không thì hệ ố th ng sẽ không được g i là thọ ời gian thực nữa Thời gian thực thi c a mủ ột task thư ng đườ ợc thiế ập ngay từ khi t lthiết kế, đặc bi t nệ ếu task hoạt động định kỳ Có hai lo i task: hard real time task và ạ -soft real time task V i hard real time task thì deadline nh- ớ - ấ ịt đnh phả ải đ m bảo nếu không hệ ố th ng sẽ ụ tr c trặc và gây nguy hiểm Với soft real-time task thì deadline nên được đảm b o, trong trư ng h p bị ỡả ờ ợ l deadline thì h thệ ống cũng không bị ả nh hưởng nghiêm trọng lắm

2.4 Cơ chế ậ l p lịch

Các task hoạt động dưới s giám sát cự ủa kernel th i gian th c Chúng bao g m: ờ ự ồ

• Một tập hợp các dịch vụ thực hiệ các công viện c như đồng bộ hoá và giao

tiếp truyền thông giữa các task

• Một bộ ập lịch (scheduler) với chứ l c năng đảm bả chỉ có duy nhất task ới o v

mức ưu tiên cao nh t đang đưấ ợc thực thi

B lộ ập lịch xem các task như những máy trạng thái (state machine) ất cả các Tkernel đều có mô hình trạng thái của nó, tuy nhiên, thông thường thì các mô hình trạng thái nảy rất phức tạp Hình dư i đây ớ cho thấy một mô hình trạng thái mang tính khái niệm của task Trong hình, ta th y có các trấ ạng thái:

• Đang thực thi ( Running): chỉ có duy nhất một task được nằm trong trạng thái

này Một task có thể ự độ t ng chuy n tể ừ trạng thái đ ang th c thi ự sang trạng

thái khoá (Blocked) bằng việc chờ đợi một sự ệ ki n xảy ra Trong một hệ

thống có chiếm quyền thực thi (chúng ta sẽ đề ậ c p đ n ế nó sau), bộ ậ l p lịch có

thể ắ b t một task đang ở ạtr ng thái đ ang th c thi xuống trạ ự ng thái sẵn sàng (Ready) nếu có một task ới mứ v c ưu tiên cao hơn chuy n để ến trạng thái ẵn s

sàng Chúng ta gọi nó là s ự chiếm quyền thực thi (preemption)

• Sẵn sàng (Ready): nếu một task đã sẵn sàng để hoạ ột đ ng nhưng lại có mức

ưu tiên thấp hơn task đang thực thi, task đó s đưẽ ợc chuyể ến đ n trạng thái này và chờ Task này sẽ được chuyể ến đ n tr ng thái ạ đ ang th c thi n ự ếu nó trởthành task có mức ưu tiên cao nhấ t

• Khoá ( Blocked): một task ị khoá là task đang đợi một sự kiệ b n nào đó xảy ra,

ví dụ như một b n tin, tin nhả ắn được gử ếi đ n hộp thư của task đó, hay th i ờgian chờ ủ c a task kết thúc…

Hình 2 Mô hình tr ng thái c 5 ạ ủ a task

2.4.1 Lập lịch có chu kỳ

Có rất nhiều task mà công việc c a nó chủ ỉ là thứ ậc d y theo chu kỳ, làm một vài công việc nào đó và quay trở ạ l i ng ti p Có m t vài phương pháp đ th c hi n ủ ế ộ ể ự ệcác task kiểu này chẳng hạn như dùng hàm trễ Delay() hoặc hàm chờ WaitTilNext()

Hàm trễ Delay() làm cho task ị khoá trong một thờ b i gian xác đ nh cho trưị ớc, thông thường thời gian này được biểu di n b ng xung đồễ ằ ng h ồ (clock tick) Hàm

WaitTilNext() s ẽkhóa tác vụ cho tới phiên thực hiện kế tiếp Trong trư ng hợp này, ờ

b lộ ập lịch sẽ đánh th c tác vứ ụ vào đúng th i điờ ểm thích hợp mà không quan tâm

đến th i gian th c hi n tác v ờ ự ệ ụ

2.4.2 Lập lịch không theo chu kỳ

Một số task phải phản ứng lại các sự kiện xảy ra ngẫu nhiên tại các thờ ểi đi m khác nhau Một sự kiện có th là vi c m t gói dể ệ ộ ữ liệu từ trên mạng được gử ếi đ n nơi, việc một cái công tắc đóng lại để chỉ ra là b nư c đã đầể ớ y ho c cũng có th là ặ ể

s kự ết thúc việc convert một tín hiệu tương tựsang số ủa bộ c Thông thường, các sựkiện không đồng bộ này đư c giao tiếp v i máy tính thông qua các ngợ ớ ắt Chương trình con d ch vị ụ ng t phắ ải có cách nào đó để ế k t nố ựi s xu t hiấ ện của ngắ ới task t vchịu trách nhiệm xử lý sự ệ ki n

Có 2 phương thức cơ bản cho việ ậc l p lịch một task: chiếm quy n th ề ự c thi và không c m quy hiế ề n th c thi ự Xét hai task: task 1 có mức ưu tiên thấp hơn đang thực

hiện và task 2 có mức ưu tiên cao hơn đang bị khoá để ờ ộ ch m t sự ện xảy ra, sự kikiện này được thông báo bở ội m t tín hi u ngắt ệ

Phần A trên hình sau cho thấy những gì xảy ra trong h ệthống không có tính chiếm quyền ưu tiên Chương trình con dịch v ng t ISR làm cho task 2 v i m c ưu ụ ắ ớ ứtiên cao hơn chuyể ừn t trạng thái khoá sang tr ng thái sẵn sàng Tuy nhiên, đến khi ạISR được th c hi n xong thì ự ệ task ớ ứ1 v i m c ưu tiên thấp hơn vẫn s ợ ếẽ đư c ti p tục

thực thi tại điểm nó bị ngắt Sau đó, khi task 1 bị khoá để ờ ự ệch s ki n thì task 2 mới được chuy n sang trạng thái thực thi ể

Phần B trên hình ứng với trường hợp của hệ thống có tính chiếm quyền ưu tiên Điểm khác bi t ở ệ đây là bộ ậ ị l p l ch được g i đ n ở ốọ ế cu i chương trình con dịch

v ụngắt Bộ ập lị l ch xác định task có mức ưu tiên cao đang ở trạng thái sẵn sàng và

chuyển nó lên tr ng thái ạ thực thi Do đó, task với mức ưu tiên th p đã bấ ị chiếm quyền th c thi ự

Hình 2 6 Lậ ịch có p l và không có chiế m quy ề n thự c thi

Một hệ thống không có tính chiếm quyền thực thi muố ằng tất cả các task n rphải là “những công dân tốt” b ng cách tằ ự nguyện trao trả ộ ử b x lý cho các task khác để chắc chắn một điều: các task đều có cơ hội để ử ụ s d ng b x lý Các th h ộ ử ế ệWindows trước kia đều là d ng này Linux thì khác, nó là m t h đi u hành có tính ạ ộ ệ ềchiếm quyền th c thi m c dù các bự ặ ản Linux chuẩn không quan tâm đến vấ ề ờn đ th i gian thực và trong một thời gian dài vấn đề chiếm quyền thực thi không đư c đợ ề

c p ậ đến

Các h ệthống có tính chiếm quyền th c thi cung cự ấp cho ta nhiều th i gian ờ

ph n ng ả ứ hơn bởi vì task có mức ưu tiên cao s đượẽ c xử lý ngay l p tậ ức Đây chính

là điểm c t lõi củố a th i gian thực: khảờ năng đ m b o ph n ng l i ả ả ả ứ ạ nhanh nhấ v i t ớ

thời gian một task nhường lại bộ ử x lý cho các task khác Tuy nhiên trong một hệ

thống có chiếm quyền ưu tiên, vấ ền đ tranh ch p tài nguyên hấ ệ ốth ng cũng c n đư c ầ ợquan tâm cẩn th n ậ

Trong phương thứ ậ ịc l p l ch ki u vòng lặp robin, mộể t task s đư c th c thi đ n ẽ ợ ự ếkhi nào nó bị khoá (block) đ ch m t sự ệể ờ ộ ki n xuất hiện hoặc cũng có khi nó tình nguyện nhường (yield) bộ ử x lý l i Sạ ự khác biệt giữa khoá và nhường là ở chỗ: trong trường hợp th 2, taskứ s ẽquay trở ại trạng thái sẵn sàng ứ l ch không ph i tr ng ả ạ

thái khóa

Xét trường h p trong danh sách S n sàng có 3 ợ ẵ task th ứ ự ầ t l n lượt là A, B, C Các task này có cùng mức ưu tiên như nhau Task A đứng đầu danh sách và được chuyể ến đ n trạng thái Thực thi Khi task A nhường (yield) bộ ử x lý, task B trởthành tr ng thái th c thi và danh sách Sạ ự ẵn sàng sẽ như sau:

Nhát cắt th i gian (time slicing) ờ là một bi n thế ể ủ c a vòng l p robin ặ Trong

đó, nó quy định m i task s nhỗ ẽ ận được m t lư ng th i gian nh t đ nh hay còn gọi là ộ ợ ờ ấ ịnhát c t th i gian Vi c làm này bắ ờ ệ ảo vệ các task khỏi trường hợp chiếm dụng bộ ử x

lý quá lâu Do đó một task s ẽ ạch y cho đến khi nó b ịkhoá, nó tình nguy n như ng ệ ờhay quá hạn về ờ th i gian cho phép Tuỳ thuộc vào hoàn c nh và yêu cả ầu, các task s ẽ

có lượng th i gian cho phép b ng nhau hoờ ằ ặc khác nhau

Ưu tiên deadline sớm nh t (Earliest Deadline First (EDF) là một giải thuật ấlập lịch mới được nghiên cứu và áp dụng trong các hệ thống thời gian thực Ý tưởng

của nó là mỗi khi một sự kiện lập lịch xảy ra (ví dụ ột task kết thúc) bộ ập lịch sẽ m ltìm kiếm trong hàng đợi các task và ch n task nào có tiọ ến độ ầ g n sát nhấ ới t vdeadline của nó Với các task định kỳ có deadline bằng với chu kỳ thực hiện của nó, EDF sẽ là gi i thu t tả ậ ối ưu nhất Nó sẽ đả m bả ất c task so t ả ẽ hoàn thành deadline miễn là tổng lượng tả ử ụi s d ng CPU không vư t quá 100% Tuy nhiên khi hệ ốợ th ng

b ị quá tải thì số task bị ỡ deadline sẽ trở nên khó đoán đị l nh trư c đư c Đây là yớ ợ ếu

đi m đáng kể ể ủ c a gi i thu t này Do vậả ậ y EDF không được sử ụ d ng nhiều trong các

h ệthống thời gian thực công nghiệp Thay vào đó người ta s d ng các gi i thu t ử ụ ả ậ

lập lị h ưu tiên cố định (fixed priority scheduling) Với giải thuậc t đó các task có độ

ưu tiên thấp có thể ỡ l deadline nhưng những task có đ ưu tiên cao sộ ẽ luôn đ m b o ả ảdeadline c a mình.ủ

2.5 Cơ chế truy ề n thông

M c dù cá áặ c t c vụ được xem như độc lập với nhau nhưng nhiệm vụ  tổng thể ủa c

hê thống yêu cầu cá ác t c vụ phải có s ựliên hệ ợ h p tác với nhau Do đ , th nh phần ó à

cốt yế ủa bất cứ ệ điều h nh thời gian thực nào u c h à là tập hợp c c dịch vụ truyền áthông và đồng bộ

Có một v i cơ chế đồng bộà và ytru ền thông hay được sử ụng bao gồm: d

• Semaphore: Sử ụ d ng cho vi c đ ng b hó íệ ồ ộ a t n hi u và kh năng t n d ng tài ệ ả ậ ụnguyên

• C s ờ ự kiện (Event Flag): Chỉ ra một hoặc v i sự kiện đ ảà ã x y ra Đây thực

chất là m rở ộng củ Semaphore trong đó a cho ph p đồng bộ hóa trên cá s é c ự

ki n.ệ

• Mailbox, hàng đợi và đường ống: Cung cấp cơ chếtruyền thông dữ liệu giữa

cá ác t c vụ

2.5.1 Semaphore

Hã éy x t 2 t c vụ, mỗi một t c vụá á có nhiệm v ụ in một bản tin c ội dung I ó n “

am task n (n l” à một số thứ ự ủ t c a task) bằng một máy in chia sẽ như trong hình dưới N u chúế ng ta không d ng b t c m t cơ ch ng b nào thì k t qu có th sử ụ ấ ứ ộ ế đồ ộ ế ả ểlà: “II a amm tatasskk 12” Chính vì vậy nhu cầu cần thiế ở đây là phải có cơ chế t nào đó để máy in ch có thỉ ể đư c sử ụợ d ng bởi 1 task ở ộ m t thời đi m xác để ịnh

Semaphore hoạt động giống như một chi c chế ìa kh a cho việó c truy cập tài nguyên Chỉ có task có ìch a kh a nó ày mới có quyề ử ụn s d ng tài nguyên Để có th ể

s dử ụng i nguyên (l tà à chiếc máy in trong trường hợp này), task ần yêu cầu c(acquire) ch a kh (semaphore) bằng ch gọi tới một dịch vụ như trong h nh dưới ì óa cá ì

Nếu ch a kh a ở trạ g th i sẵn s ng, tứì ó n á à c là tài nguyên ( y in) hi n tmá ệ ại không được

s dử ụng bởi bất kỳ ộ m t tác v nàụ o, task ó có th đư c cho phép s d ng tài đ ể ợ ử ụnguyên Sau khi sử ụ d ng xong, tác vụ đ phải trả ạ ó l i release( ) semaphore cho các task á ó kh c c thể ử ụ s d ng