軟體定義汽車時代變的何止是車
2022-03-24
作者
黃燁鋒
更早年的汽車經歷了機械定義、硬體定義的時代，到如今軟體定義的說辭風生水起，實則反映的是電子科技話語權在汽車產品上的提升，以及汽車產業、電子科技二者的發展。
現在常聽人說車上的軟體程式碼要朝著2~3億行的量級發展，並且列舉軟體價值在車內佔比來形容「軟體定義汽車」，令人感覺這還是個不容易讓人產生概念的形容方式。其實「軟體定義XX」這樣的短語一點都不稀奇，對於電子產品而言，軟體和硬體都必須同時存在——隨時代變遷，這兩者的角色在發生變化。
筆者認為，軟體定義XX的本質，是軟硬體逐步脫鉤、解耦合的過程，在任何提這個詞的領域皆如是。換句話說，應該是將原本的硬體平台、硬編碼的韌體/ROM之能力，帶入軟體層——而該軟體層跑在標準化的硬體上，也就實現了軟體定義。
「軟體定義XX」最具說服力的例子就是手機從功能型朝智慧的轉變。在本世紀初期以前，手機的硬體和軟體是在產線上就綁定了——除非手機在售出後遭遇重大Bug才考慮進行軟體更新。
這和過去甚至現在的大部分汽車是類似的：想要汽車擁有新功能嗎？買輛新車吧。如當年諾基亞(Nokia)手機的主晶片(CPU)持續數代不換，依然無人置喙，與軟硬綁定還是有很大的關係。智慧型手機透過解耦軟硬體改變了這樣的模式，智慧型手機本身成為硬體平台。手機製造商能夠打造客製的作業系統，並定期推送OTA更新；而更上層的應用則千變萬化，負責大量功能的實現。
可以說智慧型手機本質上就是一種「軟體定義手機」。至少在大方向上，它與「軟體定義汽車」、「軟體定義網路」、「軟體定義測試測量」是一樣的。
而軟體定義XX，本身就是某個類型的設備在電子化、數位化過程中發展到高階階段的表現。汽車在電動化、電子化之路上，也要迎來這種轉變。只不過汽車這樣的複雜系統，以及產業鏈的特殊性，又使「軟體定義汽車」多少有些與眾不同。
軟體定義汽車該如何定義？
軟體定義汽車變的到底是什麼？
更早年的汽車經歷了機械定義、硬體定義的時代，到如今軟體定義的說辭風生水起，實則反映的是電子科技話語權在汽車產品上的提升，以及汽車產業、電子科技二者的發展。這每一次革新，首先都意味著電子電氣架構(E/E)的變化。
從內部連接的角度來看，機械定義汽車是將車內的各種物件(如ECU、感測器、儀錶等)有需要的就點對點連起來——在E/E架構變複雜的情況下，這種方案是不可持續的；硬體定義汽車則增加了匯流排的概念，以分散式控制的方式來打造一個開放式系統，具備了顯著增強的靈活性。
但這樣的方案也逐漸不再適用當代數位化轉型的大趨勢，不同的組件各自為政，可擴展性差。就像早年的功能型手機那樣，當軟硬體綁定在一起、可擴展性又極度欠缺之時，應對需求變化就顯得相當遲緩。軟體定義汽車首先需要對E/E架構進行革命：將不同的匯流排、控制等合併，做更統一的部署——也就是這兩年經常看到來自博世(Bosch)的E/E架構演進的一張圖(圖1)；將150多個ECU做各種融合，同時還要軟硬解耦，實現更強的靈活性。
圖1：E/E架構演化。
(來源：博世)
舉個簡單的例子：軟體定義汽車時代，整車廠現在不再是要求傳統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底層架構需要變，對應的軟體定義汽車的上層建構過程也就起來了。平台與中介軟體、作業系統與虛擬化都隨之而來，畢竟在底層準備就緒以後，軟硬解耦的軟體部分也需要重新整合堆砌。或者說就像資料中心的工作方式，對外服務的過程，就需要諸多軟體層面的技術。
其中平台與中介軟體層的主要功能，是對硬體進行抽象，做到軟硬解耦。那麼開發者就能利用中間層的介面，來開發功能、特性，也確保這些功能特性不需要與底層硬體直接掛鉤。隨這部分的成熟，汽車應用開發者因此可以脫離於汽車之外進行軟體的開發測試；而且不需要太多汽車方面的專業知識。與此同時，硬體遷移也變得更簡單、高效。最終實現降低成本、增加效能。
圖2：AUTOSAR的參與者們。
當代軟體定義汽車發展的中介軟體代表為AUTOSAR (Automotive Open System Architecture)——這是個由諸多整車廠、零組件企業聯合制定的軟體標準化介面，或者說開放式系統架構標準。加入標準中的企業不僅有傳統汽車產業相關的企業，也有工具與服務及半導體相關廠商，例如英飛凌(Infineon)、瑞薩(Renesas)、恩智浦(NXP)、Arm、Mentor…等，因為這本身就是需要上下游充分協同合作的。值得一提的是，中介軟體相關的一個重要組成部分是SOA (Service-Oriented Architecture)模型通訊中介軟體。
理想情況下，平台與中介軟體層出現的另一個重要價值，也在於建構更為統一的平台。車企、開發者不需要忙於處理各種類型的硬體，用其他產業的話來說，是盡可能地解決「碎片化」問題，雖然這可能也只是理想情況。
至於作業系統與虛擬化，很多車企如今都在這方面發力，比如說大眾汽車的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，可簡單窺見其中部分軟體的層級結構。當然這其中實則也出現了其他層級，在往上層還牽扯到車廠品牌差異化的組成部分，涵蓋資訊娛樂系統、數位座艙系統、ADAS系統等。這些應用的發展也配合著對雲端服務的支援。而雲端會是整個架構的最上層，包括了ADAS服務、OTA服務等。當然支撐這個最上層的，也需要5G、V2X等基礎設施。
圖3：BlackBerry QNX技術及各部分所在的層級。
(來源：BlackBerry)
對這部分技術感興趣的讀者，可以去看一看2019年麥肯錫(McKinsey & Company)發佈的《重新思考汽車軟體與電子設備架構》報告，其中提到ECU加速融合、不同堆疊的標準化、中介軟體
層對硬體進行抽象等趨勢。這些趨勢都是在持續行進中的。從中也能夠看出，為什麼軟體的價值在整車中佔比越來越高，以及2~3億行程式碼緣何而來。
2
圖4：汽車未來的層級架構。
(來源：McKinsey & Company)
新的參與者和產業鏈結構的變
或許很多駕車者認為軟體更新沒什麼了不得，並不值得大書特書。但展望中的OTA對於軟體的更新，並不僅限於資訊娛樂系統、遠端資訊處理或車輛診斷系統(而且傳統的這些軟體更新還並非OTA)，更多的會往汽車核心功能的監控、調節等方向前進，例如動力系統。或許在未來的OTA更新過後，轉向系統就能實現更精準的控制，ADAS獲得輔助公路駕車的新特性，甚至基於電池迴圈週期的分析來實現續航里程的增加，以及在汽車發售之初根本沒有想到，或受限於開發生命週期、尚未完成的新特性。
比較典型的例子是特斯拉(Tesla)曾經利用OTA更新，降低了Model 3的剎車距離。這種轉變事實上帶來前面提到的，汽車不再是一次性消費產品，汽車產業也能夠開始從提供的數位服務甚至更新中獲利。去年Arm曾表示軟體定義汽車，可以為車廠創造每輛車「多達2,600~7,500美元的額外利潤」。對車企而言，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供應商提出，還是讓人感覺頗為意外)。
這些新角色的加入，事實上就會造成產業鏈價值分配的變化，乃至產業鏈結構的重整。在「軟體定義汽車」的「軟體」一詞上，越來越多的車企開始投入人力物力：造車新勢力本就在這方面發力，傳統車企也不甘落後。比如去年下半年，豐田(Toyota)就宣佈要投入超過18,000人進行軟體和連接計畫。
要知道其中的某些工作原本應該是由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)——這必將成為軟體定義汽車時代的技術熱點與難點。不僅是改變開發流程，而且也會導入新的市場參與者和發展熱點。
「軟體定義汽車」這一局的 「變」屬實還有的瞧。
本文同步刊登於《電子工程專輯》雜誌2022年3月號
