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

軟件定義汽車不是口號

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么是SOA？

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

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

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

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

原本大量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ù)級上升。一方面，通過減少ECU的數(shù)量，集中到域控制器和中央計算器，這是一個方法；另一方面，車載以太網(wǎng)相關(guān)的技術(shù)，如TSN（Time Sensitive Network，時間敏感網(wǎng)絡(luò)）/AVB（AudioVideo Bridging，數(shù)字音頻傳輸網(wǎng)絡(luò)）等技術(shù)，使得原本以太網(wǎng)上車的問題（延時高、丟包率高等）得到一定程度的解決，基于IP的通信會取代原有大部分的CAN、LIN總線，減少線束成本和空間。相應(yīng)地，軟件上需要配合這個變化，將這些ECU的功能集成到系統(tǒng)中，這就是SOA起到的作用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們的工程實踐

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

審核編輯：劉清