“整個行業(yè)的自動駕駛系統(tǒng)量產(chǎn)時間節(jié)點延遲了，因為在那個節(jié)點上要有一個車規(guī)級的域控制器。行業(yè)內(nèi)原定的是2021年的第一季度（實現(xiàn)自動駕駛量產(chǎn)）?，F(xiàn)在普遍都延后了一年或一年半?！北葋喌现悄荞{駛首席專家王歡近日接受雷鋒網(wǎng)新智駕專訪時表示。

域控制器是指自動駕駛汽車的計算平臺，相當于車載大腦。在王歡看來，近年來計算平臺相對系統(tǒng)的發(fā)展速度是落后的，由于缺少滿足車規(guī)級的自動駕駛域控制器，導致大部分主機廠和供應商在開發(fā)時只能暫時冷處理，將整個量產(chǎn)的時間節(jié)點向后推遲。

雷鋒網(wǎng)新智駕了解到，汽車產(chǎn)品標準分為消費規(guī)、工規(guī)和車規(guī)。其中車規(guī)是級別最高的，需要通過抗沖擊性、振動性、防火和高低溫等實驗。同時作為智能駕駛功能安全，汽車產(chǎn)品必須滿足ISO26262標準。

誰能率先推出車規(guī)級自動駕駛域控制器？關(guān)鍵或許在于客戶群體。

王歡認為，由于大陸、博世擁有龐大客戶群體，所以向客戶推送時會更加方便。華為在做生態(tài)，由于體積大、聯(lián)盟伙伴多，推起來可能也會更加容易，但創(chuàng)業(yè)公司面臨的困難可能會比較多。

除了域控制器，實現(xiàn)自動駕駛量產(chǎn)還涉及到一些研發(fā)模式等問題。比如，對于許多公司采取的在改裝量產(chǎn)車上進行方案論證的模式，主機廠會認為它并非量產(chǎn)的正確模式。

據(jù)王歡介紹，面對復雜的自動駕駛，主機廠需要有正向的開發(fā)模式、驗證體系、自動駕駛系統(tǒng)架構(gòu)等。

他在一次名為《自動駕駛開發(fā)升級》的主題演講中重點介紹了這些量產(chǎn)要求。以驗證體系為例，自動駕駛對于開放道路測試數(shù)據(jù)、人機交互、評價維度和系統(tǒng)架構(gòu)均有著迫切需求。而且，這些需求與傳統(tǒng)汽車有著根本區(qū)別。

附：

王歡的演講全文，雷鋒網(wǎng)新智駕進行了不改變原意的編輯：

今天我站在主機廠的角度，分享一些自動駕駛開發(fā)升級過程中面臨的問題。

眾所周知，自動駕駛的開發(fā)模式主要分兩種，一種是以Waymo為代表的科技公司主導的跨越式開發(fā)模式，一種是以特斯拉以及其他主機廠主導的漸進式開發(fā)模式?？缭绞介_發(fā)模式是指跨過L3，直接研究L4級自動駕駛。漸進式開發(fā)模式主要指以傳統(tǒng)的ADAS技術(shù)為基礎(chǔ)，慢慢過渡到L3、L4。這兩大陣營在開發(fā)工作項目中也有緊密的合作，一些算法公司、傳感器巨頭都參與到了合作當中。

無論是L3還是L4，行業(yè)內(nèi)都遵循著這樣的原則：首先要找出自動駕駛的落地點，然后分析這些落地點的場景，基于場景開發(fā)功能。或者沿著反方向，從場景功能倒推落地點。

如果自動駕駛適合的場景非常少，邊界非常窄，對汽車的安全貢獻就會非常小，甚至由于運行過程中超出邊界而發(fā)生危險，那么，它就是不安全的。同理，如果駕駛場景邊界特別寬，現(xiàn)在的技術(shù)又不能全面分析它的安全性，那么，這種場景也是比較危險的。

總結(jié)看，自動駕駛就是要確定合理的場景，并且設定科學的安全目標來進行開發(fā)，行業(yè)也都是按照這個流程來做的。大家會逐漸地把功能開發(fā)聚焦到幾個方面，以L3和L4舉例，它們包括HWP、TJP和AVP等，這個過程中有大量的方案論證，經(jīng)過大量的驗證，然后展示，再示范運營，最后收集數(shù)據(jù)進一步優(yōu)化算法。

其實在主機廠看來，這種模式基本上量產(chǎn)不了，原因很簡單，量產(chǎn)的過程比這復雜得多。因為量產(chǎn)自動駕駛是一項很龐大的工作，投入會很大，時間也會很長，車廠還要和一些公司建流程、出標準等等。所以說大家之前做的工作意義很大，但是還不夠。

對于這種復雜的開發(fā)，我們迫切地需要對原始的開發(fā)流程進行升級，不僅要有一個正向的開發(fā)模式，還要有一個驗證體系。此外，由于現(xiàn)在的開發(fā)都是類似于后裝的車改制的方式，所以還需要一個自動駕駛系統(tǒng)架構(gòu)。最后，人機交互和車輛平臺也是非常重要的。

關(guān)注預期功能安全

自動駕駛是以車為中心的車輛系統(tǒng)，所以還是要遵循V流程開發(fā)模式，在開發(fā)過程中要借鑒傳統(tǒng)的標準。一些標準比如說ISO21448，它只針對L1、L2而不針對L3，但是沒有關(guān)系，我們可以借鑒里面的思想，然后擴展標準里的開發(fā)流程。

主機廠更注重什么？首先是預期功能安全，它關(guān)系到能否解決場景的問題。甚至可以說，產(chǎn)生自動駕駛危險更多的是因為場景不足，而不是系統(tǒng)的不安全。預期功能安全這個標準主要關(guān)心四個范圍。范圍一是已知的安全場景。范圍二是已知的不安全場景，范圍三是未知的不安全場景，范圍四是未知的安全的場景。

很明顯，我們的重點是在范圍二和范圍三，怎么樣用一切辦法縮小它們的范圍很重要。

首先，必須要有一個場景庫，場景庫是任何一個開發(fā)團隊的核心數(shù)據(jù)庫。通過場景庫，找到一些不合理或者是不安全的場景，針對這些場景提供安全措施，通過驗證安全措施的方式，最終達到安全目的。當安全目標都能夠滿足范圍二的范圍標準的時候，主機廠就可以接受了。針對范圍三，對于未知的不安全的因素怎么考慮，其實對這個問題，可能到現(xiàn)在我們的行業(yè)都沒有一個有效的方法，都是按照完整分析測試來實現(xiàn)的。所謂的完整分析，其實是對于一個基礎(chǔ)場景進行排列組合的分析，對它所有的可能出現(xiàn)的狀態(tài)進行分析。

然后是功能安全標準ISO26262，這個標準已經(jīng)比較成熟，但在L3自動駕駛上的分析還是比較新穎的，可能目前來看，還沒有更全面的分析經(jīng)驗。

針對L3級別以上的自動駕駛與傳統(tǒng)的ADAS等級的功能安全的區(qū)別在哪？在L3的開發(fā)過程中，我們進行安全分析時目標和對象會更龐大。比如，基于V2X的HWP功能進行分析，當我們進行分析時，除了對車進行分析，還要對通訊接口、路邊設備已經(jīng)云端服務器進行分析，這是自動駕駛功能安全需要額外考慮的問題。

信息安全方面，自動駕駛要解決的問題是怎么抵抗黑客攻擊和網(wǎng)絡攻擊。在整個行業(yè)內(nèi)，信息安全幾乎沒有一家能夠獨自完成。為什么？因為一旦車聯(lián)網(wǎng)以后，它能夠被攻擊的接口太多了，有網(wǎng)關(guān)、T-BOX、V2X、第三方的云、主機廠的云、手機APP、車機、充電樁等等，甚至包括自動駕駛傳感器及系統(tǒng)本身，這些都會受到信息安全帶來的挑戰(zhàn)，所以需要各方合作。

針對車端，我們在信息安全上應該關(guān)注以下幾點，一是怎么驗證外來數(shù)據(jù)的完整性、真實性和信號來源的可靠性，一旦車輛有危險，這個危險不至于擴張到其他車輛上，要在網(wǎng)絡安全上有一個縱深的防御，以及一旦有解決措施的時候怎么升級。

無論信息安全還是功能安全，最終的落腳點都是車，如果車不動，發(fā)的信息車不執(zhí)行，那就是安全的，所以功能安全和信息安全之間有某種聯(lián)系。

在開發(fā)的過程中，怎么判斷這種關(guān)系，將他們聯(lián)系在一起？首先我們要定義一個安全指標，并且對這種安全指標進行策略分析，分別執(zhí)行兩件事，一個是功能安全，一個是信息安全，這一流程應該可以把功能安全和信息安全聯(lián)系在一起。

以上這幾個安全，包括V流程的一些開發(fā)，是主機廠面臨開發(fā)升級所面臨的挑戰(zhàn)。

如何驗證

接下來談一下驗證過程。傳統(tǒng)的ADAS開發(fā)有很多地方可供借鑒，但是它和自動駕駛的深度和廣度完全不是一個數(shù)量級的。智能駕駛更關(guān)心的數(shù)據(jù)，或更難拿到的數(shù)據(jù)是開放道路測試數(shù)據(jù)，這是有實際意義的，而且是必須要有的。

然后是人機交互，這也是驗證過程中的重頭戲。整個驗證過程的工作量是非常大的，是每個主機廠的核心工作。問題的關(guān)鍵點不僅在于怎么測試，還在于怎么通過一個評價體系把這些東西串在一起。

要引入我們虛擬測試的自動化，只有自動化才能夠滿足我們對這種工況的分析的條件。

分析結(jié)果后怎么評價，我在這里給出幾個維度的建議，一是安全度，一是舒適度，車與車之間的交互等等一些因素。以安全度為例，主要是碰撞，碰撞的程度怎么樣，碰撞之后車輛的表現(xiàn)如何。我們會發(fā)現(xiàn)，每個主機廠對自動駕駛的理解是不同的。

下面談一下主機廠更關(guān)心的系統(tǒng)架構(gòu)。

大家的前期開發(fā)都是基于量產(chǎn)車的改裝，屬于后裝形式，成本也很高，這時就急需一種正常的智能駕駛架構(gòu)。要搭建這種架構(gòu)的前提是針對什么樣的功能?；旧希δ芸梢苑譃閮纱箢?，一個是Fail-safe，一個是Fail-degrade，這些功能分別包括定位、感知、警醒等。

針對這些功能的架構(gòu)，我們可以給出一個架構(gòu)體系，就是傳感器的輸出到主輔控制器的工作模式，主輔控制器的工作受到安全監(jiān)控這個模塊的宏觀調(diào)控，再決定是由主控制器來控制，還是輔控制器來控制，這是行業(yè)比較認可的一種架構(gòu)。當然這里面沒有提到通訊和電源的冗余，正常情況是要考慮到的。

其實在架構(gòu)方面，主機廠更關(guān)注的不是架構(gòu)怎么實施，而是更關(guān)心域的概念。為什么說域是未來趨勢？因為L3的特點就是功能集成和信息共享。

這個功能集成是指控制器必須有L1和L2的功能，也包含L3的功能，現(xiàn)在的車上既然已經(jīng)有了L1和L2的功能了，如果控制器只有L3的功能，意味著車的成本是增加的。那么，為什么不能用強大的計算力，在L3的控制器把L1和L2一起都做了呢？在項目的開發(fā)過程中，其實能夠提供這種解決方案的人也比較少。

對于未來的OTA軟件升級，包括降低成本和輕量化，其實主機廠對于這種體系架構(gòu)有迫切的需求。

域的概念有一個好處就是功能集成。近年來行業(yè)里提出來一個架構(gòu)，就是以車輛的物理空間為基礎(chǔ)的域，比如它可以控制雷達、應急車燈。像這種域很明顯，它的布線就比較簡單，但是它對軟件架構(gòu)要求非常嚴，這種域在特斯拉的Motel3上已經(jīng)量產(chǎn)了。

然后是人機交互。在L3上，已經(jīng)不僅僅是人機交互那么簡單的事情，而是和安全甚至控制有密切的關(guān)系。傳統(tǒng)汽車的人機交互大部分基于人對汽車信息的監(jiān)控，L3、L4之后，汽車要監(jiān)控人的信息，這是有著天壤之別的。

所以針對人機交互的開發(fā)是不容小覷的。駕駛員在接管了自動駕駛之后的表現(xiàn)怎么樣，他慌不慌張，他迷不迷茫。另外一點就是車在接管之后，它的功能表現(xiàn)怎么樣，不同的車輛之間的替換，不同安全等級之間的切換，尤其是L2和L3，因為L2也控制縱向橫向，L3也控制縱向橫向，駕駛員容易混淆，以上的這幾點加在一起，就需要有一個行業(yè)上統(tǒng)一的HMI標準，這正是我們需要的。

同時還有一些其他的標準，包括乘客上下車的交互和場景的交互等。場景的交互主要是指車和車，包括L4的遠程控制等等。另外，人機交互還必須有關(guān)于漏報和誤報的指標，不能總發(fā)生狼來了事件。

最后談一下車輛平臺，L3以上的自動駕駛開放平臺和傳統(tǒng)的車輛平臺之間的差別在哪，我認為主要體現(xiàn)在，傳統(tǒng)汽車上，駕駛員在駕駛的時候，要求舒適性、操控性和安全性，但是在自動駕駛系統(tǒng)控制時，問題就來了，我們稱這個車是Fail-degrade的，是雙備份冗余的。

這個雙備份冗余指的是執(zhí)行層面，包括制動、轉(zhuǎn)向和電源等等，以及自動駕駛對車輛指令的響應，對響應性要求是很高的。另外就是車輛動力學的性能，發(fā)出一條指令之后的運動應該是線性的，不能是非線性的。

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。