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

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

關(guān)于功能安全機制及其診斷覆蓋率問題

Q

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

A

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

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

Q

什么樣的CRC滿足ASIL D？

A

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

Q

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

A

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

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

2）基于防御性編程思路開發(fā)，保證軟件確定性，采用標(biāo)準(zhǔn)推薦的方法。

Q

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

A

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

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

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

Q

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

A

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

Q

在做程序流監(jiān)控時，BSW或MCAL的周期任務(wù)是否也需要做監(jiān)控？

A

對于BSW或MCAL等周期任務(wù)的程序流監(jiān)控，需要通過外部獨立的硬件看門狗來實現(xiàn)。

關(guān)于功能安全等級ASIL問題

Q

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

A

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

Q

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

A

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

Q

TSR導(dǎo)出HSR和SSR時，請問FTTI如何分解？

A

在TSR分解為HSR和SSR時：

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

2）到系統(tǒng)層面時，F(xiàn)TTI需進一步分解為FDTI和FRTI；

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

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

5）軟件FRTI可根據(jù)相關(guān)診斷任務(wù)的執(zhí)行周期確定。

Q

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

A

ASIL A產(chǎn)品的功能安全要求包括：

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

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

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

Q

系統(tǒng)階段失效模式有什么參考的嗎，進行系統(tǒng)架構(gòu)設(shè)計的層次顆粒度怎么把握，并介紹做系統(tǒng)DFA的思路。

A

系統(tǒng)階段FMEA/DFA分析的失效模式可以參考：

1）通?；诠δ軐用?，如信號傳輸、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)處理等進行分析，不會細(xì)化到具體器件；

2）使用“與預(yù)期相反”、“非預(yù)期執(zhí)行”等引導(dǎo)詞指導(dǎo)功能層面分析；

3）顆粒度應(yīng)高于硬件或軟件層面分析。系統(tǒng)DFA的思路也是首先定義分析對象的DFI要素，DFI可以參考標(biāo)準(zhǔn)的推薦，結(jié)合DFI類型進行影響分析和分配相關(guān)的安全探測機制。

關(guān)于軟硬件架構(gòu)和需求分解問題

Q

在軟件架構(gòu)設(shè)計階段，如何對軟件架構(gòu)進行設(shè)計驗證？比如，如何進行數(shù)據(jù)流和控制流分析；如何進行原型驗證；如何進行動態(tài)行為仿真？

A

軟件架構(gòu)設(shè)計驗證的常用方法包括：

1）設(shè)計評審；

2）原型驗證；

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

4）動態(tài)行為仿真等。

Q

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

A

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

2）在定義TSR時，系統(tǒng)安全架構(gòu)應(yīng)已明確，TSR能夠分解至具體軟硬件實現(xiàn)；

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

Q

TSR和系統(tǒng)需求（aspice語境下是描述系統(tǒng)的黑盒需求）不是一個層級，TSR更適合放在系統(tǒng)架構(gòu)設(shè)計里？SSR也更適合放在軟件架構(gòu)設(shè)計里？

A

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

Q

在實際開發(fā)過程中，系統(tǒng)需求應(yīng)該去承接所有的客戶需求(包含F(xiàn)SR？)，如果TSR認(rèn)為和系統(tǒng)架構(gòu)是一個層級，那TSR和系統(tǒng)需求是什么關(guān)系呢？它向上追溯怎么做呢？

A

1）系統(tǒng)需求承接客戶所有需求（包括FSR）；

2）TSR和系統(tǒng)需求同級，前者描述所有系統(tǒng)需求（包括非功能安全、結(jié)構(gòu)要求、性能要求等），后者偏功能安全描述；

3）兩者共同構(gòu)成產(chǎn)品全部需求；

4）TSR上溯源自FSR,系統(tǒng)需求上溯源自客戶原始需求。

Q

怎么區(qū)分一個需求是FSR還是TSR，結(jié)合例子描述。

A

FSR和TSR的區(qū)分：

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

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

3）FSR的描述層級更高，側(cè)重整車功能，TSR的顆粒度更細(xì)，側(cè)重具體實現(xiàn)。

關(guān)于芯片/IC安全機制設(shè)計的相關(guān)問題

Q

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

A

在IC設(shè)計中，需要監(jiān)控的電源包括：

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

2）傳統(tǒng)設(shè)計中可能使用DCDC+比較器監(jiān)測電壓，但無法監(jiān)測電流；

3）外部振蕩器可利用芯片內(nèi)置的安全機制進行監(jiān)控；

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

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

Q

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

A

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

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

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

3）根據(jù)不同失效模式分配對應(yīng)的安全機制；

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

Q

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

A

在進行芯片F(xiàn)MEDA計算時，會對與分析對象無關(guān)的非安全功能模塊和管腳進行裁剪，非安全的管腳不予考慮。

Q

FMEDA中關(guān)于芯片的瞬態(tài)失效一般應(yīng)該怎么處理？

A

針對芯片瞬態(tài)失效，常見的保護機制有：

1）內(nèi)存ECC；

2）鎖步等架構(gòu)設(shè)計；

3）冗余RAM實時比對。

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

關(guān)于安全性分析問題

Q

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

A

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

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

Q

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

A

對于標(biāo)準(zhǔn)中未給出參考值的特殊安全機制，判斷其DC的依據(jù)如下：

1）標(biāo)準(zhǔn)已涵蓋80%常見器件失效模式，對芯片等新型器件也有所補充；

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

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

4）對于難以合理分配的失效模式，需結(jié)合可靠性模型進行定性定義，同時缺乏標(biāo)準(zhǔn)支持。

關(guān)于軟件失效分析問題

Q

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

A

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

Q

DFMEA和FMEA的區(qū)別

A

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

其他問題

Q

關(guān)于硬件要素評估，3類要素除了做分析評估和測試以外，標(biāo)準(zhǔn)上還說要有措施來證明系統(tǒng)性失效足夠低，現(xiàn)在主要有哪些比較認(rèn)可的措施？

A

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