自動駕駛安全框架開發進展綜述

導讀

對於自動駕駛車輛來說，安全的重要性毋庸置疑，為了恰當評價從而確保自動駕駛車輛的安全性，各國家、公司和組織已經開始努力開發一個自動駕駛安全框架或至少部分框架，以指導ADS的安全測試和部署。

本文對部分已公開的自動駕駛安全框架進行彙總介紹，歡迎大家留言補充。

RAND公司《衡量自動車輛安全：構建框架》

蘭德公司（RAND）2018年釋出了一份自動駕駛安全衡量框架的報告Measuring Automated Vehicle Safety： Forging a Framework，提出了一個用於測量配備ADS自動駕駛系統的車輛安全性的部分框架。在開發該框架時，考慮瞭如何定義ADS安全性、如何測量ADS安全性以及如何傳達對AV的瞭解和理解。報告旨在提供一個框架，討論如何以技術和公司中立的方式衡量安全性。

呈現了在不同環境（模擬、封閉場地、公共道路，有、無安全駕駛員）中針對不同階段（開發、驗證和部署）可以採用的安全衡量方法，

在報告中明確了自動駕駛汽車生命週期中的三個階段——開發、驗證和投放，並

將碰撞事故次數、交通違規次數、和“公路駕駛技能”（roadmanship）作為評定自動駕駛安全性的指標。

採用 Haddon 矩陣對碰撞因素進行分析，以便進行測量與干預。

測量框架聚焦於系統和生態系統級

Integrated Safety Framework

MobileEye 公司RSS責任敏感安全模型

MobileEye提出了一個名為RSS責任敏感安全（Responsibility Sensitive Safety）的框架，旨在解決多智慧體安全問題（由其定義為在給定環境中與多個獨立道路使用者的安全操作和互動）。RSS是一個多智慧體安全的數學模型，希望透過建立數學公式的手段，來使得自動駕駛汽車有能力判斷自身的安全狀態，從而儘可能避免事故的發生。它結合了駕駛的常識規則，同時與其他道路使用者進行互動，以最大限度地減少造成碰撞的可能性，同時在正常的行為預期範圍內操作。該方法是根據“路權”構建的規則、遮擋物體避免以及縱向和橫向的安全距離保持。MobileEye稱討論中涵蓋了特殊交通條件，包括交通燈交叉口、非結構化道路以及涉及行人（或其他道路使用者）的碰撞。

從本質上來看，RSS 模型是一整套數學公式，將人類對於安全駕駛的理念和概念轉化成為數學公式和計算方式，用來界定什麼樣的駕駛行為才是安全的駕駛。RSS 模型希望把人類駕駛員的本能變化成一套嚴謹的公式演算法，來指導 AI 的決策演算法在特定場景下做出合理安全的判斷。

RSS描述的不是駕駛策略，而是對駕駛策略的結果進行安全判定。另一方面，RSS在定義不同場景下的危險情況、正確反應、事故責任劃分中，是基於人類駕駛員的常識，而非僅僅法律法規。

RSS模型要達到的目標

具有兩重含義：

自動駕駛汽車本身不會導致事故（捲入事故和導致事故是完全不同的概念，自動駕駛汽車可能捲入事故，但它不是事故的責任方）

自動駕駛汽車應該在其它車輛發生錯誤時做出正確反應

在實際建立模型的時候，RSS 模型透過四條形式化的規則，來確保車輛在自動駕駛狀態下能夠保證安全以及避免成為製造車禍的一方：

和前車保持安全距離；

給側邊的人或車留下足夠的反應時間和空間；

在堵車的時候更謹慎；

要合理使用路權（路權的使用應優先考慮安全）。

Mobileye 在建立 RSS 模型的時候，則是把 RSS 定位在決策之後、執行之前。

如果決策演算法在某個狀態下做出了剎車的判斷，那麼這個判斷就會輸入到 RSS 模型中，得出剎車操作是否能在當前狀況下保證車輛的安全。如果結果顯示安全，那麼這個命令會直接執行；如果結果顯示有危險，那麼 RSS 模型會把這個指令返回到決策演算法，進行二次決策直到得到最安全的結果。

安全距離是指在最惡劣的情況下仍可以避免碰撞的距離。

Mobileye 釋出的官方報告中例舉了 37 種可能發生事故的場景，包括了車輛並行狀態的安全間距、安全併線的間距、避免追尾的最小安全距離、路邊有行人闖入機動車道時的安全車速等等。這 37 種狀況基本覆蓋了 99。4%的車禍可能性，也說明 RSS 模型目前已經達到了一個相當健全可用的狀態。

NVIDIA公司SFF安全框架

NVIDIA2019年3月釋出了一種稱為“安全力場（SFF：Safety Force Field）”的框架，該框架作為計算方法，用於透過模擬評估ADS是否成功監控其周圍環境且未採取不可接受的行動。SFF旨在避免撞車，其目的是透過制定一項駕駛策略來實現這一目標，該策略分析周圍環境並預測其他道路使用者的行動。根據這一分析，系統將尋求確定潛在行動，以避免造成或促成可能導致交通事故的不安全條件崩潰。

安全力場會確定一組可接受的動作來保護當前車輛以及道路上的其他車輛。這些動作並不會造成、加劇或導致危險情形的出現，此外還會包括用於緩解危險情形的必要措施。NVIDIA DRIVE 平臺使用車輛感測器資料來支援基於物理原理的SFF逐幀計算。

自動駕駛安全第一至12條原則

2019年7月， “自動駕駛安全第一” 11家企業聯盟釋出了一種描述ADS安全性設計、驗證和確認（V&V）的方法。旨在解決L3和更高級別的自動駕駛問題，並可作為檢查適用於ADS的V&V方法的有用起點。為指導安全工作，該檔案確定的共12條原則包括：安全操作；ODD確認；交通行為；使用者責任；車輛接管請求；車輛操作員與自動駕駛系統的互相依賴；自動化效果；安全評估；資料記錄；安全和被動安全；交通行為；安全層等。

Aurora自動駕駛安全案例框架

Aurora於2021年8月推出了第一個適用於自動駕駛卡車和乘用車的安全案例框架（Safety Case Framework）初始版本。

Aurora使用基於安全案例的方法，評估自動駕駛車輛何時能夠安全地在公共道路上行駛，並評估它們是否不會對機動車安全造成不合理的風險。

Aurora安全案例框架評估了車輛的整個開發生命週期，夠加快部署的速度，並確定何時可以接受自動駕駛車輛在公共道路上的安全性。

基於安全案例的方法以合乎邏輯的方式將這證據與主張兩個基本概念結合在一起，以有效地展示為確定車輛在公共道路上安全行駛所做的工作。

Aurora的安全案例框架覆蓋了對評估公共道路上自動駕駛車輛的安全開發、測試和執行至關重要的不同要素。該框架的設計涵蓋了與車輛操作員的測試，也包括沒有操作員的測試。同時，它是為適應環境而構建的，因此可以根據不同的場景和環境對其進行定製。能夠將安全案例宣告改編為適用於不同的車輛平臺、有操作員的車輛、試車跑道上的車輛以及公共道路上的車輛。

安全案例框架旨在適應不同的車輛、場景和環境。因此，將有多個單獨的安全案例，涵蓋各種配置、平臺和操作領域，而不是涵蓋自動駕駛車輛所有用途的單一安全案例。

最高級別目標

Aurora安全案例框架圍繞著“我們的自動駕駛車輛在公共道路上執行是可接受的安全性”這一最高級別的宣告展開，並將這一主張分解為五個安全原則或子原則。

G1：精通/Proficient：

自動駕駛車輛在正常執行期間具備可接受的安全。

G2：故障安全/Fail-safe：

自動駕駛車輛在出現故障和失效時具備可接受的安全。

G3：不斷改進/Continuously improving：

對構成不合理安全風險的所有已識別潛在安全問題進行評估，並採取適當的糾正和預防措施予以解決。

G4：有彈性的/Resilient：

在可合理預見的誤用和不可避免的事件情況下，自動駕駛車輛具備可接受的安全。

G5：值得信賴的/Trustworthy：

自動駕駛企業應是值得信賴的。

頂級宣告是根據涵蓋安全操作範圍的安全原則定義的，使用廣度優先、深度第二的方法分解每個安全原則。每個安全原則都被分解為中間論點、上下文和策略的層次，將每個安全論點作為邏輯分解進行追蹤。

安全原則分解示例

Waymo 系統安全計劃 SSP

Waymo在制定其安全計劃時借鑑了航空航天、汽車、國防等行業中的最佳安全實踐原則。

Waymo的安全體系一共有「五個維度」：

「行為安全」：

指車輛在道路上的行駛決策和行為

「功能安全」：

確保車輛在系統存故障或失效時的安全操控，這意味著要建立備份系統和冗餘機制來應對車輛的意外狀況。

「碰撞安全」：

車輛透過各種措施保護車內乘客的能力，藉助結構性設計來保護車內人員，提供座椅約束裝置及安全氣囊，減輕車內人員的傷亡程度。

「操作安全」：

人機互動，為消費者帶來自動駕駛車輛所提供的安全而舒適的體驗。

「非碰撞安全」：

電子器件與人類的物理隔離，提供身體上的安全防護。

Waymo在開發過程裡利用了常用的風險評估方法，如：

預先危險性分析（PHA）、故障樹（FTA），設計失效模式及後果分析（DFMEA）

等，也基於系統架構要求，針對軟體在公共道路、閉合環境及模擬駕駛情景內進行了大量的測試。這些鋪墊工作為每一個安全課題提供了大量的研究資料。此外，Waymo也採用了全面的安全實踐方法來提升系統的可靠性。

NHTSA曾就自動駕駛提出了28項核心競爭力清單，自動駕駛系統需要針對這28項技能證明自己的“行為能力”。Waymo在此基礎上，從深度和廣度上都拓展了這個要求（增加了19項核心能力），建立了具有挑戰性的測試內容。

VSSF車輛安全與安防框架（RDW）

荷蘭交通部車輛認證中心RDW提出了自動駕駛車輛安全框架提議，目標是實現自動駕駛車輛認證流程標準化。

美國AV 3。0提出的12項安全要素

美國AV 3。0中提出了自動駕駛車輛開發、開放道路測試、應用相關最主要的安全要素，包括：系統安全、ODD（Operational Design Domain）、OEDR功能、Fallback（Minimal Risk Condition）、網路安全、資料記錄、碰撞安全性（成員保護）、碰撞後處置（Post Crash）、自動駕駛車輛行為、驗證與測試、人機介面（HMI）、使用者教育與培訓、聯邦和當地法規。

車輛效能指南框架/Framework for Vehicle Performance Guidance

UL 4600《自動駕駛產品安全評估標準》

2020年4月，非營利標準組織Underwriters Laboratories（簡稱UL）宣佈UL 4600《自動駕駛產品安全評估標準》正式釋出，這是UL針對無人駕駛車輛而開發的首個安全評估標準，屬於自願性行業標準草案。

與ISO 26262和21448一樣，UL 4600是一個以過程為中心的標準，旨在供製造商在開發AV時使用。

標準範圍包括評估自動駕駛產品的安全原則與流程。此標準基於設計流程、測試、工具資格、自主性驗證、資料完整性以及針對非駕駛員的人機互動等因素，涵蓋相應風險分析與安全相關方面等若干主題，並要求提供安全論證。

標準規定採用安全案例方法來確保ADS的安全性。已釋出的安全案例方法包括三個主要要素：目標、論證和證據；每個要素都說明支援前一要素，以構建總體安全案例。

ISO 2626-功能安全

ISO 26262描述了功能安全評估過程的檔案，以幫助開發安全相關電氣和/或電子（E/E）系統。該框架旨在供製造商用於將功能安全概念整合到公司特定的開發框架中。一些要求具有明確的技術重點，以將功能安全實施到產品中；其他要求涉及開發過程本身，因此可以視為過程要求證明組織在功能安全方面的能力。

ISO 26262解決了由電氣和電子故障引起的已識別的不合理安全風險。該框架旨在應用於安全相關係統，包括安裝在生產道路車輛（不包括輕便摩托車）中的一個或多個E/E系統。ISO 26262旨在避免與電子系統相關的故障包括與軟體程式設計、間歇性電子硬體故障和電磁干擾相關的故障，並減輕執行期間潛在裝置故障的影響。除了解決故障條件外，還包括危險分析和風險評估規定、設計、驗證和確認（V&V）要求和安全管理指南。

ISO 26262旨在確保系統能夠充分緩解已識別危險的故障風險。所需的緩解量取決於潛在損失事件的嚴重程度、危險的操作暴露以及故障發生時系統的人類駕駛員可控性。這些因素結合在一起構成汽車安全完整性等級（ASIL）。ASIL確定應採用哪些技術和過程緩解措施，包括必須執行的指定設計和分析任務。

ISO 21448-SOTIF預期功能安全

ADS的安全性還與其他因素有關，如可想象的人為誤用功能、感測器或系統的效能限制以及車輛環境的意外變化。

SOTIF（預期功能的安全性）試圖防止預期功能不足或可合理預見的人員誤用。即使不存在裝置故障，也可能無法正常執行。SOTIF不適用於ISO 26262系列涵蓋的故障或直接由系統技術。相反，SOTIF與ISO 26262協同工作，以幫助製造商評估和緩解開發過程中的各種風險，ISO 26262側重於降低故障風險，ISO 21448側重於緩解可預見的系統誤用。

ISO 21448旨在應用於預期功能，其中適當的態勢感知對安全至關重要，並且該態勢感知源自複雜的感測器和處理演算法；特別是緊急干預系統（如主動安全制動系統）和高階駕駛員輔助系統。根據SAE國際標準，該標準可用於更高級別的自動化，但可能需要採取其他措施。

ISO 21448主要考慮緩解因意外操作條件（由於感測器和演算法的限制，預期功能可能不會始終在此類條件下工作）和需求差距（缺乏對實際預期功能的完整描述）而產生的風險。

美國NHTSA 的AV安全框架開發

2020年12月，美國國家公路交通安全管理局（NHTSA）透過ANPRM形式面向社會徵集對自動駕駛安全框架的建議。

以功能安全、SOTIF和UL 4600的描述為背景，NHTSA正在考慮如何在制定關於ADS的新框架的背景下，利用這些過程標準，無論是基於法規還是提供指導。

該機構預計安全框架將包括管理風險的過程和工程措施。過程措施（例如，在車輛設計過程中分析、按嚴重程度和頻率分類以及減少潛在風險源的一般做法）可能包括穩健的安全保證和功能安全計劃。工程措施（例如，效能指標、閾值和測試程式）將尋求提供證明ADS以高水平熟練程度執行其預期功能的感知、感知、規劃和控制（即執行）的方法。

NHTSA的一個關鍵研究方向專注於ADS安全效能，並尋求確定方法、指標以及評估配備ADS的車輛執行正常駕駛任務和防碰撞能力的工具。此類評估包括與系統規定的ODD和物件及OEDR事件檢測與響應能力相關的系統性能和行為以及在遇到ODD以外的條件時的故障安全能力。

第二個高階研究重點是功能安全和ADS子系統效能。

第三個研究領域涉及車輛和系統（包括ADS）的網路安全。

最後，NHTSA還研究了配備ADS的車輛可能存在的人為因素問題。

雖然感知、判斷、規劃與控制四種核心安全功能功能對於ADS是必要的，但它們不一定足以確保ADS的安全，這還取決於系統的各種其他功能和能力，以及該系統如何與配備ADS的車輛內部和周圍的人進行互動。

例如，四個功能中未包含的一個安全相關方面是車輛在駕駛環境中與車輛乘員、其他車輛和人員、尤其是易受傷害的道路使用者進行通訊的能力。ADS能夠準確、可靠地檢測車輛中自身系統或其他系統的故障，同時確保為響應任何檢測到的問題或故障而開發的操作模式之間的安全過渡（例如，故障保護或跛行回家模式）是可能影響ADS預期效能的另一個重要考慮因素。

可能影響ADS以安全可靠的方式執行其預期計劃能力的其他方面包括：

在出現故障時識別降低的系統性能和/或 ODD；

在降低的系統約束下以降級模式執行；

執行將乘客或貨物從起點運送至所選目的地的基本任務；

識別來自優先響應者的通訊並作出適當反應，包括消防、EMS 和執法；

接收、裝載和跟蹤 OTA 軟體更新；

執行系統維護和校準；

解決與安全相關的網路安全風險；

系統冗餘。

NHTSA致力於開發安全效能模型和指標的一個關鍵例子是2017年釋出的ISM瞬時安全指標。ISM瞬時安全指標計算了受試車輛和周圍交通中的其他道路使用者在給定一組可能行動時在未來預設的有限時間內可能採取的物理軌跡（例如，方向盤角度、制動/油門），並計算可能導致潛在多因素碰撞的軌跡組合。由軌跡的數量和/或比例（以及導致該軌跡的動作的嚴重性/機率）確定可能導致碰撞指標，作為評估給定駕駛狀態安全風險的工具。

更新的方法是MPrISM模型預測瞬時安全度量（：Model Predictive Instantaneous Safety Metric），建立在ISM概念的基礎上並修改其評估方法。MPrISM考慮受試車輛的完全可控動作範圍，並在受試車輛做出最佳響應選擇和現場其他參與者做出最差選擇的情況下計算碰撞影響。

ISM和MPrISM的優點之一是它們的邏輯推理和直接分析結構。然而ISM在實際應用中的一個挑戰是有效利用所需的巨大計算複雜性。MPrISM試圖透過新的度量開發工作解決這一難題，NHTSA將繼續研究降低複雜性的方法。

UNECE WP29《自動駕駛汽車框架檔案》

2019年6月，聯合國WP。29會議審議通過了中國、歐盟、日本和美國共同提出的《自動駕駛汽車框架檔案》。

在系統功能安全方面，要求“車輛製造廠商應該以設計出免於不合理安全風險的自動駕駛系統和保證負荷道路交通法規與本檔案列出的原則為目標，根據系統工程方法呈現一個健全的設計和驗證過程。設計和驗證方法應該包括對以下方面的威脅分析和安全風險評估：自動駕駛系統（ADS），目標事件探測與響應（OEDR），包含上述內容的整車設計，以及更廣泛的交通生態系統（如適用）。設計和驗證方法應展示出自動駕駛汽車正常執行期間的預期行為能力，避免碰撞的效能以及後備支援的效能，試驗方法可組合模擬測試、場地測試和實際道路測試”。

在資訊保安方面，要求“基於已建立的網路車輛物理系統最佳實踐方案，自動駕駛汽車應免受網路攻擊。車輛製造商應表明如何將車輛資訊保安考慮整合到自動駕駛系統中，這些考慮包括所有的行動、變化、設計選擇、分析和相關測試；以及確保資料在文件版本控制環境中是可追溯的”。在軟體更新方面，“車輛製造商應確保系統更新可根據需要、以安全的方式進行，並可根據需要應用於售後修理和修改”。

在事件資料記錄（EDR）和資料儲存系統（DSSAD）方面，要求“自動駕駛汽車應具有采集和記錄與系統狀態、故障發生、降級或失效相關必要資料的功能，採用一種可用來確定任何碰撞發生的原因、自動駕駛系統狀態以及駕駛員狀態的方式”。對於車輛維護和檢查，要求“應利用自動駕駛汽車維護和檢查等相關措施，確保在用車輛的安全。此外，鼓勵車輛製造商提供檔案，便於對碰撞後自動駕駛汽車的維護和修理。這些檔案將確定能保證自動駕駛汽車在修理後可安全執行的必要裝備和過程”。

除了《自動駕駛汽車框架檔案》之外，GRVA的提案Proposal for amendments to Framework document on automated/autonomous vehicles （levels 3 and higher）還提出了UNECE WP29

應優先考慮的關鍵問題和原則

：

a。系統安全/ System Safety。

b。失效響應/Failsafe Response。

c。人機介面/Human Machine Interface （HMI） /Operator information。

d。OEDR/Object Event Detection and Response （OEDR）。

e。ODD/ ［Operational Design Domain （ODD/OD）］（automated mode）。

f。系統安全驗證/Validation for System Safety。

g。網路安全/Cybersecurity。

h。軟體升級/ Software Updates。

i。事件記錄與儲存系統/Event data recorder （EDR） and Data Storage System for Automated Driving vehicles （DSSAD）。