數十種工具旨在告訴您您的 C 或 C++ 代碼是否違反 MISRA 規則。但是，雖然識別和解決分析工具標記的違規行為對于單個開發人員來說可能是一項重大挑戰，但它僅代表整個開發團隊合規流程的一部分。

事實上，讓許多人感到驚訝的是，MISRA C:2012 文檔在定義指南之前就包含了六章指南！

回過頭來對違規行為進行詳細分析，很容易看到關于整個過程的更大問題。MISRA 的文檔“MISRA 合規性：2016”比語言子集本身受到的新聞報道要少得多，但它對于了解您選擇的靜態分析工具突出顯示的信息如何與 MISRA 合規應用程序的大局相關聯非常寶貴。

很容易誤解 MISRA 合規性的性質，并假設最小化的違規計數可確保優化的應用程序安全性。但要有效，MISRA 指南需要在一個框架內應用，該框架利用合規代碼的優勢并管理任何必要的偏差，以使合規概念具有可信度。

MISRA 合規性：2016 文檔長達 33 頁，像這樣的短文無法觸及它討論的所有內容。但是，它可以讓我們深入了解合規項目的外觀。這些提示源自 MISRA 合規性文件本身概述的原則，它們反映了一點技術智慧和很多常識。

提示 1. MISRA 合規性需要記錄在案的軟件開發過程

MISRA 指南旨在用于正式軟件開發過程的框架內（如圖 1 所示）。這樣的過程將確保完整、明確和正確的軟件需求，并且所有且僅這些需求都反映在開發生命周期的每個階段創建的人工制品中。

圖 1：結構化開發生命周期對于 MISRA 合規性至關重要，如 LDRA 工具套件的 TBmanager 組件中的“Uniview”所示。（來源：LDRA）

如果您的代碼沒有違反規定但沒有滿足其要求的功能，那么它仍然是糟糕的代碼。

提示 2. 并非所有 MISRA 指南都可以通過分析工具進行檢查

MISRA C:2012 指南引入了一個系統，在該系統下，每條指南都被分類為規則或指令。

通常，規則定義得足夠好，可以通過自動化工具進行檢查，而指令可能更主觀一些。例如，MISRA C:2012 的指令 1.1 要求“程序輸出所依賴的任何實現定義的行為都應記錄并理解”。

在 MISRA C:2012 中，一些規則被標記為“不可判定”，這意味著基本上不可能有一種方法可以確定是否存在違規行為。工具可能會警告潛在的問題，也可能不會。無論哪種方式，都需要某種程度的人工干預。

并非所有工具都相同。有些人會聲稱對規則的覆蓋范圍比其他人多，而有些人則無法進行更微妙的侵權。顯示“無違規”的工具可能實際上是在說“沒有違規，除了我沒有發現的那些”。

牛津詞典對“工具”的定義是“用來幫助完成工作的東西”。工具有幫助——它們不會為你完成這項工作。

提示 3. 指南只有在有執行計劃時才有用

對于大多數指南，最簡單、最可靠和最具成本效益的實施方式是使用靜態分析工具、編譯器或兩者的組合（參見圖 2）。

圖 2：使用 LDRA 靜態分析工具強制遵守 MISRA C:2012（來源：LDRA）

對于這些指南，重要的是要確保要使用的工具已被證明是合適的，并且它的類型和版本是指定和固定的。

對于那些需要手動驗證的指南，還必須制定執行計劃。

提示 4. “偏差”不是一個骯臟的詞

對于任何現實生活中的嵌入式應用程序，很可能一些違規行為是不可避免的。如果對由此產生的應用程序的任何合規性聲明是可信的，則必須通過明確定義的流程授權管理這些違規行為，并由適當的“偏差記錄”文檔支持。

這些偏差記錄需要包括違反的準則、這種/這些違反的理由、偏差適用的情況以及它在代碼庫中的應用位置。

Tip 5. 采用的代碼不能被忽略

與功能安全的嵌入式軟件相關的許多文檔和許多標準都是從“綠地”項目的假設開始的。在現實生活中，開發人員需要利用內部遺留代碼或第三方代碼，例如設備驅動程序、數學庫或圖形庫。

盡管將 MISRA 準則追溯應用于此類代碼顯然是不切實際的，但要聲稱符合 MISRA，重要的是要確保這種所謂的“采用的代碼”不會損害整個系統的安全性。

許多根據 ISO 26262、IEC 61508 和 DO-178C 等標準開發的功能安全系統都利用 MISRA 語言子集，這并非巧合，而且很容易假設 MISRA 合規性僅適用于這些環境。

但那將是謬誤。同樣真實的是，除了語言子集本身的指導方針之外，在 MISRA 合規之前要滿足的許多基本要求可以合理地歸結為一種常識方法，以及對“正確行事”的奉獻精神。這不能是關鍵系統社區的專屬特權，因為系統在有動力可靠地工作之前不必是關鍵的。

審核編輯：郭婷