我們現在常聽人說車上的軟件代碼要奔著2-3億行的量級去，并且列舉軟件價值在車內占比來形容“軟件定義汽車”。我們感覺這還是個不容易讓人產生概念的形容方式。

其實“軟件定義XX”這個樣式的短語一點都不稀奇。對于電子產品而言，軟件和硬件都必須同時存在——只是隨時代變遷，這兩者的角色在發生變化。我們認為，軟件定義XX的本質，是軟硬件逐步脫鉤、解耦合的過程，在任何提這個詞的領域皆如是。換句話說，應該是將原本的硬件平臺、硬編碼的固件/ROM之能力，帶入軟件層——而該軟件層跑在標準化的硬件上，也就實現了軟件定義。

“軟件定義XX”最具說服力的例子就是手機從功能機向智能機的轉變。早期，手機的硬件和軟件是在產線上就做了捆綁的——除非手機在售出后遭遇重大BUG才考慮做軟件更新。當年諾基亞手機的主芯片(CPU)就是這樣持續數代不換，依然無人置喙，與軟硬捆綁還是有很大的關系。汽車的情況又何嘗不是如此：想要汽車擁有新功能嗎?就再買輛新車吧!

如今，智能手機通過解耦軟硬件改變了這樣的模式，智能手機本身成為硬件平臺。手機制造商能夠打造定制的操作系統，并定期推送OTA更新;而更上層的應用，則千變萬化，負責著大量功能的實現。

可以說智能手機本質上就是一種“軟件定義手機”。至少在大方向上，它與“軟件定義汽車”“軟件定義網絡”“軟件定義測試測量”是一樣的。

而軟件定義XX，本身就是一個類型的設備在電子化、數字化過程中發展到高級階段的表現。汽車在電動化、電子化之路上，也要迎來這種轉變。只不過汽車這樣的復雜大件，及行業、產業鏈的特殊性，又令“軟件定義汽車”多少有些與眾不同。

軟件定義汽車，變的到底是什么?

更早年的汽車經歷了機械定義、硬件定義的時代，到如今軟件定義的說辭風生水起，實則反映的是電子科技話語權在汽車產品上的提升，以及汽車產業、電子科技二者的發展。這每一次革新，首先都意味著電子電氣(E/E)架構的變化。

從內部連接的角度來看，機械定義汽車是將車內的各種物件(如ECU、傳感器、儀表等)有需要的就點對點連起來——在E/E架構變復雜的情況下，這種方案是不可持續的;硬件定義汽車則增加了總線的概念，以分布式控制的方式來打造一個開放式系統，具備了顯著增強的靈活性。

圖1：汽車 E/E架構的演進。

但這樣的方案也逐漸不再適用當代數字化轉型的大趨勢，不同的組件各自為政，可擴展性差。就像早年的功能手機那樣，當軟硬件捆綁在一起、可擴展性又極度欠缺之時，應對需求變化就顯得相當遲緩。軟件定義汽車首先需要對E/E架構進行革命性的改變：將不同的總線、控制等做合并，做更統一的部署——也就是這兩年經?？吹絹碜圆┦赖腅/E架構演進的一張圖(圖1);將150多個ECU做各種融合，同時還要軟硬解耦，實現更強的靈活性。

舉個簡單的例子：軟件定義汽車時代，整車廠現在不再是要求傳統Tier 1供應商設計各自帶ECU的電動座椅系統出來，而是需要協調軟件開發，以通用、標準化的方式做個車內平臺——電動座椅不過是其中的一環罷了。

從另一個更抽象的角度來看，SBD Automotive將這樣的變化稱作汽車1.0到汽車4.0的發展。

汽車1.0時代是沒有任何“連接”的基礎功能汽車;汽車2.0則發展出了數字化技術，引入了信息娛樂系統(infotainment)以及數字座艙，而且提供高速連接，甚至音樂流媒體、某種程度的軟件更新——這類車目前仍然活躍于市場。

汽車3.0就是可升級的汽車了。相對重要的一些特性包括自動駕駛、ADAS、智能座艙以及車聯網等特性的引入。體現“軟件定義”的核心則在于，其中的很多特性、體驗可以更新升級;而且軟件更新會以更常規的節奏來推送。如此一來汽車也就成為并非一次性銷售產品，軟件服務和數字經濟也將成為整車廠或其它供應商的重要收益構成。

而所謂的汽車4.0，在SBD Automotive的定義中是“真正的”軟件定義汽車。屆時汽車將成為云的延伸，跑在車上的軟件可由云上的中央運行環境來進行主導控制，或者協同其它車聯網內的汽車算力，來進行高性能計算，實現自動駕駛、智慧城市等特性。這就是對未來的展望了。

技術上的變

實現軟件定義汽車，最底層的E/E架構轉變、諸多ECU融合、有個核心骨干負責整個計算域的過程，這個過程就是讓汽車從傳統E/E架構，某種程度讓汽車變身到往高性能計算機接上四個輪子的過程。絕大部分相關用戶體驗組件的軟件都放在這個高性能計算機里面。

除了E/E底層架構需要變，對應的軟件定義汽車的上層構建過程也就起來了。平臺與中間件、操作系統與虛擬化都隨之而來。畢竟在底層準備就緒以后，軟硬解耦的軟件部分也需要重新整合堆砌?；蛘哒f就像數據中心的工作方式，對外服務的過程，就需要諸多軟件層面的技術。

其中平臺與中間件層的主要功能，是對硬件進行抽象，做到軟硬解耦。那么開發者就能利用中間層的接口，來開發功能、特性，也確保這些功能特性不需要與底層硬件直接掛鉤。隨著這部分的成熟，汽車應用開發者因此可以脫離于汽車之外進行軟件的開發測試;而且不需要太多汽車方面的專業知識。與此同時，硬件遷移也變得更簡單、高效。最終實現降本增效。

圖2：AUTOSAR的參與者。

當代軟件定義汽車發展的中間件代表為AUTOSAR(Automotive Open System Architecture)——這是個由諸多整車廠、零部件企業聯合制定的軟件標準化接口，或者說開放式系統架構標準。加入標準中的企業不僅有傳統汽車產業相關的企業，也有工具與服務及半導體相關廠商，比如說英飛凌、瑞薩、恩智浦、Arm、西門子 EDA等等。因為這本身就是需要上下游充分協同的。值得一提的是，中間件相關的一個重要組成部分是SOA(Service Orimented Communication)模型通信中間件，這是另一個很大的話題了。

理想情況下，平臺與中間件層出現的另一個重要價值，也在于構建更為統一的平臺。車企、開發者不需要忙于去處理各種類型的硬件。用其他行業的話來說，叫盡可能地解決“碎片化”問題，雖然這可能也只是理想情況。

至于操作系統與虛擬化，很多車企如今都在這方面發力，比如說大眾汽車的vw.os。軟件定義汽車可能會跑多個操作系統，負責不同的工作——比如說會有實時操作系統，會有通過AUTOSAR-Adaptive提供傳感器數據處理的Linux操作系統等。

前兩年我們撰文談過BlackBerry QNX，這似乎是個更能表達軟件定義汽車的、介于底層硬件和上層應用之間的組成部分的技術。當時面向汽車領域的BlackBerry QNX至少包括了QNX Neutrino OS(操作系統)、QNX Platform for ADAS(針對ADAS的平臺)、QNX OS for Safety(安全操作系統)、QNX CAR Platform for Infotainment(針對汽車信息娛樂系統的平臺)、QNX Hypervisor、QNX acoustics middleware(聲學中間件)。

圖3：BlackBerry QNX技術及各部分所在的層級。

藉由圖3這張來自BlackBerry的圖，可簡單窺見其中部分軟件的層級結構。

當然這其中實則也出現了其他層級，在往上層還牽扯到車廠品牌差異化的組成部分，涵蓋信息娛樂系統、數字座艙系統、ADAS系統等。這些應用的發展也配合著對云服務的支持。而云會是整個架構的最上層，包括了ADAS服務、OTA服務等。當然支撐這個最上層的，也需要5G、V2X等基礎設施。

圖4：汽車未來的層級架構。(圖片來源：McKinsey&Company)

對這部分技術感興趣的讀者，可以去看一看2019年麥肯錫發布的《重新思考汽車軟件與電子設備架構》報告，其中提到ECU加速融合、不同棧的標準化、中間件層對硬件做抽象等趨勢。這些趨勢都是在持續行進中的。從中我們也能夠看出，為什么軟件的價值在整車中占比越來越高，以及2-3億行代碼緣何而來。

新的參與者，和產業鏈結構的變

或許很多駕車者認為軟件更新沒什么了不得，并不值得大書特書。但我們展望中的OTA對于軟件的更新，并不僅限于信息娛樂系統、遠程信息處理或車輛診斷系統(而且傳統的這些軟件更新還并非OTA)，更多的會往汽車核心功能的監控、調節去走，比如說動力系統?；蛟S在未來的OTA更新過后，轉向系統就能實現更精準的控制，ADAS獲得輔助公路駕車的新特性，甚至基于電池循環周期的分析來實現續航里程的增加，以及在汽車發售之初根本沒有想到，或受限于開發生命周期、尚未完成的新特性。

比較典型的例子是特斯拉曾經通過OTA更新，降低了Model 3的制動距離。這種轉變事實上帶來前文提到的，汽車不再是一次性消費產品，汽車產業也能夠開始從提供的數字服務甚至更新中獲利。去年Arm曾表示軟件定義汽車，可以為車廠創造每輛車“多達2600-7500美金的額外利潤”。對車企而言，OTA也意味著部分特性、功能開發周期的放寬(典型如自動駕駛這類很難與整車研發周期配合到位的組成)。

未來、甚至今天的汽車消費用戶會更加注重“軟件定義”部分，比如說駕駛輔助特性、信息娛樂系統上的數字內容，乃至智能連接解決方案;而將更少的注意力放在諸如排氣系統之類的機械特性上。前不久我們在采訪黑芝麻智能之時，黑芝麻就談到，一些4S店反饋現在已經開始有購車者問車的算力是“多少T了”——AI芯片本身也可認為是軟件定義汽車的重要組成部分。

以上這兩點：軟件更新帶來的新特性、消費者注意力轉變，都能夠管中一窺地發現，汽車產業正在發生變化。至少這是業務模型的變化。

從最簡單的層面來看，汽車電子化及軟件定義的特性，為行業帶來了新的參與者。比較典型的除了前文提到的BlackBerry，還有像是Red Hat。Red Hat將軟件定義汽車比作邊緣計算服務器，且明確這樣的邊緣設備理應包含現代基于Linux的操作系統和生態——必須包含開源與專有組件。Red Hat自認可從行業分一杯羹的根源在于其擅長包括Linux、容器、中間件集成、DevOps架構等在內的能力，甚至把原本構建企業開源層的經驗帶到汽車上。

圖5：SOAFEE框架結構及組成。(圖片來源：Arm)

另一個我們認為頗具代表性的市場參與者是Arm。去年我們也特別報道了Arm提出的SOAFEE(Scalable Open Architecture For Embedded Edge)架構：這是在軟件定義汽車一詞正火之際，趁熱打鐵提出的統一的軟件定義汽車平臺。畢竟軟件定義汽車的技術棧復雜度、投入是相當高的。SOAFEE構建起了框架，和整個軟件棧中的基礎軟件部分和參考實施方案;且明確了功能與服務在云端環境中開發、測試和驗證——這和前文談到SBD定義的汽車4.0趨勢相符。

SOAFEE的本質是要實現硬件和軟件界面的標準化。而且作為一個開放、開源的架構，底層硬件部分Arm也準備吸收不同的硬件、IP。這個架構據說也得到了不少包括整車廠、Tier 1供應商，乃至軟件、半導體和云技術相關企業的關注和加入。SOAFEE的出現至少讓我們能看到，軟件定義汽車步入成熟的開端(雖然由Arm這個傳統意義上的芯片設計IP供應商提出，還是讓人感覺頗為意外)。

這些新角色的加入，事實上就會造成產業鏈價值分配的變化，乃至產業鏈結構的重整。在“軟件定義汽車”的“軟件”一詞上，越來越多的車企開始投入人力物力：造車新勢力本就在這方面發力，傳統車企也不甘落后。比如去年下半年，豐田就宣布要投入超過18000人進行軟件和連接計劃。

要知道其中的某些工作原本應該是由Tier 1供應商承擔的。以前整車廠會對Tier 1供應商提出具體的組件需求，供應商不僅要整合包括控制器在內的硬件，也需要進行軟件開發和測試。那么在軟件定義汽車大趨勢展開后，汽車制造商可能會選擇開發大部分所需軟件，甚至有自己的平臺、特定的一群軟件合作伙伴;則Tier 1供應商此后就需要對自己做重新定位。

現在Tier 0.5這個詞也被時常提起，某些Tier 1供應商會讓企業內的專家與整車廠的開發團隊協作，聯合開發軟件并做運維(也有Tier 2也在變身Tier 0.5)。在此，供應商幾乎成為OEM廠商的一部分，也從系統集成中產生營收。博世就有這樣的例子。在軟件定義汽車做標準接口、整車廠自己解決軟件問題或找三方軟件合作伙伴開發應用之際，許多傳統的Tier 1特別害怕自己淪為單純的硬件供應商。

去年年末的Aspencore國際汽車電子創新發展論壇上，均勝電子曾表示從過去OEM廠商直接拿turn-key方案，到如今主導軟件硬件定義。從過去Tier 1負責40%個性化開發、60%標準開發，到現在做100%的標準開發;“Tier 1將專注于模塊化、平臺化的開發，模塊迭代速度大幅提升;更高的標準化支持，同時服務更多客戶;且Tier 1將逐漸頭部化”。而對Tier 2而言，“集成化程度越來越高，技術難度越來越大，通過技術壁壘才能形成行業優勢”。

可見汽車產業鏈的不同角色職能是在發生變化的，尤其傳統汽車產業的供應鏈上游似乎變得更不好“混”了。

技術難度之外的發展阻礙

具備“革命”能力的事物，在革命的同時必然遭遇阻礙。諸多傳統車廠存在歷史悠久，組織機構龐大復雜，有些還牽扯很多品牌。他們早有一套特定的工作方式在推進。而軟件定義汽車，如前文所述需要全新的方式和思維來重新考慮汽車開發生命周期的問題，還需要車廠具備全新的能力。

則對傳統車廠而言，轉變的第一步就是自我調整，打造新的工作流程和業務模型;而且需要進行現有員工的技能培訓，以及擴招原屬于其他領域的人才;并尋找新的合作伙伴。這些大約都不是一朝一夕的。單是在E/E架構上做大改，技術之外更多面臨的可能仍是現實中人的阻礙。

與此同時，如前文所述舊時代的產業鏈和配合方式很可能已經不再適用于軟件定義汽車時代。則整車廠、Tier 1、Tier 2、Tier 3等不同層級供應商之間的合作、博弈還將做出新的調整，市場或許還會有新的發展方向。

另外本文仍有許多相關軟件定義汽車的關鍵部分未曾提及，比如說網絡安全(cybersecurity)——這必將成為軟件定義汽車時代的技術熱點與難點。不僅是改變開發流程，而且也會引入新的市場參與者和發展熱點。

“軟件定義汽車”這一局的“變”屬實還有的瞧。

審核編輯 ：李倩