--后臺回復“資料”，領取特斯拉專利技術解析報告--
一般來說軟件測試常常只是尋找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的右側提供了一種可追溯的方式來檢查左側的結果(驗證和驗證)。但是，這種檢查的概念是基于一個假設，即需求實際上是已知的，正確的、完整的、明確指定的。這種假設給自動駕駛汽車帶來了挑戰。
非確定性和統計算法
自動駕駛車輛使用的一些技術本質上是統計的。一般來說，它們往往是不確定的(不可重復的)，并且可能只在一個概率可以被分配的情況下給出基于概率正確的答案。驗證這樣的系統會帶來一些挑戰，這些挑戰通常不會出現在更確定的、傳統的汽車控制系統中
隨機系統的挑戰
隨機系統非確定性計算的挑戰包括一些算法，如規劃算法，它們可能通過對許多隨機選擇的候選者的結果進行排名來工作。由于該算法的核心操作是基于隨機生成，因此很難進行復制。雖然在單元測試中使用可重復的偽隨機數流等技術可能有幫助，但是在集成系統中創建完全確定的行為可能是不現實的，尤其是當初始條件的微小變化導致系統行為的發散狀態時。這意味著，盡管嘗試使用名義上相同的測試用例，但每一輛車測試都可能導致不同的結果。
成功的感知算法也往往是概率的。例如，證據網格框架(evidence grid framework)將來自單個、不確定的傳感器讀數的擴散累積，使得機器人對周圍環境越來越能建立一個更加詳細的地圖。這種方法產生一個對象存在的可能性，但是時候不能完全保證的。此外，這些算法基于先前的傳感器物理模型(如多路徑返回)和噪聲模型本身就是概率性的，對環境條件的微小變化敏感。
除了對環境的幾何建模之外，其他算法還從感知到的數據中提取標簽。其中突出的例子包括行人檢測。這樣的系統即使在無噪聲數據的情況下，也可能出現潛在的不可預測的故障模式。例如，視覺系統可能難以消除由于陰影而產生的顏色變化，而且在大型反射表面的存在中，視覺系統很難確定物體的位置。(公平地說，這些對人類來說都是挑戰。)此外，任何分類過程都顯示了假陰性和假陽性之間的權衡，其中一個的數量越少，另一個的數量就越多。測試的含義是這樣的算法不會在百分之百的時間內有效，而且根據構造的不同，它們可能會報告一個特定的情況是真實的，而這個情況實際是真實的可能性只是中等。
測試中的非決定論
處理測試中的非決定論很困難至少有兩個原因。
第一個是很難實施特定的邊緣情況。這是因為，只有當系統接收到來自世界的非常特定的輸入序列時，系統才可能以激活邊緣情況的方式運行。由于前面討論過的一些因素，例如計時器對輸入的微小變化的響應可能存在顯著差異，因此很難設計出一種情況，在這種情況下，環境可靠地提供適當的條件來運行特定所需的測試用例。作為一個簡單的例子，車輛可能更喜歡在寬闊的道路上行駛更迂回的路線，而不是在一條狹窄的巷子里走捷徑。為了評估在狹窄的巷道中導航的性能，測試人員需要設計一種使寬闊的巷道對計劃者沒有吸引力的情況。但是，這樣做需要對測試計劃給予額外的成本，并且可能(手動地)將車輛移動到它通常不會進入的情況以強制執行所需的響應。
測試中不確定性的第二個困難是很難評估測試結果是否正確，因為對于一個給定的測試用例來說，沒有唯一的正確系統行為。因此，正確性標準可能必須采用與前面討論的安全信封類似的形式，如果最終系統狀態在可接受的測試通行信封內，則測試通過。一般情況下可能需要多個測試來建立信任。
概率系統行為對驗證提出了類似的挑戰，因為通過一次測試并不意味著每次都能通過測試。事實上，有了概率行為我們可能會認為至少某些類型的測試會在一定程度上失敗。因此，測試可能不是為了確定行為是否正確，而是為了驗證行為的統計特征是否被精確地指定(例如，假陰性檢出率不大于相關安全參數中假定的檢出率)。比起簡單的功能驗證，這可能需要更多的測試，特別是如果問題中的行為是關鍵的安全部分且在預期中會有極低的失敗率。
從概率系統中獲得極高的性能可能需要多個子系統在發生完全獨立的故障時有低的失敗率。例如，可以將復合雷達和視覺系統結合起來，以確保在極低的概率范圍內沒有遺漏的障礙物。這種方法不僅適用于傳感模式，而且也適用于規劃和執行中的其他各種算法方案。如果這樣的方法是成功的，那么很有可能失敗的概率非常低，以至于測試驗證復合性能幾乎是不可行的。例如，如果兩個系統必須每十億次檢測就會遺漏一次障礙，那么必須運行數十億次有代表性的測試來驗證這種性能。為了驗證復合不同算法的低故障率，可以嘗試分別驗證每種算法更頻繁的允許故障率。但這是不夠的。我們還必須驗證失敗之間獨立的假設，這很可能必須基于分析和測試才能進行。
機器學習系統
只有在正確地做出一系列復雜的感知和控制決策的情況下，自動駕駛汽車才有可能采取正確的行為。要實現這一目標，通常需要對參數進行適當的調整，包括從每個相機鏡頭的校準模型，到為避免高速公路上的障礙而轉向或停車的風險的適當加權。這里的挑戰是找到校準模型或權重的比值，從而使某些誤差函數最小化。近年來，大多數機器人應用都轉向機器學習來實現這一點，因為多維優化的復雜性使得手工工作不太可能產生理想的性能水平。
機器學習方法的細節有很多，例如，有監督學習、強化學習等，但總之所有這些方法都涉及歸納學習，在歸納學習中，訓練集被用來推導一個模型。
例如，考慮在單目圖像中檢測行人的情況。使用一組大型圖像訓練集，分類器可以學習一種決策規則，該規則將行人在一組單獨的圖像驗證集中被檢測到的概率降至最低。為了我們的目的，一個基本要素是訓練集實際上是系統的需求集合，而規則是系統設計的結果。(機器學習算法本身和分類器算法都比傳統的驗證技術更容易修改。然而，這些都是通用的軟件引擎，最終的系統行為是由用于學習的訓練數據決定的。)
可以嘗試通過創建一組訓練數據的需求來回避訓練集數據形成實際需求的問題。但這最終只是將同樣的挑戰推到了一個抽象層次上。需求不應是典型V系統本身的一組功能需求，而是以一組訓練數據或收集訓練數據集的計劃的形式
驗證歸納學習的挑戰
歸納學習方法的性能可以通過從收集的總體數據集中保留一些樣本并使用這些樣本進行驗證來測試。假設有以下這種情況，如果把訓練集作為系統需求(V的左邊)看，可以用一組獨立的驗證數據來確保滿足測試的需求(V的右邊)。訓練數據不能有意外的相關性與所需的行為，否則系統將過擬合。類似地，驗證數據必須獨立于訓練數據，并且在除所需的特性之外的所有方面都與訓練數據不同，否則在驗證過程中會檢測到過擬合。當然目前尚不清楚如何論證機器學習系統沒有產生過擬合。
機器學習在實踐中的一個重要限制是，如果使用帶標簽的數據，每個數據點都可能很昂貴。(創建標簽必須由某人或某物來完成。無監督學習技術也是可能的，但需要一個巧妙的映射來解決特定的問題。此外，如果訓練集有問題或所學習的規則有問題，那么就需要收集更多的驗證數據并用于驗證更新的系統。這是必要的，因為即使對訓練數據做一個小的更改，也會產生一個完全不同的學習規則集。
由于自主系統的需求非常復雜，很可能會出現一些罕見的邊緣案例，在那里學習將會發生問題。然而，由于它們的稀缺性，收集描述這種不尋常情況的數據可能是昂貴的，而且很難衡量。(模擬和合成數據可以幫助解決這一問題，但在模擬數據中存在偏差的風險，以及對仿真工件的過度擬合。)
驗證機器學習的另一個問題是，一般來說，人類不能直觀地理解過程。例如，卷積神經網絡的內部結構可能不能讓人類觀察者更直觀地了解已經學會的決策規則。雖然可能有一些特殊的情況，但一般來說，機器學習的易讀性問題即能夠用人類的術語解釋系統的行為這個問題還沒有解決辦法。這使得除了昂貴的蠻力測試之外很難預測的技術如何應用于機器學習系統的驗證。(也許有些組織確實有資源進行廣泛的蠻力測試。但即使在這種情況下，訓練數據的準確性、有效性和代表性也必須被證明為是安全論證的一部分。)
由于機器學習系統的易讀性一般較差，而且由于過度擬合的危險是真實存在的，因此在這樣的系統中存在著嚴重影響安全性的失效模式。特別值得關注的是在訓練集數據中出現的偶然相關性，但人類往往注意不到這種相關性。例如，考慮使用經過訓練的可變形部件模型來檢測圖像中的行人的方法，這在現實世界的數據集中已被證明是相當有效的。如果訓練數據集中沒有(或很少)行人坐輪椅的圖像，那么這樣的系統很可能會將行人的標簽與用兩條腿走路的人錯誤地聯系起來。
歸納學習的解決方案
歸納學習怎么進行測試是很困難的。首先是黑天鵝問題，故事是這樣的，在18世紀末之前，在歐洲觀察到的所有的天鵝都是白色的，因此一個使用歸納邏輯的觀察者會得出結論，所有的天鵝都是白色的。然而，這名觀察者在訪問澳大利亞時，會經歷這種信念的挑戰，因為那里有大量的黑天鵝。換句話說，如果系統沒有看到一個特殊的情況，它就不能學習這個情況。這是對歸納學習方法的一個基本限制。此外，由于機器學習嚴重缺乏易讀性，人類審查員很難或不可能想象在這樣一個系統中出現類似黑天鵝的偏差。
驗證一個歸納學習系統似乎是一個極具挑戰性的問題。我們可能會使用廣泛的測試，但需要保證黑天鵝數據隨機獨立到達率的假設，并對相應大小的數據集進行測試。如果有足夠的資源，這可能是可行的，但是總會有新的黑天鵝，所以需要對大量的操作場景和輸入值進行概率評估，以確保系統故障的低水平。
另一種驗證歸納學習系統到高汽車安全完整性等級水平的方法是將一種基于歸納的低汽車安全完整性等級算法配對，該算法將命令發送給執行器，并使用基于高汽車安全完整性等級演繹的監視器。這將回避驅動算法的大部分驗證問題，因為控制執行器的誘導算法的失敗將被基于演繹生成的安全信封等概念的非感應監視器捕獲。因此，執行器算法失敗將是一個可用性問題(假定有足夠的故障轉移能力，系統安全關閉)，而不是安全問題。
關鍵任務的操作需求
現在讓我們回到先前討論過的地方，即計算機最終控制著車輛，而不是控制著人。這意味著至少部分車輛必須是基于故障操作而不是面對故障停止。
故障操作系統設計的挑戰
故障操作系統設計已經在航空航天和其他環境中成功地完成了幾十年，但是由于以下幾個原因仍然是困難的。第一個原因是顯而易見的，即必須提供冗余，以便當一個組件失敗時，另一個組件可以接管。實現這一點需要至少兩個獨立的、冗余的故障停止行為子系統。
實現故障操作系統反過來需要至少三個冗余的故障任意組件，以便在發出不正確的輸出而不是在組件級別發出靜默失敗的情況下確定故障源。對于必須容忍任意錯誤故障的系統，根據相關的故障模型，可能需要一個具有4個冗余組件的復雜容錯系統。
冗余的結構變化取決于設計方法，和可能包括配置如三冗余系統成員(在這種情況下，成員必須確保不被一個單點故障)，或兩個二對二系統，或者使用四臺電腦。這些方法除了引入的明顯開銷之外，還存在一個測試問題，即如何確保故障檢測和恢復工作的有效性，確保故障的獨立性，并確保在驅動任務開始時所有冗余組件都是無故障的。冗余似乎不太可能被避免，但為了確保安全，可能會降低提供足夠冗余的復雜性和成本。
在典型的故障操作系統(如飛機)中，所有冗余部件本質上都是相同的，它都能夠執行擴展任務。例如，商用飛機通常配置兩個噴氣發動機，每個噴氣發動機至少有一個雙冗余計算機控制。如果一臺發動機上的兩臺計算機由于持續的交叉檢測故障而關閉，那么就會有第二個獨立的引擎來維持飛機的飛行。即便如此，對引擎可靠性的要求還是非常嚴格的，因為在第一個引擎故障后，飛機可能需要飛行幾個小時才能到達最近的機場。這就對每個引擎提出了顯著的可靠性要求，從而增加了組件成本。
雖然汽車是出了名的價格敏感的，但它們也有一個優勢，即故障轉移任務的時間可以很短(例如，把車停在路邊，或者在必要時停在一條旅游線路上)，故障轉移任務的持續時間是以秒而不是小時為單位度量的。此外，用于停止車輛的故障轉移任務可能比完全自主操作的功能要少得多。這可以簡化需求復雜性、計算冗余、傳感器需求和驗證需求。(作為一個簡單的例子，故障轉移任務控制系統可能不支持變道，這極大地簡化了傳感器需求和控制算法)因此，設計一個具有故障停止主控制器和更簡單的故障操作故障轉移控制器的自動車輛可能在硬件成本和設計/驗證成本方面都具有吸引力。
它也可能不是基于完全的自主系統，而是就是完全的自主系統，在完全的自主系統中有一個檢測器.這將使故障探測器本身擁有高水平，但可能允許正常的自主功能為低汽車安全完整性等級。這種方法可以很好地映射到主自主系統的監視/執行器體系結構。故障轉移的自主性也必須以安全的方式設計，并根據其復雜性和計算的可靠性需求采用適當的體系結構方法。如果僅持續幾秒鐘的短暫故障轉移任務中發生故障的可能性足夠低，那么甚至可以使用單通道故障轉移系統。
非技術性因素
在部署自動駕駛時遇到的一些挑戰是非技術性的，例如經常提到的責任問題(當發生事故時誰負責賠償?)以及法律通常如何對待所有權、操作、維護和其他方面的車輛的問題。深入研究這個問題顯然超出了本文的范圍。然而，對非技術挑戰的決議很可能對技術解決方案產生影響。例如，對事故重建數據的自主系統可能有法律要求，需要對這些數據的來源進行仔細的分析，以確保正確使用這些數據。舉個簡單的例子，假設雷達探測概率為95%，那么它的輸出可能仍然會被記錄在系統中，以判斷是否檢測到障礙物，表面上這意味著探測的確定性。
重要的是要確保法分析考慮到，僅僅因為雷達沒有探測到行人，并不意味著行人不在那里(例如95%檢測可能意味著每20個行人中就有一個不會被檢測到)。
看起來，由于自動車輛的固有復雜性，以及無法通過測試證明完備性，開發人員必須以保證案例的形式創建安全保證參數。這樣的保證論證對于維護和解釋系統的完整性是必要的，并且它能夠可靠地解釋系統對不可避免的危險情況的反應。確保證據的完整性是應該解決的一個特殊問題，因為借此可確定由于發生特殊情況而造成的事故是否是不可避免的。其他需要關注的重要的問題是，事故是否由系統需求的缺陷、合理可預見和可避免的設計缺陷、實施的缺陷或其他原因引起的。
故障注入
從前面的討論中可以明顯看出，傳統的功能測試在面對一個完整的系統時會遇到困難，尤其是在不尋常的操作條件下，很難去執行異常的組合。雖然測試人員可以定義一些非名義上的測試用例，但由于異常、操作場景和其他相關因素的組合爆炸，該測試的可擴展性存在問題。
此外，研究還表明，即使是非常優秀的設計人員，在相對簡單的軟件系統中，也經常會出現盲點和錯過異常情況。
故障注入和魯棒性測試是在異常情況下評估系統性能的較為成熟的技術，在測試異常情況響應時可以避免設計人員和測試人員的盲點。傳統的故障注入包括將位翻轉插入到內存和通信網絡中。最近的技術增加了抽象的層次，包括基于數據類型的故障字典，并確保了故障的代表性。這些技術已經被成功地用于自動駕駛汽車的缺陷的發現和特征。
這是一種很有希望幫助驗證自主性的方法，它在組件的抽象級別執行故障注入，作為試圖偽造安全性聲明的策略的一部分。這不僅涉及到對主要傳感器輸入的對象進行模擬，還涉及到插入異常條件以測試系統的健壯性(例如，在映射中插入無效數據)。執行此類故障注入的目的不是驗證功能，而是通過探查不可預見的情況激活弱點。這種故障注入也可以ISO 26262過程中跨層執行。
根據V過程開發的安全自主車輛會遇到很多大挑戰。但是為了確保車輛是安全的，仍然需要遵循ISO26262v流程，或者證明一套同樣嚴格的流程和技術實踐。假設應用了V過程，有一下三種看起來比較有意義的方法。
分階段部署
在不受限制的真實環境中(包括特殊情況)，開發和部署一輛自動駕駛汽車來處理所有可能的場景組合似乎是不切實際的。當下正如在汽車系統中常見的那樣，基于當前開發人員實踐的分階段部署方法似乎是一種更為合理的方法。
可以將分階段部署綁定到V流程，通過指定良好的操作概念來限制操作范圍，從而限制必要的需求范圍。這會包括環境、系統和操作約束的限制，這些限制必須用于滿足于實現自主操作。驗證這些操作約束是否被執行是確保安全性的重要部分，在V過程中它必須顯示為一組包括操作需求、驗證和潛在運行時的機制。
例如，在運行時監控不僅需要監控系統狀態是否允許自主授權，而且需要假設關于安全的操作場景參數實際上是否滿足，以及操作場景的系統實際上是否認為它是被滿足的。
需要特別注意的受限操作概念的一個方面是，需要確保在操作場景突然失效時維護安全性，例如，由于意外的天氣事件或基礎設施故障引起的操作場景失效。當系統偏移在允許的自主操作場景之外時，異常轉換機制需要成功地執行系統恢復或故障轉移任務，目前尚不清楚的是，分階段部署方法是否為實現自主駕駛提供一條完整的道路。但是，這樣的方法至少提供了一種方法來取得進展，而且帶來了一些好處，與此同時因為系統看到了更多的現實世界的情況。這種方法幫我們對困難的邊界情況和未預料到的情況有更多的了解。
監控/執行機構
使用監控/執行機構架構是一種常見的方法，可以幫助減輕自動車輛安全的許多挑戰。正如所討論的，這種架構風格能滿足很高的復雜性需求(只有監視器本質上是完美的)，并部署歸納算法(通過限制對執行器的使用，并使用基于演繹的監視器)。此外，使用故障轉移任務策略可以允許自主系統監視器檢測主系統故障，而不必確保故障操作行為。更簡單、高度完整性的故障轉移自主系統可以使車輛到達安全狀態。這樣的系統可能具有足夠短的故障轉移任務，只要能夠確保在啟動故障轉移任務時整個系統是無故障的，就可以使故障轉移操作的冗余最小化。
故障注入
為了確保系統的可靠性，單獨的故障注入測試是不可行的。自動駕駛汽車增加了這一問題的復雜困難性，因為自動駕駛汽車能自動對高度復雜的環境做出反應，并引入諸如機器學習等難以測試和測試費用高昂的技術。因此由于缺乏人駕駛監督，自動駕駛系統必須有一個很高的汽車安全完整性等級。制作普通的系統測試，似乎很難獲得對合理的水平的保證。故障注入可以作為驗證策略的一部分發揮相當的作用，驗證策略包括傳統的測試和非測試驗證。特別是當故障注入應用于多個抽象級別，而不僅僅是在電氣連接器的層面上時，這一點就顯得尤為重要。
未來工作
本文討論了如何在基于ISO 26262的V框架內實現自動車輛安全的保障。但是，事實上使用架構模式(如監視/執行器方法)和通過故障注入進行驗證將限制操作性能。換句話說，我們可能需要通過收束自動駕駛汽車的功能，以適應當下的測試技術的限制。如果想放寬這些限制，需要在以下方面取得進展：描述與預期操作環境相符的機器學習訓練數據的覆蓋范圍，對基于異常駕駛條件的安全需求有信心，以及能夠驗證帶有冗余的歸納系統中故障的獨立性。
-- END --
