3.10 Hệ thống nhúng và thời gian thực

Tổng quan và động lực

Một hệ thống nhúng là phần mềm chạy trên một thiết bị thay vì trên một máy tính đa dụng. Nó sống bên trong một chiếc ô tô, máy tạo nhịp tim, bộ điều nhiệt, robot nhà máy, hay một bộ dẫn đường. Phần mềm được dành riêng cho thiết bị đó, và thiết bị thường có giới hạn chặt về bộ nhớ, sức mạnh xử lý và năng lượng. Bạn không phải lúc nào cũng thêm được tài nguyên bằng cách bấm một nút trong bảng điều khiển đám mây. Những gì bạn phát hành thường là những gì chạy trong nhiều năm.

Một hệ thống thời gian thực là hệ thống mà tính đúng đắn phụ thuộc vào thời gian, không chỉ vào việc tạo ra câu trả lời đúng. Một bộ điều khiển túi khí tính ra lệnh bung hoàn hảo nhưng trễ một giây là đã thất bại hoàn toàn. Công việc thời gian thực thêm một câu hỏi khó vào mọi tác vụ: liệu nó có xong trước hạn chót, mọi lần, trong trường hợp xấu nhất không? Đây là một kỷ luật khác với tư duy ưu tiên thông lượng phổ biến trong phần mềm web và đám mây.

Với một tổ chức lớn, điều này quan trọng hơn vẻ ngoài ban đầu. Doanh nghiệp xây ô tô kết nối, thiết bị y tế, bộ điều khiển công nghiệp, và hàng tỷ thiết bị Internet vạn vật (IoT). Chính phủ vận hành nền tảng quốc phòng, hàng không điện tử, bộ điều khiển lưới điện, và cơ quan quản lý y tế. Trong các miền này, một khiếm khuyết phần mềm có thể gây thương tích cho con người, dừng một dây chuyền sản xuất, hoặc làm tổn hại an ninh quốc gia. Các quy tắc ở đây chặt chẽ hơn, việc kiểm thử khó hơn, và các tiêu chuẩn có ràng buộc pháp lý. Chương này giúp bạn xây dựng phần mềm đúng, kịp thời, an toàn và bảo mật dưới các ràng buộc thực. Nó liên hệ với xây dựng phần mềm (chương 2.9), hệ thống phân tán (chương 3.3), khả năng mở rộng và hiệu năng (chương 3.5), bảo mật hạ tầng và đám mây (chương 4.3), và bảo trì phần mềm (chương 3.7).

Các nguyên tắc chính

Thời gian là một yêu cầu về tính đúng đắn, không phải điều tốt nếu có về hiệu năng. Một câu trả lời muộn có thể là một câu trả lời sai.
Thiết kế cho trường hợp xấu nhất, không phải trường hợp trung bình. Các bảo đảm thời gian thực dựa trên hành vi trường hợp xấu nhất, không phải tốc độ điển hình.
Tính xác định thắng tốc độ thô. Một hệ thống dự đoán được, luôn đáp ứng hạn chót, thắng một hệ thống nhanh hơn nhưng đôi khi trễ.
Tài nguyên là hữu hạn và cố định. Hãy lập ngân sách bộ nhớ, chu kỳ CPU và năng lượng một cách có chủ đích như lập ngân sách tiền.
An toàn và bảo mật được kỹ thuật hóa vào, không thêm sau. Trong các miền chịu quy định, bạn phải chứng minh công việc của mình, không chỉ khẳng định chất lượng.
Phần cứng là một phần của hệ thống. Bạn không thể suy luận về phần mềm mà không suy luận về con chip, cảm biến và vật lý.
Cập nhật tại hiện trường là một năng lực vòng đời, không phải chuyện nghĩ sau. Các thiết bị ngoài thế giới thực cần một cách an toàn để nhận các bản sửa.

Khuyến nghị

Phân loại mỗi yêu cầu thời gian là cứng, chắc hay mềm

Không phải hạn chót nào cũng như nhau. Một hạn chót thời gian thực cứng không bao giờ được bỏ lỡ, vì một lần trễ gây thất bại hệ thống hoặc tác hại: hãy nghĩ đến điều khiển động cơ hay các bề mặt điều khiển bay. Một hạn chót chắc chịu được những lần trễ hiếm, nhưng một kết quả muộn là vô dụng và bị bỏ đi. Một hạn chót thời gian thực mềm suy giảm giá trị nhẹ nhàng: một khung hình video đến hơi muộn làm giảm chất lượng nhưng không gây thảm họa. Hãy gắn nhãn mọi tác vụ nhạy cảm với thời gian bằng lớp của nó, vì công sức, mức độ chặt chẽ của kiểm thử và chi phí khác nhau rất nhiều. Hai thuộc tính mô tả hành vi thời gian. Độ trễ là khoảng chậm giữa một sự kiện và phản hồi. Jitter là sự biến thiên của độ trễ đó từ lần xảy ra này sang lần khác. Các hệ thống thời gian thực cứng quan tâm đến việc giới hạn jitter nhiều như hạ độ trễ, vì khả năng dự đoán là thứ cho phép bạn chứng minh một hạn chót luôn được đáp ứng.

Chọn nền tảng thực thi có chủ đích: RTOS hay bare metal

Bạn có hai nền tảng chính. Phần sụn bare-metal chạy trực tiếp trên phần cứng không có hệ điều hành, dùng một vòng lặp đơn giản và các trình xử lý ngắt. Đó là lựa chọn nhỏ nhất và dễ dự đoán nhất, và phù hợp với các thiết bị nhỏ xíu có một nhiệm vụ rõ ràng. Một hệ điều hành thời gian thực (RTOS) là một hệ điều hành nhỏ lập lịch các tác vụ theo mức ưu tiên và bảo đảm giới hạn thời gian. Nó cho bạn nhiều tác vụ, một bộ lập lịch, và các dịch vụ như bộ định thời và hàng đợi thông điệp, trong khi giữ thời gian dự đoán được. Hãy chọn RTOS khi bạn có nhiều tác vụ đồng thời với các hạn chót khác nhau. Chọn bare metal khi thiết bị rất hạn chế hoặc thời gian phải đơn giản một cách có thể chứng minh. Với công việc thời gian thực cứng, hãy ưu tiên bộ lập lịch ưu tiên có thể ngắt (preemptive), dựa trên mức ưu tiên, và phân tích nó bằng một phương pháp như lập lịch tốc độ-đơn điệu (rate-monotonic), gán mức ưu tiên theo tần suất tác vụ và cho phép bạn chứng minh tập tác vụ có thể lập lịch được.

Lập ngân sách bộ nhớ, CPU và năng lượng như các tài nguyên hạng nhất

Hãy coi mỗi tài nguyên khan hiếm là một ngân sách với trần cứng. Với bộ nhớ, ưu tiên cấp phát tĩnh hơn cấp phát động trên heap, vì bộ nhớ động có thể phân mảnh và có thể thất bại không đoán trước đúng lúc tệ nhất. Nhiều tiêu chuẩn an toàn hạn chế hoặc cấm dùng heap sau khi khởi động chính vì lý do này. Với CPU, hãy đo thời gian thực thi trường hợp xấu nhất (WCET), thời gian dài nhất một tác vụ có thể mất, và lập lịch theo con số đó, không phải trung bình. Với năng lượng, hãy nhớ rằng nhiều thiết bị chạy bằng pin hoặc thu năng lượng, nên hãy thiết kế chu kỳ làm việc, trạng thái ngủ và sự kiện đánh thức để đạt một ngân sách năng lượng phải kéo dài nhiều tháng hoặc nhiều năm. Hãy viết các ngân sách này ra và rà soát chúng như bất kỳ yêu cầu nào khác.

Xử lý ngắt và đồng thời với kỷ luật nghiêm ngặt

Một ngắt là một tín hiệu phần cứng tạm dừng công việc hiện tại để chạy một trình xử lý ngay lập tức. Ngắt là cách thiết bị phản ứng tức thì với thế giới, và chúng là nguồn lớn của các lỗi tinh vi. Hãy giữ trình xử lý ngắn nhất có thể: xác nhận sự kiện, cất giữ dữ liệu tối thiểu, và hoãn công việc thực sự sang một tác vụ thường. Vì một ngắt có thể kích hoạt giữa hai lệnh bất kỳ, bạn phải bảo vệ dữ liệu dùng chung khỏi điều kiện tranh đua một cách cẩn thận. Hãy dùng các kỹ thuật không khóa, các vùng tới hạn ngắn, hoặc các nguyên thủy được hiểu rõ, và đề phòng đảo ngược ưu tiên, nơi một tác vụ ưu tiên thấp giữ khóa chặn một tác vụ ưu tiên cao. Sự đồng thời này chia sẻ cách suy luận của chương 3.3, nhưng với thời gian chặt hơn và không có chỗ cho một lần thử lại.

Viết trình điều khiển thiết bị cô lập chi tiết phần cứng

Một trình điều khiển thiết bị là tầng phần mềm nói chuyện với một phần cứng cụ thể: một cảm biến, một bộ radio, một bộ điều khiển động cơ. Hãy giữ mã đặc thù phần cứng sau một giao diện sạch, để phần còn lại của phần mềm phụ thuộc vào một trừu tượng ổn định thay vì địa chỉ thanh ghi. Điều này làm mã kiểm thử được ngoài mục tiêu, dễ chuyển đổi hơn khi một con chip hết hàng, và đơn giản hơn để suy luận. Hãy lập tài liệu mọi giả định về thời gian, thứ tự byte và các điều kỳ quặc của phần cứng, vì đây là những chi tiết gây ra thất bại tại hiện trường. Đây là kỷ luật xây dựng của chương 2.9 được áp dụng ở nơi một bit sai có thể làm đứng một động cơ.

Áp dụng tiêu chuẩn an toàn chức năng điều chỉnh miền của bạn

Nếu thiết bị của bạn có thể gây hại cho con người hoặc tài sản, một tiêu chuẩn an toàn chức năng có lẽ áp dụng, và nó thường là luật. IEC 61508 là tiêu chuẩn chung cho an toàn của các hệ thống điện tử và là cha của nhiều tiêu chuẩn khác. ISO 26262 điều chỉnh an toàn xe đường bộ. DO-178C điều chỉnh phần mềm trên không trong hàng không dân dụng. IEC 62304 điều chỉnh phần mềm thiết bị y tế. Về lập trình, MISRA C là một bộ quy tắc được dùng rộng rãi hạn chế các tính năng rủi ro của ngôn ngữ C để làm mã an toàn hơn và dễ phân tích hơn. Các tiêu chuẩn này đòi hỏi truy vết từ yêu cầu đến mã đến kiểm thử, các quy trình xác định, và bằng chứng bạn có thể trao cho kiểm toán viên hoặc cơ quan quản lý. Hãy áp dụng đúng tiêu chuẩn sớm, vì trang bị dấu vết giấy tờ sau này rất đau đớn và đôi khi không thể.

Kiểm thử bằng mô phỏng và phần cứng trong vòng lặp

Bạn không thể kiểm thử phần mềm nhúng theo cách bạn kiểm thử một ứng dụng web. Hãy xây một chiến lược nhiều tầng. Chạy kiểm thử đơn vị trên một máy tính thường đối với giao diện trừu tượng phần cứng. Dùng mô phỏng để mô hình thiết bị và môi trường của nó khi phần cứng thật khan hiếm hoặc nguy hiểm để vận hành. Rồi dùng kiểm thử phần cứng trong vòng lặp (HIL), nơi bộ điều khiển thật chạy đối với một phiên bản mô phỏng của hệ thống vật lý nó điều khiển, để bạn kiểm thử an toàn các điều kiện lỗi như cảm biến kẹt hay tải đột ngột. Hãy tự động hóa các bài kiểm thử này trong đường ống của bạn để mọi thay đổi được kiểm tra dưới điều kiện thực tế trước khi đến một thiết bị.

Thiết kế cập nhật qua không khí và bảo mật thiết bị từ ngày đầu

Các thiết bị ngoài hiện trường sẽ cần các bản sửa, vì vậy hãy lên kế hoạch cho cập nhật qua không khí (OTA): một cách phân phối phần sụn mới một cách an toàn qua mạng. Một thiết kế OTA an toàn ký mật mã từng bản cập nhật, xác minh chữ ký trước khi cài, cập nhật nguyên tử, và có thể hoàn tác về một ảnh tốt đã biết nếu ảnh mới không khởi động được. Hãy kết hợp điều này với các nguyên tắc bảo mật của chương 4.3, điều chỉnh cho phần cứng hạn chế. Dùng một gốc tin cậy phần cứng và khởi động bảo mật để chỉ phần sụn đã ký mới chạy. Mã hóa dữ liệu khi truyền và khi lưu. Đổi thông tin xác thực mặc định và tắt các giao diện không dùng. Một đội thiết bị IoT là một hệ thống phân tán với bề mặt tấn công khổng lồ, và một mật khẩu mặc định yếu có thể làm tổn hại hàng triệu thiết bị cùng lúc.

Đánh đổi: ưu và nhược điểm

Lựa chọn	Ưu điểm	Nhược điểm / chi phí
RTOS	Đa nhiệm, lập lịch ưu tiên, dịch vụ thời gian	Chi phí chung, dấu chân lớn hơn, đường cong học
Bare metal	Nhỏ nhất, dễ dự đoán nhất, kiểm soát toàn bộ	Khó mở rộng cho nhiều tác vụ, nhiều việc thủ công hơn
Cấp phát tĩnh	Dự đoán được, không phân mảnh, thân thiện an toàn	Kém linh hoạt, phải định cỡ mọi thứ từ trước
Chứng nhận an toàn chính thức	Tiếp cận thị trường hợp pháp, bằng chứng chặt chẽ, tin cậy cao hơn	Chi phí thời gian và tiền lớn, lặp chậm hơn
Cập nhật OTA	Sửa và cải thiện thiết bị tại hiện trường, kéo dài tuổi thọ	Hạ tầng cập nhật, gánh nặng bảo mật, rủi ro hoàn tác

Đánh đổi chủ đạo là giữa khả năng dự đoán và tính linh hoạt. Mọi thứ làm cho một hệ thống đa dụng tiện lợi (bộ nhớ động, thu gom rác nền, lập lịch nỗ lực tốt nhất, tài nguyên co giãn) đều chống lại bảo đảm rằng một tác vụ luôn xong đúng giờ trong một dấu chân cố định. Kỹ thuật nhúng và thời gian thực cố ý từ bỏ tính linh hoạt để mua tính xác định và an toàn. Kỹ năng là chỉ chi sự đánh đổi đó ở nơi hạn chót hoặc rủi ro thực sự đòi hỏi, và giữ các phần linh hoạt, thay đổi nhanh hơn (như phần phụ trợ đám mây của thiết bị) ở phía bên kia của một ranh giới sạch.

Câu hỏi để thảo luận với đội của bạn

Bạn có đo jitter, hay chỉ độ trễ trung bình, trên các đường tới hạn về thời gian của mình? Tính đúng đắn thời gian thực cứng dựa trên việc giới hạn sự biến thiên của thời gian phản hồi (jitter), không chỉ hạ độ trễ điển hình, vì khả năng dự đoán là thứ cho phép bạn chứng minh một hạn chót luôn được đáp ứng. Một vòng điều khiển có trung bình thấp nhưng thỉnh thoảng có đỉnh lớn vẫn có thể trễ hạn chót và gây hại, và trung bình sẽ che giấu điều đó. Hãy mang các số đo của độ phân tán, bao gồm trường hợp xấu nhất, cho mỗi tác vụ tới hạn về thời gian, và gắn nhãn từng cái là cứng, chắc hay mềm để mức độ chặt chẽ của kiểm thử khớp với hậu quả của một lần trễ. Mọi thứ tiện lợi trong các hệ thống đa dụng (bộ nhớ động, thu gom rác, lập lịch nỗ lực tốt nhất) đều tấn công khả năng dự đoán, nên chúng ở ngoài đường cứng. Nếu bạn chỉ báo cáo trung bình, bạn không thể trung thực tuyên bố một hạn chót cứng được đáp ứng.
Lựa chọn RTOS-hay-bare-metal của bạn có còn đúng không, và bạn có chứng minh được tập tác vụ lập lịch được không? Nền tảng thực thi là quyết định cần xem lại khi thiết bị lớn lên: bare metal nhỏ nhất và dễ dự đoán nhất cho một nhiệm vụ rõ ràng, trong khi một RTOS xứng đáng với chi phí chung của nó khi bạn có nhiều tác vụ đồng thời với các hạn chót khác nhau. Với công việc thời gian thực cứng, chương này chỉ về bộ lập lịch ưu tiên có thể ngắt được phân tích bằng phương pháp như lập lịch tốc độ-đơn điệu, cho phép bạn chứng minh các tác vụ vừa vặn thay vì hy vọng. Hãy mang tập tác vụ hiện tại, tần suất của chúng, và thời gian thực thi trường hợp xấu nhất, rồi kiểm tra liệu khả năng lập lịch có thực sự đứng vững hay các tác vụ đã âm thầm tích tụ vượt quá những gì nền tảng bảo đảm được. Hãy đề phòng đảo ngược ưu tiên, nơi một tác vụ ưu tiên thấp giữ khóa làm đình trệ một tác vụ ưu tiên cao. Chọn nền tảng theo thói quen thay vì theo tập tác vụ là cách các bảo đảm thời gian xói mòn trong im lặng.
Ranh giới chính xác giữa thiết bị xác định và phần phụ trợ đám mây linh hoạt nằm ở đâu, và nó có đủ sạch để di chuyển nhanh ở một bên mà không gây nguy hiểm cho bên kia không? Đánh đổi chủ đạo của chương từ bỏ tính linh hoạt để mua tính xác định và an toàn, và kỹ năng là chỉ chi sự đánh đổi đó ở nơi hạn chót hoặc rủi ro thực sự đòi hỏi. Một ranh giới sạch cho phép phần sụn quan trọng về an toàn giữ bảo thủ và được chứng nhận trong khi phần phụ trợ đám mây lặp nhanh, để cả hai tiến hóa theo nhịp an toàn riêng. Hãy mang kiến trúc của bạn và xác định đường nối đó: cái gì phải được chứng minh xác định và cập nhật qua một đường đã ký, đã xác minh, so với cái gì có thể đổi hằng tuần trên máy chủ. Làm mờ ranh giới kéo các thói quen kiểu đám mây (cấp phát động, thời gian nỗ lực tốt nhất) vào đường điều khiển, hoặc làm chậm không cần thiết phần phụ trợ theo nhịp của phần sụn. Làm đúng ranh giới là thứ giữ nguyên cả bằng chứng an toàn lẫn tốc độ phân phối.
Tiêu chuẩn an toàn chức năng nào điều chỉnh từng sản phẩm, và bằng chứng hiện tại cách xa những gì một kiểm toán viên chấp nhận bao nhiêu? Tiêu chuẩn (IEC 61508, ISO 26262 cho xe đường bộ, DO-178C cho phần mềm trên không, IEC 62304 cho thiết bị y tế) thường là luật, và nó đòi hỏi truy vết từ yêu cầu đến mã đến kiểm thử mà bạn không thể làm giả vào lúc cuối. Với một đội lớn, rủi ro là các nhóm áp dụng dấu vết giấy tờ không đồng đều, nên một dòng sản phẩm sẵn sàng kiểm toán trong khi dòng khác phát hiện giữa chừng chứng nhận rằng các yêu cầu của nó chưa bao giờ được truy vết. Lực kéo đối lập là tốc độ: truy vết đầy đủ và thực thi MISRA C làm chậm việc lặp hằng ngày, và một đội chịu áp lực hạn chót bị cám dỗ hoãn bằng chứng đến “sau”. Hãy mang ma trận truy vết hiện tại, các phát hiện phân tích tĩnh còn mở, và một phân tích khoảng cách trung thực so với mức bảo đảm mục tiêu. Trong bối cảnh doanh nghiệp và chính phủ, hãy thêm thời gian chờ chứng nhận và kỳ vọng của kiểm toán viên, vì trang bị bằng chứng sau thiết kế là chậm, tốn kém và đôi khi không thể, và một chứng nhận bị trượt có thể chặn hoàn toàn việc tiếp cận thị trường.
Nếu một khiếm khuyết nghiêm trọng được tìm thấy ở thiết bị ngoài hiện trường ngày mai, bạn sửa an toàn trên cả đội thiết bị nhanh đến đâu, và bạn đã diễn tập hoàn tác chưa? Một thiết bị bạn không thể vá trở thành trách nhiệm an toàn và bảo mật vĩnh viễn, và một đợt thu hồi vật lý tốn gấp nhiều bậc so với một bản cập nhật qua không khí có ký. Căng thẳng là một cơ chế cập nhật cẩu thả bản thân nó là bề mặt tấn công và rủi ro biến thiết bị thành cục gạch: một đường OTA cài ảnh không ký, hoặc không hoàn tác được một lần khởi động hỏng, có thể biến một bản phát hành xấu thành hàng triệu thiết bị chết. Hãy mang thiết kế cập nhật của bạn (ký mật mã, xác minh chữ ký trước khi cài, cài nguyên tử, hoàn tác tự động về một ảnh tốt đã biết), tình trạng khởi động bảo mật và gốc tin cậy phần cứng, và lần cuối ai đó thực sự thực hành một lần hoàn tác trên phần cứng thật. Với một đội thiết bị doanh nghiệp hoặc công, hãy thêm ai chịu trách nhiệm về các khóa ký và bạn sẽ thu hồi một khóa bị xâm phạm thế nào, vì một khóa bị rò rỉ hay một thông tin xác thực mặc định dùng chung có thể làm tổn hại cả đội thiết bị cùng lúc.
Ngân sách bộ nhớ, CPU và năng lượng của bạn có được viết ra với trần cứng không, và chiến lược kiểm thử của bạn có thực hành cả mô phỏng lẫn phần cứng thật không? Các bảo đảm thời gian thực dựa trên thời gian thực thi trường hợp xấu nhất và một dấu chân tài nguyên cố định, không phải hành vi trung bình, nên một lần cấp phát heap không có ngân sách hay một tải trường hợp xấu nhất chưa kiểm thử là nơi tính xác định âm thầm xói mòn. Với một đội lớn, mối nguy là sự trôi dạt: các tác vụ tích tụ, bộ nhớ nhích lên, và không ai sở hữu ngân sách cho đến khi một thiết bị hỏng tại hiện trường sau nhiều tuần chạy liên tục. Đánh đổi là độ bao phủ so với chi phí, vì một giàn phần cứng trong vòng lặp tiêm lỗi như cảm biến kẹt thì đắt để xây, trong khi mô phỏng thuần túy che giấu các lỗi thời gian chỉ xuất hiện trên con chip thật. Hãy mang các ngân sách đã lập tài liệu, thời gian thực thi trường hợp xấu nhất đo được đối chiếu với chúng, và bằng chứng rằng đường ống của bạn chạy kiểm thử đơn vị trên tầng trừu tượng, mô phỏng và phần cứng trong vòng lặp trước một bản phát hành. Trong bối cảnh chịu quy định và chính phủ, hãy gắn điều này với độ bao phủ kiểm thử cấu trúc mà tiêu chuẩn yêu cầu, vì kiểm toán viên sẽ muốn bằng chứng rằng các điều kiện lỗi đã được thực hành, không phải lời bảo đảm rằng trường hợp trung bình trông ổn.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Tốc độ và sự sống còn chi phối, nên hãy chọn một RTOS nhẹ hoặc một vòng lặp bare-metal đơn giản, cấm cấp phát động sau khởi động, và đo thời gian trường hợp xấu nhất của một vòng tới hạn của bạn thay vì đuổi theo ngân sách chứng nhận bạn không có. Bỏ qua các quy trình an toàn chức năng chính thức trừ khi thị trường của bạn ép, nhưng đừng bao giờ bỏ qua cập nhật qua không khí có ký với hoàn tác tự động: một công ty non trẻ không thể sống sót qua một đợt thu hồi tại hiện trường, và một bản sửa từ xa là sự khác biệt giữa một đêm tồi và một sản phẩm chết. Giữ phần sụn thiết bị nhỏ và bảo thủ để các kỹ sư khan hiếm của bạn không phải duy trì một đường ống họ không kham nổi.

Doanh nghiệp nhỏ. Không có chuyên gia nhúng trong biên chế, hãy dựa vào các mô-đun đã được chứng minh, thiết kế tham chiếu và bản phân phối RTOS của nhà cung cấp thay vì tự viết bộ lập lịch hay bộ nạp khởi động. Hãy đóng khung lựa chọn xây-so-với-mua quanh việc ai sẽ vá thiết bị trong thập kỷ tới: một bộ bảo mật và cập nhật mua sẵn bạn dựa vào được thắng một bộ làm riêng mà không ai còn lại duy trì được. Hãy coi mật khẩu mặc định, giao diện gỡ lỗi mở và cập nhật không ký là những thất bại có khả năng làm hại bạn nhất, vì chúng rẻ để ngăn và tai hại để phát hiện tại hiện trường.

Doanh nghiệp lớn. Vấn đề là sự nhất quán qua nhiều dòng sản phẩm và đội: một chính sách nền tảng thực thi dùng chung, các mẫu ngân sách tài nguyên chung, MISRA C và phân tích tĩnh được thực thi, và một nền tảng cập nhật qua không khí cùng khởi động bảo mật được chứng nhận để mỗi nhóm không phát minh lại. Hãy ngân sách tường minh gánh nặng an toàn chức năng và phần cứng trong vòng lặp, chuẩn hóa giao diện trừu tượng phần cứng để một con chip hết hàng không làm mắc kẹt một sản phẩm, và quản lý bằng chứng thời gian, sản phẩm an toàn và tư thế bảo mật của đội thiết bị như các tài sản được quản trị thay vì truyền miệng của từng đội. Một thông tin xác thực mặc định yếu trên cả đội thiết bị là trách nhiệm ở quy mô doanh nghiệp, nên hãy tập trung quản lý thông tin xác thực và khóa.

Chính phủ. Quy tắc mua sắm, minh bạch và trách nhiệm giải trình công định hình mọi lựa chọn. Hãy yêu cầu nhà cung cấp phát triển phần mềm trên không, y tế hay quốc phòng theo tiêu chuẩn điều chỉnh (DO-178C, IEC 62304, IEC 61508) ở mức bảo đảm khớp với mối nguy, và giao bằng chứng truy vết cùng độ bao phủ cấu trúc mà kiểm toán viên sẽ rà soát. Đòi hỏi khởi động bảo mật, gốc tin cậy phần cứng và quy trình cập nhật tại hiện trường được kiểm soát, có ký, vì một bản cập nhật chưa xác minh cho một hệ thống bay hay lưới điện là không chấp nhận được. Ưu tiên các hợp đồng trao quyền đối với mã nguồn, sản phẩm an toàn, và khả năng tái chứng nhận với nhà cung cấp thứ hai, để việc một nhà cung cấp phá sản không làm mắc kẹt một hệ thống mà công chúng phụ thuộc hàng thập kỷ.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp phần cứng nhỏ xây máy đo chất lượng không khí chạy pin viết phần sụn trên một RTOS nhẹ với một tập tác vụ cố định và không cấp phát động sau khởi động, để thiết bị được phát hành là thiết bị chạy nhiều năm bằng một pin cúc áo. Ngay cả khi không có ngân sách chứng nhận, đội đo thời gian trường hợp xấu nhất của vòng đọc cảm biến và kiểm thử thiết bị với các điều kiện lỗi được tiêm trên giàn thử trước mỗi bản phát hành. Cập nhật qua không khí có ký với hoàn tác tự động cho phép họ sửa một khiếm khuyết trên mọi thiết bị đã bán, nên một số đọc sai tại hiện trường không có nghĩa là một đợt thu hồi mà công ty non trẻ không thể sống sót.

Doanh nghiệp lớn. Một nhà sản xuất xe kết nối xây bộ điều khiển phanh điện tử. Vòng điều khiển thời gian thực cứng chạy trên một RTOS với lập lịch tốc độ-đơn điệu và bộ nhớ tĩnh, và mỗi tác vụ mang một thời gian thực thi trường hợp xấu nhất đo được. Đội phát triển theo ISO 26262 với truy vết đầy đủ từ yêu cầu đến mã đến kiểm thử, và thực thi MISRA C bằng phân tích tĩnh trên mỗi commit. Một giàn phần cứng trong vòng lặp phát lại hàng nghìn kịch bản đường đi, bao gồm lỗi cảm biến được tiêm, trước khi bất kỳ phần sụn nào được phát hành. Cập nhật OTA có ký cho phép công ty sửa một khiếm khuyết trên cả đội xe mà không cần thu hồi tốn kém, với hoàn tác tự động nếu một chiếc xe không khởi động được ảnh mới.

Chính phủ. Một cơ quan hàng không quốc gia chứng nhận một máy tính quản lý chuyến bay mới. Nhà cung cấp phát triển phần mềm trên không theo DO-178C ở mức bảo đảm khớp với mối nguy, tạo ra bằng chứng về độ bao phủ yêu cầu và độ bao phủ kiểm thử cấu trúc mà kiểm toán viên rà soát. Thời gian được chứng minh xác định dưới tải trường hợp xấu nhất, với độ trễ ngắt bị giới hạn và không cấp phát động sau khởi động. Khởi động bảo mật và một gốc tin cậy phần cứng bảo đảm chỉ phần sụn đã ký, được chứng nhận mới chạy. Cập nhật tại hiện trường theo một quy trình kiểm soát, có ký, vì một bản cập nhật chưa xác minh cho một hệ thống bay là không chấp nhận được.

Luận chứng kinh doanh: động lực, ROI và TCO

Luận chứng kinh doanh bị chi phối bởi chi phí của thất bại và chi phí tiếp cận một thị trường. Trong các miền chịu quy định, bạn hoàn toàn không thể bán sản phẩm nếu không có chứng nhận an toàn, nên chi phí quy trình đơn giản là giá vé vào cửa. Ngoài ra, các khiếm khuyết trong phần cứng tại hiện trường cực kỳ đắt: một đợt thu hồi vật lý tốn kém hơn nhiều so với một bản vá nóng trên đám mây, và một sự cố an toàn mang trách nhiệm pháp lý, tiền phạt quy định và thiệt hại danh tiếng có thể chấm dứt một dòng sản phẩm. Xây dựng an toàn, tính xác định và khả năng cập nhật vào từ đầu là rẻ so với việc phát hiện sự vắng mặt của chúng ngoài hiện trường.

Hãy đóng khung lợi tức đầu tư quanh các đợt thu hồi được tránh, chứng nhận nhanh hơn và tuổi thọ thiết bị dài hơn. Một năng lực OTA vững biến nhiều đợt thu hồi lẽ ra xảy ra thành các bản sửa từ xa chi phí thấp, và mỗi đợt thu hồi được tránh có thể trả cho toàn bộ chương trình cập nhật. Phân tích WCET chặt chẽ và lập ngân sách tài nguyên cho phép bạn phát hành trên phần cứng rẻ hơn với sự tự tin, hạ chi phí mỗi đơn vị qua một đội thiết bị lớn. Về tổng chi phí sở hữu, hãy nhớ rằng các thiết bị này sống nhiều năm hay nhiều thập kỷ: gánh nặng bảo trì, vá bảo mật và hỗ trợ (chương 3.7) làm nhỏ bé việc xây dựng ban đầu. Thiết kế cho khả năng cập nhật, trừu tượng phần cứng rõ ràng và ngân sách có tài liệu là thứ giữ cho cái đuôi dài đó có thể gánh được.

Phản mẫu và cạm bẫy

Tối ưu cho trường hợp trung bình. Đáp ứng hạn chót “thường xuyên” là thất bại một yêu cầu thời gian thực cứng.
Cấp phát động trong đường điều khiển. Phân mảnh heap gây ra một thất bại chỉ xuất hiện sau nhiều tuần chạy liên tục.
Trình xử lý ngắt béo. Đặt xử lý nặng trong một ngắt làm vượt ngân sách thời gian và tạo điều kiện tranh đua.
Phớt lờ tiêu chuẩn cho đến khi kiểm toán. Trang bị truy vết và bằng chứng muộn là chậm, tốn kém và đôi khi không thể.
Phát hành không có đường cập nhật. Một thiết bị bạn không thể vá trở thành trách nhiệm bảo mật và an toàn vĩnh viễn.
Mật khẩu mặc định và giao diện mở. Một thông tin xác thực yếu biến cả đội thiết bị IoT thành một botnet.
Chỉ kiểm thử trên trình mô phỏng hoặc chỉ trên phần cứng. Mỗi cái che giấu lỗi mà cái kia sẽ bắt; bạn cần cả hai.
Coi phần cứng là vấn đề của người khác. Thời gian, thứ tự byte và những điều kỳ quặc của cảm biến là mối quan tâm của phần mềm ở đây.

Mô hình trưởng thành

Mức 1: Khởi đầu. Thời gian được hy vọng chứ không được phân tích. Bộ nhớ được cấp phát động tùy ý. Không tiêu chuẩn an toàn chức năng nào được theo. Kiểm thử là thủ công và chỉ trên thiết bị. Thiết bị không thể cập nhật sau khi phát hành, nên một khiếm khuyết tại hiện trường nghĩa là thu hồi hoặc trách nhiệm vĩnh viễn.
Mức 2: Phát triển. Một số tác vụ có thời gian đo được và một RTOS cơ bản hoặc vòng lặp có cấu trúc đã có, nhưng thực hành khác nhau theo từng đội. Hướng dẫn lập trình tồn tại nhưng không được thực thi. Kiểm thử bao gồm một chút mô phỏng. Một đường cập nhật thủ công, rủi ro tồn tại trên một số sản phẩm và không trên số khác. Thói quen tốt có mặt nhưng không nhất quán, và không gì bảo đảm dòng sản phẩm kế tiếp thừa hưởng chúng.
Mức 3: Chuẩn hóa. Yêu cầu thời gian được phân loại là cứng, chắc hoặc mềm, và được phân tích bằng thời gian thực thi trường hợp xấu nhất và một phương pháp lập lịch, được lập tài liệu và thực thi toàn tổ chức. Ngân sách tài nguyên cho bộ nhớ, CPU và năng lượng được viết ra với trần cứng. Tiêu chuẩn an toàn chức năng điều chỉnh được tuân theo với truy vết từ yêu cầu đến mã đến kiểm thử, và MISRA C hoặc tương đương được thực thi bằng phân tích tĩnh trên mỗi commit. Kiểm thử phần cứng trong vòng lặp chạy trong đường ống. Cập nhật qua không khí có ký, nguyên tử với hoàn tác và khởi động bảo mật là đường cơ sở bắt buộc ở mọi nơi.
Mức 4: Quản lý. Tổ chức đo và kiểm soát hệ sinh thái nhúng theo các đường cơ sở. Nó theo dõi biên thời gian thực thi trường hợp xấu nhất, phân bố jitter, tỷ lệ trễ hạn chót, khoảng dư bộ nhớ và năng lượng, các phát hiện phân tích tĩnh còn mở, độ bao phủ bằng chứng chứng nhận, và tỷ lệ thành công cùng hoàn tác của cập nhật qua không khí, và so sánh chúng với mục tiêu đã thống nhất. Sự trôi so với ngân sách tài nguyên hay thời gian kích hoạt hành động trước khi một thiết bị hỏng tại hiện trường, và quyết định phát hành đi hay không đi dựa trên dữ liệu này thay vì phán đoán tại chỗ. Các nhà quản lý thấy được dòng sản phẩm nào sẵn sàng kiểm toán và dòng nào đang hướng tới một hạn chót bị lỡ hay ngân sách bị vượt.
Mức 5: Điều phối. Tính xác định, bằng chứng an toàn và bảo mật được xác minh liên tục và tự động hóa. Tiêm lỗi và phần cứng trong vòng lặp chạy trên mọi thay đổi, và sản phẩm chứng nhận được tạo ra như sản phẩm phụ của quy trình. Đội thiết bị được giám sát, vá và cập nhật an toàn ở quy mô lớn suốt vòng đời dịch vụ dài. Tổ chức điều chỉnh nền tảng thực thi, ngân sách tài nguyên và việc áp dụng tiêu chuẩn khi các con chip hết hàng, các mối đe dọa tiến hóa, và quy định thay đổi, cân bằng lại toàn bộ danh mục thiết bị dựa trên bằng chứng thay vì phản ứng với từng cuộc khủng hoảng riêng lẻ.

Ý tưởng để thảo luận

Tác vụ nào của thiết bị bạn thực sự là thời gian thực cứng, và bạn có thể chứng minh mỗi cái luôn đáp ứng hạn chót không?
Bạn có biết thời gian thực thi trường hợp xấu nhất của vòng điều khiển tới hạn của mình, hay chỉ trung bình của nó?
Tiêu chuẩn an toàn chức năng nào điều chỉnh sản phẩm của bạn, và bằng chứng hiện tại của bạn cách xa những gì nó đòi hỏi bao nhiêu?
Nếu một khiếm khuyết nghiêm trọng được tìm thấy ở một thiết bị ngoài hiện trường ngày mai, bạn sẽ sửa nó thế nào, và nhanh đến đâu?
Cấp phát bộ nhớ động còn tồn tại ở đâu trong đường điều khiển của bạn, và điều gì xảy ra nếu nó thất bại ở giờ thứ 1000?
Đội thiết bị IoT của bạn sẽ chống chịu thế nào trước kẻ tấn công tìm ra một thông tin xác thực mặc định dùng chung?

Những điểm cần ghi nhớ

Phần mềm nhúng chạy trên phần cứng hạn chế, và tính đúng đắn thời gian thực phụ thuộc vào thời gian, không chỉ vào câu trả lời đúng.
Phân loại mỗi hạn chót là cứng, chắc hay mềm, và thiết kế cho thời gian trường hợp xấu nhất, jitter có giới hạn, và tính xác định hơn tốc độ thô.
Chọn RTOS hay bare metal có chủ đích, và lập ngân sách bộ nhớ, CPU và năng lượng như các tài nguyên cố định, hạng nhất.
Giữ trình xử lý ngắt nhỏ xíu, bảo vệ dữ liệu dùng chung, và cô lập phần cứng sau các giao diện trình điều khiển sạch, kiểm thử được.
Áp dụng sớm tiêu chuẩn an toàn chức năng mà miền của bạn yêu cầu (IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C), với truy vết đầy đủ.
Kiểm thử bằng mô phỏng và phần cứng trong vòng lặp, và xây dựng cập nhật OTA bảo mật, có ký, có khả năng hoàn tác cùng bảo mật thiết bị từ ngày đầu.

Tài liệu tham khảo và đọc thêm

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
ISO 26262, Road Vehicles: Functional Safety
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
IEC 62304, Medical Device Software: Software Life Cycle Processes
MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Michael Barr và Anthony Massa, Programming Embedded Systems
Elecia White, Making Embedded Systems
Jane W. S. Liu, Real-Time Systems
Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
Colin Walls, Embedded Software: The Works
Philip Koopman, Better Embedded System Software
Hướng dẫn bảo mật Internet vạn vật (IoT) của OWASP