從自動駕駛重卡落地，希迪智駕看系統架構標準問題|2019全球智能駕駛峰會

雷鋒網新智駕按：10月26日至27日，2019第二屆全球智能駕駛峰會暨長三角G60科創走廊智能駕駛產業峰會在蘇州高鐵新城正式舉行。峰會主要聚焦“自動駕駛的量產時代、單車智能和車路協同的共演之路、新型的車內交互探索”三大主題，共同探討了智能駕駛的未來發展方向。

本次峰會由蘇州市相城區人民政府主辦，蘇州高鐵新城管理委員會、雷鋒網新智駕承辦，江蘇省智能網聯汽車產業創新聯盟、江蘇省人工智能學會智能駕駛技術專業委員會、清華大學蘇州汽車研究院、中國移動通信集團等單位協辦。來自主機廠、國內外一級供應商、自動駕駛解決方案商、自動駕駛核心零部件、出行運營商等智能駕駛上下游企業，車路協同專家學者、代表企業等1500余位業內人士蒞臨現場。

大會現場，希迪智駕工程副總裁黃英君發表了《智能網聯助力重卡自動駕駛應用場景實踐》的主題演講，主要介紹了智能重卡商用落地的情況。黃英君表示，自動駕駛在場景落地方面或多或少都會碰到一些問題。目前更多的挑戰在于計算平臺和系統架構層面，這體現在配套開發工具鏈是否足夠可靠，成本是否可以承受等等。

黃英君認為，自動駕駛仍處于群雄并起時代，系統架構并無統一標準。每個系統都有自己的操作性問題，以智能重卡來說，一個車型面臨的具體場景也已經十分復雜。由于每種場景所適用的感知算法、決策和規劃算法差距非常大，因此很難有一套滿足所有場景的通用L4級自動駕駛架構。

此外，主機廠非常注重成本控制。汽車行業不景氣，影響最大的是供應商。以計算平臺為例，越來越多的解決方案都會采用異構的多域控制器方案，目前汽車行業在這L2以下的控制器軟件開發技術已經非常成熟。但目前大規模應用的控制器有限的算力限制導致無法支持更高級別自動駕駛，最多能做L2，到L2+算力已經不足。

以下為黃英君演講全文，雷鋒網新智駕進行了不改變原意的編輯：

我今天主要分享希迪智駕通過智能網聯助力重卡進行場景落地的內容。我之所以提“落地”，是因為還沒有達到量產的階段，很多方面目前正處于爬坡階段。

在場景落地上，自動駕駛或多或少會碰到一些問題，我們稱之為難點、挑戰或者是痛點。希迪智駕內部正在召開全體吐槽大會，從零部件、線纜、安裝、軟件框架，到編碼規范，各個方面都讓大家吐槽。目前為止，我們已經收到了20頁吐槽。

首先是傳感器。不管是激光雷達還是攝像頭，都非常復雜，今天不做展開討論，上半年希迪智駕花了好幾個月時間在我們的平臺上來調一款定制設備的同步驅動。

今天我想著重分享一下計算平臺和系統架構落地時碰到的一些問題，以及相關的解決方案。自動駕駛計算平臺里每個架構師碰到都會碰到的問題是，應該使用什么樣計算平臺？能不能給提供足夠的算力？配套開發工具鏈是否充分？可靠性如何？對于價格內部和商業合作伙伴能不能承受？最后是供貨問題，看起來雖然簡單，但最后實際操作時反而是最困難的，因為這超出了我們的掌控范圍。很多好的設備和芯片只有大的主機廠才能拿到，一般供應商很難拿到，或者說很難用量產的價格拿到設備。

從系統架構來看，我認為自動駕駛還是處于一個群雄并起的時代，并沒有完全統一的標準。因此這也給我們的架構師帶來一些困惑，要么選用一個架構進行參考設計，要么完全自己解決平臺硬件與軟件架構的問題。

目前L4級自動駕駛方案大多都是基于C&C（計算機和網絡）的分布式體系，涉及大量的數據交換，更多采用網絡模式。在數據交換時，在應用層功能軟件之下離不開通信中間件的支持。目前幾種通信中間件我們都用過，一種是廣泛使用的Ros，它提供的調試工具非常多，而且也是開源的，很多平臺和設備廠家都支持。ROS但在時間響應的確定性上存在先天不足。Ros2.0采用DDS方式有很大改進，但是應用在汽車上還是有一些缺陷的。

百度阿波羅開放的CyberRT也是一個很好的中間件，在調度效率和可靠性方面有獨到之處，在Apollo中已經全面應用，完全脫離的ROS。最后就是商用中間件，如RTI DDS。一般航空航天，包括部分車企也會用這樣的中間件。選擇種類多是一個優點，但同時也在量產過程中會造成一些彼此不兼容的問題。

其次在操作性上，每個系統都有自己的問題。即便希迪智駕專注于重卡車型，但面臨的具體場景變化也非常多，如專用道路場景、專用場區場景、港口場景、礦區場景、跨口岸編隊場景。每種場景的感知算法，決策和規劃算法差距非常大，很難有一套適合所有這些場景的通用全棧L4級自動駕駛架構，因此要針對具體場景甚至是具體車型進行定制化設計與部署。如何提高定制效率，如定制時算法的切換、功能裁剪、設備適配，實現基礎解決方案能夠迅速、低成本的來適應不同場景、適應不同芯片/平臺，都是要解決的問題。

最后難點來自于主機廠和用戶。汽車行業非常講究成本，目前業內的看法是，今年以來汽車行業不太景氣，受影響最大的還是零部件供應商。自動駕駛方案供應商也必須要面對設備成本的問題。

目前業內已經普遍接受的觀點就是，未來的汽車一定是軟件定義的汽車，軟件在汽車中占的地位越來越重要。個人認為自動駕駛方案供應商與汽車零部件供應商在架構上是有非常顯著的差異的，車企廣泛使用控制器（MCU、VCU）進行功能開發，特點是用量非常大，一輛車上可以有幾十個乃至上百個，價格便宜，算力很低，以控制功能為主，一般是單核，新一代的控制器已經有三核CPU。

這種控制器的優點在于，它有非常完善的工具鏈，用于開發軟件都有非常明確的標準，如已經被汽車行業廣泛接受的autosar，但是有限的算力導致無法支持更高級別的自動駕駛，最多只能做L2級，甚至L2+需要的算力都不太能夠滿足。

與此同時，在很長的一段時間內，L4級自動駕駛基本都是PC方案。幾個著名的開源框架，如autoware，Apollo，都是PC機+ubuntu的架構。Apollo系統推薦的設備是專用的車載工控機，已經是目前能夠可用的最好的計算設備，支持雙顯卡，算力很好，功耗比較高，放在卡車上進行功能開發與驗證足夠，但是長期運行則是有很多隱患。

根據我們的體驗，一般半年左右就會出現各種各樣的可靠性方面問題，比如硬盤震壞，顯卡接觸不良，溫度過高都會導致顯示失靈等，也不支持休眠、喚醒、自我診斷、看門狗等汽車功能軟件所必須的這個功能開發。還有就是系統的集成、布線方面，工控機與汽車專用的線束是不兼容的，需要各種各樣的轉接，各種插口和轉接口的可靠性是維護工程師的噩夢。在展會現場看過各種各樣的自動駕駛解決方案，很多設備艙都是比較凌亂，從某種意義上來說，從設備艙的凌亂程度就可以判斷這家公司的方案技術水平情況。

計算平臺的問題解決依賴于汽車芯片公司的進展。目前芯片這方面很多公司都在開展工作。自動駕駛車輛計算平臺有非常苛刻的要求，不同的功能模塊方案要用于不同的冗余方式。系統架構師最關注的是軟件架構、基礎軟件組件、確認的內核調度時間、端到端時延、開發工具鏈這些方面。

汽車軟件開發，要求遵循功能安全規范，如ISO 26262（對應的國標為GBT34590）。功能安全在嵌入式軟件開發方面有專門的規范，比如很簡單的一個規定就是要能夠隨時檢測故障，必須具備診斷功能。檢測故障之后，要能夠進行系統降級，自動駕駛汽車軟件必須實現這點。

一個好的計算平臺，應該能夠在功能軟件、基礎組件、設備驅動方面進行很好的分層，在設備層和基礎組件層提供診斷功能，這樣可以降低功能軟件開發的復雜度，使得自動駕駛方案供應商更專注于功能軟件和預期功能安全方面的開發。這種模式在傳統的控制器軟件開發方面已經非常成熟，autosar標準已經被廣泛接受，功能軟件開發商和基礎組件開發商的分工非常明確，所以主機廠和零部件供應商進行功能開發和更新的效率非常高。但這樣的模式在L4級自動駕駛領域還沒有很好的實踐。

最近發布的華為MDC平臺是一個很好的開端，這個平臺提供完整的autosar工具鏈，基于這個標準，自動駕駛企業可以專注于功能軟件開發，基礎組件的工作由平臺供應商提供，能夠實現軟件的基于配置的快速部署。

主機廠對軟件有很多要求，其中一個就是控制器要有多種選擇， 在autosar體系中，控制器的細節是被封裝的，功能軟件開發商基本不需要面對控制器的差異。這也是L4級自動駕駛供應商所希望的實現方式。

最后簡單介紹一下希迪智駕的幾個實踐案例，第一個是低成本的專用道路自動駕駛，使用的方案是用V2X路側感知，使用5RIV的感知方案，遵循autosar標準進行開發，基于V2V的支持進行編隊行駛，樣車已經研制完畢，進行了大量的測試和驗證。

第二個案例是重型工程車輛，使用11V+3L+5R+18S的感知方案，具備完整的多重冗余的感知和決策能力，能夠適應無差分信號、GPS信號干擾、無標準化道路等各種復雜場景。

我們的自動駕駛解決方案是維護一個不斷迭代演進的L4級解決方案，我們已經全面采用autosar架構，構建我們的自動駕駛解決方案，通過配置來部署，能夠快速裁剪適配各種定制場景，實現L2~L5的同架構平滑演進。

迪智駕基于全新平臺架構的樣車已經推出，這是一個基于量產的國產計算平臺，遵循autosar標準的可量產方案，通過了開放道路測試規程的考核，已經開始在開放道路（長沙時繞城高速）進行路測。

雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。