“軟件定義汽車”最關鍵的環節是SOA（Service-Oriented Architecture，面向服務的架構）。基于硬件算力提升、車載以太網的發展，以及汽車網聯化帶來的影響，SOA在二十年后將被重新召喚。

軟件定義汽車不是口號

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

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

然而，并非所有人都贊同“軟件定義汽車”，有一種意見就認為，這不過是IT行業進入汽車領域的宣傳，硬件和制造仍然是汽車行業賴以生存的基礎，或者認為軟件必須要基于電子電氣架構的算力才能充分發揮作用，所謂軟件定義汽車才能實現。

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

換句話說，軟件并不會取代硬件和制造環節，但軟件會成為其他環節改進、發展和演進的方向標，包括電子電氣架構（EEA）、汽車研發過程等都在發生著的變化。

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

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

汽車系統的發展趨勢

在“軟件定義汽車”的推動下，汽車電子電氣系統的演進呈現兩大新趨勢：一方面是用戶體驗上的提升，包括對用戶行為的感知能力提升和交互能力的智能化改進，如DMS（Driver Monitor System，駕駛員監測系統）、語音交互、炫酷的HMI（Human Machine Interface，人機界面）等；另一方面是整車異構系統趨向標準化、虛擬化和服務化，如EEA架構的集中化和軟件架構的SOA化。大量ECU將被集成到中央計算平臺上，變成一個獨立的Service加子板上的一個外設。

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

由于這些差異性，到目前為止整車系統的融合沒法做到徹底，這也是為什么大部分車廠的EEA、架構要分三步走，因為智能座艙域和其他要求功能安全或實時性要求高的域控制器還無法完美融合。而比較激進的特斯拉，將這些異構系統整合到AutoPilot系統中，導致了其系統安全性、實時性等均受到影響。目前，絕大部分整車廠下一代車型的EEA雖然選擇了中央計算平臺的架構，但智能座艙部分要么是以外設子板的形式存在，要么還是獨立的域控制器。

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

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

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

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

然而，這個理念跟我們提到的“軟件定義汽車”是背道而馳的。AUTOSAR體現的是軟件決定論，也就是研發人員決定了定義，定義決定了汽車，這背后是工業時代技術人員的傲慢。而“軟件定義汽車”是適者生存論，所謂的“定義”是動態的，會根據外部的反饋不斷調整、改進，達到更優的狀態，這背后是信息時代的新思維。

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

為什么是SOA？

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

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

因為傳統ECU一般都是MCU（Microcontroller Unit，微控制單元）主控，算力不足，甚至都沒有操作系統，不足以支撐SOA這種沉重的架構。隨著汽車智能化和網聯化，汽車芯片的算力大大提升，新的域控制器或中央計算平臺都是基于SoC（System on a Chip，系統級芯片）的，算力已經超過手機，直逼PC，因此能夠支撐SOA架構。

車載以太網的發展是個催化劑

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

在智能座艙概念剛剛興起時，可以看到整個座艙域里充斥著各種RPC（Remote Procedure Call，遠程過程調用）的方法，每個原本的ECU都在按照自己的方式搭建與其他ECU的連接。SOA的優勢在于，它可以用統一的方式將原本ECU的功能定義成一個個Service，并且通過注冊、發現的方式集成到系統中，讓其他的組件可以調用。

汽車網聯化帶來的影響

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

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

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

先定義好音樂源的服務接口，本地或在線音樂，均按照同樣的方式來實現服務。

每個車型根據需求和定義，將需要的音樂源服務注冊到系統中。

現在只需要一個統一的播放器，就可以自由切換音樂源和對應的服務。這樣，音樂源管理的問題就被簡單化了。當然，實際的使用場景要復雜得多，但越復雜的場景，越需要簡單，因此SOA的用武之地會越來越多。

事實上，SOA的思想在很多OS內部已經深入滲透。例如，Android的核心就由幾十個原生服務和Java服務構成，Android的Binder和Service Manager其實也實現了SOA的大部分功能。早期Windows上的COM和DCOM，甚至可以實

現遠程服務架構。那么，它們和SOA的區別到底在哪里？

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

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

圖2 SOA架構及工具鏈（來源：中科創達）

那么，不同點在哪里？RPC的核心問題是要解決跨進程乃至跨系統通信的問題，通信的可達性、穩定性和傳輸效率是關鍵點。而且RPC是點對點的，這是基于傳統C/S模式衍生出來的，這使很多服務在設計時，僅考慮特定的Client情況，也就是說Client和Server對應于需要解決的問題，解決一個問題就需要一對C/S，兩者相互依存。

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

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

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

一款應用只能在一兩個車型上使用，用戶群太分散，不存在推廣基礎，因此車機上就沒有應用商店。而SOA出現以后，部分整車廠已經看到SOA背后的標準化和跨平臺的特點，這兩個特點讓開放平臺成為可能，也就使得第三方軟件開發商甚至個人開發者進入汽車軟件開發領域的門檻大大降低，更有利于構建汽車開發生態。

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

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

要解決這些問題，除了汽車業界在SOA的推進中不斷完善服務定義，改進架構設計外，也需要SOA本身繼續往前走，如進化到微服務架構、去中心化等更完善的服務化架構。當然這也需要更多的技術，如虛擬化、容器化、硬件標準化、網絡標準化等的支持。因此，我的判斷是：會有更多的云端技術下沉到車端，推進車端系統的演進，要想定義汽車，SOA只是一個開頭。 ?

我們的工程實踐

前面說了很多概念，對于實際汽車系統的開發究竟有什么影響？我所在的公司是以操作系統技術著稱的國內軟件企業，我們目前正在開發的智能座艙系統也面臨著“軟件定義汽車”的沖擊，這也直接導致我們的系統架構不得不做一些大的變化。如圖3所示為目前基于高通SA8155平臺的Android IVI系統架構設計。

圖3 基于高通SA8155平臺的Android IVI系統架構設計（來源：中科創達）

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

中間平臺層是操作系統的主要核心，這部分是目前大部分整車廠都希望把控的核心部分。它的升級類似于手機固件，因為涉及整個系統的性能和穩定性，更新相對保守一些，一般更新周期為1~6個月，常見的是3個月。

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

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

另外，我們在服務接口定義上作了版本和兼容性定義，也使得更新后的兼容性得到一定程度的保護和確認，避免了接口不兼容或數據不兼容導致的問題。另外對于HMI層的一部分應用，我們結合了SOA和云原生的開發理念，在設計時按照云原生的要求，將服務設計為云端可運行的模式，這樣應用可以透明地在云和車端的執行引擎上切換，充分利用云和車端的算力和存儲能力。

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

圖4 基于SOA的場景引擎（來源：中科創達）

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

總結

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

審核編輯：劉清