Những công cụ hoặc tiêu chuẩn nào có thể được sử dụng để cải thiện độ tin cậy của mã C nhúng?

Tôi thường lập trình PIC trong C, thường cho các bộ chuyển đổi chế độ chuyển đổi. Tôi đã nghe nói về các công cụ và tiêu chuẩn phân tích tĩnh khác nhau như MISRA C có thể được sử dụng để giúp cải thiện độ tin cậy của mã. Tôi muốn biết thêm. Những tiêu chuẩn hoặc công cụ nào có thể phù hợp với bối cảnh của tôi?

Xác thực mã nhúng là khó khăn, đặc biệt là khi xử lý các phần tài nguyên giới hạn như PIC. Bạn thường không có sự sang trọng của mã hóa trong các trường hợp thử nghiệm do các ràng buộc ghi nhớ của bộ phận và chương trình "thời gian thực" thường được thực hiện trên các loại thiết bị này.

Dưới đây là một số hướng dẫn của tôi:

1. Viết một thông số nếu không có: Nếu bạn không mã hóa thông số kỹ thuật, hãy ghi lại mã của bạn là gì, đầu vào hợp lệ là gì, đầu ra dự kiến ​​là gì, mỗi thói quen nên mất bao lâu, những gì có thể và không thể nhận được bị đóng băng, vv - một lý thuyết về hoạt động, sơ đồ, bất cứ điều gì tốt hơn không có gì.

2. Nhận xét mã của bạn: Chỉ vì một cái gì đó rõ ràng đối với bạn không có nghĩa là nó rõ ràng (hoặc chính xác) với người khác. Nhận xét bằng ngôn ngữ đơn giản là cần thiết cho cả đánh giá và khả năng duy trì mã.

3. Mã phòng thủ: Không chỉ bao gồm mã cho đầu vào bình thường. Xử lý các đầu vào bị thiếu, các đầu vào nằm ngoài phạm vi, tràn toán học, v.v. - bạn càng bao quát các góc của thiết kế mã của mình, mã sẽ càng ít tự do hơn khi triển khai.

4. Sử dụng các công cụ phân tích tĩnh: Có thể khiêm tốn chỉ có bao nhiêu công cụ lỗi như PC-lint có thể tìm thấy trong mã của bạn. Xem xét một phân tích tĩnh sạch chạy như một điểm khởi đầu tốt cho thử nghiệm nghiêm trọng.

5. Đánh giá ngang hàng là rất cần thiết: Mã của bạn phải sạch sẽ và được ghi chép đầy đủ để có thể được xem xét một cách hiệu quả bởi một bên độc lập. Kiểm tra cái tôi của bạn ở cửa và nghiêm túc xem xét bất kỳ lời chỉ trích hoặc đề xuất nào.

6. Kiểm tra là điều cần thiết: Bạn nên thực hiện xác nhận của riêng mình, cũng như xác thực mã độc lập. Những người khác có thể phá mã của bạn theo những cách bạn không thể tưởng tượng được. Kiểm tra mọi điều kiện hợp lệ và mọi điều kiện không hợp lệ bạn có thể nghĩ đến. Sử dụng PRNG và nạp dữ liệu rác vào. Làm bất cứ điều gì bạn có thể để phá vỡ mọi thứ, sau đó sửa chữa và thử lại. Nếu bạn may mắn, bạn sẽ có thể chạy mã của mình ở chế độ gỡ lỗi và xem lén các thanh ghi và biến - nếu không, bạn sẽ cần phải xảo quyệt và chuyển đổi đèn LED / tín hiệu số để có ý tưởng về trạng thái của bạn thiết bị. Làm bất cứ điều gì cần thiết để có được thông tin phản hồi bạn cần.

7. Nhìn bên dưới mui xe: Đừng ngại nhìn vào mã máy được tạo bởi trình biên dịch C của bạn. Bạn có thể (sẽ?) Tìm những nơi mà mã C đẹp đẽ của bạn đã bị nổ tung thành hàng chục nếu không phải là hàng trăm thao tác, nơi nào đó an toàn (vì chỉ có một dòng mã, phải không?) Mất nhiều thời gian để thực hiện nhiều ngắt đã sa thải và vô hiệu hóa các điều kiện. Nếu một cái gì đó trở nên không hiệu quả khủng khiếp, hãy cấu trúc lại nó và thử lại.

Hầu hết các kỹ thuật tương tự để tạo phần mềm đáng tin cậy trên PC cũng có thể áp dụng cho phát triển nhúng. Rất hữu ích để tách các thuật toán của bạn khỏi mã dành riêng cho phần cứng và kiểm tra riêng các thuật toán đó bằng các thử nghiệm đơn vị, mô phỏng, phân tích tĩnh và các công cụ như Valgrind. Bằng cách đó, có ít mã hơn chỉ được kiểm tra trên phần cứng.

Tôi sẽ không từ bỏ C. Mặc dù các ngôn ngữ như Ada có thể đưa ra một số đảm bảo nhỏ, nhưng thật dễ dàng để rơi vào cái bẫy nghĩ rằng ngôn ngữ hứa hẹn nhiều hơn thực tế.

MISRA-C thực sự rất hữu ích để cải thiện chất lượng mã chung và giảm thiểu lỗi. Chỉ cần chắc chắn rằng bạn đọc và hiểu mọi quy tắc, hầu hết chúng đều tốt, nhưng một vài trong số chúng không có ý nghĩa gì.

Một cảnh báo ở đây. Tài liệu MISRA giả định rằng người đọc là người có kiến ​​thức sâu rộng về ngôn ngữ C. Nếu bạn không có cựu chiến binh C cứng rắn như vậy trong nhóm của mình, nhưng quyết định lấy một bộ phân tích tĩnh và sau đó làm theo một cách mù quáng mọi cảnh báo được đưa ra, rất có thể sẽ dẫn đến mã chất lượng thấp hơn , vì bạn có thể giảm khả năng đọc và đưa ra lỗi do tai nạn. Tôi đã thấy điều này xảy ra rất nhiều lần, chuyển đổi mã thành tuân thủ MISRA không phải là một nhiệm vụ tầm thường.

Có hai phiên bản của tài liệu MISRA-C có thể áp dụng. MISRA-C: 2004, vẫn là tiêu chuẩn thực tế của ngành công nghiệp nhúng hiện tại. Hoặc MISRA-C: 2012 mới hỗ trợ tiêu chuẩn C99. Nếu bạn chưa bao giờ sử dụng MISRA-C trước đây, tôi sẽ khuyên bạn nên thực hiện sau.

Tuy nhiên, hãy lưu ý rằng các nhà cung cấp công cụ thường đề cập đến MISRA-C: 2004 khi họ nói rằng họ đã kiểm tra MISRA (đôi khi họ thậm chí còn đề cập đến phiên bản MISRA-C: 1998 đã lỗi thời). Theo tôi biết, công cụ hỗ trợ cho MISRA-C: 2012 vẫn còn hạn chế. Tôi nghĩ rằng chỉ có một số máy phân tích tĩnh đã triển khai nó cho đến nay: Klocwork, LDRA, PRQA và Polyspace. Có thể nhiều hơn, nhưng bạn chắc chắn cần kiểm tra phiên bản MISRA mà nó hỗ trợ.

Trước khi quyết định, tất nhiên bạn có thể bắt đầu bằng cách đọc tài liệu MISRA và xem những gì nó đòi hỏi. Nó có thể được mua với giá £ 10 từ misra.org , khá phải chăng so với giá cho các tiêu chuẩn ISO.

Mathworks (folks MATLAB) có một công cụ phân tích mã tĩnh gọi là Polyspace .

Cũng như phân tích mã tĩnh, lint và như vậy, tôi sẽ đề nghị định nghĩa và thiết kế cẩn thận các giao diện (với quy trình xem xét chính thức) và phân tích độ bao phủ mã.

Bạn cũng có thể muốn xem hướng dẫn về thiết kế mã quan trọng về an toàn, bao gồm MISRA, nhưng cả các tiêu chuẩn UL1998 và IEC 61508.

Để có câu trả lời hoàn chỉnh cho câu hỏi này, tôi sẽ loại bỏ suy nghĩ về "độ tin cậy của mã" và thay vào đó hãy nghĩ về "độ tin cậy của thiết kế", bởi vì mã chỉ là biểu thức cuối cùng của thiết kế.

Vì vậy, bắt đầu với các yêu cầu và viết và kiểm tra những yêu cầu. Nếu bạn không có tài liệu yêu cầu, hãy chỉ vào một dòng mã ngẫu nhiên và tự hỏi "tại sao dòng đó lại cần thiết?" Nhu cầu về bất kỳ dòng mã nào cuối cùng cũng có thể truy nguyên theo yêu cầu, ngay cả khi nó đơn giản / rõ ràng như "nguồn cung cấp sẽ xuất ra 5VDC nếu đầu vào nằm trong khoảng 12-36VDC." Một cách nghĩ về điều này là nếu dòng mã đó không thể được truy tìm theo yêu cầu, thì làm sao bạn biết đó là mã đúng, hay nó hoàn toàn cần thiết?

Tiếp theo, xác minh thiết kế của bạn. Sẽ ổn nếu nó hoàn toàn nằm trong mã (ví dụ: trong các bình luận), nhưng điều đó làm cho khó biết liệu mã đó có đang thực sự có ý nghĩa gì không. Ví dụ: mã có thể có dòng ghi output = 3 * setpoint / (4 - (current * 5)); là current == 4/5Đầu vào hợp lệ có thể gây ra sự cố? Nên làm gì trong trường hợp này để ngăn chia cho 0? Bạn có tránh các hoạt động hoàn toàn hoặc làm giảm sản lượng thay thế? Có một lưu ý chung trong tài liệu thiết kế của bạn về cách xử lý các trường hợp cạnh như vậy giúp việc xác minh thiết kế ở mức cao hơn dễ dàng hơn nhiều. Vì vậy, bây giờ kiểm tra mã dễ dàng hơn vì đó là vấn đề kiểm tra xem mã có thực hiện đúng thiết kế đó không.

Cùng với đó, kiểm tra mã phải kiểm tra các lỗi phổ biến mà IDE của bạn không mắc phải (bạn đang sử dụng IDE phải không?), Chẳng hạn như '=' khi bạn có nghĩa là '==', thiếu dấu ngoặc làm thay đổi ý nghĩa của 'nếu 'báo cáo, dấu chấm phẩy nơi họ không nên, v.v.

Khi tôi viết bài này, tôi nhận thấy rằng thật khó để tóm tắt nhiều năm đào tạo / kinh nghiệm về chất lượng phần mềm trong một bài viết. Tôi viết mã cho các thiết bị y tế và ở trên là một bản tóm tắt cực kỳ đơn giản về cách chúng ta tiếp cận nó.