本文來自《汽車軟件開發(fā)社區(qū)》的系列文章，全文一萬余字，主要分為以下四個部分：

1、國內汽車基礎軟件的現(xiàn)狀與挑戰(zhàn)

2、汽車基礎軟件的定義

3、汽車基礎軟件的起源與演進

4、基礎軟件支持“軟件定義汽車”的早期形態(tài)

01.

國內汽車基礎軟件的現(xiàn)狀與挑戰(zhàn)

一直以來，操作系統(tǒng)、數(shù)據(jù)庫、中間件、編程語言及編譯器等基礎軟件領域是我國軟件產業(yè)的薄弱環(huán)節(jié)，近幾年更是因為一些“卡脖子”事件而備受關注。其實，不同的產業(yè)門類有各自不同的基礎軟件，如PC行業(yè)、手機行業(yè)、工業(yè)控制、云計算等都有自己領域的基礎軟件，汽車行業(yè)也不例外，也有自己專屬的一套基礎軟件。

非?？上驳氖?，相對于PC、手機等行業(yè)基礎軟件幾乎完全依賴國外的狀況，汽車行業(yè)的基礎軟件在近幾年受到了從上到下極高的重視，并取得了一定的實質性進展，大有彎道超車，一雪前恥的逆轉勢頭。

在汽車軟件領域，隨著汽車電子技術的不斷發(fā)展，尤其是近幾年在汽車產業(yè)“新四化”趨勢的帶動下，軟件對于汽車的重要性日益凸顯，“軟件定義汽車”的理念逐步成為行業(yè)共識。

同時，汽車行業(yè)對于新一代集中式E/E架構中的域控制器或車載計算平臺所需的基礎軟件還存在空白，還沒有類似PC行業(yè)的Windows、手機行業(yè)的Android等可供各家整車廠或供應商使用的通用操作系統(tǒng)及中間件，而從事軟件的人都知道：得操作系統(tǒng)者得天下。

因此，大家不再僅僅關注于應用軟件的開發(fā)與創(chuàng)新，同時更加重視車載操作系統(tǒng)、中間件、AUTOSAR等汽車基礎軟件的開發(fā)與創(chuàng)新，國內汽車基礎軟件領域出現(xiàn)了空前的繁榮。

• 誕生了一大批以汽車基礎軟件為主營業(yè)務的企業(yè)，如東軟睿馳、普華基礎軟件、經緯恒潤、中科創(chuàng)達、伊勢智控等，其中很多基礎軟件產品已實現(xiàn)一定規(guī)模的量產。

• 出現(xiàn)了提供包括基礎軟件在內的“全棧”汽車軟件解決方案的大型汽車軟件公司，如零束、華為；

• 獲得了行業(yè)VC風投機構越來越多的青睞。去年10月，東軟睿馳拿到國投招商、德載厚合計6.5億元人民幣投資，公司估值超過60多億人民幣。

• 由中汽協(xié)牽頭，于2020年7月成立了國內首個汽車基礎軟件領域的生態(tài)聯(lián)盟AUTOSEMO，旨在為中國汽車行業(yè)提供面向下一代汽車的標準化的基礎軟件架構、方法論和應用程序接口標準。

向來在各行各業(yè)都薄弱的國產基礎軟件，這次能在汽車行業(yè)中逆轉么？我們不妨先看下以往其它行業(yè)基礎軟件發(fā)展緩慢而沒有突破的原因。根據(jù)中國軟件行業(yè)協(xié)會在2021年發(fā)布的《中國基礎軟件根技術發(fā)展白皮書》和工信部在2017年發(fā)布的《<信息產業(yè)發(fā)展指南>解讀：基礎軟件和工業(yè)軟件》兩篇文章，國產基礎軟件發(fā)展所存在的主要問題有：

1. 國產基礎軟件對核心技術掌握不夠深入，產品性能功能、用戶體驗、穩(wěn)定性和成熟度等與國外主流產品仍存在一定差距，在產品化、工程化方面與國外企業(yè)差距較大。

2. 專業(yè)人才培養(yǎng)和儲備不足。對基礎軟件技術投入不夠，專業(yè)人才培養(yǎng)缺乏針對性，尤其缺乏復合型人才。

3. 產業(yè)規(guī)模小，力量分散，沒有形成生態(tài)。

很遺憾，在本人看來，這三個問題對于國內當前的汽車基礎軟件行業(yè)同樣存在。以下我們以汽車基礎軟件領域大家耳熟能詳?shù)腁UTOSAR軟件為例進行分析。

首先，我們對汽車基礎軟件核心技術的掌握遠不夠深入。

因為大部分人是近幾年通過AUTOSAR來才開始了解汽車基礎軟件的，在此之前我們對汽車基礎軟件的了解極少。

汽車中各個控制器的基礎軟件通常由Tier1開發(fā)完成，而汽車核心零部件一直是中國汽車行業(yè)的堅冰地帶，國內汽車零部件公司在行業(yè)“新四化”之前，大多以機械件為主，涉及到電子控制的核心零部件極少。國內最早接觸基礎軟件的開發(fā)人員大多在Bosch、Conti等外資零部件企業(yè)，而且受制于外資企業(yè)對核心技術的保護，很多工程師甚至都看不到控制器中的軟件源代碼。

插播個故事：本人2009年曾在一家外資的座椅加熱控制器研發(fā)部門實習，當時由于國內拿不到源代碼，而又急需修改一個重要參數(shù)進行產品試驗，無奈下只能分析二進制可執(zhí)行文件（軟件編譯后生成的Hex文件），通過類似反編譯的方式，找到了參數(shù)在文件中的位置，直接修改了該參數(shù)（慶幸程序中當時沒有今天的安全刷新、安全啟動等一系列信息安全機制~~），從而保證了產品試驗能夠按時完成。可見，當時國內工程師連一個簡單的座椅加熱控制功能軟件源代碼都看不到。

直到近幾年，國內新能源和自動駕駛領域誕生了眾多初創(chuàng)公司進行相關零部件的自主研發(fā)，Vector、ETAS等國外企業(yè)適時推出符合AUTOSAR標準的基礎軟件產品供其使用，才使得國內工程師有機會真正接觸汽車基礎軟件，以至于很多人誤認為基礎軟件就是AUTOSAR，AUTOSAR就是基礎軟件。而前面提到的幾家國產基礎軟件供應商，其開發(fā)人員大多也是參考AUTOSAR標準開發(fā)基礎軟件，之前毫無相關經驗。

可想而知，對于這些企業(yè)而言，要實現(xiàn)汽車基礎軟件的產品化和工程化會有多么困難。以產品化為例，由于開發(fā)人員缺乏實際開發(fā)和應用經驗，僅憑一堆AUTOSAR標準文檔開發(fā)產品，面對客戶需求時不能合理引導客戶而一味地滿足客戶千奇百怪的需求，難以形成自己的標準化產品，很容易讓自己走入死胡同。

其次，專業(yè)人才嚴重不足，且行業(yè)內對人才競爭激烈，工作穩(wěn)定性差。

從前面一點其實也不難看出來汽車基礎軟件領域專業(yè)人才的極度匱乏。而近幾年行業(yè)內如雨后春筍般出現(xiàn)的大量公司對基礎軟件人才如饑似渴，使得基礎軟件工程師身價倍增，流動率極高，不利于個人能力的成長。而從企業(yè)角度看，嚴重不足的開發(fā)人員難以支撐企業(yè)實現(xiàn)自己的宏圖大業(yè)。

在Bosch，截至2020年，約有1200名專職從事汽車基礎軟件開發(fā)的軟件工程師，按照去年Bosch對外發(fā)布的信息，其與ETAS整合后形成的“通用汽車軟件”開發(fā)團隊將達到2000多人。在Vector、KPIT等第三方軟件供應商，其汽車基礎軟件開發(fā)團隊規(guī)模也在800~1000人左右。而國內的基礎軟件企業(yè)即使?jié)M打滿算，大多只有100人左右，有些甚至不足50人，規(guī)模最大也沒超過200人。就算我們的工程師能力與國外相當，所開發(fā)的產品也會打2折，甚至1折。

再次，產業(yè)規(guī)模小，資源分散，集中度低，甚至惡性競爭。

國內汽車產業(yè)本就具有非常明顯的分散特征，而這一特征在汽車基礎軟件領域也正在上演，以AUTOSAR產品為例，國內目前已至少有東軟睿馳、普華基礎軟件、經緯恒潤、道緯科技、知從科技等五家宣稱可提供相關產品與服務。另外，還有一件讓人費解的事情：2020年11月，“中國智能網聯(lián)汽車產業(yè)創(chuàng)新聯(lián)盟基礎軟件工作組”成立了，這是國內第二個基礎軟件生態(tài)聯(lián)盟，而前一個AUTOSEMO剛剛成立不到半年。

本就稀少的資源變得更加分散，而資源分散是致命的，內耗太多，難以成事。為了拿到項目，相對于國外產品普遍按照授權使用范圍或產量進行定價的模式，一些國內企業(yè)在產品單價遠低于國外產品的情況下，進一步采取不限制使用范圍的一口價策略，后期用戶使用過程中甚至還可以以極低費用甚至免費提供工程服務直至量產，大大低估了基礎軟件的價值和應用難度，導致利潤極低，甚至虧損。部分企業(yè)已經出現(xiàn)增長乏力甚至是負增長。

據(jù)高工智能汽車報道：“作為中國軟件企業(yè)中最早進入AUTOSAR高級合作伙伴的普華基礎軟件，截至去年底，其AUTOSAR汽車級軟件平臺產品已量產超過500萬套，但公司營收卻并沒有起色。數(shù)據(jù)顯示，該公司2017年營收為7,232.14萬元，利潤僅為24.81萬元；到了2020年，營收為9,387.57，利潤153.28萬元，營收年復合增長百分比僅為個位數(shù)，公司整體估值僅為3.36億元。最新數(shù)據(jù)顯示，普華基礎軟件2021年1-9月營收為5672.82萬元，凈利潤虧損580.53萬元，在汽車軟件行業(yè)整體向好的背景下，卻凸顯業(yè)務增速的乏力?！?/span>

總的來看，汽車基礎軟件的國產化之路已經開啟，但同樣道阻且長?；A軟件技術一向是門檻高、投入大、周期長、回報慢，希望每一個真正有志于國產汽車基礎軟件的同行都能堅守初心，行穩(wěn)致遠。

要想做好汽車基礎軟件，首先應當搞明白什么是汽車基礎軟件。本人不才，一直從事于汽車動力總成領域的控制器基礎軟件開發(fā)，對于以AUTOSAR Adaptive為代表的面向智能網聯(lián)汽車的新一代汽車基礎軟件缺乏實際應用經驗。以下基于自身有限的工作經驗，僅就傳統(tǒng)ECU領域的基礎軟件，闡述自己對于到底何為汽車基礎軟件的理解，以及它的誕生與演變歷史，希望有助于國內以應用AUTOSAR Classic 平臺為主的ECU零部件供應商更高效地開發(fā)更高質量、更加安全的關鍵核心零部件，同時對于我們開發(fā)以AUTOSAR Adaptive為代表的面向智能網聯(lián)汽車的新一代汽車基礎軟件有所啟發(fā)。

02.

汽車基礎軟件的定義

汽車基礎軟件，又稱為底層軟件，雖然現(xiàn)在經常被提到，大家似乎都很熟悉了，但仔細考究就會發(fā)現(xiàn)，目前并沒有一個被行業(yè)各方都認同的統(tǒng)一的定義。就連專注于汽車基礎軟件的AUTOSAR標準，給出的定義也非常雞肋

——“The Basic Software (BSW) provides the infrastructural(schematic dependent and schematic independent) functionalities of an“Electronic Control Unit”.”，

無非就是把Basic一詞換成了Infrastructure，沒有實質內容（此處僅指概念上，AUTOSAR標準所定義的內容當然是非常多的）。所以目前每個開發(fā)組織對于基礎軟件的理解細究起來其實并不完全相同。一個非常典型的例證就是實際開發(fā)過程中底軟團隊和應用層開發(fā)團隊之間經常就某個功能應該由誰來開發(fā)而爭個不休，比如對某個開關信號的Debounce操作。

其實，AUTOSAR標準所定義的基礎軟件是各家會員單位基于自己對基礎軟件的理解相互溝通妥協(xié)后的結果，是各家會員單位具有普遍共識的部分。除此以外，還有大量的基礎軟件模塊并沒有被標準化。

以最常見的MCU驅動（Mcal）為例，AUTOSAR標準中僅對GPT、Watchdog、Flash、CAN、SPI、ADC、Port等MCU外設驅動進行了標準化，如下圖中橙色部分所示。而MCU其它常見的外設，如I2C、MSC、DMA、UART、MPU、EMM、GTM等許多模塊并沒有被標準化，如下圖中灰色部分所示。

BMW和Bosch分別是九大核心成員中OEM和Tier1的代表。我們來看下他們對于基礎軟件的理解。

BMW盡管是一家OEM，但其軟件開發(fā)能力卻毫不遜色，這也是為什么它能牽頭推動AUTOSAR標準的制定。BMW在集團范圍內定義了名為BSP（BMW Software Platform）的標準軟件平臺，這個平臺主要包括BMW AUTOSAR Core（簡稱BAC）和adaptive BMW AUTOSAR Core（簡稱aBAC）。在這里面，除了常規(guī)的AUTOSAR標準中所定義的內容，還包含有用于軟件更新的Bootloader、信息安全增強軟件包、以太網診斷擴展包等眾多獨門秘技。這些內容以企標或軟件模塊的形式傳遞給供應商，由供應商進行實現(xiàn)或集成。

Bosch作為汽車電子領域常年排名世界第一的零部件供應商，一直在引領著汽車技術的進步，在汽車基礎軟件方面其實也毫不例外，只是從來沒有專門拿出來說而已。Bosch早在2005年左右就已經形成自己較為成熟的基礎軟件，當時稱為Core Software，它主要包含Base System和Diagnosis System 兩大部分，其中前者主要包含硬件相關功能組件，如OS、啟動管理、復位管理，刷新用Bootloader、硬件封裝模塊、服務函數(shù)庫、標定與測量驅動等，而后者主要包含常規(guī)通信、診斷通信、故障管理、網絡管理、網關等功能組件。如今AUTOSAR標準中所提及的復雜驅動當時并不屬于Core Software，后來，隨著軟件架構的不斷發(fā)展，Bosch對于基礎軟件范圍的定義也持續(xù)進化。如今，Bosch的汽車基礎軟件雖然也大多采用了AUTOSAR標準，但在標準之外，仍然存在遠超標準內容的功能組件，尤其是在功能安全、信息安全、外設驅動、Ethernet等關鍵核心功能領域。

由此可見，對于基礎軟件的具體內涵，目前各家都有自己的定義，AUTOSAR所定義的內容更多的只是各家的共性部分。如果非要給基礎軟件下一個定義的話，倒是可以參考國內AUTOSEMO組織在《中國汽車基礎軟件發(fā)展白皮書1.0》中的描述：

汽車基礎軟件是用于實現(xiàn)汽車系統(tǒng)軟硬件解耦，且與用戶應用功能無關，但為應用功能提供一系列服務的支撐軟件集合。

對于不熟悉汽車基礎軟件的人而言，這種定義可能還是過于抽象。如果要用一種形象的方式解釋什么是基礎軟件，本人認為可以將基礎軟件比作人體的神經系統(tǒng)，相對應地，控制器硬件可以理解為身體，而應用軟件可以理解為大腦。如下圖所示。

以AUTOSAR架構為例：

• 系統(tǒng)技術棧部分可以理解為負責控制新陳代謝的神經

• 存儲技術棧可以理解為負責記憶的神經

• 通信技術?？梢岳斫鉃槲覀兊?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important;">聽覺和語言神經

• IO和復雜驅動技術?？梢岳斫鉃樨撠?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important;">感覺和運動的神經

舉個例子，應用軟件準確計算出了某個結果，希望驅動某個執(zhí)行器開啟或關閉但控制器卻沒有發(fā)出用于控制執(zhí)行器的物理信號，而此時控制器硬件沒有任何問題，這很像一個人想活動四肢，但卻因為神經系統(tǒng)出現(xiàn)問題而動彈不得。

上圖是本人總結的傳統(tǒng)汽車基礎軟件全景圖。其中橙色的模塊是AUTOSAR標準已涵蓋的模塊，而灰色的模塊則是AUTOSAR尚未涉及的模塊或功能包。需要說明的是，歸入復雜驅動中軟件從嚴格意義上來說，并不都屬于復雜驅動，只是它們尚未被標準化，而暫時寄存在這里而已，如Hypervisor、功能安全、信息安全、高級以太網驅動、硬件加速模塊驅動等。

那這些尚未被AUTOSAR標準化的內容占比有多少呢？不同的組織或許有不同的答案，如果對標Bosch，占比則不低于50%！

綜上所述，汽車基礎軟件沒有嚴格的定義，但可以明確的是，AUTOSAR不等于基礎軟件，基礎軟件的范疇要遠超AUTOSAR標準中所定義的內容，二者不能劃等號，它們的關系更像是早餐與豆?jié){油條的關系。AUTOSAR只是標準化了各家會員單位的共識部分，各家的還有很多“獨門秘籍”并沒有拿出來標準化。

對于組織而言，按照AUTOSAR標準只能開發(fā)出或采購到自家產品所需的部分基礎軟件模塊，一定還有需要額外自行開發(fā)的基礎軟件；在實際項目中，必須明確基礎軟件的具體范圍，而不能描述的過于籠統(tǒng)或者簡單的與AUTOSAR劃等號。否則，我們的項目將每天都有很多“意外”，很難“On Time，On Spec，On Cost”地交付。

對于個人而言，基礎軟件除了AUTOSAR以外，還有眾多待研究和開發(fā)的地方，而這些尚未標準化的內容往往是具有更高價值的功能，因此我們有充足的個人職業(yè)發(fā)展空間，而不會讓自己局限為一個簡單的所謂的“工具人”，除非我們自我設限。

或許在接下來我們了解了汽車基礎軟件的發(fā)展歷史后，我們會更加充滿信心。

03.

汽車基礎軟件的起源與演進

欲知大道，必先為史。本節(jié)重點談談汽車基礎軟件的起源與演進。汽車基礎軟件不是隨著汽車電子控制器一起誕生的，而是伴隨著控制器功能日益復雜而逐漸形成的。早期的汽車電子控制器由于功能較少，軟件比較簡單，并沒有基礎軟件的說法。隨著控制器中軟件功能的日益增多，軟件架構設計的重要性日益凸顯，如何提高軟件的復用率，避免重復開發(fā)，提高開發(fā)效率受到越來越多的關注。

首先，國際領先的汽車電子控制器研發(fā)組織是汽車基礎軟件的創(chuàng)造者。

不僅Tier1，還有OEM，因為縱觀全球汽車零部件格局，汽車零部件公司大致分兩種：一種是創(chuàng)立之初就是獨立零部件廠商；另一種則是誕生于汽車整車廠體系下。前者比如博世、麥格納，后者比如電裝、德爾福。

上世紀八九十年代，在領先的電子控制器研發(fā)組織內，控制器中的軟件逐漸被細分為若干相對獨立的模塊，從最頂層看，整個系統(tǒng)的軟件逐漸被分為與產品功能直接相關的應用軟件和不直接相關的基礎軟件兩大部分，從而使得研發(fā)組織內部的各個產品之間和同一產品的不同代系之間的軟件復用率大幅提升，減少重復開發(fā)。

舉個例子，下圖展示了Bosch在2010年左右設計的同時兼容傳統(tǒng)發(fā)動機控制和新能源汽車電機控制的軟件架構。其中上半部分為應用軟件ASW，而下半部分可以理解為基礎軟件，其中包括HDS（硬件相關軟件）、Dia（診斷軟件）、ComSys（通信軟件）、DE（傳感器與執(zhí)行器等設備封裝軟件）、CDrv（復雜驅動）五個部分。這一結構已經很接近我們今天所看到的AUTOSAR分層架構了，而這一軟件架構其實早在2005年左右在Bosch內部就已非常成熟，并廣泛地應用于發(fā)動機、變速箱等控制器。

Bosch動力總成控制器軟件架構圖

來源：論文《Experiences from a Large Scale Software Product LineMerger in the Automotive Domain》

其次，歐洲整車廠是基礎軟件標準化的推動者。

與國內的整車廠不同，歐美的整車廠大多擁有較強的電子控制器自主開發(fā)能力。隨著汽車上所集成的電子控制器數(shù)量持續(xù)增多，整車電子電氣系統(tǒng)分布式網絡控制（Networked and Distributed）的特征日益明顯，整車廠們發(fā)現(xiàn)集成的難度越來越大。德國和法國的OEM及其供應商通過調查發(fā)現(xiàn)，大量的工作花費在了開發(fā)和調試操作系統(tǒng)、通信和網絡管理以及輸入輸出設備驅動等軟件上，以確定應用功能表現(xiàn)異常的原因。也就是說為了分析系統(tǒng)功能異常的原因，花費了大量精力在基礎軟件層面上。同時發(fā)現(xiàn)，各家控制器供應商都投入了巨大的費用用于開發(fā)和維護與應用功能無關的軟件，即重復開發(fā)基礎軟件，且各家為應用軟件提供的基礎軟件在接口和協(xié)議方面相互不兼容。

為此，在1995年，歐洲整車廠們牽頭制定了汽車基礎軟件領域的首份行業(yè)標準：OSEK/VDX標準。

OSEK/VDX組織的目標是開發(fā)一套標準的API，從而減少應用軟件重復開發(fā)帶來的工作量并提高應用軟件可移植性和復用率。其結果是產生了三個相對獨立的標準：操作系統(tǒng)、通信和網絡管理。在今天看來，這些被標準化的內容是汽車基礎軟件的重要組成部分，但還遠不夠完整。以I/O技術棧為例，當時OSEK/VDX組織已意識到并沒有對這部分開發(fā)對應的標準，而采用了推薦各家在公司內部自行開發(fā)自家標準的方式來處理這一問題。

從技術和商業(yè)兩個方面來看，OSEK/VDX標準在一定程度上滿足了整車廠最初的目標，但仍然不夠。隨著汽車電子的發(fā)展，這些領先的整車廠逐漸將重點聚焦在與用戶使用體驗直接相關的應用功能軟件，以打造品牌的差異性，硬件和基礎軟件則交由供應商提供，產生了OEM和Tier1聯(lián)合開發(fā)控制器軟件的模式（我們將在下一節(jié)介紹與此相關的更多信息）。

為了使得這些自主研發(fā)的應用軟件方便地集成到不同控制器供應商的產品中，打破供應商的制約，在2003年，進一步成立了AUTOSAR組織，制定了有史以來定義最全面的基礎軟件標準——AUTOSAR標準，最大程度地實現(xiàn)了應用功能軟件與控制器硬件的解耦，也就是我們現(xiàn)在常說的“軟硬件解耦”。AUTOSAR組織的目的其實和OSEK/VDX組織差別不大，只是AUTOSAR在內容方面進行了大幅擴展，在細節(jié)方面進行更具體的定義，以期更好地滿足整車廠的愿望：

• 自主開發(fā)車輛應用軟件，實現(xiàn)差異化競爭；

• 自主開發(fā)的應用軟件可以方便地在不同供應商的控制器之間移植；

• 自主開發(fā)的應用軟件可以方便地在不同車型之間移植；

• 自主開發(fā)的應用軟件可以方便地在不同應用場景之間移植；

圖：AUTOSAR 愿景

需要特別指出的是，以上這些愿望都是整車廠的愿望，而不是供應商的。因此在早期，Bosch、Conti等零部件巨頭對AUTOSAR并沒有熱情，甚至是抗拒。這使得AUTOSAR標準早期的推廣并不順利，直到發(fā)展到R4.0版本才相對較為成熟，這也是當前業(yè)內普遍采用的版本。以Bosch為例，其產品從2015年左右才開始大規(guī)模采用AUTOSAR標準開發(fā)基礎軟件。同時，直到近幾年，在寶馬等車廠的一些項目中，Bosch的產品仍然因為對AUTOSAR的支持能力不足而沒有獲得項目定點。

最后，開源 —— 基礎軟件標準化的新嘗試。

AUTOSAR標準雖然已經定義的非常細，但畢竟仍然只是個標準，而不是具體的實例。其所倡導的“在標準上合作，在實現(xiàn)上競爭”的理念，在實際落地過程中也出現(xiàn)了各種各樣的問題，導致各家基于同一個標準開發(fā)的AUTOSAR產品彼此之間并不兼容，使得整車廠們的愿望被大打折扣。Bosch對此深有感觸，并牽頭發(fā)起了一個類開源項目：COMASSO，以期聯(lián)合各方共同開發(fā)一套符合AUTOSAR標準的基礎軟件及其工具。其背后的動機可參考如下來自其官網的描述。

After 10 years of AUTOSAR development we observe theexistence of various implementations without competition relevantdifferentiation, causing integration effort in case of SW exchange and reuse.We want to reduce this higher integration effort in case of SW exchange andresuse by supporting a common implementation of the AUTOSAR standard. Thisprovides the members a higher degree of freedom to concentrate on innovation.

從2013年Bosch和ETAS共同成立COMASSO開始，這個項目已運行近十年，20多家組織加入，不過可能受制于開源模式不夠徹底，目前依然不溫不火，知名度很低，影響力有限。但這未嘗不是一種新的嘗試，或許在未來的某個恰當時機，將猶如Linux一樣被普遍采用。

綜上所述，汽車基礎軟件的誕生是汽車軟件日益復雜的必然結果，符合軟件發(fā)展的客觀規(guī)律，是各個研發(fā)組織自我進化的自然結果。而汽車基礎軟件的標準化則體現(xiàn)了汽車行業(yè)的特點，是由整車廠牽頭推動才形成的，體現(xiàn)了整車廠的意志，對于供應商而言，由于自己的一部分業(yè)務被整車廠收回了，因而其實是弊大于利。

展望未來，汽車基礎軟件的標準化是繼續(xù)走下去，還是出現(xiàn)類似手機行業(yè)Android和蘋果iOS等不同陣營的操作系統(tǒng)實例，以及是否會出現(xiàn)安全可靠的開源解決方案，讓我們拭目以待。

04.

基礎軟件支持“軟件定義汽車”的早期形態(tài) 

面對日益復雜的汽車軟件，尤其是域控制器等中央計算平臺，僅憑一家之力難以完成，共建軟件開發(fā)生態(tài)，聯(lián)合多家生態(tài)伙伴共同開發(fā)是“軟件定義汽車”實現(xiàn)的必由之路。而這種多家聯(lián)合開發(fā)控制器軟件的模式其實在行業(yè)內早已有之，尤其是國外OEM，早在上個世紀就開始了“軟件定義汽車”的探索，只不過那時的軟件主要聚焦車輛的性能，而今天的軟件更多強調終端消費者的使用體驗，即所謂的“千人千面”。了解這些早期“軟件定義汽車”理念的具體實現(xiàn)方法對于實現(xiàn)今天的“軟件定義汽車”無疑具有重要的指導意義。本節(jié)介紹本人所了解到的傳統(tǒng)控制器中存在的各種軟件聯(lián)合開發(fā)模式，希望能有助于國內同行以更務實的態(tài)度推進“軟件定義汽車“的落地，少走彎路。

相對于軟件和硬件均由供應商完全開發(fā)的傳統(tǒng)控制器開發(fā)模式，控制器軟件由兩方及以上共同進行開發(fā)的項目都可認為屬于軟件聯(lián)合開發(fā)模式，Bosch還專門將這種開發(fā)模式定義為Software-Sharing。

為了體現(xiàn)自己的技術優(yōu)勢和產品特性，OEM通常會對直接影響車輛功能的應用軟件提出個性化需求，避免全部采用供應商的默認方案。因此軟件聯(lián)合開發(fā)模式通常在OEM和Tier1之間展開。而這種合作開發(fā)，離不開安全可靠的基礎軟件的高效支持。

OEM參與軟件開發(fā)程度的深淺以及雙方對開發(fā)相關的一系列數(shù)據(jù)交互形式，對于實際合作方法的影響巨大，必須區(qū)別對待。以下以常見的針對應用軟件的聯(lián)合開發(fā)為例，根據(jù)聯(lián)合開發(fā)程度由淺到深，劃分為五種模式，依次進行介紹。

聯(lián)合開發(fā)模式一

該模式是指OEM以非源代碼的形式，如Simulink模型或UML模型，提供一小部分應用層功能的控制策略詳細需求，源代碼仍由供應商進行開發(fā)，且供應商需要開發(fā)雙方軟件之間的交互接口層，如圖中灰色部分所示。

這一模式是程度最小的一種軟件聯(lián)合開發(fā)模式。對OEM而言，無需掌握軟件開發(fā)能力，也能夠提出自己對某部分控制功能的獨特見解，使得最終的系統(tǒng)功能有別于供應商提供的標準解決方案。模式一適用于在個別應用層功能點采用自主方案，同時具備功能建模能力但不具備軟件開發(fā)能力，軟件仍由供應商開發(fā)，且同意自主方案對供應商公開的OEM。

聯(lián)合開發(fā)模式二

該模式是指OEM以目標代碼（軟件編譯之后的Object文件）的形式提供一小部分應用層功能的控制策略。

相對于模式一，由于合作方交互過程中看不到具體的控制策略，因此這一模式可以保護OEM的自主創(chuàng)新不泄露，不過同時要求OEM具備軟件開發(fā)能力，這對于雙方的合作提出了更高更細的要求，比如提前約定好各自的函數(shù)與變量的命名空間，編譯器的具體版本等，而且由于供應商得不到源碼，導致軟件調試難度增大。模式二適用于在個別應用層功能點采用自有方案，同時具備功能建模能力和一定的軟件開發(fā)能力，軟件集成仍由供應商負責，且自主方案要求保密，不對供應商進行開放的OEM。該模式在發(fā)動機控制器領域較為常見。

聯(lián)合開發(fā)模式三

該模式是指OEM除了自身參與應用層軟件開發(fā)以外，還邀請了其它若干家供應商提供部分應用層軟件，大部分應用層軟件均不再使用控制器供應商的標準方案，并且最終的軟件集成由OEM進行。這就使得OEM能夠將各家供應商之所長集于一身，更大程度地掌控系統(tǒng)控制策略，同時又能依托控制器供應商深厚的硬件、軟件、功能安全和信息安全等開發(fā)能力和強大的生產能力。

相對于模式二，涉及的合作方更多，合作各方直接的接口數(shù)量大幅度增加，且都要求訪問基礎軟件的提供的接口，因此合作的難度大幅增加，同時對于OEM的軟件開發(fā)及系統(tǒng)集成與測試能力都提出了更高的要求。模式三適用于在較多應用層功能點采用自有方案和第三方方案組合的形式，同時具備功能建模能力和較強的軟件開發(fā)能力，軟件集成仍由供應商負責，且自主方案和第三方方案要求保密，不對供應商進行開放的OEM。

聯(lián)合開發(fā)模式四

該模式是指OEM開發(fā)大部分應用層軟件，僅有一小部分應用層軟件繼續(xù)采用控制器供應商的標準方案。該模式的合作方法與模式三基本類似，對于OEM的自主開發(fā)能力要求大幅提高，但由于不涉及其它供應商，因此項目合作難度有所降低。該模式能夠使OEM重用其自身已有的較為全面的能力，基本掌控系統(tǒng)控制策略。

模式四適用于大部分應用層功能采用自有方案，同時具備很強的軟件開發(fā)能力，能夠負責軟件集成，且自主方案要求保密，不對供應商進行開放的OEM。

聯(lián)合開發(fā)模式五

該模式是指OEM開發(fā)全部應用層軟件，控制器供應商僅提供硬件和基礎軟件（含復雜驅動）。該模式的合作方法與模式四基本類似，但由于不涉及其應用層軟件之間的交互，因此項目開發(fā)難度有所降低。該模式同樣能夠使OEM重用其自身已有的較為全面的能力，并完全掌控系統(tǒng)控制策略。模式五適用于全部應用層功能采用自有方案，同時具備較強的軟件開發(fā)能力，能夠負責軟件集成，且自主方案要求保密，不對供應商進行開放的OEM。該模式在變速箱控制器、整車控制器等領域較常見。

總結

通過以上對各種軟件合作開發(fā)模式的細分介紹可見，不同的合作模式所支持的“OEM自由度”是不同的，同時自由度越高，所需的軟件開發(fā)能力要求也越高，當然投資也會更大。下表以OEM視角，從多個角度對各種軟件聯(lián)合開發(fā)模式進行了定性對比。實際項目中，OEM（或者僅負責應用功能開發(fā)的組織）可以根據(jù)自己所期望的“自由度”，結合自身技術能力和公司資源情況，并考慮對知識產權的保護，量力而行，選擇最適合自己的聯(lián)合開發(fā)模式，穩(wěn)妥推進自己“軟件定義汽車”的夢想。

最后，需要強調的是，基礎軟件對于控制器軟件聯(lián)合開發(fā)的影響極其重大。這是因為在聯(lián)合開發(fā)過程中，基礎軟件決定了整個系統(tǒng)的狀態(tài)管理及任務調度、內存模型、底層API接口、開發(fā)與調試工具、軟件構建方法（各類文件解析與編譯）等整個軟件開發(fā)所依賴的基礎設施。

因此，OEM們最頭疼的就是由于各家供應商的基礎軟件在上述各個方面的差異而導致的巨大的移植工作量。這種問題與手機領域中一個APP通常至少要開發(fā)Android和iOS兩個版本在本質上是一樣的。

講到這里，相信大家就明白了為什么AUTOSARLogo中間那個字母“O”最特殊，絕不是僅僅出于設計美感的考慮，而是強調Open，開放！逆向思考一下：誰不開放了？誰想開放？自然是OEM希望Tier1們對自己更加開放。于是，BMW等一眾OEM強拉著Bosch等Tier1巨頭對基礎軟件進行標準化，從而形成了以架構、應用接口和方法論為三大支柱的AUTOSAR標準，以期減少OEM軟件的移植工作量。

汽車的基礎軟件還在持續(xù)不斷的發(fā)展，AUTOSAR將只有進行時，沒有完成時。

05.

關于《汽車軟件開發(fā)交流公益社區(qū)》

汽車軟件領域浩瀚無邊，而且還在持續(xù)擴張，為此，我們創(chuàng)建了一個專門面向國內汽車軟件工程師的交流社區(qū)，域名：www.basicsw.cn（即將開通）, 目前已開啟公測通道（http://175.24.230.121/），歡迎點擊文末“閱讀原文”開始體驗。

關于社區(qū)創(chuàng)辦的目的，我們總結了以下三點，希望我們的初心能夠得到大家的認同和支持。

1. 促進交流與分享，加速個人成長

隨著汽車電動化、智能化、網聯(lián)化的發(fā)展，以及“國產替代“概念的推動，汽車行業(yè)上至整車廠、下至芯片、開發(fā)工具供應商，甚至獵頭等人才服務機構一片熱火朝天。汽車行業(yè)百年未有之大變局帶火了汽車工程師，尤其是汽車軟件開發(fā)工程師，甚至原本做金融、財經業(yè)務的獵頭也大批量轉做汽車獵頭，而被獵最多的就是汽車軟件工程師。許多人正跑步加入汽車軟件開發(fā)的行列，或為高薪、或為未來、或為情懷。

然而面對AUTOSAR、ASAM、OSEK、ISO26262、ASPICE等一大堆汽車行業(yè)百年積淀下來的專業(yè)知識，突然覺得自己陷入了一片無邊無際的汪洋大海，少有人帶教，看不到盡頭，找不到方向。與此同時，一大批熱心的汽車軟件行業(yè)老兵通過知乎、微信、CSDN等平臺積極分享著自己的寶貴經驗。然而這些知識”碎片化“特征明顯，缺少歸納和歸類，也缺少互動。

因此，我們希望通過論壇這種“古老”的形式，為大家提供專注于汽車軟件這一細分領域的自由交流與分享的場所，幫助大家共同成長。

2. 打破組織邊界，凝聚全行業(yè)人才的智慧

國外經常在報告中使用“fragmented”一詞來描繪中國汽車市場的特點，國內汽車產業(yè)的分散特征由此可見一斑。由于產業(yè)分散，彼此間缺少合作，沒有形成生態(tài)，導致人才資源分散，而人才資源分散對于核心技術的掌握是致命的，使得大家疲于學習國外已有的技術，無暇進行更深層次的創(chuàng)新。

而伴隨著智能網聯(lián)汽車的發(fā)展，誕生了越來越多的汽車類企業(yè)，使得原本就稀缺的汽車軟件人才更加分散，每家都有數(shù)量遠不及預期的少數(shù)汽車軟件開發(fā)人才。

因此，我們希望通過論壇這種虛擬的組織形式，打破組織邊界，將行業(yè)人才匯聚起來，讓每個人都成為照亮他人的一束光，促進知識的沉淀。

3. 深刻理解汽車軟件開發(fā)的特點，保持敬畏而又不失勇氣

在《人月神話》一書的開頭，作者描繪了這樣一幅場景：過去幾十年的大型系統(tǒng)開發(fā)就猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈地掙扎。他們中大多數(shù)開發(fā)出了可運行的系統(tǒng)——不過，其中只有非常少數(shù)的項目滿足了目標、時間進度和預算的要求。各種團隊，大型的和小型的，龐雜的和精干的，一個接一個淹沒在了焦油坑中……

在今天這樣一個“軟件定義汽車”的時代，這樣的場景仍然正在大大小小的軟件組織中上演。軟件開發(fā)本就是復雜的，而汽車軟件的開發(fā)更是異常復雜。表面上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢。團隊成員每天都陷入各種討論會，難得寫幾行代碼。對問題的麻煩程度，每個人似乎都會感到驚訝，并且很難看清問題的本質。而我們要想解決這些問題，就必須先去理解它。

希望在一次次提問和解答中，有助于大家深刻理解汽車軟件開發(fā)所要求的高實時性、高可靠性、高安全性、硬件成本敏感、跨學科跨領域、軟件集成要求高、維護周期長、法規(guī)要求嚴等一系列特點。在實際的開發(fā)過程中，既能保持對傳統(tǒng)的敬畏，又不失創(chuàng)新的勇氣。

                                                                                        每個圖標代表一百萬行代碼

來源：汽車電子與軟件