“功能安全常見疑難問題解答”

在智能駕駛及新能源汽車的飛速發展之下，功能安全已成為繞不開的關鍵領域。然而在實際應用中，一直面臨著諸多問題和挑戰。前不久，磐時舉辦了一場針對實操問題的線上答疑活動，我們分類整理了一些熱門問題及解答，可作為大家日后實踐中的參考。

關于功能安全機制及其診斷覆蓋率問題

Q

外狗從功能上來講是否可以完全覆蓋內狗？什么情況下內狗和外狗都需要使用？

A

外狗雖然可以對程序流進行監控和保護，但無法完全替代內狗。內狗能夠直接嵌入程序中，關注程序非預期跳轉及執行時間異常等，與應用軟件結合更加緊密。而外狗作為獨立硬件，主要用于監控內狗本身，從而保證內狗的獨立性。在某些極端情況下，可以僅保留外狗而取消內狗，但這種做法時延較長且外狗需要較高智能，實際效率較低，不推薦采用。

同時由于內狗與應用軟件緊密相關，在一些情況下，如芯片內部振蕩器發生錯誤時，即使內狗正常，診斷代碼和功能執行代碼也可能失效，此時內狗就無法提高檢測覆蓋率，因此外狗是必需的。

Q

什么樣的CRC滿足ASIL D？

A

對于通信協議，標準定義了幾種失效模式，例如數據損壞、報文重復、錯序、丟失、超時、錯誤尋址、偽裝等等，通常采用CRC16/32、滾動計數器（RC值）、超時Timeout及幀ID等機制來覆蓋。在評估E2E保護機制的殘余風險時，需要根據CRC多項式計算出漢明距離，結合報文長度及每小時PDU發送量，推導出每小時的殘余差錯率。通常通信總線上的殘余差錯率定義為不超過item對應ASIL等級的1%。

Q

除了流程上滿足，BSW怎么算滿足了ASIL，常用的安全機制有哪些?

A

除了滿足流程要求外，BSW滿足ASIL還需要：

1）覆蓋硬件未能診斷的隨機失效；

2）基于防御性編程思路開發，保證軟件確定性，采用標準推薦的方法。

Q

不同功能安全等級ABCD對安全機制的要求，有哪些區別？功能安全機制一般要包含哪些要素或注意的地方？

A

不同ASIL等級對安全機制的要求有所區別：

1）等級越高，可能需要更多組合的安全機制來覆蓋所有失效模式；

2）對于同一安全機制，等級越高其診斷間隔要求就越短，以滿足更短的FTTI周期要求。描述安全機制時，不僅需要闡述診斷功能，還應包括安全路徑即達到安全狀態的功能鏈路。

Q

關于安全機制的DC，是否存在兩個low疊加能得出medium這種邏輯？

A

通常情況下，兩個低DC的安全機制無法通過疊加得到更高的DC。原因是它們可能僅覆蓋了同一種失效模式，無法涵蓋所有失效模式。不同安全機制一般覆蓋不同失效模式，需要組合使用才能獲得高DC。

Q

在做程序流監控時，BSW或MCAL的周期任務是否也需要做監控？

A

對于BSW或MCAL等周期任務的程序流監控，需要通過外部獨立的硬件看門狗來實現。

關于功能安全等級ASIL問題

Q

MPU的使用和ASIL等級是否相關，是否使用MPU還需要考慮哪些因素？

A

MPU作為內存分區的硬件機制，在操作系統等軟件無法實現時通常需要使用，與ASIL等級無直接關系。MPU的使用主要是通過限制對指定內存區域的訪問權限，從而提供通用的內存保護機制。MPU的使用與否并不僅僅取決于ASIL等級，還需要結合其他因素綜合考慮，比如不同功能或安全等級的內存保護。

Q

功能安全對于D-FMEA是否有要求？以及對于這些特性后續在PFMEA或者control plan中是否有要求？

A

功能安全對D-FMEA是有一定要求的。對于影響安全的失效模式，嚴重程度通常需標注為9或10級；同時需標注CC（關鍵特征）和SC（特殊特征），這些特性后續需要在P-FMEA和控制計劃中加以管控。

Q

TSR導出HSR和SSR時，請問FTTI如何分解？

A

在TSR分解為HSR和SSR時：

1）FTTI已在定義safety goal時確定；

2）到系統層面時，FTTI需進一步分解為FDTI和FRTI；

3）硬件FDTI和FRTI一般在幾ms甚至us量級；

4）軟件FDTI需考慮診斷間隔及誤報濾波預留；

5）軟件FRTI可根據相關診斷任務的執行周期確定。

Q

ASIL A的功能安全要求有哪些？硬件沒看到有指標，軟件這塊需要做到什么程度，有沒有需要注意的地方？

A

ASIL A產品的功能安全要求包括：

1）極少單獨存在ASIL A功能，通常與更高等級需求合并；

2）滿足ISO 26262相關篇章中ASIL A的基本要求，比如產品的可靠性測試和功能測試；

3）主要體現在功能安全管理流程方面,對診斷機制要求不會過高。

Q

系統階段失效模式有什么參考的嗎，進行系統架構設計的層次顆粒度怎么把握，并介紹做系統DFA的思路。

A

系統階段FMEA/DFA分析的失效模式可以參考：

1）通常基于功能層面，如信號傳輸、數據轉換、數據處理等進行分析，不會細化到具體器件；

2）使用“與預期相反”、“非預期執行”等引導詞指導功能層面分析；

3）顆粒度應高于硬件或軟件層面分析。系統DFA的思路也是首先定義分析對象的DFI要素，DFI可以參考標準的推薦，結合DFI類型進行影響分析和分配相關的安全探測機制。

關于軟硬件架構和需求分解問題

Q

在軟件架構設計階段，如何對軟件架構進行設計驗證？比如，如何進行數據流和控制流分析；如何進行原型驗證；如何進行動態行為仿真？

A

軟件架構設計驗證的常用方法包括：

1）設計評審；

2）原型驗證；

3）繪制數據流圖和控制流圖,并進行軟件FMEA分析；

4）動態行為仿真等。

Q

系統安全需求TSR和系統需求（把系統作為黑盒）是一個層級的需求嗎？TSR是否得移植迭代直到一條TSR要不是給軟件實現要不就是給硬件實現？TSR是否屬于系統架構級別的需求？（因為它還需要allocate給你一個系統要素）？同理軟件安全需求和軟件需求的關系是不是也是這樣？

A

1）系統安全需求TSR與系統需求雖屬同一層級，但TSR的顆粒度更細，至少需將需求分配到具體的軟硬件組件；

2）在定義TSR時，系統安全架構應已明確，TSR能夠分解至具體軟硬件實現；

3）軟件安全需求SSR的描述原則與TSR相似，需分配到具體的軟件組件，并完整描述功能鏈路。

Q

TSR和系統需求（aspice語境下是描述系統的黑盒需求）不是一個層級，TSR更適合放在系統架構設計里？SSR也更適合放在軟件架構設計里？

A

可以將TSR視為系統架構級需求，SSR視為軟件架構級需求。通過明確的TSR和SSR，可充分描述各功能安全鏈路，并組合形成系統和軟件的完整安全架構設計。

Q

在實際開發過程中，系統需求應該去承接所有的客戶需求(包含FSR？)，如果TSR認為和系統架構是一個層級，那TSR和系統需求是什么關系呢？它向上追溯怎么做呢？

A

1）系統需求承接客戶所有需求（包括FSR）；

2）TSR和系統需求同級，前者描述所有系統需求（包括非功能安全、結構要求、性能要求等），后者偏功能安全描述；

3）兩者共同構成產品全部需求；

4）TSR上溯源自FSR,系統需求上溯源自客戶原始需求。

Q

怎么區分一個需求是FSR還是TSR，結合例子描述。

A

FSR和TSR的區分：

1）FSR更多從功能角度，側重整車item層面，如防止非預期加速；

2）TSR更關注具體的功能安全要求，如（為了防止非預期加速）對輸出加速信號進行E2E校驗和輸出合理性檢擦等，關注使用何種安全機制等；

3）FSR的描述層級更高，側重整車功能，TSR的顆粒度更細，側重具體實現。

關于芯片/IC安全機制設計的相關問題

Q

IC設計中哪些電源和時鐘是要監控的，時鐘會有很多分頻或分支出來，在使用前都要監控嗎？

A

在IC設計中，需要監控的電源包括：

1）通常采用帶ASIL等級的PMIC或SBC進行電壓/電流監測；

2）傳統設計中可能使用DCDC+比較器監測電壓，但無法監測電流；

3）外部振蕩器可利用芯片內置的安全機制進行監控；

4）芯片內部時鐘樹分支后，各個域可能有專門的PLL監測機制，具體取決于芯片安全機制。

同時對于IC內部電源和時鐘監控，設計時需要基于一些假設前提，如定義安全域。針對這些域使用的供電和時鐘，會有通用的域值檢測機制，包括輸入輸出檢測、配置檢測等。

Q

芯片內部一些常用的Safety Mechanism的Diagnostic Coverage 通常該怎么定義？

A

芯片內部安全機制的診斷覆蓋率DC無法直接采用ISO 26262中低/中/高的粗粒度定義方式，需要：

1）具體分析被分析對象的失效模式；

2）結合可靠性模型定義各失效模式的占比；

3）根據不同失效模式分配對應的安全機制；

4）通過芯片層面的故障注入測試,驗證所有失效模式均被覆蓋。

Q

芯片有300多個引腳，與該軟件功能相關只有40~50個，那么其他引腳的失效需要考慮嗎？

A

在進行芯片FMEDA計算時，會對與分析對象無關的非安全功能模塊和管腳進行裁剪，非安全的管腳不予考慮。

Q

FMEDA中關于芯片的瞬態失效一般應該怎么處理？

A

針對芯片瞬態失效，常見的保護機制有：

1）內存ECC；

2）鎖步等架構設計；

3）冗余RAM實時比對。

這些措施通常應用于高ASIL等級且檢測間隔要求很短的場景。在產品級FMEDA中，個人建議應當考慮芯片瞬態失效的影響。雖然采用針對性保護機制能提供較高DC，但由于瞬態失效基數較高，殘余風險仍較可觀。不過，業內通常在采用一定保護措施后，不會過多關注瞬態失效問題。

關于安全性分析問題

Q

在做FMEDA時，標準中對于一些影響EMC相關的失效定義比較模糊，什么時候需要定義為單點，什么時候定義為潛伏或者安全故障？

A

通常EMC不會被視為需要在FMEDA中分析的隨機失效，而是作為系統性失效的一個要素，在可靠性設計時需要考慮。只有在特定條件下缺少EMC保護措施時，EMC才可能被定義為單點失效進行分析。

舉個例子，產品在正常的設計和使用狀態下，通常都會有外殼等保護措施,能夠防范EMC相關的靜電放電風險對敏感元器件造成損害。但是，如果在生產或運行過程中，產品暴露于無外殼保護的特殊環境，那么人員操作或維修時可能會導致靜電釋放，對敏感元器件產生影響，此時就需要將這種EMC故障視為單點故障進行分析。不過，在產品設計階段，通常已經充分考慮了這一風險。比如，通過EMC可靠性測試和系統測試，驗證了產品在特殊環境下的穩定性能；同時，對于電氣敏感元件也采取了外殼、封裝等保護措施。因此，在正常的設計和使用條件下，EMC相關的故障極少被視為單點故障進行分析。

Q

FMEDA分析的時候，會有DC的概念，ISO內給了一部分的參考值。比如ECC，Parity。對于ISO沒給的特殊的SM，通常如何判斷其DC？比如，部分IP的故障模式可以被NOC的Timeout檢測到，這個SM的DC該如何定義?

A

對于標準中未給出參考值的特殊安全機制，判斷其DC的依據如下：

1）標準已涵蓋80%常見器件失效模式，對芯片等新型器件也有所補充；

2）可根據器件功能定義分析潛在失效模式，采用失效模式占比平均分配的方法初步評估DC；

3）對自定義的檢測方法，需從被檢測對象的失效模式出發，分析所使用的安全機制能覆蓋哪些失效模式，可通過故障注入測試驗證機制有效性；

4）對于難以合理分配的失效模式，需結合可靠性模型進行定性定義，同時缺乏標準支持。

關于軟件失效分析問題

Q

軟件分析中對于軟件的失效（不考慮硬件）是都可以通過流程措施來解決軟件失效，還是必須增加實時運行的檢測機制來監控軟件（如程序流監控）？如果有的需要有的不需要，是什么依據來判斷的？

A

功能安全相關軟件的失效模式分為兩個方面：系統性失效和隨機失效。系統性失效如設計缺陷、編碼錯誤等，可以通過改進流程、規范編碼習慣等措施來解決。隨機失效如受EMI干擾、硬件故障影響等，則需要采取諸如程序優先級分配、程序流監控、數據端到端保護等技術手段。因此，針對不同的軟件失效模式，需要采取流程措施和技術手段相結合的方式。

Q

DFMEA和FMEA的區別

A

DFMEA考慮維度更廣，不僅包括安全相關器件的隨機故障，還包括非安全器件對性能的影響、制造過程問題等。而FMEA則專注于安全相關器件的隨機故障模式分析，并提出相應的安全機制和診斷覆蓋率，用于量化殘余風險。在功能安全項目中，系統階段需要同時開展FMEA（分析隨機故障）、故障樹分析等，也需要DFMEA分析，兩者是互補而不沖突的。

其他問題

Q

關于硬件要素評估，3類要素除了做分析評估和測試以外，標準上還說要有措施來證明系統性失效足夠低，現在主要有哪些比較認可的措施？

A

對于三類硬件元件（ASIL C等級），通常不會單獨分配安全機制,而是通過其他措施來證明其系統性失效足夠低。目前較為認可的措施是“經證實使用”（Proven in Use），即通過大量實踐使用和測試來證明元件的可靠性。但這種方式的置信度相對較低。硬件組件鑒定活動通常采用“經證實使用”方法，如果一個元件在多款ASIL B級產品中使用并證明了相關可靠性，則可被視為滿足ASIL B級使用要求，但不等于通過ASIL B級認證。目前無統一量化標準規定“經證實使用”的具體條件，大多數公司在這方面較為保守，認為這種方式最多只能達到ASIL B級，要更高級別還需要完整的分析評估過程。