Phân tích, thiết kế phần mềm nhúng

Tuy nhiên muốn xây dựng Hệ thống nhúng – Thời gian thực tốt, đáp ứng được yêu cầu đòi hỏi người thiết kế và phát triển phải có sự hiểu biết sâu về hệ thống, thiết bị phần cứng, những vấn

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

TRẦN MINH TUẤN

PHÂN TÍCH, THIẾT KẾ PHẦN MỀM NHÚNG

LUẬN VĂN THẠC SỸ

HÀ NỘI, 2008

MỤC LỤC

DANH MỤC HÌNH VẼ BẢNG BIỂU TRONG LUẬN VĂN 3

BẢNG THUẬT NGỮ VÀ KÝ HIỆU SỬ DỤNG 5

LỜI GIỚI THIỆU 6

CHƯƠNG 1: TỔNG QUAN VỀ THIẾT KẾ 8

HỆ THỐNG NHÚNG 8

1.1 Hệ nhúng và các khái niệm 8

1.1.1 Hệ thống nhúng 8

1.1.2 Hệ thống nhúng thời gian thực 8

1.2 Giới thiệu chung về thiết kế hệ thống nhúng 10

1.2.1 Xác định yêu cầu sản phẩm 11

1.2.2 Lựa chọn bộ vi xử lý 11

1.2.2 Phân bổ giữa phần cứng và phần mềm 12

1.2.3 Thực hiện và lặp lại 14

1.2.4 Thiết kế chi tiết phần cứng và phần mềm 14

1.2.5 Tích hợp phần cứng phần mềm 15

1.2.6 Kiểm thử 16

1.2.7 Bảo trì và cập nhật 16

CHƯƠNG 2: THIẾT KẾ PHẦN MỀM NHÚNG 17

2.1 Phần mềm nhúng 17

2.1.1 Sự khác biệt giữa phần mềm nhúng và phần mềm thông thường trên PC 18

2.1.2 Nguyên tắc thiết kế chung 19

2.1.3 Thiết kế phần mềm nhúng với RTOS 20

2.2 Kiến trúc phần mềm nhúng 24

2.2.1 Round robin 24

2.2.2 Round robin với ngắt 25

2.2.3 Kiến trúc Function – Queue - Scheduling 26

2.2.4 Kiến trúc Hệ điều hành thời gian thực (RTOS) 27

2.3 Các phương pháp đặc tả và thiết kế phần mềm nhúng 28

2.3.1 Phương pháp đặc tả hình thức (formal method) 28

2.3.2 Phương pháp đặc tả bán hình thức (semi-formal method) 30

2.4 Công cụ phát triển phần mềm nhúng 35

2.5 Case study về thiết kế phần mềm nhúng 38

2.5.1 Phân tích yêu cầu 38

2.5.2 Thiết kế 44

2.5.3 Phân chia tác vụ 48

2.5.4 Kiến trúc phần cứng của hệ thống 48

CHƯƠNG 3: HỆ ĐIỀU HÀNH THỜI GIAN THỰC 49

3.1 Tính đa nhiệm 49

3.1.1 Lập lịch ưu tiên (Preemptive Scheduling) 51

3.1.2 Kích hoạt và bỏ kích hoạt tác vụ (Activation and Deactivation of Tasks) 51

3.1.3 Lập lịch hướng sự kiện (Event-Driven Scheduling) 51

3.2 Theo dõi các tác vụ 52

3.3 Truyền thông giữa các tác vụ 52

3.4 Quản lý bộ nhớ 54

3.5 Quản lý tài nguyên 54

3.6 RTOS và ngắt 55

3.7 Liên lạc trong RTOS thông dụng 56

3.8 Khả năng sử dụng RTOS 56

3.9 Ưu nhược điểm của hệ điều hành thời gian thực 57

3.10 Hệ điều hành thời gian thực µC/OS 58

CHƯƠNG 4: CÁC CÁCH TIẾP CẬN VỚI BÀI TOÁN NHẬN DẠNG CHỮ NÔM 63

4.1 Nhận dạng chữ Nôm bằng mạng nơ-ron 63

4.1.1 Áp dụng mạng nơ-ron trong nhận dạng chữ Nôm 63

4.1.2 Thực nghiê ̣m 64

4.2 Ứng dụng Tesseract để nhận dạng chữ Nôm 66

4.2.1 Tóm tắt về Tesseract 66

4.2.2 Áp dụng với chữ Nôm 68

4.3 So sánh và thảo luận 69

CHƯƠNG 5: ỨNG DỤNG VÀ PHÁT TRIỂN PHẦN MỀM NHẬN DẠNG CHỮ NÔM CHO THIẾT BỊ NHÚNG 70

5.1 Phân tích ứng dụng trên môi trường nhúng 70

5.2 Thực nghiệm chương trình nhận dạng dựa trên Tesseract với môi trường µC/OS 76

KẾT LUẬN 77

TÀI LIỆU THAM KHẢO 78

PHỤ LỤC 80

DANH MỤC HÌNH VẼ BẢNG BIỂU TRONG LUẬN VĂN

DANH MỤC HÌNH VẼ

Hình 1.1 Quan hệ giữa hệ nhúng và thời gian thực 9

Hình 1.2 Quy trình thiết kế co-design 10

Hình 1.3 Thiết kế máy in laser 13

Hình 1.4 Một ví dụ về vấn đề big endian/little endian 15

Hình 1.5 Mối liên hệ về chi phí sửa lỗi cho mỗi giai đoạn 16

Hình 2.1 Phần mềm nhúng trong hệ thống 17

Hình 2.2 Thành phần phần mềm nhúng 18

Hình 2.3 Cấu trúc đề nghị của một tác vụ 23

Hình 2.4 Kiến trúc Round robin 25

Hình 2.5 Kiến trúc Round-robin with interrupts 26

Hình 2.6 Kiến trúc Function-Queue-Scheduling 27

Hình 2.7 Kiến trúc Hệ điều hành thời gian thực 28

Hình 2.8 Biểu đồ luồng dữ liệu hệ thống đồng hồ báo thức 31

Hình 2.9 Biểu đồ trạng thái 32

Hình 2.10 Đặc tả theo giả mã 33

Hình 2.11 Qui trình phát triển blueprint 34

Hình 2.12 Cấu trúc của SPT profile 35

Hình 2.13 Quá trình phát triển và biên dịch phần mềm nhúng 38

Hình 2.14 Hình dáng của thiết bị 39

Hình 2.15 Biểu đồ ngữ cảnh của hệ thống 40

Hình 2.16 Biểu đồ Use Case 41

Hình 2.17 Biểu đồ tuần tự cho ca sử dụng Playback a message 42

Hình 2.18 Alarm while playback a message 43

Hình 2.19 Ngữ cảnh vào và ra khỏi chế độ stand-by 44

Hình 2.20 Biểu đồ lớp của hệ thống 46

Hình 2.21 Các hệ thống con trong Digital Sound Recorder 46

Hình 2.22 Biểu đồ lớp hệ thống Audio 47

Hình 2.23 Biểu đồ tuần tự nghe một thông điệp 47

Hình 2.24 Thiết kế phần cứng của hệ thống 48

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

Hình 3.2 Hoạt động chia nhỏ thời gian và tuần tự 50

Hình 3.3 Một ví dụ về semaphore 52

Hình 3.4 Truyền thông của RTOS 53

Hình 3.5 Các khối bộ nhớ được gán trong RTOS 55

Hình 3.6 Cấu trúc một tác vụ 59

Hình 3.8 Hàm dịch vụ ngắt trong µC/OS 61

Hình 4.2 Cấu trúc mô-dun của chương trình 65

Hình 4.3 Lưu đồ huấn luyê ̣n ma ̣ng 66

Hình 4.4 Kiến trúc tổng quát của Tesseract 67

Hình 5.1 Quá trình học chữ Nôm 70

Hình 5.2 Quá trình nhận dạng 70

Hình 5.3 Biểu đồ ngữ cảnh của hệ thống 71

Hình 5.4 Biểu đồ Use case của hệ thống 72

Hình 5.5 Biểu đồ tuần tự của hệ thống nhận dạng chữ Nôm 73

Hình 5.6 Biểu đồ lớp của hệ thống nhận dạng chữ Nôm 74

Hình 5.7 Trạng thái của tác vụ khi thực thi trong hệ thống 75

Hình 5.8 Biểu đồ chuyển đổi giữa các tác vụ 75

DANH MỤC BẢNG BIỂU Bảng 2.1 Bảng các sự kiện tác động lên hệ thống 41

Bảng 2.2 Các đối tượng của hệ thống 45

Bảng 4.1 Mô ̣t kết quả nhận dạng 65

Bảng 4.2 Kết quả nhâ ̣n da ̣ng chữ Nôm với Tesseract 68

Bảng 5.1 Các sự kiện tác động vào chương trình 72

Bảng 5.2 Kết quả thực hiện tác vụ nhận dạng 76

BẢNG THUẬT NGỮ VÀ KÝ HIỆU SỬ DỤNG

network)

thống (Communicating Sequential Process)

JTAG (Joint Test Action Group)

(K-Nearest Neighbor)

Object Oriented Modelling)

UML

Description Language)

Language)

LỜI GIỚI THIỆU

Thời gian gần đây, các Hệ thống nhúng – Thời gian thực được quan tâm nhiều hơn

ở Việt Nam, và trên thế giới thì các hệ thống này đã và đang được phát triển mạnh mẽ

và là xu hướng thịnh hành ở các nước Công nghiệp vì những lợi ích to lớn, thiết thực

mà nó mang lại Theo các chuyên gia nhận định, sự phát triển của máy tính (PC) đã

chuyển sang giai đoạn thứ 3 - giai đoạn của môi trường thông minh mà hệ thống

nhúng là cốt lõi (còn gọi là giai đoạn hậu PC - Internet) Phát triển hệ nhúng và phần

mềm nhúng đang là quốc sách của nhiều quốc gia

Tuy nhiên muốn xây dựng Hệ thống nhúng – Thời gian thực tốt, đáp ứng được yêu

cầu đòi hỏi người thiết kế và phát triển phải có sự hiểu biết sâu về hệ thống, thiết bị

phần cứng, những vấn đề về hệ điều hành thời gian thực (RTOS), lập trình nhúng, các

giải thuật trong lập lịch (Scheduling), cấp phát (Allocation), bố trí hệ thống (layout),

phân chia phần cứng – phần mềm (HW-SW partioning)…Việc thiết kế và xây dựng hệ

thống nhúng cần phát triển theo hướng co-design [7] Nghĩa là phải phát triển phần

cứng và phần mềm đồng thời nhằm xác định giải pháp tối ưu nhất cho hệ thống nhúng

Mục đích của luận văn là đi sâu nghiên cứu các phương pháp, cách thức nhằm phân

tích, thiết kế tốt phần mềm nhúng trong hệ thống nhúng - thời gian thực

Bên cạnh mục đích trên, còn có một mục tiêu rất quan trọng và thiết thực đó là

nghiên cứu các cách tiếp cận nhận dạng chữ Nôm để xây dựng ứng dụng cho bài toán

này trên thiết bị nhúng Về lĩnh vực nhận dạng, nhận dạng chữ là bài toán rất hữu ích

trong việc số hóa dữ liệu ở dạng văn bản giấy hoặc ảnh Với chữ Latin bài toán đã

được nghiên cứu và phát triển từ lâu và hiện có nhiều phần mềm nhận dạng ký tự Latin

với độ chính xác cao Gần đây một số ngôn ngữ tượng hình như chữ Trung Quốc hay

chữ Nhật Bản cũng đã được giải quyết bằng nhiều phương pháp nhận dạng khác nhau

như: láng giềng gần nhất [9], mạng nơ-ron [29]

Ở Việt Nam, vấn đề nhận dạng chữ Quốc ngữ cũng đang được nhiều tổ chức thực

hiện, ví dụ VnDOCR [5] cho phép quét, đọc ảnh văn bản với nhiều định dạng khác

nhau và kết quả nhận dạng là văn bản có kiểu phông tùy chọn Tuy nhiên với bài toán

nhận dạng chữ Nôm, bài toán nhận dạng rất có ý nghĩa trong việc khôi phục và gìn giữ

di sản văn hóa dân tộc, hiện vẫn chưa có nhiều nghiên cứu với kết quả khả quan Một

số tổ chức đã nghiên cứu và xây dựng một số phần mềm liên quan đến số hóa chữ

Nôm như: bộ phông chữ Nôm của Viện Hán Nôm, phần mềm Từ điển Hán Nôm trên

PDA của Trung tâm công nghệ thông tin Thừa Thiên Huế [5], phần mềm đánh văn bản

chữ Hán Nôm của tác giả Trần Uyên Thi và Alexandre Lê, phần mềm từ điển Trực

tuyến Việt-Hán-Nôm biên soạn dựa trên cuốn Tự điển Hán -Việt của Thiều Chửu do

nhóm tác giả Phan Anh Dũng và Nguyễn Thế thực hiện [4] Đây là những nền tảng cần

thiết khích lệ tôi nghiên cứu bài toán nhận dạng chữ Nôm để ứng dụng vào các nguồn

văn bản đang tồn tại rất nhiều trong các thư viện, công trình văn hoá, và trong đời sống

hàng ngày cũng như xây dựng những tiện ích nhận dạng chữ Nôm trên thiết bị nhúng

để đáp ứng nhu cầu của nhân dân

Luận văn được chia thành 5 chương và phụ lục Trong đó:

những hệ thống này

nó

những kết quả thực nghiệm của các phương pháp

Tesseract cho thiết bị nhúng và thực nghiệm trên hệ điều hành thời gian thực

µC/OS

CHƯƠNG 1: TỔNG QUAN VỀ THIẾT KẾ

HỆ THỐNG NHÚNG

1.1 Hệ nhúng và các khái niệm

1.1.1 Hệ thống nhúng

Trong thế giới thực của chúng ta bất kỳ một thiết bị hay hệ thống điện/điện tử

có khả năng xử lý thông tin và điều khiển đều có thể tiềm ẩn trong đó một thiết bị hay

hệ nhúng, ví dụ như các thiết bị truyền thông, thiết bị đo lường điều khiển, các thiết bị

phục vụ sinh hoạt hàng ngày như lò vi sóng, máy giặt, camera…Rất dễ dàng để có thể

kể ra hàng loạt các thiết bị hay hệ thống như vậy đang tồn tại quanh ta, chúng là hệ

nhúng Vậy hệ nhúng thực chất là gì và nên hiểu thế nào về hệ nhúng? Hiện nay cũng

chưa có một định nghĩa nào thực sự thoả đáng để được chuẩn hoá và thừa nhận rộng

rãi cho hệ nhúng mà vẫn chỉ là những khái niệm diễn tả về chúng thông qua những đặc

thù chung [25] Tuy nhiên ở đây chúng ta có thể hiểu hệ nhúng là một phần hệ thống

xử lý thông tin tích hợp trong các hệ thống lớn, phức hợp và độc lập ví dụ như trong

ôtô, các thiết bị đo lường, điều khiển, truyền thông và thiết bị thông minh nói chung

Chúng là những tổ hợp của phần cứng và phần mềm để thực hiện một hoặc một nhóm

chức năng chuyên biệt, cụ thể (Trái ngược với máy tính PC mà chúng ta thường thấy

được sử dụng không phải cho một chức năng mà là rất nhiều chức năng hay phục vụ

chung cho nhiều mục đích)

Chúng ta có thể kể ra rất nhiều các ứng dụng của hệ thống nhúng đang được sử

dụng hiện nay, và xu thế sẽ còn tiếp tục tăng nhanh Một số lĩnh vực của các hệ thống

nhúng có thể được nhóm như sau:

1.1.2 Hệ thống nhúng thời gian thực

Hệ thống thời gian thực là hệ thống mà tính đúng đắn của toàn bộ hệ thống phụ

thuộc cả vào tính đúng đắn về chức năng và tính đúng đắn về thời gian Tính đúng đắn

về thời gian được hiểu là yêu cầu của hệ thống phải đảm bảo thoả mãn về tính tiền

định trong hoạt động của hệ thống Tính tiền định nói lên hành vi của hệ thống thực

hiện đúng trong một khung thời gian cho trước hoàn toàn xác định Khung thời gian

này được quyết định bởi đặc điểm hoặc yêu cầu của hệ thống, có thể là vài giây và

cũng có thể là vài nano giây hoặc nhỏ hơn nữa Ở đây chúng ta phân biệt yếu tố thời

gian gắn liền với khái niệm về thời gian thực Không phải hệ thống thực hiện rất nhanh

là sẽ đảm bảo được tính thời gian thực vì nhanh hay chậm hoàn toàn là phép so sánh

có tính tương đối vì mili giây có thể là nhanh với hệ thống điều khiển nhiệt nhưng lại

là chậm đối với các đối tượng điều khiển điện như dòng, áp… Hơn thế nữa nếu chỉ

nhanh không thì chưa đủ mà phải đảm bảo duy trì ổn định bằng một cơ chế hoạt động

tin cậy Chính vì vậy hệ thống không kiểm soát được hoạt động của nó thì không thể là

một hệ thống đảm bảo tính thời gian thực mặc dù hệ thống đó có thể cho đáp ứng rất

nhanh, thậm chí nhanh hơn rất nhiều so với yêu cầu đặt ra Một ví dụ minh hoạ tiêu

biểu đó là cơ chế truyền thông dữ liệu qua đường truyền chuẩn Ethernet truyền thống,

mặc dù ai cũng biết tốc độ truyền là rất nhanh nhưng vẫn không phải hệ hoạt động thời

gian thực vì không thoả mãn tính tiền định trong cơ chế truyền dữ liệu (có thể là rất

nhanh và cũng có thể là rất chậm nếu có sự canh trạnh và giao thông đường truyền bị

nghẽn)

Người ta phân ra làm hai loại đối với khái niệm thời gian thực là cứng (hard

real-time) và mềm (soft real-time) Thời gian thực cứng là khi hệ thống hoạt động với

yêu cầu thoả 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 bị phá huỷ Ví dụ về hoạt động điều

khiển cho một lò phản ứng hạt nhân, nếu chậm ra quyết định có thể dẫn đến thảm hoạ

gây ra do phản ứng phân hạch và dẫn đến bùng nổ cả hệ thống Thời gian thực mềm là

khi hệ thống hoạt động với yêu cầu thoả 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ụ như hệ thống phát thanh truyền hình, nếu thông tin

truyền đi từ trạm phát tới người nghe/nhìn chậm một vài giây thì cũng không ảnh

hưởng đáng kể đến tính thời sự của tin được truyền đi và hoàn toàn được chấp nhận

bởi người theo dõi Thực tế thấy rằng hầu hết hệ nhúng là các hệ thời gian thực và hầu

hết các hệ thời gian thực là hệ nhúng Điều này phản ánh mối quan hệ mật thiết giữa

hệ nhúng và thời gian thực và tính thời gian thực đã trở thành như một thuộc tính tiêu

biểu của hệ nhúng Vì vậy hiện nay khi đề cập tới các hệ nhúng người ta đều nói tới

đặc tính cơ bản của nó là tính thời gian thực

1.2 Giới thiệu chung về thiết kế hệ thống nhúng

Các kỹ sư xây dựng hệ thống nhúng luôn phải đối mặt với nhiều khó khăn trong

quá trình thiết kế hệ thống Từ việc xác định phân bổ giữa phần cứng và phần mềm

cho đến việc tính toán để thiết kế đạt những mục tiêu về hiệu năng và chi phí Việc xây

dựng hệ thống nhúng ngày càng trở lên phức tạp vì yêu cầu ngày càng cao Họ phải

xây dựng những hệ thống ngày càng thông minh hơn, có nhiều chức năng hơn nhưng

lại phải được gói gọn trong một không gian nhỏ hơn, ít tiêu thụ điện năng hơn, thời

gian sản xuất nhanh hơn và chi phí cho hệ thống giảm Có lẽ bởi vì liên quan đến sự

kết hợp của ít nhất hai nguyên tắc phức tạp và sáng tạo: kỹ nghệ phần mềm và thiết kế

logic Vấn đề này thường liên quan đến xây dựng một cái mới mà mọi người chưa

từng xây dựng bao giờ hay đơn giản là có quá nhiều sự lựa chọn như: sử dụng bộ vi xử

lý nào cho phù hợp, cách sắp xếp các bus, triển khai bằng ngôn ngữ lập trình nào, có

sử dụng hệ điều hành hay không, môi trường phát triển …làm cho người phát triển

nhiều lúc không biết bắt đầu từ đâu

Không giống với việc thiết kế các ứng dụng phần mềm trên máy tính, việc thiết

kế một hệ thống nhúng phải thực hiện thiết kế cả phần cứng và phần mềm một cách

song song Mặc dù không phải lúc nào cũng vậy nhưng thực tế cho thấy đây là cách

thức tiếp cận việc thiết kế hệ thống nhúng một cách hiệu quả và ảnh hưởng sâu sắc đến

Trong hệ thống nhúng việc xác định yêu cầu là rất quan trọng Nó có thể giúp

chúng ta tránh được những vấn đề sau này như lượng RAM thiết kế cho hệ thống

nhúng không đủ cho hoạt động hay bộ xử lý được chọn có tốc độ quá chậm cho công

việc…Sau khi yêu cầu sản phẩm đã được xác định thì công việc tiếp theo là xác định

liệu sử dụng bộ vi xử lý có phải là sự lựa chọn tốt nhất không Những câu hỏi sau đây

có thể hữu ích khi xác định xem sử dụng bộ vi xử lý có hợp lý không:

vẫn đang tăng lên nhưng có một giới hạn trên thực tế với tốc độ bộ vi xử lý có

thể đọc từ một đầu vào hoặc cập nhật đầu ra và vẫn đang thực hiện công việc

Nếu hệ thống phải thực hiện việc xử lý quan trọng, xử lý bộ đệm, hoặc những

tính toán khác thì tỉ lệ cập nhật sẽ giảm xuống

thực hiện được công việc không? nếu có thì sử dụng bộ vi xử lý là không cần

thiết

nếu có thì bộ vi xử lý sẽ giải quyết công việc thuận lợi hơn

chuyện với hệ thống khác dùng giao thức điều khiển liên kết dữ liệu đồng bộ

(SDLC) hoặc một vài giao thức truyền thông phức tạp khác thì sử dụng bộ vi xử

lý là lựa chọn đúng đắn

(khởi động) điện tử hiện đại có rất nhiều đầu vào (các cảm ứng không khí, động

cơ rpm …) với những liên quan phức tạp sẽ có vài lựa chọn thay vì sử dụng bộ

vi xử lý

thiết kế không? Có cần phải tuỳ biến sản phẩm cho những phiên bản đặc biệt

không? những yêu cầu này đều ảnh hưởng đến việc có lựa chọn bộ vi xử lý hay

không

Thật may là công việc này của người thiết kế đang trở lên dễ dàng hơn do chi phí của

bộ vi xử lý sẽ giảm nhưng tốc độ và hiệu năng của nó sẽ được tăng lên

1.2.2 Lựa chọn bộ vi xử lý

Giả sử chúng ta đã quyết định sử dụng bộ vi xử lý cho hệ thống nhúng của mình

thì vấn đề tiếp theo là lựa chọn bộ vi xử lý cho phù hợp với hệ thống cần xây dựng

Thực tế cho thấy có nhiều sự lựa chọn đúng bộ xử lý cho hệ thống nhúng bởi vì sẽ có

vài bộ xử lý có thể đạt các yêu cầu đặt ra Sự lựa chọn bao gồm việc cân bằng các yếu

tố giữa chi phí và các chức năng Một số vấn đề cần phải được xem xét khi lựa chọn:

1.2.2 Phân bổ giữa phần cứng và phần mềm

Thiết kế hệ nhúng sẽ liên quan đến cả hai vấn đề là thiết kế các thành phần phần

cứng và các thành phần phần mềm, người thiết kế phải xác định xem vấn đề nào được

giải quyết trong phần cứng và vấn đề nào thì giải quyết ở phần mềm Sự lựa chọn này

được gọi là phân bổ quyết định

Những nhà phát triển ứng dụng thường phát triển với phần cứng được xác định

trước có thể có những khó khăn trong việc điều chỉnh về phần cứng để nâng cao hiệu

quả xử lý vấn đề Tuy nhiên họ cũng có thể đã gặp phải những vấn đề lựa chọn cân

nhắc giữa phần cứng và phần mềm Ví dụ, trong những ngày đầu của PC (trước khi

giới thiệu bộ xử lý 80486), những bộ xử lý 8086, 80286 và 80386 đều không có đơn vị

xử lý dấu phảy động trên chip Những bộ xử lý này yêu cầu những thiết bị đi kèm, đơn

vị xử lý dấu phảy động 8087, 80287 và 80387 (FPUs) để chạy trực tiếp các chỉ thị dấu

phảy động trong chương trình Nếu PC không có một FPU, thì mã chương trình phải

chặn những chỉ thị dấu phảy động lại và thực hiện một ngoại lệ hoặc hàm bẫy lỗi sẽ

thực hiện vấn đề xử lý dấu phảy động trên phần mềm Tuy nhiên điều này sẽ chậm hơn

nhiều so với có đơn vị xử lý dấu phảy động trên bảng mạch nhưng chí ít thì mã

chương trình cũng được thực thi

Một ví dụ khác về phân bổ giữa phần cứng và phần mềm, ta có thể mua một

thiết bị modem cho PC của mình rồi cắm vào khe ISA như vậy trên máy tính đã có

mạch thực hiện điều chế và giải điều chế Nếu ít tiền hơn ta có thể mua một win

modem để cắm vào khe PCI và sử dụng bộ vi xử lý để trực tiếp xử lý các chức năng

của modem Việc thiết kế là kết hợp giữa các thành phần phần cứng và phần mềm để

cho ra một giải pháp thiết kế nhúng hiệu quả nhất Chúng ta có thể thực hiện việc thiết

kế một chức năng nào đó dựa trên phần mềm (ví dụ CPU không có đơn vị FPU ở trên),

dựa trên phần cứng hoặc dựa trên cả phần cứng và phần mềm Để làm rõ hơn về vấn

đề phân chia giữa phần cứng và phần mềm chúng ta sẽ xét tiếp một ví dụ về thiết kế

máy in laser

Hình 1.3 mô tả một thiết kế cho máy in laser Với sự giúp đỡ từ những nhà thiết

kế máy in laser chúng ta có thể hình dung ra những công việc có thể thực hiện trong

máy in laser (phần mềm) Bộ vi xử lý nắm bắt luồng dữ liệu đến thông qua cổng song

song, cổng tuần tự RS-232C, cổng USB, hoặc cổng Ethernet vào trong bộ đệm

Hình 1.3 Thiết kế máy in laser

Cùng một thời điểm, bộ xử lý quản lý các cổng dữ liệu và chuyển những dữ liệu đến

thành luồng điều chế (stream of modulation) và những tín hiệu điều khiển cho ống

phóng laser, gương xoay, trống xoay, bộ phận quản lý giấy Chúng ta có thể thấy điều

này làm cho bộ xử lý phải làm rất nhiều việc do đó giới hạn hiệu năng của hệ thống

Chúng ta có thể tìm cách nâng cao hiệu năng của hệ thống bằng cách thêm nhiều bộ xử

lý và phân chia những nhiệm vụ đồng thời giữa chúng Điều này sẽ làm cho tốc độ xử

lý tăng lên, chi phí tăng lên, nhưng không có nhiều thông tin hơn để in

Khi phân tích giải pháp thiết kế chúng ta sẽ thấy rằng những công việc mà ảnh

hưởng đến hiệu năng của hệ thống cũng có những cận giới hạn nhất định và được mô

tả đầy đủ Những công việc này có thể được xử lý bằng các phương pháp thiết kế một

cách dễ dàng và có thể thực hiện theo giải pháp dựa trên phần cứng Ví dụ trong thiết

kế máy in laser này, chúng ta có thể sử dụng một khối phần cứng cho việc ghi các

điểm laser trên bề mặt của trống máy in Điều này sẽ giải phóng cho bộ xử lý để thực

hiện những công việc khác và chỉ yêu cầu nó khởi tạo và phục vụ phần cứng nếu có lỗi

nào đó xảy ra

Những yêu cầu cho phần cứng chặt chẽ hơn nhiều so với phần mềm bởi vì nó

phức tạp hơn, mất chi phí cho sửa lỗi phần cứng nhiều hơn so với sửa lỗi phần mềm

Nếu phần cứng là IC chuyên về ứng dụng tùy biến (Custom - ASIC) thì cần phải xem

xét nhiều hơn vì tính phức tạp của việc thiết kế một IC tùy biến Nếu cách tiết cận này

dường như quá rủi ro cho dự án, đội thiết kế có thể chuyển sang giải pháp phần mềm

hoặc đội thiết kế có thể đưa ra quyết định cần phải sử dụng một bộ xử lý mới hơn,

mạnh hơn để nâng cao hiệu năng Tuy nhiên điều này cũng liên quan đến vấn đề chi

phí, những công cụ mới, bố cục mạch mới, đường dữ liệu rộng hơn, tính phức tạp cao

hơn Hai triết lý thiết kế khác nhau này đã được áp dụng thành công cho thiết kế máy

in laser trong các công ty sản xuất máy in ngày nay Một bên thì thiết kế khả năng điều

chỉnh hiệu năng của bộ xử lý để tối thiểu hoá dùng các thiết bị phần cứng chuyên biệt

Ngược lại thì bên kia sử dụng các thiết bị phần cứng chuyên biệt để giảm gánh nặng

cho bộ xử lý Cả hai đều có những sản phẩm cạnh tranh nhưng thực hiện hai chiến

lược thiết kế khác nhau cho phân chia các thành phần cứng và mềm

Quyết định phân chia là một vấn đề tối ưu và phức tạp Nhiều thiết kế hệ thống

nhúng yêu cầu:

Những yêu cầu dường như mẫu thuẫn lẫn nhau này sẽ làm cho khó tạo ra một

thiết kế tối ưu cho sản phẩm nhúng Giải pháp phân bổ phụ thuộc vào bộ xử lý nào sử

dụng trong thiết kế, cách thực hiện thiết kế tổng thể và kinh nghiệm của người thiết kế

1.2.3 Thực hiện và lặp lại

Phần thực hiện và lặp lại của qui trình này thể hiện một vùng phân chia mờ giữa

thực hiện và phân bổ phần cứng/phần mềm (được thể hiện ở hình 1.2) Trong bước này

phần thiết kế phần mềm và phần cứng sẽ được tách ra và thực hiện đồng thời Giai

đoạn này thể hiện những công việc thiết kế đầu tiên trước khi đội phần cứng và phần

mềm thực hiện công việc cụ thể của lĩnh vực mình Mặc dù các vấn đề chính đã được

phân bổ giữa các thành phần phần cứng và phần mềm, tuy nhiên vẫn còn những vấn đề

có thể dịch chuyển giữa ranh giới này khi các ràng buộc thiết kế được mô hình hoá và

hiểu rõ hơn Trong giai đoạn này đòi hỏi người thiết kế thực hiện nhiều sự lựa chọn

liên quan đến công cụ, môi trường… Nhà thiết kế phần cứng có thể sử dụng các công

cụ mô phỏng để hỗ trợ cho quá trình thiết kế của mình như bộ mô phỏng kiến trúc

Nhà thiết kế phần mềm có thể sẽ chạy những đoạn mã chuẩn trên những bo mạch đơn

độc lập sử dụng bộ vi xử lý đích Những bo mạch này thường liên quan đến những

mạch đánh giá và chúng sẽ được dùng để đánh giá hiệu năng của bộ vi xử lý chạy trên

đoạn mã kiểm tra Những mạch đánh giá này cũng cung cấp một môi trường gỡ lỗi và

thiết kế phần mềm thuận tiện cho đến khi hoàn thành xong phần cứng của hệ thống

1.2.4 Thiết kế chi tiết phần cứng và phần mềm

Bước này đi sâu vào thực hiện thiết kế chi tiết phần cứng và phần mềm sau khi

đã có những đặc tả và phân chia các thành phần phần cứng, phần mềm Ở giai đoạn

này cần có những công cụ đặc biệt để hỗ trợ quá trình thiết kế và mô hình một cách

trực quan Ví dụ để thiết kế chi tiết phần cứng cần có các công cụ để mô tả phần cứng

như VHDL hay Verilog Đối với phần mềm có rất nhiều công cụ hỗ trợ trong gia đoạn

này như: Timed CSP, Z, UML-Realtime…(sẽ được trình bày chi tiết hơn ở chương 2)

1.2.5 Tích hợp phần cứng phần mềm

Giai đoạn tích hợp giữa phần cứng và phần mềm của vòng đời phát triển hệ

thống nhúng phải có những công cụ đặc biệt và phương pháp để quản lý độ phức tạp

Qui trình tích hợp phần cứng và phần mềm nhúng là quá trình thực nghiệm và gỡ lỗi

Thực nghiệm ở đây có nghĩa là phải xác định xem phần mềm thiết kế ra có chạy tốt

trên nền phần cứng không và có thực sự hiểu tài liệu đặc tả phần cứng không Ví dụ,

một vấn đề về big endian/ little endian trong quá trình tích hợp Người thiết kế phần

cứng thực hiện thứ tự các byte được tổ chức theo big endian, còn người thiết kế phần

mềm cho rằng theo thứ tự little endian Điều này có nghĩa là thành phần phần mềm và

phần cứng có thể đúng đắn trong quá trình thiết kế riêng nhưng bị lỗi trong quá trình

tích hợp do giao tiếp bị hiểu nhầm Ví dụ: cổng tuần tự được thiết kế cho một ASIC

với một bus 16 bit vào ra Cổng là vùng bộ nhớ ánh xạ tại địa chỉ 0x400000, 8 bit của

một từ là phần dữ liệu của cổng, 8 bít khác là phần trạng thái của cổng Thậm chí

người thiết kế phần cứng có thể xác định những bit nào là trạng thái, bit nào là dữ liệu

thì người thiết kế phần mềm vẫn có thể gán sai địa chỉ cổng khi ghi vào cổng theo cách

truy cập byte (hình 1.4)

Hình 1.4 Một ví dụ về vấn đề big endian/little endian

Nếu sử dụng mô hình big endian và tính địa chỉ theo byte, thì thuật toán nên kiểm tra

các bít trạng thái tại địa chỉ 0x400001 và bít dữ liệu được đọc từ hoặc viết tới địa chỉ

0x400000 Nếu sử dụng mô hình bộ nhớ little endian thì ngược lại Hệ thống nhúng

thường có độ phức tạp cao và hành vi không xác định mà nó chỉ có thể được phân tích

khi xảy ra Việc cố gắng mô hình và mô phỏng chính xác hành vi của hệ thống có thể

mất nhiều thời gian hơn thời gian phát triển sản phẩm Khi những công cụ mô hình

hoá được cải tiến thì sẽ nâng cao hơn khả năng tìm ra lỗi sớm

Gỡ lỗi hệ thống nhúng cũng gần giống như gỡ lỗi ứng dụng trên Desktop Nhìn

chung có ba yêu cầu cho việc gỡ lỗi hệ nhúng thời gian thực:

 Kiểm soát thực thi - khả năng thực hiện, dừng, hoạt động tối đa của bộ xử lý và

bộ nhớ

độ, dễ tải mã, gỡ lỗi và sửa đổi

Nhiều hệ thống nhúng không thể gỡ lỗi trừ khi chúng được thực hiện ở tốc độ thực và

việc chạy một chương trình nhúng dưới bộ gỡ lỗi có thể làm chậm chương trình

1.2.6 Kiểm thử

Kiểm thử hệ thống nhúng cần sự quan tâm đặc biệt vì không những nó phải

đảm bảo các chức năng của hệ thống hoạt động đúng và đủ mà còn phải đảm bảo cả về

yếu tố thời gian thực hiện Đặc biệt trong những hệ thống an toàn, an ninh liên quan

đến mạng sống con người, việc kiểm thử cần phải thực hiện kỹ hơn vì chỉ cần một lỗi

nhỏ cũng gây ra những thảm họa đáng tiếc Do đó yêu cầu về kiểm thử và độ tin cậy

đối với hệ thống nhúng đòi hỏi phải chặt chẽ hơn đa số các ứng dụng trên Desktop Ví

dụ nhiều ứng dụng trên Desktop có những rò gỉ về bộ nhớ và khi chương trình chạy

được một khoảng thời gian thì máy tính sẽ bị tràn bộ nhớ, tuy nhiên trên Desktop thì

RAM và không gian swap là tương đối lớn và nhiều khi không phải là vấn đề Ngược

lại đối với hệ thống nhúng, do chúng thường hoạt động liên tục nên chỉ cần một lỗi rò

gỉ bộ nhớ nhỏ cũng có thể gây ra trục trặc Nếu phát hiện ra lỗi sớm hơn thì chi phí để

sửa lỗi sẽ ít hơn là khi phát hiện ra lỗi muộn, hình 1.5 dưới đây thể hiện mối liên hệ

này

Hình 1.5 Mối liên hệ về chi phí sửa lỗi cho mỗi giai đoạn

1.2.7 Bảo trì và cập nhật

Đa số các nhà thiết kế hệ thống nhúng (khoảng 60 %) thực hiện bảo trì và nâng

cấp sản phẩm tồn tại hơn là thiết kế lại sản phẩm mới Hầu hết họ không phải là những

thành viên của đội thiết kế ban đầu của sản phẩm, do đó họ phải dựa vào kinh nghiệm,

kỹ năng và những tài liệu về sản phẩm để hiểu sản phẩm ban đầu và thực hiện bảo trì

nâng cấp Giai đoạn này đòi hỏi cần phải có những công cụ để bóc tách được những

vấn đề từ mã nguồn để nhanh chóng hiểu nó Ví dụ muốn đáp ứng nhanh yêu cầu mới

đặt ra cho sản phẩm được thực hiện bằng cách cần tăng tốc độ bộ vi xử lý lên 25%, tuy

nhiên nó sẽ gây ra những thay đổi đến toàn bộ thiết kế, do đó cần có sự nghiên cứu kỹ

lưỡng với những giải pháp đưa ra

CHƯƠNG 2: THIẾT KẾ PHẦN MỀM NHÚNG

2.1 Phần mềm nhúng

Trong những ngày đầu của hệ thống nhúng, tất cả những công việc xây dựng hệ

thống (bao gồm cả phần cứng và phần mềm) đều được xử lý bởi một kỹ sư Các thành

phần phần mềm chỉ chiếm một phần nhỏ trong toàn bộ quá trình thiết kế và phát triển:

khoảng 5% đến 10% Qua thời gian, phần công việc kỹ thuật dành cho phát triển phần

mềm nhúng đã tăng đáng kể Vào giữa những năm 80 thì phần công việc được thực

hiện bởi các chuyên gia phần mềm lớn hơn 50%, và đến nay mặc dù thiết kế phần

cứng ngày càng trở lên phức tạp thì công sức giành cho xây dựng phần mềm nhúng

chiếm khoảng 70% đến 80%

Hình 2.1 Phần mềm nhúng trong hệ thống

Do yêu cầu của hệ thống, ngày càng nhiều phần mềm cần được phát triển trong

một khoảng thời gian ngắn và môi trường để kiểm thử cho phần mềm nhúng cũng cần

sớm hơn (ngay trong quá trình phát triển phần mềm) Rất nhiều giải pháp đã được đưa

ra bao gồm những môi trường mẫu thực thi mã, mô phỏng tập chỉ thị, và sử dụng các

bảng mạch đánh giá chuẩn, chi phí thấp để kiểm thử phần mềm trên môi trường giống

môi trường đích Ngoài ra những công nghệ kết nối máy chủ - máy đích chi phí thấp

cũng đang trở lên phổ biến, ví dụ sử dụng một giao tiếp JTAG Điều này tạo điều kiện

cho các đội phần cứng và phần mềm nhúng thực sự phối hợp làm việc với nhau sử

dụng những kỹ thuật đồng thiết kế (co-design) và đồng kiểm chứng (coverification)

Thời gian dành cho phát triển phần mềm nhúng tăng lên, trong khi đó dưới áp

lực cạnh tranh thì thời gian đưa các sản phẩm nhúng ra thị trường đang giảm xuống

Điều này ảnh hưởng nhanh chóng đến chiến lược thiết kế Những thiết kế ban đầu

thường khá đơn giản, chỉ bao gồm những mã chương trình được thiết kế của một tổ

chức, đơn vị Khi các hệ thống đã trở lên phức tạp, một mô hình đa nhiệm đã được áp

dụng rộng rãi cho phát triển phần mềm và nhiều nhà phát triển đã sử dụng những sản

phẩm hệ điều hành thời gian thực (RTOS) thương mại chuẩn cho hệ thống của mình

Phần phần mềm mua sẵn hay sở hữu trí tuệ (intelectual property - một từ vay mượn từ

thiết kế phần cứng) trong hệ nhúng đã tăng lên đều đặn và xem như một tiêu chuẩn để

áp dụng Được thể hiện trong hình vẽ 2.2

Hình 2.2 Thành phần phần mềm nhúng

Phần mềm cho hệ thống nhúng có những yêu cầu khác với những phần mềm

chạy trên máy tính cá nhân hoặc trên máy trạm Ngoài việc trả lời câu hỏi “Hệ thống

phải làm gì?” người thiết kế phải biết được “Thời gian đáp ứng cho chức năng đó là

bao lâu?”

2.1.1 Sự khác biệt giữa phần mềm nhúng và phần mềm thông thường trên

PC

Sự khác nhau giữa việc phát triển hệ thống nhúng và hệ thống chạy trên máy tính

thông thường có thể liệt kê một số điểm như sau [13]:

các nền tảng tính toán và xử lý chung Các bộ xử lý trong hệ thống nhúng là các

vi xử lý chuyên biệt Nó được lập trình chỉ để thực hiện một vài tác vụ Thay

đổi các tác vụ có thể đòi hỏi phải thiết kế lại hệ thống hoặc thay đổi toàn bộ hệ

 Các hệ thống nhúng được thiết kế cùng với phần cứng được chỉ định sẵn Chính

vì thế, tính năng của hệ thống luôn được cân nhắc cùng với chi phí phát triển

Ngoài ra với một số tác vụ cần phải có những phần cứng chuyên biệt

thống nhúng thời gian thực

hành thời gian thực Giống như vi xử lý nhúng, hệ điều hành nhúng cũng có rất

nhiều (cả thương mại và phi thương mại) và có cách quản lý khác nhau Tuy

nhiên mục tiêu quan trọng là nó phải giải quyết các vấn đề khắt khe về mặt thời

gian và chia sẻ tài nguyên

chương trình để tìm lỗi đòi hỏi phải có những phần cứng hỗ trợ, thông thường

được gọi là emulator

năng lượng được coi là quan trọng hàng đầu Phương pháp đầu tiên để duy trì

năng lượng Pin là tắt bớt các dịch vụ không cần thiết trong quá trình hoạt động

hoặc chuyển vào các chế độ tiết kiệm năng lượng khi cần thiết Hầu hết các vi

xử lý cho hệ thống nhúng đều có các chế độ tiết kiệm năng lượng Phần mềm

thường đặt bộ vi xử lý trong những chế độ này với các chỉ thị đặc biệt hoặc ghi

một giá trị tới thanh ghi điều khiển bên trong vi xử lý Các chế độ tiết kiệm điện

thường thấy như: sleep mode, low-power mode, idle mode, standby mode,

nhúng có mặt ở mọi nơi và có thể được thiết kế để làm mọi thứ Chính vì thế

khi thiết kế hệ thống phải đặc biệt chú trọng tới các yếu tố phần cứng có khả

năng chịu được điều kiện môi trường Ví dụ như các hệ thống nhúng kiểm tra

trong hầm lò, lò phản ứng hạt nhân, trên không gian

hơn nhiều so với các ứng dụng Desktop

2.1.2 Nguyên tắc thiết kế chung

Thiết kế hệ thống nhúng phải đối mặt với nhiều yếu tố tác động và thông

thường phức tạp hơn việc thiết kế các ứng dụng trên desktop Trong quá trình thiết kế,

không những người thiết kế phải trả lời câu hỏi hệ thống làm gì mà còn phải biết được

tốc độ thực thi của hệ thống và khả năng đáp ứng thời gian từ đó đưa ra những lựa

chọn trong quá trình thiết kế Thời gian thực thi luôn là yếu tố đặc trưng của một hệ

thống nhúng thời gian thực Hơn nữa, phải xác định khoảng thời gian thực thi nào

quan trọng để điều tiết bộ lập lịch Điều này phụ thuộc vào tính chất của hệ thời gian

thực cứng hay mềm

Để thiết kế phần mềm hiệu quả, chúng ta cũng phải biết về các thiết bị phần

cứng Ví dụ hệ thống của chúng ta sẽ nhận dữ liệu từ một cổng tuần tự ở tốc độ 9600

bit (khoảng 1000 ký tự) trên giây Nếu mỗi ký tự nhận được sinh ra một ngắt thì phần

mềm thiết kế phải đảm bảo phục vụ được các hàm ngắt cổng tuần tự thực hiện 1000

lần trong một giây Ngược lại, nếu phần cứng cổng tuần tự có thể copy những ký tự

đến vào bộ nhớ thông qua một kênh DMA và hệ thống không phải quan tâm đến các

ký tự ngay lập tức khi chúng đến thì ta sẽ không phải xử lý hàm ngắt nhiều như trường

hợp trên nữa Chúng ta cũng phải biết được tốc độ của bộ vi xử lý để xác định xem

mỗi tính toán mất bao nhiêu thời gian và liệu nó có ảnh hưởng đến deadline không khi

thiết kế

Thiết kế phần mềm nhúng cũng sử dụng những kỹ năng kỹ nghệ phần mềm nói

chung Các khái niệm cấu trúc, mô-đun, thành phần, lớp, đối tượng cũng đóng vai trò

quan trọng trong thế giới phần mềm nhúng Các công cụ và phương pháp thiết kế cũng

vậy, có những cái chung hoặc mở rộng cho thiết kế hệ thống nhúng Không có công cụ

nào có thể đảm bảo được chất lượng thiết kế hệ nhúng, mà chất lượng thiết kế phụ

thuộc vào kinh nghiệm, sự hiểu biết và tính cẩn thận của người thiết kế

Do việc gỡ lỗi và kiểm thử cho hệ thống nhúng khá là khó khăn nên trong quá

trình thiết kế cần xem xét đến vấn đề này

2.1.3 Thiết kế phần mềm nhúng với RTOS

a Hoạt động chung

Các hệ thống nhúng thường không làm gì cho đến một thời điểm nào đó hoặc

có sự kiện bên ngoài yêu cầu đáp ứng Ví dụ: nếu không có dữ liệu để in, các máy in

laser sẽ không làm gì ngoài việc “wake up” từng phút hoặc dịch chuyển trống máy in

một chút Nếu người dùng không nhấn công tắc hoặc các phím thì máy quét mã vạch

sẽ chuyển sang trạng thái nghỉ ngơi cho bộ xử lý

Do các sự kiện bên ngoài thường gây ra các ngắt, và có thể gây ra ngắt bằng

cách đặt thời gian trong bộ định thời, các ngắt trở thành một yếu tố điều khiển của

phần mềm nhúng Một kỹ thuật thiết kế hệ thống nhúng thường dùng là khoá từng tác

vụ của RTOS mà ngốn nhiều thời gian lại và đợi cho một hàm ngắt hoặc tác vụ khác

gửi một thông điệp hay gây ra một sự kiện hoặc giải phóng một semaphore để thông

báo cho tác vụ đó biết có việc cần xử lý Khi một ngắt xảy ra, hàm ngắt sử dụng các

dịch vụ RTOS để truyền tín hiệu cho một hoặc nhiều tác vụ Từng tác vụ sẽ thực hiện

công việc của mình và có thể lại truyền tín hiệu cho một tác vụ khác Theo cách này,

từng ngắt có thể tạo ra một dãy các tín hiệu và các hoạt động của tác vụ

b Viết các hàm ngắt ngắn gọn

Nhìn chung viết các hàm ngắt ngắn gọn thì tốt hơn là viết các hàm ngắt dài thực

hiện nhiều công việc Có hai lý do để thực hiện điều này: Thứ nhất, vì ngay cả những

hàm ngắt có độ ưu tiên thấp nhất vẫn được ưu tiên thực hiện trước những mã tác vụ có

mức ưu tiên cao nhất Viết những hàm ngắt dài sẽ làm cho sự đáp ứng các mã tác vụ

chậm hơn Thứ hai là, các hàm ngắt thường có xu hướng gây ra nhiều lỗi và khó gỡ lỗi

hơn mã tác vụ

Hầu hết các sự kiện yêu cầu những đáp ứng khác nhau từ hệ thống phần mềm:

hệ thống phải khởi tạo lại cổng phần cứng, lưu lại dữ liệu nhận được, khởi tạo lại bộ

điều khiển ngắt, phân tích dữ liệu nhận được, tính toán các đáp ứng,…Thời hạn đối

với những đáp ứng này có thể rất khác nhau Mặc dù khởi tạo lại cổng phần cứng và

bộ điều khiển ngắt, lưu dữ liệu có thể cần ngay lập tức, nhưng việc phân tích dữ liệu

và đáp ứng cho nó thường không gấp như vậy Do đó trong hàm ngắt nên xử lý những

hành động cần đáp ứng gấp và sau đó truyền tín hiều cho một tác vụ để thực hiện

những công việc còn lại

c Phân chia bao nhiêu tác vụ cho phù hợp?

Một trong những vấn đề đầu tiên khi thiết kế hệ thống nhúng là việc phân chia

công việc hệ thống ra thành các tác vụ RTOS Một câu hỏi đặt ra là “liệu phân chia ra

thành nhiều tác vụ thì tốt hay ít tác vụ thì tốt ?” Để trả lời câu hỏi này, hãy xem xét

những ưu nhược điểm mà ảnh hưởng đến việc phân chia tác vụ:

Ƣu điểm:

 Với nhiều tác vụ hơn, chúng ta sẽ kiểm soát thời gian đáp ứng các phần khác

nhau của công việc được tốt hơn Ví dụ ta chia công việc của một hệ thống ra

thành 8 tác vụ thì lúc đó có thể gán được 8 mức ưu tiên khác nhau cho các tác

vụ Chúng ta sẽ có được thời gian đáp ứng tốt cho công việc được thực hiện ở

những tác vụ có mức ưu tiên cao hơn Nếu ta sử dụng số tác vụ trong khoảng từ

1 đến 8 thì sẽ nhận được những đáp ứng trong khoảng đó

 Với nhiều tác vụ hơn, hệ thống sẽ được chia thành nhiều mô-đun xử lý độc lập

hơn Ví dụ nếu hệ thống có một máy in, một cổng tuần tự, một kết nối mạng,

một bàn phím và nếu xử lý tất cả những thiết bị này trong một tác vụ, thì tác vụ

đó sẽ dễ bị nhầm lẫn và rối tung lên Sử dụng tác vụ tách biệt cho từng thiết bị

sẽ làm cho chương trình rõ ràng và dễ xử lý hơn

 Với nhiều tác vụ hơn, ta có thể bao gói dữ liệu hiệu quả hơn Nếu kết nối mạng

được xử lý bởi một tác vụ tách biệt thì chỉ có mã trong tác vụ đó cần truy cập

tới các biến chỉ trạng thái của giao tiếp mạng

Nhƣợc điểm:

 Với nhiều tác vụ hơn, chúng ta có thể có nhiều dữ liệu được chia sẻ giữa các tác

vụ hơn Điều này dẫn tới cần nhiều cơ chế semaphore để kiểm soát và do đó sẽ

mất nhiều thời gian để bộ vi xử lý xử lý semaphore hơn và cũng có thể gây ra

nhiều lỗi liên quan đến semaphore

 Với nhiều tác vụ hơn, chúng ta có thể cần nhiều yêu cầu để truyền thông điệp từ

một tác vụ tới tác vụ khác thông qua pipe, mailbox, queue …Điều này cũng dẫn

tới mất nhiều thời gian xử lý và có cơ hội xảy ra lỗi hơn

 Mỗi tác vụ đều yêu cầu một stack; do đó với nhiều tác vụ hơn sẽ cần phải cấp

nhiều bộ nhớ hơn, ít nhất là cho stack và có khi còn cho các thông điệp giữa các

tác vụ

 Mỗi lần RTOS chuyển tác vụ, bộ xử lý sẽ phải mất thời gian để lưu lại những

trạng thái của tác vụ đó và khôi phục lại khi thực hiện tiếp Một điều khác nữa

là khi thiết kế nhiều tác vụ thì có thể dẫn đến RTOS chuyển tác vụ nhiều hơn và

làm giảm thông lượng của hệ thống

 Nhiều tác vụ hơn cũng đồng nghĩa với việc có nhiều lời gọi tới RTOS hơn Các

nhà sản xuất RTOS có thể nâng cao những sản phẩm của họ bằng cách thông

báo thời gian chuyển đổi giữa các tác vụ của hệ thống, đặt các thông điệp vào

mailbox, đặt các sự kiện …Điều đó sẽ làm cho sản phẩm của họ nhanh hơn, tuy

nhiên các chức năng RTOS sẽ không làm những thứ mà khách hàng quan tâm

Do đó thông qua việc xem xét các ưu nhược điểm của việc phân chia tác vụ trên,

người thiết kế hệ thống sẽ phải nghiên cứu rất kỹ lưỡng các yếu tố để tiến hành phân

chia tác vụ hợp lý cho hệ thống của mình Và thêm tác vụ chỉ khi có những lý do cần

thiết như:

đối với những kiến trúc khác là nâng cao được khả năng điều khiển đáp ứng của các mã tác vụ Do đó có nhiều tác vụ sẽ có khả năng gán những mức ưu tiên cao hơn cho các phần việc đòi hòi yêu cầu thời gian đáp ứng chặt chẽ hơn Ví dụ trong hệ thống nhúng theo dõi bể xăng ngầm, sự kiện bấm nút sẽ cần đáp ứng tốt hơn những tính toán về mức xăng (mất nhiều thời gian), vậy nên mã viết cho hai phần này của hệ thống cần được đưa vào những tác vụ riêng rẽ

sẻ bởi các phần khác nhau của hệ thống thì nên thêm vào đó một tác vụ riêng biệt Ví dụ, mã xử lý các nút bấm trên một bảng nút phía trước máy

in laser, sử dụng màn hình máy in để trả kết quả lại cho người dùng, và

mã dùng để di chuyển giấy thông qua cơ chế của máy in cũng sử dụng màn hình để hiển thị hết giấy hoặc kẹt giấy Nếu cả hai phần của hệ thống đều có thể ghi trực tiếp ra màn hình thì có thể sinh ra tranh chấp

do cả hai có thể đều muốn ghi ra màn hình cùng một thời điểm Nên việc đưa thêm một tác vụ tách biệt để điều khiển màn hình là cần thiết và có thể giải quyết được vấn đề này Khi những tác vụ khác trong hệ thống có thông tin cần ghi ra màn hình chúng sẽ gửi thông điệp tới tác vụ màn hình RTOS sẽ đảm bảo việc đưa các thông điệp vào queue và xác định xem thông điệp nào được hiển thị trước Tương tự như vậy, nếu có nhiều phần của hệ thống muốn lưu dữ liệu vào một bộ nhớ flash thì nên thêm một tác vụ riêng có trách nhiệm quản lý bộ nhớ flash sẽ làm đơn giản hoá vấn đề

d Sử dụng cấu trúc tác vụ hiệu quả

Tác vụ duy trì một vòng lặp vô hạn chờ tín hiệu từ RTOS để thực hiện một

công việc nào đó Tín hiệu thường được định dạng trong một thông điệp từ hàng đợi

Tác vụ này khai báo các dữ liệu private của nó

Hình 2.3 Cấu trúc đề nghị của một tác vụ

Ưu điểm của cấu trúc này là:

(empty), tác vụ sẽ bị khoá và không tiêu tốn thời gian xử lý của CPU

vụ khác muốn xem hoặc thay đổi dữ liệu private của tác vụ này cần viết một

yêu cầu gửi tới hàng đợi Do đó không có dữ liệu chia sẻ và không có

semaphore

Tác vụ trong hệ thống nhúng thường được cấu trúc như các máy trạng thái: trạng thái

được lưu trong các biến private của tác vụ, thông điệp mà tác vụ nhận được trong hàng

đợi của nó là các sự kiện

e Tránh việc khởi tạo và huỷ các tác vụ

Mọi RTOS cho phép tạo các tác vụ khi hệ thống khởi động Hầu hết RTOS cho

phép tạo và huỷ các tác vụ khi hệ thống đang chạy Tuy nhiên, ta nên tránh các hành

động này vì hai lý do như sau: thứ nhất, các hàm tạo và huỷ tác vụ thường tiêu tốn

nhiều thời gian xử lý của CPU, thường cao hơn nhiều so với việc nhận một semaphore

hoặc ghi một thông điệp vào mailbox Thứ hai, khi tạo một tác vụ thì thao tác này

tương đối tin cậy nhưng thao tác huỷ bỏ tác vụ là một thao tác không tin cậy vì khó có

thể huỷ bỏ một tác vụ mà không để lại một chút gì liên quan và dễ sinh ra lỗi Ví dụ,

nếu huỷ một tác vụ trong khi tác vụ đó đang nắm giữ một semaphore, khi mà các tác

vụ khác cần semaphore đó có thể bị khoá mãi mãi

f Xem xét đến việc tắt phân lát thời gian

Chúng ta biết rằng bộ lập lịch RTOS luôn thực hiện những tác vụ sẵn sàng có

độ ưu tiên cao nhất Tuy nhiên có vấn đề nảy sinh khi có hai hay nhiều tác vụ có cùng

mức ưu tiên và không tác vụ nào có mức ưu tiên cao hơn Một lựa chọn mà hầu hết các

RTOS đưa ra trong tình huống này là chia nhỏ thời gian thành các lát, để bộ xử lý thực

hiện luân phiên tất cả các tác vụ, mỗi tác vụ trong một lát thời gian ngắn (thực hiện

tác vụ này trong một lát thời gian được chia rồi lại chuyển sang tác vụ khác và cứ như

vậy cho đến khi thực hiện xong) Lựa chọn này rất là tuyệt vời khi có nhiều người

dùng có chương trình chạy trên cùng một hệ thống, nếu sử dụng các lát thời gian chia

nhỏ thì từng chương trình sẽ được gán CPU để xử lý công việc và mọi người đều thấy

tiến triển công việc của mình RTOS cũng cho phép chúng ta tắt lựa chọn này Với

nhiều hệ thống ta nên cân nhắc để làm việc này vì phân chia nhỏ thời gian cho các tác

vụ cũng sẽ dẫn đến có nhiều chuyển đổi tác vụ trong khi thực hiện nên sẽ gây ra làm

giảm thông lượng của hệ thống

g Hạn chế các dịch vụ không cần thiết của RTOS trong hệ thống

Hầu hết các RTOS, ngay cả những cái khá nhỏ cũng đều đưa ra nhiều dịch vụ

hơn so với nhu cầu sử dụng trong một dự án cụ thể Do nhiều RTOS cho phép cấu

hình lại chúng để loại bỏ những dịch vụ không cần thiết cho dự án, ta có thể tiết kiệm

được không gian nhớ và khả năng tính toán của CPU bằng việc cấu hình một tập các

dịch vụ RTOS đủ dùng cho hệ thống của mình Ví dụ nếu hệ thống cần xây dựng sử

dụng bảy pipe và một queue, chúng ta sẽ phải thêm cả mã pipe và mã queue vào trong

hệ thống Nếu có thể thay thế queue bằng cái pipe thứ tám, ta có thể loại bỏ mã queue

RTOS ra khỏi hệ thống

Nhiều nhà thiết kế hệ nhúng thích đưa các shell vào trong RTOS và gọi shell

thay vì gọi trực tiếp RTOS từ mã Điều này không chỉ hạn chế phần còn lại của mã với

tập các dịch vụ của RTOS đã được lựa chọn, mà còn làm cho mã chương trình trở lên

khả chuyển hơn từ RTOS này tới các RTOS khác bởi vì chỉ cần viết lại shell

2.2 Kiến trúc phần mềm nhúng

Người ta chia kiến trúc hệ thống nhúng ra làm 4 loại [13]: Round robin, Round

robin với ngắt, Function-queue-scheduling và hệ điều hành thời gian thực

2.2.1 Round robin

Đây là kiến trúc đơn giản nhất, nó không có cơ chế ngắt, không có vấn đề về dữ

liệu chia sẻ (thường xẩy ra đối với kiến trúc có cơ chế ngắt) và vấn đề về độ trễ Vòng

lặp chính đơn giản chỉ kiểm tra lần lượt từng thiết bị vào ra và phục vụ khi thiết bị đó

yêu cầu Dưới đây là khuôn mẫu về kiến trúc này:

Hình 2.4 Kiến trúc Round robin

Do tính đơn giản của nó, kiến trúc round – robin được áp dụng cho việc thiết kế một số

hệ thống nhúng đơn giản

Ví dụ: Kiến trúc này được áp dụng cho thiết kế thiết bị đo điện tử Thiết bị này

dùng để đo điện trở, cường độ và hiệu điện thế dòng điện theo các đơn vị ohm, amp,

vol trong một số khoảng khác nhau Một thiết bị đo điện tử thông thường có 2 cực mà

người sử dụng sẽ dùng để chạm vào 2 điểm của mạch điện cần đo, một màn hình hiển

thị, và một nút xoay to dùng để chọn đơn vị và khoảng để đo Hệ thống sẽ đo và hiển

thị kết quả gần nhất vừa đo Tại mỗi thời điểm hệ thống sẽ kiểm tra vị trí của nút xoay

và thực hiện tính toán đo tương ứng sau đó định dạng kết quả đưa ra màn hình Kiến

trúc Round-robin hoạt động tốt đối với hệ thống này bởi vì chỉ có 3 thiết bị vào ra,

không có những yêu cầu chặt về thời gian đáp ứng của hệ thống Bộ vi xử lý có thể

đọc phần cứng và đưa ra những đánh giá thích hợp tại mỗi thời điểm Kiến trúc này chỉ

có được ưu điểm là sự đơn giản so với các kiến trúc khác, trong khi đó nó có một số

nhược điểm mà không thể áp dụng được cho nhiều hệ thống:

phải đi qua và xử lý tất cả các thiết bị trong vòng lặp thì hệ thống không đáp

ứng được

thống cũng chưa chắc đã hoạt động tốt vì khi trong vòng lặp có một việc xử lý

chiếm nhiều thời gian

2.2.2 Round robin với ngắt

Kiến trúc này phức tạp hơn vì có thêm vào cơ chế ngắt, các hàm ngắt dùng để

xử lý những việc cấp thiết của phần cứng và sau đó thiết lập các cờ Nó cho phép

chúng ta điều khiển một chút về mức độ ưu tiên và hàm ngắt sẽ nhận được thời gian

đáp ứng tốt bởi vì tín hiệu ngắt sẽ làm cho bộ xử lý dừng những công việc đang xử lý

và thay vào đó là thực hiện công việc trong hàm ngắt Tất cả những việc xử lý cho vào

trong hàm ngắt thì đều có mức độ ưu tiên cao hơn mã tác vụ trong vòng lặp chính

Hơn nữa ta có thể gán nhiều mức độ ưu tiên cho cho các hàm ngắt trong hệ thống và

điều khiển được mức độ ưu tiên đó Khuôn mẫu của kiến trúc này như sau:

Hình 2.5 Kiến trúc Round-robin with interrupts

Nhược điểm chính của kiến trúc này là tất cả các mã tác vụ đều thực hiện ở mức độ ưu

tiên như nhau Giả sử rằng những phần xử lý trong mã tác vụ của hình trên với các

thiết bị A, B, và C mất khoảng 200 mili giây cho mỗi thiết bị Nếu tất cả các thiết bị A,

B, C đều ngắt khi bộ vi xử lý thực hiện câu lệnh tại đỉnh vòng lặp, thì mã tác vụ cho

thiết bị C có thể phải đợi tới 400 mili giây trước khi nó bắt đầu được xử lý

2.2.3 Kiến trúc Function – Queue - Scheduling

Trong kiến trúc này, các hàm ngắt sẽ thêm những con trỏ hàm vào hàng đợi con

trỏ hàm cho hàm chính gọi Hàm chính chỉ đọc các con trỏ từ hàng đợi và gọi các hàm

Điều làm cho kiến trúc này trở lên thú vị là không có luật nào nói rằng hàm main()

phải gọi các hàm theo một thứ tự nhất định mà các hàm ngắt xảy ra Nó có thể gọi

chúng dựa trên bất kỳ lược đồ về mức ưu tiên phù hợp với mục đích của người thiết

kế Bất kỳ hàm tác vụ nào muốn đáp ứng nhanh hơn có thể được thực hiện sớm hơn

Dưới đây là khuôn mẫu của kiến trúc này

Hình 2.6 Kiến trúc Function-Queue-Scheduling

Mặc dù kiến trúc function-queue-scheduling làm giảm thời gian đáp ứng xấu

nhất của hệ thống đối với những mã tác vụ có mức độ ưu tiên cao, nhưng nó vẫn còn

chưa đủ tốt bởi vì một số hàm mã tác vụ có mức độ ưu tiên thấp hơn sẽ phải chờ khá

lâu, nó sẽ ảnh hưởng đến thời gian đáp ứng của những hàm có mức ưu tiên cao hơn

2.2.4 Kiến trúc Hệ điều hành thời gian thực (RTOS)

Trong kiến trúc này, như những phần trước chúng ta đã thảo luận thì hàm ngắt

sẽ tiếp quản những việc xử lý cấp thiết nhất (những thứ mà không thể chờ được), sau

đó chúng truyền tín hiệu cho mã tác vụ để thực hiện những công việc còn lại Sự khác

nhau giữa kiến trúc này với các kiến trúc trước là:

- Việc đánh tín hiệu giữa các hàm ngắt và với mã tác vụ được xử lý bởi hệ

điều hành thời gian thực Chúng ta không cần phải sử dụng những biến dùng

chung cho mục đích này

- Không có vòng lặp trong mã để quyết định xem sẽ thực hiện công việc gì

tiếp theo Hệ điều hành thời gian thực biết được tất cả những công việc cần

thực hiện và nó sẽ thực thi những công việc nào cần thiết tại mỗi thời điểm

- Hệ điều hành thời gian thực có thể tạm thời dừng một hàm mã tác vụ đang

được xử lý để thực hiện một nhiệm vụ khác

Có rất nhiều Hệ điều hành thời gian thực mà ta có thể mua để áp dụng cho mục đích

cụ thể và khi mua hệ điều hành này ta sẽ có ngay những giải pháp cho vấn đề thời gian

đáp ứng cùng với các công cụ gỡ lỗi Nhược điểm chính của kiến trúc này là vấn đề

bản thân hệ điều hành thời gian thực cũng cần thời gian để xử lý những công việc của

hệ điều hành Chúng ta sẽ nhận được thời gian đáp ứng tốt hơn khi tiêu tốn ít thông

lượng

Hình 2.7 Kiến trúc Hệ điều hành thời gian thực

2.3 Các phương pháp đặc tả và thiết kế phần mềm nhúng

2.3.1 Phương pháp đặc tả hình thức (formal method)

Các phương pháp hình thức là các kỹ thuật toán học cho việc đặc tả, phát triển

và kiểm định các hệ thống phần mềm và phần cứng Cách tiếp cận này đặc biệt quan

trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống điều khiển lò

phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò quan

trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi, điều

này cũng rất phù hợp cho phát triển các hệ thống nhúng vì đòi hỏi những yêu cầu ràng

buộc khắt khe Các phương pháp hình thức đặc biệt hiệu quả tại giai đoạn đầu của quá

trình phát triển (tại các mức yêu cầu và đặc tả hệ thống), nhưng cũng có thể được sử

dụng cho một quá trình phát triển hoàn chỉnh của một hệ thống

Các phương pháp hình thức có thể được sử dụng để mô tả về hệ thống cần phát

triển, tại bất kỳ mức độ chi tiết nào và bất cứ pha nào trong vòng đời phát triển phần

mềm Khi một đặc tả hình thức đã được phát triển xong, đặc tả đó có thể được sử dụng

làm một hướng dẫn trong quá trình hệ thống thực được phát triển (nghĩa là được hiện

thực hóa trong phần mềm hoặc phần cứng) Sau đó đặc tả này có thể được dùng làm cơ

sở cho việc chứng minh các tính chất của hệ thống Các đặc tả hình thức mô tả ở mức

độ chính xác logic cao Nó loại trừ những nhầm lẫn mập mờ không tránh khỏi trong

các đặc tả phi hình thức Tính chính xác này giúp cho người diễn tả và người đọc

chúng có tiếng nói chung, đạt được sự nhất quán, giúp cho phát triển hệ thống ổn định

an toàn

Định nghĩa đặc tả hình thức:

Đặc tả hình thức là một mô tả chính xác các hành vi và thuộc tính của hệ thống

được viết trên một số ngôn ngữ có cơ sở toán học, nó mô tả một cách ngắn gọn và chặt

chẽ các yêu cầu mà một hệ thống được giả định là sẽ thực hiện Vì vậy có thể loại trừ

những chi tiết mập mờ và mô tả được những thay đổi tổng quát cộng với những thay

đổi của hệ thống trong tương lai

Có khá nhiều phương pháp hình thức được áp dụng cho đặc tả, phát triển và

kiểm định các hệ thống nhúng, thời gian thực Trong bài luận văn này đưa ra giới thiệu

các phương pháp phổ biến đã được nghiên cứu và ứng dụng rộng rãi để phát triển các

hệ thống trong công nghiệp Ngoài ra, do yêu cầu và đặc trưng của từng loại hệ thống

nhúng người ta còn có thể kết hợp các phương pháp hình thức với nhau hoặc với các

phương pháp bán hình thức (sẽ được trình bầy ở phần sau) để mô tả đầy đủ và chính

xác về hệ thống cần xây dựng

a Timed CSP (Communicating Sequential Processes)

Timed CSP là ngôn ngữ đặc tả mở rộng về tính thời gian thực của CSP Nó là

một ngôn ngữ đặc tả hình thức để mô hình và phân tích các hành vi điều khiển động

của các hệ thống song song và phân tán Trong Time CSP yếu tố thời gian thực được

mô hình bởi các số thực dương

Một số tiến trình mô hình các mẫu hành vi của một hệ thống hay một thành

phần, các mẫu này sẽ quyết định việc điều khiển các hành động nội tại và môi trường

Các thao tác tiến trình cho phép phân tách các tiến trình theo một cấu trúc phân cấp

thành các tiến trình con tương tác với nhau Trong Timed CSP có hai cách khác nhau

để định nghĩa một tiến trình: thuật ngữ tiến trình và vị từ

Timed CSP là ngôn ngữ đặc tả mạnh để mô hình các hành vi động Tuy nhiên

nó không cung cấp bất kỳ cấu trúc nào để mô hình hành vi có thể chuyển đổi dữ liệu

Vì vậy, Timed CSP thường được sử dụng kết hợp với một ngôn ngữ đặc tả khác như

Z

b Đặc tả B

B là ngôn ngữ đặc tả được phát triển tại Bell Labs và xuất hiện khoảng năm

1969 Nó được áp dụng rộng rãi trong công nghiệp và trong các trường học để xây

dựng hệ thống đòi hỏi tính đúng đắn, chặt chẽ (bao gồm cả hệ thống nhúng - thời gian

thực)

Theo phương pháp B, những yêu cầu ban đầu được thể hiện thành tập các máy

trừu tượng và sử dụng cách tiếp cận hướng đối tượng trong các giai đoạn phát triển B

dựa trên tập hợp các ký hiệu đủ mạnh để thể hiện các mức độ từ đặc tả, thiết kế đến

thực hiện hệ thống Nó cũng cung cấp các công cụ để kiểm tra cú pháp, kiểm tra mô

hình, chứng minh và các công cụ sinh mã

c Đặc tả Z

Một đặc tả viết trong Z là sự trộn lẫn của các câu lệnh toán học, hình thức, với

các văn bản giải thích phi hình thức Phần mô tả hình thức: cho một số mô tả chính

xác, khoa học của hệ thống Còn phần phi hình thức để làm tài liệu

Thành phần hình thức của Z sử dụng lý thuyết tập hợp quen thuộc (lý thuyết tập

hợp có phân loại) Đặc biệt hơn nữa, đặc tả Z sử dụng các sơ đồ cho phép nhóm các

đối tượng đặc tả lại thành các bộ phận

Đặc tả Z có thể được ứng dụng vào tất cả các pha của vòng đời phần mềm Và

kinh nghiệm đã chỉ ra rằng việc xây dựng một mô hình toán học cho hệ thống như Z sẽ

mạng lại lợi ích to lớn trong qúa trình phát triển phần mềm Hiện nay có một số công

cụ hỗ trợ Z như CICS của IBM, Inmos T800 của Transputer, …

d ObjectZ và TCOZ (RT-Z) (tích hợp của ObjectZ và timed CSP)

Cốt lõi của ObjectZ là ngôn ngữ Z ObjectZ mở rộng đặc tả theo hướng đối

tượng cho phép đặc tả có thể tạo ra các lớp và tính kế thừa các lớp ObjectZ được mở

rộng để đặc tả các hệ thống có tính liên tục và thời gian thực

RT-Z là kết hợp của ngôn ngữ Z và Timed CSP cho phép đặc tả các hệ thống

thời gian thực Ngôn ngữ Z đặc tả sâu tính cấu trúc còn Timed CSP lại biểu diễn rất tốt

cho các hệ thống thời gian thực

e Mạng Petri (Pertrinet)

Năm 1962 Carl Adam Petri đã công bố phương pháp mô hình hình họa tác vụ

hay quá trình theo sự phụ thuộc nhân quả đã được phổ cập rộng rãi và được biết tới

như ngày này với tên gọi là mạng Petri Ngôn ngữ đặc tả hình thức nổi tiếng về tính

hiệu quả

Mạng Petri được sử dụng phổ biến để biểu diễn mô hình và phân tích các hệ

thống có sự cạnh tranh trong quá trình hoạt động Một hệ thống có thể hiểu là một tổ

hợp của nhiều thành phần và mỗi thành phần thì đều có các thuộc tính Các thuộc tính

đó có thể thay đổi và được đặc trưng bởi các biến trạng thái Một chuỗi các trạng thái

sẽ mô tả quá trình động của một hệ thống Mạng Petri thực sự là một giải pháp mô tả

hệ thống động với các sự kiện rời rạc tác động làm thay đổi trạng thái của các đối

tượng trong hệ thống theo từng điều kiện cụ thể trạng thái của hệ thống Mạng Petri

được thiết lập dựa trên 3 thành phần chính: (1) Các điều kiện, (2) các sự kiện, và (3)

quan hệ luồng Các điều kiện có thể là thoả mãn hoặc không thoả mãn Các sự kiện là

có thể xảy ra hoặc không Và quan hệ luồng mô tả điều kiện của hệ trước khi sự kiện

xảy ra Các điều kiện đòi hỏi phải thoả mãn để một sự kiện xảy ra hoặc chuyển trạng

thái thực hiện thì được gọi là điều kiện trước (precondition) Các điều kiện mà được

thoả mãn khi một sự kiện nào đó xảy ra thì được gọi là điều kiện sau (postcondition)

2.3.2 Phương pháp đặc tả bán hình thức (semi-formal method)

Các phương pháp bán hình thức là các kỹ thuật đặc tả, phát triển và kiểm định

các hệ thống phần mềm và phần cứng theo cấu trúc sử dụng các thành phần đồ hoạ và

được ứng dụng rộng rãi trong phân tích thiết kế phần mềm nói chung bao gồm cả các

hệ thống nhúng, thời gian thực như SDL, UML Cách tiếp cận này giúp cho người

phát triển mô hình hoá hệ thống một cách trực quan dễ hiểu và các bộ phận tham gia

phát triển hệ thống có thể hiểu và đóng góp được nhằm xác định đúng hệ thống cần

xây dựng Các phương pháp này được áp dụng tại tất cả các pha trong vòng đời phát

triển phần mềm

a Biểu đồ luồng dữ liệu (Data Flow Diagram)

Có nhiều cách mô tả thiết kế phần mềm, phụ thuộc vào thông tin gì được truyền

đạt Một phương pháp được sử dụng là biểu đồ luồng dữ liệu Biểu đồ luồng dữ liệu

chỉ ra mỗi tiến trình như là một khối (vòng) Những đường kẻ nối các khối chỉ ra các

thông tin được chuyển giữa các tiến trình Theo cách thiết kế này trước hết chúng ta sẽ

phân tích các yêu cầu của hệ thống và xác định các mô-đun chức năng, rồi sau đó tiến

hành vẽ biểu đồ theo luồng dữ liệu của các mô-đun chức năng đã phân tích, nhằm mục

đích xác định được tác vụ theo các ràng buộc chặt chẽ mà hệ thống nhúng đòi hỏi

Ví dụ hệ thống đồng hồ báo thức: có thể được chia làm 6 tác vụ như sau:

DisplayTask, TimebaseTask, ButtonTask, AlarmcontrolTask, AlarmtoneTask,

ErrorTask Hình 2.8 thể hiện biểu đồ luồng dữ liệu giữa các tác vụ trong hệ thống đồng

hồ báo thức

Hình 2.8 Biểu đồ luồng dữ liệu hệ thống đồng hồ báo thức

b Biểu đồ trạng thái (Statechart Diagram)

Biểu đồ trạng thái thể hiện từng trạng thái có thể có trong hệ thống và những

đầu vào, ra gây ra thay đổi thành trạng thái khác Như hình 2.9 thể hiện biểu đồ trạng

thái tổng quát, hệ thống chuyển từ trạng thái này sang trạng thái khác nhờ các trigger

Trong một hệ thống phức tạp hơn, từng đầu vào gây ra những thay đổi trạng thái được

thể hiện và chỉ rõ từ trạng thái cũ ra trạng thái mới Cách đặc tả này hữu dụng trong

Hình 2.9 Biểu đồ trạng thái

c Giả mã (Pseudo code)

Phương pháp tiếp theo là sử dụng giả mã để thiết kế phần mềm Bước đầu tiên

là mô tả lôgic và mô tả chức năng mức cao Danh sách liệt kê này mô tả bằng tiếng

anh chính xác những gì phần mềm sẽ làm Bước tiếp theo là đi vào giả mã thực nhưng

giả mã vẫn còn được mô tả dưới dạng tiếng anh có cấu trúc, đoạn text thêm vào mô tả

những cờ gì, biến gì và những loại phần tử khác được xử lý để thực hiện những chức

năng mô tả Điểm thuận lợi của phương pháp này là các mô tả chức năng có thể được

ghi ra và chi tiết được hoàn chỉnh trong quá trình thiết kế, cuối cùng được chuyển

thành giả mã

Những mô tả chức năng và giả mã hữu dụng cho những hệ thống đơn giản được

viết bởi một lập trình viên Nếu nhiều lập trình viên làm việc trên cùng một dự án và

đặc biệt là nếu nhiều bộ xử lý được sử dụng thì phải dùng một số phương tiện để mô tả

đầy đủ những thông tin được chuyển giữa các tiến trình hoặc các chức năng được thực

hiện bởi các lập trình viên Thông tin về phân chia thời gian cho các chức năng thời

gian thực là rất quan trọng Ví dụ, chức năng X phải được gọi trong Y mili giây của

chức năng Z hoặc là sẽ mất sự đồng bộ trong hoạt động Trong một hệ thống phức tạp,

có nhiều mức tài liệu là rất hữu dụng Những lược đồ khối tổng thể chỉ ra những dữ

liệu gì được truyền ra vào hệ thống, những lược đồ khác chỉ ra sự truyền thông giữa

các hệ thống nhỏ hoặc bảng mạch hoặc những chức năng chính của firmware và dùng

giả mã hoặc lược đồ trạng thái để mô tả từng chức năng hoạt động Ví dụ ở hình 2.10

là mô tả một phần mềm về bộ chuyển đổi giao thức đơn giản Hệ thống nhận dữ liệu từ

cổng tuần tự RS-232 từ một hệ thống chủ, thực hiện việc xử lý, lưu dữ liệu vào bộ đệm

và gửi nó cho một hệ thống thứ hai thông qua một giao tiếp khác Giao thức

XON/XOFF được sử dụng để điều khiển luồng dữ liệu:

Hình 2.10 Đặc tả theo giả mã

Phần mềm xử lý xung quanh vòng lặp này Hệ thống thực sự còn bao gồm một

số việc về kiểm tra lỗi và những công việc khác nhưng đã được loại bỏ để đơn giản

hoá mô tả Việc sử dụng giả mã cũng có những hạn chế nhất định như khó mô tả được

hệ thống lớn phức tạp và mỗi lần thêm một chức năng mới cho ứng dụng thì cần phải

xác định lại mô tả giả mã, ví dụ cách truyền tham số cho một hàm, gán các thanh ghi

để tính toán một biểu thức…Mỗi lần chuyển sang một nền phần cứng mới thì cần thực

hiện lại xây dựng mã chương trình cho phù hợp với kiến trúc bộ xử lý mới

d Thiết kế sử dụng UML

UML đã trở thành một phương pháp luận thiết kế phần mềm nhúng quan trọng

trong những năm gần đây [10][19] (ngoài ra còn có UML-Realtime một phương pháp

thiết kế kết hợp giữa UML và ngôn ngữ hướng đối tượng thời gian thực ROOM do

công ty Object time đưa ra) Có hai cách thông dụng để sử dụng công cụ thiết kế đó là:

như một bản đặc tả thiết kế ứng dụng để hướng dẫn viết mã chương trình hoặc như là

một phương tiện để sinh mã trực tiếp Việc sinh mã vẫn còn có những hạn chế và cần

nâng cao tính năng này do nhiều vấn đề riêng biệt đối với từng loại hệ thống không thể

thể hiện hết được Phương pháp phân tích thiết kế và lập trình hướng đối tượng cũng là

sợi dây xuyên suốt trong quá trình thiết kế sử dụng UML

Đối với UML có một đặc điểm thuận lợi là có thể xây dựng những trình biên

dịch mô hình cho các nền phần mềm khác nhau, như vậy là có thể sinh ra chương trình

chạy trên nhiều kiến trúc vi xử lý khác nhau tiết kiệm chi phí phát triển Một nền phần

mềm đơn giản là tập các công nghệ xác định cấu trúc phần mềm như cấu trúc dữ liệu,

cách truy cập dữ liệu, các luồng và tác vụ, cấu trúc bộ vi xử lý và định vi chương trình

Tất cả các chi tiết này được đưa vào trong bộ biên dịch mô hình để xác định vào một

nền phần cứng đích

Hình 2.11 Qui trình phát triển blueprint

Về ứng dụng nhúng thời gian thực, UML tập trung vào hỗ trợ cho việc mô hình

hoá cơ chế hoạt động song song, hành vi, truyền thông của các tác vụ và cho phép diễn

tả được những đặc tính định lượng của hệ thống thời gian thực (như thời hạn, giai

đoạn, mức ưu tiên,…) Ngoài ra, OMG đã đưa ra thêm bản mô tả (profile) dành cho

các hệ thống thời gian thực là bản profile về lập lịch, hiệu năng, thời gian (Scheduling,

Performace và Time) được ký hiệu là UML-SPT [23]

Bản profile UML–SPT xác định một tập các khái niệm thích hợp cho mô hình

hoá hệ thống thời gian thực nhằm mục đích tích hợp những ký hiệu được sử dụng bởi

các kỹ thuật phân tích hệ thống thời gian thực hiện có vào trong UML UML-SPT

được tổ chức thành hai phần chính: Thứ nhất là xác định tập các khái niệm chung làm

nền tảng cho định nghĩa các khái niệm phức tạp hơn đảm bảo mô hình hoá những đặc

tính thời gian thực Thứ hai là dựa trên những khái niệm đã được định nghĩa trước để

phân tích những hành vi thời gian thực của ứng dụng dựa trên UML

Phần đầu của SPT bao gồm ba gói con (hình 2.12):

những khái niệm chung về Resource và QualityOfService Nó cũng giới thiệu

những mô hình nhân quả để làm sáng tỏ khía cạnh động của hệ thống

những cơ chế liên quan đến thời gian như timer, clock …

những khái niệm cơ bản để đặc tả tính song song của ứng dụng

Hình 2.12 Cấu trúc của SPT profile

Phần tiếp theo của SPT tập trung vào các kỹ thuật phân tích hành vi thời gian

thực của ứng dụng dựa trên UML Trong phần này cung cấp các gói nhỏ hơn cho

những phân tích khác nhau như: gói phân tích khả năng lập lịch (Schedulability

Analysis) xác định những khuôn mẫu, nhãn, ràng buộc cho phân tích khả năng lập

lịch; tương tự như vậy gói phân tích hiệu năng (Performance Analysis) cũng cung cấp

những thứ đó để phân tích hiệu năng Các gói này đều sử dụng những khái niệm đã

được xác định trong profile về resource, concurrency và time như đã đề cập ở trên

Tóm lại, UML-SPT đưa ra tập những khuôn mẫu, nhãn và ràng buộc cho mô

hình hoá những ứng dụng thời gian thực ở mức cao, chi tiết Bản profile này cũng hình

thành một khung tốt cho xác định lại những khái niệm riêng biệt để giải quyết vấn đề

thời gian thực

2.4 Công cụ phát triển phần mềm nhúng

Người lập trình ứng dụng thường thực hiện công việc trên cùng một loại máy

tính mà ứng dụng chạy Ví dụ, viết chương trình chạy trên Window thì thường thực

hiện công việc lập trình trên máy chạy Window Việc sửa chữa, dịch, liên kết và gỡ lỗi

chương trình đều trên cùng một máy Điều này thay đổi khi xây dựng hệ thống nhúng

Thứ nhất, hầu hết hệ thống nhúng đều có những phần cứng chuyên biệt để gắn với các

bộ cảm ứng hoặc để điều khiển, và chỉ có cách duy nhất là thử phần mềm trên phần

cứng chuyên biệt đó Thứ hai, các hệ thống nhúng thường sử dụng các bộ vi xử lý mà

chưa bao giờ được sử dụng trên máy trạm Rõ ràng là chương trình không thể tự nhiên

dịch ra được các chỉ thị phù hợp với bộ vi xử lý lựa chọn cho hệ thống và chương trình

cũng không thể tự nhiên nhẩy vào trong bộ nhớ của hệ nhúng để thực hiện được Phần

Các máy chủ và đích

Trong thế giới nhúng, có nhiều lý do để thực hiện những công việc lập trình

ứng dụng trên một hệ thống khác với hệ thống mà chương trình chạy Hệ thống phát

triển có thể không có bàn phím, màn hình, ổ đĩa và các thiết bị ngoại vi cần thiết cho

lập trình Do đó, hầu hết công việc lập trình cho hệ thống nhúng được thực hiện trên

một máy tính (host) có cài đặt các công cụ lập trình Chỉ sau khi chương trình được

viết, biên dịch và liên kết nó mới được chuyển tới máy đích

Trình biên dịch chéo

Hầu hết hệ thống máy tính để bàn được dùng như là các host cùng với bộ biên

dịch, asssembler, bộ liên kết … để xây dựng chương trình chạy trên host Những công

cụ này được gọi là những công cụ địa phương Bộ biên dịch trên hệ thống Window NT

được dựa trên kiến trúc của Intel Pentium, chúng được sử dụng để xây dựng những

chương trình chạy trên nền tảng Intel Pentium Bộ biên dịch này có thể hữu dụng khi

chúng ta dùng bộ vi xử lý Pentium để xây dựng hệ thống, nhưng nó hoàn toàn không

có ích lợi gì nếu như chúng ta sử dụng một bộ xử lý đích khác, ví dụ như: Motorola

68000, MIPS hay Zilog Z80 Những bộ xử lý mới hơn này không hiểu được các chỉ thị

nhị phân của Pentium Nhưng trong trường hợp này thì các chỉ thị Pentium là cái mà

bộ biên dịch sinh ra Vậy nên những gì chúng ta cần là một bộ biên dịch chạy trên hệ

thống host nhưng có thể sinh ra những chỉ thị nhị phân mà bộ xử lý đích trên hệ thống

nhúng có thể hiểu được Những bộ biên dịch như vậy được gọi là bộ biên dịch chéo

Về môi trường lý tưởng, nếu viết một chương trình bằng C hoặc C++, ta có thể

biên dịch trên bộ biên dịch địa phương và chạy trên host, thì cũng có thể dịch chương

trình thông qua bộ biên dịch chéo và có được chương trình chạy trên môi trường đích

Thật không may, điều này không đúng như vậy thậm chí là trong lý thuyết Trong lý

thuyết, một chương trình biên dịch không có lỗi với bộ biên dịch địa phương cũng biên

dịch không có lỗi trên bộ biên dịch chéo Những qui tắc xây dựng chương trình đã

được xác định trong bộ biên dịch Tuy nhiên, trong thực tế ta sẽ thấy rằng những cấu

trúc được chấp nhận ở một trình biên dịch này có thể sẽ không được chấp nhận ở trình

biên dịch khác Chúng ta sẽ không gặp vấn đề với những câu lệnh như if, switch hay

vòng do loop; nhưng lỗi sẽ xảy ra nếu chúng ta sử dụng hàm mà không khai báo hoặc

sử dụng một kiểu khai báo cũ Các nhà cung cấp bộ biên dịch vẫn đang làm việc để tối

thiểu hoá vấn đề này nhưng nó vẫn đang tồn tại

Thực tế là nếu chương trình làm việc tốt trên host và được biên dịch thành công

với bộ biên dịch chéo nhưng cũng không có gì đảm bảo là nó sẽ hoạt động trên hệ

thống đích Những vấn đề thường gặp phải khi chuyển một chương trình C từ nền này

sang nền khác như những biến được khai báo kiểu int có thể có 1 kích cỡ trên host

nhưng khi đưa sang máy đích lại có một kích cỡ khác

Bởi vì những điều này nên chúng ta mong muốn có những cảnh báo từ bộ biên

dịch chéo Ví dụ, nếu mã gán một con trỏ void cho một phần tử int, bộ biên dịch địa

phương có thể hiểu hai thực thể đó là cùng một kích thước và không đưa ra cảnh báo

Ngược lại bộ biên dịch chéo có thể cảnh báo rằng int và con trỏ void không cùng kích

thước trên hệ thống đích

Bộ Assembler chéo và chuỗi công cụ

Một công cụ khác chúng ta sẽ cần khi xây dựng chương trình với ngôn ngữ

Assembler là bộ Assember chéo Tức là bộ Assembler chạy trên host nhưng sinh ra

các chỉ thị nhị phân thích hợp với máy đích tương tự như với bộ biên dịch chéo Hình

2.13 dưới đây mô tả qui trình xây dựng phần mềm cho hệ thống nhúng Chúng ta có

thể thấy những file đầu ra của công cụ này sẽ trở thành file đầu vào của công cụ tiếp

theo do đó các công cụ này phải tương thích với nhau và hình thành một chuỗi công cụ

(tool chain) cho phát triển ứng dụng

Bộ liên kết/ bộ định vị (Linker/Locator) cho phần mềm nhúng

Công việc của bộ biên dịch chéo cũng giống như bộ biên dịch địa phương là

đọc một file mã nguồn và sinh ra một object file phù hợp cho bộ liên kết Một bộ liên

kết cho hệ nhúng sẽ làm những công việc khác với bộ liên kết địa phương do bản chất

hai chương trình khác nhau Bộ liên kết cho hệ thống nhúng thường gọi đến bộ định vị

hoặc bộ liên kết định vị Điểm khác nhau cơ bản giữa một bộ liên kết địa phương và

bộ định vị là ở chính các file mà chúng tạo ra Bộ liên kết địa phương tạo ra một file

trên ổ đĩa của hệ thống Host và nó được đọc bởi bộ loader của hệ điều hành khi người

sử dụng yêu cầu chạy chương trình Loader sẽ tìm tới đoạn bộ nhớ để nạp chương

trình và copy chương trình từ đĩa vào trong bộ nhớ trong và thực hiện một số xử lý

khác trước khi chạy chương trình Locator thì ngược lại, tạo ra một file và file đầu ra

này sẽ được copy vào hệ thống đích Sau đó nó sẽ phải tự thực thi (Chú ý rằng trong

hệ thống nhúng sẽ không có hệ điều hành tách biệt; locator sẽ gắn mã chương trình của

chúng ta với RTOS và sự kết hợp này được copy tới hệ thống đích chỉ trong một lần)

Trong hầu hết các hệ thống nhúng đều không có loader Khi locator thực hiện

xong file đầu ra của nó sẽ được copy vào hệ thống đích Do đó, locator phải biết được

vị trí chương trình nằm trong bộ nhớ và sắp đặt địa chỉ Và một vấn đề khác mà locator

cũng cần giải quyết đó là trong môi trường nhúng thì một số phần của chương trình

được kết thúc trong ROM và một số phần trong RAM

Đưa phần mềm nhúng vào trong hệ thống đích

Locator sẽ xây dựng một file mô tả ảnh của phần mềm đích và sau đó đưa file

đó lên hệ thống đích Có nhiều cách để thực hiện điều này:

Bộ lập trình PROM

Cách cổ điển là dùng file đó để tạo ra một ROM hoặc PROM do việc tạo ROM

chỉ thích hợp khi đã hoàn thành xây dựng phần mềm do chi phí cho công cụ xây dựng

ROM khá cao Để đưa chương trình vào PROM đòi hỏi một thiết bị được gọi là bộ lập

trình PROM Cái này phù hợp với có những thay đổi trong phần mềm hoặc trong khi

đang gỡ lỗi

Hình 2.13 Quá trình phát triển và biên dịch phần mềm nhúng

Việc đặt PROM vào một socket trên hệ thống đích thay vì hàn chặt nó vào mạch sẽ

tiện lợi hơn cho quá trình gỡ lỗi và thay đổi chương trình nếu như chúng ta tìm thấy lỗi

và cần xoá nội dung trong PROM Khi định sử dụng một bộ lập trình PROM thì cần

xem xét kỹ rằng bộ đó có thể hiểu được file đầu ra mà locator tạo ra

ROM Emulator

Một cách phổ biến khác cho việc đưa phần mềm vào hệ thống máy đích để gỡ

lỗi đó là sử dụng một thiết bị ROM emulator, một thiết bị dùng để thay thế ROM ở hệ

thống đích Emulator này sẽ có chức năng giống như ROM trên máy đích Tuy nhiên

ROM Emulator bao gồm một hộp điện tử lớn và một cổng tuần tự hoặc một kết nối

mạng để kết nối với host Phần mềm chạy trên host có thể gửi file được tạo ra bởi

locator cho ROM Emulator và thiết bị này hoạt động giống như ROM trên máy đích

2.5 Case study về thiết kế phần mềm nhúng

Đây là một ví dụ về phân tích và thiết kế hệ thống nhúng hướng đối tượng sử

dụng UML Hệ thống được đưa ra phân tích ở đây là máy ghi âm số (Digital Sound

Recorder) [14] Thiết kế sử dụng một bộ vi xử lý nhúng trong thiết bị và ngôn ngữ lập

trình C++

2.5.1 Phân tích yêu cầu

Máy ghi âm số là một thiết bị điện tử được thiết kế để ghi âm và nghe lại những

đoạn ghi âm trong máy Thông điệp được ghi âm bằng cách sử dụng một micro gắn

sẵn trong thiết bị và sau đó được lưu trữ trong bộ nhớ Người dùng có thể nghe lại

những thông điệp được ghi một cách dễ dàng tại bất cứ lúc nào thông qua một loa đặt

ở trước thiết bị Máy ghi âm số phải nhỏ, gọn, đẹp, dễ sử dụng, chạy tiết kiệm pin (pin

sạc)

Hình 2.14 thể hiện giao diện của thiết bị Đó là một thiết bị cầm tay, màn hình phẳng

với các nút bấm ở bề mặt

Hình 2.14 Hình dáng của thiết bị

Những đặc điểm chính của thiết bị:

hạn bởi bộ nhớ thiết bị

thức tắt khi người dùng bấm một phím bất kỳ hoặc tự tắt sau 60 giây

trên màn hình cũng có những chỉ dẫn rõ ràng về cách sử dụng và đang thực hiện

công việc gì

hết pin

chúng không sử dụng và sẽ hoạt động bình thường trở lại khi người dùng bấm

một phím

a Những sự kiện bên ngoài

Một hệ thống nhúng luôn phải tương tác với môi trường của nó Trong giai

đoạn đầu tiên của quá trình phân tích, chúng ta có thể coi hệ thống như là một hộp đen

phản ứng lại với các yêu cầu và thông điệp từ môi trường Môi trường bao gồm các tác

nhân Mỗi tác nhân tương tác với hệ thống có mục đích khác nhau và trao đổi một tập

thông điệp khác nhau