聊聊軟體工具置信度

作者：劉釗江；微信號：zhjliu

本文為汽車電子設計系列，由國內工程師撰寫一些心得體會，有空的時候刊登出來，希望閱讀的汽車電子工程師參與討論和提供不同意見的，希望對國內汽車電子工程師的成長有價值。

功能安全標準ISO 26262-8明確規定了對軟體工具的置信度要求。為什麼會提出這些要求？有哪些關鍵點？應該如何實施？本文將為你獨家解讀。

背景

功能安全的開發過程中會用到多種多樣的軟體工具。如果軟體工具在使用過程中出現了功能異常，就有可能影響功能安全。這是需要對軟體工具置信度進行論證的根本原因。

那麼，哪些軟體工具需要進行論證呢？ISO 26262-8的11.4.1節的描述是：「a software tool for the development of a system, or its hardware orsoftware elements」，應該說範圍很明確。

關鍵點

軟體工具置信度論證，主要包含計劃（Plan）、分級（Classification）、鑒定（Qualification）和確認評審（Confirmation Review）4個環節。對於論證範圍內的每一種軟體工具，從流程上來說這4個環節都是不可省略的。

一、計劃軟體工具的使用，主要包括確定軟體工具的版本號、配置以及它可能影響的所有安全需求中的最高ASIL等級。這個環節的目的就是對需要用到的軟體工具進行精確定位。

二、分級，是為了確定軟體工具的置信度水平（Tool Confidence Level，TCL）。置信度水平越高，就越有可能影響功能安全，這在下一個鑒定環節也有所體現。通過分析軟體工具的功能（輸入、輸出），從工具影響（Tool Impact，TI）和工具錯誤探測（Tool error Detection，TD）兩個方面進行評估：

• TI：軟體工具功能異常影響安全需求的可能性（有、無）；
• TD：防止或探測軟體工具功能異常的置信度（高、中、低）。

然後，依據下表來確定置信度水平：

請注意，以上結論並不是絕對的，具體問題還需具體分析。Cadence公司的模擬/混合信號工具鏈實施的是TCL1認證，這是因為相對軟體設計工具而言，硬體設計工具顯然具有更高的錯誤探測置信度。

三、分級之後，對TCL2和TCL3的軟體工具需要進行鑒定，而TCL1的軟體工具可以跳過此環節。鑒定方法見下表：

對上述a、b、c、d四種鑒定方法而言：

• 使用中積累置信度：需要特別注意軟體工具的版本、配置及bug記錄；
• 工具開發流程評估：從搜集證據的角度來說，這種方法最容易實施；
• 軟體工具確認：主要通過測試進行，需要考慮異常運行條件；
• 按照安全標準開發：自己開發的工具可考慮採用此方法。

不難發現，c、d方法的實施難度和a、b方法完全不在一個層面。但當你進行高ASIL等級的開發時，不可避免的會面對c、d的要求。怎麼辦？如果你擔心技術難度太大又或者項目周期太緊，你可以藉助軟體工具供應商的力量。目前主流的功能安全軟體設計工具、測試工具及編譯器均有符合ISO 26262要求的版本面世，你可以放心大膽的使用。當然，這樣的軟體工具一般價格也不便宜。

四、確認評審依據ISO 26262-2的相關要求進行。需要特別注意的是，只對ASIL C和ASIL D的開發有強制進行確認評審的要求。

實施建議

論證軟體工具置信度，無非就是橫向和縱向兩種方式。所謂橫向實施，就是每個環節出一份報告，這份報告里包含了所有軟體工具的信息；所謂縱向實施，就是每一種軟體工具的論證都合在一份報告里，包括全部4個環節。

這兩種方法各有利弊。橫向實施把同一階段的任務集中在一起，更有利於開展工作；縱向實施把同一工具的論據集中在一起，更有利於維護更新。

另外，要特彆強調一下論據復用。在首次進行軟體工具置信度論證時，正所謂萬事開頭難，工作量非常大。但有了基礎之後，產品變更設計或者其它項目進行功能安全開發時，只要使用的軟體工具沒有發生變化，其論據就可以重複使用，這樣能節省大量的時間精力。當然，確認評審還是要重新做。

（個人觀點，僅供參考；如有異議，歡迎討論。）