沒有工具和軟件就無法建造房屋。IEC 61508談到了兩種類型的軟件工具。作為應用程序的一部分運行的在線工具，以及在開發或制造階段使用的離線工具。在線軟件工具與安全系統中的任何其他軟件具有相同的要求，但是用于開發或測試產品中軟件的離線軟件工具呢？離線軟件工具包括編譯器、編輯器、靜態分析工具和需求管理工具等。本博客討論了與 IEC 61508、ISO 26262 和 D0-178C/D0-330 等標準中的離線軟件工具相關的要求。

我注意到，與工具相關的功能安全要求遠比網絡安全等其他高完整性領域要繁重得多。大多數網絡安全標準幾乎沒有與工具相關的要求，這讓我感到驚訝，因為它們沒有與集成電路開發相關的要求，而集成電路是大多數系統的基礎。

下圖顯示了與汽車 ISO 26262 要求兼容的過程。首先，列出了您計劃使用的所有工具。然后，如果您的開發過程中有其他東西會檢測到工具輸出中的錯誤，則無需對工具進行進一步分析，如下面的流程圖所示。雖然這不是嚴格的IEC 61508標準，但我喜歡這種方法，因為對于大多數工具來說，它提供了一個快速簡便的退出點，官方流程最終到達，但經過更多步驟。

圖1 - 基于ISO 26262要求的簡化流程圖

回到IEC 61508流程，有3類定義的工具

T1 – 對可執行代碼沒有影響的工具。IEC 61508-4：2010中給出的示例包括文本編輯器和需求管理工具。也許與文本中給出的示例更一致的描述是不用于生成代碼或驗證代碼的工具，但即便如此，也很難說文本編輯器只是一個 T1 工具。

T2 – 僅影響可執行代碼驗證的工具，并且不能將錯誤注入代碼，但可能導致錯誤丟失，例如靜態時序分析工具

T3 – 可以在代碼中放置錯誤的工具，例如編譯器

第一個要求是應管理工具的使用。這通常意味著在制定軟件安全計劃時，您應該列出您計劃使用的所有工具、它們的用途以及您計劃使用的工具版本。 還需要說明該工具的理由。

接下來，根據上述定義將工具排名為 T1、T2 和 T3。如果一個工具被列為 T2 或 T3，那么您需要考慮該工具如何出錯，以及開發過程中還有哪些內容會捕獲該錯誤（開發過程中固有的緩解措施）。如果沒有任何東西可以捕獲此類錯誤，則必須確定一些適當的方法來減輕錯誤。

分類為 T2、T3 的工具還必須具有合適的文檔。此外，對于歸類為 T3 的工具，需要額外的證據證明它符合該文檔。證據可以基于使用中的證明或基于測試用例的工具驗證。

對于具有許多功能的復雜工具，每個功能都可以單獨分析，就好像它是幾個獨立的工具一樣。

在IEC 61508圈子里，關于軟件離線工具要求是否適用于硬件開發工具存在一些爭論。用于開發集成電路的工具包含在IEC 61508-2：2010附錄F的要求中，主要涉及在類似復雜性的項目中使用2年的證明使用。在汽車領域，更清楚的是，無論正在開發的硬件還是軟件，工具要求都適用。我相信這也是基于IEC 61508的開發的正確方法。

后來在IEC 61508-3中，表A.1提倡使用工具進行需求管理，表A.3提倡使用經過認證的工具和經過認證的翻譯人員。

展望未來，有計劃改進IEC 61508-3中的離線工具要求，請關注此空間。

審核編輯：郭婷