Nghiên cứu ứng dụng “NModel” trong việc phát triển hệ thống nhúng thời gian thực

1

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ





NGUYỄN THỊ HẠNH





NGHIÊN CỨU ỨNG DỤNG “NMODEL” TRONG VIỆC PHÁT
TRIỂN HỆ THỐNG NHÚNG THỜI GIAN THỰC








LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội - Năm 2014
2

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ




NGUYỄN THỊ HẠNH

NGHIÊN CỨU ỨNG DỤNG “NMODEL” TRONG VIỆC PHÁT
TRIỂN HỆ THỐNG NHÚNG THỜI GIAN THỰC



Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103



LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN



NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS. TS. Đặng Văn Đức

Hà Nội - Năm 2014

3



LỜI CAM ĐOAN
Tôi xin cam đoan rằng nội dung và những kết quả của luận văn tốt nghiệp này
là do tôi tự nghiên cứu dƣới sự hƣớng dẫn của PGS.TS Đặng Văn Đức. Trong toàn bộ
nội dung của luận văn, những điều đƣợc trình bày là của cá nhân tôi hoặc đƣợc tổng
hợp từ nhiều nguồn tài liệu khác. Tất cả các tài liệu tham khảo đều đƣợc trích dẫn rõ
ràng ở phần cuối của luận văn.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của mình.
Hà Nội, ngày 10 tháng 06 năm 2014
Học viên



Nguyễn Thị Hạnh
4

LỜI CẢM ƠN
Trong quá trình học tập và nghiên cứu tại khoa Công nghệ thông tin trƣờng Đại
học Công nghệ - Đại học Quốc gia Hà Nội, đến nay tôi đã hoàn thành chƣơng trình
học và luận văn tốt nghiệp. Tôi không thể quên gửi lời cảm ơn tới các thầy cô, gia đình
và bạn bè.
Đầu tiên, tôi xin đƣợc bày tỏ lòng biết ơn sâu sắc tới sự giúp đỡ của giảng viên
hƣớng dẫn PGS.TS. Đặng Văn Đức. Trong suốt thời gian làm luận văn, thầy đã giúp

đỡ và chỉ bảo nhiệt tình để tôi có thể hoàn thành luận văn đạt đƣợc kết quả tốt.
Tôi cũng xin gửi lời cám ơn đến tập thể các thầy cô giáo trong Khoa CNTT –
ĐH Công Nghệ - ĐH Quốc Gia Hà Nội cùng các bạn học viên cao học khóa K18 đã
tạo điều kiện cho tôi tiếp thu kiến thức, làm việc theo nhóm và có một môi trƣờng học
tập tốt nhất.
Cuối cùng, tôi xin gửi lời cảm ơn tới gia đình tôi – những ngƣời thân đã động
viên tôi bằng cả vật chất lẫn tinh thần trong suốt thời gian tôi học tập.
Tuy rằng, tôi đã cố gắng hết sức trong quá trình làm luận văn nhƣng không thể
tránh khỏi thiếu sót, tôi rất mong nhận đƣợc những góp ý của thầy cô và các bạn.
Hà Nội, ngày 10 tháng 06. năm 2014
Học viên



Nguyễn Thị Hạnh
5

MỤC LỤC
LỜI CAM ĐOAN 3
LỜI CẢM ƠN 4
MỤC LỤC 5
DANH MỤC CÁC HÌNH VẼ 8
CHƢƠNG 1. GIỚI THIỆU 10
1.1. Đặt vấn đề 10
1.2. Nội dung nghiên cứu 10
1.3. Tầm quan trọng của kiểm thử dựa trên mô hình 11
1.4. Cấu trúc luận văn 11
CHƢƠNG 2. TỔNG QUAN VỀ HỆ THỐNG NHÚNG 12
2.1. Các khái niệm về hệ thống nhúng 12
2.1.1. Hệ thống nhúng 12

2.1.2. Hệ thời gian thực 13
2.2. Cấu trúc phần cứng hệ thống nhúng 14
2.2.1. Các thành phần cơ bản 14
2.2.1.1. Đơn vị xử lý trung tâm (CPU) 14
2.2.1.2. Bộ nhớ 14
2.2.1.3. Thiết bị ngoại vi 15
2.2.1.4. Bus địa chỉ, bus dữ liệu và bus điều khiển 17
2.2.2. Một số nền phần cứng nhúng thông dụng 18
2.2.2.1. Vi điều khiển nhúng 18
2.2.2.2. Chip DSP 19
2.3. Kiến trúc phần mềm nhúng 19
2.3.1. Kiến trúc Round-Robin (RR) 19
2.3.2. Kiến trúc Round-Robin với ngắt (RRI) 20
2.3.3. Kiến trúc Lập lịch dòng chức năng (FQS) 21
2.3.4. Kiến trúc Hệ điều hành thời gian thực (RTOS) 21
2.4. Hệ điều hành thời gian thực 22
2.4.1. Khái niệm hệ điều hành thời gian thực 22
2.4.2. Tác vụ (Task) và trạng thái tác vụ 23
2.4.3. Queue và các trạng thái của queue 24
6

2.4.4. Các phƣơng pháp lập lịch 26
CHƢƠNG 3. NGHIÊN CỨU VỀ KIỂM THỬ VÀ PHÂN TÍCH DỰA TRÊN MÔ
HÌNH 28
3.1. Tổng quan 28
3.1.1. Khái niệm NModel 28
3.1.2. Khái niệm chƣơng trình mô hình 28
3.1.3. Khái niệm phân tích dựa trên mô hình 29
3.1.4. Khái niệm kiểm thử dựa trên mô hình 29
3.1.5. Chƣơng trình mô hình trong quy trình phần mềm 30

3.2. Hệ thống với các mô hình hữu hạn 30
3.2.1. Chƣơng trình mô hình 30
3.2.1.1. Hành động (Action) 30
3.2.1.2. Hành vi (Behavior) 31
3.2.1.3. Cấu trúc chƣơng trình mô hình hợp đồng C# 31
3.2.2. Thăm dò và phân tích chƣơng trình mô hình hữu hạn 32
3.2.2.1. Máy trạng thái hữu hạn (FSM-Finite State Machines) 32
3.2.2.2. Thăm dò 33
3.2.2.3. Phân tích 36
3.2.3. Cấu trúc chƣơng trình mô hình với thành phần (Composition) 36
3.2.3.1. Điều khiển kịch bản (Scenario control) 37
3.2.3.2. Thành phần (Composition) 37
3.2.4. Kiểm thử hệ thống đóng 43
3.2.4.1. Tạo bộ kiểm thử (test suite) cho phƣơng pháp kiểm thử ngoại tuyến
(Offline) 43
3.2.4.2. Dấu vết và giới hạn 43
3.2.4.3. Bản khai thác kiểm thử (Test harness) và việc thực thi kiểm thử (Test
execution) 44
3.2.4.4. Hạn chế của kiểm thử ngoại tuyến 46
3.2.5. Kiểm thử các hệ thống với trạng thái phức tạp 46
3.2.5.1. Kiểm thử “on-the-fly” 46
3.2.5.2. Các chiến lƣợc 50
CHƢƠNG 4. XÂY DỰNG DEMO VÀ KIỂM THỬ HỆ THỐNG VỚI NMODEL 53
4.1. Giới thiệu NModel 53
7

4.1.1. Cài đặt NModel 53
4.1.2. Cách sử dụng các công cụ mpv, otg, ct 53
4.1.2.1. Công cụ mpv 53
41.2.2. Công cụ otg 54

4.1.2.3. Công cụ ct 54
4.2. Xây dựng và thực nghiệm với demo hệ thống client/server 55
4.2.1. Mô tả bài toán 55
4.2.2. Kiểm thử demo bằng NModel 57
4.2.2.1. Kiểm thử ngoại tuyến (Offline) 57
4.2.2.2. Kiểm thử on-the-fly 65
CHƢƠNG 5. KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN 67
5.1. Kết luận 68
5.2. Hƣớng phát triển 68
TÀI LIỆU THAM KHẢO 69
PHỤ LỤC 70

8

DANH MỤC CÁC HÌNH VẼ
Hình 2.1: Mẫu xe trong cuộc thi Micom Car Rally (chip Renesas H8) 12
Hình 2.2: Một số hệ thống nhúng thông dụng nhƣ robot, máy in và điện thoại 13
Hình 2.3:Cấu trúc CPU 14
Hình 2.4: Kiến trúc bộ nhớ Von Neumann và Havard 15
Hình 2.5: Cấu trúc ghép nối giữa máy tính và thiết bị ngoại vi 16
Hình 2.6: Chu kỳ hoạt động bus dồn kênh 18
Hình 2.7: Kiến trúc nguyên lý của VĐK với cấu trúc Havard 19
Hình 2.8: Minh họa kiến trúc RR bằng giả mã và đồ thị 20
Hình 2.9: Minh họa kiến trúc RRI bằng giả mã 21
Hình 2.10: So sánh kiến trúc RTOS và OS chuẩn 22
Hình 2.11: Cấu trúc hệ điều hành thời gian thực 23
Hình 2.12: Cấu trúc của một Task cơ bản 24
Hình 2.13: Các trạng thái của task 24
Hình 2.14: Hàng đợi Queue 25
Hình 2.15: Trạng thái của Queue 25

Hình 2.16: Phân loại các phƣơng pháp lập lịch 26
Hình 2.17: Giản đồ thời gian thực hiện lịch của tác vụ 27
Hình 3.1: Sơ đồ hoạt động của MBT 29
Hình 3.2: Mô hình chữ V trong phát triển phần mềm dựa trên mô hình 30
Hình 3.3: Một thuật toán thăm dò đầy đủ 35
Hình 3.4: Chƣơng trình mô hình M1 38
Hình 3.5: Chƣơng trình mô hình M2 39
Hình 3.6: MP M1xM2 - sản phẩm của M1 và M2 39
Hình 3.7: Phần mở rộng vòng lặp của M1 39
Hình 3.8: Phần mở rộng vòng lặp của M2 40
Hình 3.9: MP M1xM2, các trạng thái đôi và hành động phù hợp 41
Hình 3.10: Các trạng thái , hành động trong M1xM2 41
Hình 3.11: M1 dƣới dạng FSM text file 42
Hình 3.12: Bag implementation 47
Hình 3.13: Bag Model 48
Hình 3.14: Một tính năng của mô hình và kịch bản 49
Hình 3.15: Bag stepper 50
Hình 3.16: Giao diện IStrategy 51
Hình 4.1. Thiết bị điều khiển từ xa – Hệ thống Client/Server 55
Hình 4.2: Giao thức client/server 56
9

Hình 4.3: FSM đúng của MP hợp đồng 58
Hình 4.4: FSM của MP kịch bản 59
Hình 4.5: FSM của MP kịch bản kết hợp với MP hợp đồng 59
Hình 4.6: FSM của test suite đƣợc tạo với MP hợp đồng 62
Hình 4.7: FSM của test suite đƣợc tạo khi MP hợp đồng biên soạn với MP kịch bản . 63
Hình 4.8: Kết quả kiểm thử ngoại tuyến với trƣờng hợp sử dụng MP hợp đồng 64
Hình 4.9: Kết quả kiểm thử ngoại tuyến với trƣờng hợp sử dụng điều khiển kịch bản
(MP hợp đồng đƣợc biên soạn với MP kịch bản) 64

Hình 4.10: Kết quả kiểm thử ngẫu nhiên khi sử dụng MP hợp đồng 66
Hình 4.11: Kết quả kiểm thử ngẫu nhiên khi sử dụng điều khiển kịch bản (1) 66
Hình 4.12: Kết quả kiểm thử ngẫu nhiên khi sử dụng điều khiển kịch bản (2) 67
10

CHƢƠNG 1. GIỚI THIỆU
1.1. Đặt vấn đề
Ngày nay, các hệ thống nhúng rất phát triển với những ứng dụng rộng rãi trong
nhiều lĩnh vực công nghiệp và đời sống. Các hệ thống nhúng có kiến trúc phần cứng
cũng nhƣ phần mềm rất đa dạng và phong phú. Nhƣ chúng ta đã biết, trong phát triển
phần mềm thì hoạt động kiểm thử có vai trò hết sức quan trọng, mang tính sống còn
của sản phẩm và với phần mềm nhúng cũng không phải là ngoại lệ. Sự phát triển của
hệ thống nhúng kéo theo những yêu cầu phát triển của hoạt động kiểm thử phần mềm
nhúng.
Thông thƣờng, một cách rất phổ biến để kiểm thử phần mềm cho hệ thống
nhúng nói chung đó là chạy phần mềm trên chƣơng trình giả lập phần cứng, chƣơng
trình giả lập ở đây có thể là một vi điều khiển ảo cũng có thể là một chƣơng trình mô
phỏng hình dung cả một hệ thống mạch bao gồm vi điều khiển và các thiết bị khác.
Tuy nhiên hiện nay, hệ thống nhúng ở Việt Nam mới phát triển khá khiêm tốn
so với thế giới, và lĩnh vực kiểm thử nhúng lại càng khiêm tốn hơn. Có rất ít các bài
báo, các tài liệu nói về hoạt động kiểm thử nhúng cũng nhƣ không có nhiều công cụ hỗ
trợ cho việc kiểm thử này. Do đó, việc nghiên cứu và tìm hiểu các phƣơng pháp, các
kỹ thuật kiểm thử cũng nhƣ công cụ cho phần mềm nhúng là một vấn đề cần thiết hiện
nay, nó sẽ góp phần thúc đẩy sự phát triển của lĩnh vực hệ thống nhúng, một lĩnh vực
giàu tiềm năng nhƣng mới chỉ bƣớc đầu phát triển ở việt nam.
Trong luận văn này, tôi chọn nghiên cứu kiểm thử dựa trên mô hình với
NModel trong việc phát triển phần mềm nhúng, cụ thể là kiểm thử cho bài toán về hệ
thống Client/Server – một thiết bị điều khiển từ xa có sử dụng cảm biến nhiệt độ.
1.2. Nội dung nghiên cứu
Mục tiêu của luận văn: Mục tiêu đặt ra là nghiên cứu phƣơng pháp kiểm thử

dựa trên mô hình để hỗ trợ cho việc phát triển hệ thống nhúng.
Nhiệm vụ của luận văn: Trong luận văn này, nhiệm vụ chính là nghiên cứu ứng
dụng cụ thể NModel sau đó áp dụng kiểm thử bài toán thiết bị điều khiển từ xa
Client/Server.
Luận văn tập trung nghiên cứu và khảo sát tổng quan về lý thuyết hệ thống
nhúng; lý thuyết phân tích và kiểm thử dựa trên mô hình và các kỹ thuật kiểm thử
phần mềm; luận văn cũng nghiên cứu về các loại chƣơng trình mô hình trong NModel
để kiểm thử bài toán về thiết bị điều khiển từ xa Client/Server . Từ những hiểu biết về
phân tích và kiểm thử phần mềm, luận văn đã áp dụng quy trình của các phƣơng pháp
kiểm thử ngoại tuyến và kiểm thử trực tuyến (on-the-fly) để kiểm thử bài toán.
Hệ thống Client/Server – thiết bị điều khiển từ xa là bài toán về hệ thống nhúng
đơn giản nhƣng đầy đủ, không sử dụng hệ điều hành nhúng. Các chƣơng trình đƣợc
viết bằng ngôn ngữ C# và kiểm thử đƣợc chạy mô phỏng bằng công cụ NModel.
11

1.3. Tầm quan trọng của kiểm thử dựa trên mô hình
Trong phát triển phần mềm, các kiểm thử viên thƣờng thực hiện công việc bằng
phƣơng pháp truyền thống nên đôi khi bị nhàm chán vì công việc lặp đi lặp lại, tốn
thời gian để thực hiện kiểm thử. Do đó, kiểm thử dựa trên mô hình sẽ khắc phục đƣợc
một số vấn đề nhƣ sau:
 Quá trình sinh ca kiểm thử là tự động nên sẽ rút ngắn thời gian làm phần mềm,
chất lƣợng phần mềm đƣợc cải thiện hơn, sinh ra nhiều ca kiểm thử và phát
hiện nhiều lỗi.
 Loại bỏ đƣợc sự nhàm chán và tính chủ quan khi làm việc nên giúp cho các
kiểm thử viên hài lòng với công việc của mình.
 Tự động tạo và kiểm tra để tránh các ca kiểm thử trùng nhau hoặc không hữu
hiệu.
 Khi có yêu cầu thay đổi hệ thống thì việc thay đổi các ca kiểm thử chỉ việc thay
đổi mô hình của hệ thống.
1.4. Cấu trúc luận văn

Các phần còn lại của luận văn có cấu trúc nhƣ sau:
Chƣơng 2 trình bày tổng quan về hệ thống nhúng và phần mềm nhúng.
Chƣơng 3 trình bày về lý thuyết phân tích và kiểm thử dựa trên mô hình, và hệ
thống với các mô hình hữu hạn.
Chƣơng 4 giới thiệu về cách cài đặt và cách sử dụng công cụ NModel, trình bày
về bài toán và kết quả thực nghiệm kiểm thử hệ thống Client/Server – thiết bị điều
khiển từ xa.
Cuối cùng là kết luận về quá trình nghiên cứu, đƣa ra các kết quả đạt đƣợc, và
hƣớng nghiên cứu tiếp theo.
12

CHƢƠNG 2. TỔNG QUAN VỀ HỆ THỐNG NHÚNG
2.1. Các khái niệm về hệ thống nhúng
2.1.1. Hệ thống nhúng
Ngày nay, xung quanh ta có rất nhiều thiết bị, đồ dùng liên quan đến hệ thống
nhúng nhƣ đồng hồ kỹ thuật số, ô tô, hoặc những sản phẩm lớn nhƣ đèn giao thông,
máy giặt, hệ thống kiểm soát các máy năng lƣợng hạt nhân. Vậy thực chất “hệ thống
nhúng là gì?”. Có rất nhiều khái niệm về hệ thống nhúng. Tuy nhiên, theo [1]: “Hệ
thống nhúng là một thuật ngữ để chỉ một hệ thống có khả năng tự trị đƣợc nhúng vào
trong một môi trƣờng hay một hệ thống mẹ. Đó là các hệ thống tích hợp cả phần cứng
và phần mềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự
động hóa điều khiển, quan trắc và truyền tin”.
Không giống nhƣ các máy tính đa chức năng, hệ thống nhúng đƣợc thiết kế để
thực hiện một chức năng chuyên biệt nào đó. Nó có đặc điểm là hoạt động ổn định và
có tính năng tự động hóa cao.
Sau đây là một số ví dụ điển hình về hệ thống nhúng:
 Các hệ thống dẫn đƣờng trong không lƣu, hệ thống định vị toàn cầu, vệ
tinh.
 Các thiết bị gia dụng: tủ lạnh, lò vi sóng, lò nƣớng.
 Các thiết bị kết nối mạng: router, hub, gateway.

 Các thiết bị văn phòng: máy photocopy, máy fax, máy in, máy scan.
 Các thiết bị y tế: máy thẩm thấu, máy điều hòa nhịp tim.
 Các máy trả lời tự động.
 Dây chuyền sản xuất tự động trong công nghiệp, robots.


Hình 2.1: Mẫu xe trong cuộc thi Micom Car Rally (chip Renesas H8)

13


Hình 2.2: Một số hệ thống nhúng thông dụng nhƣ robot, máy in và điện thoại

2.1.2. Hệ thời gian thực
Thời gian thực rất khó định nghĩa chính xác. Thông thƣờng, trong các bài toán
điều khiển hay gặp thuật ngữ “thời gian thực”. Vậy thời gian thực nên đƣợc hiểu nhƣ
thế nào cho đúng? Thời gian thực là yêu cầu khắt khe về sự ràng buộc thời gian, có
nghĩa là: Các yêu cầu của hệ thống phải đảm bảo thoả mãn các hành vi của hệ thống
đƣợc thực hiện đúng trong khung thời gian cho trƣớc hoàn toàn xác định. Khung thời
gian này đƣợc xác định bởi yêu cầu của hệ thống.
Về cơ bản, thời gian thực đƣợc phân ra thành hai loại là thời gian thực cứng
(hard real-time) và thời gian thực mềm (soft real-time). Theo [1], hai loại thời gian
thực đƣợc định nghĩa nhƣ sau:
 Thời gian thực cứng là khi hệ thống hoạt động với yêu cầu thỏa mãn sự ràng
buộc trong khung thời gian cứng tức là nếu vi phạm thì sẽ dẫn đến hoạt
động của toàn hệ thống bị sai hoặc phá hủy.
 Thời gian thực mềm là khi hệ thống hoạt động với yêu cầu thoản mãn ràng
buộc trong khung thời gian mềm, nếu vi phạm và sai lệch nằm trong khoảng
cho phép thì hệ thống vẫn có thể hoạt động đƣợc và chấp nhận đƣợc.
Ví dụ với hệ thời gian thực cứng: 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ễ thì tính mạng của ngƣời bệnh sẽ gặp nguy hiểm.
Ví dụ với hệ thời gian thực mềm: Cây rút tiền tự động ATM. Khi ta đƣa thẻ
ATM vào máy, có thể do nghẽn mạng mà việc rút tiền bị trễ vài giây thậm chí vài phút
thì ta vẫn có thể kiên nhẫn chờ đợi mà không gây thiệt hại gì cho ngƣời rút tiền.
Các lĩnh vực ứng dụng của hệ thống nhúng: Ngày nay, có rất nhiều các ứng
dụng của hệ thống nhúng đang đƣợc sử dụng và sẽ tiếp tục tăng nhanh trong tƣơng lai.
Một số lĩnh vực và sản phẩm thị trƣờng của các hệ thống nhúng có thể đƣợc nhóm nhƣ
sau:
 Các thiết bị điều khiển
 Lĩnh vực truyền thông
 Thiết bị y tế
14

 Hệ thống nhà thông minh
 Rô bốt
 Ô tô, tàu điện
2.2. Cấu trúc phần cứng hệ thống nhúng
2.2.1. Các thành phần cơ bản
2.2.1.1. Đơn vị xử lý trung tâm (CPU)


Hình 2.3:Cấu trúc CPU

CPU là viết tắt của chữ “Central Processing Unit”. Nó là đơn vị xử lý trung tâm
đóng vai trò nhƣ bộ não chịu trách nhiệm thực thi các phép tính và thực hiện các lệnh.
CPU là một mạch tích hợp phức tạp gồm hàng triệu transitor trên một bảng mạch nhỏ.
Bộ xử lý trung tâm bao gồm đơn vị logic toán học ALU (Arthimetic Logic Unit), bộ
giải mã (decoder), bộ tuần tự (sequencer) và các thanh ghi.
Trong tài liệu [1], cơ chế làm việc của CPU đƣợc giải thích nhƣ sau:

Bộ giải mã chuyển đổi các lệnh lƣu trữ ở trong bộ mã chƣơng trình thành
các mã mà ALU có thể hiểu đƣợc và thực thi. Bộ tuần tự có nhiệm vụ quản
lý dòng dữ liệu trao đổi qua bus dữ liệu của vi xử lý. Các thanh ghi đƣợc sử
dụng để CPU lƣu trữ tạm thời các dữ liệu chính cho việc thực thi các lệnh
và chúng có thể thay đổi nội dung trong quá trình hoạt động của ALU. Hầu
hết các thanh ghi của vi xử lý đều là các bộ nhớ đƣợc tham chiếu và hội
nhập với khu vực bộ nhớ và có thể đƣợc sử dụng nhƣ bất kỳ khu vực nhớ
khác.
2.2.1.2. Bộ nhớ
Bộ nhớ là một yêu cầu tài nguyên quan trọng không chỉ trong hệ thống nhúng
mà trong mọi hệ thống khác. Ngay cả hệ thống con ngƣời cũng cần bộ nhớ. Về kiến
15

trúc bộ nhớ đƣợc chia làm hai loại cơ bản là kiến trúc bộ nhớ Von Neumann và
Havard.
Kiến trúc bộ nhớ von Neumann và Havard đƣợc biểu diễn nhƣ trong hình 2.4.

Hình 2.4: Kiến trúc bộ nhớ Von Neumann và Havard

Kiến trúc Von Neumann không phân biệt vùng chứa dữ liệu và mã chƣơng
trình. Chúng đều đƣợc truy xuất trên cùng một đƣờng. Còn với kiến trúc Havard thì
phân biệt vùng lƣu mã chƣơng trình và dữ liệu. Mã chƣơng trình chỉ có thể lƣu và thực
hiện trong vùng chứa ROM và dữ liệu cũng chỉ đƣợc lƣu và trao đổi trong vùng RAM.
Ngày nay, trong các vi xử lý nhúng kiến trúc bộ nhớ Havard đƣợc sử dụng nhiều hơn
so với kiến trúc bộ nhớ von Neumann. Ví dụ Chip vi điều khiển nhúng hay sử dụng
cấu trúc Havard là 8031, PIC, Atmel AVR90S. Lý do kiến trúc Harvard đƣợc dùng
nhiều là nó có ƣu điểm nổi bật hơn von Neumann. Nó có hai kênh tách biệt để truy
nhập vào vùng bộ nhớ dữ liệu và mã chƣơng trình. Điều đó giúp cho mã chƣơng trình
và dữ liệu có thể đƣợc truy nhập đồng thời và làm tăng tốc độ luồng trao đổi với bộ xử
lý.

2.2.1.3. Thiết bị ngoại vi
Máy tính hay hệ vi xử lý trao đổi dữ liệu với môi trƣờng bên ngoài thông qua các
thiết bị ngoại vi. Các thiết bị ngoại vi bao gồm:
 Các thiết bị vào chuẩn nhƣ bàn phím, chuột
 Các thiết bị ra chuẩn nhƣ màn hình, máy in
 Các bộ nhớ ngoài chuẩn nhƣ ổ cứng, CD ROM
 Các hệ đo lƣờng, điều khiển.
Cấu trúc ghép nối giữa máy vi tính và thiết bị ngoại vi đƣợc thể hiện trong hình
2.5.
Bộ phối ghép nằm giữa máy vi tính và các thiết bị ngoài, đóng vai trò trung
chuyển dữ liệu giữa chúng. Khi truyền dữ liệu từ máy tính ra thiết bị ngoài thì nó đóng
16

vai trò nhận dữ liệu từ máy tính và là nguồn cấp dữ liệu cho thiết bị ngoài. Ngƣợc lại,
khi truyền dữ liệu từ thiết bị ngoài vào thì bộ phối ghép lại đóng vai trò nhận dữ liệu từ
thiết bị ngoài và là nguồn cấp dữ liệu cho máy tính. Bộ phối ghép làm nhiệm vụ phối
hợp trao đổi dữ liệu giữa máy tính và thiết bị ngoài về mức công suất của tín hiệu,
dạng tín hiệu, tốc độ và phƣơng thức trao đổi.


Hình 2.5: Cấu trúc ghép nối giữa máy tính và thiết bị ngoại vi

Phối hợp về mức và công suất tín hiệu: Máy tính thƣờng có mức tín hiệu là
(0V, 5V). Trong khi đó, các thiết bị ngoài hoặc ở mức cao (± 15V, ± 48V ) hoặc rất
thấp (˂ 1V). Do đó, bộ phối ghép phải biến đổi các mức tín hiệu trên cho phù hợp.
Công suất tín hiệu trên bus dữ liệu rất nhỏ (cỡ vài chục mA), trong khi thiết bị ngoài
lại cần công suất lớn hơn nhiều. Do đó, bộ phối ghép phải biến đổi công suất cho phù
hợp.
Phối hợp về dạng dữ liệu (tín hiệu): Bộ phối ghép phải đảm bảo tính tƣơng
thích về cơ chế trao đổi dữ liệu giữa máy tính và thiết bị ngoại vi.

Phối hợp về tốc độ trao đổi dữ liệu: Máy tính hoạt động với tốc độ cao còn
các thiết bị ngoại vi hoạt động với tốc độ chậm hơn. Do đó, bộ phối ghép phải có khả
năng cấp, nhận dữ liệu nhanh với máy tính còn với thiết bị ngoại vi thì ngƣợc lại.
Phối hợp về phƣơng thức trao đổi dữ liệu
Nếu việc trao đổi dữ liệu do máy tính yêu cầu thì quá trình diễn ra nhƣ sau:
Máy tính đƣa lệnh điều khiển để khởi động bộ phối ghép hoặc thiết bị ngoại vi. Máy
tính đọc tín hiệu trả lời, nếu có tín hiệu sẵn sàng mới trao đổi tin, nếu không thì thêm
17

một chu kỳ chờ và đọc lại trạng thái. Máy tính trao đổi tin khi đọc thấy trạng thái sẵn
sàng.
Nếu việc trao đổi tin do thiết bị ngoại vi yêu cầu thì việc trao đổi diễn ra khi:
Thiết bị ngoại vi gửi yêu cầu trao đổi tin tới bộ xử lý ngắt của khối ghép nối (KGN).
Nếu có nhiều thiết bị ngoại vi cùng gửi yêu cầu thì KGN xử lý theo mức ƣu tiên ngắt
định trƣớc rồi đƣa yêu cầu trao đổi tin cho máy tính. Máy tính nhận yêu cầu, chuẩn bị
trao đổi và gửi tín hiệu xác nhận sẵn sàng trao đổi. KGN nhận và truyền tín hiệu xác
nhận cho thiết bị ngoại vi. Thiết bị ngoại vi trao đổi tin với KGN còn khối ghép nối
trao đổi với máy tính (nếu là đƣa tin vào) hoặc máy tính trao đổi tin với KGN và KGN
trao đổi với thiết bị ngoại vi (nếu là đƣa tin ra).
2.2.1.4. Bus địa chỉ, bus dữ liệu và bus điều khiển
Bus địa chỉ: là các đƣờng dẫn tín hiệu logic một chiều, nó làm nhiệm vụ truyền
địa chỉ tham chiếu đến các khu vực nhớ và chỉ ra nơi mà dữ liệu đƣợc lƣu trữ trong
không gian bộ nhớ. Trong quá trình hoạt động, CPU sẽ điều khiển bus địa chỉ để
truyền dữ liệu giữa CPU và bộ nhớ. Dữ liệu đƣợc lƣu trữ thƣờng là 8 bít, 16 bít, hoặc
32 bít tùy vào cấu trúc từng loại vi xử lý và vi điều khiển. Đối với vi điều khiển thì địa
chỉ dữ liệu thƣờng đƣợc đánh theo khối 8 bít. CPU có thể truy nhập trực tiếp vào các
khu vực bộ nhớ bằng địa chỉ tham chiếu. Nếu vi xử lý có N bít địa chỉ thì nó có thể
đánh đƣợc 2
N
địa chỉ khu vực mà CPU có thể tham chiếu tới. Các khu vực đƣợc đánh

địa chỉ theo qui ƣớc bắt đầu từ 0 và tăng dần đến 2
N
-1. Độ rộng của bus dữ liệu thƣờng
là 16, 20, 24 hoặc 32 bít.
Bus dữ liệu: là các kênh truyền tải thông tin theo hai chiều giữa CPU và bộ nhớ
hay các thiết bị ngoại vi vào ra. CPU điều khiển bus dữ liệu để đọc và viết dữ liệu hoặc
mã lệnh thực thi. Độ rộng của bus dữ liệu xác định đƣợc lƣợng dữ liệu có thể truyền và
trao đổi trên bus. Tốc độ truyền dữ liệu đƣợc tính theo đơn vị là [byte/s].
Bus điều khiển: Theo tài liệu [1], bus điều khiển đƣợc giải thích nhƣ sau:
Bus điều khiển phục vụ truyền tải các thông tin dữ liệu để điều khiển hoạt
động của hệ thống. Thông thƣờng các dữ liệu điều khiển bao gồm các tín
hiệu chu kỳ để đồng bộ các nhịp chuyển động và hoạt động của hệ thống.
Bus điều khiển thƣờng đƣợc điều khiển bởi CPU để đồng bộ hóa nhịp hoạt
động và dữ liệu trao đổi trên các bus. Trong trƣờng hợp vi xử lý sử dụng
dồn kênh bus dữ liệu và bus địa chỉ tức là một phần hoặc toàn bộ bus dữ
liệu sẽ đƣợc sử dụng chung chia sẻ với bus địa chỉ thì cần một tín hiệu điều
khiển để phân nhịp truy nhập cho phép chốt lƣu trữ thông tin địa chỉ mỗi
khi bắt đầu một chu kỳ truyền.
Ví dụ về bus điều khiển: Ví dụ về hoạt động của hệ thống bus địa chỉ và dữ liệu
dồn kênh đƣợc chỉ ra trong hình 2.6. Đây là hoạt động điển hình trong họ vi điều khiển
8051.
18


Hình 2.6: Chu kỳ hoạt động bus dồn kênh
2.2.2. Một số nền phần cứng nhúng thông dụng
Ngày nay, các chủng loại chip khả trình phát triển nhanh chóng với mật độ tích
hợp cao đang có tác động đáng kể đến sự thay đổi trong việc thiết kế các nền phần
cứng thiết bị xử lý và điều khiển số. Mỗi chủng loại có những đặc điểm và phạm vi
ứng dụng và không ngừng phát triển để đáp ứng cho các yêu cầu công nghệ một cách

tốt nhất. Có rất nhiều loại chíp khả trình có thể sử dụng cho các bài toán thiết kế hệ
thống nhúng nhƣ Chip DSP (Digital Signal Processing), họ vi xử lý/vi điều khiển
nhúng (Microprocessor/Microcontroller) và các Chip khả trình trƣờng (FPD-Field
Programmable Device).
2.2.2.1. Vi điều khiển nhúng
Ngày nay, vi điều khiển nhúng là một chủng loại rất điển hình và đƣợc dùng
phổ biến. Chúng đƣợc ra đời và sử dụng theo sự phát triển của các chip xử lý ứng dụng
cho máy tính. Các nhà chế tạo cung cấp các họ vi xử lý điều khiển có rất nhiều nhƣ
Intel, Atmel, Motorola, Infineon. Chúng cũng có cấu trúc tƣơng tự nhƣ các chip xử lý
phát triển cho PC nhƣng đơn giản hơn nhiều về công năng và tài nguyên. Chủ yếu là
các chip có độ rộng bus dữ liệu là 8 bít, 16 và 32 bít. Vi điều khiển nhúng đƣợc tích
hợp thêm các ngoại vi, các ngoại vi thƣờng là các khối chức năng ngoại vi thông dụng
nhƣ bộ định thời gian, bộ đếm, bộ chuyển đổi A/D, giao diện song song, nối tiếp. Tùy
theo mục đích ứng dụng mà mức độ tích hợp ngoại vi cũng khác nhau. Nếu thực tế các
ứng dụng yêu cầu độ tích hợp cao thì sẽ sử dụng giải pháp tích hợp trên chip, nếu
không thì các chip đều cung cấp giải pháp mở rộng ngoại vi đáp ứng cho số lƣợng ứng
dụng rộng và mềm dẻo.
Ví dụ về kiến trúc nguyên lý của vi điều khiển (VĐK) với cấu trúc Havard:
19


Hình 2.7: Kiến trúc nguyên lý của VĐK với cấu trúc Havard

2.2.2.2. Chip DSP
Theo tài liệu [1], chip DSP đƣợc giải thích nhƣ sau:
DSP vẫn đƣợc biết tới nhƣ một loại vi điều khiển đặc biệt với khả năng xử
lý nhanh để phục vụ các bài toán yêu cầu khối lƣợng và tốc độ xử lý tính
toán lớn. Với ƣu điểm nổi bật về độ rộng băng thông của bus và thanh ghi
tích lũy, cho phép ALU xử lý song song với tốc độ đọc và xử lý lệnh nhanh
hơn các loại vi điều khiển thông thƣờng. Chip DSP cho phép thực hiện

nhiều lệnh trong một nhịp nhờ vào kiến trúc bộ nhớ Havard.
Khi phải sử dụng DSP thì định dạng biểu diễn toán học sẽ là một yếu tố quan
trọng để phân loại và đƣợc quan tâm. Hiện nay, chúng đƣợc phân loại theo hai kiểu là
dấu phảy động và dấu phảy tĩnh. Đây cũng là yếu tố quan trọng đối với ngƣời thiết kế
để lựa chọn DSP phù hơp với ứng dụng của mình. Các DSP dấu phảy tĩnh thƣờng là
16 bít hoặc 24 bít còn các DSP dấu phảy động thƣờng là 32 bít.
2.3. Kiến trúc phần mềm nhúng
2.3.1. Kiến trúc Round-Robin (RR)
Kiến trúc phần mềm đơn giản nhất có thể đƣợc gọi là “round robin”. Kiến trúc
Round robin không có ngắt, tổ chức phần mềm bao gồm một vòng lặp chính. Trong
đó, bộ vi xử lý rất đơn giản, nó làm nhiệm vụ thăm dò từng thiết bị đính kèm theo lần
lƣợt và cung cấp dịch vụ nếu có yêu cầu. Sau khi tất cả các thiết bị đã đƣợc phục vụ thì
vòng lặp bắt đầu lại từ đầu. Kiến trúc phần mềm Round robin đƣợc minh họa bằng đồ
thị và đoạn giả mã nhƣ hình 2.8

20


Hình 2.8: Minh họa kiến trúc RR bằng giả mã và đồ thị

Các ứng dụng có thể áp dụng kiến trúc round robin nhƣ máy bán hàng tự động,
máy ATM, hoặc thiết bị gia dụng nhƣ lò vi sóng. Round robin có ƣu điểm là phƣơng
pháp thăm dò rất đơn giản, đủ tốt để sử dụng, chi phí phát triển thấp, chu kỳ phát triển
ngắn. Tuy nhiên, kiến trúc này cũng có nhƣợc điểm là không thể xử lý những vấn đề
phức tạp, rất lãng phí thời gian để kiểm tra các thiết bị kể cả khi thiết bị đó không cần
phục vụ hoặc trong trƣờng hợp có quá nhiều thiết bị cần phục vụ thì phƣơng án thăm
dò tỏ ra không hiệu quả, gây chậm trễ cho các thiết bị đó.
2.3.2. Kiến trúc Round-Robin với ngắt (RRI)
Kiến trúc Round-Robin với ngắt (Round-Robin with Interrupts - RRI) là kiến
trúc hỏi vòng có ngắt. Các tác vụ cấp bách đƣợc xử lý trong một dịch vụ thƣờng xuyên

bị gián đoạn, có một bộ cờ để xử lý theo dõi trong vòng lặp chính. Nếu không có gì
cấp bách xảy ra thì sau đó bộ vi xử lý tiếp tục hoạt động luân chuyển vòng. Quản lý
các tác vụ quanh vòng lặp. Kiến trúc RRI có thể đƣợc minh họa bằng giả mã nhƣ hình
2.9.
Lợi thế rõ ràng của RRI là thời gian đáp ứng với các tác vụ ƣu tiên cao đƣợc cải
thiện. Tuy ISR luôn luôn có ƣu tiên hơn vòng lặp chính (tức vòng lặp chính sẽ luôn
luôn dừng lại bất cứ điều gì nó đang làm để phục vụ ngắt), nhƣng nó vẫn còn khá đơn
giản. Thời gian đáp ứng trong trƣờng hợp xấu nhất cho một tác vụ ƣu tiên thấp là tổng
thời gian thực hiện đối với tất cả các mã lệnh trong vòng lặp chính cộng với tất cả các
thủ tục gián đoạn dịch vụ. Hơn nữa, với sự ra đời của ngắt thì vấn đề chia sẻ dữ liệu có
thể xảy ra.

21


Hình 2.9: Minh họa kiến trúc RRI bằng giả mã

2.3.3. Kiến trúc lập lịch dòng chức năng (FQS)
Kiến trúc lập lịch dòng chức năng (Function-Queue Scheduling - FQS) là kiến
trúc thô sơ của kiến trúc hệ điều hành mà nó đang đƣợc sử dụng cho máy tính đa năng.
Tất cả các yêu cầu đƣợc đặt vào hàng đợi và mỗi một yêu cầu có một mức độ ƣu tiên
nhất định. Vi xử lý sẽ tùy theo cơ chế lập lịch để phục vụ những yêu cầu nào trƣớc.
FQS có rất nhiều cơ chế lập lịch ví dụ nhƣ lập lịch ƣu tiên thứ tự trƣớc sau (đến trƣớc
phục vụ trƣớc), lập lịch ƣu tiên theo độ ƣu tiên (độ ƣu tiên cao hơn thì đƣợc phục vụ
trƣớc), lập lịch ƣu tiên những yêu cầu đơn giản trƣớc, lập lịch giả song song (mỗi yêu
cầu đƣợc phục vụ một thời gian ngắn rồi quay lại phục vụ tiếp sau khi phục vụ thiết bị
khác).
FQS có ƣu điểm là tất cả các yêu cầu đều đƣợc phục vụ, không có một yêu cầu
nào đƣợc bỏ qua. Tuy nhiên, FQS không đánh giá đƣợc yêu cầu nào phải thực hiện
bao nhiêu thời gian, tốn bao nhiêu tài nguyên.

2.3.4. Kiến trúc hệ điều hành thời gian thực (RTOS)
Kiến trúc hệ điều hành thời gian thực (Real-Time Operating Systems – RTOS)
có ba đặc điểm khác biệt so với các kiến trúc khác đó là: (1) Quá trình điều khiển giữa
các chu trình ngắt và mã nguồn thực thi tác vụ đƣợc quản lý bởi RTOS (tức là không
cần dùng biến chia sẻ). (2) RTOS quyết định lập lịch các tác vụ thay vì dùng một vòng
lặp chính để quyết định xem tác vụ thực thi tiếp theo là gì hoặc ngắt tiếp theo là gì. (3)
RTOS có thể tạm dừng một tác vụ đang thực thi để thực thi tác vụ khác.
22

RTOS là kiến trúc tốt hơn các kiến trúc khác vì nó có thể đáp ứng các yêu cầu
ràng buộc về thời gian (ràng buộc thời gian cứng, ràng buộc thời gian mềm), chịu lỗi
cao và cho phép xử lý đa nhiệm. Do đó, RTOS có các ƣu điểm sau: Thay đổi bất kỳ
tác vụ nào trong Round robin hoặc lập lịch theo hàng đợi. Thay đổi tới tác vụ có độ ƣu
tiên thấp hơn trong RTOS không ảnh hƣởng đến thời gian đáp ứng của các tác vụ có
độ ƣu tiên cao hơn. RTOS đƣợc sử dụng rộng rãi và là giải pháp thật sự cần thiết cho
các hệ thống yêu cầu ràng buộc về thời gian đáp ứng. Tuy nhiên, RTOS vẫn có nhƣợc
điểm là cần thêm một số thời gian để xử lý các thông tin về tác vụ trƣớc và sau khi đƣa
nó vào xử lý trong CPU nên hiệu suất sử dụng bị ảnh hƣởng. Ngoài ra, chi phí cao khi
mua các sản phẩm thƣơng mại.
2.4. Hệ điều hành thời gian thực
2.4.1. Khái niệm hệ điều hành thời gian thực
Hệ điều hành thời gian thực đƣợc định nghĩa theo [1]: “Hệ điều hành thời gian
thực – RealTime Operating Systems (RTOS) là phần mềm điều khiển chuyên dụng
thƣờng đƣợc dùng trong những ứng dụng điện toán nhúng có tài nguyên bộ nhớ hạn
chế và yêu cầu ngặt nghèo về thời gian đáp ứng tức thời, tính sẵn sàng cao và khả năng
tự kiểm soát một cách chính xác.”
RTOS có khả năng tách biệt với ứng dụng, vì thế nếu có một chƣơng trình bị
“chết” hay hoạt động không hợp lệ thì RTOS có thể cô lập chƣơng trình này một cách
nhanh chóng, kích hoạt cơ chế phục hồi và bảo vệ các chƣơng trình khác hay chính
bản thân hệ điều hành khỏi các hậu quả của các lệnh sai. Cơ chế bảo vệ cũng đƣợc áp

dụng để tránh tình trạng tràn bộ nhớ do các chƣơng trình gây ra.
Hệ điều hành thời gian thực là hệ điều hành hỗ trợ khả năng xây dựng các hệ
thống thời gian thực.

Hình 2.10: So sánh kiến trúc RTOS và OS chuẩn

Hệ điều hành với phần lõi là hạt nhân phải đảm bảo các tác vụ chính sau:
 Xử lý ngắt: Lƣu trữ ngữ cảnh chƣơng trình tại thời điểm xuất hiện ngắt. Nhận
dạng và lựa chọn đúng bộ xử lý và phục vụ dịch vụ ngắt.
23

 Điều khiển quá trình hoạt động: Tạo và kết thúc quá trình/tác vụ. Lập lịch và
điều phối hoạt động hệ thống. Định thời.
 Điều khiển ngoại vi: Xử lý ngắt. Khởi tạo giao tiếp vào ra.


Hình 2.11: Cấu trúc hệ điều hành thời gian thực

2.4.2. Tác vụ (Task) và trạng thái tác vụ
Tác vụ là một luồng thực thi độc lập mà có thể cạnh tranh chiếm quyền thực thi.
Mỗi một ứng dụng đƣợc chia làm nhiều tác vụ để tối ƣu khả năng đáp ứng vào ra trong
luật thời gian. Một tác vụ đƣợc định nghĩa là một tập hợp các tham số và cấu trúc dữ
liệu. Thành phần của một tác vụ bao gồm: tên tác vụ, ID, độ ƣu tiên, khối điều khiển
tác vụ, ngăn xếp và các thủ tục thực thi tác vụ. Các thành phần của một tác vụ đƣợc thể
hiện trong hình 2.12.
Các trạng thái của một tác vụ: Tại bất cứ thời điểm nào, mỗi tác vụ tồn tại một
trong các trạng thái nhƣ sẵn sàng (Ready), đang thực thi (Running) hoặc khóa
(Blocked). Khi hệ thống nhúng thời gian thực chạy, mỗi tác vụ thay đổi từ trạng thái
này đến trạng thái khác theo quy luật logic của một máy trạng thái hữu hạn FSM
(Finite state machine). Các chuyển đổi trạng thái đƣợc thể hiện trong hình 2.13.

Ready: Tất cả dữ liệu cần thiết có sẵn và tác vụ đƣợc chuẩn bị chạy khi bộ vi xử
lý có sẵn. Nhiều tác vụ có thể sẵn sàng bất cứ lúc nào, và sẽ chạy theo thứ tự ƣu tiên.
Running: Mã tác vụ đang đƣợc thực thi bởi bộ vi xử lý. Tại bất kỳ thời điểm
nào cũng chỉ có duy nhất một tác vụ có thể đƣợc chạy.
Blocked: Một tác vụ có thể bị khóa và chờ đợi dữ liệu cho một sự kiện xảy ra.
Một tác vụ nếu không đƣợc ƣu tiên thì sẽ khóa sau khi chạy để hoàn thành. Tại một
thời điểm, nhiều nhiệm vụ có thể bị khóa.

24


Hình 2.12: Cấu trúc của một Task cơ bản



Hình 2.13: Các trạng thái của task
2.4.3. Queue và các trạng thái của queue
Hàng đợi Queue là một máy giao tiếp dữ liệu giữa các Task. Một message
Queue là một đối tƣợng tƣơng tự nhƣ Buffer (bộ nhớ đệm) thông qua Task hoặc ISR
để gửi và nhận “thông điệp” (message) để giao tiếp và đồng bộ dữ liệu. Nó giữ thông
điệp tạm thời từ bên gửi (sender) cho đến khi bên nhận đƣợc định trƣớc (intended
receiver) sẵn sàng đọc dữ liệu.
25

Khi một thông điệp Queue đƣợc tạo ra lần đầu, nó đƣợc gán vào một khối quản
lý Queue, gồm các thông tin tên thông điệp, ID, bộ nhớ đệm, chiều dài Queue, độ dài
tối đa mỗi thông điệp, một hay nhiều danh dách các task đang chờ.


Hình 2.14: Hàng đợi Queue

Các trạng thái của Queue đƣợc thể hiện rõ trong hình 2.15: Mỗi Queue có thể
có một trong các trạng thái nhƣ rỗng (Empty), không rỗng (Not Empty) hoặc đầy
(Full).

Hình 2.15: Trạng thái của Queue