Blog

1. Tổng quan về quy trình thiết kế

Bài viết này cung cấp tổng quan về quy trình thiết kế hệ thống nhúng nhằm vào hai mục tiêu: đầu tiên, nó cung cấp cho chúng ta các bước khác nhau trong thiết kế hệ thống máy tính nhúng trước khi chúng ta đi sâu vào nghiên cứu chi tiết từng bước. Thứ hai, nó cho phép chúng ta hiểu hơn về bản thân phương pháp thiết kế.

Một phướng pháp thiết kế rất quan trọng bởi ba lý do như sau. Đầu tiên, nó cho phép chúng ta giữ một bảng ghi chú về một thiết kế để đảm bảo rằng chúng ta đã làm mọi thứ chúng ta cần làm, chẳng hạn như có cần tối ưu hóa hiệu năng hay không hoặc khi nào thực hiện kiểm tra chức năng của thiết kế. Thứ hai, nó cho phép chúng ta phát triển các công cụ thiết kế được hỗ trợ bởi máy tính. Phát triển một công cụ duy nhất để hỗ trợ toàn bộ quá trình thiết kế một hệ thống máy tính nhúng sẽ là một nhiệm vụ khó khăn, nhưng bằng cách chia quy trình thiết kế thành các bước nhỏ có thể quản lý, chúng ta có thể tạo ra các công cụ tự động hóa (hoặc ít nhất là bán tự động hóa) quá trình thiết kế cho mỗi bước trong quy trình. Thứ ba, một phương pháp thiết kế giúp các thành viên của nhóm thiết kế trao đổi với nhau dễ dàng hơn. Bằng cách xác định một quy trình thiết kế tổng thể, các thành viên trong nhóm có thể dễ dàng hiểu những gì họ phải làm, những gì họ sẽ nhận được từ các thành viên khác trong nhóm vào những thời điểm nhất định và những gì họ phải bàn giao khi hoàn thành các bước được giao. Bởi vì phần lớn các hệ thống máy tính nhúng được thiết kế và thực hiện bởi các nhóm, sự phối hợp nhịp nhàng giữa các nhóm thể hiện vai trò quan trọng nhất trong phương pháp thiết kế.

Hình 1‑2 tóm tắt các bước chính trong quy trình thiết kế hệ thống nhúng. Trong luồng thiết kế từ trên xuống, chúng ta bắt đầu với việc đưa ra các yêu cầu thiết kế (Requirements) của hệ thống. Trong bước tiếp theo, đặc tả kỹ thuật (specification), chúng ta tạo ra một bản mô tả chi tiết hơn về những gì chúng ta muốn thiết kế. Tuy nhiên, bản đặc tả chỉ nêu ra cách hệ thống hoạt động mà không phải cách nó được xây dựng thế nào. Các chi tiết bên trong của hệ thống bắt đầu hình thành khi chúng ta phát triển kiến trúc – một sơ đồ khối chỉ ra cấu trúc của hệ thống dưới dạng các khối chức năng. Khi chúng ta xác định các khối chức năng chính cấu thành lên hệ thống chúng ta có thể thiết kế các khối chức năng đó, bao gồm cả các khối chức năng phần mềm và bất kỳ khối chức năng phần cứng chuyên dụng nào mà chúng ta cần. Dựa trên các khối chức năng đó, cuối cùng chúng ta có thể tích hợp chúng lại với nhau để xây dựng một hệ thống hoàn chỉnh.

Hình 1‑2 Các bước chính trong quy trình thiết kế hệ thống máy tính nhúng.

Nhưng các bước trong quy trình thiết chỉ là một trục mà chúng ta có thể xem xét quá trình thiết kế hệ thống máy tính nhúng. Bên cạnh đó chúng ta cũng cần xem xét thêm các mục tiêu chính của thiết kế:

• Chi phí sản xuất
• Hiệu năng (bao gồm tốc độ tính toán và thời hạn một tính toán phải hoàn thành)
• Sự tiêu thụ năng lượng.

Chúng ta cũng cần xem xét các nhiệm vụ mà chúng ta cần thực hiện ở mọi bước trong thiết kế, cụ thể như:

• Chúng ta phải phân tích thiết kế ở mỗi bước để xác định cách chúng ta có thể thỏa mãn các yêu cầu kỹ thuật trong bản đặc tả
• Sau đó chúng ta phải tinh chỉnh thiết kế để đi sâu vào thiết kế chi tiết
• Chúng ta cần kiểm thử thiết kế để đảm bảo rằng nó vẫn đáp ứng được tất cả các mục tiêu của hệ thống chẳng hạn như chi phí, tốc độ, …

1.1.     Yêu cầu thiết kế (Requirements)

Rõ ràng trước khi chúng ta thiết kế một hệ thống, chúng ta cần phải biết những gì mình phải thiết kế. Các giai đoạn đầu tiên của quy trình thiết kế nhằm thu thập những thông tin này để sử dụng cho việc xây dựng kiến trúc và các khối chức năng. Chúng ta thường tiến hành theo hai bước: đầu tiên chúng ta thu thập một bản mô tả không chính thức từ các khách hàng được gọi bản yêu cầu và chúng ta tinh chỉnh các yêu cầu đó thành một bản đặc tả có đủ thông tin để bắt đầu thiết kế kiến trúc của hệ thống.

So sánh yêu cầu và đặc tả kỹ thuật: Việc phân tách phân tích yêu cầu và đặc tả kỹ thuật là cần thiết do sự khác biệt lớn giữa những gì khách hàng mô tả về hệ thống mà họ muốn và những gì mà người kỹ sư cần thiết kế. Người đặt hàng các hệ thống nhúng thường không phải là người có chuyên môn về thiết kế hệ thống nhúng hay sản phẩm chứa hệ thống nhúng đó. Sự hiểu biết của họ về hệ thống nhúng thường dựa trên cách họ hình dung về người dùng tương tác với hệ thống. Họ có thể có những mong muốn không thực tế về những gì có thể thực hiện trong phạm vi ngân sách của họ và họ cũng có thể thể hiện mong muốn của họ bằng ngôn ngữ rất khác so với những gì kỹ sư thiết kế phải làm. Thu thập một tập hợp phù hợp các yêu cầu từ khách hàng và sau đó đưa chúng vào một bản đặc tả chính thức là một cách quản lý quá trình chuyển dịch từ ngôn ngữ của người đặt hàng sang ngôn ngữ của kỹ sư thiết kế.

Các yêu cầu có thể là về đặc điểm chức năng hoặc đặc điểm phi chức năng. Các yêu cầu về đặc điểm phi chức năng của hệ thống nhúng bao gồm:

• Hiệu năng (Performance): hiệu năng có thể là sự kết hợp của hiệu năng mềm như thời gian xấp xỉ để thực hiện một chức mức người dùng và thời hạn cứng mà một hoạt động nhất định phải hoàn thành.
• Chi phí (Cost): Chi phí mục tiêu hoặc giá mua hệ thống hầu như luôn là một nhân tố phải được xem xét khi thiết kế hệ thống nhúng. Chi phí thường có hai thành phần chính: chi phí sản xuất bao gồm chi phí mua linh kiện và chi phí công lắp ráp sản phẩm; chi phí trả trước cho một lần nghiên cứu, thiết kế, phát triển và thử nghiệm sản phẩm NRE (nonrecurring engineering) bao gồm chi phí cho nhân sự và các chi phí khác khi thiết kế hệ thống.
• Kích thước vật lý và trọng lượng: Các đặc tính vật lý của hệ thống có thể thay đổi rất nhiều tùy thuộc vào ứng dụng. Chẳng hạn, một hệ thống điều khiển dây chuyền lắp ráp công nghiệp có thể được thiết kế để phù hợp với giá đỡ kích thước tiêu chuẩn mà không có giới hạn nghiêm ngặt về trọng lượng. Tuy nhiên, một thiết bị cầm tay thường có các yêu cầu chặt chẽ cả về kích thước và trọng lượng.
• Sự tiêu thụ năng lượng: công suất rất quan trọng trong các hệ thống chạy bằng pin và thường cũng quan trọng trong các loại ứng dụng khác. Công suất có thể được chỉ định trong giai đoạn phân tích yêu cầu như thời lượng sử dụng pin vì có thể khách hàng không thể miêu tả công suất theo đơn vị Wat.

Một biểu mẫu yêu cầu đơn giản

Phân tích yêu cầu cho một hệ thống lớn có thể là một công việc phức tạp và tiêu tốn nhiều thời gian. Tuy nhiên, thu thập một lượng thông tin tương đối nhỏ trong một định dạng đơn giản, rõ ràng là khởi đầu tốt để hiểu được các yêu cầu về hệ thống. Để thực hành phương pháp phân tích yêu cầu trong quy trình thiết kế hệ thống, chúng ta sẽ sử dụng một biểu mẫu thu thập yêu cầu đơn giản như chỉ ra trong Hình 1‑3. Mẫu yêu cầu này có thể được điền vào lúc bắt đầu dự án. Chúng ta sau đó có thể sử dụng mẫu yêu cầu này như một danh sách kiểm tra khi xem xét các đặc điểm cơ bản của hệ thống. Hãy xem xét các mục trong biểu mẫu:

• Tên (Name): Thông tin của mục này tuy đơn giản nhưng lại rất hữu ích. Đặt tên cho dự án không chỉ đơn giản trong trao đổi công việc với người khác mà còn có thể cô đọng được mục đích của dự án.
• Mục đích (Purpose): là một đoạn mô tả ngắn gọn một hoặc hai dòng về những gì hệ thống phải làm. Nếu chúng ta có thể mô tả bản chất của hệ thống trong một hoặc hai dòng chứng tỏ chúng đã hiểu đủ rõ về điều chúng ta phải làm.
• Các đầu vào và đầu ra (Inputs and outputs): Hai mục này phức tạp hơn vẻ ngoài của chúng. Các đầu vào và đầu ra của hệ thống bao gồm rất nhiều thông tin chi tiết như:
  • Loại dữ liệu (Types of data): Tín hiệu là tín hiệu điện tương tự hay dữ liệu số? Có các đầu vào cơ khí hay không?
  • Đặc điểm của dữ liệu (Data characteristics): Dữ liệu đến một cách tuần hoàn hay không? Đầu vào từ người dùng có xảy ra thường xuyên hay không? Sử dụng bao nhiều bit cho mỗi phần tử dữ liệu?
  • Các loại thiết bị vào/ra (Types of I/O devices): Có sử dụng nút bấm hay không? Có sử dụng các bộ chuyển đổi tương tự/số hay không? Có dữ liệu hiển thị dạng video hay không?
• Chức năng (Functions): Đây là một đoạn mô tả chi tiết hơn về những gì hệ thống phải làm. Một cách tiếp cận hợp lý là mô tả chức năng của hệ thống theo luồng xử lý tín hiệu từ từ đầu vào đến đầu ra: Khi hệ thống nhận được dữ liệu đầu vào nó sẽ làm gì? Các đầu vào giao diện người dùng ảnh hưởng đến các chức năng hệ thống như thế nào? Các chức năng khác nhau của hệ thống tương tác với nhau như thế nào?
• Hiệu năng (Performance): Nhiều hệ thống máy tính nhúng dành ít nhất một khoảng thời gian để điều khiển các thiết bị vật lý hoặc xử lý dữ liệu đến từ thế giới vật lý. Trong hầu hết các trường hợp này, việc tính toán phải được thực hiện trong một khung thời gian quy định. Điều cần thiết là các yêu cầu về hiệu năng phải được xác định sớm vì chúng phải được đo lường cẩn thận trong quá trình thực hiện để đảm bảo hệ thống hoạt động đúng.
• Chi phí sản xuất (Manufacturing cost): Mục này bao gồm chủ yếu là chi phí của các thành phần phần cứng. Ngay cả khi chúng ta không biết chính xác cần chi bao nhiêu cho các thành phần hệ thống, chúng ta cũng nên có một số ý tưởng về khoảng chi phí cuối cùng. Chi phí có ảnh hưởng đáng kể đến kiến ​​trúc: Một hệ thống có giá bán ở mức 10 đô-la có thể có cấu trúc bên trong rất khác so với hệ thống 100 đô-la.
• Công suất (Power): Tương tự, chúng ta có thể chỉ có một ý tưởng sơ bộ về việc hệ thống có thể tiêu thụ bao nhiêu năng lượng, nhưng một ít thông tin đó có thể giúp người thiết kế đưa ra những quyết định quan trọng về kiến trúc của hệ thống cần thiết kế. Thông thường, quyết định quan trọng nhất là liệu máy sẽ chạy bằng pin hay sử dụng nguồn điện lưới. Hệ thống chạy bằng pin phải được cân nhắc cẩn thận hơn về cách chúng tiêu thụ năng lượng.
• Kích thước vật lý và trọng lượng (Physical size and weight): Chúng ta nên đưa ra một số chỉ dẫn về kích thước vật lý của hệ thống để giúp định hướng các quyết định thiết kế kiến ​​trúc hệ thống. Cho ví dụ, thiết kế một máy tính để bàn có sự linh hoạt hơn nhiều trong việc lựa chọn các linh kiện được sử dụng so với thiết kế một máy ghi âm gắn trên ve áo.

Hình 1‑3 Mẫu thu thập thông tin yêu cầu thiết kế.

Một bản phân tích yêu cầu kỹ lưỡng hơn cho một hệ thống lớn có thể sử dụng một biểu mẫu tương tự như Hình 1‑3 như một bản tóm tắt cho tài liệu mô tả các yêu cầu dài hơn. Sau phần giới thiệu có chứa biểu mẫu này, tài liệu mô tả yêu cầu dài hơn có thể bao gồm chi tiết về từng mục được đề cập trong phần giới thiệu. Ví dụ, mỗi tính năng riêng lẻ được mô tả trong một câu của phần giới thiệu có thể được mô tả chi tiết trong một phần của đặc tả.

Tính thống nhất của các yêu cầu

Sau khi viết các yêu cầu, bạn nên kiểm tra chúng để đảm bảo tính thống nhất giữa các hạng mục, chẳng hạn: bạn có quên gán một chức năng cho đầu vào hoặc đầu ra hay không? Bạn đã xem xét tất cả các chế độ mà bạn muốn hệ thống hoạt động chưa? Bạn có đặt một số tính năng không thực tế vào một hệ thống chi phí thấp và chạy bằng pin hay không?

Để thực hành xây dựng các yêu cầu hệ thống chúng ta cùng xem xét việc tạo ra các yêu cầu cho hệ thống hiển thị bản đồ di chuyển sử dụng GPS trong Ví dụ 1.1.

Dưới đây là một danh sách các yêu cầu ban đầu mà chúng ta có thể nhận được từ khách hàng cho hệ thống hiển thị bản đồ dịch chuyển sử dụng GPS:

• Chức năng (Functionality): Hệ thống này được thiết kế để sử dụng cho các lái xe trên đường cao tốc và mục đích sử dụng tương tự, không sử dụng trong hàng hải hoặc hàng không những mục đích sử dụng đòi hỏi cơ sở dữ liệu và chức năng chuyên biệt hơn. Hệ thống sẽ hiển thị các đường chính và các mốc ranh giới có sẵn trong cơ sở dữ liệu địa hình tiêu chuẩn.
• Giao diện người dùng (User interface): Màn hình phải có độ phân giải tối thiểu 400 × 600 pixel. Thiết bị nên được điều khiển bởi không quá ba nút. Một hệ thống thực đơn (menu) pop-up sẽ mở ra trên màn hình khi các nút được bấm để cho phép người dùng thực hiện các lựa chọn để điều khiển hệ thống.
• Hiệu năng (Performance): Bản đồ sẽ cuộn trơn tru. Khi bật nguồn, màn hình sẽ mất không quá một giây để hiện thị bản đồ và hệ thống có thể xác minh vị trí của nó và hiển thị bản đồ tại vị trí hiện tại trong vòng 15 giây.
• Chi phí (Cost): Giá bán lẻ của một đơn vị không quá 120 đô-la.
• Kích thước và trọng lượng vật lý (Physical size and weight): Thiết bị phải nằm vừa vặn và thoải mái trong lòng bàn tay.
• Tiêu thụ công suất (Power consumption): Thiết bị nên chạy được ít nhất trong tám giờ với bốn cục pin AA, với ít nhất 30 phút trong tám giờ đó bao gồm hoạt động với màn hình được bật.

Lưu ý rằng nhiều trong số các yêu cầu này không được xác định trong các đơn vị kỹ thuật, ví dụ, kích thước vật lý được đo tương đối với một bàn tay, không tính bằng centimet. Mặc dù các yêu cầu này cuối cùng phải được dịch thành những tham số định lượng có thể được sử dụng bởi các kỹ sư thiết kế, việc lưu giữ hồ sơ về những gì khách hàng muốn có thể giúp giải quyết các câu hỏi về đặc điểm kỹ thuật có thể phát sinh sau này trong quá trình thiết kế. Dựa trên các thông tin được thảo luận ở trên chúng ta có thể viết một bảng các yêu cầu cho hệ thống bản đồ di chuyển dùng GPS như sau:

Bảng tóm tắt này đã bổ sung một số yêu cầu dưới dạng thuật ngữ kỹ thuật sẽ được sử dụng cho các kỹ sư thiết kế. Ví dụ, nó cung cấp kích thước định lượng dự kiến của thiết bị. Chi phí sản xuất được lấy từ giá bán bằng cách sử dụng một quy tắc đơn giản: Giá bán gấp bốn đến năm lần giá vốn hàng bán (tức tổng cộng tất cả các chi phí linh kiện).

1.2     Đặc tả kỹ thuật (Specification)

Bản đặc tả kỹ thuật mô tả chính xác hơn về hệ thống cần thiết kế và đóng vai trò là hợp đồng giữa khách hàng và kỹ sư thiết kế. Do đó, bản đặc tả kỹ thuật phải được viết cẩn thận để nó phản ánh chính xác các yêu cầu của khách hàng làm căn cứ trong suốt quá trình thiết kế.

Bản đặc tả kỹ thuật phải đủ dễ hiểu để bất cứ ai cũng có thể xác minh rằng nó thỏa mãn các yêu cầu của hệ thống cần thiết kế cũng như những kỳ vọng của người đặt hàng. Nó cũng phải đủ rõ ràng để các kỹ sư thiết kế biết họ cần phải xây dựng cái gì. Các kỹ sư thiết kế có thể gặp phải một số loại vấn đề khác nhau do thông số kỹ thuật không rõ ràng. Nếu một số tính năng trong một tình huống cụ thể không rõ ràng từ đặc tả, kỹ sư thiết kế có thể thực hiện chức năng sai. Nếu các đặc tính toàn cục của đặc tả là sai hoặc không đầy đủ, kiến trúc hệ thống tổng thể được đề xuất từ đặc tả đó có thể không đủ để thỏa mãn các yêu cầu cần thực hiện.

Một bản đặc tả cho hệ thống hiển thị bản đồ sự dịch chuyển trên cơ sở GPS sẽ bao gồm các thành phần như sau:

• Dữ liệu nhận được từ hệ thống định vị vệ tính GPS;
• Dữ liệu bản đồ;
• Giao diện người dùng;
• Các hoạt động phải được thực hiện để đáp ứng các yêu cầu của người đặt hàng;
• Các hoạt động nền cần thiết để giữ cho hệ thống hoạt động, chẳng hạn sự vận hành của bộ thu GPS.

1.3     Thiết kế kiến trúc (Architecture Design)

Đặc tả không chỉ ra cách hệ thống thực hiện các chức năng được yêu cầu mà chỉ cho biết những gì hệ thống làm. Mô tả cách hệ thống thực hiện các chức năng đó là mục đích của thiết kế kiến trúc. Kiến trúc là một bản kế hoạch chỉ ra cấu trúc tổng thể của hệ thống sẽ được sử dụng sau này để thiết kế các khối chức năng thành phần tạo nên kiến trúc. Việc tạo ra kiến trúc là giai đoạn đầu tiên trong quyas trình kỹ sư thiết kế thiết kế ra hệ thống được đặt hàng.

Để hiểu một bản mô tả kiến trúc là gì, hãy xem kiến trúc được đề xuất cho hệ thống bản đồ hiển thị sự di chuyển trong Ví dụ 1.1. Hình 1‑4 cho thấy một kiến trúc hệ thống dưới dạng sơ đồ khối mô tả các hoạt động chính và luồng dữ liệu giữa chúng. Sơ đồ khối này vẫn còn khá trừu tượng – chúng ta chưa xác định rõ các hoạt động nào sẽ được thực hiện bằng phần mềm chạy trên CPU và những hoạt động nào sẽ được thực hiện bởi phần cứng chuyên dụng, v.v. Tuy nhiên, sơ đồ thể hiện một bước tiến dài trong việc mô tả cách thực hiện các chức năng được mô tả trong bản đặc tả kỹ thuật. Ví dụ, chúng ta thấy rõ rằng hệ thống cần tìm kiếm cơ sở dữ liệu địa hình và hiển thị kết quả ra màn hình. Chúng ta chọn tách hệ thống thành các chức năng như vậy để có khả năng thực hiện chúng song song – thực hiện xuất dữ liệu ra màn hình tách khỏi quá trình tìm kiếm cơ sở dữ liệu có thể giúp hệ thống cập nhật lại màn hình trơn tru hơn.

Hình 1‑4. Sơ đồi khối chức năng của hệ thống bản đồ hiển thị sự dịch chuyển.

Ngay sau khi chúng ta hoàn thành thiết kế một kiến trúc ban đầu không thiên quá nhiều về các chi tiết được triển khai, chúng ta sẽ tinh chỉnh sơ đồ khối hệ thống này thành hai sơ đồ khối: một sơ đồ cho phần cứng và một sơ đồ cho phần mềm. Hai sơ đồ khối đã được tinh chỉnh này được thể hiện trong Hình 1‑5. Sơ đồ khối phần cứng cho thấy rõ rằng chúng ta có một CPU trung tâm được bao quanh bởi các thiết bị I/O và bộ nhớ. Cụ thể, chúng ta đã chọn sử dụng hai bộ nhớ: một bộ đệm khung cho các điểm ảnh được hiển thị và một bộ nhớ chương trình/dữ liệu riêng để CPU sử dụng chung. Sơ đồ khối phần mềm bám sát theo sơ đồ khối hệ thống, nhưng chúng ta đã thêm vào một bộ định thời gian để điều khiển khi nào chúng ta sẽ đọc các nút trên giao diện người dùng và khi nào thì hiển thị dữ liệu lên màn hình. Để có một mô tả kiến trúc thực sự hoàn chỉnh, chúng ta cần sự mô tả chi tiết hơn, chẳng hạn như các đơn vị trong sơ đồ khối phần mềm sẽ được thực hiện ở đâu trong sơ đồ khối phần cứng và khi nào các hoạt động sẽ được thực hiện.

Hình 1‑5. Kiến trúc phần cứng và phần mềm cho hệ thống hiển thị bản đồ sự dịch chuyển.

Các bản mô tả kiến trúc phải được thiết kế để đáp ứng cả hai yêu cầu chức năng và phi chức năng. Tức là, nó không chỉ phải thỏa mãn tất cả các chức năng cần thiết mà còn phải thỏa mãn các tiêu chí về chi phí, tốc độ, công suất và các ràng buộc phi chức năng khác. Bắt đầu với kiến trúc hệ thống và tinh chỉnh nó thành kiến trúc phần cứng và phần mềm là một cách tốt để đảm bảo hệ thống được thiết kế ra đáp ứng tất cả các thông số kỹ thuật. Chúng ta có thể tập trung vào các yếu tố chức năng trong sơ đồ khối hệ thống, sau đó xem xét các ràng buộc phi chức năng khi tạo phần cứng và kiến trúc phần mềm.

Làm thế nào để chúng ta biết rằng kiến trúc phần cứng và phần mềm của chúng ta trên thực tế thỏa mãn ràng buộc về tốc độ, chi phí, v.v. Thường thì chúng ta phải bằng cách nào đó ước tính các thuộc tính của các thành phần của sơ đồ khối, chẳng hạn như các chức năng tìm kiếm và hiển thị thông tin trong hệ thống bản đồ di chuyển. Ước tính chính xác thường được suy ra từ một phần từ kinh nghiệm, bao gồm cả kinh nghiệm thiết kế chung và kinh nghiệm cụ thể với các hệ thống tương tự, của kỹ sư thiết kế. Tuy nhiên, đôi khi chúng ta có thể tạo ra các mô hình đơn giản hóa để giúp chúng ta ước tính chính xác hơn. Ước tính của tất cả các ràng buộc phi chức năng trong giai đoạn thiết kế kiến trúc là rất quan trọng bởi vì các quyết định dựa trên dữ liệu xấu sẽ xuất hiện trong các giai đoạn cuối cùng của thiết kế cho thấy trên thực tế hệ thống không thỏa mãn các đặc tả kỹ thuật.

1.4     Thiết kế các thành phần phần cứng và phần mềm

Mô tả kiến trúc cho chúng ta biết những thành phần chúng ta cần phải thực hiện. Nỗ lực thiết kế những thành phần này là nhằm mục đích xây dựng các thành phần đó phù hợp với kiến trúc và bản đặc tả kỹ thuật. Các thành phần nói chung sẽ bao gồm cả các mảng cổng lập trình phần cứng (FPGA), bo mạch chủ, và các mô-đun phần mềm. Một số thành phần đã được tạo sẵn. Ví dụ, CPU cũng như các chip bộ nhớ và nhiều thành phần khác sẽ là một thành phần tiêu chuẩn trong hầu hết các trường hợp. Trong hệ thống hiển thị bản đồ di chuyển, máy thu GPS là một ví dụ điển hình của một thành phần chuyên dụng tiêu chuẩn được thiết kế trước. Chúng ta cũng có thể sử dụng các mô-đun phần mềm tiêu chuẩn. Một ví dụ điển hình cho mô-đun phần mềm tiêu chuẩn là cơ sở dữ liệu địa hình được nén với hệ số nén rất cao theo một định dạng xác định để tiết kiệm không gian lưu trữ. Đối với cơ sở dữ liệu địa hình tiêu chuẩn như vậy chúng ta cũng thường muốn sử dụng các chương trình tiêu chuẩn để truy cập tới chúng. Sử dụng phần mềm tiêu chuẩn cho các chức năng truy cập này không chỉ giúp chúng ta tiết kiệm thời gian thiết kế mà còn có thể giúp chúng ta đạt được sự thực hiện các chức năng chuyên dụng khác như phần mềm giải nén dữ liệu nhanh hơn. Bên cạnh đó, chúng ta sẽ phải tự thiết kế một số thành phần. Ngay cả khi chúng ta chỉ sử dụng các mạch tích hợp tiêu chuẩn, chúng ta có thể phải thiết kế bản mạch in để kết nối chúng lại với nhau. Chúng ta có thể cũng sẽ phải làm rất nhiều chương trình chuyên dụng theo yêu cầu riêng của hệ thống mà chúng ta đang phát triển. Khi tạo các mô-đun phần mềm nhúng này, chúng ta phải sử dụng chuyên môn của mình để đảm bảo hệ thống chạy đúng theo thời gian thực và nó không chiếm nhiều dung lượng bộ nhớ hơn mức cho phép. Sự tiêu thụ điện năng của phần mềm trong hệ thống vẽ bản đồ di chuyển là đặc biệt quan trọng. Ví dụ, nó có thể cần phải rất cẩn thận về cách hệ thống đọc và ghi bộ nhớ để giảm thiểu công suất. Vì truy cập bộ nhớ là nguồn tiêu thụ năng lượng chủ yếu, các phiên giao dịch bộ nhớ phải được lập lịch cẩn thận để tránh đọc cùng một dữ liệu nhiều lần.

1.5     Tích hợp hệ thống System Integration

Ngay sau khi các thành phần chức năng được xây dựng xong, chúng ta có thể kết hợp chúng lại với nhau thành một hệ thống làm việc hoàn chỉnh. Tất nhiên, giai đoạn này không đơn giản chỉ là lắp ráp mọi thứ lại với nhau. Lỗi thường xuất hiện trong quá trình tích hợp hệ thống. Bằng cách xây dựng hệ thống theo từng giai đoạn và chạy các phép thử nghiệm được chọn đúng cho mỗi giai đoạn, chúng ta thường có thể tìm thấy các lỗi dễ dàng hơn. Nếu chúng ta chỉ gỡ lỗi một vài mô-đun tại một thời điểm, chúng ta có nhiều khả năng phát hiện ra các lỗi đơn giản và sửa chúng. Chỉ sau khi đã sửa sớm các lỗi đơn giản, chúng ta mới có thể dùng các phép kiểm thử khó để phát hiện ra các lỗi phức tạp hơn hoặc các lỗi bị che khuất không thể phát hiện bằng các phép thử đơn giản. Nếu chúng ta đảm bảo được việc thực hiện các giai đoạn thiết kế kiến trúc và thiết kế các mô-đun thành phần đúng quy trình thì giai đoạn lắp ráp hệ thống và kiểm tra chức năng sẽ diễn ra tương đối dễ dàng.

Tích hợp hệ thống là quá trình đầy thách thức vì nó thường rất khó để quan sát hệ thống ở mức đủ chi tiết để xác định chính xác xem cái gì sai bên trong. Bên cạnh đó, các phương tiện gỡ lỗi cho các hệ thống nhúng thường có nhiều giới hạn hơn so với những công cụ dùng cho các hệ thống máy tính để bàn. Kết quả là, xác định lý do tại sao mọi thứ không hoạt động chính xác và làm thế nào chúng có thể được sửa chữa bàn thân nó đã là một thách thức. Cần cẩn thận sử dụng các phương tiện sửa lỗi thích hợp trong quá trình thiết kế từ đó có thể giúp giảm bớt các vấn đề tích hợp hệ thống.

(Dịch từ tài liệu Marilyn  Wolf. , Computers as components: Principles of Embedded Computing Systems Design, 3rd Ed., Morgan Kaufmann publisher, ISBN: 978-1-558-60541-1, 2012)