一般來說軟體測試常常隻是尋找bug，而不是通過精密的實驗來保證産品品質。一個相比簡單的系統級的測試，即測試—失敗—更新檔（改進）—測試更好的方法已經開始大規模部署在無人駕駛汽車上。ISO26262的v模型建立了一個架構，該架構将每種類型的測試與相應的設計或需求文檔聯系起來，但該模式在處理自動駕駛汽車面臨的各種新測試問題時會遇到挑戰。本文根據自主車輛的V模型确定了測試中的五個主要挑戰領域:駕駛員不在環、複雜需求、非确定性算法、歸納學習算法和故障作業系統。
有希望在這些不同的挑戰領域中實作的通用解決方案包括:使用逐漸減少限制的操作場景進行分階段部署，使用觀測器/執行器架構把複雜的自動駕駛功能從相對簡單的安全功能分離出來，采用故障注入來執行更多的的邊緣案例測試。盡管為高等級的自動駕駛算法提供安全認證安全仍然存在重大的挑戰，但似乎可以采用現有的軟體安全方法來建構系統和與其相對應的設計過程。
自動駕駛汽車已然成為一個熱門話題，不過實際上它們背後的技術已經發展了幾十年了，最早可追溯到自動化公路系統項目。從這些早期的示範算起，自動駕駛技術已經發展了成熟的駕駛員輔助系統(ADAS)。像自動車道保持和智能巡航控制也已經是許多車輛的标準了。除此之外，現在還有許多處于不同的發展階段的不同級别的自動駕駛車輛項目。
如果有人相信所謂專家的話，那麼無人駕駛汽車好像呼之欲出。但事實上，搞傳統汽車行業的都知道，在擁有專業的安全駕駛人員的情況下，制造幾輛車以在合理且有利的條件下運作，與在不受限制的世界裡運作數百萬輛車之間，有着巨大的鴻溝。
有人會說，（自動駕駛汽車）成功的示範和幾千公裡(甚至幾十萬公裡)的成功駕駛裡程意味着自動駕駛技術基本上已經做好全面部署的準備。但是，很難僅僅從這樣的測試就能得出這足以確定安全性的結論。實際上，至少有一些開發人員已經在做更多相關的測試工作，但問題是還需要做多少工作，以及我們如何才能知道現在的車輛已經足夠安全到可以上路了呢？
在本文中，我們将探讨一些正在等待開發人員解決的挑戰，這些開發人員正試圖開發完全自主的L4級别車輛并進行大規模部署。是以，我們跳過了過去可能采用的半自動化方法，即在這種情形下，司機根本不用負責操作車輛。對研究對象我們進行了進一步限制了範圍，隻考慮在ISO26262v架構内設計和驗證的車輛。采取這種限制的原因是這是一種可接受的確定安全的架構。
完全基于計算機的系統應該是不安全的，這是一個可以确認的，除非你有令人信服的相反論點來論證。總之，自動駕駛汽車不能被認為是安全的，除非它們能被顯示符合或可以被映射到ISO26262或其他一些合适的、被廣泛接受的軟體安全标準。
完全測試的不可行性
人們早就知道不可能徹底地測試系統以確定系統的可靠性（備援）。例如，假設有一個100萬輛汽車的車隊每天運作一個小時。如果安全目标是這個車隊每1000天發生一次災難性的計算故障，即每次發生災難性故障之間的平均時間應該為10億小時，這與飛機的允許故障率相當。
為了驗證發生災難性事故的頻率，最少得進行長達十億小時的測試，更有甚者也可能是幾倍的時間，重複多次測試可以達到統計學意義。但即使這樣，這也是假定測試環境是基于真實世界部署的，具有高度代表性的并且導緻錯誤的環境部署以随機的、獨立的方式出現。
但是，建造一個足夠大的、能夠在具有代表性的測試環境中運作數十億小時而又不會危及公衆的車隊是不切實際的。是以，我們需要替代的驗證方法，可能包括模拟仿真、故障注入、面向不斷增加的車隊規模的自适應、在非極端工況中獲得元件的實際工作狀況以及人工評審等方法。（元件級的測試也發揮了作用，但是為實體硬體裝置積累十億小時的部署前測試仍然是不切實際的)
考慮到自主系統的測試比日常軟體系統的測試更困難，這會讓事情會變得更糟。
對于相對非關鍵的計算系統來說，可以将測試作為确認其安全級别的主要依據。這是因為低嚴重程度和低暴露性的故障相比災難性故障更容易發生。例如，如果每1000小時發生一次特定類型的故障是可以接受的(因為這種故障會導緻最低成本的事故或輕微的中斷)，那麼通過數千小時的測試，就可以可靠地驗證該故障的故障率。這并不是說對這些系統而言，所有的（必要）保證軟體品質的步驟可以放着不管了，而是一個合适的測試和故障監控政策可能能夠驗證一個事實，即如果平均故障間隔時間要求相對寬松的話，一個品質合适的元件确實已經被确認為擁有一個可以接受的低故障率。
作為起點的V模型
因為系統級測試不能完成上述工作，我們需要更多相關測試，這正是建立更健壯的安全軟體的開發架構的意義所在。V軟體開發模型長期以來一直适用于汽車。它是20多年前納入MISRA指導方針的發展參考模型之一。最近，它被推廣為構成ISO26262基礎的參考模型。
通常，V模型表示一個有條理的建立過程和驗證過程。V的左側包括從需求到設計再到實作的過程。在每個步驟中，系統被劃分為并行處理的典型的子系統（例如，有一組系統需求，但是每個子系統都有單獨的設計)。V的右側疊代地驗證和驗證越來越大的系統，它是從小的元件過渡到到系統級的評估的一個過程。雖然ISO2626262對這個模型進行了詳細的闡述，但是我們這裡保留一些通用的架構，以友善讨論拓展。
盡管ISO 26262和它的V架構已經明朗了在確定汽車安全方面的公認做法，但在将全自動車輛的技術映射到V方法這方面依然有很多挑戰。
駕駛員不在環
在全自動駕駛汽車中，最明顯的挑戰可能就是司機不再真正駕駛汽車。這意味着，根據定義，不能再指望司機在運作過程中為車輛提供控制輸入。
可控性挑戰
對于低完整性裝置來說，典型的汽車安全可能取決于駕駛員的控制能力。例如，在一個進階驅動輔助系統(ADAS)中，如果一個軟體故障導緻一個潛在的危險情況，司機可能會被期望越過軟體功能直接将車輛恢複到安全狀态。司機有時候也被希望能把汽車從嚴重的機械故障中恢複過來，比如輪胎爆裂等問題。換句話說，在人類駕駛的汽車中，司機會負責采取正确的糾正措施。但在現在這種情況下，司機沒有能力采取糾正措施，也就是說車輛缺乏可控性，是以必須設計更高的汽車安全完整性水準，或汽車安全完整性等級。
一款完全自動化駕駛的汽車不指望司機處理特殊情況。當故障發生時和出現超出指定的操作條件能處理的情況時，計算機系統必須被指定為故障的處理者。與ADAS系統相比，讓計算機負責異常處理會顯著增加自動化的複雜性。組合的ADAS系統技術如車道保持和智能巡航控制，似乎非常接近全自動操作，然而，完全自動駕駛的車輛必須處理所有可能出現的問題，它具有更高的複雜性。因為，現在确實已經沒有接管方向盤和踩刹車的司機了。
自主架構方法
在ISO2626262環境下的自主體系結構方法中，讓計算機負責管理需要以下兩種評估風險的政策之一。
一種政策是将風險評估的可控性部分設定為C3，即難以控制或無法控制。如果嚴重程度和暴露度很低，這可能是一個可行的選擇。但是，在嚴重程度中等或高的情況下，系統必須設計成更高的汽車安全完整性水準(汽車安全完整性等級)。(有人可能會認為應該有更高的可控性分類C4，因為自動化系統有可能采取主動的危險行動，而不是簡單地不能提供安全功能。)但我們假設現有的C3就足夠了。
另一種處理潛在的汽車高安全完整性等級自主功能的方法是使用分解，具體方法要接着觀測器/執行器架構和備援的組合。觀測/執行器架構是指主要功能為：一個子產品(執行器)負責執行，而另一個子產品(螢幕)執行驗收測試或其他行為驗證。如果執行器行為不當，觀測器會關閉整個功能(兩個子產品)，進而形成一個故障靜默系統。
如果觀測器/執行器對(圖2)設計正确，那麼隻要觀測器有足夠高的汽車安全完整性等級并檢測所有可能的故障，執行器就可以設計成低汽車安全完整性等級。(還要求檢測觀測器中的潛在故障，以避免損壞的觀測器未能檢測到驅動器故障的問題。)如果可以使觀測器比執行器簡單得多，則可以減少觀測器的規模，并允許将大部分複雜功能放置到較低的汽車安全完整性等級執行器中，這種體系結構模式是相當有利。
觀測器/執行器對的優點和缺點都是它建立了一個故障靜默建構塊(如果有錯誤，它就會關閉)。異構備援的使用，即觀測器和執行器的使用是為了防止由于執行器故障而發出危險的指令。
至少，提供故障操作行為需要更多的備援(即多個觀測/執行器對)，并且需要滿足多樣性，進而使同一模式的軟體設計故障不會造成整個系統故障。這對于避免出現Arianne5航班501的丢失這樣的情況是很重要的，這是由于主系統和備份系統都出現了相同的未處理異常操作條件而導緻的故障。
應該指出的是，因為例如實作不同的元件時有脆弱性等問題，實作多樣性并不一定是簡單的，對于非自主軟體也是如此。還需要注意的是，故障/執行器對的故障沉默需求是基于故障獨立性的假設。
一個關鍵的點是無論采用什麼方法，總需要有一種方法來檢測當自主功能不正常工作的狀态(無論是由于硬體故障、軟體故障，還是需求缺陷)，并以某種方式把系統轉移到一個安全的狀态。
複雜的需求
V開發模型的一個基本特征是，V的右側提供了一種可追溯的方式來檢查左側的結果(驗證和驗證)。但是，這種檢查的概念是基于一個假設，即需求實際上是已知的，正确的、完整的、明确指定的。這種假設給自動駕駛汽車帶來了挑戰。
需求挑戰
如前所述，從控制系統中去掉司機意味着軟體必須能處理異常，包括天氣、環境危害和裝置故障。會有很多不同類型的故障，從惡劣天氣(洪水、霧、雪、煙，龍卷風)，違反交通規則(錯誤的方向公路上一個汽車，其他司機闖紅燈，被偷走的交通标志),到當地駕駛約定（靠左行駛），動物危害(蝗災、鹿、犰狳)。
任何一個開了足夠長時間車的人，都會有自己的故事，他們會講述他們在路上看到過的怪異事件。總的來說，車輛數目多的話很可能會經曆所有這類事件，甚至更多。更糟糕的是，惡性事件和駕駛條件的組合可能會出現，而在經典的書面需求規範中，這些組合實在是太多了。如果這些組合的結果可能是無害的，那麼可能不需要涵蓋所有這種極其罕見的組合，但是需求應該清楚地知道什麼是系統設計範圍内的要處理的故障，什麼不是。是以，以列舉所有系統需求的文檔為起點的經典V程序似乎不太可能以狹義的方式擴充到自動車輛異常處理系統上，至少在不久的将來會一直是這樣。
操作概念的方法
管理需求的複雜性的一種方法是限制操作概念并進行需求的分階段擴充。這已經由開發人員完成了，他們可能會在特定的地理區域集中進行道路測試（例如，僅在矽谷的高速公路上進行白天的駕駛，因為那裡的降水有限，天氣寒冷)。采用限制概念的想法可以從多個次元擴充，典型的可以利用限制操作概念軸（次元）包括:
道路可達:限制到達的高速公路，共乘車道，農村道路、郊區，封閉校園，城市街道，等；
可見性:白天，晚上，霧，霾、吸煙，雨，雪；
車載環境:在一個封閉的車庫内沒有其他車輛移動，僅允許自動駕駛的車道，非自動駕駛車輛上的标記應答器等；
外部環境:基礎設施的支援，預先規劃的道路，由人駕駛的汽車；
速度:較低的速度可能産生更小的故障後果和更大的恢複空間。
雖然上述自由度仍然有很多組合(當然還有更多的組合是不可想象的)，但是從可能的操作概念中進行選擇的目的不是增加複雜性，而是減少複雜性。減少需求的複雜性可以通過在特定的情況下應用自主系統來實作，在這些情況下的需求應該是完全被了解的(并確定對這些有效的操作條件的識别是正确的)。
是以，限制操作概念成為一種引導政策，用于在逐漸複雜的操作中部署更複雜的技術能力。一旦确定對某一特定業務概念的需求有了充分的了解，就會有更多類似的需求。随着時間的推移，可以添加操作概念來擴充允許的自動化場景的範圍。但這并不能完全消除複雜需求的問題，但是它可以幫助減輕組合爆炸的需求和例外情況。
安全需求和限制條件
即使使用了受限的操作概念，使用傳統的與安全相關的需求方法似乎也是不切實際的。這種方法或多或少是按以下這種方式進行的：首先建立功能需求。在執行了一些風險評估過程後，對安全性相關的需求進行評注(annotation)。将這些與安全相關的需求配置設定給安全關鍵子系統。設計安全關鍵子系統以滿足配置設定的需求。最後，通過重複循環來找到并減少不在預期内的緊急子系統表現。
對安全關鍵需求進行評注對于自主應用程式來說可能不切實際，這裡至少有兩個原因。
一個原因是，許多需求可能隻與部分安全相關，并且與功能性能密不可分。例如，當汽車行駛時，使用停車制動的許多條件可能是一組初始(基礎)需求。然而這些需求的某些方面實際上是安全的關鍵，而這些方面在很大程度上是受其他互動功能的緊急影響。考慮停車制動的情況，停車制動很可能被許多功能需求所描述。但是讓我們來簡化問題，在減速模式中唯一安全的關鍵操作可能是在其他需求的緊急互動下必須避免在減速過程中鎖住車輪。
用于識别安全相關需求的需求注釋可能失敗的第二個原因是，在使用機器學習技術時是不可能進行評注的。這是因為需求采用了一組訓練資料的形式，這些資料列舉了一組輸入值和正确的系統輸出。這些通常不是傳統需求的形式，是以需要對需求管理和驗證采用不同的方法。
與其試圖在安全性和非安全性子系統之間配置設定功能需求，不如建立一組嚴格與安全性相關的獨立的、并行的需求集。這些需求的形式往往是限制條件，它們指定了安全所需的系統狀态。這種方法可以解決性能和優化問題(最短路徑是什麼?或者最優燃料消耗的速度是多少?)從安全的角度來看(我們會撞上什麼東西嗎?)
使用這種方法可以将需求集劃分為V模型的兩個部分。第一組的需求将是一組非安全相關的功能需求，這可能是傳統的格式或一種非傳統的格式如機器學習訓練集。
第二組需求将是一組純粹的安全需求，它們完全明确地定義了安全對于系統的意義，相對獨立于最優系統行為的細節。這種需求可以采取安全操作信封的形式，适用于不同的操作模式，系統可以自由地在操作信封内優化其性能。顯然，這樣的信封至少可以在某些情況下使用(例如，執行速度限制或設定最小的跟随距離。這個概念是相當籠統的，但也說明這可能是未來的工作。
采用一組與功能需求正交的安全需求的一個令人信服的理由是，這種方法可以清晰地映射到觀測/執行器體系結構上。功能需求可以配置設定給低汽車安全完整性等級執行器功能塊，而安全需求可以配置設定給高汽車安全完整性等級螢幕。這個想法作為螢幕/執行器設計模式的一部分已經被非正式地使用多年了。我們建議将這種方法提升為一種主要的政策，用于設計自動車輛的設計、需求和安全案例，而不是降級為一種詳細的實作備援政策。
非确定性和統計算法
自動駕駛車輛使用的一些技術本質上是統計的。一般來說，它們往往是不确定的(不可重複的)，并且可能隻在一個機率可以被配置設定的情況下給出基于機率正确的答案。驗證這樣的系統會帶來一些挑戰，這些挑戰通常不會出現在更确定的、傳統的汽車控制系統中。
随機系統的挑戰
随機系統非确定性計算的挑戰包括一些算法，如規劃算法，它們可能通過對許多随機選擇的候選者的結果進行排名來工作。由于該算法的核心操作是基于随機生成，是以很難進行複制。雖然在單元測試中使用可重複的僞随機數流等技術可能有幫助，但是在內建系統中建立完全确定的行為可能是不現實的，尤其是當初始條件的微小變化導緻系統行為的發散狀态時。這意味着，盡管嘗試使用名義上相同的測試用例，但每一輛車測試都可能導緻不同的結果。
成功的感覺算法也往往是機率的。例如，證據網格架構(evidence grid framework)将來自單個、不确定的傳感器讀數的擴散累積，使得機器人對周圍環境越來越能建立一個更加詳細的地圖。這種方法産生一個對象存在的可能性，但是時候不能完全保證的。此外，這些算法基于先前的傳感器實體模型(如多路徑傳回)和噪聲模型本身就是機率性的，對環境條件的微小變化敏感。
除了對環境的幾何模組化之外，其他算法還從感覺到的資料中提取标簽。其中突出的例子包括行人檢測。這樣的系統即使在無噪聲資料的情況下，也可能出現潛在的不可預測的故障模式。例如，視覺系統可能難以消除由于陰影而産生的顔色變化，而且在大型反射表面的存在中，視覺系統很難确定物體的位置。(公平地說，這些對人類來說都是挑戰。)此外，任何分類過程都顯示了假陰性和假陽性之間的權衡，其中一個的數量越少，另一個的數量就越多。測試的含義是這樣的算法不會在百分之百的時間内有效，而且根據構造的不同，它們可能會報告一個特定的情況是真實的，而這個情況實際是真實的可能性隻是中等。
測試中的非決定論
處理測試中的非決定論很困難至少有兩個原因。
第一個是很難實施特定的邊緣情況。這是因為，隻有當系統接收到來自世界的非常特定的輸入序列時，系統才可能以激活邊緣情況的方式運作。由于前面讨論過的一些因素，例如計時器對輸入的微小變化的響應可能存在顯著差異，是以很難設計出一種情況，在這種情況下，環境可靠地提供适當的條件來運作特定所需的測試用例。作為一個簡單的例子，車輛可能更喜歡在寬闊的道路上行駛更迂回的路線，而不是在一條狹窄的巷子裡走捷徑。為了評估在狹窄的巷道中導航的性能，測試人員需要設計一種使寬闊的巷道對計劃者沒有吸引力的情況。但是，這樣做需要對測試計劃給予額外的成本，并且可能(手動地)将車輛移動到它通常不會進入的情況以強制執行所需的響應。
測試中不确定性的第二個困難是很難評估測試結果是否正确，因為對于一個給定的測試用例來說，沒有唯一的正确系統行為。是以，正确性标準可能必須采用與前面讨論的安全信封類似的形式，如果最終系統狀态在可接受的測試通行信封内，則測試通過。一般情況下可能需要多個測試來建立信任。
機率系統行為對驗證提出了類似的挑戰，因為通過一次測試并不意味着每次都能通過測試。事實上，有了機率行為我們可能會認為至少某些類型的測試會在一定程度上失敗。是以，測試可能不是為了确定行為是否正确，而是為了驗證行為的統計特征是否被精确地指定(例如，假陰性檢出率不大于相關安全參數中假定的檢出率)。比起簡單的功能驗證，這可能需要更多的測試，特别是如果問題中的行為是關鍵的安全部分且在預期中會有極低的失敗率。
從機率系統中獲得極高的性能可能需要多個子系統在發生完全獨立的故障時有低的失敗率。例如，可以将複合雷達和視覺系統結合起來，以確定在極低的機率範圍内沒有遺漏的障礙物。這種方法不僅适用于傳感模式，而且也适用于規劃和執行中的其他各種算法方案。如果這樣的方法是成功的，那麼很有可能失敗的機率非常低，以至于測試驗證複合性能幾乎是不可行的。例如，如果兩個系統必須每十億次檢測就會遺漏一次障礙，那麼必須運作數十億次有代表性的測試來驗證這種性能。為了驗證複合不同算法的低故障率，可以嘗試分别驗證每種算法更頻繁的允許故障率。但這是不夠的。我們還必須驗證失敗之間獨立的假設，這很可能必須基于分析和測試才能進行。
機器學習系統
隻有在正确地做出一系列複雜的感覺和控制決策的情況下，自動駕駛汽車才有可能采取正确的行為。要實作這一目标，通常需要對參數進行适當的調整，包括從每個相機鏡頭的校準模型，到為避免高速公路上的障礙而轉向或停車的風險的适當權重。這裡的挑戰是找到校準模型或權重的比值，進而使某些誤差函數最小化。近年來，大多數機器人應用都轉向機器學習來實作這一點，因為多元優化的複雜性使得手工工作不太可能産生理想的性能水準。
機器學習方法的細節有很多，例如，有監督學習、強化學習等，但總之所有這些方法都涉及歸納學習，在歸納學習中，訓練集被用來推導一個模型。
例如，考慮在單目圖像中檢測行人的情況。使用一組大型圖像訓練集，分類器可以學習一種決策規則，該規則将行人在一組單獨的圖像驗證集中被檢測到的機率降至最低。為了我們的目的，一個基本要素是訓練集實際上是系統的需求集合，而規則是系統設計的結果。(機器學習算法本身和分類器算法都比傳統的驗證技術更容易修改。然而，這些都是通用的軟體引擎，最終的系統行為是由用于學習的訓練資料決定的。)
可以嘗試通過建立一組訓練資料的需求來回避訓練集資料形成實際需求的問題。但這最終隻是将同樣的挑戰推到了一個抽象層次上。需求不應是典型V系統本身的一組功能需求，而是以一組訓練資料或收集訓練資料集的計劃的形式。
驗證歸納學習的挑戰
歸納學習方法的性能可以通過從收集的總體資料集中保留一些樣本并使用這些樣本進行驗證來測試。假設有以下這種情況，如果把訓練集作為系統需求(V的左邊)看，可以用一組獨立的驗證資料來確定滿足測試的需求(V的右邊)。訓練資料不能有意外的相關性與所需的行為，否則系統将過拟合。類似地，驗證資料必須獨立于訓練資料，并且在除所需的特性之外的所有方面都與訓練資料不同，否則在驗證過程中會檢測到過拟合。當然目前尚不清楚如何論證機器學習系統沒有産生過拟合。
機器學習在實踐中的一個重要限制是，如果使用帶标簽的資料，每個資料點都可能很昂貴。(建立标簽必須由某人或某物來完成。無監督學習技術也是可能的，但需要一個巧妙的映射來解決特定的問題。此外，如果訓練集有問題或所學習的規則有問題，那麼就需要收集更多的驗證資料并用于驗證更新的系統。這是必要的，因為即使對訓練資料做一個小的更改，也會産生一個完全不同的學習規則集。
由于自主系統的需求非常複雜，很可能會出現一些罕見的邊緣案例，在那裡學習将會發生問題。然而，由于它們的稀缺性，收集描述這種不尋常情況的資料可能是昂貴的，而且很難衡量。(模拟和合成資料可以幫助解決這一問題，但在模拟資料中存在偏差的風險，以及對仿真工件的過度拟合。)
驗證機器學習的另一個問題是，一般來說，人類不能直覺地了解過程。例如，卷積神經網絡的内部結構可能不能讓人類觀察者更直覺地了解已經學會的決策規則。雖然可能有一些特殊的情況，但一般來說，機器學習的易讀性問題即能夠用人類的術語解釋系統的行為這個問題還沒有解決辦法。這使得除了昂貴的蠻力測試之外很難預測的技術如何應用于機器學習系統的驗證。(也許有些組織确實有資源進行廣泛的蠻力測試。但即使在這種情況下，訓練資料的準确性、有效性和代表性也必須被證明為是安全論證的一部分。)
由于機器學習系統的易讀性一般較差，而且由于過度拟合的危險是真實存在的，是以在這樣的系統中存在着嚴重影響安全性的失效模式。特别值得關注的是在訓練集資料中出現的偶然相關性，但人類往往注意不到這種相關性。例如，考慮使用經過訓練的可變形部件模型來檢測圖像中的行人的方法，這在現實世界的資料集中已被證明是相當有效的。如果訓練資料集中沒有(或很少)行人坐輪椅的圖像，那麼這樣的系統很可能會将行人的标簽與用兩條腿走路的人錯誤地聯系起來。
歸納學習的解決方案
歸納學習怎麼進行測試是很困難的。首先是黑天鵝問題，故事是這樣的，在18世紀末之前，在歐洲觀察到的所有的天鵝都是白色的，是以一個使用歸納邏輯的觀察者會得出結論，所有的天鵝都是白色的。然而，這名觀察者在通路澳洲時，會經曆這種信念的挑戰，因為那裡有大量的黑天鵝。換句話說，如果系統沒有看到一個特殊的情況，它就不能學習這個情況。這是對歸納學習方法的一個基本限制。此外，由于機器學習嚴重缺乏易讀性，人類審查員很難或不可能想象在這樣一個系統中出現類似黑天鵝的偏差。
驗證一個歸納學習系統似乎是一個極具挑戰性的問題。我們可能會使用廣泛的測試，但需要保證黑天鵝資料随機獨立到達率的假設，并對相應大小的資料集進行測試。如果有足夠的資源，這可能是可行的，但是總會有新的黑天鵝，是以需要對大量的操作場景和輸入值進行機率評估，以確定系統故障的低水準。
另一種驗證歸納學習系統到高汽車安全完整性等級水準的方法是将一種基于歸納的低汽車安全完整性等級算法配對，該算法将指令發送給執行器，并使用基于高汽車安全完整性等級演繹的螢幕。這将回避驅動算法的大部分驗證問題，因為控制執行器的誘導算法的失敗将被基于演繹生成的安全信封等概念的非感應螢幕捕獲。是以，執行器算法失敗将是一個可用性問題(假定有足夠的故障轉移能力，系統安全關閉)，而不是安全問題。
關鍵任務的操作需求
現在讓我們回到先前讨論過的地方，即計算機最終控制着車輛，而不是控制着人。這意味着至少部分車輛必須是基于故障操作而不是面對故障停止。
故障作業系統設計的挑戰
故障作業系統設計已經在航空航天和其他環境中成功地完成了幾十年，但是由于以下幾個原因仍然是困難的。第一個原因是顯而易見的，即必須提供備援，以便當一個元件失敗時，另一個元件可以接管。實作這一點需要至少兩個獨立的、備援的故障停止行為子系統。
實作故障作業系統反過來需要至少三個備援的故障任意元件，以便在發出不正确的輸出而不是在元件級别發出靜默失敗的情況下确定故障源。對于必須容忍任意錯誤故障的系統，根據相關的故障模型，可能需要一個具有4個備援元件的複雜容錯系統。
備援的結構變化取決于設計方法，和可能包括配置如三備援系統成員(在這種情況下，成員必須確定不被一個單點故障)，或兩個二對二系統，或者使用四台電腦。這些方法除了引入的明顯開銷之外，還存在一個測試問題，即如何確定故障檢測和恢複工作的有效性，確定故障的獨立性，并確定在驅動任務開始時所有備援元件都是無故障的。備援似乎不太可能被避免，但為了確定安全，可能會降低提供足夠備援的複雜性和成本。
在典型的故障作業系統(如飛機)中，所有備援部件本質上都是相同的，它都能夠執行擴充任務。例如，商用飛機通常配置兩個噴氣發動機，每個噴氣發動機至少有一個雙備援計算機控制。如果一台發動機上的兩台計算機由于持續的交叉檢測故障而關閉，那麼就會有第二個獨立的引擎來維持飛機的飛行。即便如此，對引擎可靠性的要求還是非常嚴格的，因為在第一個引擎故障後，飛機可能需要飛行幾個小時才能到達最近的機場。這就對每個引擎提出了顯著的可靠性要求，進而增加了元件成本。
雖然汽車是出了名的價格敏感的，但它們也有一個優勢，即故障轉移任務的時間可以很短(例如，把車停在路邊，或者在必要時停在一條旅遊線路上)，故障轉移任務的持續時間是以秒而不是小時為機關度量的。此外，用于停止車輛的故障轉移任務可能比完全自主操作的功能要少得多。這可以簡化需求複雜性、計算備援、傳感器需求和驗證需求。(作為一個簡單的例子，故障轉移任務控制系統可能不支援變道，這極大地簡化了傳感器需求和控制算法)是以，設計一個具有故障停止主要制器和更簡單的故障操作故障轉移控制器的自動車輛可能在硬體成本和設計/驗證成本方面都具有吸引力。
它也可能不是基于完全的自主系統，而是就是完全的自主系統，在完全的自主系統中有一個檢測器.這将使故障探測器本身擁有高水準，但可能允許正常的自主功能為低汽車安全完整性等級。這種方法可以很好地映射到主自主系統的監視/執行器體系結構。故障轉移的自主性也必須以安全的方式設計，并根據其複雜性和計算的可靠性需求采用适當的體系結構方法。如果僅持續幾秒鐘的短暫故障轉移任務中發生故障的可能性足夠低，那麼甚至可以使用單通道故障轉移系統。
非技術性因素
在部署自動駕駛時遇到的一些挑戰是非技術性的，例如經常提到的責任問題(當發生事故時誰負責賠償?)以及法律通常如何對待所有權、操作、維護和其他方面的車輛的問題。深入研究這個問題顯然超出了本文的範圍。然而，對非技術挑戰的決議很可能對技術解決方案産生影響。例如，對事故重建資料的自主系統可能有法律要求，需要對這些資料的來源進行仔細的分析，以確定正确使用這些資料。舉個簡單的例子，假設雷達探測機率為95%，那麼它的輸出可能仍然會被記錄在系統中，以判斷是否檢測到障礙物，表面上這意味着探測的确定性。
重要的是要確定法分析考慮到，僅僅因為雷達沒有探測到行人，并不意味着行人不在那裡(例如95%檢測可能意味着每20個行人中就有一個不會被檢測到)。
看起來，由于自動車輛的固有複雜性，以及無法通過測試證明完備性，開發人員必須以保證案例的形式建立安全保證參數。這樣的保證論證對于維護和解釋系統的完整性是必要的，并且它能夠可靠地解釋系統對不可避免的危險情況的反應。確定證據的完整性是應該解決的一個特殊問題，因為借此可确定由于發生特殊情況而造成的事故是否是不可避免的。其他需要關注的重要的問題是，事故是否由系統需求的缺陷、合理可預見和可避免的設計缺陷、實施的缺陷或其他原因引起的。
故障注入
從前面的讨論中可以明顯看出，傳統的功能測試在面對一個完整的系統時會遇到困難，尤其是在不尋常的操作條件下，很難去執行異常的組合。雖然測試人員可以定義一些非名義上的測試用例，但由于異常、操作場景和其他相關因素的組合爆炸，該測試的可擴充性存在問題。
此外，研究還表明，即使是非常優秀的設計人員，在相對簡單的軟體系統中，也經常會出現盲點和錯過異常情況。
故障注入和魯棒性測試是在異常情況下評估系統性能的較為成熟的技術，在測試異常情況響應時可以避免設計人員和測試人員的盲點。傳統的故障注入包括将位翻轉插入到記憶體和通信網絡中。最近的技術增加了抽象的層次，包括基于資料類型的故障字典，并確定了故障的代表性。這些技術已經被成功地用于自動駕駛汽車的缺陷的發現和特征。
這是一種很有希望幫助驗證自主性的方法，它在元件的抽象級别執行故障注入，作為試圖僞造安全性聲明的政策的一部分。這不僅涉及到對主要傳感器輸入的對象進行模拟，還涉及到插入異常條件以測試系統的健壯性(例如，在映射中插入無效資料)。執行此類故障注入的目的不是驗證功能，而是通過探查不可預見的情況激活弱點。這種故障注入也可以ISO 26262過程中跨層執行。
根據V過程開發的安全自主車輛會遇到很多大挑戰。但是為了確定車輛是安全的，仍然需要遵循ISO26262v流程，或者證明一套同樣嚴格的流程和技術實踐。假設應用了V過程，有一下三種看起來比較有意義的方法。
分階段部署
在不受限制的真實環境中(包括特殊情況)，開發和部署一輛自動駕駛汽車來處理所有可能的場景組合似乎是不切實際的。當下正如在汽車系統中常見的那樣，基于目前開發人員實踐的分階段部署方法似乎是一種更為合理的方法。
可以将分階段部署綁定到V流程，通過指定良好的操作概念來限制操作範圍，進而限制必要的需求範圍。這會包括環境、系統和操作限制的限制，這些限制必須用于滿足于實作自主操作。驗證這些操作限制是否被執行是確定安全性的重要部分，在V過程中它必須顯示為一組包括操作需求、驗證和潛在運作時的機制。
例如，在運作時監控不僅需要監控系統狀态是否允許自主授權，而且需要假設關于安全的操作場景參數實際上是否滿足，以及操作場景的系統實際上是否認為它是被滿足的。
需要特别注意的受限操作概念的一個方面是，需要確定在操作場景突然失效時維護安全性，例如，由于意外的天氣事件或基礎設施故障引起的操作場景失效。當系統偏移在允許的自主操作場景之外時，異常轉換機制需要成功地執行系統恢複或故障轉移任務，目前尚不清楚的是，分階段部署方法是否為實作自主駕駛提供一條完整的道路。但是，這樣的方法至少提供了一種方法來取得進展，而且帶來了一些好處，與此同時因為系統看到了更多的現實世界的情況。這種方法幫我們對困難的邊界情況和未預料到的情況有更多的了解。
監控/執行機構
使用監控/執行機構架構是一種常見的方法，可以幫助減輕自動車輛安全的許多挑戰。正如所讨論的，這種架構風格能滿足很高的複雜性需求(隻有螢幕本質上是完美的)，并部署歸納算法(通過限制對執行器的使用，并使用基于演繹的螢幕)。此外，使用故障轉移任務政策可以允許自主系統螢幕檢測主系統故障，而不必確定故障操作行為。更簡單、高度完整性的故障轉移自主系統可以使車輛到達安全狀态。這樣的系統可能具有足夠短的故障轉移任務，隻要能夠確定在啟動故障轉移任務時整個系統是無故障的，就可以使故障轉移操作的備援最小化。
為了確定系統的可靠性，單獨的故障注入測試是不可行的。自動駕駛汽車增加了這一問題的複雜困難性，因為自動駕駛汽車能自動對高度複雜的環境做出反應，并引入諸如機器學習等難以測試和測試費用高昂的技術。是以由于缺乏人駕駛監督，自動駕駛系統必須有一個很高的汽車安全完整性等級。制作普通的系統測試，似乎很難獲得對合理的水準的保證。故障注入可以作為驗證政策的一部分發揮相當的作用，驗證政策包括傳統的測試和非測試驗證。特别是當故障注入應用于多個抽象級别，而不僅僅是在電氣連接配接器的層面上時，這一點就顯得尤為重要。
未來工作
本文讨論了如何在基于ISO 26262的V架構内實作自動車輛安全的保障。但是，事實上使用架構模式(如監視/執行器方法)和通過故障注入進行驗證将限制操作性能。換句話說，我們可能需要通過收束自動駕駛汽車的功能，以适應當下的測試技術的限制。如果想放寬這些限制，需要在以下方面取得進展：描述與預期操作環境相符的機器學習訓練資料的覆寫範圍，對基于異常駕駛條件的安全需求有信心，以及能夠驗證帶有備援的歸納系統中故障的獨立性。
-- END --