關於功能安全的幾大誤區

Adding value with our service portfolio

Adding value with our service portfolio

避免在未來安全專案出錯

TÜV SÜD擁有20多年功能安全相關系統和零部件測試和驗證經驗。在此期間,我們的員工已經觀察到某些功能安全概念曲解因而造成問題復發。下表列出了每個人應注意的一些最常見的錯誤。

  • 1. PFH/PFD:SIL的必要但不充分條件

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

  • 2. SIL並不意味著控制系統的可靠性

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

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

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

  • 3. 看門狗和微控制器

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

  • 4. 在使用中證明的軟體

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

  • 5. 避免干擾

    我們通常遵守非安全性群組件與安全性群組件混合的系統設計。這是降低複雜度和系統成本的一種標準方法。 但是,採用混合安全完整性水準設計方法時,需要提供避免干擾自由的證據。分析需要在詳細硬體或軟體層面執行(取決於系統),考慮到不安全性群組件的任何可能失效模式以及對安全性群組件的相關影響(比如,不安全零部件過壓、錯誤資料、短路等)。

  • 6. 單元測試規範

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

  • 7. 無SIL資格的智慧感測器

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

  • 8. 電源保護/監督

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

  • 9. 溫度過高

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

  • 10. SIL與SIL不同

    多個標準使用縮寫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),增加了複雜性。

  • 11. 通過冗餘提高SIL

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

  • 12. 故障樹分析(FTA)中的常見原因

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

  • 13. SIL的定義

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

  • 14. 系統範圍

    系統範圍需要從安全角度分析,而且它們與其他系統部件的介面在專案開始往往沒有明確界定。比如,沒有明確哪些零部件屬於系統部分,哪些感測器/執行機構變體應該考慮在內等。沒有界定範圍是無法開始安全分析的,沒有避免多個反覆運算那麼每次範圍都會變化。

  • 15. SIL包含診斷

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

  • 16. 啟動過程中的系統自測

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

更多

Select Your Location