THUYẾT TRÌNH HỆ THỐNG NHÚNG-CHƯƠNG 11-XÁC ĐỊNH CHƯƠNG TRÌNH KHỞI TẠO VÀ TÀI LIỆU LIÊN QUAN ĐẾN THIẾT KẾ HỆ THỐNG NHÚNG

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP. HỒ CHÍ MINH
KHOA CÔNG NGHỆ ĐIỆN TỬ


THUYẾT TRÌNH
HỆ THỐNG NHÚNG
Đề tài:
Chương 11: XÁC ĐỊNH CHƢƠNG TRÌNH KHỞI TẠO VÀ
TÀI LIỆU LIÊN QUAN ĐẾN THIẾT KẾ HỆ THỐNG NHÚNG

GVHD: ThS. Phan Vinh Hiếu
Danh sách nhóm:
1. Trần Nhật Quang 09079551
2. Nguyễn Vũ Châu 09090541
3. Bùi Tấn Vang 09083181
4. Phạm Thế Linh 09193371
5. Trần Văn Hƣng 09218441
6. Nguyễn Hồng Phúc 09215081

TP. Hồ Chí Minh, tháng 6 năm 2012


2

Chương 11
XÁC ĐỊNH CHƢƠNG TRÌNH KHỞI TẠO
VÀ TÀI LIỆU LIÊN QUAN ĐẾN THIẾT KẾ HỆ THỐNG NHÚNG

Trong Chƣơng này
- Xác định các giai đoạn tạo ra một kiến trúc hệ thống nhúng.

- Giới thiệu vòng thƣơng mại kiến trúc và ảnh hƣởng của nó đến kiến trúc.
- Mô tả cách khởi tạo một kiến trúc và các tài liệu liên quan.
- Giới thiệu cách đánh giá và đối chiếu một thiết kế kiến trúc.

Chƣơng này cung cấp cho ngƣời đọc một số quy trình kỹ thuật thực tế hữu ích đƣợc
ứng dụng trong những năm qua. Xác định sơ đồ và kiến trúc của nó, giai đoạn phát
triển là giai đoạn khó khăn nhất và quan trọng nhất của toàn bộ vòng phát triển. Hình
11-1 cho thấy các giai đoạn phát triển khác nhau theo quy định của Thiết kế hệ thống
nhúng và mô hình phát triển. [11-1]

Khái niệm về
sản phẩm













Hình 11-1: Thiết kế Hệ thống nhúng và mô hình phát triển
Phân tích sơ bộ
các yêu cầu
Xây dựng phiên bản
kiến trúc

Tạo ra các
thiết kế kiến trúc
Cung cấp phiên bản
kiến trúc cuối cùng
Phát triển [thực hiện]
hệ thống
Xem xét và thử
nghiệm hệ thống
Phân phối & bảotrì
hệ thống
Cung cấp phiên
bản kiến trúc
Giai đoạn1:Tạo Kiến trúc
Kết hợp thông
tin phản hồi
Xem xét & lấy
thông tin phản hồi
Giai đoạn2:Thực hiện kiến trúc
Giai đoạn3:Kiểm tra hệ thống
Giai đoạn4:Duy trì hệ thống
Kết hợp thông
tin phản hồi
3


Mô hình này chỉ ra rằng quy trình thiết kế một hệ thống nhúng và đƣa nó ra thị trƣờng
có bốn giai đoạn:
- Giai đoạn 1: Tạo kiến trúc, là quá trình lập kế hoạch thiết kế hệ thống nhúng.
- Giai đoạn 2: Thực hiện kiến trúc, là quá trình phát triển hệ thống nhúng.
- Giai đoạn 3: Kiểm tra hệ thống, là quá trình thử nghiệm các vấn đề của hệ thống

nhúng và sau đó giải quyết những vấn đề này.
- Giai đoạn 4: Duy trì hệ thống, là quá trình triển khai hệ thống nhúng vào các ứng
dụng và hỗ trợ kỹ thuật cho ngƣời sử dụng thiết bị.
Mô hình này cũng chỉ ra rằng giai đoạn trọng nhất là giai đoạn 1, tạo ra kiến trúc. Ở
giai đoạn này, không có bo mạch nào đƣợc thiết lập và không có phần mềm nào đƣợc
mã hoá. Đó là việc tập trung điều tra, thu thập thông tin về thiết bị đang đƣợc phát
triển, tìm hiểu những tài liệu tìm đƣợc. Nếu việc xác định kiến trúc của hệ thống đƣợc
chuẩn bị tốt, xác định đƣợc các yêu cầu, sự hiểu biết về những rủi ro, thì các giai đoạn
phát triển, thử nghiệm và duy trì các thiết bị sẽ đơn giản hơn, nhanh hơn và rẻ hơn.
Điều này, tất nhiên yêu cầu các kỹ sƣ phải có các kỹ năng cần thiết.
Trong thời gian ngắn, nếu giai đoạn 1 đƣợc thực hiện tốt, thì thời gian dành cho
việc xử lí các yêu cầu không liên quan đến ứng dụng sẽ ít hơn, nếu không lỗi gặp phải
sẽ nhiều hơn,và do đó, phải làm việc nhiều hơn.
Thông tin thu thập có thể không chính xác, chi tiết kỹ thuật có thể thay đổi, vì vậy các
nhà thiết kế phải có sự chuẩn bị trƣớc để giải quyết các yêu cầu phát sinh và các lỗi
mới phát sinh mới có thể đƣợc xác định và giải quyết ngay lập tức. Từ đó, quá trình
phát triển sản phẩm sẽ giảm bớt áp lực, giảm bớt thời gian và chi phí, hao phí cũng
thấp hơn. Quan trọng nhất, Dự án xuất phát từ một quan điểm kỹ thuật, gần nhƣ chắc
chắn thực hiện sẽ thành công.
11.1 Tạo một kiến trúc hệ thống nhúng
Một số phƣơng pháp công nghiệp có thể đƣợc áp dụng trong thiết kế kiến trúc của một
hệ thống nhúng nhƣ : quy trình phát triển phần mềm (Rational Unified Process RUP),
phƣơng pháp thiết kế thuộc tính (Attribute Driven Design ADD), lập trình hƣớng đối
tƣợng (the object-oriented process OOP) và mô hình điều khiển kiến trúc ( the model
driven architecture MDA ) và một vài phƣơng pháp khác nữa. Quá trình này bao gồm
sáu giai đoạn, mỗi giai đoạn xây dựng dựa trên kết quả của giai đoạn trƣớc đó. Các
giai đoạn này là :

4

1. Giai đoạn 1.Có một cơ sở kĩ thuật vững chắc
2. Giai đoạn 2. Hiểu biết về vòng thƣơng mại kiến trúc
3. Giai đoạn 3. Xác định mô hình kiến trúc và các mô hình tham khảo
4. Giai đoạn 4. Tạo các hệ thống kiến trúc
5. Giai đoạn 5. Tài liệu về kiến trúc
6. Giai đoạn 6. Phân tích và đánh giá kiến trúc
Sáu giai đoạn này phục vụ để nghiên cứu các phƣơng pháp thiết kế kiến trúc trong
công nghiệp. Tuy nhiên, nếu thời gian và nguồn lực hạn chế mà phải nghiên cứu nhiều
đề án kiến trúc khác nhau trƣớc khi bắt đầu thiết kế một sản phẩm chính thức, thì sáu
giai đoạn này có thể đƣợc sử dụng trực tiếp nhƣ là một mô hình đơn giản để tạo ra
một kiến trúc. Phần còn lại của chƣơng này sẽ cung cấp thêm chi tiết về sáu giai đoạn
này.
Tác giả lưu ý: Cuốn sách này cố gắng cung cấp một quy trình đơn giản để tạo ra một
hệ thống nhúng dựa trên một số phương pháp phức tạp hơn trong công nghiệp. Tác
giả cố gắng tránh các phương pháp phức tạp đó bằng cách sử dụng rất nhiều thuật
ngữ cụ thể, bởi vì các thuật ngữ theo cách hiểu khác nhau có thể có định nghĩa khác
nhau, cũng như các thuật ngữ khác nhau có thể có ý nghĩa giống hệt nhau.
Giai đoạn 1: Cơ sở kỹ thuật vững chắc
Giai đoạn 1 là các kiến thức trình bày trong chƣơng 2 đến chƣơng 10 của cuốn sách
này. Một kỹ sƣ hoặc lập trình viên sẽ phát triển và làm việc với tất cả các thành phần
của một hệ thống nhúng, bao gồm tất cả các yếu tố có thể đƣợc thực hiện trong một hệ
thống nhúng. Điều này bao gồm các hoán vị của cả phần cứng và phần mềm, hoặc có
thể là đại diện trong các mô hình hệ thống nhúng, chẳng hạn nhƣ mô hình Von-
Neumann, mô hình này cho thấy các thành phần chính có thể đƣợc tìm thấy trên một
board nhúng (đƣợc hiển thị trong hình11-2a) hoặc các thành phần phức tạp hơn có thể
có thể tồn tại trong phần mềm lớp hệ thống (thể hiện trong hình 11-2b).

5

Hình 11-2a: Von-Neumann và mô hình Hệ thống nhúng







Hình lớp11-2b: Lớp phần mềm hệ thống và mô hình sơ đồ hệ thống nhúng


Sơ đồ Hệ thống nhúng
Điều khiển sử dụng và thao tác dữ liệu
Bộ xử lí trung tâm
CPU

Bộ nhớ
Dữ liệu vào
Dữ liệu ra
Dữ liệu từ CPU hay thiết bị đầu vào lƣu trữ
trong bộ nhớ cho đến khi một CPU hoặc thiết bị
đầu ra nhận đƣợc yêu cầu xử lí.
5 thành phần hệ thống thƣờng
Kết nối qua Bus
Bộ nhớ
Truyền dữ liệu ra hệ thống nhúng
Truyền dữ liệu vào hệ thống nhúng
Dữ liệu vào
Dữ liệu ra
Lớp phần cứng
Lớp phần mềm hệ thống
Lớp phần cứng
Lớp phần mềm hệ thống
Lớp phần cứng
Lớp phần mềm hệ thống
Phần cứng
Phần mềm lớp hệ thống
Phần mềm lớp ứng dụng
Lớp hƣớng thiếtbị
Lớp phần mềm
ứngdụng
Lớp trung gian
Lớp phần mềm
ứngdụng
Lớp hƣớng thiết bị
Lớp phần mềm

ứngdụng
Lớp hƣớng thiết bị
Lớp điều hành
6

Giai đoạn 2: Hiểu biết về ABCs (Architecture Business Cycles : vòng thƣơng
mại kiến trúc) của hệ thống nhúng
Vòng thƣơng mại Kiến trúc (ABC) [11-2] của một thiết bị nhúng, đƣợc hiển thị
trong hình 11-3, nói về ảnh hƣởng của vòng đến kiến trúc của một hệ thống nhúng và
các ảnh hƣởng này ảnh hƣởng đến hệ thống nhúng tùy thuộc môi trƣờng- nơi mà nó
đƣợc phát triển. Các kiến thức cơ bản của hệ thống nhúng có nhiều loại khác nhau,
nhƣng chúng có cùng ảnh hƣởng để tạo ra các yêu cầu của hệ thống, các yêu cầu lần
lƣợt tạo ra các kiến trúc, sau đó kiến trúc đƣợc sản xuất trong hệ thống và kết quả là
chƣơng trình cung cấp các yêu cầu và các yêu cầu này có khả năng xuất hiện trong
việc tổ chức các thiết kế nhúng trong tƣơng lai.

Mô hình này cũng cho thấy rằng, dù sao đi nữa thì kiến trúc không đƣợc thiết
kế bởi các yêu cầu kỹ thuật đơn lẻ. Ví dụ, cùng một loại hệ thống nhúng, chẳng hạn là
điện thoại di động hoặc tivi, với cùng một yêu cầu kĩ thuật nhƣng đƣợc thiết kế bởi
các nhóm thiết kế khác nhau, nên có kiến trúc khác nhau và đƣợc kết hợp sản xuất bởi
các bộ vi xử lý, hệ điều hành khác nhau. Một kỹ sƣ nhận ra điều này từ đầu sẽ có
nhiều lợi thế hơn trong việc tạo ra kiến trúc cho một hệ thống nhúng. Nếu một kỹ sƣ
chịu trách nhiệm thiết kế một hệ thống nhúng mà xác định, hiểu và tham gia các cuộc
7

hội thảo khác nhau nói về bản thiết kế lúc bắt đầu một dự án, điều này sẽ làm giảm
khả năng có những ý kiến thay đổi thiết kế hoặc là sau khi mất rất nhiều thời gian, tiền
bạc, công sức và nỗ lực phát triển kiến trúc phải hủy bỏ để làm lại từ đầu.
Các bƣớc của giai đoạn 2 bao gồm:
- Bƣớc 1. Hiểu rằng ảnh hƣởng của vòng ABC đến hệ thống nhúng và những ảnh

hƣởng này không chỉ giới hạn trong ngành kĩ thuật.
- Bƣớc 2. Xác định tất cả các ảnh hƣởng cụ thể của vòng ABC về thiết kế, bao gồm
kỹ thuật, thƣơng mại, chính trị và xã hội.
- Bƣớc 3. Tham gia các buổi hội thảo khác nhau càng sớm càng tốt, phát triển và thu
thập các yêu cầu của hệ thống.
- Bƣớc 4. Xác định phần cứng cần thiết hoặc các yếu tố phần mềm có thể đáp ứng yêu
cầu thu thập.
Trang trƣớc giới thiệu chi tiết các bƣớc 1 và 2, các phần tiếp theo của chƣơng này sẽ
thảo luận cụ thể hơn các bƣớc 3 và 4.
Thu thập yêu cầu
Khi danh sách các yếu tố ảnh hƣởng đã đƣợc xác định, thì yêu cầu về kiến trúc của hệ
thống sẽ đƣợc thu thập. Theo đó, thông tin thu đƣợc từ các yếu tố ảnh hƣởng khác
nhau có thể khác nhau, tùy thuộc vào từng dự án, thông tin có đƣợc qua truyền miệng
- điều này không đƣợc khuyến khích.
Bất kể phƣơng pháp nào đƣợc sử dụng cho các yêu cầu thu thập, điều quan trọng cần
nhớ là phải xác định thông tin cần thu thập có đƣợc từ văn bản hoặc tài liệu nào,
không có phân biệt về vấn đề hình thức và thông tin đó nên đƣợc lƣu lại. Khi câu lệnh
có yêu cầu sẽ làm giảm xác suất nhầm lẫn, bởi vì tài liệu bằng văn bản có thể đƣợc
tham chiếu để giải quyết các vấn đề liên quan.
Các loại thông tin phải đƣợc thu thập bao gồm các yêu cầu chức năng và phi chức
năng của hệ thống. Do sự đa dạng của các hệ thống nhúng, điều khó khăn trong cuốn
sách này là cung cấp một danh sách các yêu cầu chức năng có thể áp dụng cho tất cả
nhúng hệ thống. Mặt khác, yêu cầu phi chức năng có thể áp dụng cho một loạt các hệ
thống nhúng và sẽ đƣợc sử dụng trong chƣơng này ở các ví dụ sau. Hơn nữa, từ yêu
cầu phi chức năng thì một số yêu cầu chức năng có thể đƣợc khởi tạo. Điều này là cần
thiết cho những ngƣời không có yêu cầu chức năng cụ thể nào vào lúc bắt đầu của một
dự án và chỉ có một khái niệm chung chung về chức năng của các thiết bị có trong
thiết kế. Các phƣơng pháp cần thiết nhất cho sự hiểu biết về các yêu cầu phi chức
năng thông qua bảng phác thảo tính năng chung ABC và đƣợc sử dụng để “làm mẫu”.
Tính năng chung của bảng ABC là cho thấy ảnh hƣởng của các yêu cầu đến đặc điểm

của một thiết bị. Điều này có nghĩa rằng các yêu cầu phi chức năng của thiết bị này
dựa trên bảng phác thảo tính năng chung ABC. Trong thực tế, bởi vì hầu hết các hệ
thống nhúng thƣờng yêu cầu kết hợp một số tính năng chung của bảng phác thảo tính
năng ABC, nên nó có thể đƣợc sử dụng nhƣ là một điểm khởi đầu trong việc xác định
8

và lƣu lại yêu cầu hệ thống của bất kỳ hệ thống nhúng nào. Một số tính năng phổ biến
nhất của bảng phác thảo tính năng chung ABC đƣợc thể hiện trong bảng 11-1.
Bảng 11-1: Ví dụ về các tính năng bảng phác thảo tính năng ABC

9


Ảnh hƣởng
Tính năng
Mô tả
Kinhdoanh
( Bán hàng,
Marketing,
Điều hành
Quản lý,…)
Doanh số
Các thiết bị đƣợc bán nhƣ thế nào, có bán đƣợc hay
không, bán số lƣợng bao nhiêu, …
Thời gian đƣa
ra thị trƣờng
Các đặc trƣng kĩ thuật của thiết bị,….
Chi phí
Chi phí phát triển thiết bị là bao nhiêu, có thể bán
với số lƣợng bao nhiêu, đạt số lƣợng lớn nhất là

bao nhiêu, hỗ trợ kĩ thuật cho thiết bị trên thị
trƣờng nhƣ thế nào,…
Vòng đời
thiết bị
Các thiết bị tồn tại bao lâu trên thị trƣờng, thiết bị
sẽ sử dụng đƣợc bao lâu trong các lĩnh vực,
Mục tiêu
thị trƣờng
Chủng loại thiết bị, đối tƣợng khách hàng…
Lịch trình
Thiết bị đƣợc sản xuất khi nào, khi nào hoàn thành
và sẵn sàng để đƣợc triển khai ra thị trƣờng.
Khả năng
Xác định danh sách các tính năng thiết bị cần phải
có cho mục tiêu thị trƣờng, những việc làm cần
thiết khi vận chuyển từ nơi sản xuất, hiểu rõ tất cả
lỗi nghiêm trọng có thể xảy ra trong lúc vận chuyển
sản phẩm,…
Rủi ro
Các vụ kiện về tính năng thiết bị, trục trặc, phát
hành sản phẩm không đúng nhƣ dự kiến, không đáp
ứng mong đợi của khách hàng,…

Kỹ thuật

Hiệu suất
Các thiết bị hoạt động có đáp ứng nhu cầu ngƣời
dùng hay không, các yêu cầu có đƣợc thực hiện hay
không thông qua các vi xử lí,……
Thân thiện với

ngƣời dùng
Làm thế nào để sử dụng thiết bị một cách dễ dàng,
đồ họa có thú vị, hấp dẫn không,…
Khả năng
nâng cấp
Làm thế nào nó có thể nhanh chóng để sửa lỗi hay
nâng cấp,…
Khả năng
bảo mật
Có an toàn từ các đối thủ cạnh tranh, tin tặc,
virus…hay không,
Độ tin cậy
Liệu nó có xảy ra sự cố hoặc “treo” hay không,
những gì sẽ xảy ra nếu gặp sự cố hoặc bị “treo”,
những nguyên nhân có thể gây ra sự cố hoặc “treo”.
Tính di động
Làm thế nào để chạy các ứng dụng trên các phần
cứng khác nhau hoặc trên các hệ thống phần mềm
khác nhau,
10

Thử nghiệm
Hệ thống dễ dàng đƣợc thử nghiệm, những tính
năng có thể đƣợc thử nghiệm, thiết bị đƣợc thử
nghiệm nhƣ thế nào,……
Độ khả dụng
Các phần mềm hoặc phần cứng trong hệ thống có
sẵn sàng hoại động khi cần thiết, đó là uy tín của
các nhà cung cấp,
Tiêu chuẩn

(Xem Bảng Tiêu chuẩn Công nghiệp dƣới đây.)
Phụ lục
( Xem Bảng Tiêu chuẩn thƣơng mại dƣới đây )
Công nghiệp
Tiêu chuẩn
Tiêu chuẩn ngành công nghiệp (đƣợc giới thiệu
trong Chƣơng 2), có thể là tiêu chuẩn cuả một lĩnh
vực cụ thể (ví dụ, tiêu chuẩn truyền hình, tiêu
chuẩn thiết bị y tế, …) hay nói chung mục đích
tổng quát là tạo điểm chung của các thiết bị khác
nhau ( tiêu chuẩn ngôn ngữ lập trình, tiêu chuẩn kết
nối mạng, )
Tiêu chuẩn
chất lƣợng
Thử nghiệm
( Xem Bảng kỹ thuật ở trên)
Sẵn sàng
Khi độ khả dụng của hệ thốngđƣợc kiểm tra.
Phụ lục
(Xem Bảng công nghiệp ở trên.)
Các tính năng
(Xem Bảng thƣơng mại ở trên.)
Tiêu chuẩn bảo
đảm chất lƣợng
ISO 9000, ISO 9001. (Xem Bảng ngành công
nghiệp trên.)
Khách hàng
Chi phí
Chi phí sản xuất thiết bị là bao nhiêu, tốn bao nhiêu
chi phí để sửa chữa hoặc nâng cấp thiết bị,

Thân thiện
ngƣời dùng
(Xem Bảng kỹ thuật ở trên.)
Hiệu suất
(Xem Bảng kỹ thuật ở trên.)


11

Một công cụ hữu ích trong sự hiểu biết, nắm bắt, và mô hình hóa các yêu cầu
hệ thống thông qua việc sử dụng một hệ thống mẫu ban đầu, một mô hình vật lý chạy
có chứa một số kết hợp yêu cầu hệ thống. Một mẫu thử có thể đƣợc sử dụng để xác
định phần cứng và phần mềm các thành phần có thể đƣợc thực hiện trong thiết kế, và
chỉ ra bất kỳ rủi ro liên quan đến việc sử dụng các thành phần. Sử dụng một mẫu thử
nghiệm kết hợp với các tính năng chung ABC cho phép bạn xác định chính xác sớm
trong dự án giải pháp phần cứng và phần mềm sẽ là khả thi cho thiết bị đƣợc thiết kế.
Một mẫu thử có thể đƣợc phát triển từ đầu hoặc có thể đƣợc dựa trên hiện đang
đƣợc triển khai sản phẩm trên thị trƣờng, mà có thể là bất kỳ thiết bị tƣơng tự hoặc các
thiết bị phức tạp hơn bằng cách kết hợp các chức năng mong muốn. Bằng các phƣơng
pháp tại các nơi tiêu thụ khác có thể có những mong muốn xem và cảm nhận ngay cả
khi các ứng dụng không phải là những gì bạn đang tìm kiếm. Ví dụ, nếu bạn muốn
thiết kế một thiết bị y tế cầm tay không dây cho các bác sĩ, ngƣời tiêu dùng PDAs
(hiển thị Hình 11-4) đã đƣợc triển khai thành công vào thị trƣờng có thể đƣợc nghiên
cứu và điều chỉnh để hỗ trợ các yêu cầu và kiến trúc hệ thống của thiết bị y tế.



Khi so sánh các sản phẩm của bạn để thiết kế tƣơng tự đã có trên thị trƣờng,
cũng nhận thấy khi những gì đã đƣợc thông qua trong thiết kế là không nhất thiết phải
là giải pháp kỹ thuật tốt nhất cho sản phẩm đó. Hãy nhớ rằng, có thể có vô số lý do

đặc trƣng, từ đặc trƣng ảnh hƣởng, một phần cứng cụ thể hoặc thành phần phần mềm
đƣợc thực hiện.
Một số trong những lý do chính để xem xét các giải pháp tƣơng tự là để tiết
kiệm thời gian và tiền bạc bằng bộ gom, ý tƣởng về những gì là khả thi, những vấn đề
hoặc hạn chế có liên quan với một giải pháp đặc biệt, và nếu kỹ thuật mẫu thử nghiệm
là một ghép hợp lý, sự hiểu biết tại sao đó là trƣờng hợp. Nếu có thực sự là không có
thiết bị trên thị trƣờng phản ánh bất kỳ yêu cầu của hệ thống, bằng cách sử dụng một
bảng tham khảo có sẵn và phần mềm hệ thống có sẵn là một phƣơng pháp nhanh
12

chóng để tạo ra mẫu thử của riêng bạn. Bất kể mẫu thử đƣợc tạo ra nhƣ thế nào, nó là
một công cụ hữu ích trong việc mô hình hóa và phân tích thiết kế và hành vi của một
kiến trúc tiềm năng.
Suy ra phần cứng và phần mềm từ các yêu cầu
Sự hiểu biết và áp dụng các yêu cầu để lấy đƣợc phần cứng và phần mềm khả
thi
các giải pháp cho một thiết kế đặc biệt có thể đƣợc thực hiện thông qua:
1. Xác định một tập hợp các bản phác thảo yêu cầu.
2. Phác thảo chiến thuật cho mỗi bản có thể đƣợc sử dụng để mang lại những
mong muốn hệ thống phản ứng.
3. Sử dụng chiến thuật nhƣ kế hoạch chi tiết cho những gì chức năng là cần
thiết trong thiết bị, và sau đó lấy đƣợc từ một danh sách các phần cứng cụ thể và các
yếu tố phần mềm có chứa chức năng này.
Nhƣ thể hiện trong hình 11-5, phác thảo một kịch bản có nghĩa là xác định:
 các nguồn tác nhân kích thích bên ngoài và nội bộ tƣơng tác với hệ thống
nhúng
 các hành động và các sự kiện, hoặc các tác nhân kích thích, gây ra bởi các
nguồn tác nhân kích thích.
 các môi trƣờng hệ thống nhúng là trong khi có tác nhân kích thích diễn
ra,chẳng hạn nhƣ trong lĩnh vực áp suất bình thƣờng, trong nhà máy bị áp suất

cao, ngoài trời tiếp xúc với nhiệt độ cực đoan, trong nhà.
 các yếu tố của hệ thống nhúng có thể bị ảnh hƣởng bởi các tác nhân kích thích,
cho dù nó là toàn bộ hệ thống hoặc phần cứng hoặc phần tử phần mềm bên
trong nhƣ bộ nhớ, bộ xử lý tổng thể, hoặc dữ liệu.
 mong muốn hệ thống phản ứng với tác nhân kích thích, trong đó phản ánh một
hoặc nhiều điều kiện của hệ thống
 làm thế nào hệ thống phản ứng có thể đƣợc xác định, có nghĩa là làm thế nào
để chứng minh hệ thống nhúng đáp ứng các yêu cầu.
Sau khi phác thảo các trƣờng hợp khác nhau, các chiến thuật sau đó có thể đƣợc
định nghĩa mang lại mong muốn hệ thống phản ứng. Những chiến thuật này có thể
đƣợc sử dụng để xác định loại chức năng cần thiết trong thiết bị. Đây là một số ví dụ
chứng minh nhƣ thế nào phần cứng và phần mềm thành phần có thể đƣợc bắt nguồn từ
yêu cầu phi chức năng dựa trên hiệu suất, an toàn, và các khả năng kiểm tra chung
tính năng ABC.
13





Ví dụ 1: công năng
Hình 11-6a là một trong những trƣờng hợp có thể cho một yêu cầu thực hiện dựa trên.
Trong ví dụ này, các nguồn tác nhân kích thích có thể ảnh hƣởng đến hoạt động là
nguồn nội bộ và bên ngoài hệ thống nhúng. Những nguồn tác nhân kích thích có thể
tạo ra một thời gian và sự kiện định kỳ không đồng bộ. Theo trƣờng hợp này, môi
trƣờng trong đó những sự kiện xảy ra khi ở tình trạng bình thƣờng đến một mức độ
cao của dữ liệu hệ thống nhúng để xử lý. Các nguồn tác nhân kích thích tạo ra sự kiện
tác động đến hiệu suất của thiết bị nhúng, ngay cả nếu nó là chỉ có một hoặc một vài
yếu tố cụ thể trong hệ thống trực tiếp điều khiển bằng tay bởi các sự kiện. Điều này là
bởi vì thƣờng bất kỳ hiện tƣợng tắc ngẽn trong hệ thống đƣợc cảm nhận bởi ngƣời sử

dụng nhƣ là một vấn đề hiệu suất với toàn bộ hệ thống.
Trong trƣờng hợp này này, một hệ thống mong muốn phản ứng là cho các thiết bị để
xử lý và phản ứng giai đoạn một cách kịp thời, một chỉ số có thể là hệ thống đáp ứng
việc thực hiện mong muốn yêu cầu. Để chứng minh rằng hiệu suất của hệ thống nhúng
đáp ứng cụ thể thực hiện dựa trên yêu cầu, hệ thống phản ứng có thể đƣợc đo và xác
minh thông qua, độ trễ hay mất mát dữ liệu đáp ứng các biện pháp hệ thống.



14





Với trƣờng hợp hiệu suất thể hiện trong hình 11-6a, một phƣơng pháp mà theo
đó để mang lại sự hệ thống phản ứng mong muốn là để kiểm soát khoảng thời gian mà
các tác nhân kích thích đƣợc xử lý và phản ứng tạo ra. Trong thực tế, bằng cách xác
định các biến cụ thể tác động đến khoảng thời gian, sau đó bạn có thể xác định chiến
thuật cần thiết để kiểm soát các biến này. Các chiến thuật sau đó có thể đƣợc sử dụng
xác định các yếu tố cụ thể trong một kiến trúc sẽ thực hiện các chức năng chiến thuật
để cho phép để thực hiện mong muốn của thiết bị.
Ví dụ, thời gian đáp ứng, một phản ứng hệ thống biện pháp trong trƣờng hợp
này bị ảnh hƣởng bởi sẵn có và sử dụng các nguồn tài nguyên trong một thiết bị. Nếu
có rất nhiều tranh cãi giữa nhiều sự kiện mà muốn truy cập vào cùng một tài nguyên,
chẳng hạn nhƣ các sự kiện có để ngăn chặn và chờ đợi cho các sự kiện khác để hoàn
thành bằng cách sử dụng một nguồn tài nguyên, thời gian chờ đợi cho nguồn tài
nguyên ảnh hƣởng đến thời gian đáp ứng. Nhƣ vậy, một chiến thuật quản lý nguồn tài
nguyên đƣợc hiển thị trong hình 11-6b phân xử và quản lý các yêu cầu của sự kiện
cho phép sử dụng công bằng và tối đa các nguồn lực có thể đƣợc sử dụng để giảm thời

gian phản ứng, và tăng hiệu suất của hệ thống.
15






Một lịch trình, chẳng hạn nhƣ tìm thấy trong một hệ điều hành, là một ví dụ
của một phần tử phần mềm cụ thể mà có thể cung cấp chức năng quản lý tài nguyên.
Vì vậy, nó là hệ điều hành hệ thống với các thuật toán lập lịch trình mong muốn đƣợc
nguồn gốc cho các cấu trúc trong ví dụ này. Trong ngắn hạn, ví dụ này chứng minh
rằng tác nhân kích thích (sự kiện) và một mong muốn hệ thống phản ứng (hiệu suất
tốt), chiến thuật có thể đƣợc bắt nguồn (quản lý tài nguyên) để đạt đƣợc hệ thống phản
ứng mong muốn (hiệu suất tốt) đo lƣờng thông qua một biện pháp đáp ứng hệ thống
(thời gian đáp ứng). Các chức năng đằng sau chiến thuật này, quản lý tài nguyên, sau
đó có thể cài đặt thông qua một hệ thống hoạt động và thông qua lập kế hoạch, đề án
quản lý quá trình.
Tác giả lƣu ý: Đó là vào thời điểm này giai đoạn 1, " Có một cơ sở kĩ thuật
vững chắc " là quan trọng. Để xác định các yếu tố phần mềm hoặc phần cứng có thể
hỗ trợ một chiến thuật,một trong những nhu cầu rất quen thuộc với các phần cứng và
các yếu tố phần mềm có sẵn để đi vào một hệ thống nhúng và chức năng của các yếu
tố này. Nếu không có điều này, kết quả của giai đoạn này có thể là tai họa cho một dự
án.

16

Ví dụ 2: An ninh
Hình 11-7a là tình huống cho một yêu cầu bảo mật. Trong ví dụ này, các nguồn kích
thích bên ngoài có thể ảnh hƣởng đến vấn đề an ninh chẳng hạn nhƣ một hacker hay

virus. Những nguồn này có thể tạo ra các sự kiện mà nó có thể truy cập tài nguyên hệ
thống, chẳng hạn nhƣ các nội dung bộ nhớ. Theo tình huống này, môi trƣờng trong đó
những sự kiện này có thể xảy ra khi các thiết bị nhúng kết nối với một mạng và có trao
đổi dữ liệu. Trong ví dụ này, các nguồn kích thích tạo ra các sự kiện tác động an ninh
bất kỳ bộ nhớ chính hay tài nguyên hệ thống truy cập vào các nguồn kích thích. Trong
quá trình này, hệ thống đáp ứng yêu cầu cho các thiết bị nhúng bao gồm việc bảo vệ,
hồi phục và chống lại một cuộc tấn công hệ thống. Mức độ và hiệu quả của hệ thống
an ninh đƣợc đo trong ví dụ này bằng các biện pháp đáp ứng hệ thống chẳng hạn nhƣ
xác định mức độ thƣờng xuyên của hành vi vi phạm bảo mật xảy ra, phải mất bao lâu
để các thiết bị phục hồi từ lúc vi phạm an ninh xảy ra, khả năng phát hiện và bảo vệ
chống lại các cuộc tấn công an ninh trong tƣơng lai. Với tình huống an ninh thể hiện
trong hình 11-7a, là một trong những phƣơng pháp mà theo đó một hệ thống nhúng
phản ứng để nó có thể chống lại một cuộc tấn công hệ thống kiểm soát truy cập các
nguồn bên ngoài có tài nguyên hệ thống nội bộ.

Hình 11-7a: tổng quát tình huống an ninh ABC
Để thao tác truy cập vào tài nguyên hệ thống, ngƣời ta có thể kiểm soát các biến số tác
động đến hệ thống thông qua việc xác thực của các nguồn bên ngoài truy cập vào hệ
thống, và thông qua việc giới hạn truy cập vào tài nguyên của hệ thống nguồn. Vì vậy,
việc ủy quyền và xác thực đƣợc hiển thị trong hình 11 7b-có thể đƣợc sử dụng để cho
phép một thiết bị theo dõi các nguồn truy cập vào thiết bị và sau đó từ chối truy cập
đến các nguồn có hại bên ngoài, do đó tăng khả năng bảo vệ cho hệ thống. Với một
nguồn tài nguyên bị ảnh hƣởng bởi một hành vi vi phạm an ninh, chẳng hạn nhƣ bộ
nhớ chính,vd: bộ nhớ và quá trình quản lý nhƣ những ngƣời đƣợc tìm thấy trong hệ
thống điều hành, an ninh và các bộ nhớ chƣơng trình phân bổ bao gồm khi sử dụng
17

một số ngôn ngữ lập trình nhƣ Java, và các giao thức bảo mật mạng ví dụ về các yếu
tố phần mềm và phần cứng có thể hỗ trợ truy cập quản lý bộ nhớ nguồn tài nguyên.
Ví dụ này cho thấy rằng việc đƣa ra các tác vụ ( truy cập / xóa / tạo ra các dữ liệu trái

phép) vào một hệ thống đáp ứng (phát hiện, chống lại, phục hồi từ các cuộc tấn công),
có thể đƣợc bắt nguồn (quản lý quyền truy cập vào tài nguyên) để đạt đƣợc các hệ
thống đáp ứng mong muốn (Phát hiện, chống lại, phục hồi từ các cuộc tấn công) thông
qua một biện pháp hệ thống phản ứng (xuất hiện của vi phạm an ninh).
Ví dụ 3: Khả năng kiểm tra
Trong ví dụ này, các nguồn kích thích bên ngoài có thể ảnh hƣởng đến khả năng kiểm
tra trong và ngoài hệ thống. Những nguồn này có thể tạo ra sự kiện khi các yếu tố
phần cứng và phần mềm trong hệ thống nhúng đã đƣợc hoàn thành hoặc cập nhật, và
đã sẵn sàng để đƣợc kiểm tra. Theo ví dụ này, Xác định hệ thống Kiến trúc và tài liệu
Thiết kế môi trƣờng trong đó những sự kiện này diễn rakhi thiết bị đang phát triển,
trong quá trình sản xuất, hoặc khi nó đã đƣợc triển khai đến lĩnh vực này. Các yếu tố
bị ảnh hƣởng trong các hệ thống nhúng có thể là bất kỳ phần cứng cá nhân hoặc yếu tố
phần mềm, hoặc toàn bộ các thiết bị nhúng.
Trong tình huống này, hệ thống phản ứng mong muốn là các câu trả lời dễ dàng kiểm
soát và quan sát để kiểm tra.khả năng kiểm tra của hệ thống đƣợc đo bằng các biện
pháp đáp ứng hệ thống nhƣ số các bài kiểm tra thực hiện, tính chính xác của các bài
kiểm tra, thời gian kiểm tra thực hiện, xác minh dữ liệu trong sổ đăng ký hoặc trong
bộ nhớ chính, cho dù kết quả thực tế của các bài kiểm tra phù hợp với thông số kỹ
thuật. Với tình huống trong Hình 11-8a, phƣơng pháp thao tác một Phản ứng của hệ
thống nhúng để các câu trả lời kiểm tra có thể kiểm soát và quan sát để cung cấp khả
năng tiếp cận các nguồn kích thích hoạt động nội bộ của hệ thống nhúng.
18


Figure 11-8a: Các bƣớc kiểm tra trong ABC nói chung
Để cung cấp khả năng truy cập vào các hoạt động nội bộ của hệ thống, ngƣời ta có thể
kiểm soát các biến số tác động đáp ứng hệ thống, chẳng hạn nhƣ khả năng làm chạy
thời gian đăng ký và bộ nhớ để xác minh dữ liệu. Điều này có nghĩa là các hoạt động
nội bộ của hệ thống phải đƣợc hiển thị cho và nguồn kích thích cho phép yêu cầu
kiểm soát nội bộ và thông tin trạng thái (tức là, trạng thái của các biến, biến thao tác,

bộ nhớ sử dụng, vv), và nhận đƣợc đầu ra dựa trên yêu cầu.
Vì vậy, một chiến thuật giám sát nội bộ, nhƣ thể hiện trong hình 11-8b, có thể đƣợc sử
dụng để cung cấp nguồn kích thích với khả năng giám sát các hoạt động nội bộ của hệ
thống và cho phép cơ chế giám sát nội bộ để chấp nhận đầu vào và cung cấp kết quả
đầu ra. Chiến thuật này làm tăng khả năng kiểm tra của hệ thống, vì làm thế nào có thể
thử nghiệm một hệ thống thƣờng phụ thuộc nhƣ thế nào có thể nhìn thấy và truy cập
các hoạt động nội bộ của hệ thống.
19


Hình 11-8b: Sơ đồ khả năng kiểm tra ABC
Xây dựng trong màn hình nhƣ những ngƣời đƣợc tìm thấy trên bộ vi xử lý khác nhau,
hoặc chƣơng trình con về các phần mềm gỡ lỗi tích hợp vào phần mềm hệ thống có
thể đƣợc gọi là một trình sửa lỗi hệ thống để thực hiện các bài kiểm tra khác nhau, là
những ví dụ của các yếu tố có thể cung cấp giám sát nội bộ của một hệ thống. Những
phần cứng và các yếu tố phần mềm là những ví dụ của những gì có thể đƣợc bắt
nguồn từ tình huống này. Trong ngắn hạn, ví dụ này chứng minh rằng việc đƣa ra các
kích thích (hoàn thành yếu tố và sẵn sàng để đƣợc kiểm tra) và một hệ thống phản ứng
mong muốn (dễ dàng kiểm tra các yếu tố và quan sát kết quả), một chiến thuật sau đó
có thể đƣợc bắt nguồn (giám sát nội bộ của hệ thống) để đạt đƣợc các mong muốn hệ
thống đo lƣờng thông qua một hệ thống phản ứng (dễ dàng kiểm tra các yếu tố và
quan sát kết quả) biện pháp phản ứng (kết quả thử nghiệm, thời gian thử nghiệm, kiểm
tra độ chính xác, vv).
Lƣu ý: Trong khi những ví dụ rõ ràng chứng minh làm thế nào các yếu tố bên trong
một kiến trúc có thể đƣợc bắt nguồn từ yêu cầu chung (thông qua các tình huống và
chiến thuật của họ), họ cũng ngầm chứng minh rằng các chiến thuật cho một trong
những yêu cầu có thể là phản tác dụng yêu cầu khác. Ví dụ, các chức năng cho phép
bảo mật có thể ảnh hƣởng đến hiệu suất hoặc chức năng cho phép để thử nghiệm khả
năng truy cập có thể tác động đến an ninh của hệ thống. Ngoài ra, lƣu ý rằng:
- một yêu cầu có thể có nhiều chiến thuật

- chiến thuật không bị giới hạn đối với một yêu cầu
20

- một chiến thuật có thể đƣợc sử dụng trên nhiều yêu cầu
Nhớ những điểm này khi xác định và hiểu rõ các yêu cầu của hệ thống bất kỳ.
Giai đoạn 3: Xác định các hình mẫu kiến trúc và mô hình tham khảo
Một mô hình kiến trúc (cũng đƣợc gọi là thành ngữ kiến trúc, phong cách kiến trúc)
cho một thiết bị cơ bản là cấu hình cấp cao của các hệ thống nhúng. Cấu hình là một
mô tả các loại khác nhau của các yếu tố phần mềm và phần cứng thiết bị có thể bao
gồm các chức năng của các yếu tố trong hệ thống, bố trí topo của các yếu tố (aka một
mô hình tham chiếu), và mối tƣơng quan và các giao diện yếu tố bên ngoài. Mô hình
đƣợc dựa trên phần cứng và các yếu tố bắt nguồn từ yêu cầu chức năng và phi chức
năng thông qua các nguyên mẫu, kịch bản, và chiến thuật.
Hình 11-9 là một ví dụ về mô hình kiến trúc thông tin. Nó bắt đầu từ trên xuống trong
việc xác định các yếu tố cho một hộp set-top TV kỹ thuật số (DTV-STB). Điều này có
nghĩa là nó bắt đầu với các loại ứng dụng sẽ chạy trên thiết bị, sau đó đƣa ra những gì
các hệ thống phần mềm và phần cứng các ứng dụng này yêu cầu ngầm hay rõ ràng,
bất kỳ hạn chế nào trong hệ thống…

21

Những thông tin về hệ thống có thể liên quan đến việc đƣa ra những kiểu phần cứng
và phần mềm có liên quan cho các thiết bị. Hình 11-10 đƣa ra mô hình tham khảo cho
các DTV-STB (Digital TV set-top box: hộp giải mã tivi kỹ thuật số).



Hình 11-10: Mô hình tham khảo của DTV-STB
Theo khuyến nghị của tác giả: Nếu các yêu cầu phần mềm đƣợc biết đến, sơ đồ và
phân tích càng nhiều yếu tố phần mềm lớn (tức là hệ điều hành, JVM, các ứng dụng,
mạng, v v ) thì nó có thể hoàn thành trƣớc các yếu tố phần cứng. Đó là bởi vì phần
22

cứng bị hạn chế (có thể nâng cấp) đƣợc thực hiện thông qua phần mềm. Phần cứng
sau đó sẽ tƣơng thích với cấu hình phần mềm, các bộ vi xử lý chính với các mô hình
khác nhau. Điều này có thể bao gồm loại bỏ một số chức năng hoặc thực hiện một số
thành phần phần mềm trong phần cứng.
Chọn phần cứng thương mại có sẵn và phần mềm
Dù các yếu tố thực hiện theo cách nào vào một kiến trúc, tất cả thƣờng phải đáp ứng
một tập hợp của các tiêu chí cơ bản, cả chức năng và phi chức năng, nhƣ thể hiện
trong giai đoạn 2, chẳng hạn nhƣ:
* Chi phí. Nên mua hay tự làm ra? Tích hợp và triển khai các yếu tố, thành phần có
hạn chế bớt chi phí không?
* Thời gian đưa ra thị trường. Các yếu tố sẽ đáp ứng các yêu cầu trong khung thời
gian quy định (tức là việc đảm bảo các sự kiện quan trọng trong suốt quá trình, thời
gian sản xuất, ….) ?
* Hiệu suất. Các yếu tố có đáp ứng sự hài lòng của ngƣời dùng? hoặc cho các yếu tố
khác phụ thuộc nó ?

* Các công cụ phát triển và gỡ rối. Những công cụ nào có sẵn để thiết kế các yếu tố
nhanh hơn và dễ dùng hơn?
*
Trong khi các thành phần có thể tự thiết kế và yêu cầu hỗ trợ kiến trúc, nhiều thành
phần có thể đƣợc mua. Danh sách cụ thể các tiêu chí, cách phổ biến trong lựa chọn
giữa các thành phần thƣơng mại để xây dựng một bảng các tính năng cần thiết cho
mỗi phần tử và sau đó điền vào bảng với các sản phẩm đáp ứng các yêu cầu cụ thể
(xem hình 11-11).

Yêu cầu 1
Yêu cầu 2
Yêu cầu 3
Yêu cầu
Yêu cầu "N"
Sản phẩm 1
CÓ
Các tính năng
KHÔNG
Chƣa có


Sản phẩm 2
CÓ
Các tính năng
CÓ
Các tính năng
CÓ
Các tính năng

Sản phẩm 3
KHÔNG
CÓ
Các tính năng
KHÔNG



Sản phẩm 4
CÓ
Các tính năng
Chƣa có
Trong 3 tháng
KHÔNG
Trong 6 tháng


23

Sản phẩm





Sản phẩm "N"

Hình 11-11: Mẫu bảng ma trận sản phẩm và yêu cầu
Trong khi tất cả các yếu tố có sẵn (nhƣ ngăn kết nối mạng, trình điều khiển thiết bị,
v v ) trong hệ thống nhúng rất quan trọng trong việc thiết kế, một số yếu tố quyết
định đó là việc lựa chọn ngôn ngữ lập trình, hệ điều hành và bộ xử lý chính trên mạch.
Trong phần này, những yếu tố trên đƣợc sử dụng nhƣ các ví dụ trong việc cung cấp
các gợi ý làm thế nào để lựa chọn giữa các tùy chọn có sẵn và tạo ra một bảng tƣơng
đối trong mỗi lĩnh vực.
Ví dụ 1: Lựa chọn ngôn ngữ lập trình
Tất cả các ngôn ngữ đòi hỏi một trình biên dịch để dịch mã nguồn thành mã máy cho
bộ xử lý, dù đó là 32-bit, 16-bit hay 8-bit, v v Với thiết kế 4-bit và 8-bit dựa trên số
kilobyte chứa trong bộ nhớ (tổng bộ nhớ ROM và RAM), thông thƣờng ngôn ngữ
Assembly (Hợp ngữ) sẽ đƣợc lựa chọn. Trong các hệ thống với kiến trúc mạnh mẽ
hơn, hợp ngữ thƣờng đƣợc sử dụng cho các thao tác phần cứng cấp thấp. Viết mã lệnh
trong hợp ngữ luôn luôn là một sự lựa chọn và trong thực tế, hầu hết các hệ thống
nhúng thực hiện các mã lệnh hợp ngữ này. Dù hợp ngữ khá nhanh nhƣng nó thƣờng
gặp khó khăn khi viết cho các chƣơng trình ở mức cao hơn.
C thƣờng là cơ sở của nhiều ngôn ngữ phức tạp đƣợc sử dụng trong các hệ thống
nhúng, nhƣ C++, Java, Perl, v v Trong thực tế, ngôn ngữ C thƣờng sử dụng trong
nhiều thiết bị nhúng phức tạp có một hệ điều hành hoặc là sử dụng ngôn ngữ phức tạp
hơn chẳng hạn nhƣ là ngôn ngữ JavaScript. Điều này là bởi vì hệ điều hành, ngôn ngữ
JavaScript thƣờng đƣợc viết bằng C.
Sử dụng ngôn ngữ lập trình hƣớng đối tƣợng cấp cao nhƣ C++ hoặc Java trong 1 thiết
bị nhúng là hữu ích cho các ứng dụng nhúng lớn hơn mà các mô-đun mã có thể đơn
giản hóa việc thiết kế, phát triển, thử nghiệm và bảo trì các ứng dụng lớn mã hóa thủ
tục (chẳng hạn nhƣ C). Ngoài ra, C++ và Java giới thiệu thêm các cơ chế, chẳng hạn
nhƣ bảo mật, xử lý ngoại lệ (exception handling), không gian tên (namespace) , các
chuẩn về an toàn, v v., mà ta sẽ không tìm thấy trong ngôn ngữ C. Trong một số
trƣờng hợp, tiêu chuẩn thị trƣờng có thể yêu cầu các thiết bị hỗ trợ một ngôn ngữ cụ
thể (ví dụ triển khai DTV nhất định đòi hỏi phải sử dụng Java)

Để thực hiện các ứng dụng nhúng là phần cứng và hệ thống phần mềm độc lập, Java,
ngôn ngữ Net (C#, Visual Basic, v v ), ngôn ngữ Script phổ biến nhất ngôn ngữ cấp
cao cho sự lựa chọn. Để có thể chạy các ứng dụng viết bằng các ngôn ngữ này, một
24

JVM (Java), NET Framework Compact (C #, Visual Basic, vv), và một phiên dịch
(cho các ngôn ngữ nhƣ JavaScript, HTML , Perl, vv ) đều cần phải đƣợc đƣa trong
kiến trúc. Với mong muốn cho phần cứng và phần mềm ứng dụng hệ thống độc lập,
các API (Application Programming Interface: giao diện lập trình ứng dụng) chính xác
phải đƣợc hỗ trợ trên thiết bị theo thứ tự cho các ứng dụng chạy. Ngoài ra, nếu yếu tố
này không đƣợc thực hiện trong phần cứng (ví dụ, JVM trong một bộ xử lý Java), sau
đó nó phải đƣợc thực hiện trong các ngăn xếp phần mềm hệ thống hoặc một phần của
hệ điều hành, chuyển đến hệ điều hành và bộ vi xử lý chính (nhƣ là trƣờng hợp
với .NET đến WinCE hoặc một JVM chuyển đến VxWorks, Linux, MIPS ) hoặc nó
cần đƣợc thực hiện nhƣ một phần của ứng dụng (ví dụ, HTML, JavaScript trong một
trình duyệt, một JVM trong một tập tin .exe trên WinCE hoặc tập tin .prc trên PalmOS,
v v ). Ngoài ra, lƣu ý, nhƣ với bất kỳ yếu tố phần mềm khác đƣợc giới thiệu trong
kiến trúc, sức mạnh xử lý tối thiểu và yêu cầu bộ nhớ trong phần cứng của các hệ
thống có chứa các yếu tố ngôn ngữ cấp cao để cho các mã đƣợc viết bằng các ngôn
ngữ này thực hiện một cách hợp lý.
Ta có ví dụ để miêu tả là một hệ thống nhúng có thể đƣợc dựa trên một số ngôn ngữ
khác nhau (ví dụ nhƣ hợp ngữ, C, Java,….). Nhƣ thể hiện trong hình 11-12, cho ta
thấy những gì các ngôn ngữ đáp ứng chức năng và yêu cầu phi chức năng của thiết bị.

Thời gian thực
Hiệu suất nhanh
MHP-
Spec
ATVEF-
Spec

Ứng dụng
trình duyệt

Hợp ngữ
CÓ
CÓ
Không
yêu cầu
Không
yêu cầu
Không
yêu cầu

C
CÓ
CÓ
Chậm hơn so với hợp ngữ
Không
yêu cầu
Không
yêu cầu
Không
yêu cầu

C++
CÓ
CÓ
Chậm hơn so với C
Không
yêu cầu

Không
yêu cầu
Không
yêu cầu

.NetCE
(C #)
KHÔNG
WinCE không có
RTOS
Phụ thuộc vào bộ vi xử lý,
chậm hơn so với C trên bộ vi
xử lý tối thiểu.
Không
yêu cầu
Không
yêu cầu
Không
yêu cầu

JVM
(Java)
Phụ thuộc vào
JVM và hệ điều
hành có RTOS
Phụ thuộc vào mã byte của
JVM, chậm hơn so với C trên
bộ vi xử lý tối thiểu
CÓ
Không

yêu cầu
Không
yêu cầu

HTML
(Scripting)
Phụ thuộc vào
ngôn ngữ viết và
hệ điều hành
Chậm hơn bởi vì việc phiên
dịch cần phải đƣợc thực hiện
và phụ thuộc vào ngôn ngữ
thông dịch.
Không
yêu cầu
CÓ
CÓ

Hình 11-12: Bảng các ngôn ngữ lập trình
25

DVB (Digital Video Broadcasting): Truyền hình kĩ thuật số
MHP (Multimedia Home Platform): Giải trí đa phƣơng tiện tại gia
ATVEF (Advanced Television Enhancement Forum
RTOS Real Time Operating System : Hệ điều hành thời gian thực
Ví dụ 2: Lựa chọn một hệ điều hành
Các vấn đề chính xung quanh việc sử dụng một hệ điều hành (OS) trong việc thiết kế
hệ thống nhúng là:
1. Loại hệ thống thƣờng sử dụng hoặc yêu cầu của một hệ điều hành?
2. Là một hệ điều hành cần thiết để thực hiện các yêu cầu hệ thống?

3. Điều gì cần thiết để hỗ trợ một hệ điều hành trong việc thiết kế?
4. Làm thế nào để lựa chọn hệ điều hành tốt nhất phù hợp với các yêu cầu?
Các thiết bị nhúng dựa trên bộ vi xử lý 32-bit (hoặc cao hơn) thƣờng có một hệ điều
hành, bởi vì các hệ thống này thƣờng phức tạp hơn và có nhiều megabytes mã để quản
lý. Đôi khi các yếu tố khác trong kiến trúc đòi hỏi một hệ điều hành trong hệ thống,
chẳng hạn nhƣ một JVM hoặc NET Compact Framework đƣợc thực hiện trong các
ngăn xếp phần mềm hệ thống.
Một hệ điều hành là cần thiết hay không, nó phụ thuộc vào yêu cầu và sự phức tạp của
hệ thống. Ví dụ, nếu xử lý đa nhiệm, lịch công việc trong một chƣơng trình cụ thể,
quản lý tài nguyên một cách tƣơng đối, quản lý bộ nhớ ảo và rất nhiều mã ứng dụng
quan trọng, thì lúc này ta sử dụng một hệ điều hành sẽ không chỉ đơn giản hóa toàn bộ
dự án mà có thể rất quan trọng để hoàn thành nó. Để có thể giới thiệu một hệ điều
hành vào bất kỳ thiết kế, ta cần xem xét đến: sức mạnh xử lý, bộ nhớ, và chi phí. Điều
này cũng có nghĩa là hệ điều hành cần hỗ trợ phần cứng (nhƣ chip xử lý chính…)
Lựa chọn một hệ điều hành phổ biến, một lần nữa, quay lại để tạo ra bảng với yêu cầu
và các tính năng hệ điều hành. Các tính năng trong bảng này có thể bao gồm:
* Chi phí. Khi mua một hệ điều hành, nhiều chi phí cần phải đƣợc xem xét. Ví dụ, nếu
công cụ phát triển đi kèm với một gói phần mềm hệ điều hành, thƣờng sẽ có một
khoản phí cho các công cụ đó, cũng nhƣ một khoản phí giấy phép lƣu hành của hệ
điều hành. Một số công ty tính phí một lần lệ phí cấp giấy phép hệ điều hành, trong