比亞迪王歡:自動駕駛卡在域控制器環節 量產或將延后至2022年

時間:2019-07-29

來源:雷鋒網

0

導語:“整個行業的自動駕駛系統量產時間節點延遲了,因為在那個節點上要有一個車規級的域控制器。行業內原定的是2021年的第一季度(實現自動駕駛量產)?,F在普遍都延后了一年或一年半?!北葋喌现悄荞{駛首席專家王歡近日接受專訪時表示。

“整個行業的自動駕駛系統量產時間節點延遲了,因為在那個節點上要有一個車規級的域控制器。行業內原定的是2021年的第一季度(實現自動駕駛量產)。現在普遍都延后了一年或一年半。”比亞迪智能駕駛首席專家王歡近日接受專訪時表示。

比亞迪王歡:自動駕駛卡在域控制器環節 量產或將延后至2022年

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

汽車產品標準分為消費規、工規和車規。其中車規是級別最高的,需要通過抗沖擊性、振動性、防火和高低溫等實驗。同時作為智能駕駛功能安全,汽車產品必須滿足ISO26262標準。

誰能率先推出車規級自動駕駛域控制器?關鍵或許在于客戶群體。

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

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

據王歡介紹,面對復雜的自動駕駛,主機廠需要有正向的開發模式、驗證體系、自動駕駛系統架構等。

他在一次名為《自動駕駛開發升級》的主題演講中重點介紹了這些量產要求。以驗證體系為例,自動駕駛對于開放道路測試數據、人機交互、評價維度和系統架構均有著迫切需求。而且,這些需求與傳統汽車有著根本區別。

附:王歡的演講全文

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

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

無論是L3還是L4,行業內都遵循著這樣的原則:首先要找出自動駕駛的落地點,然后分析這些落地點的場景,基于場景開發功能?;蛘哐刂捶较?,從場景功能倒推落地點。

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

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

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

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

關注預期功能安全

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

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

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

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

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

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

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

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

無論信息安全還是功能安全,最終的落腳點都是車,如果車不動,發的信息車不執行,那就是安全的,所以功能安全和信息安全之間有某種聯系。

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

以上這幾個安全,包括V流程的一些開發,是主機廠面臨開發升級所面臨的挑戰。

如何驗證

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

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

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

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

下面談一下主機廠更關心的系統架構。

大家的前期開發都是基于量產車的改裝,屬于后裝形式,成本也很高,這時就急需一種正常的智能駕駛架構。要搭建這種架構的前提是針對什么樣的功能。基本上,功能可以分為兩大類,一個是Fail-safe,一個是Fail-degrade,這些功能分別包括定位、感知、警醒等。

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

其實在架構方面,主機廠更關注的不是架構怎么實施,而是更關心域的概念。為什么說域是未來趨勢?因為L3的特點就是功能集成和信息共享。

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

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

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

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

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

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

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

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

低速無人駕駛產業綜合服務平臺版權與免責聲明:

凡本網注明[來源:低速無人駕駛產業綜合服務平臺]的所有文字、圖片、音視和視頻文件,版權均為低速無人駕駛產業綜合服務平臺獨家所有。如需轉載請與0755-85260609聯系。任何媒體、網站或個人轉載使用時須注明來源“低速無人駕駛產業綜合服務平臺”,違反者本網將追究其法律責任。

本網轉載并注明其他來源的稿件,均來自互聯網或業內投稿人士,版權屬于原版權人。轉載請保留稿件來源及作者,禁止擅自篡改,違者自負版權法律責任。

如涉及作品內容、版權等問題,請在作品發表之日起一周內與本網聯系,否則視為放棄相關權利。

關注低速無人駕駛產業聯盟公眾號獲取更多資訊

最新新聞