IEC 61508 和 ISO 26262 都提供“經過驗證的使用”作為聲明合規性的替代途徑。在 IEC 61508 中，經使用驗證的術語稱為路由 2S.更常見的路線 1S表示該項目的開發符合標準的所有適用要求。路線 2S當該項目的開發不符合IEC 61508時，可以使用，但有很多操作經驗可以表明其安全性。已經運行了很長時間并且從未出現任何問題的東西足以在安全系統中使用，這似乎是合理的。這至少是路線2背后的前提S.該路由可用于硬件和軟件，但在這種情況下，我將更多地關注硬件合規性。

以下是IEC 61508和ISO 26262中最重要的表格。雖然IEC 61508暗示了表格背后的數學原理，但此博客可能會使您不必自己弄清楚。我個人總是喜歡了解我應用的任何東西。否則很容易誤用。對于ISO 26262，幾乎沒有給出的理由，這個博客對于任何想要更好地了解該標準的人來說都是有價值的。這篇博客將總結我試圖證明使用中證明背后的數字和方程式的經驗。博客不會討論應用路線 2 的優點S對于軟件與硬件，它只看數字和數學。

圖 1 - IEC 61508-7：2010 附錄 D 中的相關表格。

下面給出了ISO 26262的等效項。

圖 2 - ISO 26262-8：2018 中的表格

讓我們從IEC 61508數字的最后一列開始，該列用于具有95%置信水平的連續或高要求安全功能。這與之前博客中關于在不同置信水平下進行可靠性預測的匹配非常相似，請參閱此處。

對于較大的 k 值，故障率可以估計為 λ = k/T，其中 k 是故障次數，T 是總操作時間。較大的值可能是 10 次或更多次失敗。因此，如果您運行 100 億小時（10000 臺設備運行 1 年）并出現 10 次故障，則故障率的良好估計為 10/1e8 = 100e-9 或 100 FIT。但是，如果您遇到 0 次失敗，那么您會將故障率估計為零，這是一個不太可能的值。然后需要對數據進行統計解釋。

有些人喜歡使用 Θ=1/λ 而不是 λ，其中 Θ=MTTF（平均故障時間）。因此，對于 λ=100e-9，我們有 MTTF = 10 萬小時。請記住，我們不希望該項目運行 10 萬小時，而是表示大量單元的預期運行時間，直到其中一個單元發生故障，前提是任何項目的聲明壽命都不超過 20 年。如果超過零件的速率壽命，故障率將開始急劇增加。

現在，有人比我花在數學上的時間多得多，表達式 2Tλ 是用 χ 表示的卡方分布分布的2.

我們的汽車同事說得最好，他們說

圖 3 - ISO 26262-8：2018 第 14 條中所需的服務小時公式

在這個公式中

f 是觀察到的故障數，在本例中我們假設為 0

CL 是所需的置信水平，我們假設為 95%

t平均時間是我們希望展示的平均失敗時間

則總操作時間為t服務需要證明MTTF處于該置信度。

注意 – 如果我們使用 95% 的置信水平，那么 MTTF 的真實值大于計算的 MTTF 的置信度為 95%。

因此，讓我們進行計算。理解后，您可以使用Excel為您進行數學運算，而忘記所有細節。

下表表示卡方分布。第一列顯示自由度 （2f+2），第一行顯示所需的置信水平。

因此，對于 f=0（零故障），我們有 DF=2，對于 95% 的置信度，我們有 p = 0.05 （1-95/100），我們從表中讀取 5.991。

SIL 2 的 PFH 范圍給出了每小時允許的危險故障率為 1e-6 至 1e-7。推桿 t平均時間= 1/1e-7（記住故障率為 1/t平均時間并使用波段下端的 λ 值）然后我們得到所需的小時數為 （1/1e-7）*5.991/2 = 30 萬小時，這與上圖 1 中的表格一致。

圖 1 中的倒數第二列就很容易了。我們將 p=5.991 （0-01/1） 的值讀出為 99.100，而不是 9.21，以獲得所需的 46 萬小時的維修間隔。

圖 4 - 顯示卡方分布的表格

該數學適用于任意數量的觀察到的故障，并且您需要更長的觀察期才能獲得相同的置信度，即故障率足夠低。但是，有些人認為任何系統性故障都是不可接受的，并說您應該修復故障的原因并重新開始。這些人會說使用的失敗次數應該為零，因此 df = 2。我認為這種態度存在許多問題，包括難以確定該領域的失敗是否是系統性的，但我今天不會進入這場辯論，因為我只是想解釋這些數字來自哪里。然而，我確實注意到，雖然IEC 61508使用這種數學來證明足夠的系統完整性，但我們的汽車同事只是用它來證明足夠低的故障率，包括隨機和系統故障模式（例如參見ISO 26262-5 5.8.3和ISO 26262-8：2018 14.2）。

上圖26262所示的ISO 2數字與IEC 61508的數字不同。這是因為ISO 26262只需要70%的置信水平。因此，再次讀取 df=2 和 p=1-70/100=0.3 的表格，我們得到所需的服務時間 = 1/1e-7*2.41/2 = 12 萬小時。

汽車僅具有高或連續模式操作。IEC 61508的需求也很低，定義為需求率為<1 /年。為了從表5的第1列中獲取值，我們現在假設需求率正好是1 /年（這是最壞的情況，即最高需求率）。假設每年 10000 小時，您只需將高需求/連續模式的 95% 和 99% 置信值除以 10000。因此，30 萬小時變成了 30000 個需求。

您可能會爭辯說，對給定的 SIL 使用 PFH 范圍的下限是保守的，例如，當范圍從 1e-7/h 到 2e-1/h 時，對 SIL 7 使用 1e-6/h。您可能會爭辯說，如果您進行了定量的SIL測定并確定您需要PFH為5.3e-7 / h（在SIL 2范圍內），則應使用該值代替1e-7 / h。但是，機械安全和ISO 26262通常使用風險圖，并且假設危險故障率只有一個上限。相反，您也可以爭辯說，標準編寫者使用了給定 SIL 范圍底部的值，因為所評估的元素或組件只是安全功能的一部分，因此將 10% 的預算分配給特定項目。

在功能安全標準中使用經過驗證的類似概念包括

先前使用 IEC 61511

IEC 61508的現場經驗

路線 2H符合 IEC 61508 標準

DO-254相關服務經驗

僅依靠經過驗證的使用的一些問題包括：

軟件故障實際上并不取決于時間，而是取決于代碼中的錯誤數量、代碼中錯誤存在的位置、代碼的使用方式、輸入參數的順序和可變性等因素。

日歷時間與操作時間

系統級冗余可以隱藏故障

未報告低后果故障

1000 個項目運行 1000 小時真的與一個項目運行 <> 萬個小時真的一樣嗎

并非所有現場故障都會被報告，因為與永久性硬件故障不同，它們可以迅速消失并且難以重現，我們習慣于容忍軟件故障

運送的物品可以作為備件存放在倉庫中

難以區分隨機硬件故障和系統故障

系統故障可能只針對一組特定的輸入出現。如果確實出現這些情況，故障將始終發生

系統故障是否有可接受的故障率！

在愛爾蘭，至少所有投資產品廣告都聲明“過去的回報不是未來回報的證據”或類似的東西。但這正是您正在使用歷史數據來預測未來回報的經過驗證的事情。

使用卡方計算置信區間假定故障率恒定，并且故障時間呈指數分布

IEC 61508-2：2010 7.4.10 在進行驗證使用時提出了額外的要求（路線 2S） 索賠。這包括例如7.4.10.3，它要求對新舊操作環境之間的任何差異進行影響分析。它沒有提供任何關于可能產生影響的線索，但作為一個主要是硬件的人，我建議可能包括工作溫度范圍、更快的時鐘速度、具有更快斜坡速率的不同電源、輸入變量的不同分布......

但請記住，安全標準包含聲稱符合標準所需的最低要求。這聽起來有點消極，但事實并非如此。這只是一個事實。因此，經過驗證的使用候選者的安全案例可能包括其他內容，例如：

用于開發軟件的開發過程的詳細信息，即使它不是符合IEC 61508的開發過程（如果它是符合IEC 61508的開發過程，您將聲明路線1S而不是路線 2S).

來自現場經驗參數的信息顯示設計到 10 個不同的應用程序中（這意味著由 10 個不同的團隊驗證并暴露于更大的輸入組合）。

請記住，您的目標是讓您的獨立評估員更容易說“是”。您可以提供的感覺良好的信息越多（也許其他緩解措施聽起來更專業），您的評估員在通常是工程判斷時就會感到越高興。

當然，您聲明路線 2 的項目S通常被納入正在根據IEC 61508開發的系統中，因此將與系統的其余部分一起進行驗證和確認。這意味著至少它不應該有任何明顯的錯誤，這些錯誤應該在集成過程中發現。

審核編輯：郭婷