什么是汽車基礎軟件

基礎軟件（Basic Software）似乎是汽車行業獨有的一個軟件分類，有時候也叫底層軟件（Low Level Software）或者底層技術（Base Tech）。汽車行業分工細致，上下游產業鏈豐富，很多并非從事基礎軟件相關工作的汽車工程師對汽車基礎軟件并不是很了解。本文嘗試針對初學者作簡單的介紹和探討，基礎軟件大佬請自動略過或批評指正。

那究竟什么是汽車基礎軟件呢？這是很多初接觸者經常會問的問題。如果以傳統計算機行業術語類比，基礎軟件應該最接近于計算機中的驅動軟件。抽象來看，兩者都是硬件或操作系統和應用軟件之間的橋梁。舉個類比的例子，我們平時電腦上用Word打印文件是一個很簡單的操作。

電腦連接一個新的打印機時，我們往往要安裝一個新的打印機驅動程序，但是Word軟件本身并不需要更改或重新安裝。這里的打印機就像是汽車行業中眾多的硬件，Word軟件就像是汽車行業中豐富的應用軟件（Application Software, ASW），而這里的打印機驅動軟件就最像是汽車行業中的基礎軟件，解耦軟硬件，讓應用軟件可以適配不同的硬件。

圖1：打印機驅動軟件（類似汽車行業基礎軟件）示意圖

而如果要進一步深究基礎軟件的精確定義，那只能搬出汽車基礎軟件屆大佬組織AUTOSAR中的定義描述： ——“The Basic Software (BSW) provides the infrastructural (schematic dependent and schematic independent) functionalities of an“Electronic Control Unit.” 這個定義似乎也比較抽象和泛化，但這也許正是基礎軟件的外延。因為在汽車行業，似乎除了功能應用軟件，其他軟件部分在不同場景下都可以稱為基礎軟件。有些時候基礎軟件也延伸為基礎技術或者平臺服務等名字，這時候其往往還包含了一部分傳統意義上的應用軟件模塊。

因為“基礎”這個定義本身就是相對的，在不同語境下有不同的內涵。就像很多產業工人會自稱基層，很多高級工程師也自稱基層，很多高級經理也自稱基層。以下圖經典AUTOSAR架構為例，狹義的基礎軟件就是硬件和運行時環境（RTE）之間的這部分軟件，但在某些討論背景下，例如討論OTA升級功能時，基礎軟件和基礎技術的外延往往會延伸到包括RTE和部分應用軟件（對應AUTOSAR中的SWC）。

圖2：狹義和廣義基礎軟件示意圖

為什么要做汽車基礎軟件

基礎軟件往往是從demo走向量產的關鍵難題，也往往是OEM從企業或者整車層面定義得最多最詳盡最復雜的需求。傳統外資OEM像大眾、寶馬、福特、通用等公司都會定義詳細的基礎軟件需求，往往高達上百篇文檔，上十萬條需求。

基于這些詳細的基礎軟件需求，留給Tier1的空間其實很小，有點像OEM已經把整個設計圖紙都定義好了，就是讓Tier1“代工”把基礎軟件實現出來。這背后也是這類強勢OEM的一種戰略要求：掌握汽車軟件的核心技術能力，讓車上所有控制器及其軟件都按自己的要求標準化、平臺化，方便統一調度，也方便切換不同的供應商，進一步加固自己在行業的核心地位。

汽車上的軟件越來越多，而這并不僅僅是多了幾百萬行代碼那么簡單。這背后實際上是要求汽車具備更豐富而完善的軟件基礎設施（infrastructure），涵蓋從開發到部署到維護的整個過程。將基礎軟件獨立地分離出來一個類別，并集中精力地設計開發，可以帶來以下明顯的好處：

1.軟硬件解耦

這是基礎軟件最突出的使命和優勢。就如開頭舉的Word軟件和打印機的例子，用戶需求肯定包括Word軟件要適配不同的打印機硬件，而有了驅動程序后，Word應用軟件就可以和打印機硬件解耦。設計Word軟件的工程師可以專注于應用軟件本身，打印機廠家也可以專注于打印機本身的設計，專注各自領域并把事情做好。這對汽車上數百個軟硬件復合的用戶功能來說也是一樣。在“缺芯”時代，正是由于基礎軟件的存在，才讓那么多汽車廠家可以有效地找尋替代料，切換芯片供應商，保障供應。

2.提高魯棒性

“穩定”、“安全”、“可靠”等特性對于汽車行業來說都具有特殊的意義，對汽車軟件尤甚。汽車畢竟事關駕駛員和乘客的生命安全，而且往往會行駛十幾年，攀山涉水，環境變量復雜。通過細分基礎軟件，可以讓各個開發方專注領域內的設計開發，完善各自領域內的軟件開發規范和流程，保障軟件質量。同時，標準化的模塊和接口以及其標準化的屬性，都可以讓產品在頂層設計時就充分考慮到軟件的可靠性。

3.提高復用性

汽車基礎軟件的獨立，實質上是帶著“高內聚”和“低耦合”的面向對象的思想。標準化的模塊和接口可以給基礎軟件帶來很強的復用性?；谶@個優勢，對成熟的基礎軟件模塊，供應商都是提供相應的配置開發工具，由汽車軟件工程師按照不同項目配置不同參數，再由工具自動生成源碼。

所以汽車基礎軟件往往是第一次實現的時候需要很多人力物力，例如某新勢力供應商第一次獲得傳統OEM的項目定點時。但是該供應商如果再做該OEM的后續項目時，哪怕是開發全新的應用功能，也可以很輕松地復用之前項目的大部分基礎軟件代碼。

但是汽車基礎軟件也有其面臨的挑戰，一個是上文提到的第一次實現時需要大量人力物力投入，另一個是分層思想和軟硬件解耦帶來的效率損失。

前者的一個現實體現就是很多汽車新勢力公司都不愿意投入巨量資源到基礎軟件的開發中，相比之下快速交付產品更為重要。后者則更多是產品設計理念的取舍。例如按網絡披露的消息，特斯拉在自研FSD芯片的基礎上，就采用了很多軟硬件一體化的設計思想，并沒有過多地開發層次化、標準化的基礎軟件，以提高硬件利用率和減少軟件時延。

這種選擇，在我看來就有點像選用瑞士軍刀還是選用完備的刀具套裝：各有利弊，得根據具體情況選擇，沒有必然結論。按行業觀察，基礎軟件對于新勢力來說很多時候是一種“技術羈絆”，而對很多傳統汽車豪強來說則是他們的“技術積累”。

怎么做汽車基礎軟件

既然汽車基礎軟件事實上大量存在于汽車行業的軟件開發項目中，那么實際上大家都是怎么開發的呢？ 談到怎么實施的問題，就不得不提到AUTOSAR（Automotive Open System Architecture），它定義的主要范圍就是基礎軟件。AUTOSAR匯聚了眾多汽車行業頂尖軟件大牛的智慧，是基于行業最佳實踐而總結提煉的精華，并且應用了大量層次結構和面向對象的思想理念，也是汽車行業基礎軟件的事實標準。它在行業內的統治地位，通過下圖所示的組織成員就可見一斑。

目前AUTOSAR分為Classic Platform AUTOSAR（CP）和Adaptive Platform AUTOSAR（AP）兩個平臺。CP是面向功能的FOA架構（Function-Oriented Architecture），目前廣泛應用于傳統嵌入式處理器中，如發動機控制器、電機控制器、ADAS域控制器中的MCU等。而AP則是面向服務的SOA架構（Servic-Oriented Architecture），應用于針對高計算能力、高帶寬通信、分布式部署的智能駕駛域控制器和座艙控制器的SOC上。

下圖是AUTOSAR通信協議棧的示意圖。接下來我們以它為例子，看一下通信的具體實施。我們先從上往下看一下信號從應用層軟件產生到發送到物理總線的過程。信號由應用層軟件創建后，通過RTE發送至COM模塊，它下面的軟件不能區分信號，只能理解PDU。因此COM將信號打包成PDU，進一步傳輸給PDU Router。

PDU Router按照不同的傳輸協議將其傳輸給下游。如果PDU長度過大，則會先傳給CAN TP或者FlexRay TP，將一條長的PDU分割成若干條滿足協議要求的PDU。以CAN為例，CAN TP分割完PDU后會將其傳給CAN Interface（CAN If）模塊。

CAN If是ECU抽象層中的一個模塊，它負責傳輸請求、傳輸確認和PDU模式控制等服務。CAN If往上的軟件和接口都是對具體的CAN收發器硬件不感知的。然后CAN If會調用底層的CAN Driver模塊，以控制和訪問實際的CAN收發器硬件。CAN Driver為它上層的軟件提供了硬件訪問接口，亦即硬件抽象。FlexRay和LIN的數據下行也是同理。而當數據從物理總線接收再反饋到應用軟件則是同理的逆向過程。

圖5：AUTOSAR通信協議棧示意圖

這個通信分層的架構，可以讓各層軟件各司其職，讓應用層等軟件屏蔽底層軟硬件實現。例如不管是CAN、FlexRay、LIN還是以太網傳輸上來的PDU，都會匯總到PDU Router，再到COM，統一管理內存，這樣應用層軟件獲取信號就可以只關注其端口號，而無需考慮它究竟從哪類總線傳上來的，因為這對應用軟件來說也沒有意義。

而在實際操作層面，AUTOSAR基礎軟件標準化帶來了高度的可復用性，成熟的工具鏈也往往可以讓汽車軟件工程師不用埋頭寫基礎代碼，而是通過配置來高效地生成可靠的軟件代碼。通過AUTOSAR的標準接口文件（*.arxml）可以很方便地在不同工具之間交互配置數據。

以下圖的Vector工具鏈為例，OEM可以通過PREEvision設計整車EE架構，定義通信數據等，然后導出基于ECU抽象的*.arxml文件提供給供應商。通過DaVinci Developer等工具可以導出應用層SWC的*.arxml文件?；谀Ｐ偷膽脤榆浖ぞ撸ɡ?a href="http://m.xsypw.cn/tags/matlab/" target="_blank">Matlab）可以利用該應用層接口文件生成滿足AUTOSAR標準的應用層源碼（*.c和*.h文件）。

而基礎軟件部分則可以通過導入ECU抽象的*.arxml文件和ODX診斷數據庫等文件，在DaVinci Configurator中進行詳細配置，生成RTE和各個BSW模塊的源碼（*.c和*.h文件）?；A軟件、RTE和應用軟件的源碼合在同一個工程項目中后，就可以通過編譯器生成可以刷寫到ECU上的可執行代碼（如*.hex或*.elf）。這個高效配置的工作流，既可以讓開發者專注關鍵功能設計，又能保障生成的源碼質量，是汽車基礎軟件優勢的一個實踐體現。

圖6：Vector的AUTOSAR基礎軟件配置工作流示意圖

審核編輯：劉清