“博世依據(jù)ISO26262規(guī)范，在時間成本、研發(fā)成本和駕駛體驗、功能安全反饋體驗等關(guān)鍵項上進行功能安全保障。

 內(nèi)容摘錄自蓋世汽車，BOSCH-姬聰飛，僅供學(xué)習(xí)參考！

功能安全開發(fā)的兩個重點——成本考量、用戶體驗

功能安全開發(fā)主要關(guān)注的方向是符合規(guī)范，成本考量和用戶體驗。規(guī)范上，相對應(yīng)的國標是ISO26262, 主要是產(chǎn)品出口壓力，要出口到歐盟、北美、南美、澳大利亞、中東這些地區(qū)，避免法律上不合規(guī)問題。

成本上，在保證了產(chǎn)品可靠性安全性的同時，成品成本隨之提高，這個不可避免。對于成本我們在考慮可以嘗試使用新技術(shù)的加持，如AI大數(shù)據(jù)，chatGPT等，希望能在成本上作些優(yōu)化。

用戶體驗上，用戶感知度最高的就是體驗。駕駛體驗，功能安全反饋體驗這兩者之間有一定的矛盾點。駕駛體驗，偏重于用戶對智能座艙產(chǎn)品的可用性、舒適性的體驗。而功能安全更偏重于可靠性。它的反饋體驗就是在出現(xiàn)異常事件時，在滿足安全目標的前提下，所采取的措施和進入的安全狀態(tài)，是否能滿足或解決用戶的切身需求，并讓用戶能夠和平接受。

就像車輛異常進入跛行模式，行動緩慢，但是用戶希望能正常駕駛。再比如說智能座艙中監(jiān)控到某種異常，然后儀表黑屏。但是用戶還希望能看到儀表中的其他指示信息。這是對軟件策略制定和開發(fā)人員的挑戰(zhàn)。

功能安全開發(fā)實戰(zhàn)經(jīng)驗

下面結(jié)合項目，和大家聊一下，在滿足功能安全ISO26262要求的前提下，我們在其中的一些探索和思考。

智能座艙功能安全的主流方案其中的一個safety goals是報警燈或者檔位指示燈，避免非預(yù)期不發(fā)出報警或錯誤指示或者不發(fā)出提醒。

目前我們計算安全報警燈顯示的內(nèi)容，完全依賴于區(qū)域內(nèi)所有像素點，像素點顯示是否正確?；谒@示的圖標的像素點進行檢測，大家可以看左側(cè)，我可以對這張圖進行轉(zhuǎn)換，轉(zhuǎn)換為二進制，比如說后三位數(shù)是011，如果說其中的像素點產(chǎn)生了偏差，最后的二進制就變成了110，這個時候我就可以通過這種機制，來判斷是否這張圖受到了干擾，或者是這張圖已經(jīng)跟原來不一致了，比如說圖有殘缺或是完全不一致。

其中的思路是從pipeline混合后的圖層中，基于區(qū)域獲取到區(qū)域內(nèi)所有像素點，利用CRC引擎計算，然后去對比，若有差異則進入安全狀態(tài)。

當前的主流方案有兩個技術(shù)性的要求，一個是基于每個像素點的檢測，一個是基于一塊方形區(qū)域進行檢測。這是比較傳統(tǒng)的做法。

就算增加硬件成本，升級硬件依然是基于區(qū)域內(nèi)所有像素點的，檢查圖標范圍內(nèi)像素的偏差。于是在滿足功能安全規(guī)范的前提下，我們也在探索一些新的功能安全解決方案和架構(gòu)設(shè)計。

圖源：演講嘉賓素材

大家看左側(cè)的顯示對比，第一個是正常的，其次是背景透傳，雪花斑點，波段條紋，是否都可以正常識別出是安全氣囊故障報警指示燈？

我們認為駕駛員是可以識別出來的，如果基于現(xiàn)在主流的方案，畢竟存在像素點的偏差，我們會認為這樣的狀態(tài)存在錯誤。但是站在駕駛員的角度，功能安全更人性化和可用性的角度，這種情況是否也有一定的合理性呢？

基于這種思考，我們在探索一個新的方案：

采用圖像識別技術(shù)，對圖像的特征點和關(guān)鍵點進行動態(tài)識別。假如有背景透傳，我們認為這些存在像素點的偏差，但是這些像素點的偏差并不會對駕駛員整體的判斷產(chǎn)生影響，那么我們依然認為這是一個安全的狀態(tài)。

那么在實施的時候，我們可以對類似于表示安全氣囊的圓球和人形輪廓進行動態(tài)采集。在滿足功能安全ISO26262標準要求的前提下，將采集到的數(shù)據(jù)集導(dǎo)入模型組件進行訓(xùn)練，并將訓(xùn)練和驗證好的模型部署到工程模塊中。

通過部署的模型可以識別出雖然有些瑕疵但是依然可以被用戶正常識別的case,避免不必要的進入安全狀態(tài)情況，提高系統(tǒng)的可用性、容忍性。現(xiàn)在如果對安全狀態(tài)行為細分的話，現(xiàn)在多數(shù)方案為簡單的 Fail-Safe，就是第四種重啟系統(tǒng)，重啟就會黑屏，帶來的問題就是用戶體驗很不友好。這就又回到了駕駛體驗與功能安全反饋體驗之間的沖突。

為了降低兩種體驗之間的沖突，我們探索采用多級降級方案，就算進入安全狀態(tài)也可以繼續(xù)使用，來提升系統(tǒng)的可用性，同時也提升用戶體驗。

目前我們評估能夠想到的大概是這四種方式。當檢測到問題之后，按照嚴重程度，我們評估出問題若是一些偶發(fā)低嚴重程度的問題，可以采用第一種顯示備份圖標。如果持續(xù)校驗失敗，嚴重度升級為中等，可以采用第二種彈窗提示。

如果是持續(xù)的，不可恢復(fù)的故障 ，那么就要嘗試重啟相關(guān)組件。由此帶來另一個問題就是不同組件之間要進行解耦，功能安全相關(guān)的功能在設(shè)計時要保證獨立性。當所有的降解方案都無效后，再嘗試采用第四種重啟系統(tǒng)恢復(fù)。

上面的嚴重度判定可以結(jié)合圖像識別模型的判斷，反饋的每種錯誤分為非嚴重，輕微嚴重，中等嚴重，重度嚴重等級四種嚴重度對應(yīng)4級恢復(fù)策略?？傮w來說就是降低駕駛體驗與功能安全反饋體驗之間的沖突，提升可用性與用戶體驗，其中重啟相關(guān)組件最為復(fù)雜。

對于重啟相關(guān)組件，使用多核系統(tǒng)，進行多核功能分區(qū)，不同組件之間解耦并保持獨立性。

比如，如果功能分區(qū)1是對配置數(shù)據(jù)進行監(jiān)控，若發(fā)現(xiàn)配置數(shù)據(jù)損壞后，可以單獨init該功能分區(qū)，重新設(shè)置配置數(shù)據(jù)。或者功能分區(qū)3是部署的圖片識別模型，與CRC引擎計算結(jié)果不匹配，那么可以單獨重啟圖片識別模型功能分區(qū)即可。當然在執(zhí)行相關(guān)重啟的時候，如果對中控和儀表會有影響，可能設(shè)置的策略為在小于60km速度場景下可以嘗試單獨重啟，儀表在30km速度下可以嘗試單獨重啟等。 

圖源：演講嘉賓素材

對于測試驗證：1.針對圖像識別模型，使用錯誤圖數(shù)據(jù)集訓(xùn)練出的圖像故障模型，結(jié)合測試case進行自動化故障注入測試。

2.其他所有安全機制，根據(jù)需求和應(yīng)用場景整合大量的test cade，進行充分的自動化測試。用來保證產(chǎn)品的魯棒性等。

智能座艙領(lǐng)域面臨的挑戰(zhàn)是更多Telltale燈，更多主題模式，主機廠推出主題商城，層出不窮的UI設(shè)計風(fēng)格，也使開發(fā)復(fù)雜度難度增大。在這里的體會是，實施了功能安全可以被看作是state of the art。但是需要注意的是state of the art并不是靜態(tài)停滯的，它是隨著技術(shù)發(fā)展需要不斷迭代更新的。我們就要找到新的思路和方法去適應(yīng)和推動產(chǎn)品的迭代發(fā)展，讓客戶更好的接受和認可功能安全。