廣告
SOTIF：自動駕駛汽車測試和驗證的挑戰(zhàn)
2020-07-20 17:41:03· 來源：上?？匕?軒轅實驗室
軟件測試常常只是一個簡單的BUG搜索，而不是一個經(jīng)過深思熟慮的確保質(zhì)量的實踐。要大規(guī)模部署安全的自動駕駛車輛，需要一種比簡單的系統(tǒng)級測試-故障補丁-測試周
軟件測試常常只是一個簡單的BUG搜索，而不是一個經(jīng)過深思熟慮的確保質(zhì)量的實踐。要大規(guī)模部署安全的自動駕駛車輛，需要一種比簡單的系統(tǒng)級測試-故障補丁-測試周期更有條理的方法。ISO26262開發(fā)V流程建立了一個框架，將每種類型的測試與相應(yīng)的設(shè)計或需求文檔聯(lián)系起來，但在適應(yīng)處理自動駕駛汽車面臨的各種新測試問題時，會遇到一些挑戰(zhàn)。根據(jù)自動駕駛車輛V模型，提出了自動駕駛車輛測試的主要挑戰(zhàn)：駕駛員不再參與控制、復(fù)雜需求、非確定性算法、歸納學(xué)習(xí)算法和故障操作系統(tǒng)。在這些不同的挑戰(zhàn)領(lǐng)域中，通用的解決方案似乎效果很好，包括：使用相繼放松的操作場景的分階段部署，使用監(jiān)視器/執(zhí)行器對來將最復(fù)雜的自動功能與簡單的安全功能分離，以及將故障注入作為執(zhí)行更有效的邊緣情況測試的一種方式。為了提供高水平自主，雖然安全認證類型算法方面仍存在重大挑戰(zhàn)，但似乎可以將體系結(jié)構(gòu)及其隨附的設(shè)計過程構(gòu)造為能夠采用現(xiàn)有的軟件安全方法。
1 簡 介
盡管自動駕駛汽車最近成為了一個熱門話題，但其背后的技術(shù)已經(jīng)發(fā)展了幾十年，可以追溯到自動公路系統(tǒng)項目[1]以及之前。從那些早期的演示開始，該技術(shù)已經(jīng)成熟到先進的駕駛員輔助系統(tǒng)(ADAS)，如自動車道保持和智能巡航控制是許多車輛的標(biāo)準(zhǔn)配置。除此之外，還有許多處于不同發(fā)展階段的完全自主汽車項目，包括多車車隊的擴展道路測試。
如果你相信權(quán)威人士的說法，那么全自動汽車(通常被稱為自動駕駛汽車)的全面普及指日不遠了。然而，正如傳統(tǒng)汽車行業(yè)所熟知的那樣，制造幾輛汽車，讓它們在有專業(yè)安全駕駛員的合理良性環(huán)境中運行，與制造數(shù)百萬輛汽車，讓它們在一個沒有約束的世界中運行，兩者之間存在巨大差異。有人說，成功的測試和幾千公里(甚至幾十萬公里)的駕駛經(jīng)驗意味著，自動駕駛技術(shù)基本上已經(jīng)準(zhǔn)備好全面部署。但是，很難看出僅僅這樣的測試就足以確保足夠的安全性。實際上，至少一些開發(fā)人員似乎在做更多的工作，但問題是還需要做多少工作，以及我們?nèi)绾沃雷罱K的工具在部署時是非常安全的。
在這篇文章中，我們探索了一些開發(fā)者的挑戰(zhàn)，這些開發(fā)者正試圖獲得完全自主，以及NHTSA級別4[2]車輛大規(guī)模部署的資格。因此，我們跳過了潛在的半自動化方法來處理那些駕駛員完全不負責(zé)車輛安全操作的系統(tǒng)。我們進一步限制范圍來考慮如何在ISO 26262 v框架內(nèi)設(shè)計和驗證這樣的車輛。這個限制的原因是，這是一個確保安全的可接受的做法?；谟嬎銠C的系統(tǒng)應(yīng)該被認為是不安全的，除非有令人信服的其他理由，這是一個公認的安全原則(即，安全必須表現(xiàn)出來，而不是假設(shè))。因此，自動駕駛汽車不能被認為是安全的，除非和直到他們被證明符合或映射到ISO 26262或其他一些適當(dāng)?shù)?，廣泛接受的軟件安全標(biāo)準(zhǔn)。
完全測試不可行
車輛水平的測試不足以確保安全。人們早就知道，對系統(tǒng)進行足夠徹底的測試以確保系統(tǒng)運行的可靠性是不可行的
例如，假設(shè)有100萬輛汽車，每天運行一小時(即每天106小時運作時間)。如果安全目標(biāo)是每1000天發(fā)生一次災(zāi)難性計算故障，那么安全目標(biāo)是109小時的平均災(zāi)難性故障時間，這與飛機的允許故障率[3]相當(dāng)。請注意，這承認了在車隊的生命周期中，由于計算機缺陷或故障而導(dǎo)致的幾次災(zāi)難性故障發(fā)生的可能性。但是，如果與手動駕駛車輛相比，由于駕駛員失誤而導(dǎo)致災(zāi)難性事故的發(fā)生率大大降低，那么這一目標(biāo)可能是合理的。(這只是一個失敗率的例子。人們可能會為這個比率的高低提出論據(jù)，但它被選為一個合理的比率，說明了實現(xiàn)安全方面的一些困難。)
為了驗證車輛的災(zāi)難性故障率為每109小時一次，一個人必須進行至少109車輛操作小時的測試(十億小時)[4]，事實上必須測試幾倍的時間，可能會重復(fù)多次這樣的測試來實現(xiàn)統(tǒng)計學(xué)意義。即使這樣，也假定測試環(huán)境是真實部署的高度代表，并且導(dǎo)致災(zāi)難的環(huán)境是以隨機、獨立的方式出現(xiàn)的。在不危及公眾安全的情況下，建立一支能在典型測試環(huán)境下運行數(shù)十億小時的大型實體車隊似乎是不切實際的?？赡馨ǚ抡?、形式證明、故障注入、引導(dǎo)的基礎(chǔ)上穩(wěn)步增加車隊規(guī)模、獲得非關(guān)鍵角色的組件技術(shù)的現(xiàn)場經(jīng)驗和人員審查等方法。(組件級測試也起作用，但是為物理硬件設(shè)備積累109個小時的預(yù)部署測試仍然是不切實際的。)當(dāng)人們考慮到自動系統(tǒng)的測試甚至比日常軟件系統(tǒng)的測試更困難時，情況會變得更糟，下面將對此進行討論。
也就是說，對于相對非關(guān)鍵的計算系統(tǒng)，可以使用測試作為驗證適當(dāng)安全級別的主要基礎(chǔ)。這是因為涉及低嚴(yán)重程度和低暴露的故障可能比災(zāi)難性故障的發(fā)生率更高。例如，如果特定類型的故障每1000小時發(fā)生一次是可以接受的(因為這種故障會導(dǎo)致最低成本的事件或輕微的中斷)，那么通過數(shù)千小時的測試可以可靠地驗證該故障率。這并不是說所有的軟件質(zhì)量過程可以放棄這樣的系統(tǒng)， 而是如果平均故障間隔時間要求相對寬松，那么適當(dāng)?shù)臏y試和故障監(jiān)視策略可能可以驗證具有適當(dāng)質(zhì)量的組件實際上達到了可接受的低故障率。
以V模型為起點
因為系統(tǒng)級測試無法完成這項工作，所以需要更多的測試。這正是擁有一個更健壯的開發(fā)框架來創(chuàng)建安全關(guān)鍵軟件的關(guān)鍵所在。
軟件開發(fā)V模型在汽車上的應(yīng)用由來已久。它是20多年前納入MISRA指南的發(fā)展參考模型之一[5，6]。最近，它被提升為形成ISO26262[7]基礎(chǔ)的參考模型。
通常，V模型(圖1)表示一個有方法的創(chuàng)建過程，然后是驗證和確認。V模型的左側(cè)工作方式是從需求到設(shè)計再到實現(xiàn)。在每個步驟中，系統(tǒng)通常被分解為并行處理的子系統(tǒng)(例如，有一組系統(tǒng)需求，但是每個子系統(tǒng)的設(shè)計是獨立的)。當(dāng)系統(tǒng)從小型組件恢復(fù)到系統(tǒng)級評估時，V的右邊迭代地驗證和驗證越來越大的系統(tǒng)塊。盡管ISO 26262對該模型進行了詳細的闡述，但我們?nèi)匀槐３滞ㄓ眯裕杂懻摳呒壦枷搿?br />
盡管ISO 26262及其V框架通常反映了確保汽車安全的公認做法，但在將汽車的技術(shù)映射到V模型方面，全自動汽車面臨著獨特的挑戰(zhàn)。
圖1 一個通用的V模型
2 駕駛員不參與控制
對于全自動駕駛汽車來說，最明顯的挑戰(zhàn)可能是，關(guān)鍵在于駕駛員不再真正駕駛汽車。這意味著，根據(jù)定義，在[2]操作期間，司機不能再為車輛提供控制輸入。
可控性的挑戰(zhàn)
對于低完整性裝置的典型汽車安全論證可能取決于人類駕駛員施加控制的能力。例如，在一個高級的駕駛員輔助系統(tǒng)(ADAS)中，如果一個軟件故障導(dǎo)致了一個潛在的危險情況，那么這個駕駛員可能被期望越過那個軟件功能并恢復(fù)到一個安全的狀態(tài)。司機們也有望從嚴(yán)重的車輛機械故障中恢復(fù)過來，比如輪胎爆裂。換句話說，在有人駕駛的車輛中，駕駛員負責(zé)采取正確的糾正措施。駕駛員沒有能力采取糾正措施的情況被認為是缺乏可控性，因此必須設(shè)計到更高的汽車安全完整性水平，即ASIL[8]。
有了全自動駕駛汽車，駕駛員就不能指望處理特殊情況了。相反，計算機系統(tǒng)必須承擔(dān)主要異常處理程序的角色，處理錯誤、故障和超出指定的操作條件。與ADAS系統(tǒng)相比，讓計算機負責(zé)異常處理似乎可能會極大地增加自動化的復(fù)雜性。ADAS系統(tǒng)的組合，如車道保持和智能巡航控制，似乎誘人地接近于完全自主操作。然而，一輛全自動汽車必須要有額外的復(fù)雜性來處理所有可能出錯的情況，因為當(dāng)事情出錯時，沒有司機來抓方向盤和剎車。
自主體系結(jié)構(gòu)方法
在ISO 26262的背景下，讓計算機負責(zé)提出了評估風(fēng)險的兩種策略。一種策略是將風(fēng)險評估[8]的可控性部分設(shè)置為難以控制或無法控制的C3。如果嚴(yán)重程度和暴露程度很低，這可能是一個可行的選擇，因此可以指定較低的ASIL。但是，在中度或高度嚴(yán)重和暴露的情況下，該系統(tǒng)必須設(shè)計到一個高的汽車安全完整性水平(ASIL)。(有些人可能會說，應(yīng)該有一個更高的可控性分類C4，因為自動化系統(tǒng)有時候不僅不能提供安全功能，還有可能主動采取危險積極行動。但我們假設(shè)現(xiàn)有的C3就足夠了。)
另一種處理高ASIL自治功能的方法是通過結(jié)合監(jiān)視器/執(zhí)行器架構(gòu)和冗余來使用ASIL分解[9]。監(jiān)測/執(zhí)行器架構(gòu)是這樣一種架構(gòu)，其中主要功能由一個模塊(執(zhí)行器)執(zhí)行，一個成對的模塊(監(jiān)視器)執(zhí)行驗收測試[5，10]或其他行為驗證。如果執(zhí)行器動作不正確，監(jiān)視器將關(guān)閉整個功能(兩個模塊)，導(dǎo)致故障-沉默系統(tǒng)(任何故障都會導(dǎo)致一個沉默組件，有時也稱為故障-停止或故障-安全。)
如果監(jiān)視器/執(zhí)行器對(圖2)設(shè)計正確，只要監(jiān)視器具有非常高的ASIL并檢測到監(jiān)視器中所有可能的故障，執(zhí)行器就可以設(shè)計為一個低ASIL (此外，還需要檢測監(jiān)視器中的潛在故障，以避免因執(zhí)行器故障而導(dǎo)致監(jiān)視器損壞) 。如果監(jiān)視器能夠比執(zhí)行器簡單得多，減少高ASIL監(jiān)視器的尺寸，并允許大部分功能復(fù)雜性被放置到一個低ASIL執(zhí)行器中，那么這種結(jié)構(gòu)模式將是特別有利的。
圖2監(jiān)控器/執(zhí)行器概念圖
監(jiān)視器/執(zhí)行器對的優(yōu)點和缺點都是創(chuàng)建了一個故障-沉默模塊(如果有故障就會關(guān)閉)。使用異構(gòu)冗余(兩個模塊：監(jiān)視器和執(zhí)行器)是為了防止發(fā)生故障的執(zhí)行器發(fā)出危險的命令。但是，如果出現(xiàn)故障，也會導(dǎo)致執(zhí)行器功能喪失，這對于故障后必須操作的功能（例如在行駛中的車輛中轉(zhuǎn)向）是一個問題。
至少，提供失敗的操作行為需要更多的冗余(不止一個監(jiān)視器/執(zhí)行器對)，并且很有可能設(shè)計多樣性，這樣普通模式的軟件設(shè)計失敗就不會導(dǎo)致系統(tǒng)失敗。這是很重要的，以避免損失的情況，如阿麗亞娜5號航班501，這是由于主系統(tǒng)和備份系統(tǒng)經(jīng)歷了相同的未處理異常(組件設(shè)計未預(yù)料到的)操作條件而以相同的方式故障所導(dǎo)致的。
應(yīng)該注意的是，實現(xiàn)多樣性并不一定是簡單的，因為在同一套用于簡化不同組件(例如，[12])的高級需求中存在缺陷的脆弱性等問題。然而，這種情況也適用于非自動軟件。還應(yīng)該注意，監(jiān)視器/執(zhí)行器對故障沉默的要求是基于故障獨立性的假設(shè)，但這同樣適用于非自動系統(tǒng)。
高水平自動駕駛汽車的一個關(guān)鍵觀點是，需要有一種方法來檢測自動功能何時不能正常工作(無論是由于硬件故障、軟件故障還是需求缺陷)，并且在通過故障操作降級模式自動功能檢測到此類故障時，以某種方式使系統(tǒng)處于安全狀態(tài)。
3 復(fù)雜的需求
開發(fā)的V模型的一個基本特征是，V的右側(cè)提供了一種可跟蹤的方法來檢查左側(cè)的結(jié)果(驗證和校驗)。然而，這種檢查的概念是基于這樣一個假設(shè)，即需求實際上是已知的、正確的、完整的、明確指定的。這一假設(shè)對自動駕駛汽車提出了挑戰(zhàn)。
需求挑戰(zhàn)
如前所述，從控制系統(tǒng)中移除驅(qū)動程序意味著軟件必須處理異常，包括天氣、環(huán)境危害和設(shè)備故障。其中可能有很多不同類型，從惡劣的天氣(洪水、霧、雪、吸煙，龍卷風(fēng))，到違反交通規(guī)則(錯誤行駛方向，其他司機闖紅燈等)到當(dāng)?shù)氐鸟{駛習(xí)慣，再到動物危害(鹿、犰狳和偶爾的蝗災(zāi))。
任何一個開了很長時間車的人都可能遇到行駛路上的各種怪事。一個規(guī)模很大的車隊，總的來說，可能會經(jīng)歷所有這些類型的事件，或者更多。更糟糕的是，不良事件和行車條件的組合可能會發(fā)生，其數(shù)量之多簡直無法用書面需求來描述。如果結(jié)果可能是無害的，也許不需要覆蓋所有這些極其罕見的組合，但是需求應(yīng)該清楚地說明系統(tǒng)設(shè)計范圍內(nèi)的內(nèi)容，以及哪些內(nèi)容不屬于系統(tǒng)設(shè)計范圍。因此，從列舉所有系統(tǒng)需求的文檔開始的經(jīng)典V流程，不太可能以嚴(yán)格的方式擴展到自動車輛異常處理，至少在不久的將來是這樣。
操作概念方法
管理需求復(fù)雜性的一種方法是約束操作概念，并參與需求的階段性擴展。開發(fā)人員已經(jīng)在這樣做了，他們可能會專注于特定地理區(qū)域的道路測試(例如，只在硅谷的分道公路上進行日間駕駛，那里降水有限，幾乎沒有冰凍天氣)。然而，使用操作概念的想法可以在許多方向上擴展。
可以用來限制操作概念的例子包括：
•道路接入：有限接入高速公路、HOV車道、農(nóng)村道路、郊區(qū)、封閉校園、城市街道等。
•能見度：晝、夜、霧、霾、煙、雨、雪等。
•車輛環(huán)境：在封閉的車庫中進行自動停車，沒有其他車輛行駛，只有自動車道，非自動車輛上有標(biāo)志應(yīng)答器等。
•外部環(huán)境：基礎(chǔ)設(shè)施支持、預(yù)先測繪的道路、配備人力駕駛的汽車
•速度：較低的速度可能導(dǎo)致更低的故障后果和更大的恢復(fù)裕度
雖然上面提到的自由度仍然有很多組合(當(dāng)然還有更多可以想象的)，但是從可能的操作概念中進行選擇的目的并不是要增加復(fù)雜性，而是要減少復(fù)雜性。降低需求復(fù)雜性的方法是，只在完全理解需求的特定有限的情況下(并確保對這些有效的操作條件的識別是正確的)允許自主。
因此，限制操作概念成為一種引導(dǎo)策略，用于在日益復(fù)雜的操作環(huán)境(例如，[14，15])中依次部署更復(fù)雜的技術(shù)能力。一旦對特定的操作概念的需求有了充分的了解，就可以隨著時間的推移添加其他類似的操作概念，以擴展允許的自動化場景的范圍。它不會完全消除復(fù)雜需求的問題，但是它可以幫助減少需求和異常的組合爆炸。
安全需求和不變性
即使使用了受限的操作概念，使用傳統(tǒng)的與安全相關(guān)的需求方法似乎也是不合適的。這種方法或多或少是這樣進行的。首先創(chuàng)建功能需求。然后，在執(zhí)行了一些風(fēng)險評估過程之后，對與安全相關(guān)的需求進行了注釋。然后，將這些安全相關(guān)需求分配給安全關(guān)鍵子系統(tǒng)。然后，設(shè)計滿足分配需求的安全關(guān)鍵子系統(tǒng)。最后，通過重復(fù)該循環(huán)來標(biāo)識和減輕未預(yù)料到的緊急子系統(tǒng)交互。
對于自治應(yīng)用程序來說，安全關(guān)鍵需求的注釋可能是不切實際的，至少有兩個原因。原因之一是許多需求可能只與部分安全性相關(guān)，并且與功能性能不可避免地交織在一起。例如，當(dāng)汽車移動時操作停車制動的許多條件可能是一組啟動條件。然而，只有這些需求的某些方面實際上是安全關(guān)鍵的，而這些方面在很大程度上是其他功能相互作用的緊急后果。以駐車制動為例，當(dāng)駐車制動以速度施加時的減速特性是所期望的功能之一，并且可能由許多功能需求來描述。但是，簡化后，減速模式中唯一的安全關(guān)鍵方面可能是其他需求的緊急交互必須避免在減速過程中鎖定車輪。
用于識別安全相關(guān)需求的需求注釋可能失敗的第二個原因是，當(dāng)使用機器學(xué)習(xí)技術(shù)時，這甚至可能不可能。這是因為需求(盡管它們是)采用一組訓(xùn)練數(shù)據(jù)的形式，列舉一組輸入值和正確的系統(tǒng)輸出。這些往往不是傳統(tǒng)需求的形式，因此需要對需求管理和驗證采用不同的方法。(參見本文后面關(guān)于機器學(xué)習(xí)的部分)。
與其試圖在安全子系統(tǒng)和非安全子系統(tǒng)之間分配功能需求，不如創(chuàng)建一個單獨的、與嚴(yán)格安全相關(guān)的[16]的需求并行集。這些需求往往以不變量的形式指定安全所需的系統(tǒng)狀態(tài)(必須為真才能安全，必須為假才能安全)。這種方法可以解決性能和優(yōu)化問題(最短的旅行路徑是什么?)或者最優(yōu)燃油消耗的速度是多少?)從安全的角度(我們會撞到什么東西嗎?)
使用這種方法將需求集劃分為V模型的兩部分。第一組需求將一組non-safety-related功能需求，這可能是在傳統(tǒng)的格式或一種非傳統(tǒng)的格式如機器學(xué)習(xí)訓(xùn)練集。然而，根據(jù)定義這些潛在的非傳統(tǒng)的需求并不安全，所以它可能是可以接受的，如果跟蹤和驗證有充足但不完美的報道。
第二組需求是一組純粹的安全需求，它完全而明確地定義了系統(tǒng)的安全含義，相對獨立于最佳系統(tǒng)行為的細節(jié)。對于不同的操作模式，這些需求可以采取安全操作信封的形式，系統(tǒng)可以在[17]操作信封內(nèi)自由地優(yōu)化其性能。很明顯，這樣的信封至少可以在某些情況下使用(例如，強制限速或設(shè)置最小跟隨距離)。這個概念承諾相當(dāng)普遍，但要證明它仍然是未來的工作。
采用一組與功能需求正交的安全需求的一個令人信服的理由是，這種方法干凈地映射到監(jiān)視器/執(zhí)行器架構(gòu)。功能需求可以分配到一個低ASIL執(zhí)行器功能塊，而安全需求可以分配到一個高ASIL監(jiān)視器。多年來，該思想一直被非正式地用作監(jiān)視器/執(zhí)行器設(shè)計模式的一部分。我們建議將此方法提升為設(shè)計自動駕駛車輛設(shè)計、需求和安全案例的主要策略，而不是將其降級為詳細的實現(xiàn)冗余策略。
4 非確定性和統(tǒng)計算法
自動駕駛汽車使用的一些技術(shù)本質(zhì)上是統(tǒng)計性質(zhì)的。一般來說，它們趨向于不確定(不可重復(fù))，并且可能只對某些概率給出正確的答案——如果某個概率可以被賦值的話。驗證這樣的系統(tǒng)所面臨的挑戰(zhàn)是傳統(tǒng)的確定性汽車控制系統(tǒng)所沒有的。
隨機系統(tǒng)的挑戰(zhàn)
非確定性計算包括一些算法，如計劃器，它們可能通過對大量隨機選擇的候選對象的結(jié)果進行排序來工作(例如，概率路線圖計劃器[18])。由于該算法的核心操作是基于候選對象的隨機生成，所以很難進行復(fù)制。雖然在單元測試中使用可重復(fù)的偽隨機數(shù)流等技術(shù)是有用的，但在集成系統(tǒng)中創(chuàng)建完全確定的行為可能是不實際的，特別是在初始條件的微小變化導(dǎo)致系統(tǒng)行為發(fā)散的情況下。這意味著，盡管試圖使用名義上相同的測試用例，但每一次車輛水平測試都可能導(dǎo)致不同的結(jié)果。
成功的感知算法也往往是概率性的。例如，證據(jù)網(wǎng)格框架[19]將來自個體的、不確定的傳感器讀數(shù)的不同證據(jù)累積到一個機器人周圍環(huán)境的越來越模糊和詳細的地圖中。這種方法產(chǎn)生一種可能性，即有一個物體存在，但從不完全可靠。此外，這些算法是基于先前的傳感器物理模型(例如，多路徑返回)和噪聲(例如，在雷達報告范圍內(nèi)的高斯噪聲)，它們本身是概率性的，并且對環(huán)境條件的微小變化很敏感。
除了對周圍環(huán)境的幾何建模外，其他算法還從感知到的數(shù)據(jù)中提取標(biāo)簽。突出的例子包括行人檢測[20]。這樣的系統(tǒng)可以表現(xiàn)出潛在的不可預(yù)測的故障模式，即使是在很大程度上無噪聲的數(shù)據(jù)。例如，視覺系統(tǒng)可能在消除由陰影引起的顏色變化的歧義上有困難，以及在大型反射面存在時，確定物體位置的經(jīng)驗差異。(平心而論，這些都是人類目前面臨的挑戰(zhàn)。)此外，任何分類過程都表現(xiàn)出假陰性和假陽性之間的權(quán)衡，其中一種情況的減少必然導(dǎo)致另一種情況的增多。它的測試含義是這樣的算法不會在100%的情況下工作，并且根據(jù)構(gòu)造它們可能報告一個特定的情況為真，而實際情況為真的概率只有中等大小。
非確定性測試
在測試中處理非確定性是困難的，至少有兩個原因。第一個問題是，在特定的邊緣情況下很難進行操作。這是因為，只有當(dāng)系統(tǒng)接收到來自外界的一個非常特殊的輸入序列時，它才會以激活邊緣情況的方式運行。由于前面討論過的因素，例如計劃者對輸入的微小變化的響應(yīng)可能存在巨大差異，所以很難設(shè)計出一種情況，在這種情況下，世界將可靠地提供正確的條件來運行特定的期望測試用例。
舉個簡單的例子，汽車可能更喜歡在寬闊的馬路上繞行，而不是在狹窄的小巷里抄近路。為了評估在狹窄的巷道中行駛的性能，測試人員需要設(shè)計一種情況，使寬闊的巷道對計劃人員沒有吸引力。但是，這樣做需要對測試計劃進行額外的關(guān)注，并且可能(手動)將車輛移動到它通常不會進入的環(huán)境中來強制執(zhí)行所需的響應(yīng)。測試車輛在兩條幾乎同樣不吸引人的道路中選擇更好的一條而不動搖的能力可能更加困難。
測試中與非確定性的第二個區(qū)別是，評估測試結(jié)果是否正確是不同的，因為對于給定的測試用例沒有唯一正確的系統(tǒng)行為。因此，正確性標(biāo)準(zhǔn)可能必須采用與前面討論的安全信封類似的形式，在安全信封中，如果最終系統(tǒng)狀態(tài)在可接受的測試通過信封中，則測試通過。一般來說，可能需要多個測試來建立系統(tǒng)將總是在測試通過信封中結(jié)束的信心。
概率系統(tǒng)行為對驗證提出了類似的挑戰(zhàn)，因為通過一次測試并不意味著每次都通過測試。事實上，對于概率行為，可以預(yù)期至少某些類型的測試在某些情況下會失敗。因此，測試的目的可能不是確定行為是否正確，而是驗證行為的統(tǒng)計特征是準(zhǔn)確指定的(例如，假陰性檢出率不大于伴隨的安全參數(shù)中假定的率)。這可能需要比簡單的功能驗證多得多的測試，特別是如果所涉及的行為是安全關(guān)鍵的，并且預(yù)期失敗率極低。
要從概率系統(tǒng)中獲得極高的性能，可能需要多個子系統(tǒng)，而在復(fù)合系統(tǒng)中，由于具有完全獨立的故障，因此假定這些子系統(tǒng)能夠提供較低的總體故障率。例如，可以將復(fù)合雷達和視覺系統(tǒng)組合起來，以確保在極低的概率范圍內(nèi)不會遺漏任何障礙物。該方法不僅適用于傳感模式，也適用于規(guī)劃和執(zhí)行中的其他各種算法方案。如果這種方法是成功的，那么很可能導(dǎo)致失敗的概率非常低，因此驗證復(fù)合性能的測試是不可行的。例如，如果兩個系統(tǒng)必須在十億次探測中有一次錯過障礙物，那么必須進行數(shù)十億次有代表性的測試來驗證這種性能。驗證復(fù)合不同算法的非常低的故障率可以通過單獨驗證每個算法的更頻繁的允許故障率來嘗試。但這是不合理的。人們還必須驗證故障之間獨立的假設(shè)，這可能除了測試之外，還必須基于分析。
5 機器學(xué)習(xí)系統(tǒng)
只有正確地做出一系列復(fù)雜的監(jiān)測和控制決策，自動駕駛汽車才有可能做出正確的行為。實現(xiàn)這一目標(biāo)通常需要對參數(shù)進行適當(dāng)?shù)恼{(diào)整，包括從每個相機鏡頭的校準(zhǔn)模型到為避開高速公路上的障礙物而轉(zhuǎn)彎和停車的風(fēng)險權(quán)重的調(diào)整。這里的挑戰(zhàn)是找到校準(zhǔn)模型或權(quán)值之比，使某些誤差函數(shù)最小化。近年來，大多數(shù)機器人應(yīng)用已經(jīng)轉(zhuǎn)向機器學(xué)習(xí)來完成這一任務(wù)[21，22]，因為多維優(yōu)化的復(fù)雜性使得手工工作不太可能產(chǎn)生期望的性能水平。
機器學(xué)習(xí)方法的細節(jié)有很多，例如從演示中學(xué)習(xí)、主動學(xué)習(xí)、監(jiān)督與非監(jiān)督方法。然而，所有這些方法都涉及到歸納學(xué)習(xí)，在歸納學(xué)習(xí)中使用訓(xùn)練實例來推導(dǎo)模型。
例如，考慮在單目圖像中檢測行人的情況。通過使用一組大型訓(xùn)練圖像，分類器可以學(xué)習(xí)一個決策規(guī)則，最小化行人在單獨的驗證圖像集中被檢測到的概率。對于我們的目的，一個基本元素訓(xùn)練集實際上是系統(tǒng)的需求集，而規(guī)則是最終的系統(tǒng)設(shè)計。(機器學(xué)習(xí)算法本身和分類器算法都更適合傳統(tǒng)的驗證技術(shù)。然而，這些都是通用的軟件引擎，最終的系統(tǒng)行為是由用于學(xué)習(xí)的訓(xùn)練數(shù)據(jù)決定的。)
人們可以通過建立一套收集訓(xùn)練數(shù)據(jù)的要求來避免訓(xùn)練集數(shù)據(jù)形成事實需求的問題。但這最終只是把同樣的挑戰(zhàn)推到了抽象的一個層次上。需求不是系統(tǒng)本身的一組功能需求的典型V模型，而是一組訓(xùn)練數(shù)據(jù)的形式或收集訓(xùn)練數(shù)據(jù)集的計劃。如何驗證訓(xùn)練數(shù)據(jù)是一個開放的問題，可以通過對數(shù)據(jù)的特征描述以及數(shù)據(jù)生成或數(shù)據(jù)收集過程進行組合來解決。
驗證歸納學(xué)習(xí)的挑戰(zhàn)
歸納學(xué)習(xí)方法的性能可以通過從已收集的整體數(shù)據(jù)集中保留一些樣本并使用這些樣本進行驗證來測試。假設(shè)如果將訓(xùn)練集用作系統(tǒng)需求（V模型的左邊），則可以使用獨立的驗證數(shù)據(jù)集來確保滿足需求（形成相應(yīng)的V模型右邊）。訓(xùn)練數(shù)據(jù)不能與期望行為無關(guān)，否則系統(tǒng)將變得“過度擬合”。類似地，除了所需的特性之外，驗證數(shù)據(jù)必須與訓(xùn)練數(shù)據(jù)在各個方面都是獨立和不同的，否則在驗證期間將不會檢測到過擬合問題。目前還不清楚，如何證明機器學(xué)習(xí)系統(tǒng)沒有被作為安全論證的一部分過度擬合。
機器學(xué)習(xí)在實踐中的一個重要限制是，如果使用帶標(biāo)簽的數(shù)據(jù)，每個數(shù)據(jù)點都可能很昂貴。(創(chuàng)建標(biāo)簽必須由某人或某事完成。無監(jiān)督學(xué)習(xí)技術(shù)也是可能的，但需要一個聰明的映射來解決特定的問題。)此外，如果發(fā)現(xiàn)了訓(xùn)練集（一個需求缺陷）或規(guī)則學(xué)習(xí)（一個設(shè)計缺陷）的問題并進行了糾正，那么就必須收集更多的驗證數(shù)據(jù)并用于驗證更新后的系統(tǒng)。這是很有必要的，因為即使是對訓(xùn)練數(shù)據(jù)的一個小的改變也會產(chǎn)生一個非常不同的學(xué)習(xí)規(guī)則集。
由于自治系統(tǒng)需求的復(fù)雜性，學(xué)習(xí)問題很可能會在少數(shù)情況下出現(xiàn)。然而，由于它們的稀缺性，收集描述這種不尋常情況的數(shù)據(jù)的成本可能很高，而且難以衡量。(模擬和合成數(shù)據(jù)可以幫助解決這一問題，但同時也存在模擬數(shù)據(jù)存在偏倚的風(fēng)險，以及過度過渡到模擬工件的風(fēng)險。)
驗證機器學(xué)習(xí)的另一個問題是，一般來說，人類不能直觀地理解過程的結(jié)果。例如，卷積神經(jīng)網(wǎng)絡(luò)[23]的內(nèi)部結(jié)構(gòu)可能無法直觀的告訴人類觀察者關(guān)于所學(xué)習(xí)的決策規(guī)則。雖然可能會有一些特殊的情況，但機器學(xué)習(xí)的易讀性問題[24、25]在能夠以人類的方式解釋系統(tǒng)行為方面是無法解決的。除了昂貴的蠻力測試之外，很難預(yù)測其他技術(shù)如何應(yīng)用于機器學(xué)習(xí)系統(tǒng)的驗證。(也許有些組織確實有資源來進行廣泛的蠻力測試。但是，即使在這種情況下，訓(xùn)練數(shù)據(jù)的準(zhǔn)確性、有效性和代表性也必須作為基于機器學(xué)習(xí)系統(tǒng)正確性的安全論證的一部分進行證明。
由于機器學(xué)習(xí)系統(tǒng)的易讀性普遍較差，而且過度擬合的危險是真實存在的，所以在這樣的系統(tǒng)中存在著能夠顯著地影響安全性的故障模式。特別值得關(guān)注的是在訓(xùn)練集數(shù)據(jù)中出現(xiàn)的意外相關(guān)性，但是沒有被人工審閱人員注意到。例如，考慮使用經(jīng)過訓(xùn)練的可變形部分模型在圖像中檢測行人的方法，該方法已被證明在真實的數(shù)據(jù)集[26]中非常有效。如果訓(xùn)練數(shù)據(jù)集中沒有(或很少)出現(xiàn)坐輪椅的行人的圖像，那么這個系統(tǒng)很可能會錯誤地將行人的標(biāo)簽與用兩條腿走路的人聯(lián)系起來。
歸納學(xué)習(xí)的解決方案
眾所周知，由于黑天鵝問題(black swan problem)[27]，確認歸納學(xué)習(xí)是非常困難的。通常，黑天鵝問題指的是一個人(或一個系統(tǒng))很容易相信普遍的觀察結(jié)果是正確的，而由于大量的數(shù)據(jù)點相互關(guān)聯(lián)，可能會得出錯誤的結(jié)論。故事是這樣的。在18世紀(jì)晚期之前，歐洲所有被觀察到的天鵝都是白色的，因此，使用歸納邏輯的觀察者會得出所有天鵝都是白色的結(jié)論。然而，這個觀察者在訪問澳大利亞的時候，會經(jīng)歷這種信念上的打擊，那里有大量的黑天鵝。換句話說，如果系統(tǒng)沒有看到一個特殊的情況，它就不能學(xué)習(xí)那個情況。這是一個基本的限制，歸納學(xué)習(xí)方法是不容易治愈的[28]。此外，隨著機器學(xué)習(xí)的發(fā)展，這個問題會因為可讀性的缺乏而變得更加復(fù)雜，所以人類評論者很難或不可能想象在這樣的系統(tǒng)中，一個類似于黑天鵝的偏見會形成什么樣的形式。
驗證歸納學(xué)習(xí)系統(tǒng)似乎是一個極具挑戰(zhàn)性的問題?？梢允褂脧V泛的測試，但是需要驗證黑天鵝數(shù)據(jù)隨機獨立到達率的假設(shè)，并對相應(yīng)大小的數(shù)據(jù)集進行測試。如果有足夠的資源，這可能是可行的，但總會有新的黑天鵝，因此必須對大量的操作場景和輸入值進行概率評估，以確保系統(tǒng)故障處于可接受的低水平。(如果有足夠的資源以一種合理的方式來做這件事，這可能會形成V過程的右邊。)
將基于低ASIL誘導(dǎo)的算法與基于高ASIL演繹的監(jiān)控相結(jié)合，是驗證高ASIL誘導(dǎo)學(xué)習(xí)系統(tǒng)是否適用于高ASIL水平的另一種選擇。這將回避執(zhí)行算法的大部分驗證問題，因為控制執(zhí)行器的歸納算法的故障將由基于演繹生成的安全包絡(luò)線等概念的無感監(jiān)控器捕獲。因此，執(zhí)行器算法故障將是一個可用性問題(系統(tǒng)安全關(guān)閉，假設(shè)有足夠的故障轉(zhuǎn)移能力)，而不是一個安全問題。
6 關(guān)鍵任務(wù)運行要求
作為一個最終的技術(shù)領(lǐng)域，我們回到前面討論的一點，最終控制車輛的是計算機而不是人。這意味著，至少車輛有一部分系統(tǒng)必須是故障-運行，而不是故障-停止。
故障-運行系統(tǒng)的設(shè)計挑戰(zhàn)
故障-運行系統(tǒng)的設(shè)計已經(jīng)在航空航天和其他領(lǐng)域成功地進行了幾十年，但由于幾個原因仍然存在差異。第一個原因很明顯，必須提供冗余，以便當(dāng)一個組件發(fā)生故障時，另一個組件可以接管。
實現(xiàn)這一點需要至少兩個獨立的、冗余的子系統(tǒng)來實現(xiàn)故障停止行為。反過來，實現(xiàn)一個故障運行系統(tǒng)需要至少三個冗余的任意故障組件，以便在它發(fā)出錯誤輸出而不是在組件級別[29]故障停止的情況下，可以確定這三個組件中的哪個失敗了。對于必須容忍任意故障的系統(tǒng)，可能需要一個包含四個冗余組件的拜占庭容錯系統(tǒng)[30]，具體取決于相關(guān)的故障模型。
冗余的結(jié)構(gòu)根據(jù)設(shè)計方法不同而有所不同，可能包括配置，如帶有投票者的三倍冗余系統(tǒng)，或?qū)29]中的四臺計算機的雙—雙冗余系統(tǒng)使用故障-停止。除了這些方法帶來的明顯開銷之外，還存在一個測試問題，以確保故障檢測和恢復(fù)工作，確保故障的獨立性，并確保在驅(qū)動任務(wù)開始時所有冗余組件都是無故障的。冗余似乎不太可能被避免，但它可能會降低復(fù)雜性和費用提供足夠的冗余，以確保安全。
故障轉(zhuǎn)移
在典型的故障運行系統(tǒng)中，例如飛機，所有的冗余部件基本上是相同的，并且能夠執(zhí)行擴展的任務(wù)。例如，商用飛機通常配置兩個噴氣發(fā)動機，每個噴氣發(fā)動機至少有一個雙冗余計算機控制。如果一個引擎上的計算機對由于通過持續(xù)交叉檢測到的故障而關(guān)閉，就會有另一個獨立的引擎來保持飛機的飛行。即便如此，對發(fā)動機可靠性的要求還是非常嚴(yán)格的，因為飛機在發(fā)動機第一次故障后可能要飛行幾個小時才能到達最近的機場，而發(fā)動機可能會第二次出現(xiàn)故障。它對每臺發(fā)動機都提出了很高的可靠性要求，因此增加了部件成本。
雖然汽車的成本敏感性是出了名的高，但它們確實有一個優(yōu)勢，那就是故障轉(zhuǎn)移所需時間可能很短(例如，將車停在路邊，或者在必要時在行車道上停車)，故障轉(zhuǎn)移任務(wù)的持續(xù)時間以秒而不是小時計算。此外，與完全自主運行相比，停止車輛的故障轉(zhuǎn)移任務(wù)可能具有的功能要少得多。它可以簡化需求復(fù)雜性、計算冗余、傳感器需求和可靠性需求。(作為一個簡單的例子，故障轉(zhuǎn)移任務(wù)控制系統(tǒng)可能不支持變道，這極大地簡化了傳感器需求和控制算法。一些復(fù)雜的方法可能比完全自主汽車更簡單。)因此，設(shè)計具有故障停止主控制器和更簡單的故障運行、故障轉(zhuǎn)移控制器的自動駕駛汽車，在硬件成本和設(shè)計/驗證成本方面都很有吸引力。
也有可能，安全論證不是基于完全自治系統(tǒng)的完美，而是基于完全自治系統(tǒng)有一個探測器，當(dāng)它出現(xiàn)故障或遇到需求缺口時，它能意識到。這將使故障檢測器本身具有高ASIL，但可能允許正常的自主功能具有低ASIL。這種方法可以很好地映射到主自治系統(tǒng)的監(jiān)視器/執(zhí)行器架構(gòu)。故障轉(zhuǎn)移自治還必須以安全的方式設(shè)計，并根據(jù)其復(fù)雜性和計算出的可靠性需求采用適當(dāng)?shù)捏w系結(jié)構(gòu)方法。如果在僅持續(xù)幾秒的短故障轉(zhuǎn)移任務(wù)期間發(fā)生故障的可能性非常低，甚至可以使用單通道故障轉(zhuǎn)移系統(tǒng)。
7 非技術(shù)因素
在部署自主權(quán)方面的一些挑戰(zhàn)是非技術(shù)性的，比如經(jīng)常提到的責(zé)任問題(當(dāng)發(fā)生事故時由誰來負責(zé)?)以及法律通常如何對待車輛的所有權(quán)、運營、維護和其他方面。
對這個主題的深入研究超出了本文的范圍。然而，解決非技術(shù)挑戰(zhàn)很可能會對技術(shù)解決方案產(chǎn)生影響。例如，對于事故重建數(shù)據(jù)的自治系統(tǒng)可能會有法醫(yī)要求。需要對這些數(shù)據(jù)的來源進行仔細分析，以確保正確使用這些數(shù)據(jù)。舉個簡單的例子，假設(shè)一個雷達的探測概率是95%，那么它的輸出可能仍然會被記錄在系統(tǒng)中，根據(jù)是否探測到一個障礙物，這意味著探測的確定性。重要的是要確保法醫(yī)分析考慮到，僅僅因為雷達沒有檢測到行人并不意味著行人不在那里(例如，95%的檢測可能意味著20個行人中有1個實際上不會被檢測到)。
由于自動駕駛汽車固有的復(fù)雜性，以及無法通過測試證明任何接近完美的東西，因此開發(fā)人員很有可能以保證案例的形式創(chuàng)建一個安全保證論點(例如，根據(jù)[31])。這樣的保證論證對于維護和解釋系統(tǒng)的完整性是必要的，并且能夠可信地解釋系統(tǒng)對圍繞不可避免的事故所發(fā)生的事件的響應(yīng)。應(yīng)該解決的一個特殊問題是，確保證據(jù)的完整性，以確定事故是否由于其環(huán)境而合理地不可避免。其他重要的問題將是，事故是否可以認為是由系統(tǒng)需求中的缺陷(例如，培訓(xùn)數(shù)據(jù)中的缺口)、合理可預(yù)見和可避免的設(shè)計缺陷、簡單的心理缺陷或其他可歸因于汽車制造商的原因引起的
8 故障注入
從前面的討論中可以明顯看出，傳統(tǒng)的功能測試在運行一個完整的系統(tǒng)時會遇到困難，尤其是在不尋常的操作條件下，很難運行異常的組合。雖然測試人員可以防御一些不符合標(biāo)準(zhǔn)的測試用例，但是由于異常、操作場景和其他相關(guān)因素的組合爆炸，測試的可伸縮性是有問題的。此外，研究表明，即使是非常優(yōu)秀的設(shè)計師也常常會在相對簡單的軟件系統(tǒng)[32]中發(fā)現(xiàn)盲點，從而錯過一些特殊的情況。
故障注入和魯棒性測試是比較成熟的評估系統(tǒng)在[33]異常條件下性能的技術(shù)，可以幫助設(shè)計人員和測試人員在測試異常條件響應(yīng)時避免盲點。傳統(tǒng)的故障注入包括將位翻轉(zhuǎn)插入內(nèi)存和通信網(wǎng)絡(luò)。最近的技術(shù)已經(jīng)提高了抽象級別，包括基于數(shù)據(jù)類型的故障字典[32]，并確保了故障的代表性[33]。這種技術(shù)已經(jīng)成功地用于自動駕駛車輛[35]缺陷的發(fā)現(xiàn)和表征。
幫助驗證自治特性的一個很有前途的方法是在組件的抽象級別上執(zhí)行錯誤注入，這是試圖偽造安全[36]聲明的策略的一部分。這不僅涉及到模擬初級傳感器輸入的對象，還涉及到插入異常條件來測試系統(tǒng)的健壯性(例如，將無效數(shù)據(jù)插入到地圖中)。進行這種故障注入的目的不是驗證功能，而是探測可能在不可預(yù)見的情況下被激活的弱點。這種故障注入可以在ISO 26262 v模型的范圍內(nèi)進行。
9 總結(jié)
根據(jù)V模型開發(fā)安全的自動駕駛汽車的挑戰(zhàn)是重大的。然而，確保車輛安全仍然需要遵循ISO 26262 V模型，或者證明一套同樣嚴(yán)格的過程和技術(shù)實踐已經(jīng)得到應(yīng)用。假設(shè)應(yīng)用了V模型，有三種通用的方法看起來很有前途。
分階段部署
開發(fā)和部署一輛能夠在不受限制的真實環(huán)境(包括特殊情況)中處理所有可能的場景組合的自動駕駛汽車似乎是不切實際的。相反，正如汽車系統(tǒng)中常見的那樣，基于當(dāng)前開發(fā)人員實踐的分階段部署方法似乎是一種合理的方法。
將階段部署綁定到V流程可以通過識別指定良好的操作概念來限制操作范圍，從而限制必要的需求范圍來完成。它將包括環(huán)境、系統(tǒng)健康狀況和操作約束方面的限制，必須滿足這些限制才能進行自主操作。確認這些操作約束是強制的，這將是確保安全性的一個重要部分，并且必須作為一組操作需求、驗證和潛在的運行時強制機制出現(xiàn)在V流程中。例如，運行時監(jiān)控不僅可能需要監(jiān)控系統(tǒng)狀態(tài)是否允許自治權(quán)，而且假設(shè)關(guān)于安全的操作場景參數(shù)實際上是被滿足，以及是否操作場景的系統(tǒng)實際上是它認為。
需要特別注意的受限操作概念的一個方面是，確保在操作場景突然失效(例如，由于意外天氣事件或基礎(chǔ)設(shè)施故障)時維護安全性。從可接受的操作概念體系中進行的此類異常轉(zhuǎn)換將要求成功地執(zhí)行系統(tǒng)恢復(fù)或故障轉(zhuǎn)移任務(wù)，即使系統(tǒng)偏移超出了允許的自治操作場景的假設(shè)。
目前還不清楚分階段部署方法是否會提供一條通往完全自治的道路。但是，至少這種方法提供了一種取得進展和獲得自治的一些好處的方法，同時可以更好地理解不同的邊界情況和隨著系統(tǒng)更多地暴露于現(xiàn)實世界條件而出現(xiàn)的未預(yù)料到的場景。
監(jiān)控器/執(zhí)行器架構(gòu)
一種可能有助于減輕自動駕駛汽車安全的許多挑戰(zhàn)的常見方法是使用監(jiān)視器/執(zhí)行器架構(gòu)。正如前面所討論的，這種架構(gòu)風(fēng)格可以幫助解決需求復(fù)雜性(只有監(jiān)控器需要是非常完美的)和歸納算法的部署(通過限制對執(zhí)行器的使用，并使用基于演繹的監(jiān)控器)。
此外，故障轉(zhuǎn)移任務(wù)策略的使用可以允許主自治系統(tǒng)監(jiān)視器檢測主系統(tǒng)故障，而不必確保故障操作行為。一個更簡單、高度完整的自動故障轉(zhuǎn)移系統(tǒng)可以使車輛進入安全狀態(tài)。這樣的系統(tǒng)可能具有足夠短的故障轉(zhuǎn)移任務(wù)，因此需要最小的故障轉(zhuǎn)移操作冗余，只要能夠確保在啟動故障轉(zhuǎn)移任務(wù)時系統(tǒng)是無故障的。
故障注入
為了確保系統(tǒng)的超可靠性，單獨進行測試是不可行的。自動駕駛汽車只會讓這個問題變得更加困難，因為它會自動地對高度復(fù)雜的環(huán)境心理狀況做出反應(yīng)，還會引入機器學(xué)習(xí)等技術(shù)，而這些技術(shù)測試起來既復(fù)雜又昂貴。此外，由于大部分的自動駕駛能力必須有較高的ASIL由于缺乏人類駕駛監(jiān)督，它似乎很難做足夠的普通系統(tǒng)測試，以獲得甚至一個合理的水平的保證。
作為驗證策略的一部分，故障注入可以發(fā)揮有用的作用，該策略還包括傳統(tǒng)的測試和非基于測試的驗證。如果將故障注入應(yīng)用于多個抽象級別，而不是僅應(yīng)用于固定的電子連接器級別，則尤其如此。
未來的工作
本文討論了在基于ISO 26262的V框架下實現(xiàn)自動駕駛汽車安全保障的方法。但是，使用諸如監(jiān)視器/執(zhí)行器方法之類的體系結(jié)構(gòu)模式和通過故障注入可能實現(xiàn)的驗證的實際限制將對操作性能造成限制。換句話說，自動駕駛汽車的功能可能需要受到限制，以適應(yīng)可行驗證技術(shù)的約束。放松這些限制將需要在一些領(lǐng)域取得進展，例如與預(yù)期的操作環(huán)境相比，確定機器學(xué)習(xí)培訓(xùn)數(shù)據(jù)的覆蓋范圍，對特殊駕駛條件下的安全要求有足夠的信心，能夠驗證冗余感應(yīng)型系統(tǒng)故障的獨立性。
廣告 編輯推薦
最新資訊
-
開年豪擲1.8億搶用戶，又一車企加入“價格
2026-03-04 16:05
-
聯(lián)合國法規(guī)R60對兩輪車操縱件與指示裝置的
2026-03-04 12:08
-
標(biāo)準(zhǔn)立項|《汽車異種材料鉚接接頭拉伸性能
2026-03-04 11:40
-
“汽車大角度座椅 第1部分：通用要求”將有
2026-03-04 11:39
-
“汽車大角度座椅 第2部分：可靠性要求”將
2026-03-04 11:39
