關于功能安全的幾大誤區

制造商通常只會計算其系統或子系統的PFD/PFH值，并在之后給出一個SIL。PFH/PFD表示安全相關系統（或子系統）每小時（PFH）或者按需（FPD）的危險失效率。這兩個值說明了隨機硬件失效，而且通常使用FMEDA計算。達到具體的安全完整性水平（SIL）不僅要求控制硬件的隨機失效，而且還要避免和控制硬件和軟件的系統失效。后者表示為系統水平（SC，值為1至4，對應SIL的 4個等級）而且反映了安全相關系統開發過程中使用的方法和技術。因此，SIL始終包括：PFD/PFH以及開發過程穩健性的指標，比如SC。

有時系統集成商和裝置制造商要求其供應商提供具有一定SIL水平且可以確保系統正常操作的控制系統，以確保控制系統和/或公用設施具有一定的可靠性。但是安全功能（通過安全相關系統執行）的目的是讓受控設備（EUC）處于安全狀態，而不是提高其可用性。

受控設備安全狀態是危害和風險分析的結果，而且取決于其不同的操作模式。在這種情況下，我們經常會觀察到一些對于故障安全情景方法和概念理解錯誤情況，比如在失效情況下關閉受控設備；以及對于失效時運行情景，比如讓受控設備盡可能地運轉。

隨機硬件失效（和可靠性）是根據失效率計算的。在功能安全方面，失效率分為安全和危險失效。在計算PFD/PFH值時，只需考慮危險失效（阻止安全功能發揮預期作用）。因此，SIL僅代表當受控設備處于安全狀態時設備按照預期實現安全功能的一定程度的可靠性。

微控制器的看門狗往往只能重置控制器，不能直接獨立控制任何輸出。當微控制器內發生故障時，要求其輸出行為是確定的。使用內部看門狗并不足以獲得該功能，因為無法保證輸出達到預期狀態：內部看門狗是微控制器缺陷的一部分，因此，無法保證正確運行。

我們還根據運行經驗，聲稱現有軟件系統能力的方法（IEC 61508中的路線2S）。根據IEC TS 61508-3-1，所有軟件故障需要在觀察期中檢測和報告，而且所有輸入數據組合、執行順序和時間關系也必須記錄在文件中。這種方法通常不切實際。

我們通常遵守非安全組件與安全組件混合的系統設計。但是，采用混合安全完整性水平設計方法時，需要提供避免干擾自由的證據。分析需要在詳細硬件或軟件層面執行（取決于系統），考慮到不安全組件的任何可能失效模式以及對安全組件的相關影響（比如，不安全零部件過壓、錯誤數據、短路等）。

在開發安全關鍵性軟件時，現在，最先進的方法是使用自動化工具確定效率和安全性。但是，我們已多次發現此類工具的一些錯誤使用。單元測試規范首先應該根據軟件單元/模塊規范編寫，而不是通過源代碼白盒分析。目的是測試軟件單元的預期功能行為。代碼層面的測試覆蓋率是否滿足的證據必須提供，在這種情況下要求白盒分析，但這并不是單元測試的唯一目標。

在現代復雜的安全相關系統中，智能傳感器的使用越來越重要。傳感器的功能應當具有要求的完整性或者應當合理證明不影響總體安全功能。有些系統設計錯誤地基于這樣的假設：復雜智能傳感器的失效模式（比如,帶邏輯處理器、通信協議等）可以使用某些外部安全裝置在規定的診斷覆蓋率和失效檢測/反應時間內診斷出并得到緩解。

我們看到電源保護/監督缺失相關的問題復發。安全標準沒有具體說明應該如何具體實施過壓/欠壓措施，但是應該根據要求的SIL水平制定適當的保護機制。對于要求HFT>1的架構，使用非冗余過壓保護機制，是一個典型的復發問題。電源電壓監測（包括要求的反應，比如關閉和安全狀態）應當采用單獨的零部件完成，該零部件能夠在更廣泛的電壓范圍內使用，不會受到過壓/欠壓條件影響。即使短時過壓也可能不明顯地造成微控制器組件永久損壞。因此，過壓后對微處理器重置并不是妥當的措施；只要欠壓沒有持續，在欠壓條件之后重置是可行的。

溫度過高檢測和相應反應（進入安全狀態，停電等）無法采用一個在溫度過高條件下在規定范圍以外運行的零部件完成（比如，微控制器）。單純重置此處無用，應該假設溫度過高條件持續，或者在打開期間溫度已經偏高。安全標準（比如EN50129）中有時不對低溫予以規定，但是應用條件（用戶手冊）應當確保僅在規定的溫度范圍內驅動設備（對于所有零部件）。

多個標準使用縮寫SIL（安全完整性水平）。但在各個標準中，其流程、架構和技術要求不同。有些標準使用其他縮寫，比如ASIL（汽車SIL）。有些使用相同的縮寫（SIL），很容易混淆和誤解。

比如，SIRF（Sicherheitsrichtlinie Fahrzeug; EBA）使用的SAS水平（德文:“Sicherheitsanforderungsstufe”代表安全完整性水平）與EN 50128 /EN 50129標準中所述的SIL水平（“安全完整性水平”）不同。SIRF (SAS)僅使用EN 50129附件E中列出的一部分措施，省去了組織和流程措施，而且沒有規定的危害率限制。IEC 61508中的SIL與EN 50129中的SIL不同。有時，SIL會被解釋為軟件完整性水平而不是安全完整性水平（比如，EN 50657），增加了復雜性。

沒有安全證據的系統或使用同類冗余系統組合，無法提高系統的SIL水平。比如，單純結合多個SIL2系統/通道（比如，通過多個SIL2控制系統達到系統SIL3）無法提高SIL至SIL4。一個原因是，SIL2軟件流程與SIL4軟件流程對于系統性軟件失效的防止方式（完整性）不同。IEC 61508標準規定，如果一個雙通道結構使用兩個獨立的系統，則可將系統的系統能力提高1級。如果是同類冗余，則無法提高。其他標準（比如，EN 50129）則沒有提供這種可能性。

在故障樹分析（FTA）中往往會忽略常見原因。同時能影響一個系統多個組件的故障（比如，斷電）必須作為基本事件包含到故障樹的所有相關分支中。替代辦法：使用FTA工具中的“β系數”執行常見原因。

SIL（安全完整性水平）的定義適用于從某些風險分析/分類中導出的功能。對于一個系統/零部件，我們經常會聽到這樣的說法，比如“SIL 2控制器”, “SIL3 制動系統”等，正確表述SIL僅與具體（安全）功能有關。風險分析的目的是確定哪些功能是安全的。更加正確的定義是“系統能夠實現高達SILx”的安全功能。這意味著系統符合標準中的流程、架構和技術要求。

系統范圍需要從安全角度分析，而且它們與其他系統部件的接口在項目開始往往沒有明確界定。比如，沒有明確哪些零部件屬于系統部分，哪些傳感器/執行機構變體應該考慮在內等。沒有界定范圍是無法開始安全分析的，沒有避免多個迭代那么每次范圍都會變化。

故障檢測和監測塊（診斷）屬于具有特定SIL水平的安全功能，但是卻有單獨SIL水平。有些標準允許把要求的完整性水平降低1級，但是從功能安全的角度而言，診斷是安全功能的一部分。完整性要求也適用于診斷。后續分解分析也能夠降低完整性水平，但通常不排除任何安全要求。

有些完整性/診斷措施是在系統每次啟動時執行（比如，RAM測試，Flash CRC檢查，輸出測試等）。這些測試非常重要，因為它們用于測試診斷措施論證或者安全分析中的故障檢測時間（測試時間間隔）。但是有時，運行條件會變化（新項目，新要求等）。定期關機的系統，較長時間處于上電狀態。比如，現在軌道系列如今往往持續通電，每天早上無需重啟。在這種情況下，預期的診斷措施便無效。根據安全分析需要，應該在安全手冊、操作文件等中明確對定期重啟做出規定。