Giai đoạn 2: Nắm được ABC của sản phẩm• Giai đoạn 2 gồm các bước nhỏ sau đây • Bước 1: Liệt kê tất cả các ảnh hưởng có thể tác động đến yêu cầu của hệ thống không chỉ có các yếu tố kỹ t
Trang 1BÀI GIẢNG MÔN HỌC HỆ NHÚNG
Chương 2: Quy trình phát triển hệ thống nhúng
2.1 Tìm hiểu phân tích yêu cầu
Trang 2• Điều gì xảy ra nếu không có qui trình phát triển hệ thống hoặc qui trình không tốt?
Trang 32 Qui trình phát triển hệ thống nhúng
Trang 42.1 Tìm hiểu phân tích yêu cầu
• Giống như quá trình tìm hiểu phân tích yêu cầu đối với phần mềm
• Tuy nhiên, đối với hệ nhúng thường chú trọng nhiều hơn đến
performance
• Tốc độ CPU
• Bộ nhớ hỗ trợ
• Realtime?
Trang 52.1 Tìm hiểu phân tích yêu cầu
• Đầu vào
• Yêu cầu của người sử dụng (khách hàng)
• Theo cách nhìn của người sử dụng
• Chưa rõ ràng, chi tiết (đôi khi là mập mờ)
• Đầu ra
• Bản đặc tả yêu cầu người dùng
• Yêu cầu hệ thống dưới góc nhìn của người thiết kế, phát triển hệ thống
• Chi tiết, rõ ràng tất cả các yêu cầu của người sử dụng
Trang 62.2 Thiết kế hệ thống nhúng
• Mô hình vòng đời thiết kế và phát triển hệ thống nhúng
• Quá trình tạo bản thiết kế hệ thống nhúng
Trang 7Mô hình vòng đời thiết kế và phát triển
Trang 8Mô hình vòng đời thiết kế và phát
Trang 9Quá trình tạo bản thiết kế hệ nhúng
• Quá trình thiết kế cần trải qua 6 giai đoạn chính sau đây:
• Giai đoạn 1: Nắm vững kiến thức nền tảng
• Giai đoạn 2: Hiểu được vòng đời thương mại của sản phẩm (architecture business cycle - ABC)
• Giai đoạn 3: Xây dựng thiết kế tổng quan
• Giai đoạn 4: Thiết kế chi tiết
• Giai đoạn 5: Tài liệu hóa các thiết kế
• Giai đoạn 6: Phân tích và đánh giá thiết kế
Trang 10Giai đoạn 1: Nắm vững kiến thức nền tảng
• Cần nắm vững các kiến thức nền tảng cả phần cứng lẫn phần mềm
• Hiểu tổng quan về toàn bộ hệ thống mình tham gia
Trang 11Giai đoạn 2: Nắm được ABC của sản phẩm
Trang 12• Từ Architecture Business Cycle của hệ nhúng có thể suy ra:
• Hệ nhúng không chỉ được thiết kế trên cơ sở các yêu cầu về mặt kỹ thuật mà còn phụ thuộc rất nhiều yếu tố khác
• Ví dụ: Cùng là thiết kế một chiếc TV
• Technical requirement là hoàn toàn giống nhau
• Tuy nhiên mỗi hãng khác nhau lại cho ra một thiết kế riêng của mình
lý do tại sao?
Trang 13Giai đoạn 2: Nắm được ABC của sản phẩm
• Giai đoạn 2 gồm các bước nhỏ sau đây
• Bước 1: Liệt kê tất cả các ảnh hưởng có thể tác động đến yêu cầu của hệ
thống (không chỉ có các yếu tố kỹ thuật)
• Bước 2: Phân loại các yếu tố ảnh hưởng: yếu tố nào là kỹ thuật, yếu tố nào là yếu tố kinh doanh, yếu tố con người…
• Bước 3: Từ 2 bước trên thu thập yêu cầu cho hệ thống
• Bước 4: Xác định các thành phần phần cứng, phần mềm có thể thỏa mãn yêu cầu hệ thống
Trang 14Giai đoạn 2: Nắm được ABC của sản phẩm
• Trên thực tế, hầu hết các hệ nhúng đều dùng các đặc trưng chung của ABCs là tiêu chí đầu tiên để thu thập requirement
Các Ảnh hưởng Đặc trưng Mô tả
Business [Sales, Marketing, Management…]
Sellability Tính thương mại của sản phẩm Time-to-Market Thời gian phát triển sản phẩm
Cost Giá thành của sản phẩm
Device lifetime Vòng đời của sản phẩm ngoài thị trường,
vòng đời của sản phẩm thực tế…
Schedule, Capability, Risks Lịch trình từng bước để phát triển sản phẩm, khả năng của sản phẩm, các rủi ro
có thể phát sinh
Trang 15Giai đoạn 2: Nắm được ABC của sản phẩm
Các Ảnh hưởng Đặc trưng Mô tả
Technical Performance Tốc độ, khả năng lưu trữ, độ chính xác…
User-friendliness Dễ sử dụng, giao diện thân thiện đẹp mắt… Modifiability Khả năng dễ dàng sửa đổi, nâng cấp
Security Tính bảo mật của hệ thống, khả năng chống
bẻ khóa, chống hacker…
Reliability Hệ thống có bị hỏng hóc, ngừng hoạt động
đột ngột? Khi có sự cố xảy ra hệ thống phản ứng thế nào…
Portability Khả năng phần mềm có thể chạy trên nhiều
phần cứng khác nhau, hay phần cứng có tương thích với nhiều nền tảng phần mềm khác nhau
Trang 16Giai đoạn 2: Hiểu ABCs của hệ nhúng
Các Ảnh hưởng Đặc trưng Mô tả
Technical Testability Hệ thống có dễ kiểm tra, phát hiện lỗi không
Availability Tính sẵn sàng Standards Các tiêu chuẩn cần tuân thủ Schedule
Trang 17Giai đoạn 2: Hiểu ABCs của hệ nhúngCác Ảnh hưởng Đặc trưng Mô tả
Industry Standards Các chuẩn công nghiệp, có thể do thị trường
qui định (Ví dụ: chuẩn TV, chuẩn cho các thiết
bị y tế, chuẩn mạng…)
Quality Assurance Testability Xem trong phần technical ở trên
Availability Khi nào thì hệ thống sẵn sàng cho việc test Schedule Xem trong phần business ở trên
QA standards ISO 9000, ISO 9001…
Customer Cost Giá của thiết bị, giá vận hành bảo trì…
User friendliness Xem trong phần bussiness ở trên Performance Xem trong phần technical ở trên
Trang 18Xác định các thành phần phần cứng, mềm
• Để xác định các thành phần phần cứng phần mềm thỏa mãn
requirements
• Liệt kê các kịch bản thỏa mãn mỗi yêu cầu
• Đưa ra các chiến lược (cách giải quyết) cho mỗi kịch bản ở trên
• Dựa vào các chiến lược ở trên đưa ra các chức năng cần thiết phải có trong
hệ thống, từ đó liệt kê các phần cứng và phần mềm
Trang 19Liệt kê các kịch bản thỏa mãn yêu cầu
• Ví dụ kịch bản thõa mãn yêu cầu về performance
Trang 20Liệt kê các kịch bản thỏa mãn yêu cầu
• Ví dụ kịch bản thỏa mãn yêu cầu về tính testability của hệ thống
Trang 21Đưa ra các chiến lược giải quyết các kịch bản
• Ví dụ chiến lược giải quyết kịch bản thỏa mãn yêu cầu performance
Trang 22Đưa ra các chiến lược giải quyết các kịch bản
• Ví dụ chiến lược giải quyết kịch bản thỏa mãn yêu cầu testability
Trang 23Giai đoạn 3: Xây dựng thiết kế tổng quan
• Đưa ra danh sách các thành phần phần cứng và phần mềm mà hệ thống cần có
• Mối quan hệ giữa các thành phần với nhau
• Thường tiến hành thiết kế theo kiểu top-down và đưa ra mô hình phân tầng
• Phân rã hệ thống thành các chức năng con
• Phân rã các chức năng con thành các chức năng nhỏ hơn nữa
Trang 24Giai đoạn 3: Xây dựng thiết kế tổng quan (basic design)
• Ví dụ: Thiết kế TV set-top box
Trang 25Giai đoạn 3: Xây dựng thiết kế tổng quan
• Sau khi có mô hình phân tầng, tiến hành chọn lựa các thành phần phần cứng và phần mềm
Trang 26Chọn lựa các thành phần phần cứng và phần mềm
• Cách phổ biến nhất để tiến hành lựa chọn các thành phần phần cứng
và phần mềm là lập bảng phân tích đặc trưng cho mỗi yêu cầu của từng sản phẩm
Trang 27Ví dụ: Chọn ngôn ngữ lập trình
MHP: Multimedia home platform
ATVEF:
Advanced Television Enhancement Forum
Trang 29Ví dụ: Chọn hệ điều hành được sử dụng cho hệ nhúngOS Tools Portability Non-kernel Processor Scheduling time …
vxWork Tornado IDE,
Singer step debugger…
BSP Device driver,
graphics, networking…
x86, MIPS, ARM, PPC Hard real-time, priority based …
Linux Depend on
vendor for developmen
t IDE, gcc…
Depend on vendor, some with
no BSP
Device driver, graphics,
networking…
Depend on vendor (x86, ARM…)
Depend on vendor, some are hard real-time, some are soft
Trang 30Giai đoạn 4: Thiết kế chi tiết
• Có nhiều kỹ thuật thiết kế kiến trúc hệ thống
• Kỹ thuật thông dụng và được ưa dùng nhất là mô hình “4+1”
Trang 31Mô hình cấu trúc “4+1”
• “4”: Đưa ra thiết kế cấu trúc hệ thống từ 4 góc nhìn khác nhau
• Thành phần “+1”: đóng vai trò đánh giá và đảm bảo 4 cấu trúc trên đồng nhất
Trang 32Mô hình cấu trúc “4+1”
• Cấu trúc 1: logical structure là cấu trúc module của hệ thống (sơ đồ
khối) đưa ra các thành phần phần cứng phần mềm, mối quan hệ giữa thành phần
• Cấu trúc 2: process structure đối với các hệ thống có hệ điều hành,
cấu trúc process giải quyết các yêu cầu phi chức năng như
performance, system integrity, resource availability…
Trang 33Mô hình cấu trúc “4+1”
• Cấu trúc 3: development structure đưa ra môi trường phát triển hệ
thống: IDE, debugger, ngôn ngữ lập trình… Cấu trúc này đưa ra cách mapping hệ thống phần cứng và phần mềm vào trong môi trường phát triển
• Cấu trúc 4: deployment/physical structure đưa ra cách đồng bộ hệ
thống phần mềm với hệ thống phần cứng
Trang 34Giai đoạn 5: Tài liệu hóa các thiết kế
• Các chuẩn để viết các tài liệu thiết kế rất đa dạng tùy thuộc vào từng ngành công nghiệp, từng công ty hay các nhóm phát triển…
• Thông thường quá trình tài liệu hóa thường có 2 bước
• Bước 1: Viết overview về hệ thống, gồm có các cấu trúc nào, các mối quan hệ giữa các cấu trúc
• Bước 2: Viết chi tiết cho từng cấu trúc cụ thể
• Không có template chuẩn để viết các tài liệu cho hệ thống embedded, tuy nhiên có thể dùng các ngôn ngữ mô hình hóa thông dụng
• UML
• ADD
• …
Trang 35Giai đoạn 5: Tài liệu hóa các thiết kế
• Ví dụ UML
Trang 36Giai đoạn 6: Phân tích và đánh giá thiết kế
• Thông thường bản thiết kế cần được đánh giá bởi một nhóm
• Trong nhóm đánh giá cần có người không thuộc nhóm thiết kế, phát triển để đảm bảo tính khách quan và tránh bị tư duy theo lối mòn
• …
Trang 372.3 Thực thi hệ thống nhúng
• Quá trình thực thi hệ thống nhúng thường trải qua các giai đoạn sau
Giai đoạn 1: Cài đặt môi trường phát triển
Giai đoạn 2: Thiết kế mạch phần cứng
Giai đoạn 3: Porting hệ điều hành, viết firmware
Giai đoạn 4: Viết phần mềm điều khiển, giao tiếp trên PC
Trang 38Giai đoạn 1: Cài đặt môi trường phát triển
• Cài đặt IDE
• Cài đặt SDK
• Compiler, cross compiler
• Thiết lập kết nối host-target
• …
Trang 39Giai đoạn 2: Thiết kế mạch phần cứng
• Thiết kế sơ đồ nguyên lý
• Thiết kế sơ đồ mạch in
• Đặt mạch, hàn thiết bị lên mạch
Trang 40Giai đoạn 3: Porting hệ điều hành, viết firmware
• Đối với các hệ nhúng có hệ điều hành
• Porting hệ điều hành
• Cài đặt các driver cần thiết
• Đối với các hệ không có hệ điều hành
• Viết firmware
• Giao tiếp với các ngoại vi
• Giao tiếp với máy tính
Trang 41Giai đoạn 4: Viết phần mềm điều
khiển giao tiếp trên PC
• Phần mềm trên PC đóng vai trò điều khiển, hoặc cập nhật dữ liệu cho board mạch cứng
• Ngay cả với các hệ nhúng hoạt động độc lập, thường vẫn cần viết
phần mềm trên PC để giao tiếp với board mạch cứng
• Test các chức năng mạch
• Giả lập các môi trường thực tế
• …
Trang 422.4 Kiểm thử hệ thống nhúng
• Về cơ bản cũng giống như qui trình kiểm thử phần mềm
• Gồm các bước sau
• Lập test plan
• Viết các test case
• Tiến hành test, và phản hồi tới đội phát triển
Trang 432.4 Kiểm thử hệ thống nhúng
• Ở đây xin đưa ra một số lưu ý và trình tự kiểm thử thông dụng
1) Sau khi thiết kế xong mạch phần cứng, kiểm tra thông mạch đảm bảo
mạch phần cứng không có vấn đề như bị đứt dây ngầm, chập các điểm… 2) Kiểm tra module nguồn Đảm bảo module nguồn cấp đúng mong muốn,
không bị quá dòng, quá áp…
3) Kiểm tra IC chính (IC sẽ được nạp firmware)
Trang 442.4 Kiểm thử hệ thống nhúng
3) Kiểm tra IC chính
• Kiểm tra nguồn cấp đến chân nguồn, chân GND của IC
• Nạp thử chương trình để kiểm tra mạch nạp có nhận đúng IC
4) Kiểm tra các ngoại vi
5) Kiểm tra firmware và phần mềm trên PC
Trang 452.5 Triển khai bảo trì hệ thống
nhúng
• Qui trình triển khai bảo trì bao gồm các bước sau
• Lập kế hoạch triển khai
• Cung cấp tài liệu hướng dẫn vận hành, sử dụng, tổ chức đào tạo vận hành hệ thống
• Ghi nhận các lỗi phát sinh
• Tiến hành sửa chữa đảm bảo hệ thống vận hành đúng theo yêu cầu thực tế
Trang 46Bài tập thảo luận
• Phân nhóm thực hiện hai công đoạn trong quy trình phát triển hệ nhúng: bắt yêu cầu và thiết kế tổng quan