軟件的功能安全由IEC 61508第3部分涵蓋。通常，在uC，uP和DSP上運行的軟件是由購買我們芯片的應用程序人員編寫的。但是，在集成電路上運行并由ADI公司等IC供應商提供的軟件呢？

首先，什么是軟件，我在下面展示了一些定義，我認為無論您將其稱為軟件，固件還是嵌入式軟件，都適用相同的規則并不重要，這些規則通常來自IEC 61508-3。

在“安全關鍵系統的嵌入式軟件開發”一書中找到了更好的軟件定義，其中指出“問軟件是什么似乎很奇怪 - 直覺上人們覺得他們可以區分軟件和硬件。如果你把它放在腳上時很痛，那就是硬件”。

由您的 IC 供應商提供的與集成電路相關的軟件類型包括：

引導加載程序/引導ROM軟件

使用片上uC或DSP而不是固定功能邏輯實現的“邏輯塊”

軟件測試庫

協議堆棧或驅動程序庫

用于演示IC如何工作的示例代碼

對于IEC 61508-3范圍以上的所有軟件類型，似乎清楚地表明IEC 61508-3適用，但讓我們更詳細地討論它們;與功能安全一樣，總是有“如果”和“但是”，答案很少是/否。

引導加載程序：

引導加載程序是當uC或DSP上電并配置IC時運行的軟件的一個名稱，可能通過更改RAM大小，將校準系數從閃存移動到RAM，并可能實施協議以允許通過串行端口對閃存進行編程。

IEC 61508-3顯然適用于此類規范，但可以提出論據來減輕合規負擔。此類參數可能包括：

代碼簡單，決策點少，其正確性可以通過100%測試來驗證，而無需了解所使用的開發過程

代碼在應用程序代碼之前運行，并且應用程序代碼無法跳回到代碼中，因此不會干擾應用程序代碼

但無論哪種方式，這仍然意味著IEC 61508-3適用，并且應記錄您的功能安全論據，以證明為開發該代碼而降低SIL或沒有SIL。

軟件測試庫：

STL（軟件測試庫）是一段代碼，可能由IC供應商或第三方提供，用于對其運行的uC / DSP進行診斷覆蓋。您可以嘗試爭辯說，由于STL的故障不會直接導致安全功能的故障，因此此類軟件的SIL可以為0或至少小于使用運行STL的IC的安全功能的SIL。然而，作者認為，很難說STL獨立于它正在檢查的硬件，并且獨立于uC中運行的任何其他安全相關軟件。因此，STL可能需要開發為與依賴它的安全功能相同的SIL。但是，總是有可能提出相反的論點。

使用片上uC或DSP實現的邏輯塊：

如果包含該代碼的IC是安全相關系統的一部分，則需要根據IEC 61508-3開發代碼，除非對原因提出接受且有效的論據。無論代碼存儲在閃存，OTP，ROM還是RAM中，它仍然是安全系統中的軟件。可能降低合規性要求的參數包括

一些外部安全監視器不依賴于確保安全的軟件

通過單獨測試來驗證代碼的可能性（如果是簡單的代碼）

在系統級使用分集來降低任何片上代碼的SIL。

協議棧和庫：

此處的假設是最終用戶無法使用源代碼。在這種情況下，由于軟件在安全系統中運行，因此通常需要將其開發為與應用軟件相同的SIL。此處的例外情況可能是，如果協議是網絡協議堆棧并且是黑色通道的一部分，在這種情況下，不需要將其開發為 SIL。然而，將堆棧實施到其系統中的人員必須確保堆棧與其系統中的任何其他安全相關軟件（包括SCL（安全通信層））或所有軟件之間具有更高的SIL之間足夠的獨立性。

用于演示IC如何編程或工作的示例代碼：

這里的假設是此類代碼以源代碼格式提供。因此，IC開發人員無需按照IEC 61508-3開發此類代碼。將IC設計到其系統中的人員應將IEC 61508-3應用于代碼本身。

總之，安全相關系統中的軟件，無論是由IC供應商還是IC用戶開發，都需要按照IEC 61508-3進行開發，或者關于IEC 61508為什么不適用或為什么可以根據有效的記錄安全論據進行定制。特別是，使用相同的冗余不會減少此類軟件所需的 SIL。

審核編輯：郭婷