汽車越來越依賴電子產品，制造商也越來越多地轉向電子產品和軟件方面的創新，以賦予他們競爭優勢。一輛現代豪華汽車可能有多達 100 個不同的嵌入式處理器，運行超過 1 億行代碼。有了這么多的軟件，基本上不可能把它弄好。如今，據估計 60-70% 的汽車召回涉及軟件。

汽車系統中軟件缺陷的風險很高，因為軟件控制著車輛的許多安全關鍵方面，包括油門、變速箱和制動器。因此，安全關鍵型汽車軟件的開發需要嚴格的標準和縝密的方法。

2011 年，ISO 26262 作為開發安全關鍵型汽車電子系統的國際標準發布，其在全球范圍內的使用正在增加。它基于更通用的 IEC 61508 安全標準，但引入了針對汽車的改進。本文試圖總結標準中對嵌入式軟件開發人員最重要的一些關鍵方面。它首先簡要介紹了 ISO 26262，并描述了如何使用一般工具來幫助進行認證。接下來描述了工具如何獲得用于認證的資格。上一節討論的關鍵要點是，該標準的大部分內容都涉及健壯的軟件開發，并且如果使用得當，

ISO 26262

本文檔使用術語 ISO 26262 或“標準”來表示 ISO 26262 中涉及軟件的部分；特別是 ISO 26262-6:2011 道路車輛 — 功能安全 — 第 6 部分：軟件級別的產品開發。

ISO 26262 是一個基于風險的標準。雖然它承認不可能將風險降至零，但它要求對風險進行定性評估，并采取措施將風險降至“合理可行的最低水平”（ALARP）。

ISO 26262 中使用的詞匯涉及故障、錯誤和故障，其中“故障可以表現為錯誤……而錯誤最終會導致故障”。要理解的最重要的術語是“汽車安全完整性等級”或 ASIL。ASIL 是對電子元件風險的分類。D 級代表風險最高的部件，A 級代表最低風險（當風險被認為低于 ASIL A 時，使用附加標簽 QM）。該級別是通過遵循適用于危害的評估過程來分配的。每個潛在危險事件都按其可能造成的傷害嚴重程度進行分類，其中 SIL0 表示沒有傷害，而 SIL3 表示對生命的威脅。評估中的其他重要因素是暴露，范圍從 E0（極低概率）到 E4（非常可能），

ASIL 是通過綜合考慮這些因素來確定的。很明顯，在嚴重性、暴露性和可控性方面得分較高的危險將被指定為 ASIL D。但是，如果發生概率非常低，則可以將嚴重性較高的危險指定為 ASIL A。

一旦 ASIL 被確定為危險，它就會被減輕危險的安全目標和由此產生的安全要求繼承。然后 ASIL 規定了軟件的最低測試要求。

使用工具幫助認證

ISO 26262 明確承認軟件驗證工具對于滿足測試要求至關重要。因此，該標準要求此類工具本身是合格的。需要注意的重要一點是，使用的工具本身可能不完善，這些不完善可能會破壞整個系統的安全案例，因此該標準要求評估工具置信度 （TCL）。這是通過評估兩件事來確定的：

如果測試工具失敗，則無法滿足測試要求的可能性，以及

用戶可以檢測到工具故障的概率

該值的范圍可以從 TCL1（最低置信度）到 TCL3（最高置信度）。兩個因素用于確定 TCL：工具影響 （TI） 和工具錯誤檢測 （TD）。

工具影響用于描述工具中潛在故障的后果。TI1 用于有爭議的工具本身故障 a） 不能導致系統故障，并且 b） 不能防止故障被檢測到。否則使用 TI2。

TD 是對工具報告故障的能力的置信度評估，其中 TD1 表示最低置信度，TD3 表示最高置信度。

一旦評估了工具置信度和錯誤檢測，就可以根據表 1 中的信息確定 TCL。

例如，考慮一個虛構的動態分析工具 Cov，它可用于測量通過在給定測試套件上運行軟件實現的代碼覆蓋率。假設 ASIL 為 D（風險最高），相應的安全要求是測試套件必須達到 100% 的分支覆蓋率。

Cov 的工具影響顯然是 TI2，因為如果它未能正確報告覆蓋率指標，則可能無法滿足代碼覆蓋率要求。

判斷工具錯誤檢測可能很棘手。假設 Cov 有一個缺點，它有時無法檢測代碼的某些部分，因此無法測量這些部分的代碼覆蓋率，并且在這種情況下它沒有發出警報，而是簡單地從其報告中省略了該信息。沒有經驗的工具用戶可能不會注意到遺漏，因此可能會無意中錯過覆蓋目標。在這種情況下，工具可能會被判斷為 TD2。

因此，參考表 1，Cov 的 TCL 將為 TCL2。

工具資質

ISO 26262 規定具有 TCL1 的工具不需要進一步鑒定，但 TCL2 和 TCL3 都要求必須使用至少一種工具鑒定方法，才能正確聲稱該工具合格。四種資格認證方法是：

使用信心增加，這意味著該工具已成功用于類似項目的跟蹤記錄。

對工具開發過程的評價，意味著工具開發者一直小心翼翼地遵循一個高質量的軟件開發過程。

軟件工具的驗證，意味著該工具已經過嚴格的驗證協議。

按照安全標準進行開發，即在開發過程中遵循嚴格的開發標準（如 ISO 26262 本身）。

對于較高的 ASIL 級別，強烈推薦后兩種方法，因為它們產生高置信度。

工具鑒定并非微不足道，而且通常超出了大多數嵌入式軟件項目本身的范圍。幸運的是，大多數關心 ISO 26262 的工具供應商已經完成了獲得認證的工作。最好的情況是供應商已經獲得了專門從事該領域的獨立機構的資格。獨立認證意味著供應商已成功滿足相當苛刻的要求，不僅讓工具用戶對其質量充滿信心，而且為這些用戶節省了大量的認證工作。

當然，要獲得給定嵌入式系統的 ISO 26262 認證，開發人員必須自己制作案例，因此他們必須收集所有相關材料，包括所有工具資格。大多數供應商將提供一個“認證工具包”，其中包含該材料的易于使用的形式。

靜態分析工具和 ISO 26262

ISO 26262 不要求使用任何特定類別的工具；相反，它指定了代碼應該具有的屬性，但通常只列出可用于提供證據證明代碼確實具有這些屬性的方法。在許多情況下，工具的使用實際上是強制性的（例如，如果不使用現代工具，基本上不可能收集準確的代碼覆蓋率指標）。在其他情況下，可能不清楚是否有可用的工具可以提供幫助。

與靜態分析工具最相關的標準部分是第 8 節：軟件單元設計和實現。靜態分析工具最明顯的應用之一是驗證軟件是否符合第 5.4.7 節規定和第 8.4.3.d 節要求的編碼標準。汽車領域最好的例子當然是 MISRA C。自從早期版本首次發明以來，發現此類違規一直是靜態分析工具的優勢。

最新一代的靜態分析工具仍然能夠發現違反編碼標準的情況，但它們還具有更多功能。它們的主要目的是發現嚴重的編程錯誤，例如那些可能導致程序崩潰或陷入未定義行為的錯誤。這些工具的設計足夠靈活，可以使用它們來滿足 ISO 26262 的其他一些要求。

最相關的部分之一是 8.4.4，其中列出了“在源代碼級別進行軟件單元設計和實現的設計原則……”以實現包括正確執行順序、健壯性甚至代碼可讀性在內的屬性。第 8.4.5 節繼續列出應該用于驗證軟件是否符合要求的技術。列出的技術之一是靜態代碼分析。

ISO 26262 在幾個方面引用了“穩健性”的概念。在軟件單元設計和實現的上下文中，魯棒性被認為包括防止“不可信的值、執行錯誤、被零除以及數據流和控制流中的錯誤”（8.4.4）。軟件單元測試 （9.4.2） 和軟件集成與測試 （10.4.3） 的穩健性特征包括“不存在無法訪問的軟件、有效的錯誤檢測和處理”。

總結穩健性要求的一種合理方式是，應盡量減少可預防的嚴重軟件缺陷的數量。這正是高級靜態分析工具的最大優勢。

粗略地說，這些工具從解析代碼開始，然后創建整個程序的高保真模型。發現缺陷的分析通過以各種方式遍歷模型尋找異常來進行。最復雜的算法通過探索代碼路徑來模擬程序的執行，但它們不是使用具體值來表示執行狀態，而是使用一組抽象方程來模擬程序屬性。

這些工具最重要的特性是，它們可以探索比最復雜的測試方案所能探索的更多的執行路徑。即使代碼已經過嚴格的覆蓋要求測試，例如完整的 MCDC（ISO 26262 規定的最嚴苛的要求），也不能保證完全的路徑覆蓋。原則上，高級靜態分析工具可以保證 100% 的路徑覆蓋（盡管在實踐中，通常會做出犧牲以實現合理的可擴展性和精度）。因此，他們能夠并且確實發現了傳統測試遺漏的缺陷。此外，它們可以在開發周期的早期應用，甚至在編寫單元測試之前。眾所周知，越早發現bug，修復越便宜，

結論

任何安全關鍵編碼標準（尤其是 ISO 26262）的動機都是為了將??軟件故障對 ALARP 的風險降低到盡可能低的程度。這意味著不僅要遵守標準的最低要求，還要應用最佳實踐技術來實現高質量。先進的靜態分析工具的特性使其不僅在遵守法律條文方面非常寶貴，而且對于保持其精神 - 開發健壯和可靠的軟件。

審核編輯：郭婷