百度智駕事業群產品戰略可以被分為車、路、行三大領域：“車”是面向B端車企提供智能汽車解決方案；“路”是為城市交通提供的智能解決方案；“行”是為C端消費者提供的出行服務。

2023年3月14日-16日，在2023第四屆軟件定義汽車論壇暨AUTOSAR中國日上，百度Apollo智能技術有限公司高級工程師吳長隆表示，百度在L4領域的技術積累和L2+產品的規?；瘍瀯菹嗷ゴ龠M，現已實現出租車-乘用車-城市交通的全面布局。技術層面，通過MCU模塊化和強主線的軟件架構，可以滿足同平臺適配不同車型、多項目并行開發的需求；借助敏捷開發方法和CICD的支撐得以在滿足快速變化的內外部需求的同時，保證產出質量。

吳長隆 | 百度Apollo智能技術有限公司 高級工程師

以下是演講內容整理：

百度Apollo智駕域控制器的發展與挑戰

過去十多年中，百度在人工智能領域積累了豐富的技術和經驗，現在把這些領先的AI技術應用到汽車領域。百度智駕事業群產品戰略從三個領域布局，分為車、路、行。

“車”是指汽車的智能化，百度的智能汽車事業部ASD是作為tier1的角色面向B端車企客戶提供全棧的智能汽車解決方案，包括智駕、智艙。目前已經為31家車企、134個車型、700多萬輛車提供了智能汽車的解決方案。百度旗下的汽車是百度Apollo的合作伙伴之一，將搭載百度智能汽車的全棧智能解決方案，于今年上市。

“路”是指智能城市交通。目前，百度的智能城市交通已經為全國63個城市提供了解決方案，為城市的交通出行提供了效率。

“行”是指為C端消費者提供出行服務，就是大家所熟知的蘿卜快跑。去年百度發布了第六代RT6，具備在復雜城市道路的自動駕駛能力，并且其成本做到了25萬元。RT6的量產落地將極大的加速無人車規?；蜕虡I化。

上述業務相輔相成。百度在L4領域積累了豐富的技術和經驗，可以為L2+的產品提供熱啟動；L2+產品借助規?；膬瀯莘床窵4產品，解決L4產品最終商業落地的長尾問題。

百度智能汽車的產品包含智駕、智艙，包括小度車載系統和軟硬一體的解決方案ARC。智駕域控制器分為MCU和SOC兩大異構的控制芯片。MCU部署了AUTOSAR協議站，在此基礎上開發CDD和應用算法；SOC端底層是一個系統，往上是硬件的戳向層以及百度自研的中間件Apollo OS；再往上是算法的各種原子能力服務；再往上是算法的各種應用邏輯。

接下來分享我們在智駕域控制器MCU軟件基于AUTOSAR開發當中面臨的挑戰。

首先，近幾年百度智駕域控制器的項目較多，已經面臨同一個硬件平臺同時支持多個項目、多個車型并行開發的局面。一個項目需要維護獨立的軟件分支，而在一個項目分支里做出的軟件改動、軟件優化或修復總是手動的遷移到其他項目分支里，才能保證產品體驗的一致性。且軟件模塊間的耦合性很強，一個軟件模塊改動往往會導致其他幾個模塊軟件也需要改動，牽一發而動全身；此外，需要同時往多個軟件分支遷移，維護的工作量隨著軟件復雜度以及項目的增加呈指數級增長。

在智駕賽道需求頻繁變更的階段，時間周期要求非常短；但對產出的質量要求不會有任何降低。這對我們的軟件架構提出了挑戰。我們迫切的需要一套可以支撐多項目并行開發、快速迭代的軟件架構。

怎么樣解決這個問題？我們在AUTOSAR上找到了靈感。AUTOSAR的核心思想就是軟硬件解耦，最底層實現了硬件強相關的軟件功能，并且把它們抽象成了標準的接口提供給上層。上層的ECU以及應用層對于下層硬件的差異幾乎是無感的，使得AUTOSAR架構軟件可以在多個硬件平臺遷移。

其次AUTOSAR的核心思想是軟件的模塊化和接口的標準化，AUTOSAR分成上百個軟件的模塊，軟件模塊功能定義非常清晰，而且軟件之間的數據以定義好的標準化接口做交換。當改變其中一個模塊軟件時，對其他軟件模塊乃至整個控制器軟件的影響都是可控的。

智駕域控制器MCU軟件的平臺化

我們的MCU平臺化軟件架構參照了AUTOSAR的思想。首先需要一套松耦合的軟件架構，所謂松耦合即軟件模塊化，每個軟件模塊的功能定義必須要清晰；模塊間交換接口標準化，并按照AUTOSAR的架構方法在統一的文件中管理。

第二是強主線的軟件架構。參照AUTOSAR上下分層的軟件架構思想，把我們的MCU軟件按照實際的業務需求分成不同軟件。一個硬件平臺只有一個軟件，一個項目有一個單獨的軟件。之間的接口預先定義好，不能輕易改動。以保證一套軟件可以與多個項目的不同軟件結合。

這套軟件架構實際操作方法是：

首先AUTOSAR的BSW工程與具體的項目和車型強相關，比如通信總線的數量、通信矩陣的配置、診斷協議站的配置、網絡管理的配置等等，這些配置每個車型都不同。所以整個AUTOSAR的BSW工程代碼劃分為BASE軟件、CDD軟件（包括各種硬件的IOO抽象以及傳感器的數據介入等等）,這些模塊只與硬件平臺有關，和項目沒有直接關系。應用層軟件通過信號抽象模塊來隔離開各個車型信號接口的不同，讓大多數的應用層軟件做到與項目無關。

此外，還有一些比較特殊的軟件模塊，像時間同步模塊。我們域內的時間同步方案各個項目是一致的；而跨域的、整車域的方案各個項目不同。對于這種模塊我們把一個模塊的軟件拆成兩部分維護，前提是必須定義好軟件間的接口，才能做到多個項目共用一個軟件，使用不同的BASE軟件結合到一起可以正常的工作。

在這套軟件架構下軟件管理的方法有所不同，一個硬件平臺只有一個軟件倉庫，每個項目有單獨的BASE軟件倉庫，軟件合并才會得到最終的MCU軟件產出，其優勢在于主線優化對每個項目直接生效；而挑戰是怎么保證主線上的改動對每一個項目都不出錯，這就需要敏捷開發以及CICD來保證。

智駕域控制器MCU軟件的敏捷開發

整個智駕域控制器的軟件版本交付基本遵循傳統汽車的微模型開發，從開始的需求輸入到軟件設計、軟件開發、軟件測試以及整體驗收，一個版本大概持續2-3個月。在大的周期里我們把MCU軟件版本迭代拆分成以周為單位的敏捷開發周期。

以周為單位敏捷迭代的循環還可以細化到以天為單位的開發迭代。百度內部有自己的一套代碼管理工具，當我們推送代碼進入后觸發持續集成編譯流水線得到編譯的結果和產出；同時每晚系統會自動觸發拉取庫上最新的代碼，推送到CICD測試服務器。測試服務器會模擬上位機把軟件部署到測試臺架的域控制器上，該臺架除了域控制器實物，還有全套的傳感器環境以及模擬的整車環境。部署完后按照預先設定好的測試流程，將MCU軟件配合SOC端進行一套系統性的測試。

測試后，最終服務器收集測試的結果，并生成郵件報告推送給對應的人，第二天上班時就知道前一天的合作代碼是否有問題。除了臺架測試，每天我們都有大量的車進行路測，測試中產生的數據以及發生的問題都會上傳到數據中心，并有專門的管理人員將問題和數據分發到對應的模塊負責人。研發人員分析完數據，定位好問題后按照優先級把問題的修復計劃排到敏捷迭代流程中，進行軟件的迭代開發，獲取新的產出后快速部署到研發車上，再進行閉環的驗證。

現在整車廠越來越重視軟件自研，尤其在自動駕駛領域。有的整車廠選擇百度作為智駕系統軟硬件的供應商；同時希望參與到部分智駕功能的開發中。

我們在項目中也有一些成功經驗，首先OEM會生成我們智駕域控制器的文檔，搭建算法模型后生成AR文件格式的SWC文章。并且會生成最終實現的C代碼，ECU文檔給到百度，我們導入AUTOSAR開發配置工具后可以生成MCU AUTOSAR的技術工程，進行MCU的軟件開發。再把它編譯成黑盒的工程給到OEM端，OEM端將黑盒的工程加入他們生成的代碼進行集成編譯，編譯通過后會做自己的模塊測試，測試通過后將他們的模型代碼編譯程黑盒的形式給到百度，我們再去做最終的MCU軟件的集成、編譯以及MCU軟件產出，完成整個MCU域控制器的集成測試，測試通過交付整車廠，再去做整車級的測試。

（以上內容來自吳長隆 | 百度Apollo智能技術有限公司 高級工程師吳長隆于2023年3月14日-16日在2023第四屆軟件定義汽車論壇暨AUTOSAR中國日發表的《基于AUTOSAR的智駕域控制器軟件平臺化與敏捷開發》主題演講。）

返回第一電動網首頁 >