“軟件定義汽車”最關(guān)鍵的環(huán)節(jié)是SOA（Service-Oriented Architecture，面向服務(wù)的架構(gòu)）。基于硬件算力提升、車載以太網(wǎng)的發(fā)展，以及汽車網(wǎng)聯(lián)化帶來的影響，SOA在二十年后將被重新召喚。

軟件定義汽車不是口號(hào)

“軟件定義汽車”是近來很火的概念。2016年，前百度高級(jí)副總裁王勁提出“軟件定義汽車（Software Defined?Vehicle，SDV）”。在2019年達(dá)沃斯論壇上，大眾CEODr. Herbert Diess宣布，大眾要轉(zhuǎn)型成為一家軟件驅(qū)動(dòng)的公司，并且發(fā)布《軟件定義汽車》的文章。此后整個(gè)2020年，SDV這個(gè)詞一直縈繞在汽車行業(yè)的各種會(huì)議和論壇上。但事實(shí)上，整個(gè)行業(yè)對(duì)于軟件定義汽車的認(rèn)識(shí)是不太一致的。

首先，在未來的汽車中，軟件部分的價(jià)值會(huì)逐漸提升，這在行業(yè)內(nèi)已基本達(dá)成共識(shí)。根據(jù)普華永道的預(yù)測(cè)，到2030年，汽車軟件占汽車總價(jià)值的比例將會(huì)達(dá)到60%以上，開發(fā)成本增加83%以上。在智能座艙、自動(dòng)駕駛、ADAS（Advanced Driving Assistance System，高級(jí)輔助駕駛系統(tǒng)）、能源管理等方面，軟件部分的創(chuàng)新將占整體的90%以上。因此，整個(gè)2021年上半年，汽車行業(yè)內(nèi)呈現(xiàn)著軟件人才緊缺的現(xiàn)象，各個(gè)整車廠和零部件廠商都在大力籌建自己的軟件研發(fā)團(tuán)隊(duì)。

然而，并非所有人都贊同“軟件定義汽車”，有一種意見就認(rèn)為，這不過是IT行業(yè)進(jìn)入汽車領(lǐng)域的宣傳，硬件和制造仍然是汽車行業(yè)賴以生存的基礎(chǔ)，或者認(rèn)為軟件必須要基于電子電氣架構(gòu)的算力才能充分發(fā)揮作用，所謂軟件定義汽車才能實(shí)現(xiàn)。

那么，到底誰對(duì)誰錯(cuò)？其實(shí)刨除“屁股決定腦袋”的言論，“軟件定義汽車”這件事情正在發(fā)生。華為智能汽車解決方案BU CTO蔡建永曾說：“軟件定義汽車，即軟件將深度參與到汽車的定義、開發(fā)、驗(yàn)證、銷售、服務(wù)等過程中，并不斷改變和優(yōu)化各個(gè)過程。實(shí)現(xiàn)體驗(yàn)持續(xù)優(yōu)化、過程持續(xù)優(yōu)化、價(jià)值持續(xù)創(chuàng)造。”應(yīng)該說這個(gè)解釋是目前為止比較客觀、中肯和實(shí)際的。

換句話說，軟件并不會(huì)取代硬件和制造環(huán)節(jié)，但軟件會(huì)成為其他環(huán)節(jié)改進(jìn)、發(fā)展和演進(jìn)的方向標(biāo)，包括電子電氣架構(gòu)（EEA）、汽車研發(fā)過程等都在發(fā)生著的變化。

例如，EEA的演進(jìn)方向從分布式ECU（Electronic ControlUnit，電子控制單元）階段，到域控制器融合，再到中央計(jì)算平臺(tái)階段。這個(gè)演進(jìn)過程，一方面是為了提升電子電器元件的集成度，降低成本的同時(shí)節(jié)約空間；另一方面也是為了提升硬件的標(biāo)準(zhǔn)化程度，方便軟件更新迭代，加快汽車駕乘體驗(yàn)的改進(jìn)和迭代。因此，軟件只是“定義”了汽車，但并不會(huì)“實(shí)現(xiàn)”汽車。

另外，“軟件定義汽車”不僅僅對(duì)于汽車的定義和開發(fā)階段有影響，也會(huì)延伸到銷售和服務(wù)階段，甚至改變汽車的商業(yè)模式，如特斯拉的輔助駕駛包和自動(dòng)駕駛包付費(fèi)升級(jí)模式。同時(shí)，越來越多的車廠計(jì)劃把收費(fèi)模式延伸到銷售以后，如資訊訂閱、車主團(tuán)購(gòu)服務(wù)等。再比如，如果可以通過OTA升級(jí)軟件就能實(shí)現(xiàn)召回，成本可以降低90%以上，整車廠就能承受更多的試錯(cuò)成本，從而改進(jìn)用戶體驗(yàn)。

汽車系統(tǒng)的發(fā)展趨勢(shì)

在“軟件定義汽車”的推動(dòng)下，汽車電子電氣系統(tǒng)的演進(jìn)呈現(xiàn)兩大新趨勢(shì)：一方面是用戶體驗(yàn)上的提升，包括對(duì)用戶行為的感知能力提升和交互能力的智能化改進(jìn)，如DMS（Driver Monitor System，駕駛員監(jiān)測(cè)系統(tǒng)）、語音交互、炫酷的HMI（Human Machine Interface，人機(jī)界面）等；另一方面是整車異構(gòu)系統(tǒng)趨向標(biāo)準(zhǔn)化、虛擬化和服務(wù)化，如EEA架構(gòu)的集中化和軟件架構(gòu)的SOA化。大量ECU將被集成到中央計(jì)算平臺(tái)上，變成一個(gè)獨(dú)立的Service加子板上的一個(gè)外設(shè)。

總體來說，前者更類似于消費(fèi)類電子的發(fā)展趨勢(shì)，尤其像手機(jī)。這也是為什么Android在智能座艙中的占有率逐年上升，大有一統(tǒng)江湖的趨勢(shì)。而后者更像邊緣計(jì)算乃至云端系統(tǒng)的技術(shù)演進(jìn)趨勢(shì)，如虛擬化、容器、SOA。兩個(gè)趨勢(shì)有共同的路線，如對(duì)于大算力、虛擬化、高吞吐量總線的要求，以及信息安全和網(wǎng)絡(luò)安全的要求。但其中也有一些差異點(diǎn)，如對(duì)于功能安全、低延時(shí)、界面響應(yīng)速度的要求等。

由于這些差異性，到目前為止整車系統(tǒng)的融合沒法做到徹底，這也是為什么大部分車廠的EEA、架構(gòu)要分三步走，因?yàn)橹悄茏撚蚝推渌蠊δ馨踩驅(qū)崟r(shí)性要求高的域控制器還無法完美融合。而比較激進(jìn)的特斯拉，將這些異構(gòu)系統(tǒng)整合到AutoPilot系統(tǒng)中，導(dǎo)致了其系統(tǒng)安全性、實(shí)時(shí)性等均受到影響。目前，絕大部分整車廠下一代車型的EEA雖然選擇了中央計(jì)算平臺(tái)的架構(gòu)，但智能座艙部分要么是以外設(shè)子板的形式存在，要么還是獨(dú)立的域控制器。

相對(duì)于硬件架構(gòu)，軟件，尤其是操作系統(tǒng)的集中化趨勢(shì)比較明顯。在中控娛樂系統(tǒng)領(lǐng)域，Android的優(yōu)勢(shì)愈加明顯，除了國(guó)內(nèi)幾乎全線使用Android外，歐美的幾大車廠都開始放棄原來的自有系統(tǒng)或GENIVI系統(tǒng)，轉(zhuǎn)向Android。國(guó)內(nèi)的斑馬OS背靠少數(shù)幾家車廠和阿里的生態(tài)，維持著一定的份額，豐田還在堅(jiān)守自己發(fā)起的AGL（Automotive Grade Linux，面向整個(gè)汽車行業(yè)的開源平臺(tái)）聯(lián)盟，Windows、QNX等系統(tǒng)則基本退出這個(gè)領(lǐng)域了。不得不說，Android依靠手機(jī)市場(chǎng)培育出來的開發(fā)者生態(tài)，基本可以碾壓其他OS，尤以中國(guó)市場(chǎng)為最。試想一下，某互聯(lián)網(wǎng)企業(yè)開發(fā)出一款A(yù)ndroid版的手機(jī)App，通過簡(jiǎn)單適配就可以移植到車機(jī)上，這個(gè)性價(jià)比可以接受。但假如需要投入大量人力、物力，去重新開發(fā)一個(gè)Linux版，卻只能獲得最多幾十萬用戶，這個(gè)賬肯定不劃算。AGL就面臨這個(gè)問題，它的生態(tài)環(huán)境不足以支撐OS繼續(xù)下去，也許學(xué)學(xué)Windows和鴻蒙，兼容Android應(yīng)用是條活下去的路。

座艙以外的系統(tǒng)我們一般會(huì)從內(nèi)核和中間件層來分析。這些域用的都是實(shí)時(shí)操作系統(tǒng)（RTOS），如BlackBerry的QNX，Green Hills Software的INTEGRITY、RTLinux等。出于功能安全的要求，這些系統(tǒng)中大部分設(shè)計(jì)和實(shí)現(xiàn)都是“久經(jīng)考驗(yàn)”的商業(yè)操作系統(tǒng)。例如，QNX就通過了ISO26262的ASIL-D級(jí)別認(rèn)證（D級(jí)為最高等級(jí)要求）。當(dāng)然RTLinux不屬于“大部分”，因?yàn)長(zhǎng)inux的數(shù)百萬行代碼，如果都按照ISO26262的要求過一遍，合格的最后剩不了幾行，單就內(nèi)存靜態(tài)分配這一條就過不去。

而中間件層，針對(duì)自動(dòng)駕駛域，目前有ROS2（RobotOperating System，機(jī)器人操作系統(tǒng)）、Autoware、Apollo等架構(gòu)。由于自動(dòng)駕駛對(duì)于大數(shù)據(jù)量（圖像數(shù)據(jù)和雷達(dá)數(shù)據(jù)）的傳輸和低延時(shí)（10ms級(jí)）的要求，這些架構(gòu)都專注于數(shù)據(jù)傳輸和實(shí)時(shí)性上，使自動(dòng)駕駛域的感知、決策和控制部分能夠更好地協(xié)作。

對(duì)于傳統(tǒng)車身控制這部分，仍然是AUTOSAR（汽車開放系統(tǒng)架構(gòu)）的天下，只不過慢慢從AUTOSAR Classic?Platform（AUTOSAR CP）演變?yōu)锳UTOSAR Adaptive?Platform（AUTOSAR AP）。說起AUTOSAR，可以算是“軟件定義汽車”的原始版本，研發(fā)人員用開發(fā)工具把汽車信號(hào)、硬件環(huán)境等配置寫到配置文件，通過AUTOSAR的編譯器，生成一堆代碼和中間件模塊，再自動(dòng)編譯成MCAL（Microcontroler Abstraction Layer，中間件模塊），與BSW（Basic Software ，硬件支持模塊）RTE（Runtime environment，運(yùn)行環(huán)境）和App一起鏈接成ECU的固件（Firmware），可以說研發(fā)人員就是通過一堆參數(shù)，“定義”了一個(gè)汽車的部件——ECU。

然而，這個(gè)理念跟我們提到的“軟件定義汽車”是背道而馳的。AUTOSAR體現(xiàn)的是軟件決定論，也就是研發(fā)人員決定了定義，定義決定了汽車，這背后是工業(yè)時(shí)代技術(shù)人員的傲慢。而“軟件定義汽車”是適者生存論，所謂的“定義”是動(dòng)態(tài)的，會(huì)根據(jù)外部的反饋不斷調(diào)整、改進(jìn)，達(dá)到更優(yōu)的狀態(tài)，這背后是信息時(shí)代的新思維。

AUTOSAR AP也沒有從根本上改變AUTOSAR，因此我個(gè)人的觀點(diǎn)是：在目前域控制器融合階段，智能駕駛和車身控制分開的情況下，自動(dòng)駕駛系統(tǒng)和AUTOSAR系統(tǒng)會(huì)各司其職。到中央計(jì)算平臺(tái)階段，AUTOSAR的地位會(huì)逐漸不保，有可能會(huì)被SOA取代。

為什么是SOA？

既然提到了SOA，我們就展開來說說汽車系統(tǒng)中的SOA。SOA并非新概念，在2000年左右IT界就已經(jīng)存在，那為什么在時(shí)隔20年之后又被提出來了？綜合內(nèi)外部因素，有以下幾個(gè)原因。

硬件算力提升，使得SOA成為可能

因?yàn)閭鹘y(tǒng)ECU一般都是MCU（Microcontroller Unit，微控制單元）主控，算力不足，甚至都沒有操作系統(tǒng)，不足以支撐SOA這種沉重的架構(gòu)。隨著汽車智能化和網(wǎng)聯(lián)化，汽車芯片的算力大大提升，新的域控制器或中央計(jì)算平臺(tái)都是基于SoC（System on a Chip，系統(tǒng)級(jí)芯片）的，算力已經(jīng)超過手機(jī)，直逼PC，因此能夠支撐SOA架構(gòu)。

車載以太網(wǎng)的發(fā)展是個(gè)催化劑

原本大量ECU分布式的系統(tǒng)，通過不同的總線CAN（Controller Area Network，控制器局域網(wǎng)）、LIN（Local Interconnect Network，區(qū)域互聯(lián)網(wǎng)絡(luò)）、Flexray等和特定的通信協(xié)議棧連接到一起，連接復(fù)雜度隨著ECU數(shù)量增加呈指數(shù)級(jí)上升。一方面，通過減少ECU的數(shù)量，集中到域控制器和中央計(jì)算器，這是一個(gè)方法；另一方面，車載以太網(wǎng)相關(guān)的技術(shù)，如TSN（Time Sensitive Network，時(shí)間敏感網(wǎng)絡(luò)）/AVB（AudioVideo Bridging，數(shù)字音頻傳輸網(wǎng)絡(luò)）等技術(shù)，使得原本以太網(wǎng)上車的問題（延時(shí)高、丟包率高等）得到一定程度的解決，基于IP的通信會(huì)取代原有大部分的CAN、LIN總線，減少線束成本和空間。相應(yīng)地，軟件上需要配合這個(gè)變化，將這些ECU的功能集成到系統(tǒng)中，這就是SOA起到的作用。

在智能座艙概念剛剛興起時(shí)，可以看到整個(gè)座艙域里充斥著各種RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）的方法，每個(gè)原本的ECU都在按照自己的方式搭建與其他ECU的連接。SOA的優(yōu)勢(shì)在于，它可以用統(tǒng)一的方式將原本ECU的功能定義成一個(gè)個(gè)Service，并且通過注冊(cè)、發(fā)現(xiàn)的方式集成到系統(tǒng)中，讓其他的組件可以調(diào)用。

汽車網(wǎng)聯(lián)化帶來的影響

隨著車云連接，呈現(xiàn)的車、云、路、人一體化的趨勢(shì)，對(duì)系統(tǒng)架構(gòu)提出了新的要求，原本只是汽車內(nèi)部的架構(gòu)已經(jīng)無法解決這個(gè)問題。例如，在車上播放音樂，以前只有CD、U盤時(shí)比較簡(jiǎn)單，本地實(shí)現(xiàn)兩個(gè)播放器引擎就可以。但現(xiàn)在加入了大量的在線音樂服務(wù)提供商，還可以通過手機(jī)播、車機(jī)放，這樣情況就會(huì)復(fù)雜很多，如果每一種音樂源都要重新開發(fā)一套軟件，開發(fā)維護(hù)成本會(huì)倍增。

前面提到過，傳統(tǒng)車廠和供應(yīng)商還在用RPC解決問題。但既然車云一體了，為什么不試著用云的方式解決問題？

干脆把云端的SOA拿到終端來，大家一致搞服務(wù)化。這樣，前面音樂源的問題，就可以按照如下方式來解決：

先定義好音樂源的服務(wù)接口，本地或在線音樂，均按照同樣的方式來實(shí)現(xiàn)服務(wù)。

每個(gè)車型根據(jù)需求和定義，將需要的音樂源服務(wù)注冊(cè)到系統(tǒng)中。

現(xiàn)在只需要一個(gè)統(tǒng)一的播放器，就可以自由切換音樂源和對(duì)應(yīng)的服務(wù)。這樣，音樂源管理的問題就被簡(jiǎn)單化了。當(dāng)然，實(shí)際的使用場(chǎng)景要復(fù)雜得多，但越復(fù)雜的場(chǎng)景，越需要簡(jiǎn)單，因此SOA的用武之地會(huì)越來越多。

事實(shí)上，SOA的思想在很多OS內(nèi)部已經(jīng)深入滲透。例如，Android的核心就由幾十個(gè)原生服務(wù)和Java服務(wù)構(gòu)成，Android的Binder和Service Manager其實(shí)也實(shí)現(xiàn)了SOA的大部分功能。早期Windows上的COM和DCOM，甚至可以實(shí)

現(xiàn)遠(yuǎn)程服務(wù)架構(gòu)。那么，它們和SOA的區(qū)別到底在哪里？

首先，我們看兩者的相同點(diǎn)。Binder、COM的本質(zhì)是RPC，而SOA的內(nèi)核是基于RPC的（對(duì)于云端而言是ProtoBuf、RESTful、HTTPS等，對(duì)于車端而言是SOME/IP、DDS等）。

兩者的核心和關(guān)注點(diǎn)都是服務(wù)接口定義，因此不論是SOA、Binder還是COM，都定義了自己的服務(wù)/接口描述語言。一個(gè)東西需要單獨(dú)定義和開發(fā)一套語言來描述，足以說明它的重要性了，SOA架構(gòu)及工具鏈如圖2所示。

圖2 SOA架構(gòu)及工具鏈（來源：中科創(chuàng)達(dá)）

那么，不同點(diǎn)在哪里？RPC的核心問題是要解決跨進(jìn)程乃至跨系統(tǒng)通信的問題，通信的可達(dá)性、穩(wěn)定性和傳輸效率是關(guān)鍵點(diǎn)。而且RPC是點(diǎn)對(duì)點(diǎn)的，這是基于傳統(tǒng)C/S模式衍生出來的，這使很多服務(wù)在設(shè)計(jì)時(shí)，僅考慮特定的Client情況，也就是說Client和Server對(duì)應(yīng)于需要解決的問題，解決一個(gè)問題就需要一對(duì)C/S，兩者相互依存。

而SOA雖然基于RPC，但它往前走了一步，對(duì)整個(gè)系統(tǒng)業(yè)務(wù)進(jìn)行分析整理后，根據(jù)業(yè)務(wù)邏輯的分工劃分出各個(gè)服務(wù)的定義，分別實(shí)現(xiàn)后，組合成一個(gè)系統(tǒng)。這就不再是兩點(diǎn)之間的連接，而是一個(gè)網(wǎng)狀架構(gòu)。理論上，每個(gè)服務(wù)可以由不同的供應(yīng)商來實(shí)現(xiàn)，也可以被不同供應(yīng)商提供的組件來調(diào)用，這符合汽車行業(yè)的大分工原則，即每個(gè)部件都可能由不同的供應(yīng)商來提供。理論上基于SOA的架構(gòu)，不同的組件都是獨(dú)立的服務(wù)，只要滿足服務(wù)定義，經(jīng)過嚴(yán)格測(cè)試，組件就可以無縫地集成到系統(tǒng)中。在這個(gè)前提下，服務(wù)定義的完備性、接口的穩(wěn)定性、兼容性，都直接影響各個(gè)組件是否能無縫集成到系統(tǒng)中，性能和效率的優(yōu)先級(jí)就得往后靠了。

SOA帶來的組件化，使基于組件的OTA升級(jí)成為可能。這樣在理論上，一次汽車的軟件升級(jí)只需對(duì)必要的組件進(jìn)行升級(jí)，既不需要升級(jí)整個(gè)ECU或域控制器，也無須重啟整車系統(tǒng)，就不再需要停車一個(gè)多小時(shí)來升級(jí)了。有了SOA，加上OTA的加持，軟件快速迭代就成為可能，因此SOA是軟件定義汽車的重要一環(huán)。

此外，SOA使得獨(dú)立第三方軟件開發(fā)商的進(jìn)入門檻大大降低。相信很多開車的讀者也注意到了，目前中控娛樂系統(tǒng)上雖然用到很多Android的功能，但絕大多數(shù)沒有應(yīng)用商店，這點(diǎn)跟手機(jī)完全不同。如果哪個(gè)手機(jī)上沒有應(yīng)用商店，這款手機(jī)是賣不出去的。汽車之所以會(huì)出現(xiàn)這樣的現(xiàn)象，主要是由于汽車軟件行業(yè)傳統(tǒng)的封閉性，導(dǎo)致軟件在不同車型上的適配成本居高不下，甚至于同一車廠的不同車型之間的軟件都不能通用，這對(duì)于第三方軟件供應(yīng)商而言是非常不劃算的。

一款應(yīng)用只能在一兩個(gè)車型上使用，用戶群太分散，不存在推廣基礎(chǔ)，因此車機(jī)上就沒有應(yīng)用商店。而SOA出現(xiàn)以后，部分整車廠已經(jīng)看到SOA背后的標(biāo)準(zhǔn)化和跨平臺(tái)的特點(diǎn)，這兩個(gè)特點(diǎn)讓開放平臺(tái)成為可能，也就使得第三方軟件開發(fā)商甚至個(gè)人開發(fā)者進(jìn)入汽車軟件開發(fā)領(lǐng)域的門檻大大降低，更有利于構(gòu)建汽車開發(fā)生態(tài)。

更多的參與者加入進(jìn)來，也可以更好地發(fā)揮聰明才智，進(jìn)一步提升用戶體驗(yàn)。目前有相當(dāng)一部分車廠愿意向公眾開放自己的SOA服務(wù)接口，希望形成開發(fā)者社區(qū)。但單個(gè)車廠的力量是不夠的，相信未來會(huì)有一些標(biāo)準(zhǔn)化組織來主導(dǎo)這些接口的標(biāo)準(zhǔn)化，形成更大的生態(tài)。例如，可能會(huì)出現(xiàn)幾個(gè)大的服務(wù)商店和公開標(biāo)準(zhǔn)，可以讓車廠、開發(fā)者和消費(fèi)者形成交易圈。這樣車廠和開發(fā)者才能從中受益，讓這個(gè)模式運(yùn)轉(zhuǎn)下去。

當(dāng)然，這還只是理論上的，實(shí)際上想做到這點(diǎn)要復(fù)雜得多，技術(shù)上還需解決很多實(shí)際問題，如SOA固有的性能問題、各個(gè)組件之間的耦合程度、某些組件的特殊時(shí)序給系統(tǒng)帶來的“蝴蝶效應(yīng)”、部分服務(wù)升級(jí)期間系統(tǒng)如何正常運(yùn)行和恢復(fù)、升級(jí)失敗后的回滾機(jī)制等。

要解決這些問題，除了汽車業(yè)界在SOA的推進(jìn)中不斷完善服務(wù)定義，改進(jìn)架構(gòu)設(shè)計(jì)外，也需要SOA本身繼續(xù)往前走，如進(jìn)化到微服務(wù)架構(gòu)、去中心化等更完善的服務(wù)化架構(gòu)。當(dāng)然這也需要更多的技術(shù)，如虛擬化、容器化、硬件標(biāo)準(zhǔn)化、網(wǎng)絡(luò)標(biāo)準(zhǔn)化等的支持。因此，我的判斷是：會(huì)有更多的云端技術(shù)下沉到車端，推進(jìn)車端系統(tǒng)的演進(jìn)，要想定義汽車，SOA只是一個(gè)開頭。 ?

我們的工程實(shí)踐

前面說了很多概念，對(duì)于實(shí)際汽車系統(tǒng)的開發(fā)究竟有什么影響？我所在的公司是以操作系統(tǒng)技術(shù)著稱的國(guó)內(nèi)軟件企業(yè)，我們目前正在開發(fā)的智能座艙系統(tǒng)也面臨著“軟件定義汽車”的沖擊，這也直接導(dǎo)致我們的系統(tǒng)架構(gòu)不得不做一些大的變化。如圖3所示為目前基于高通SA8155平臺(tái)的Android IVI系統(tǒng)架構(gòu)設(shè)計(jì)。

圖3 基于高通SA8155平臺(tái)的Android IVI系統(tǒng)架構(gòu)設(shè)計(jì)（來源：中科創(chuàng)達(dá)）

可以看到，整個(gè)系統(tǒng)被分成了三層，分別為BSP（Board?Support Package，板級(jí)支持包）、Platform和HMI，這是一種按照從硬到軟、迭代速度從慢到快進(jìn)行分層的方式。最下層的硬件和BSP一旦出廠就不太可能更新了，因此這部分屬于迭代最慢的，一般整車廠會(huì)交給硬件一級(jí)供應(yīng)商去設(shè)計(jì)開發(fā)。

中間平臺(tái)層是操作系統(tǒng)的主要核心，這部分是目前大部分整車廠都希望把控的核心部分。它的升級(jí)類似于手機(jī)固件，因?yàn)樯婕罢麄€(gè)系統(tǒng)的性能和穩(wěn)定性，更新相對(duì)保守一些，一般更新周期為1~6個(gè)月，常見的是3個(gè)月。

最上層是應(yīng)用，深度影響用戶體驗(yàn)的軟件大部分集中在這一層，既包括車廠自己開發(fā)的軟件，也包括集成的第三方軟件。按道理，這部分應(yīng)用更新速度應(yīng)該是最快的，類似于手機(jī)上的應(yīng)用更新一樣，可以做到一日數(shù)更。但由于目前車機(jī)開發(fā)環(huán)境的封閉，以及車廠缺少自己的App分發(fā)渠道（應(yīng)用商店等），這些軟件的開發(fā)和升級(jí)還是走FOTA渠道，以跟隨系統(tǒng)一起更新為主，更新速度并沒有達(dá)到預(yù)期。這就是目前大部分主機(jī)廠推崇的軟硬分離模式，希望把軟件的核心部分把握在自己手上，而將硬件設(shè)計(jì)和制造交給硬件供應(yīng)商去做。

我們現(xiàn)在正在做的事情，就是利用組件化、服務(wù)化的方式，將整個(gè)系統(tǒng)的軟件部分拆分整合，使之更容易快速迭代。例如，我們將平臺(tái)層的部分核心服務(wù)打包成數(shù)個(gè)微服務(wù)，針對(duì)這幾個(gè)微服務(wù)，從服務(wù)定義、服務(wù)實(shí)現(xiàn)、服務(wù)驗(yàn)證到服務(wù)部署形成DevOps閉環(huán)，能夠支持服務(wù)級(jí)升級(jí)，不需要重啟系統(tǒng)（需要OS支持）。如果OTA系統(tǒng)支持部件級(jí)升級(jí)的話，這些服務(wù)就可以在不停機(jī)的情況下實(shí)現(xiàn)無感更新。

另外，我們?cè)诜?wù)接口定義上作了版本和兼容性定義，也使得更新后的兼容性得到一定程度的保護(hù)和確認(rèn)，避免了接口不兼容或數(shù)據(jù)不兼容導(dǎo)致的問題。另外對(duì)于HMI層的一部分應(yīng)用，我們結(jié)合了SOA和云原生的開發(fā)理念，在設(shè)計(jì)時(shí)按照云原生的要求，將服務(wù)設(shè)計(jì)為云端可運(yùn)行的模式，這樣應(yīng)用可以透明地在云和車端的執(zhí)行引擎上切換，充分利用云和車端的算力和存儲(chǔ)能力。

一個(gè)具體的案例是場(chǎng)景引擎（見圖4）。通過將汽車的各種開放能力定義成各項(xiàng)服務(wù)，允許場(chǎng)景引擎可以訪問到其他車端服務(wù)（感知、地圖、車身數(shù)據(jù)等），并通過SOA使得場(chǎng)景引擎能同時(shí)跑在車端和云端，可以實(shí)時(shí)根據(jù)配置向車主下發(fā)新的場(chǎng)景配置，來控制相關(guān)的車輛行為（如燈光、音樂、語音提示等）。

圖4 基于SOA的場(chǎng)景引擎（來源：中科創(chuàng)達(dá)）

這里需要特別指出的是，要想快速迭代，除了軟件架構(gòu)的變化，軟件開發(fā)流程的改革也必不可少。目前很多車廠都在嘗試構(gòu)建敏捷開發(fā)流程，來適應(yīng)“軟件定義汽車”的趨勢(shì)。但受限于整個(gè)行業(yè)對(duì)于“敏捷”的理解水平不夠，再加上汽車行業(yè)原本的流程限制，很多時(shí)候變成了所謂的“大瀑布、小敏捷”這樣的夾生飯，或者僅僅是引入Scrum Meeting、Backlog這些概念的“偽敏捷”。而我認(rèn)為，敏捷的核心是解決從需求到實(shí)現(xiàn)再到反饋的延遲問題，就目前汽車系統(tǒng)開發(fā)過程而言，主要的瓶頸在于需求、設(shè)計(jì)、編碼、發(fā)布和部署的流轉(zhuǎn)時(shí)間太長(zhǎng)。因此，我們的敏捷轉(zhuǎn)型中心集中在這幾個(gè)環(huán)節(jié)的銜接上，采用工具鏈、架構(gòu)調(diào)整、自動(dòng)化測(cè)試等手段，爭(zhēng)取達(dá)到單個(gè)組件1天內(nèi)、全系統(tǒng)3天內(nèi)完成從定義到發(fā)布的全迭代過程（目前我們還只能做到單個(gè)組件3天、全系統(tǒng)2周的迭代速度，還有不小的改進(jìn)空間）。

總結(jié)

不管怎樣，“軟件定義汽車”這個(gè)概念正在重新定義汽車行業(yè)，同時(shí)在原本封閉的汽車行業(yè)里打開了幾扇門，如新的軟件架構(gòu)、操作系統(tǒng)和軟件開發(fā)方法，這些都意味著新的機(jī)會(huì)。因此，作為具有超過35年編程經(jīng)驗(yàn)的資深程序員和汽車行業(yè)的從業(yè)人員，我衷心希望能有更多人加入到汽車軟件這個(gè)行列中來，一起為了讓汽車更智能、更好玩而努力。

審核編輯：劉清