近年來，隨著智能駕駛的興起，傳統(tǒng)的汽車電子開發(fā)模式已不再適用于智駕的系統(tǒng)開發(fā)場景，基于智能駕駛中間件的開發(fā)模式成為突破口。2023年9月21日，在2023第三屆智能汽車域控制器與中央計算平臺創(chuàng)新峰會上，華玉通軟聯(lián)合創(chuàng)始人兼CTO李堅表示，通過面向智能駕駛芯片以及上層軟件需求開發(fā)的基礎軟件/中間件，可以讓智能駕駛的系統(tǒng)開發(fā)成本得到極大的降低，同時縮短開發(fā)周期，提高軟件的可靠性。

李堅 ｜華玉通軟聯(lián)合創(chuàng)始人兼CTO

以下為演講內容整理：

在傳統(tǒng)的汽車電子控制開發(fā)的模式中，使用基于AUTOSAR CP的中間件進行開發(fā)已經成為行業(yè)中主流的開發(fā)模式。隨著智能駕駛的興起，雖然其在應用的需求以及應用所使用的技術和傳統(tǒng)的汽車電子控制是截然不同的兩個領域，但它的系統(tǒng)規(guī)模更加復雜。因此在智能駕駛的場景中，基于基礎軟件或者基于中間件的開發(fā)模式仍然是非常必要的。通過基礎軟件，我們可以讓智能駕駛的系統(tǒng)開發(fā)成本得到極大的降低，縮短開發(fā)周期，提高軟件的可靠性。

面向智能駕駛的基礎軟件/中間件行業(yè)目前仍處于發(fā)展期，技術壁壘很高。不論是ADAS輔助智能駕駛的應用，還是高階自動駕駛，系統(tǒng)軟件都是整個軟件體系架構的重要組成，高度關乎系統(tǒng)的可靠性和安全性。

圖源：演講嘉賓素材

正是基于此，華玉通軟致力于面向智能駕駛的基礎軟件研發(fā)，目前已經推出了完整的面向智能駕駛的基礎軟件系列產品。在和多個主機廠、Tier1進行量產合作的過程中，我們也發(fā)現(xiàn)了基礎軟件在量產過程中出現(xiàn)的一系列挑戰(zhàn)，并逐一進行了解決。下面將和大家分享我們遇到了怎樣的問題，以及在華玉產品中的解決策略。

DDS量產案例

在量產過程中，從通信、執(zhí)行管理到確定性調度以及工具鏈是我們在搭建智能駕駛系統(tǒng)時繞不開的話題。用開源的DDS或開源的ROS去搭建demo級別的自動駕駛軟件平臺所能達到的系統(tǒng)可靠性以及穩(wěn)定性，與基于華玉基礎軟件去構建滿足嚴苛量產需求的系統(tǒng)化軟件架構所能實現(xiàn)的是截然不同的。

通信層面，例如在ARM A核上，量產過程中通常會遇到的問題是多個應用、算法帶來的通信場景復雜、數(shù)據收發(fā)節(jié)點多、通信頻次高，數(shù)據量非常大等挑戰(zhàn)。用成本很高的大算力芯片去解決這些問題是目前常用的方式。但隨著智能駕駛系統(tǒng)普及的需求越來越高，車企都希望能使用低成本的芯片構建自動駕駛系統(tǒng)，將CPU的性能盡可能充分利用，以將CPU用滿為目標來做資源分配。那么如何在高系統(tǒng)負載下保證通信的低延遲抖動就成為了非常重要的問題。同時，在這樣一個復雜的通信場景下，不同節(jié)點對于通信性能和通信場景的需求是不同的。華玉通信中間件可以通過非常簡單的QoS配置，來滿足客戶復雜多變的通信場景需求。此外，SoC的資源非常豐富，有多種底層通信channel，如何根據不同應用需求（進程內/進程間/核間/芯片間/域間）選擇效率最高的channel，也是華玉通信中間件能夠幫客戶解決的實際問題。在通信過程中，華玉通信中間件可以提供完整的通信診斷支持，幫助用戶快速定位與通信相關的故障所在。

下面是我們在和某Tier1量產項目中的實際通信場景。在TDA4和J5之間，TDA4的A核和R核之間要做大量的數(shù)據交互。

圖源：演講嘉賓素材

TDA4的A核上要發(fā)布的topic數(shù)量為56個，要接收來自A核數(shù)據的節(jié)點的數(shù)量為105個，接收來自R核數(shù)據的節(jié)點為8個。通信的頻次是為25赫茲、50赫茲、100赫茲。通信數(shù)據包的平均大小從30字節(jié)到3M字節(jié)不等，平均每秒要收發(fā)的數(shù)據包數(shù)量是6000個，每秒鐘吞吐量為500M字節(jié)。這種復雜的場景如果不依賴通信中間件，要從底層直接實現(xiàn)一個車規(guī)級通信的框架是很困難的，并且需要消耗大量的人力、物力和時間成本。

在這個復雜通信場景下，我們使用華玉SWIFT DDS實現(xiàn)了數(shù)據互通。在J5及TDA4的A核/R核上都部署了SWIFT DDS，所有的通信都通過SWIFT DDS完成，并且可以根據應用的部署位置及需求來選擇最優(yōu)的通訊方式。

圖源：演講嘉賓素材

另一個案例是一個雙Orin加雙TC397的架構。在所有的芯片上同樣是通過SWIFT DDS來打通所有的通信鏈路。這里面有一顆Orin還會運行一些車云的相關應用，可以用擴展的DDS協(xié)議，包括DDS-SECURITY、DDS-RPC和DDS-WEB，幫助客戶方便快捷的直接打通車端和云端的連接并且滿足車端和云端通信的特定需求。在這樣的場景下，使用同一華玉的通信中間件就可以把車內通信、車間通信以及車云通信全部統(tǒng)一起來。

在這個案例中，為何客戶選擇了SWIFT DDS而不是其他方案？首先，SWIFT DDS可以實現(xiàn)對復雜場景的支持。通過其他方式也可以將通信場景搭建起來，但通信過程中，其他的搭建方式無法滿足除通信本身之外的功能以及性能的需求。而SWIFT DDS則可以通過DDS的配置工具輕松實現(xiàn)復雜場景下的通信功能及性能需求。

其次，SWIFT DDS有多種高性能通信的支持。例如在TDA4 A核R核通信中，SWIFT DDS會自動切換底層channel使用效率更高的RPMessage進行通信。

第三是對于通信延遲抖動的控制。量產過程中，A核需要運行數(shù)十個甚至上百個進程，這些進程都有自己的周期。一旦通信發(fā)生抖動，這個抖動是不可控制的。比如用Some/IP，普通抖動的平均值可能是5毫秒，但如果它在一段時間內抖動的最大值能達到幾百毫秒甚至秒的量級，對于時序要求非常嚴格的上層應用來說，是沒有辦法使用的。因此SWIFT DDS提供支持確定性調度的接口，針對前面所提到的抖動問題做了深度的優(yōu)化。

最后是對于診斷和多種通信QoS的支持。SWIFT DDS針對智能駕駛汽車的場景或做了非常多的優(yōu)化和改進，而其他幾種方案是沒有這些功能的。

圖源：演講嘉賓素材

量產過程中的執(zhí)行和狀態(tài)管理

SoC上運行了非常多的進程，這些進程之間有各自的依賴關系。大部分公司是按模塊開發(fā)，最后將模塊放在一起拼成一個系統(tǒng)。在這個過程中，程序以怎樣的形式部署到硬件上？怎樣開始運行和結束？這當中并沒有統(tǒng)一的框架進行規(guī)定。

對于狀態(tài)管理而言，在量產過程中必須要有一個統(tǒng)一的框架，比如相關的二進制文件。對于依賴庫，對于運行的參數(shù)進行統(tǒng)一的管理和配置。同時，對于應用要進行統(tǒng)一的部署，進行OTA的升級等，也都必須在一個獨立的統(tǒng)一框架下完成才能以最高的效率實現(xiàn)。

另外，我們的執(zhí)行和狀態(tài)管理要做到進程和資源的隔離，保證A核上運行的多個進程一旦有崩潰的，不會影響其他進程。

針對這些挑戰(zhàn)，我們開發(fā)了“云雀”執(zhí)行管理中間件，在量產過程中使用我們的中間件可以將應用程序的配置、開發(fā)、部署、運行，以及OTA統(tǒng)一到一個框架下來進行。

從應用程序的生命周期管理和狀態(tài)管理而言，通過“云雀”執(zhí)行管理中間件，可以和上層業(yè)務進行解耦。用戶在只有system design（所有模塊節(jié)點的框圖以及節(jié)點之間數(shù)據流圖），還沒有實際的業(yè)務代碼之前，就可以根據這些信息把程序生命周期管理和狀態(tài)管理全部實現(xiàn)，而不依賴于實際的算法實現(xiàn)。而如果在應用里把這些功能實踐出來，造成的結果就是狀態(tài)管理、執(zhí)行管理本身會和上層業(yè)務有嚴重的耦合，會非常難以調試，以及后續(xù)擴展困難。

對于部署和OTA來說，“云雀”執(zhí)行管理中間件把程序的部署和OTA一并放到執(zhí)行管理框架下，只要用同樣一個框架就可以實現(xiàn)程序開發(fā)、部署、執(zhí)行、OTA，所有相關的東西都在同一個框架下實現(xiàn)，高度保證其連續(xù)性和一致性。

圖源：演講嘉賓素材

我們在量產中面臨的另一挑戰(zhàn)是確定性執(zhí)行。Linux的調度機制是盡最大的能力去做調度，但不會保證程序在確定的時間內執(zhí)行完畢，而目前在A核上運行的很多智能駕駛算法是有明確的截止時間和周期要求的。一旦某個程序的執(zhí)行時間不確定，就會造成整個系統(tǒng)狀態(tài)陷入混亂。這個過程中整個系統(tǒng)不僅在節(jié)點上進行計算、處理業(yè)務邏輯，節(jié)點和節(jié)點之間還要做通信，通信本身也會帶來不確定性。

有人提出用TSN解決這個問題，TSN解決的是硬件層面確定性的數(shù)據傳輸，但如果用戶不愿意在數(shù)據鏈路層使用TSN做傳輸，而在傳輸層使用UDP做數(shù)據傳輸，從鏈路層到傳輸層的數(shù)據處理過程中，kernel會帶來新的不確定性。因此，確定性的執(zhí)行必須解決通信過程中數(shù)據從用戶進程發(fā)送到用戶進程接收的端到端確定性通信問題。針對這一挑戰(zhàn)，我們對用戶空間到內核空間數(shù)據全鏈路的收發(fā)流程做了細致的研究、分析以及優(yōu)化，推出了華玉確定性版本的全鏈路通信。

通過華玉確定性執(zhí)行模塊，用戶只需要把任務相關信息輸入到確定性調度generator里，產生確定性調度的方案之后，再通過確定性調度的runtime，把確定性調度方案實現(xiàn)出來，就可以實現(xiàn)跨芯片的全局確定性調度。

圖源：演講嘉賓素材

量產過程中的工具鏈需求

對于傳統(tǒng)的MCU或者AUTOSAR CP的開發(fā)，相應的中間件廠商都提供了一套完整的工具鏈。但我們在A核上開發(fā)智能駕駛應用的時候，相應的工具鏈是非常少的。在Linux上做開發(fā)一般都是通過API接口調用，需要一定量的程序開發(fā)工作把應用和底層的中間件使用glue code黏合到一起。另外，上層業(yè)務的數(shù)據流是抽象的算法層面的東西，如何把算法層面比如發(fā)送數(shù)據的類型映射到中間件數(shù)據類型上也需要一定的工作量。

通常開發(fā)過程中的V字模型全流程的閉環(huán)，包括分析，設計，開發(fā)，測試，部署和維護，V字型的流程對于現(xiàn)在汽車電子面向智能駕駛的系統(tǒng)軟件是非常缺失的。

而針對V字模型開發(fā)中的每一個環(huán)節(jié)，華玉都有對應的工具來幫大家完成這些任務。比如我們的System Configurator和Code Generator針對用戶可以使用配置的方式來實現(xiàn)它想要的DDS的通信場景。Monitor可以讓用戶在做DDS測試和調試時直接獲取DDS實時通信狀態(tài)。DDS-Recorder、DDS-Replayer可以讓用戶在實驗室環(huán)境回放錄制的DDS數(shù)據，方便用戶進行通信調試。

Green Engine是華玉推出的自動化集成工具。通過Green Engine，用戶僅需提供上層算法就可以完成整個智能駕駛應用的集成。Green Engine替代了用戶手動去集成核心系統(tǒng)軟件模塊的工作。用戶只需要提供系統(tǒng)節(jié)點之間的框圖以及數(shù)據流的關系圖和擬采用的算法，再使用Green Engine SDK進行處理，就可以生成能直接運行的、基于車規(guī)級中間件搭建的智能駕駛應用。這樣一來，用戶可以只專注于智能駕駛應用程序的業(yè)務本身，而底層的數(shù)據通信、計算調度、執(zhí)行管理等均由Green Engine做綜合和集成，從而實現(xiàn)智能駕駛系統(tǒng)的快速構建及部署。

圖源：演講嘉賓素材

中間件與SOA架構密不可分，目前SOA的底層基礎架構功能基本全部通過中間件進行搭建。雖然SOA可以降低應用、節(jié)點之間的耦合，但是其中還帶來了不小的開發(fā)集成工作。比如直接使用第三方的中間件會有較高的配置復雜度。一個量產項目中車企可能會用到多個中間件供應商，需要協(xié)調多個供應商進行溝通和對接，過程中會花費大量的時間/人力成本，導致最后的集成變得非常復雜且不可控。

使用華玉Green Engine進行開發(fā)集成，因為所有中間件都是華玉自研，并且可以涵蓋用戶上層應用的全部底層需求，所以用戶只需要提供算法，就可以方便快捷地實現(xiàn)量產級別的智能駕駛軟件系統(tǒng)。

（以上內容來自華玉通軟聯(lián)合創(chuàng)始人兼CTO李堅于2023年9月21日-22日在2023第三屆智能汽車域控制器與中央計算平臺創(chuàng)新峰會發(fā)表的《全場景車規(guī)芯片助力跨域融合》主題演講。）

返回第一電動網首頁 >