如何理解預期功能安全

2022年5月24日 10:58
瀏覽：2921


當前汽車行業熱度非常高的三個標準為預期功能安全ISO21448，功能安全ISO26262和網絡安全ISO21434，其中預期功能安全對于系統開發者來說比較陌生，容易將它與功能安全混為一談，預期功能安全要解決的問題是什么，為什么要在功能安全之外還要考慮預期功能安全，網上已經有很多的資料去講，本篇談談對預期功能安全概念的理解。

背景

Road vehicles - safety of the intended functionality SOTIF（道路車輛 預期功能安全）標準在2019年1月作為公開技術規范發布（ISO/PAS 21448），正式版預計將于2022年發布，目前PAS版本共有29頁+23頁附件，重點關注SAE自動化level 1和level 2駕駛輔助功能。

這個規范用于降低由于系統的預期功能不足（設計不足或性能局限）或可預見的人員誤操作導致的不可接受風險，這也是預期功能安全概念的定義，適用的電子系統為安全功能受外部環境影響的功能，來自于傳感器和處理算法，典型的有AEB自動緊急制動系統、車道保持系統等高級駕駛輔助系統。

預期功能安全概念

功能安全在于解決系統內的隨機失效和系統性失效引起的危害，造成安全事故，包括硬件故障、軟件故障，而系統功能正常時出現的危害不在功能安全考慮的范圍內，由于使用傳感器或算法的性能限制，駕駛人員對系統的誤操作，SOTIF規范的推出旨在解決這一類問題。下圖來自中國汽車標準化技術委員會在2020年發布的《預期功能安全國際標準ISO21448及中國實踐白皮書》，用于說明功能安全與預期功能安全概念的區別。

如何理解預期功能安全的圖1

SOTIF關注領域

一、系統的運行設計域ODD（或稱為運行場景）超出了系統和部件性能限制，比如一個自動巡航系統在其ODD范圍內（高速公路、天氣良好）運行，遇到了有低照明條件的情況，超出了前置攝像頭的性能限制；

二、人為因素對系統的影響，特別是與人機交互界面的接口。如駕駛員沒有將手放在方向盤上（在需要時）；駕駛員對系統能力和限制的理解，以及駕駛員的責任；以及駕駛員理解和應對警告和警報的能力。

在SOTIF規范中，也對不同標準適用的范圍進行了說明，如下表，此表為筆者對英文版規范的翻譯，如有差異，以原文為準。

如何理解預期功能安全的圖2

SOTIF四象限概念

預期功能安全提出了四象限圖的概念，用于確定系統所在的各類場景，這個概念類似于IEC61508中安全失效率λs、危險失效率λd的概念，不過SOTIF所關注的外部觸發事件造成的危害，不是系統內失效引起的危害。

如何理解預期功能安全的圖3

Area 1代表已知的安全場景，這是系統有能力處理的安全場景，例如這些場景已經完全在系統的ODD范圍內，也可以是現有措施可以解決的場景。
Area 2代表已知的不安全場景，這些是系統設計者已知的場景，在這些場景下，系統不能安全地運行。系統設計者可以通過幾種途徑：

  • 分析方法（FTA、FMEA、HAZOP、STPA等方法）；
  • 已有運行的現場數據和事故案例；
  • 已有系統開發的經驗教訓；
  • 標準、指南和行業最佳實踐

找出導致系統處于Area 2的觸發事件，對系統進行功能迭代優化，促成Area 2向Area 1的轉化。

Area 3代表未知的不安全場景，這些是系統設計者不知道的場景，因此沒有現實的數據和案例支持做決策，需要通過分析方法（FTA、FMEA、HAZOP、STPA等方法）、仿真和實際道路測試進行觸發，以識別出未知的不安全情況，促成Area 3向Area 2的轉化。

Area 4代表未知的安全場景，這些場景系統可以安 全 處 理，因此SOTIF并不識別這些場景。

四象限中，Area 3的范圍是SOTIF的最大挑戰，它不可能完全消除，剩余的未知不安全場景將作為系統的殘余風險，最終評判是否可接受。
 
SOTIF生命周期模型 VS ISO26262生命周期模型

在汽車電子系統的研發過程中，伴隨著功能安全和預期功能安全從風險分析、安全需求確定、軟件和硬件的設計、驗證與確認過程。下圖在ISO26262生命周期模型中標注了SOTIF對應的階段。

如何理解預期功能安全的圖4

上圖中標紅的是SOTIF生命周期模型階段，具體為

  • ISO21448.5：functional and System specification

  • ISO21448.6：SOTIF related hazard identification and evaluation

  • ISO21448.7：identification and evaluation of triggering events

  • ISO21448.8：functional modifications to reduce SOTIF risks

  • ISO21448.9：definition of the verification and validation

  • ISO21448.10：verification of the SOTIF: evaluate known scenarios

  • ISO21448.11：validation of the SOTIF: evaluate unknown scenarios

  • ISO21448.12：methodology and criteria for SOTIF release


從上面的生命周期模型映射關系來看：

  1.  對于功能安全和SOTIF來說，系統的邊界、功能、場景條件的假設，對于兩者都很重要，而SOTIF更要確定設計使用的傳感器類型、關鍵算法功能的初步描述，因為這些定義對于SOTIF風險分析很重要；

  2. 功能安全HARA風險分析用于識別安全目標，從而將安全目標分解到軟硬件層面；而SOTIF不會給每個功能規定一個安全等級，在于找到促成風險向區域2，進而向區域1轉化的措施；

  3.  預期功能安全沒有像功能安全標準一樣，規定軟硬件的設計實現方法，而重點放在對風險減輕措施的驗證和確認策略上，這一點可能是從所實現技術的更新迭代速度，對于標準來說，規定做什么，而不規定怎么做，但筆者建議，對于ISO26262的技術方法，如果SOTIF同樣采用了類似的技術，應該參考ISO26262的要求來做；

  4. SOTIF對于傳感器、決策算法、執行器給出了推薦性的驗證與確認策略，用于避免累積跑無效里程，而采用需求驅動、風險事件驅動的VV策略。
 
HARA VS SOTIF風險評估

實際項目實施中，沒有必要分別去做HARA和SOTIF風險分析，整車級危害所引出的安全目標可以基于同一個過程來做，但在SOTIF會識別出可預見的人員誤操作造成的頂層危害，以車道保持系統（實現車輛的居中和變道行駛）為例，在功能安全中，整車級危害有：

  • 車道保持系統啟動過程中發生車道偏離；
  • 在目標車道上由于障礙物或車道被占變道；
  • 車輛未完成變道或跨越到兩車道；
  • 系統對更高優先級的安全系統造成干擾（爭奪控制權）

而從SOTIF角度，考慮到可預見的司機誤操作，還存在的危害有：

  • 司機與系統之間控制權的轉換不當；

造成的事故后果可能是撞行人、與迎面車輛相撞、撞擊障礙物、追尾車輛、側面相撞，判斷風險等級都是從可控性、嚴重性、暴露性三個方面去評價，以確定整車級的安全目標。

預期功能安全的啟發

春節前發生的地鐵夾人導致傷亡的事件，事故造成的影響很大，引發了社會公眾對于無人駕駛系統的關注，現在還未發布最終的事故報告，根據現場的視頻和各方的分析，與現場站務人員在處理站臺門夾人故障情況下操作有關，從SOTIF角度，這也是一個系統故障（屏蔽門夾人）疊加人員誤操作造成了更嚴重的事故。

從系統安全角度會做操作與維護造成危害的安全分析，但從功能安全的角度，多數把人員的失效排除在系統設計范圍外，通過對人員的管理規定進行落實。但從各行業的歷次事故報告來看，在緊急狀況下，人往往是靠不住的，比如737 MAX事故中自動駕駛系統與駕駛員控制權的爭奪，723事故中高鐵信號系統故障后調度員未對司機進行及時提醒。從預期功能安全的角度，對人員誤操作開展風險分析，并制定相應的驗證確認策略，就有很大的必要性。

按照預期功能安全對人員誤操作進行安全分析，需要考慮的情況有：

  • 操作人員對系統信息的識別，需要考慮操作人員對系統給出信息不理解和理解錯誤（信息發生混淆）的情況；
  • 操作人員錯誤的判斷，無意對系統的停用、錯誤的啟動和解除系統；
  • 操作人員錯誤的動作，對其它系統錯誤操作導致本系統無意地停用；
  • 人機界面接口的控制和響應操作錯誤。

談預期功能安全的觸發事件triggering event，它指的是車輛駕駛場景的某個特定條件，啟動了系統的特定反應，導致危害事件發生。

在ISO21448中舉了一個例子：車輛在高速公路上行駛過程中，車輛的自動緊急制動系統AEB誤認為路標是前方的一輛車，從而以X g的減速度減速Y秒。

這個示例中，觸發事件是AEB的感知子系統對前方物體的識別發生了誤判，危害事件是非預期的減速，可能導致車輛的追尾事故。

如何理解預期功能安全的圖5

ISO21448定義的第一類觸發事件是超過系統和部件性能限制的事件，需要針對系統設計所使用的技術，以車道保持系統使用的camara和radar為例，列舉幾個典型的SOTIF觸發事件。

如何理解預期功能安全的圖6
例1：環境中的干擾因素如道路的光線反射，會影響相機檢測車道標線的能力，下圖中對光線反射亮斑的識別

如何理解預期功能安全的圖7
例2：相機對路面環境條件的檢測可能造成的誤判，下圖中車輪行駛印跡與車道線的混淆

如何理解預期功能安全的圖8
例3：雷達天線上覆蓋水膜對雷達信號的損失衰減，下圖中水膜厚度的增加對雷達天線功率的影響，引自[1] https//www.hirecpaint.com

以上這些示例都屬于感知組件中在物理環境中的局限性導致的性能下降，在系統的功能安全分析過程中，不會覆蓋此類性能局限下的影響分析，這類外部環境對系統傳感器、控制器、執行器的影響是SOTIF的范圍。

第二類觸發事件是潛在可能的非預期的人為誤操作，第一類觸發事件中，有人機界面的限制，人機界面屬于系統內的一部分，也存在潛在的性能不足，還有的觸發事件是人為潛在的可預見的誤用。

列舉幾個典型的SOTIF第二類觸發事件：

例1：駕駛員難以接觸系統控制界面（如果系統控制位于子菜單中或控制界面的按鈕位置設計較遠）。

如何理解預期功能安全的圖9

例2：車道保持系統在控制過渡期結束時將控制權還給駕駛員，未考慮司機的注意力狀態。

例3：駕駛員將其他車輛系統反饋的信息，如其它系統發出的警告，誤認為是自動車道保持系統的警告。駕駛員可能會操作車道保持系統的控制功能，而不是操作其他系統的控制功能。

例4：駕駛員在系統的ODD范圍外啟動自動車道保持系統，不滿足進入系統功能的條件。

在ISO21448附件E中描述的三個階段的人為操作過程：

  1. 對信息的獲取
  2. 對信息的判斷
  3. 對系統的操作

將人類比于一個系統，按照I-P-O的方式去分析三個環節中存在的各種誤操作因素。

如何理解預期功能安全的圖10

SOTIF規定的第1類和第2類觸發事件相當于功能安全HARA分析中的危害識別，觸發事件的識別是一個不斷遞進往復的過程，它的細化程度決定了減輕措施的針對性。

在ISO21448中，減輕措施的類別可以歸為以下幾種：

對系統性能限制的減輕策略
  • 限制系統操作或特定使用情況（降級條件）下的權限。
  • 防止系統在特定的使用情況下運行。

設計改進的緩解策略
  • 提高算法的性能。
  • 采用多樣化的傳感器技術以規避單一傳感器的性能受限。
  • 調整傳感器位置。
  • 檢測傳感器受到的干擾并作出反應。
  • 確定系統所處于ODD的極限邊界。
  • 改進控制執行技術，包括反應時間、準確度、耐久程度和可靠性能力。
  • 檢測并應對已知的不支持的user case。
  • 針對已知的不安全情況，通過系統和組件的可測試性進行檢測。

緩解策略，以改善人的后 備操作，減少可預見的誤用
  • 改進人機界面。
  • 改進預警和降級策略。
  • 提高司機對系統限制的理解。

理解了SOTIF的觸發事件，如何開發完備的針對所考慮系統的觸發事件場景，是一個具有挑戰性的工作，如何從具有無限種可能性的場景分析中找出影響系統預期功能的觸發事件，這個方面在ISO21448中并沒有提供明確的指導方法。

在系統開發V模型中的上升階段，什么時候意味著開發可以收口，系統達到了發布的條件，從風險管理的角度，就是說具備什么條件，意味著系統殘余的風險可以接受，在預期功能安全中，可以總結為兩句話：

一：所有已知的風險已有對應措施進行了控制（區域2）——ISO21448第10節
二：所有未知的風險在實際運行中已經足夠?。▍^域3）——ISO21448第11節

下面對這兩個方面展開談談

第一句是對已知的不安全情況（區域2）進行評估，確保在采取SOTIF緩解措施的情況下，已知情況下導致危害事件，不存在不合理的風險了。緩解措施可能包括限制系統應用范圍ODD，進行傳感器和算法的冗余設計。風險接受的重點在于是否根據已知的緩解措施對傳感器、算法、執行器和集成后的系統進行有針對性的測試。ISO21448提供了一系列測試方法的組合，包括分析、模擬仿真和實車測試，用于對區域2的各種場景進行全面的測試。

驗證技術的運用不那么簡單，寥寥數語，實際做起來非常考驗安全和驗證人員的能力。舉個例子，對于第一點，已知不安全情況的風險評估，在采用了冗余的系統架構時，不同計算通道的獨立性是需要驗證的。而獨立性要從系統失效的獨立性（軟件和硬件）和隨機失效的獨立性（硬件）兩個方面進行驗證，例如軟件系統性失效方面如使用了兩個不同類型算法的分類器，但采用了相同的數據集進行訓練，容易對相同的樣本產生同一錯誤的輸出，因此建議采用有區分度的數據集進行訓練，硬件系統性失效，如主計算通道和輔計算通道采用了不同的硬件平臺進行冗余計算，但存在采用了同一電源，在同一個電路板上，存在由于電源波動和EMI干擾，導致多樣化硬件同時失效的情況，這些都是系統保證獨立性需要考慮的因素。

比如在基于觸發事件進行場景測試時，要求單個觸發事件有明確的場景條件，基于場景可以去構建測試案例，如果危害分析中的觸發事件比較籠統，則需要進行額外的分析，以建立基于場景的測試案例。以車道保持系統觸發事件——車道線被覆蓋導致相機無法檢測到，需要考慮的場景變量就有很多種：

車輛行駛的地點有：出入高速口、車道并窄、分叉口、彎道左轉、彎道右轉、施工維修路障；

覆蓋物類型有：水完全淹沒、雪、沙、雨水淋、泥漿、淤泥、標線模糊、跌落異物。

如何理解預期功能安全的圖11
ODD不同場景的延展 （取自網絡）

第二句是對未知的不安全情況（區域3）進行評估，這是非常具有挑戰性的，僅靠測試里程的不斷累積顯然無法達到目標，需要綜合運用結構化的分析技術（如引導詞頭腦風暴HAZOP）和道路測試，暴露未知不安全的場景。在SOTIF過程中，識別未知不安全場景所需的測試范圍仍然是一個尚未解決的問題，測試范圍與場景的類別和分布相關聯，能夠覆蓋ODD的所有要素，并考慮到以前的經驗成果、司機的可控性和其它因素。

ISO21448附錄C提供了一種方法，先設定一個里程目標值，在測試范圍中識別出了新的未知不安全場景，就需要補充新的類型的測試，以針對設計更改的范圍。

如何理解預期功能安全的圖12

總結以上，在ISO21448中對于區域2和區域3給出的指導性原則方法，在實際項目中進行延展，構建一套完整的結構化分析方法和測試場景庫。

那么，什么是預期功能安全最終的衡量標準，可以考慮的方法有：

  1. 與現有的交通數據（如碰撞事故統計、數據分析）比較；
  2. 現行行業中類似功能預先存在的目標；
  3. 與人類駕駛員行為的對比
  4. 其它的風險接受準則（GAMAB、ALARP等）。

對于L2和L3級系統，由于存在著自動駕駛系統與人之間的權限過渡，如果系統不能實現駕駛任務，但是能安全地讓司機接管，也會避免事故的發生，因此需要考慮司機接管成功的概率。

沒有足夠的交通數據的情況，選擇其它的風險評價原則，GAMAB和ALARP是法國和英國鐵路領域應用的風險評價原則，

GAMAB（全局至少一樣好），增加系統帶來的風險不高于用于比較的現有系統的風險。這個概念是基于風險和危害之間的權衡。

ALARP，合理可行的范圍內減少風險，同時考慮減少風險的成本，取得風險降低和成本之間的權衡。

以上四種風險接受方法可以結合使用，先將系統性能與交通數據或人類駕駛行為進行比較，取決于數據是否可用，如果系統允許司機接管，則評估司機安全接管的概率，不斷驗證和迭代系統開發，直到系統滿足選定的指標。最后，如果存在具有成本效益的措施可以進一步降低風險，滿足ALARP原則，也將這些措施考慮到系統設計中。


登錄后免費查看全文
立即登錄
App下載
技術鄰APP
工程師必備
  • 項目客服
  • 培訓客服
  • 平臺客服

TOP

1