Xác Định Hệ thống – Tạo kiến trúc và lập hồ sơ thiết kế
Xác định Hệ thống — Tạo Kiến trúc và lập hồ sơ thiết kế
Trong chương này f Xác định các giai đoạn tạo kiến trúc hệ thống nhúng f Giới thiệu về chu kỳ kinh doanh kiến trúc và ảnh hưởng của nó đối với kiến trúc f Mô tả cách tạo và ghi lại một kiến trúc f Giới thiệu cách đánh giá và thiết kế ngược một kiến trúc
Chương này nói về việc cung cấp cho người đọc một số quy trình và kỹ thuật thực tế có đã được chứng minh là hữu ích trong những năm qua Việc xác định hệ thống và kiến trúc của nó, nếu được thực hiện đúng, là giai đoạn phát triển khó khăn nhất và quan trọng nhất trong toàn bộ chu kỳ phát triển Hình 11-1 cho thấy các giai đoạn phát triển khác nhau được xác định bởi: Mô hình vòng đời thiết kế và phát triển hệ thống nhúng
Mô hình này chỉ ra rằng quá trình thiết kế một hệ thống nhúng và thiết kế đó 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 Triển khai 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 kiểm tra hệ thống nhúng cho vấn đề, và sau đó giải quyết những vấn đề đó
• Giai đoạn 4 Bảo trì Hệ thống , là quá trình triển khai phần mềm nhúng hệ thống vào hiện trường và cung cấp hỗ trợ kỹ thuật cho người dùng thiết bị đó để thời gian tồn tại của thiết bị
Mô hình này cũng chỉ ra rằng thời gian quan trọng nhất được dành cho giai đoạn 1, tạo ra kiến trúc Ở giai đoạn này của quá trình, không có bo mạch nào được chạm vào và không có phần mềm nào được mã hóa Đó là việc dành toàn bộ sự chú ý, sự tập trung và các kỹ năng điều tra để thu thập thông tin về thiết bị sẽ được phát triển, hiểu những lựa chọn nào tồn tại và ghi lại những phát hiện đó Nếu việc chuẩn bị đúng được thực hiện trong việc xác định kiến trúc của hệ thống, xác định các yêu cầu, hiểu các rủi ro, v.v thì các giai đoạn phát triển, kiểm tra và bảo trì thiết bị còn lại sẽ đơn giản hơn, nhanh hơn và rẻ hơn Tất nhiên, điều này đòi hỏi các kỹ sư chịu trách nhiệm phải có các kỹ năng cần thiết
Tóm lại, nếu giai đoạn 1 được thực hiện chính xác, thì sẽ ít thời gian bị lãng phí hơn cho việc giải mã mã không đáp ứng yêu cầu hệ thống hoặc đoán ý định của nhà thiết kế, điều này thường dẫn đến nhiều lỗi hơn và nhiều công việc hơn Điều đó không có nghĩa là quá trình thiết kế luôn thuận buồm xuôi gió Thông tin thu thập được có thể không chính xác, các thông số kỹ thuật có thể thay đổi, v.v., nhưng nếu nhà thiết kế hệ thống có kỷ luật, chuẩn bị và có tổ chức về mặt kỹ thuật, các rào cản mới có thể được nhận ra và giải quyết ngay lập tức Điều này dẫn đến một quá trình phát triển ít căng thẳng hơn nhiều, ít lãng phí thời gian và tiền bạc hơn Quan trọng nhất, dự án, từ quan điểm kỹ thuật, gần như chắc chắn sẽ kết thúc thành công
Chương này giới thiệu một quy trình đơn giản để tạo ra một kiến trúc hệ thống nhúng bao gồm sáu giai đoạn chính: có nền tảng kỹ thuật vững chắc (giai đoạn 1), hiểu được chu trình kinh doanh kiến trúc của hệ thống (giai đoạn 2), xác định các mẫu kiến trúc và mô hình tương ứng (giai đoạn 3), xác định cấu trúc kiến trúc (giai đoạn 4), lập hồ sơ kiến trúc (giai đoạn 5), và phân tích đánh giá kiến trúc (giai đoạn 6) Nói tóm lại, quá trình này sử dụng một số cơ chế hữu ích nhất của các phương pháp tiếp cận kiến trúc công nghiệp phổ biến khác nhau Người đọc có thể sử dụng các cơ chế này như một điểm khởi đầu để hiểu nhiều cách tiếp cận khác nhau, cũng như để tạo ra một kiến trúc hệ thống nhúng dựa trên cách tiếp cận thực dụng, đơn giản này
Chương tiếp theo và cuối cùng - Chương 2, thảo luận về các giai đoạn còn lại của thiết kế hệ thống nhúng: triển khai kiến trúc, kiểm tra thiết kế và các vấn đề về khả năng bảo trì của thiết kế sau khi triển khai
1 Vẽ và mô tả bốn giai đoạn của Mô hình Vòng đời Thiết kế và Phát triển Hệ thống Nhúng
2 [a] Trong bốn giai đoạn, giai đoạn nào được coi là khó khăn và quan trọng nhất?
3 Sáu giai đoạn trong việc tạo ra một công trình kiến trúc là gì?
Nguồn kích thích bên ngoài (người dùng: nhân viên bán hàng, kỹ sư ứng dụng hiện trường, khách hàng, v.v.)
Các biện pháp phản hồi của hệ thống (độ trễ trong phản ứng với đầu vào của người dùng, khôi phục từ lỗi của người dùng, mức độ hài lòng của người dùng, v.v.)
[b] Vẽ và mô tả chu trình
5 Liệt kê và xác định bốn bước của Giai đoạn 2 của việc tạo kiến trúc
6 Kể tên bốn loại ảnh hưởng đến quá trình thiết kế của một hệ thống nhúng
7 Phương pháp nào ít được khuyến nghị nhất để thu thập thông tin từ các ảnh hưởng của
A.Mô hình máy trạng thái hữu hạn
E Tất cả những điều trên
8 Kể tên và mô tả bốn ví dụ về các đặc điểm chung của ABC từ năm ảnh hưởng khác nhau
[b] Làm thế nào một nguyên mẫu có thể hữu ích?
10 Sự khác biệt giữa kịch bản và chiến thuật là gì?
11.Trong Hình 1-2, liệt kê và xác định các thành phần chính của một kịch bản
Kích thích sự thân thiện với người dùng (học cách sử dụng hệ thống, cập nhật hệ thống, v.v.)
Yếu tố bị ảnh hưởng (Hệ thống nhúng)
Môi trường (tại hiện trường.)
Phản hồi hệ thống (kết quả đầu ra phù hợp với đầu vào của người dùng, v.v.)
Hình 1-2: Kịch bản chung về mức độ thân thiện với người dùng của ABC
12 [T / F] Một yêu cầu có thể có nhiều chiến thuật
13 Sự khác biệt giữa mô hình kiến trúc và mô hình tham chiếu là gì?
[b] Tại sao nó hữu ích?
[c]Liệt kê và xác định cấu trúc tương ứng với mô hình “4 + 1”
15 [a] Quy trình ghi lại một kiến trúc là gì?
[b] Làm thế nào một cấu trúc cụ thể có thể được ghi lại?
16 [a] Liệt kê và xác định hai cách tiếp cận phổ biến để phân tích và đánh giá một ngành kiến trúc?
[b] Đưa ra ít nhất năm ví dụ trong thế giới thực về một trong hai
17 Sự khác biệt giữa cách tiếp cận thuộc tính chất lượng định tính và định lượng là gì?
18 Năm bước được giới thiệu trong văn bản là một phương pháp để xem xét một ngành kiến trúc?
Các giai đoạn cuối cùng của thiết kế nhúng: Thực hiện và Kiểm tra
Thực hiện thiết kế
Có tài liệu kiến trúc rõ ràng giúp các kỹ sư và lập trình viên trong nhóm phát triển triển khai một hệ thống nhúng phù hợp với các yêu cầu Trong suốt cuốn sách này, các đề xuất trong thế giới thực đã được đưa ra để triển khai các thành phần khác nhau của thiết kế đáp ứng các yêu cầu này Ngoài việc hiểu các thành phần và khuyến nghị này, điều quan trọng là phải hiểu những công cụ phát triển nào có sẵn để hỗ trợ việc triển khai một hệ thống nhúng Việc phát triển và tích hợp các thành phần phần cứng và phần mềm khác nhau của hệ thống nhúng có thể thực hiện được thông qua các công cụ phát triển cung cấp mọi thứ từ tải phần mềm vào phần cứng đến cung cấp quyền kiểm soát hoàn toàn đối với các thành phần hệ thống khác nhau
Các hệ thống nhúng thường không được phát triển trên một hệ thống - ví dụ:
Bo mạch kho của hệ thống nhúng — nhưng thường yêu cầu ít nhất một hệ thống máy tính khác được kết nối với nền tảng nhúng để quản lý sự phát triển của nền tảng đó Nói tóm lại, môi trường phát triển thường được tạo thành từ mục tiêu (hệ thống nhúng đang được thiết kế) và máy chủ (PC, Sparc Station hoặc một số hệ thống máy tính khác nơi mã thực sự được phát triển) Mục tiêu và máy chủ được kết nối bằng một số phương tiện truyền dẫn, khi nối tiếp, Ethernet hoặc phương pháp khác Nhiều công cụ khác, chẳng hạn như các công cụ tiện ích để ghi EPROMs hoặc các công cụ gỡ lỗi, có thể được sử dụng trong môi trường phát triển cùng với máy chủ và mục tiêu (Xem Hình 2-1.)
Hình 2.1: Môi trường phát triển
Các công cụ phát triển quan trọng trong thiết kế nhúng có thể được đặt trên máy chủ, trên đích hoặc có thể tồn tại độc lập Các công cụ này thường thuộc một trong ba loại: tiện ích, công cụ dịch và gỡ lỗi Các công cụ tiện ích là các công cụ chung hỗ trợ phát triển phần mềm hoặc phần cứng, chẳng hạn như trình soạn thảo (để viết mã nguồn), VCS (Phần mềm kiểm soát phiên bản) để quản lý các tệp phần mềm, trình ghi ROM cho phép đưa phần mềm vào ROM, v.v Các công cụ dịch chuyển mã mà nhà phát triển dự định cho mục tiêu thành một dạng mà mục tiêu có thể thực thi và các công cụ gỡ lỗi có thể được sử dụng để theo dõi và sửa lỗi trong hệ thống Tất cả các loại công cụ phát triển đều quan trọng đối với một dự án như thiết kế kiến trúc, bởi vì nếu không có các công cụ phù hợp, việc triển khai và gỡ lỗi hệ thống sẽ rất khó khăn, nếu không muốn nói là không thể
2.1.1 Công cụ tiện ích phần mềm chính: Viết mã trong trình soạn thảo hoặc IDE Mã nguồn thường được viết bằng một công cụ như trình soạn thảo văn bản ASCII tiêu chuẩn hoặc Môi trường phát triển tích hợp (IDE) nằm trên nền tảng máy chủ (phát triển), như trong Hình 12-2 IDE là một tập hợp các công cụ, bao gồm một trình soạn thảo văn bản
ASCII, được tích hợp vào một giao diện người dùng ứng dụng Trong khi bất kỳ trình soạn thảo văn bản ASCII nào đều có thể được sử dụng để viết bất kỳ loại mã nào, độc lập với ngôn ngữ và nền tảng, IDE dành riêng cho nền tảng đó và thường được cung cấp bởi nhà cung cấp của IDE, một nhà sản xuất phần cứng (trong một bộ khởi động bao gồm bảng phần cứng với các công cụ như IDE hoặc trình soạn thảo văn bản), nhà cung cấp hệ điều hành hoặc nhà cung cấp ngôn ngữ (Java, C, v.v.)
2.1.2 Thiết kế có sự hỗ trợ của máy tính (CAD) và phần cứng
Các công cụ thiết kế có sự hỗ trợ của máy tính (CAD) thường được các kỹ sư phần cứng sử dụng để mô phỏng mạch ở cấp độ điện nhằm nghiên cứu hành vi của mạch trong các điều kiện khác nhau trước khi họ thực sự chế tạo mạch
Hình 2-3a: Mẫu mô phỏng Pspice CAD Hình 2-3b: Mẫu mạch Pspice CAD
Thị trường công cụ nhúng
Thị trường công cụ nhúng là một thị trường nhỏ, phân mảnh, với nhiều nhà cung cấp khác nhau hỗ trợ một số tập hợp con của các CPU, hệ điều hành, JVM, v.v được nhúng sẵn có Bất kể nhà cung cấp lớn đến đâu, vẫn chưa có một "cửa hàng tổng hợp" nơi có thể mua tất cả các công cụ cho hầu hết các loại linh kiện cùng loại Về cơ bản, có nhiều bản phân phối khác nhau từ nhiều nhà cung cấp công cụ khác nhau, mỗi nhà cung cấp hỗ trợ nhóm biến thể của riêng họ hoặc hỗ trợ các nhóm biến thể tương tự Các kiến trúc sư hệ thống có trách nhiệm cần phải nghiên cứu và đánh giá các công cụ có sẵn trước khi hoàn thiện thiết kế kiến trúc của họ để đảm bảo rằng cả hai công cụ phù hợp đều có sẵn để phát triển hệ thống và các công cụ có chất lượng cần thiết Chờ đợi một vài tháng để một công cụ được chuyển sang kiến trúc của bạn hoặc để sửa lỗi từ nhà cung cấp sau khi quá trình phát triển đã bắt đầu, không phải là một tình huống tốt
—Dựa trên bài báo “Rắc rối với thị trường công cụ nhúng” của Jack Ganssle
—Lập trình hệ thống được nhúng Tháng 4 năm 2004
Hình 2-3a là ảnh chụp nhanh của một trình mô phỏng mạch tiêu chuẩn phổ biến, được gọi là PSpice Phần mềm mô phỏng mạch này là một biến thể của một trình mô phỏng mạch khác ban đầu được phát triển tại Đại học California, Berkeley có tên là SPICE (Chương trình Mô phỏng với Nhấn mạnh Mạch Tích hợp) PSpice là phiên bản PC của SPICE và là một ví dụ về trình mô phỏng có thể thực hiện một số loại phân tích mạch, chẳng hạn như thoáng qua phi tuyến, một chiều phi tuyến, xoay chiều tuyến tính, nhiễu và biến dạng Như trong Hình 2-3b, các mạch được tạo trong trình mô phỏng này có thể được tạo thành từ nhiều phần tử chủ động và/ hoặc bị động Nhiều công cụ mô phỏng mạch điện có sẵn trên thị trường nói chung tương tự như PSpice về mục đích tổng thể của chúng và chủ yếu khác nhau về những gì có thể thực hiện phân tích, những thành phần mạch có thể được mô phỏng hoặc giao diện của giao diện người dùng của công cụ
Do tầm quan trọng và chi phí liên quan đến việc thiết kế phần cứng, có nhiều kỹ thuật công nghiệp trong đó các công cụ CAD được sử dụng để mô phỏng một mạch Với một bộ mạch phức tạp trong bộ xử lý hoặc trên bo mạch, rất khó, nếu không muốn nói là không thể, thực hiện mô phỏng trên toàn bộ thiết kế, do đó, một hệ thống phân cấp các trình mô phỏng và mô hình thường được sử dụng Trên thực tế, việc sử dụng các mô hình là một trong những yếu tố quan trọng nhất trong thiết kế phần cứng, bất kể hiệu quả hoặc độ chính xác của trình mô phỏng Ở cấp độ cao nhất, một mô hình hành vi của toàn bộ mạch được tạo cho cả mạch tương tự và mạch kỹ thuật số, và được sử dụng để nghiên cứu hành vi của toàn bộ mạch Mô hình hành vi này có thể được tạo bằng một công cụ CAD cung cấp tính năng này, hoặc có thể được viết bằng ngôn ngữ lập trình chuẩn Sau đó, tùy thuộc vào loại và cấu tạo của mạch, các mô hình bổ sung được tạo ra cho các thành phần hoạt động và thụ động riêng lẻ của mạch, cũng như cho bất kỳ phụ thuộc môi trường nào (ví dụ: nhiệt độ) mà mạch có thể có
Ngoài việc sử dụng một số phương pháp cụ thể để viết phương trình mạch cho một mô phỏng cụ thể, chẳng hạn như phương pháp hoạt cảnh hoặc phương pháp nút đã sửa đổi, còn có các kỹ thuật mô phỏng để xử lý các mạch phức tạp bao gồm một hoặc một số kết hợp của:
• Chia các mạch phức tạp hơn thành các mạch nhỏ hơn, và sau đó kết hợp các kết quả
• Sử dụng các đặc tính đặc biệt của một số loại mạch
• Sử dụng vector tốc độ cao và/ hoặc máy tính song song
2.1.3 Công cụ dịch — Bộ tiền xử lý, Phiên dịch, Trình biên dịch và các liên kết
Dịch mã lần đầu tiên được giới thiệu ngắn gọn về một số công cụ được sử dụng trong dịch mã, bao gồm trình tiền xử lý, trình thông dịch, trình biên dịch và trình liên kết Theo đánh giá, sau khi mã nguồn được viết, nó cần được dịch sang mã máy, vì mã máy là ngôn ngữ duy nhất mà phần cứng có thể trực tiếp thực thi Tất cả các ngôn ngữ khác đều cần các công cụ phát triển, để tạo ra mã máy tương ứng mà phần cứng sẽ hiểu được Cơ chế này thường bao gồm một hoặc một số kết hợp của các kỹ thuật tạo mã máy của trình tiền xử lý, dịch và hoặc phiên dịch Những cơ chế này được thực hiện trong nhiều loại công cụ phát triển dịch thuật
Tiền xử lý là một bước tùy chọn xảy ra trước khi dịch hoặc diễn giải mã nguồn và có chức năng thường được thực hiện bởi bộ tiền xử lý Vai trò của bộ tiền xử lý là tổ chức và cấu trúc lại mã nguồn để làm cho việc dịch hoặc giải thích mã này dễ dàng hơn Bộ tiền xử lý có thể là một thực thể riêng biệt, hoặc có thể được tích hợp trong đơn vị biên dịch hoặc phiên dịch
Nhiều ngôn ngữ chuyển đổi mã nguồn, trực tiếp hoặc sau khi đã được xử lý trước, thành mã đích thông qua việc sử dụng trình biên dịch, một chương trình tạo ra một số ngôn ngữ đích, chẳng hạn như mã máy, mã byte Java, v.v., từ ngôn ngữ nguồn, chẳng hạn như
Hình 2-4: Sơ đồ tổng hợp
Một trình biên dịch thường dịch tất cả mã nguồn thành mã đích cùng một lúc Như thường thấy trong các hệ thống nhúng, hầu hết các trình biên dịch được đặt trên máy chủ của lập trình viên và tạo mã đích cho các nền tảng phần cứng khác với nền tảng mà trình biên dịch đang thực sự chạy Các trình biên dịch này thường được gọi là trình biên dịch chéo Trong trường hợp lắp ráp, trình biên dịch hợp ngữ là trình biên dịch chéo chuyên dụng được gọi là trình hợp dịch và sẽ luôn tạo mã máy Các trình biên dịch ngôn ngữ cấp cao khác thường được gọi bằng tên ngôn ngữ cộng với “trình biên dịch” (tức là trình biên dịch Java, trình biên dịch C) Các trình biên dịch ngôn ngữ cấp cao có thể rất khác nhau về những gì được tạo ra Một số tạo mã máy trong khi những người khác tạo các ngôn ngữ cấp cao khác, sau đó yêu cầu những gì được tạo ra phải chạy qua ít nhất một trình biên dịch nữa Vẫn còn các trình biên dịch khác tạo mã hợp ngữ, mã này sau đó phải được chạy thông qua trình hợp dịch
Sau khi hoàn tất quá trình biên dịch trên máy chủ của lập trình viên, tệp mã đích còn lại thường được gọi là tệp đối tượng và có thể chứa bất kỳ thứ gì từ mã máy đến mã byte Java, tùy thuộc vào ngôn ngữ lập trình được sử dụng Như trong Hình 2-5, trình liên kết tích hợp tệp đối tượng này với bất kỳ thư viện hệ thống cần thiết nào khác, tạo ra những gì thường được gọi là tệp nhị phân thực thi, trực tiếp vào bộ nhớ của bo mạch hoặc sẵn sàng được chuyển vào bộ nhớ của hệ thống nhúng đích bởi một bộ nạp
Hình 2-5: Ví dụ C về các bước biên dịch / liên kết và kết quả tệp đối tượng
Đảm bảo chất lượng và kiểm tra thiết kế
Trong các mục tiêu của việc kiểm tra và đảm bảo chất lượng của hệ thống là tìm ra lỗi trong thiết kế và theo dõi xem lỗi đã được sửa chưa Đảm bảo chất lượng và kiểm tra tương tự như gỡ lỗi, được thảo luận trước đó trong chương này, ngoại trừ mục tiêu của việc gỡ lỗi là để sửa các lỗi đã phát hiện Sự khác biệt chính khác giữa gỡ lỗi và kiểm tra hệ thống là việc gỡ lỗi thường xảy ra khi nhà phát triển gặp sự cố khi cố gắng hoàn thành một phần của thiết kế và sau đó là kiểm tra để vượt qua bản sửa lỗi (nghĩa là kiểm tra chỉ để đảm bảo hệ thống hoạt động tối thiểu trong các trường hợp bình thường) Mặt khác,với thử nghiệm các lỗi được phát hiện do cố gắng phá vỡ hệ thống, bao gồm cả thử nghiệm để vượt qua và thử nghiệm để thất bại, nơi các điểm yếu trong hệ thống được thăm dò
Trong quá trình thử nghiệm, các lỗi thường xuất phát từ việc hệ thống không tuân thủ các đặc điểm kiến trúc nghĩa là, hoạt động theo cách mà nó không nên theo tài liệu, không hoạt động theo cách cách nó phải theo tài liệu, hoạt động theo cách không được đề cập trong tài liệu hoặc không có khả năng kiểm tra hệ thống Các loại lỗi gặp phải trong thử nghiệm phụ thuộc vào loại thử nghiệm đang được thực hiện Nói chung, các kỹ thuật thử nghiệm thuộc một trong bốn mô hình: thử nghiệm hộp đen tĩnh, thử nghiệm hộp trắng tĩnh, thử nghiệm hộp đen động hoặc thử nghiệm hộp trắng động (xem ma trận trong Hình 2-9) Kiểm tra hộp đen xảy ra với người kiểm tra không có khả năng hiển thị các hoạt động bên trong của hệ thống (không có sơ đồ, không có mã nguồn, )
Kiểm tra hộp đen dựa trên tài liệu yêu cầu sản phẩm chung, trái ngược với kiểm tra hộp trắng (còn được gọi là kiểm tra hộp trong hoặc hộp kính), trong đó người kiểm tra có quyền truy cập vào mã nguồn, sơ đồ, Thử nghiệm tĩnh được thực hiện khi hệ thống không chạy, trong khi thử nghiệm động được thực hiện khi hệ thống đang chạy
Thử nghiệm với hộp đen Thử nghiệm với hộp trắng
Kiểm tra các thông số kĩ thuật của sản phẩm bằng cách:
1.tìm kiếm các vấn đề cơ bản, sơ suất, thiếu sót ở mức độ cao (tức là coi như mình lầ khách hàng, nghiên cứu các hướng dẫn/tiêu chuẩn hiện có, xem xét và kiểm tra phần mềm tương tự, v.v.)
2.kiểm tra đặc điểm kỹ thuật cấp thấp bằng cách đảm bảo tính đầy đủ, chính xác, độ chính xác, tính nhất quán, mức độ liên quan, tính khả thi,…
Quy trình xem xét phần cứng và mã một cách có phương pháp để tìm ra lỗi mà không cần thực thi
Yêu cầu xác định phần mềm nào và phần cứng bao gồm:
• kiểm tra dữ liệu, kiểm tra thông tin về đầu vào và đầu ra của người dùng
Kiểm tra hệ thống đang chạy trong khi xem mã, sơ đồ, v.v
Trực tiếp kiểm tra mức thấp và mức cao dựa trên kiến thức hoạt động chi tiết,
• kiểm tra điều kiện ranh giới, đó là truy cập các biến và kết xuất bộ nhớ kiểm tra các tình huống ở cạnh các giới hạn hoạt động theo kế hoạch của phần mềm
• kiểm tra ranh giới nội bộ, đó là thử nghiệm lũy thừa của hai, bảng ASCII
Tìm kiếm lỗi tham chiếu dữ liệu, dữ liệu lỗi khai báo, lỗi tính toán, lỗi so sánh, lỗi luồng điều khiển, lỗi tham số chương trình con, lỗi I/O,
• kiểm tra đầu vào, kiểm tra dữ liệu trống, dữ liệu không hợp lệ
• kiểm tra trạng thái, là kiểm tra các chế độ và chuyển đổi giữa các chế độ mà phần mềm đang thực hiện với các biến trạng thái tức là, điều kiện tương tranh, thử nghiệm lặp lại (lý do chính là phát hiện rò rỉ bộ nhớ), ứng suất(đói phần mềm = thấp bộ nhớ, mạng chậm cpu chậm), tải (phần mềm nguồn cấp dữ liệu kết nối nhiều thiết bị ngoại vi, xử lý lượng lớn dữ liệu, web máy chủ có nhiều máy khách truy cập, )
Hình 12-10: Ma trận mô hình kiểm tra
Trong mỗi mô hình (được hiển thị trong Hình 12-10), thử nghiệm có thể được chia nhỏ hơn nữa để bao gồm thử nghiệm đơn vị / mô-đun (thử nghiệm gia tăng các phần tử riêng lẻ trong hệ thống), thử nghiệm tính tương thích (thử nghiệm xem phần tử đó không gây ra sự cố với các phần tử khác trong hệ thống), thử nghiệm tích hợp (thử nghiệm gia tăng các phần tử tích hợp), thử nghiệm hệ thống (thử nghiệm toàn bộ hệ thống nhúng với tất cả các phần tử được tích hợp), thử nghiệm hồi quy (chạy lại các kiểm tra đã vượt qua trước đó sau khi sửa đổi hệ thống) và thử nghiệm sản xuất
(thử nghiệm để đảm bảo rằng việc sản xuất hệ thống không tạo ra lỗi)
Từ các thử nghiệm này, tập hợp các trường hợp thử nghiệm hiệu quả có thể được rút ra để xác minh rằng một hệ thống hoặc cấp độ đáp ứng các thông số kỹ thuật kiến trúc, cũng như xác nhận rằng phần tử đó hoặc hệ thống đáp ứng các yêu cầu thực tế, có thể đã hoặc chưa được phản ánh một cách chính xác hoặc hoàn toàn trong tài liệu Khi các trường hợp thử nghiệm đã được hoàn thành và các thử nghiệm được chạy, cách xử lý kết quả có thể khác nhau tùy thuộc vào tổ chức, nhưng thông thường khác nhau giữa các trường hợp không chính thức, nơi thông tin được trao đổi mà không cần tuân theo bất kỳ quy trình cụ thể nào và đánh giá thiết kế chính thức hoặc đánh giá đồng cấp nơi các nhà phát triển đồng nghiệp trao đổi các yếu tố để kiểm tra, hướng dẫn nơi kỹ sư chịu trách nhiệm chính thức xem qua sơ đồ và mã nguồn, kiểm tra khi ai đó không phải là kỹ sư chịu trách nhiệm thực hiện bước này Các phương pháp và mẫu thử nghiệm cụ thể cho các trường hợp thử nghiệm, cũng như toàn bộ quy trình thử nghiệm, đã được xác định trong một số tiêu chuẩn thử nghiệm và đảm bảo chất lượng phổ biến trong ngành, bao gồm tiêu chuẩn Đảm bảo chất lượng ISO9000, Mô hình trưởng thành (CMM) và chuẩn bị ANSI/IEEE 829, Chạy và Hoàn thành Các tiêu chuẩn kiểm tra
Cuối cùng, cũng như gỡ lỗi, có rất nhiều công cụ tự động hóa và kiểm tra cũng như công nghệ kỹ thuật có thể hộ trợ tốc độ, hiệu quả và độ chính xác của việc kiểm tra các yếu tố khác nhau, bao gồm các công cụ tải, công cụ ứng suất, bộ phun nhiễu, bộ tạo nhiễu, công cụ phân tích, macro, ghi và phát lại, và macro được lập trình bao gồm các công cụ được liệt kê trong bảng 2-1
Các sửa đổi pháp lý tiềm năng (ở Hoa Kỳ) KHÔNG thử nghiệm
Luật của Hoa Kỳ về trách nhiệm sản phẩm được coi là rất nghiêm ngặt, và khuyến nghị rằng những chịu trách nhiệm về việc đảm bảo chất lượng và kiểm tra hệ thống nên được đào tạo về luật trách nhiệm sản phẩm để nhận biết khi nào sử dụng luật để đảm bảo một lỗi nghiêm trọng đã được khắc phục và khi nào thì nhận rằng một lỗi có thể gây ra trách nhiện pháp lý nghiêm trọng cho tổ chức
Các luật chung mà người tiêu dùng có thể kiện về các vấn đề sản phẩm là:
• Vi phạm Hợp đồng (nghĩa là nếu các bản sửa lỗi được nêu trong hợp đồng không được đưa ra kịp thời)
• Vi phạm bảo hành và bảo đảm ngầm định (nghĩa là cung cấp hệ thống mà không có các tính năng đã hứa)
• Trách nhiệm pháp lý nghiêm ngặt và sơ suất đối với thương tích cá nhân hoặc thiệt hại đối với tài sản (tức là do lỗi gây ra thương tích hoặc tử vong cho người dùng)
• Sơ suất (tức là khách hàng mua sản phẩm bị lỗi)
• Khai báo sai và gian lận (tức là sản phẩm được phát hành và bán không đáp ứng được các quyền sở hữu như quảng cáo, dù cố ý hay vô ý)
Hãy nhớ là, các luật này áp dụng cho dù “sản phẩm” của bạn có phải là dịch vụ tư vấn nhúng, công cụ nhúng, thiết bị nhúng thực tế hay phần mềm/phần cứng có thể được tích hợp vào thiết bị
- Dựa trên chương “Hậu quả pháp lý của phần mềm bị lỗi”của Cem Kaner
- Kiểm tra phần mềm máy tính 1999
Kết luận: Duy trì hệ thống nhúng và hơn thế nữa
Chương này giới thiệu một số yêu cầu chính đằng sau việc triển khai một hệ thống nhúng thiết kế, chẳng hạn như hiểu các công cụ phát triển tiện ích, dịch và gỡ lỗi Các công cụ bao gồm IDE và CAD, cũng như trình thông dịch, trình biên dịch và trình liên kết Một loạt các công cụ gỡ lỗi hữu ích cho cả gỡ lỗi và kiểm tra các thiết kế nhúng, từ
ICE phần cứng, trình giả lập ROM và máy hiện sóng đến trình gỡ lỗi phần mềm, trình định cấu hình và màn hình Chương này cũng thảo luận về những gì có thể được mong
Cuối cùng, sau khi một thiết bị nhúng đã được triển khai, vẫn có những trách nhiệm điển hình cần được đáp ứng, chẳng hạn như đào tạo người dùng, hỗ trợ kỹ thuật, cung cấp các bản cập nhật kỹ thuật, sửa lỗi, Ví dụ trong trường hợp đào tạo người dùng, tài liệu kiến trúc có thể được sử dụng tương đối nhanh chóng để làm cơ sở cho các hướng dẫn kỹ thuật, người dùng và đào tạo Tài liệu kiến trúc cũng có thể được sử dụng để đánh giá tác động liên quan đến việc giới thiệu các bản cập nhật (tức là các tính năng mới, sửa lỗi, ) cho sản phẩm khi sản phẩm đang ở hiện trường, giảm thiểu rủi ro thu hồi hoặc sự cố tốn kém, hoặc cuộc kiểm tra của các FAE có thể được yêu cầu tại địa điểm của khách hàng
Trái với suy nghĩ của nhiều người, trách nhiệm của nhóm kỹ sư kéo dài trong suốt vòng đời của thiết bị và không kết thúc khi hệ thống nhúng đã được triển khai tới đồng ruộng Để đảm bảo thành công trong thiết kế hệ thống nhúng, điều quan trọng là phải làm quen với các giai đoạn thiết kế các hệ thống nhúng, đặc biệt là tầm quan trọng của việc tạo ra một cấu trúc đầu tiên Điều này đòi hỏi tất cả các kỹ sư và lập trình viên, bất kể trách nhiệm và nhiệm vụ của họ là gì, phải có nền tảng kỹ thuật vững chắc bằng cách hiểu ở cấp hệ thống tất cả các thành phần chính có thể đi vào thiết kế của bất kỳ hệ thống nhúng nào Điều này có nghĩa là các kỹ sư phần cứng hiểu phần mềm và các kỹ sư phần mềm hiểu phần cứng tại ít nhất là cấp độ hệ thống Điều quan trọng nữa là các nhà thiết kế có trách nhiệm phải áp dụng, hoặc đưa ra phương pháp luận đã được thống nhất để triển khai và kiểm tra hệ thống, sau đó có kỷ luật để tuân theo các quy trình bắt buộc
Tác giả hy vọng rằng bạn đánh giá cao cách tiếp cận kiến trúc của cuốn sách này, và nhận thấy nó là một công cụ hữu ích như một phần giới thiệu toàn diện về thế giới của các hệ thống nhúng thiết kế Có những yêu cầu và ràng buộc riêng liên quan đến việc thiết kế một hệ thống nhúng, chẳng hạn như những yêu cầu và ràng buộc được quyết định bởi chi phí và hiệu suất Việc tạo ra một kiến trúc giải quyết những yêu cầu này rất sớm trong một dự án, cho phép nhóm thiết kế giảm thiểu rủi ro Chỉ vì lý do này, kiến trúc của một thiết bị nhúng sẽ tiếp tục là một trong những yếu tố quan trọng nhất của bất kỳ dự án hệ thống nhúng nào
1 Sự khác biệt giữa máy chủ và mục tiêu là gì?
2 Các công cụ phát triển thường thuộc loại cấp cao nào?
3 [T/F] Một IDE được sử dụng trên đích để giao tiếp với hệ thống máy chủ
5 Ngoài CAD, những kỹ thuật nào khác được sử dụng để thiết kế các mạch điện phức tạp?
6 [a] Bộ tiền xử lý là gì?
[b] Cung cấp một ví dụ trong thế giới thực về cách bộ tiền xử lý được sử dụng liên quan đến ngôn ngữ lập trình
7 [T/F] Một trình biên dịch có thể nằm trên một máy chủ hoặc một mục tiêu, tùy thuộc vào ngôn ngữ
8 Một số tính năng giúp phân biệt nhu cầu biên dịch trong hệ thống nhúng so với trong các loại hệ thống máy tính khác?
9 [a] Tệp đối tượng là gì?
[b] Sự khác biệt giữa trình tải và trình liên kết là gì?
[b] Kể tên ba ngôn ngữ trong thế giới thực yêu cầu thông dịch viên
11 Một thông dịch viên cư trú trên:
B Mục tiêu và vật chủ
E Không có điều nào ở trên.
