Lesson 1: Safety Assurance for Self-Driving Vehicles

歡迎來到本課程的第三周。?本周, 我們將深入探討基礎知識關于將安全性融入自動駕駛汽車設計的。本單元中，我們將討論最近的一些自動駕駛車的碰撞報告，然后我們會正式定義自動駕駛車的安全概念,?并討論最常見的危險源。?我們將討論一些行業對安全性的看法，最后，?我們將通過討論安全系統設計中使用的一些常見框架來總結。?

在本課中, 我們將討論?2017年和2018年首次發生的自動駕駛車碰撞事件。?然后，我們將定義一些基本的安全概念并?列出一些自動駕駛車危險的最常見原因，?并討論低水平和高水平的安全要求。?應該指出，本單元中的材料?大多取公布的指南,?由國際標準組織ISO發布的。?您可以在網上找到這些框架的更全面版本。?

?

讓我們首先討論一些迄今為止更為突出的自動駕駛汽車故障。2016年3月，一輛自動駕駛的谷歌車Waymo，撞上了一輛公共汽車的一側, 當它試圖從后面的障礙物中撤出時。一輛公共汽車正從后面駛來, 目的是將谷歌車停在車道上，這是在其車道的右側準備轉彎。谷歌汽車軟件認為, 這輛公交車不會試圖通過它,?因為它與下一車道的汽車之間的差距太窄。?事實證明， 公交車經常會在較小的縫隙中行駛?比谷歌預期小的縫隙，這也導致了這次的碰撞。當谷歌汽車可能會對公交車位置的新測量做出反應時，但為時已晚。這只是一個例子, 說明它是多么困難在事情發生之前預測所有其他車輛行動。?

?一年后，一輛優步自動駕駛車在另一輛車造成輕微碰撞時反應過度，最終翻車。?由于車輛的動態模型不承擔來自其他車輛的顯著干擾力，?因此控制器可能沒有針對這種情況進行測試并且反應過度。?此次碰撞突顯了集成?到控制系統中的穩健性以及涵蓋盡可能多的可預見事件的探索性測試的需求。?

?2017年底,一輛GMCruise雪佛蘭Bolt撞倒了一名摩托車手，在中止車道變換后。?在Bolt啟動機動之后，?它希望進入進去的間隙迅速關閉，?由于相鄰車道中的制動引導車輛。那個正打算變道的摩托車手，在Bolt旁邊向前移動，并阻擋了回程機動。Bolt 陷入了進退兩難的境地;與摩托車相撞或撞上兩輛車在相鄰的車道上。目前尚不清楚在這里作出具體決定選擇一個或另一個結果，訴訟也掩蓋了案件的細節。然而，由于其他agent也會預測自動駕駛車的動作，因此在許多情況下評估正確的行動是非常具有挑戰性的。在可能的情況下，并道可能是一種更激進的駕駛風格或者稍有延遲的中指可能就有足夠時間來避免撞擊到摩托車手。這種緊密的決策互動仍然是自動駕駛車的一大挑戰。?

最后, 我們應該談談 Uber 事故,?那場2018年初導致行人死亡的事故。?在亞利桑那州坦佩市，?優步當時有一個廣泛的測試計劃，?與安全司機在監控著自動軟件。?事故發生在一條寬闊的多車道分道路上，?當晚一名行人在一個沒有標記的地區騎自行車穿過馬路。?受害者Elaine Herzberg?是一名來自坦佩的49歲女子。?

這是從鳥瞰圖描繪的汽車和場景。?可以看到從圖像左側進入的行人?和從圖像底部沿著道路行駛的車輛。?初步調查顯示,?是由于多個失靈導致這次的事故。?

讓我們來看看促成的不同的因素。首先，安全司機沒有實時進行查看。那個時候，安駛員不專心，據稱當時正在觀看Hulu。?安全員在車上可能什么都可以做，優步在車輛上沒有任何方法來評估安全員的注意力。因為觀看自動駕駛系統操作是一項難以集中精力的任務，所以擁有安全駕駛員監控系統非常重要。?其次, 軟件檢測系統存在明顯的混亂。在最初檢測到6秒撞擊時，受害者首先被識別為未知物體，然后被誤識別為車輛，然后被誤識別為自行車。最后，無人駕駛軟件做出的決定是忽略檢測，可能是因為認為檢測太不可靠。感知并不完美, 切換分類不應當導致車輛完全忽略這樣的物體。最后，在發生碰撞前1.3秒，?沃爾沃緊急制動系統確實可以檢測到行人，并且會迅速施加制動以降低撞擊速度，從而可能挽救Elaine Herzberg的生命。然而, 那是不安全的,?在測試期間讓多個防撞系統同時運行。因此優步在無人駕駛模式下禁用了沃爾沃系統。最終，自動駕駛車沒有對行人的路徑作出反應，并且疏忽的安全員無法快速反應以避免撞擊。?這次事故由以下組成：?感知系統無法正確識別行人，用自行車和規劃系統來避免偵探物體, 即便類別是不確定的,?這樣導致了這次失敗，同時，缺乏人或緊急制動備用最終導致了死亡。

我們可以從這一系列事件中看到?自動駕駛系統的各個方面：?感知、規劃和控制都可能導致系統失敗和撞擊，而且多個系統或多個決策的交互往往會導致意外后果。事實上, 無人駕駛系統還有很多可能失敗的方式。?很明顯, 我們需要嚴格和詳盡的安全方法,?行業和監管機構正在正面應對安全挑戰。?好。現在, 我們對安全評估的挑戰有了認識,讓我們正式定義一些基本的安全術語。?

我們將使用術語,?

“Harm”定義對生物的物理傷害，?

"Risk" 一詞來描述事件發生的概率,?以及事件的嚴重程度，?可能造成的傷害。?

?

我們現在可以將安全描述為避免對生物造成傷害的不合理風險的過程。例如, 當交通信號燈為紅色時駛入交叉路口將是不安全的，因為這會導致不合理的風險，?對車輛和通過交叉路口的其他車輛。最后, 危險是潛在根源，不合理的傷害風險或安全威脅的。因此，如果我的系統軟件有可能導致事故的錯誤，那么軟件錯誤將是一個危險。?

?

現在，您認為自動車輛危害最常見的來源是什么？危險可能是機械的，因此制動系統的錯誤組裝可能導致過早失效。危險可以是電氣的，因此有缺陷的內部布線會導致指示燈不亮。危險也可能是計算用于自動駕駛的硬件芯片的失敗。如前所述，它們可能是由于無人駕駛軟件錯誤和bug造成的。?危險也可以由傳感器數據不良或嘈雜或感知不準確引起的。?危險也會發生，由于不正確的規劃和決策，無意中選擇危險操作也可能導致危險，因為特定場景的行為選擇設計不正確。也有可能是對安全員支援，?提供足夠的警告以恢復其責任，或者自動駕駛車可能被某些惡意實體攻擊。?這些都是主要類別的危害, 這些危害都是經?？紤]：機械、電氣、計算硬件、軟件、感知、規劃、駕駛任務支援和網絡安全。?

?

在評估整體系統安全性時，每種危險都需要不同的方法。我們將在后續視頻中詳細介紹如何處理這些類別。?既然我們知道安全所涉及的基本術語，那么讓我們考慮以下問題。我們如何確保我們的自動駕駛車真正安全呢？也就是說，我們如何處理復雜的駕駛任務和可能發生的許多危險，并為完整的自動駕駛系統定義安全評估框架？在美國，國家公路運輸安全管理局或國家公路交通安全管理局已經制定了一個由十二部分組成的安全框架，用于構建自動駕駛的安全評估。正如我們將在本單元的下一個視頻中看到的那樣，該框架只是一個起點，不同的方法，通過結合多種現有的放你發和標準方法已經在行業中已經出現了。讓我們首先討論NHTSA的安全建議。這個框架是作為建議發布的,?而非強制性的?？蚣茉?017年發布。?框架本身由12個領域或?或要素組成，任何自動駕駛公司應該關注或者更確切地說，?鼓勵關注。?

????????首先, 應采用安全的系統設計方法,?這實際上滲透到了整個框架文件中。精心策劃和控制的軟件開發過程至關重要，以及現有的 SAE 和 ISO 標準在汽車、?航空航天和其他相關行業應在相關情況下適用。?對于剩余的11個領域，?我們可以將它們大致分成兩類。?自治設計，這需要某些組件?被包括在自治軟件堆棧中并加以考慮,?測試和緩解碰撞,?其中包括測試自治功能和減少故障負面影響的方法,?以及從中學習。

在自治設計類別中，我們看到了一些我們已經熟悉的組件。?NHTSA鼓勵明確定義的ODD（設計適用范圍），??讓設計人員清楚地認識到這個系統的缺陷和局限性,?并且可以評估哪些方案是支持的并且是安全的，在測試或部署之前。?接下來，它激勵經過充分測試的物體和事件檢測和響應系統，?這對于感知和避免碰撞至關重要。?然后，它激勵汽車具有?可靠和方便的后退機制，?通過該機制警告駕駛員或使汽車自動安全。?開發這種機制至關重要，?記住駕駛員可能會疏忽。?因此，應該考慮如何將系統置于最小風險狀態，如果發生這種情況。?還應該設計驅動系統，以便所有聯邦級別，州級別和當地交通法規能夠在ODD內遵循和遵守。?接下來，該框架鼓勵設計人員考慮網絡安全威脅，?以及如何保護驅動系統免受惡意代理的攻擊。最后，應該對人機界面（HMI）進行一些思考。?因此，汽車應該能夠傳達機器的狀態在任何時間點，對乘客或駕駛員進行?？梢燥@示的狀態信息的重要示例是所有傳感器是否可操作，當前運動規劃是什么，環境中的哪些對象正在影響我們的駕駛行為等等。?

我們現在轉向測試和碰撞緩沖區。?首先，NHTSA建議在為公眾開展任何服務之前需要進行強有力的廣泛測試計劃。這種測試可以依賴三個共同的支柱：仿真模擬，近距離測試以及公共道路駕駛。接下來，應該仔細考慮減輕碰撞事件中發生的傷害或損壞程度的方法。碰撞仍然是公共道路駕駛和無人駕駛的考慮，最大限度地減少碰撞能量，要超過乘客安全標準，安全氣囊和碰撞價值應該是正常的。接下來，應該支持碰撞后的行為。例如，汽車必須迅速恢復到安全狀態，停止燃油泵燃油。發出警報等等。此外，應該有自動數據記錄功能或黑匣子記錄器。這些碰撞數據的分析和設計系統是有助于將來避免發生特定類型的碰撞，并解決出錯的問題，以及在事件發生時出錯的地方。?最后，應該有明確地對消費者進行教育和培訓。因此，在為消費者駕駛員和乘客進行測試和培訓期間，駕駛員的課程可以更好地理解部署的無人駕駛系統的功能和限制。最后一步對于確保我們對自動化的自然過度自信至關重要，這不會導致早期采用者引入不必要的危害。

?請記住，這些是任何公司應該處理的建議區域。尚未強制要求。?NHTSA的主要目標是指導公司?在不過度限制創新的情況下制造自動駕駛汽車。 人們預先選擇技術。?隨著市場的進入開始出現，可能會出現更加明確的安全評估要求。?這條線的斜率 這個導數是這條線的斜率 讓我們總結一下在這段視頻中，我們討論了無人駕駛行業首次發生的一些事故，并揭示了自動化軟件失敗的多種方式。然后，我們正式定義了危害，風險，傷害?和安全，并列出了自動駕駛車輛危險的主要來源。然后，我們看了NHTSA安全框架。

?

?Supplementary Reading: Safety Assurance for Self-Driving Vehicles

• Check out Dr. Krzysztof Czarnecki'spaper on WISE Drive: Requirements Analysis Framework for Automated Driving Systems. You will watch an interview with Dr. Czarnecki's later in this Module.

• Learn more about the non-mandatory safety guidelines for autonomous cars in the NHTSA - Automated Driving Systems: A Vision for Safety 2.0 report.

Lesson 2: Industry Methods for Safety Assurance and Testing

歡迎來到本周的第二節課。 在本課中，我們將討論有關安全和測試的各種行業觀點。 具體來說，我們先分析 業內兩大巨頭的安全觀點：Waymo 和 GM。 然后我們將討論兩種不同的評估方法 安全性：分析與經驗。 ????????讓我們開始。正如我們在上一個視頻中看到的，NHTSA 要求每個自動駕駛開發者，應制定和描述全面的安全策略涵蓋了其指導文件中包含的 12 個概念。迄今為止，Waymo 和通用汽車已經出現了兩份重要的報告，我們將使用這兩者作為我們討論行業安全方法的基礎。Waymo 安全報告于 2017 年發布，并且對如何組織有很多深刻的見解自動駕駛汽車的綜合安全策略。Waymo 涵蓋了 NHTSA 的所有 12 個概念，但將它們組織成五級安全方法。 ????????首先，Waymo 系統旨在在行為層面執行安全駕駛。這包括遵循交通規則的決策，可以處理 ODD 內的各種場景，并通過它維護車輛安全。其次，Waymo 確保系統有備份和冗余。這樣即使發生故障或故障，汽車可以切換到輔助組件或備份過程以最大限度地減少故障的嚴重性并使車輛恢復到安全狀態，如果可能，繼續駕駛。這稱為功能安全。接下來，Waymo 強調 NHTSA 推薦的碰撞安全。它設計的系統可確保將損壞降至最低發生碰撞時車內人員。接下來，它試圖確保操作安全。因此，這意味著它的界面是可用的、方便的和直觀的。這里的重點是讓乘客對車輛有一定程度的控制，但僅限于維護系統安全的方式。最后，Waymo 促進了非碰撞安全。這是指最小化的系統設計對可能以某種方式與系統交互的人的危險，急救人員、機械師、硬件工程師等。這五個支柱構成了 Waymo 的安全設計系統，并導致一個廣泛的需求定義系統，設計迭代，和測試以確保每個組件都滿足系統的目標。該過程使用了來自現有域，我們將在下一個視頻中詳細介紹這些工具。 一開始，Waymo 團隊確定了盡可能多的危險場景盡可能并分析每個可能的緩解策略，即如何保證車輛能夠發生危險時仍能達到安全狀態。然后，他們使用危害評估方法來確定更具體的安全要求。他們使用的各種方法都是對可能存在的安全風險進行初步分析，故障樹危害評估在動態駕駛任務方面自上而下，以及一些自下而上的設計失效模式和影響分析評估效果對系統整體功能的小子系統故障。最后，他們執行大量測試以確保滿足要求。

?讓我們討論一下 Waymo 的測試程序以下專門評估其軟件，因為它是最公開可見和有據可查的程序。首先，他們測試所有軟件更改每天模擬 1000 萬英里的模擬量。這代表了持續運行的巨大計算工作量確認對系統安全要求的預期改進。為此，他們挖掘了所有在路上的經驗來挑戰場景并執行系統的場景模糊測試，這會改變位置和其他車輛和行人的速度參數隨機，因此他們可以測試自我車輛是否在所有車輛中安全運行。這種方法對于尋找困難的邊緣情況特別有用，例如，難以解決合并或交叉路口的時間間隔。

?然后他們進行封閉式測試，他們在私人軌道上測試他們的軟件。它們涵蓋了加州大學伯克利分校研究確定的 28 個核心場景，以及 Waymo 添加的 19 個附加場景。這些場景是圍繞避免追尾四種最常見的事故場景，交叉路口、道路偏離和車道變更。這些類別中的每一個顯然都有很多變體，但它們加起來占所有事故的 84% 以上。

?最后，他們進行真實世界的測試，這些測試是經常出現在美國許多不同城市的街道上，包括位于 Google 主校區附近的加利福尼亞山景城。該測試使他們能夠識別越來越多的不尋常的案件主要依靠關于動態駕駛任務回退策略讓人類在測試期間監控自治軟件。這些測試策略的組合絕非 Waymo 獨有，但已成為事實上的標準，因為它提供固定投資的最大靈活性和反饋，將每種測試方法集中在它最擅長的方面，模擬操縱使它們變得困難的場景，封閉課程測試確認具體收益尋找更具挑戰性的場景的安全性能和實際測試，并提高公眾對該技術的信心。

?

?好的?，F在讓我們把注意力轉向通用汽車的安全理念，2016 年收購 Cruise Automation 并推動因此，它在自動駕駛開發方面處于領先地位。

????????GM 戰略非常遵循 NHTSA 安全框架密切關注 12 個主要領域中的每一個。通用汽車的安全策略并沒有試圖重組或簡化 NHTSA 指南，而是專注于其實現所需安全評估的實施策略。首先，通用汽車強調了他們的迭代設計模型，其中第一個分析場景，然后構建軟件，然后模擬場景，并測試他們的軟件。最后，將他們的軟件部署在現實世界的汽車上，他們不斷添加改進和改進需求和自治系統都是迭代的。

?其次，Waymo 依靠 OEM 來設計它的車輛，只討論與其自主硬件相關的機械和電氣危險，通用汽車完全自己制造汽車，因此可以強制執行更集成的設計與整個自動駕駛硬件的質量標準一致。其次，通用汽車通過全面的風險管理方案確保安全。他們識別和解決風險并嘗試完全消除它們，而不僅僅是減輕它們。最后，他們所有的系統都遵循內部明確定義的安全標準，可靠性、安全性等。他們在汽車行業擁有多年??的車輛開發經驗，并因此開發了廣泛的安全流程。

他們的安全過程涉及三種類型的分析。首先，他們通過以下方式進行演繹分析故障樹法和查明可能有故障的組件并解決它們。接下來，他們通過設計 FMEA 進行歸納分析。因此，他們對他們的設計方案進行故障模式和影響分析，并盡量自下而上確保安全。最后，他們采用危害和可操作性研究來進行探索性分析，并找出系統何時可能無法按預期工作。現在，這聽起來可能很熟悉，事實上，這些與 Waymo 描述的分析支柱相同。在下一個視頻中，我們將詳細介紹這些方法的實際工作原理。 讓我們談談安全閾值和通用汽車。所有通用汽車至少必須遵循兩個關鍵的安全閾值。首先，通用汽車定義了一套明確的故障保險、備份系統、和不同組件的冗余，所以即使發生故障，系統仍能繼續工作。二、組件必須通過我們將在下一個視頻中更詳細地討論 SOTIF 評估。通過此評估，我們確保所有關鍵功能都在已知和未知場景中進行評估。最后，通用汽車遵循由性能測試組成的嚴格測試機制，需求驗證，故障注入，侵入式測試、耐久性測試和基于模擬的測試。這兩家公司都嚴格遵守安全標準，并且因此，很好的例子說明了如何切實有效地確保安全。因此，我們現在對工業中如何進行安全評估有了更清晰的認識，但我們仍然有這個問題：真的有可能嗎？真正準確評估自動駕駛汽車是否安全？或者至少比人類司機更安全？

?讓我們討論一下可以采用的各種方法用于評估自動駕駛系統的安全性。我們有兩種可能的方法：分析或數據驅動的安全評估。通過分析安全性評估，我們的意思是系統可以被分析來定義可量化的安全性能或基于對危險和情景的嚴格評估的故障率。如果可以通過分析確定整體系統故障率，它可以為哪些方面提供強有力的指導該系統是整體安全的最大貢獻者。一個很好的例子是航天飛機計劃，其初步估計分析失敗率為 100,000 次飛行中的 1 次。然而節目結束后，一項法醫研究表明，早期的航天飛機計劃飛行的失敗率接近十分之一，到節目結束時，這只會發展到百分之一。令人驚奇的是，這種分析甚至可以用于這樣一個復雜的系統，考慮到所有進入航天飛機發射的數千個子系統，以及所有可能影響這些系統運行的數百萬個變量。這種詳細的分析也適用于自動駕駛汽車，但可能會更復雜，因為車輛的無限多種情況將自己局限在其中。最后，分析方法只能為自動駕駛系統的安全性能提供指導，他們的結果需要通過經驗來驗證。為了評估經驗，我們使用數據驅動測試。這是我們確信的概念該系統是安全的，因為它已經證明，使用特定版本的軟件，它可以在一組上達到預期的故障率包含在運營設計領域的道路和場景。在自駕的情況下，這些期望的故障率可以與人類水平的駕駛表現聯系起來，我們希望將事故減少 10 倍或 100 倍于當今駕駛員的表現。

那么，數據說明了什么？自動駕駛汽車真的更安全嗎？首先，按照人類的標準，知道駕駛仍然是危險的。2015 年的一份報告得出的結論是，在所有駕駛致死事故中，其中大約 90% 是由于人為錯誤造成的，有時由于缺乏判斷力，有時是由于人類感知的失敗，等等。但人類也非常擅長駕駛，事實上，整個駕駛環境都經過精心設計基于人類的感知和計劃能力。在美國，每行駛 1.46 億公里，就有大約 1 人死亡。每行駛 210 萬公里就有 1 人受傷，大約每 400,000 公里發生一次碰撞。最后一個數字只是估計的，因為實際上沒有報告大多數較小的碰撞。事實上，自動駕駛可能對更多地了解這些統計數據綜合報告和重建將可以使用我們可用的其他傳感器。

?現在，讓我們考慮初步的自動駕駛車輛統計數據，更具體地說，脫離率由在加利福尼亞測試的所有自動駕駛車輛發布。脫離是當這個自治軟件請求駕駛員接管控制或安全駕駛員覺得有必要進行干預。獲得真正的崩潰統計數據是可以理解的具有挑戰性的整個車隊都在接受測試，因為這些都是敏感的統計數據。幸運的是，加州的測試伴隨著一些有用的報告要求。2017 年，Waymo 在加州行駛了 56.3 萬公里，經歷了 63 次脫離接觸每 9,000 公里大約有一次脫離接觸。GM Cruise 在加州行駛了 210,000 公里大約每 2,000 公里有 105 次脫離接觸。兩者都在全年迅速改善，達到每 12,500 公里一次的脫離接觸率，每年最后三個月分別為每 8,300 公里。這些是很難與人類表現相關的數字，但大致意味著一個典型的通勤者只需要對于自治系統的失敗，每年進行一次干預。這是巨大的進步，但距離人類每年在數萬億英里內實現的碰撞之間的距離為 400,000 公里。按頻率順序排列 63 次 Waymo 脫離的主要原因，是不需要的車輛操縱，感知差異，硬件問題，軟件問題，行為預測，最后是一個魯莽的道路使用者的案例。很明顯，感知的核心任務，預測和行為規劃仍然是具有挑戰性的問題，還有很多工作要做。

最后，關于統計意義。 從今天的艦隊觀察到的表現令人印象深刻， 但它們在多大程度上代表了與人類能力的準確比較？ 我們真的需要開車到多少英里 證明自動駕駛汽車比人類駕駛員更安全， 特別是在死亡人數方面？ 在補充材料中， 我們已經包含了指向報告的鏈接 蘭德公司試圖解決這個問題， 數字令人吃驚。 由于死亡事件是如此罕見，而且考慮到的因素很多， 報告指出，如果 純粹的道路測試用于驗證自動駕駛系統的安全案例。 一個由 100 輛汽車組成的車隊 24/7 行駛至少需要 400 年， 等待的時間很長。

?正是出于這個原因，我們看到了如此多方面的安全方法，每家公司都在擴大車隊增加在道路上使用自主系統獲得的經驗。總而言之，在這個視頻中，我們研究了自動駕駛安全評估的兩個行業觀點，Waymo 和 GM，發現了很多借鑒其他行業的方法。我們討論了當前的離職率和道路測試要求證明比人類表現更好。

Lesson 2 Supplementary Reading: Industry Methods for Safety Assurance and Testing

Supplementary Reading: Industry Methods for Safety Assurance and Testing

Read more about how companies approach safety assurance and testing:

• Waymo Safety Report

• GM Safety Report, 2018

• Ford Safety Report, 2018

• Uber Safety Report, 2018

• NHTSA Crash Statistics, 2015

• Autonomoose: Towards All Weather Driving in Canada, Steven’s presentation, University of Toronto & University of Waterloo (June 15, 2018).

2018_06 Autonomoose Driving in Canada.pdf

PDF File

• How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability?; Rand Corporation Report, 2016

Lesson 3: Safety Frameworks for Self-Driving

歡迎收看本周的最終視頻。在本視頻中，我們將討論一些流行的安全框架，其中一些我們在上一課中遇到過。更具體地說，我們將描述一些通用的，分析框架，包括故障樹，失效模式和影響分析或 FMEA，危害和可操作性分析或 HAZOP。然后我們將重點放在汽車和自主安全框架并討論功能安全或 FUSA，和預期功能的安全性，或 SOTIF。

?我們稍后會在視頻中定義這些術語。讓我們開始。我們將從故障樹分析開始。故障樹可以作為初步的分析框架，并且可以穩步擴展以包含盡可能多的必要細節。故障樹是自上而下的流，我們在其中分析要避免的系統可能出現的故障，然后確定它可以使用的所有方法發生在系統較低級別的事件和故障中。故障樹中的頂部節點是根或頂部事件。故障樹中的中間節點是邏輯門，定義了根本事件的可能原因。分解繼續到詳細程度可以定義此類事件的概率。然后可以通過組合來分析故障樹使用布爾邏輯定律的概率。評估總體概率根本原因事件和最有助于其發生的原因。讓我們考慮一個簡單的例子，并將車禍作為我們的根本事件。車禍的原因可能會被分解無論是軟件故障還是硬件故障，在我們提供的許多其他可能性中在我們之前的視頻中被描述為危險等級。非常粗略地說，硬件故障可能是因為例如，制造缺陷或材料缺陷。同樣，軟件錯誤可能是由感知代碼故障或某些網絡安全問題，比如說，如果我們被黑了。從那里，我們可以繼續進行軟件子系統和這些子系統中的特定計算在每個連續的分支處加深樹。

?最終，我們將得出我們可以達到的特定故障率分配每小時或每英里運行的發生概率。我們現在已經到達故障樹的葉子節點。然后使用邏輯門結構，我們可以顯式計算給出了對單個葉節點故障率的評估的總體故障率。用于向上傳播這些概率的操作將與事件遵循集合論時的概率規則相同。因此，例如，對于獨立事件，OR 和 AND 概率將是子節點概率的總和或乘積。這是故障樹背后的一般思想，被稱為概率故障樹，當概率包含在葉節點時。概率故障樹是一種自上而下的安全方法已廣泛應用于核工業和航空航天工業，并且可以類似地應用于自動駕駛。挑戰在于建立一個綜合樹和錯誤地識別葉節點事件的概率。

現在讓我們看看 FMEA，代表失效模式和影響分析。鑒于故障樹從系統故障流向其所有可能的原因，FMEA 是一個自下而上的過程，它著眼于個人原因并確定所有可能發生的影響。通常，FTA 和 FMEA 一起用于評估安全關鍵系統。失效模式是模式或方式，其中整個系統的特定組件可能導致系統發生故障。效果分析是指分析所有這些模式故障可能導致的可能影響。通常，效果分析旨在確定那些導致最嚴重故障的模式，然后可以導致改進的設計增加更多的冗余或更高的系統可靠性。 讓我們來看看 FMEA 背后的大想法。目標是按優先級對故障模式進行分類。 所以，我們會問這樣的問題，后果有多嚴重，這些故障發生的頻率有多高，檢測這些故障有多容易？然后我們使用優先級值量化所有失敗，然后我們首先開始處理具有最高優先級的故障。

?以下是步驟。目標是構建所有可能的危險情況的表格，我們開始，首先與現場專家討論在表中我們想要的詳細程度識別流程。然后，我們質疑系統的目的并列出所有失敗的可能性。那么對于每一個失敗的可能性，我們確定可能的后果并分配每個后果的嚴重性等級在 1 到 10 之間，10 是最嚴重的。對于每個后果，我們確定可能的根本原因，對于每個路徑原因，我們在 1 到 10 之間分配另一個數字，表示此原因發生的頻率。然后，我們確定了操作員可以檢測到故障模式的所有方式，維護、檢查或故障檢測系統。我們之前評估了整體模式檢測的可能性它會產生效果并從 1-10 分配另一個分數，1個保證被檢測到，10個不能被檢測到。最后，我們計算一個稱為風險優先級的最終數字，這是嚴重程度的產物，發生和檢測。這個值越高，優先級越高。

最終，我們通過修改來解決最有問題的故障模式我們實施該系統，直到我們將風險降低到可接受的水平。也可以執行 FMEA故障樹分析中的實際故障概率，并根據以下方面定義可接受的風險水平在固定的運營期間發生關鍵事件的可能性。該方法不僅改變了完成整個分析的數量和復雜性。 讓我們堅持簡單的評分方法，讓FMEA 過程通過一個簡短的例子更加具體。考慮車輛行駛的特定故障由于道路建設而出現在其測試區域的礫石斑塊上，從而導致控制器不穩定。最壞的情況可能是物理崩潰，這將是嚴重程度 10。它還可能導致駕駛員不適，或有驚無險，但這些將是較低嚴重性的事件。此事件可能會在城市環境中定期發生任何特定類型的構造發生的地方。所以，有點可能。假設我們能夠評估出現次數為四。同樣，我們可以將當前分數分配給其他效果。讓我們假設這個問題目前無法檢測到，因為路面紋理不活躍在我們的自治軟件運行期間進行監控。因此，所有這些影響的可檢測性都排在第 10 位。那么，崩潰的風險優先級數將是 10 乘以 4 乘以 10，即 400。 同樣，我們也可以有其他故障模式。比方說，優先級數為 100 的符號感知失敗，優先級數為 300 的 GPS 同步失敗，也可能是優先級為 150 的車輛運動預測失敗。因此，我們將著手解決這些失敗通過專注于在礫石上行駛而不是 GPS 故障來實施，比運動預測，最后是符號感知。

?這就是 FMEA 背后的一般框架。FMEA 是一種風險評估理念，由軍事和航空航天工業，后來又帶到了汽車工業。它提供了一種真正結構化的方法來量化風險并進行處理。先說最重要的。最后，經常出現的 FMEA 的一個常見變體，是危害和可操作性研究或 HAZOP。與 FMEA 相比，HAZOP 更像是一個定性過程，我們尋求定量地定義風險。因此，在 HAZOP 中，主要目的是有效地對可能出現的一系列危險進行集思廣益。對于復雜的過程，可以評估風險無需為發生分配特定值，嚴重性和檢測，這可能很難做到。HAZOP 通常在設計過程的早期用于指導概念設計階段。HAZOP 中的關鍵補充是，引導詞用于引導應用于每個系統要求的頭腦風暴。這些引導詞包括諸如不、更多、更少、早期、晚期并導致可能不考慮的故障模式。因此，可以將 HAZOP 視為一種簡化的持續 FMEA 頭腦風暴方法。

?現在讓我們關注更具體的安全類型并討論用于汽車和低級自主功能開發的現有安全框架，這通常用于評估自動駕駛汽車的硬件和軟件故障。特別是，讓我們討論功能安全方法在 ISO 26262 中描述和安全在 ISO 上延伸到的預期功能方法26262 并在 ISOPAR 21448.1 中定義。我們將無法詳細介紹這兩個過程，但如果您想了解更多信息，我已經包含了補充材料的鏈接。功能安全或 FUSA，是不存在不合理的風險由汽車硬件和軟件故障引起的故障行為，或與其預期設計相關的意外行為。ISO 262 標準定義了功能安全術語和機動車輛內電氣和電子系統的活動。因此，僅解決硬件和軟件危害這可能會影響自動駕駛汽車的安全。該標準定義了四個汽車安全完整性等級或 ASIL。ASIL D 是最嚴格的，A 是最不嚴格的。每個級別都有與之相關的特定開發要求，必須遵守才能獲得認證。

功能安全流程遵循 V 型流程。從左上角的需求規范開始，然后進行分析危害和風險并著手實施功能。然后我們爬上正確的分支以確認設計目標已經實現。我們從低級驗證開始，例如軟件單元測試，然后通過仿真進行子系統和全系統驗證，測試軌道、操作和道路測試。當我們沿著左邊的V下降時，高層次的需求變成低層次的實現。當我們爬上右邊的 V 形時，我們在之前確認每個低級函數實現將它們結合起來以確認安全操作的系統要求。最后一步是總結功能安全評估，評估剩余風險和確定我們的系統是否已達到可接受的安全水平。在功能安全 V 開始時，我們使用 HARA 或危害和風險評估。在HARA，我們識別和分類危險事件，并規定避免不合理風險的要求。這個過程推動了所有系統的開發和測試。為此，我們首先確定可能的硬件和軟件可能影響汽車安全的故障或故以及意外功能。這是使用 FMEA 或 HAZOP 的地方功能安全框架，并導致我們系統的一系列特定危害。然后，我們定義了一系列場景或情況，系統必須在我們的 ODD 上繪圖才能創建此列表。接下來，我們將危險和情況組合成危險事件，描述預期的損害，并確定風險參數，計算數值每種情況和危險組合的潛在風險。風險評估后，我們選擇風險最高的情景。每個可能的故障可能發生的最壞情況事件。最后，我們根據這些最壞的情況定義我們的安全要求。HARA 流程為系統設定設計目標一種了解所有可能發生的最壞情況故障的方法。通過驗證確認這些最壞情況下的故障僅以合理的風險進行處理。這就是功能安全背后的主要思想。您專注于最壞情況的需求，然后實施至少可以處理這些最壞情況要求的硬件和軟件。

?最后，讓我們簡要探討一下預期功能標準或 SOTIF 的安全性，在 ISOPAS 21448 文檔中正式定義。SOTIF 特別關注與相關的故障原因系統性能限制和可預見的系統誤用。由于執行功能的性能限制或不足技術限制，例如傳感器性能限制和噪聲，或算法的限制，例如物體檢測故障和執行器技術的局限性。硬件和軟件故障通過以下方式解決ISO 26262 中的功能安全標準，不在 SOTIF 的范圍內。SOTIF 還解決了由于用戶可預見的誤用而導致的不安全行為。比如用戶混淆，用戶超載和用戶過度自信。當前的 SOTIF 標準針對自動化水平，零，一和二。它還指出，它的方法可以應用于第三級，四個和五個自治，但可能需要額外的措施。SOTIF 可以看作是功能安全流程的延伸，專為應對自動駕駛功能的挑戰而設計。因此，它遵循非常相同的V型發展理念，但有增強的組件。SOTIF 還使用 HARA 來識別性能限制和誤用引起的危險。然后執行類似的設計序列，單元測試和驗證和確認，確認已滿足安全要求。如果您想深入了解功能安全或 SOTIF 標準，請查看補充材料中的鏈接。

?讓我們總結一下我們在這個視頻中學到的東西。我們首先討論了通用安全框架。故障樹分析作為一種自上而下的方法安全評估和故障模式和效果分析作為一種自下而上的安全方法。然后我們討論了常用的功能安全的概念。軟件和硬件風險評估和討論了 SOTIF 作為功能安全的擴展，這說明了性能限制和誤用。所有這些想法在行業中被大量使用，正如我們在 Waymo 和 GM 中看到的那樣幾乎所有這些技術都在他們的安全評估中。

?恭喜。你已經完成了這個安全評估模塊。讓我們總結一下我們這周學到的東西。我們首先討論了為什么安全很重要，特別是如何廣泛的不同故障可能導致自動駕駛事故。然后我們正式定義安全概念并討論NHTASA 對自動駕駛汽車的安全建議。然后我們討論了 Waymo 和通用汽車如何看待自動駕駛安全。然后，我們描述了展示安全性的分析和數據驅動方法。最后，在今天的視頻中，我們討論了共同的安全評估框架。包括故障樹、故障模式和影響分析，功能安全和預期功能的安全性。

?希望本周能讓你深入了解設計安全的自動駕駛系統并正確評估您構建的系統。在我們結束這周之前，我們將與滑鐵盧大學的 Krzysztof Czarnecki 教授，自主安全評估專家。我有很多有趣的問題要問。敬請關注。

第三課補充閱讀：自動駕駛的安全框架

補充閱讀：自動駕駛的安全框架

查看以下有關自動駕駛汽車安全框架的鏈接：

• 失效模式和影響分析 - asq.org

• ISO 26262-1:2018 - 道路車輛的功能安全

• ISO/PAS 21448 - 道路車輛預期功能的安全性

證明自動駕駛汽車的可靠性需要行駛多少英里？

蘭德公司關于安全駕駛的報告

總結

以上是生活随笔為你收集整理的Self-Driving Cars 专项课程-Safety for Self-Driving Cars的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。