概要

無論是車載娛樂軟件、駕駛輔助軟件還是自動駕駛軟件，軟件的加持為汽車行業和用戶帶來了巨大的好處和便利。然而，正如機械零件需要清潔、潤滑和更換一樣，軟件也需要維護。

原始設備制造商（OEM）和一級供應商也許十分擅長挑選方便定期保養（如更換發動機的機油或者正時鏈）的汽車零件，但對于汽車軟件，卻很可能無從下手。

隨著軟件功能越來越復雜，如果現在選擇的軟件架構不合適，未來幾年可能就需要付出高昂的軟件維護費。因此，原始設備制造商和一級供應商必須重視車載軟件系統及軟件架構，并將軟件所需的定期維護（如軟件安全漏洞補丁或軟件升級）納入考慮范圍。

在本文中介紹如何確保軟件定義汽車配備最先進的安全和安保解決方案，同時闡述使用開源軟件的重要性——不僅能讓原始設備制造商專注于開發下一代應用、滿足消費者需求，還能控制成本。

引言

軟件定義汽車行業的U形賽道

過去的幾年里，汽車電氣化和自動駕駛領域取得了飛速發展，汽車行業所面臨的主要挑戰由機械零件轉為電子系統和車載軟件。

以前，汽車設計階段出現的問題往往與機械零件相關。為了保證機械零件的充足供應，原始設備制造商通常會與一級供應商和二級供應商簽訂長期協議，保證在某款汽車停產后的至少十年內市面上仍有相應零件可供替換。當汽車需要維修保養時，處在價值鏈末端的最終消費者將間接向一級和二級供應商支付零件的費用，直至車輛使用壽命結束。

隨著“軟件定義汽車”逐漸成為汽車產業的主要發展趨勢，汽車設計過程中需要解決的問題也多與軟件相關，也與最終消費者更密切相關。每一位車主都希望在汽車安全得到保障的同時，享受最新推出的功能，但很少有車主愿意頻繁為安全功能更新付費。

日新月異的市場變化迫使汽車行業奮起直追，緊跟發展趨勢。這一點，從雷諾或大眾等公司軟件工程部門驚人的部門擴張中可見一斑。 “在2011年時，雷諾和大眾公司甚至找不出一個內部軟件工程師”，而如今，這兩家知名車企都各自擁有一支龐大的軟件工程師團隊。

與此同時，供應商也爭相組建自己的軟件工程部門。以生產出全球首款溝紋汽車輪胎的德國大陸集團為例，該公司僅2021年一年就投入3100萬歐元用于公司內部開發軟件 。大陸汽車技術核心業務部門（分為車輛網聯技術（VNI）、自動駕駛及安全技術（AMS）業務單元）擁有約89,000名員工，而輪胎業務部門現在只有約57,000名員工。大陸集團并非特例，知名的雨刷系統和燈光照明系統供應商法雷奧集團以及知名排氣系統供應商馬瑞利公司都采取了相似的措施，擴大其在電子解決方案和軟件領域的專業優勢。

盡管各個公司都紛紛組建自己的軟件部門，但不得不承認的是，市場期待和隨著技術難度增加而飆升的成本之間存在著不小的差距。

基于上述考慮，原始設備制造商面臨的挑戰將是如何部署日益復雜系統，并且控制好因維護系統而支出的年度經常性費用。

起步階段

重新定義數據時代的汽車架構

從汽車行業的發展現狀可以明顯看出，在未來，汽車每天需要處理的數據量將達到十兆字節。車內的長程傳感器和短程傳感器（如LiDAR和攝像頭）將收集各類數據，并且，傳感器的數量將呈現遞增趨勢。

除需要數據處理和計算的自動駕駛外，汽車內部還有車載娛樂系統和擴展的車輛故障診斷系統（進一步增強車載自動診斷系統OBD-II進行的故障診斷）。這三大車載系統都需要穩定的數據處理。

那么，是否可以將這些數據都上傳到云服務器呢？這種可能性微乎其微。事實是，車載系統將先對部分數據進行本地處理，隨后再將主要數據或者整合數據上傳到云端。

"為了保證每天數千萬字節的數處理量，汽車系統中必須嵌入計算引擎。" 這樣一來，需要上傳的數據量大大增加。此前，車輛的電子控制單元（ECU）位置通?？拷c其相連的傳感器和執行器，因此分散在汽車內部的不同位置。如今，原始設備制造商（OEM）紛紛轉而使用“汽車電子電氣架構”（EEA），實現電子控制單元的合并與整合，并使用以太網將將各個電子控制單元互聯起來。這種全新架構中也會包含1至5臺內置高性能計算機（HPC）。

下面，我們將介紹從傳統架構轉向全新EEA架構產生的諸多影響，特別是在硬件和軟件維護方面的影響。

復雜性與日俱增

硬件復雜性

在汽車領域，電子硬件的設計并不像電腦那樣基于安裝在主板上的中央處理單元（CPU）和PCIe擴展卡，而是基于“片上系統”（SoC）。片上系統是一種集成電路，其上包括所有或者絕大多數計算組件。實際上，汽車的片上系統通常包括幾個CPU，用于保證計算性能和行車安全。這幾個CPU包括數字信號處理（DSP）單元、圖形處理單元（GPU）、視頻加速器、圖像處理單元（IPU）以及CAN總線接口等。換言之，片上系統是一個非常復雜的系統。



來源：德州儀器公司TDA片上系統

"硬件已經如此復雜了，汽車生產商需要更強大的軟件實力才能征服前行道路上的挑戰，因為軟件比硬件更為復雜。"

縱觀汽車硬件的發展，不難發現，片上系統的復雜性仍在攀升，尚未到達發展巔峰。實際上，即使目前車載硬件的性能尚未達到Teraflop區間，但市面上已經出現了一些包含16個CPU內核的芯片組 。可以預見，汽車將很快迎來80核CPU甚至計算性能更卓越的多核CPU。

軟件復雜性以及微服務

汽車行業逐漸由“機械定義汽車”轉變為“軟件定義汽車”。在這個趨勢的推動下，汽車開發周期被重塑，汽車開發工作方式和所需技能也迎來全面轉折。這些變革為行業帶來了額外的重重挑戰。為了應對挑戰，汽車生產商紛紛擴大專業團隊，不惜重金聘用并培訓專業人才。就目前來看，人才成本仍處于上升趨勢。

在大范圍聘用專業人才的同時，企業又面臨另外一個挑戰：如何吸引能夠為公司打下堅實軟件戰略基礎的得力人才。還有一種辦法是培訓原始設備制造商及其供應商的現有人員，教會他們追趕變革潮流所需的新技能。然而，技能學習十分簡單，重塑員工的固有思維方式卻非常困難，尤其是該領域的發展已經高度成熟時，難度尤為突出。

與此同時，終端消費者對更多、更復雜的功能的需求也在逐漸增加。麥肯錫公布的數據表明，“在過去十年中，汽車行業單個軟件項目的平均復雜度增長了300%?！比缃瘢恳惠v汽車之上，都有大約1億行代碼在運行——比軍用飛機F-35或波音787夢想客機的代碼條數還多 。預計到2025年，汽車上運行的代碼行數將達到2億，而對于L5(完全自動)自動駕駛系統而言，代碼行數甚至有可能達到10億行。

以下為美國汽車工程師學會（SAE）定義的駕駛自動化級別



美國汽車工程師學會（SAE）對駕駛自動化等級的劃分

除此之外，人工智能（AI）或機器學習（ML）算法也在很大程度上增加了車載軟件的復雜性。



來源：麥肯錫

網絡安全威脅

據報道，1983年，軟件和互聯網領域最早的“黑客”凱文·鮑爾森（Kevin Poulsen）黑入了互聯網的前身——Arpanet阿帕網。那時，偷車賊需要打破車窗，連接方向盤下的電線才能成功偷走汽車。而如今，隨著車載軟件數量的激增，汽車行業更加容易受到網絡犯罪的攻擊。

1983年，德國BOSCH公司發明了CAN總線，其誕生比萬維網和互聯網還早。由于CAN總線本質上不能抵御黑客的攻擊，當將其嵌入現代汽車后，CAN總線就給了黑客可乘之機。正如凱文·鮑爾森黑客事件暴露出了互聯網的漏洞，“黑客遠程劫持吉普車事件” 則暴露了汽車導航系統的許多安全隱患。

2021年發布的一份關于全球汽車安全的報告指出，“汽車行業的常見安全漏洞和安全暴露（CVE）已經有110個，僅在2020年就有33個，而2019年有24個?！?然而，并非所有安全威脅都納入了CVE。上述報道中還指出，在2020年8月，在10家不同公司開發的40個ECU軟件中發現了300多個漏洞。有關當局正在審慎研究安全漏洞對經濟造成的影響，并出臺了一些規章制度來抵御安全威脅。

ISO/SAE 21434標準“規定了有關道路車輛電氣和電子（E/E）系統（包括其部件和接口）的概念、產品開發、生產、運營、維護和退役等各階段網絡安全風險管理的工程要求”。此外，聯合國還通過了第155號條例《關于批準車輛的網絡安全和網絡安全管理體系的統一規定》。該條例概述了“有關車輛網絡安全和網絡安全管理系統審批的統一規定”。

由于聯合國第155號條例的出臺，原始設備制造商及其供應商必須合作開發軟件安全補丁或修復程序，以防止并限制車輛使用期間出現網絡犯罪行為。每一次軟件交付，無論其目的是引入增強功能、修復錯誤還是解決安全問題，都需要在經過網絡安全評估和正式的審批程序后才能推送給車輛端。

為了滿足這一強制性要求以及客戶的期望，原始設備制造商和一級供應商應該了解車載軟件的復雜性。在軟件領域，僅通過一種方法來實現一項功能或服務的情況非常少見。軟件架構師必須做出明智的決定，因為減少管理軟件的復雜性是削減長期軟件維護成本的唯一途徑。

"我們所面臨的挑戰不僅僅是交付一個軟件系統，還包含如何對其進行長期維護。汽車生產商是否為此做好充分準備？"

但網絡安全風險并不局限于軟件，有時硬件也會暴露出安全漏洞——眾多產品中發現的“崩潰(Meltdown)”和“幽靈(Spectre)”兩種安全漏洞就是一個有力的證明 。顯然，這樣的安全漏洞會增加系統設計的復雜性，因為軟件架構師需要在考慮軟件風險的基礎上，預測潛在的硬件漏洞。

安全考慮因素

系統復雜性并非汽車行業面臨的唯一挑戰。我們剛才談到了網絡安全問題。實際上，車輛的網絡安全和安全保障是兩個獨立的話題，因為車載系統的安全并不能確保乘客的安全。汽車是一個移動設備，其重量往往超過一公噸：汽車不僅需要保障乘客的人身安全，還要保護行車環境的安全。

假如乘客不系安全帶，即使安全系數最高的汽車也不能完全保障乘客的生命安全。盡管二者概念截然不同，但它們的關系卻是密不可分的。

上文提到的“黑客遠程劫持吉普車事件”就證明了這一點，黑客破壞汽車網絡安全后也對乘客的人身安全構成了威脅。隨著汽車上安裝越來越多起到預先防撞作用的主動安全系統，這一點尤其需要考慮。由于主動安全系統依賴于軟件的正常運行，因而十分容易受到網絡安全攻擊。為此，汽車行業引入了功能安全（FuSa）概念，旨在為原始設備制造商及其供應商提供一個框架，讓安全理念滲透到各個流程中，并成為概念、生產、交付、保養等流程的重心。

ISO 26262《道路車輛功能安全》是一個國際安全標準，對安裝在量產道路車輛上的電氣和/或電子系統的功能安全進行了約束和規定。ISO 26262標準將汽車“功能安全（FuSa）”定義為“不存在因電氣和電子系統故障所導致的不合理風險”。

功能安全問題不是單純的硬件系統問題，也不是單純的軟件系統問題，它是一個系統性問題，涉及硬件系統和軟件系統兩方面的具體操作和流程。

硬件安全

對于硬件系統而言，其只有在滿足嚴格安全要求的片上系統（SoC）和電子控制單元（ECU）之后才能安裝到汽車中。ISO 26262標準對汽車安全完整性等級（ASIL）進行了定義，并根據目前正在開發的系統的重要性，梳理了各個等級適用的要求和流程。例如，如果要達到ASIL-B等級，則汽車系統的單點失效覆蓋率需要達到90%以上，而ASIL-D等級則要求單點失效覆蓋率達到99%以上。同時，ISO 26262標準也給出了“單點失效”的定義，并規定了“預測失效率”的計算方法。該標準中還定義了所需關鍵術語，并提供了相應評估方法，以幫助讀者全面理解汽車的系統安全。

預測硬件失效率 ISO 26262標準介紹了幾種評估半導體元件失效率的技術，可以評估電應力、晶體管失效或封裝失效的發生率。這些失效類型和各自的發生率主要取決于電路類型、實施技術和環境因素，如濕度、溫度、壓力、電磁干擾等。ISO 26262標準還區分了元件的預計失效率和預計可靠性。此外，該標準指出，特殊情況下，某個單點失效可能會引起幾個單獨元件的安全風險。該標準進一步明確可通過相關失效分析（DFA）并識別相關失效發起點（DFI）解決這些風險場景。

數據傳輸故障檢測 為了滿足上述安全要求，半導體公司提出了大量的硬件檢測機制和解決方案。其中最為常見的包括：

? 奇偶校驗碼。通過在片上通信流量中添加一個“校驗比特”以達到檢測數據傳輸性的目的。奇偶校驗位是最簡單的錯誤檢測碼，檢測方法直截了當：若設置校驗比特位為0，則傳輸編碼個數為偶數個；若設置校驗比特位為1，則傳輸編碼個數為奇數個。若接收端接收到偶數個編碼，并且知道校驗比特的位置，就可以把它去掉，找到傳輸的數字。這樣一來，如果接收端得到奇數個編碼，就意味著在傳輸過程中出現了數據損壞。雖然奇偶校驗碼可以檢測到傳輸錯誤，但不能檢索到正確的信息，因此需要重新發送信息。

? 循環冗余校驗（CRC）是另一種用于檢測數據傳輸故障的工具。循環冗余校驗利用除法及余數的原理來做錯誤偵測。將特定大小的余數附加到數據后面，然后在接收端進行檢驗確定數據是否發生變化。在收到信息后，接收端對包含CRC的部分進行多項式除法：與信息一起收到的CRC應該與接收信息上計算的CRC一致，否則意味著有一個傳輸錯誤。

? 糾錯碼（ECC）是奇偶校驗法的增強版解決方案，因為這種辦法包括了一種即使硬件損壞下也能檢索到初始信息的方法。糾錯碼有很多種類，甚至無線5G標準也包含了新的糾錯碼機制。

雖然目標是檢測傳輸問題和檢索傳輸的初始信息，但這些檢驗技術需要與信息一起傳輸額外的編碼。這對實際的網絡帶寬有直接的影響，此等影響會逐漸減少：如果每個字節中有1比特用于錯誤檢測，7比特為實際數據，那么帶寬會減少1/8，即12.5%。 然而，有時會出現傳輸中斷。傳輸中斷可能是因為物理通信中斷，更多的時候是因為某個進程掛起時間太久。因此，我們使用“通信超時”來檢測通信損失量。

檢測運行時錯誤 如前所述，ISO 26262標準涵蓋了可能發生在晶體管層面的問題。半導體公司如今往往使用硬件檢查工具來驗證操作的正確性。但半導體公司同時也利用安全控制器收集整個系統中的故障信息，對其進行分析，并將故障信息傳遞到軟件系統的高層架構。 最近興起的另外一種低成本提高安全合規性的方法是“內置自檢”（BIST）。此方法誕生的契機是因為半導體制造商早前需要一種方法來識別產品的制造缺陷，完善質檢流程。通過充分利用這些增強的系統內置測試功能，同時在處理器正常運行時使用這些功能，能達到有效識別運行時故障的目的。

冗余檢測機制

為了達到安全要求，生產商通常會采用復制系統的辦法。在相同安全要求下，如果兩個系統是分別實施的，安全性甚至還會增高。雙重模塊冗余（DMR）以及三重模塊冗余（TMR）是指將一個系統或系統中的某個元素增加一倍或兩倍，并向此等系統或者模塊提供相同的輸入信號，比較輸出信號的一般方法。

三重模塊冗余的原則是多數表決，取多數輸出結果為最后的輸出：若三個系統中有二個系統輸出結果相同，則這個結果為正確的輸出結果。就雙重模塊而言，如果輸出結果不一致，則說明系統存在錯誤。雙模塊冗余（DMR）以及三重模塊冗余（TMR）用于不同的硬件層次，包括模塊層次、芯片層次，甚至在某些情況下也可能是系統層次。

一些片上系統支持雙核鎖步功能。安全硬件機制通過雙重模塊冗余（DMR）來實現，為兩個完全相同的CPU內核提供完全相同的軟件，并共享同一個時鐘周期。在每個時鐘周期，會有一個邏輯比較器檢查兩個內核的輸出結果是否一致，如果不一致，就會報錯。

但高性能CPU通常結構更復雜，確定性更弱，所以，雙核鎖步法實際效果可能會不盡如人意。因此，一些比雙核鎖步法更復雜的替代法應運而生，比如使用“安全島”在保持高度安全完整性的CPU內核中執行檢查任務。除此之外，雙核鎖步法的另一個優化方法是“CPU分核-鎖步”。

就像前面提到的失效檢測技術對減少通信實際帶寬一樣，CPU冗余技術也會占用其本身的可用處理能力。雙核鎖步法或其引申辦法會使片上系統的有效計算能力減少50%（使用Split-Lock辦法時計算力減少幅度略少）。此外，這項技術還會導致開發成本和硬件成本增高，因為必須要增加冗余。

軟件安全性

半導體公司通常需要使用專用軟件來確保硬件安全合規性 。換言之，一些云上系統需要軟件執行特定以充分發揮其安全潛力，例如在硬件安全章節提到的“內置自檢(BIST)”。恩智浦半導體公司推出的S32車用處理平臺是當下最熱門的汽車SoC系列之一。該公司認為：“S32安全軟件架構組建參與了啟動、運行和故障恢復期間的工作?！?



來源：恩智浦S32安全軟件架構

并非所有的軟件都是安全合規軟件，也并非所有軟件都能滿足安全要求。此外，軟件認證費也是一筆不菲的花銷。因此，伴隨著電子控制單元的逐步整合，在同一個片上系統或電子控制單元中包含不同的安全臨界等級逐漸成為行業趨勢。這種趨勢能夠優化成本控制和性能。車載信息娛樂系統電子控制單元就是一個有趣的例子。

現在，行業普遍將中控臺、儀表盤、平視顯示器和乘客監控功能融合在同一個電子控制單元中。融合后，某些顯示元素和聲音元素的安全要求就比其他元素更高。下圖介紹了實現電子控制單元整合的主要軟件。

?

不同選項之間的主要區別在于處理安全合規功能的地方有所不同。

? 在選項a中，硬件分離由符合ASIL/安全合規的管理程序管理。 ? 在選項b中，硬件分離是通過在片上系統中使用2種類型的內核來實現的。例如，用一個或幾個ARM Cortex-M內核來滿足車輛通信和安全需求，另外一組通用內核來實現高端計算功能。

? 在選項c中，硬件分離不在片上系統進行，而是在硬件層面——使用兩個不同的專用片上系統（一個用于安全，一個用于一般用途）來實現硬件分離。

這樣的架構不僅會增加軟件開發難度，而且會帶來復雜的集成和調試挑戰。 可以使用類似辦法或者其他新辦法，比如在系統中引入AUTOSAR自適應平臺。這些是通常基于特定片上系統的優化選項，而特定能力通常帶來會增加復雜性。

硬件復雜性將會持續增長，以此擴增片上系統的計算能力。

在此之上，安全要求還會增加系統復雜性。將計算能力和安全性整合到單個片上系統會變得越來越復雜。半導體公司將不得不提高片上系統的成本，以便達成相應安全要求。 同樣地，系統復雜性越高，認證就越困難，花費的成本也就越高。價格的增長曲線不太可能是線性的，更有可能是呈指數級增長。

但要確保安全合規，還需要在軟件方面多加投入。ISO 26262標準要求系統開發過程遵照V型生命周期模型。這意味著，軟件開發商首先要捕捉客戶需求，然后根據這些需求定義功能。軟件開發商需要將功能分解到硬件系統和軟件系統；軟件系統再細分為功能。此外還需要定義、創建或重新啟用具體的測試流程，然后依次進行功能層面、軟件層面、硬件層面，系統層面的測試。這種系統開發方法伴隨著一套流程來運行軟件，包括代碼審查、捕捉需求偏差、運行測試、測量測試覆蓋率等等。

"汽車公司必須做好承擔高額軟件維護成本的準備。" 現在，我們假設，現有的1億行嵌入在當前汽車中的代碼都是符合安全標準的（事實可能并非如此），按照ISO 26262標準定義的V型生命周期模型，我們還需要多久才能寫出新的1億行代碼，以便到2025年前使總代碼數達到2億行？我們需要多少名軟件工程師的通力合作？

參照現在已有的1億行代碼，原始設備制造商和一級供應商應該能夠粗略估算出按照COCOMO或任何其他方法，新增1億行代碼所需的成本但這也僅僅是預計成本，任何的變更都會導致成本的變更。

那么對于擁有5級自動駕駛系統的汽車來說，10億行代碼的預估工作量是什么樣的概念呢？同樣，如果大部分內容都不能重復使用，那么編寫規范、執行和測試如此大規模的軟件需要多長時間呢？ 使用開源是唯一的可持續發展方式，在“建議”節詳細闡述。

隔絕干擾

如前所述，硬件電子控制單元整合是一大趨勢。在大多數情況下，這意味著將安全關鍵組件和普通處理組件整合到同一個電子控制單元中。但安全系統必須具備“免干擾”功能。換言之，如果一個系統結合了安全關鍵組件和非安全關鍵組件（如在同一個電子控制單元內），則應證明非安全關鍵環境不會對系統中的安全部分造成干擾，進而引發安全問題。

例如，應確保調度器不會被破壞，某個進程不會終止系統，且內存堆可應對緩沖區溢出的情況。

在查看了CVE事件之后，我們發現，大多數CVE事件都是基于后門、內存溢出或軟件（或硬件）組件的意外/無意行為：因此CVE的重點在于強調安全威脅。我們每天都會發現新的CVE漏洞。即便按照ISO 26262（《道路車輛功能安全》標準）設計，且嚴格遵循Automotive Spice（軟件流程改進和能力測定標準）流程，具備ASIL D等級的實時操作系統（RTOS）也會存在安全漏洞。

但不管怎么說，沒有保護措施就意味著缺乏安全性，這是大家一致公認的事實。

ISO 26262標準并不足以確保汽車的安全性。根據現有先進技術要求，我們應按照ISO/PAS 21448（《道路車輛預期功能安全》標準），將預期功能安全（SOTIF）納入對系統的分析之中。這是另一個亟需解決的難題。 "系統越復雜，就越難評估和證明其安全合規性。"

建議

尋找解決難題及安全性問題的有效方法

?

現階段，我們可解決以下問題：

? 處理更多車輛數據，速度更快

? 不斷攀升的硬件復雜性所帶來的挑戰

? 軟件泛濫問題

? 網絡威脅帶來的其他難題

? 軟件的長期維護需求

? 軟硬件各自或共同的安全要求

接下來，我們將探索航電、開源軟件開發等行業應對這些挑戰的最佳實踐案例。

限制安全污染

我們已經證明，使用開源是唯一的可持續發展方式。但這并不代表我們應該寄希望于修改開源軟件來滿足對汽車的需求。例如，安全污染是指系統中越來越多的部分開始需要安全保護。如果我們一味地追求縮短上市時間，而非提升最終用戶的安全性，最終會導致忽略相應的架構研究。安全污染極大地限制了開源軟件的使用性，

因為絕大多數開源軟件都不符合、也不可能符合安全要求。對OEM而言，對系統各部分實行高安全合規性要求，例如要求每個組件都是ASIL D等級，似乎比將ASIL B等級系統升至ASIL D等級更為容易。然而，這樣做會導致復雜性和成本增加，同時還降低了功能。例如，與更通用的操作系統相比，符合安全標準的操作系統支持的功能更少。此外，每做一次更改（如CVE補?。?，都需要進行一次安全評估，因此同時兼顧安全性和保護措施的合規性會導致復雜程度再次升級。

因此，一旦在車輛上配置此類系統，運行成本會迅速增加。而且配置完成后，系統架構可能很難更改。對原始設備制造商而言，避免成本激增的唯一方法是理性控制系統的安全邊界。

最近，隨著自動駕駛和電子控制單元的整合，安全要求已經對車載信息娛樂系統等許多車輛組件造成了影響。

在避免安全污染方面，汽車公司可以借鑒其他行業的經驗。例如，航電系統架構就明確規定了系統安全與非安全相關組件之間的區別。比方說機載信息娛樂系統不會干擾飛機的安全組件。某些安全組件還可以控制非安全組件，比如機長廣播可以控制機載信息娛樂系統。

我們針對未來電子電氣架構的建議是考慮支持兩種類型的通信通道（在電子控制單元硬件層面）：安全通道和通用通道。系統中的通用組件可與符合安全標準的組件交互（訪問傳感器或執行器并從中讀取狀態），在可用時，使用云原生類型的消息傳遞系統（安全組件）進行回復：安全第一。應禁止通用組件設置參數或控制安全組件。

不建議重建電子控制單元安全和非安全組件。建議由兩種不同類型的片上系統（SoC）/中央處理器（CPU）負責同一電子控制單元中的安全性和通用特性，（如前述選項c）硬件分離所示）。這樣，就無需將所有的高性能計算或邊緣計算SoC/CPU連接到安全通信通道上，從而降低軟硬件設計的復雜性。

?

麥肯錫預計，硬件和軟件將實行分開采購，使“采購更具競爭力，擴展更簡單，并允許使用應用軟件標準化平臺，同時保持硬件方面的競爭”。

出于這一原因，原始設備制造商和一級供應商下一步將分別采購軟硬件安全和通用組件。

硬件安全要求催生了進入壁壘，從而阻止了更大規模的競爭。而取消系統架構中部分硬件模塊（如HPC）的安全要求，將導致競爭局面重演，并降低物料清單（BOM）成本。

例如，半導體公司可能會借此機會，為汽車行業提供符合AEC-Q100標準的CPU，且無需經過ASIL標準認證。我們可以期待看到功能更加強大、具備多個內核的CPU，同時相比個人電腦/服務器，它們的價格也不會出現大幅上漲的情況。 如今，有多少在Linux操作系統上創建的原型，為了最后能夠在“安全實時操作系統”上運行，不得不進行重新設計、移植和調整？試想一下，如果開發出能夠立即在目標硬件上運行的概念驗證（POC），把符合安全標準的組件與通用組件區分開來，這樣將大大減少對符合安全標準的虛擬化解決方案的需求，并增加符合安全標準的定制化操作系統的使用（無論是否基于Linux操作系統）。屆時，原始設備制造商將能夠使用Linux操作系統和開源軟件。與安全操作系統的使用情況相同，獲得有限領域內的安全要求也將改善資源的使用情況：降低所需的具備安全知識的工程師數量。招聘壓力會更小。

采用開源和Linux操作系統

Facebook/Meta、Airbnb、Netflix（以及許多其他公司）之所以成功，是因為他們試圖用自己的操作系統取代微軟的Windows或Linux，還是因為他們使用了開源并專注于客戶服務呢？他們肯定非常熟悉自己的軟件棧，但不會浪費精力去重新發明開源社區中已經存在的東西。如果他們發現了一個漏洞，或者開發了一個增強版開源模塊，他們就會將其發布到社區，從而讓模塊功能進入上游，獲益更多人，并促使整個社區共同參與維護過程。這就是開源的改進和發展方式。

我們建議原始設備制造商和一級供應商與Linux的商業供應商合作，以此對Linux內核及擴展開源軟件包進行長期支持和安全維護。這樣，他們就得以專注于自身的軟件解決方案，并通過客戶應用程序開發和服務推動差異化競爭。

同時，由于車輛與云端連接，原始設備制造商應考慮與Linux發行商合作，為云服務器、工程師桌面及車載Linux軟件提供支持。這樣，原始設備制造商就能以較低的費用獲得更高級的支持，同時減輕管理多家供應商、多份合同及多個開發環境的負擔。

開發下一代汽車應用程序

軟件代碼庫的擴展并非汽車行業所特有。為維持軟件復雜性和日益多樣的功能之間的平衡，整個IT行業不再固守靜態和單一方法，而是開始采用微服務和高可用性軟件設計。

微服務案例 基于微服務的應用程序架構實現了將單個應用程序開發為一套小型的、狹義的且可獨立部署的服務。每個微服務都在各自獨立的進程中運行，并與輕量級機制（通常是超文本傳輸協議應用程序編程接口）通信。這些服務將聚焦特定的業務功能，并使用完全自動化的機制獨立部署。

打個比方，我們可以用一座老舊的房屋來理解向微服務的過渡。這種過渡就好比打通這座房屋內廚房和客廳之間的墻，拆除手工制作的櫥柜，然后以大品牌的模塊化系統取而代之，并添設可通過家庭局域網和互聯網通信的廚房電器和電視機。這座房屋的外墻沒有任何改變，內部也仍設有一個廚房和一個客廳，但這些設施都更加現代化，舒適度更高，且具備一系列全新功能。

在這個重構遺留應用程序的過程中，部分遺留代碼是由其他人（即社區）維護的，因此通常會被開源代碼所取代，也就是說使用這些代碼的人無需承擔所有維護成本。此外，與取代的遺留代碼相比，開源代碼的用戶使用量更高，覆蓋更多案例：換言之，這種開源代碼的可靠性也更高。

向微服務架構模型的過渡應旨在以等價開源軟件取代70%（或以上）的遺留軟件。這樣，就可以將精力集中在剩下30%（或以下）可帶來關鍵差異的軟件上，從而為公司創造附加值。

如何處理單點故障

高可用性軟件設計的目的是識別單點故障（SPOF）。SPOF是系統的一部分，如果它停止運轉，將導致整個系統停止工作。例如，如果一架單引擎飛機的引擎發生故障，那么飛機就無法起飛，而相比之下，搭載雙引擎的商用飛機在起飛過程中即使其中一個引擎發生故障，飛機也能順利起飛。使用具備微服務設計的應用程序，能更輕松識別SPOF，并嘗試消除它們。消除SPOF的方法有以下幾種：鏡像、負載平衡、復制、自我修復等等。本文的目的并非深究細節，其關鍵在于，IT行業使用高可用性設計來確保服務器的容錯性和99.9%的正常運行時間。

此外，其還能在不關機的情況下，立刻進行服務器維護、升級和實驗。車輛不就是應該具有容錯性，并在大部分時間內保持正常功能和較長的正常運行時間嗎？我們不就是應該能在不用停車的情況下進行升級嗎？當IT行業工作者設定下這些目標時，他們充滿了斗志。但這些目標的實現是十分有益的，應該應用于汽車行業。

事實證明，互聯網具備穩定性，并且能夠全天候運行。高可用性軟件和基于微服務的應用架構是實現這一目標的關鍵支柱。數據中心運行的軟件在很大程度上是與硬件無關的。它可以輕松部署在世界上的許多地方，也可以由Amazon Web Services，谷歌云平臺，微軟Azure等公共云托管，甚至可以在企業內部托管，切換主機時無需重寫應用程序/服務。這只是其優勢之一。

微服務應用程序是容器化的軟件：也就是說它們在一個“盒子”（即容器）中運行，這個盒子中包含了它們需要執行的內容。容器化的軟件有幾大優點：

? 如果微服務出現故障，受影響的只是它所運行環境或容器中的部分，并不會導致整個系統癱瘓。

? 為支持微服務運行，容器中配置了一個虛擬硬件和操作系統環境。

由此產生了硬件抽象，使得微服務與實際的物理硬件無關。

網站、網頁游戲或網頁應用與硬件無關：它們可以在許多具有硬件特性（如屏幕尺寸、方向、圖形處理器、網絡攝像頭）的設備上運行。 我們認為在嵌入式關鍵任務軟件中，Snap軟件包能夠實現所需的硬件抽象（讓應用程序與硬件無關），同時提高整個系統的穩定性（應用程序中的某個功能故障不會危及整個系統）。

Snap是一項應用程序及其所有依賴項的捆綁集成包，無需修改即可在所有主要的Linux發行版，甚至集成Snap支持的定制發行版上運行。已經有數以百萬計的人使用了41個Linux發行版中的上千個Snap。其中包含了教程、支持材料、創建和部署新應用程序或補丁的工具。原始設備制造商和一級供應商也有可能創建Snap，并將其部署到運行Linux的新舊電子控制單元中。每個人都可以在Linux電腦（和物聯網設備）上免費使用這些Snap，無需付費或解鎖。

Snap的一大優點體現在操作和應用管理上。實際上，它們不僅能保證開箱即用的安全性，還能在不損害系統的完整性和可靠性的前提下，充分利用硬件的可移植性。任何原始設備制造商都可輕松部署Snap，無需在任何設備上移植即可運行。 Ubuntu Core ，一種完全基于snap的容器化版本。Ubuntu Core的設計具備安全性：通過AppArmor和安全計算模式提供安全性隔離。其還提供TPM支持，安全啟動和全磁盤加密。

利用Snap的整體安全方法，嵌入式系統具備了安全性、不變性、模塊性和可組合性等優點。軟件可通過delta進行無線更新，delta在出現問題時會（從Linux操作系統到任何單個應用程序）自動回滾。

?

汽車工業從CAN總線到以太網的過渡用了30多年的時間（而且只是部分過渡）。構建故障抵御系統是汽車行業的必備條件，有許多方法可以實現這一目標。此外，系統的網絡安全維護設計需具備成本效益。隨著ISO/SAE 21434（《道路車輛網絡安全工程》）網絡安全法規的實施，當前正是從安全性、保護措施和可擴展性三大角度重新考量汽車軟硬件架構的合適時機。

以客戶為中心

與手機的設計和功能相比，車載信息娛樂系統已經過時了長達4年多。

?

實現與手機相同的功能只是一個里程碑，并非我們的目標。車輛可開發的功能遠超手機（比如自動駕駛）。

固件或軟件在線升級（FOTA/SOTA）是第一步，但它并不具有突破性：人們在相關領域已對手機和電腦展開了探索。問題在于，更新能為最終用戶創造哪些好處。如果還保留2年前的功能或外觀，很可能會讓客戶大失所望。

原始設備制造商和一級供應商需要提升軟件開發與交付的速度，以便與其他行業（如手機）保持同步創新。再者，汽車是最先進的消費品。它們具備實現更高期望的潛力，而不應只達到其他行業的同等水平。

對于原始設備制造商來說，軟件開發成本應更低，且上市時間應更快。如果軟件的主要部分（將取悅最終客戶的部分和承載第三方服務的部分）能夠在非安全環境中運行，這一切將成為可能。同時，硬件的采購也需更容易（至少是在非安全環境下運行的硬件），并減少使用汽車專用片上系統。

這樣，原始設備制造商就可為其客戶和第三方生態系統提供新的服務。智能手機的成功很大程度上歸因于平臺（即智能手機及其應用程序商店）提供的第三方應用程序和服務生態系統。

集成軟件公司的思維方式

雖然汽車行業正在探索從硬件定義汽車向軟件定義汽車的過渡，但我們有必要了解這兩者之間的區別：

? 硬件設計通常以節約成本為主：如何在硬件上做出改變，使成本降低1美元？每臺設備節省1美元，那么100萬臺設備就能節省100萬美元。

? 軟件通常要考慮可擴展性因素：我們怎樣才能使軟件解決方案適用于上百萬的用戶呢？每月向每個用戶收取1美元費用，就能產生100萬美元的收益。 這兩者之間有著本質區別。

傳統汽車制造商曾鉆研過硬件設備的物料清單。汽車在開發過程中需要明確和詳細的規范。為滿足規范要求，制造商選擇了最具成本效益的硬件。最終，車輛在一定程度上受到了這些硬件的限制，且這種影響會持續整個生命周期。

特斯拉等公司則傾向于選擇功能更加強大的硬件方案。但這并不意味著他們不注重物料清單成本。他們在考慮競爭優勢因素時，有更大的自由度。特斯拉甚至在車機系統內引進了游戲。這些游戲指的并非機載娛樂設備上的游戲，而是需要在家里用游戲本玩的游戲。提供車載游戲這個功能可以奏效嗎？也許沒有，但這不是問題的關鍵。問題是，如果客戶在知曉這一功能之后，是否會感到滿意？因為不管怎么說，客戶滿意度都比功能本身更重要。

這樣的硬件和片上系統更加昂貴，但每年部署的新功能，也為吸引客戶提供了更多優勢。同樣，客戶滿意度是關鍵驅動因素。而且可以肯定的是，大多數客戶更傾向于功能不斷完善的汽車：這會讓他們擁有一種定期獲得新車似的新奇感受。的確，與較低端的片上系統方案相比，這樣的選擇會導致物料清單成本增加。

但每家原始設備制造商都做出了戰略選擇，比如彎曲復雜的車門形狀、添加可伸縮的后擾流板、使用特定的輪輞……這些選擇有助于將他們的產品做出區分，以及建立各自的品牌認知。一些原始設備制造商認為，車載硬件和軟件的計算能力能有效提升客戶滿意度。

但還有另一個有趣的影響因素：30年前，制造商在生產消費電子設備、手機或車輛時，在產品生命周期內花費的電子硬件成本為零。但現在的情況已截然不同，因為軟件在這些設備中發揮著重要作用。如今，客戶希望看到不斷推出新的產品功能，此外，系統安全也需要維護，這樣一來，每年都會產生與軟件相關的費用。因此，除了硬件的物料清單成本外，還需要評估和優化電子電氣架構的總體擁有成本（TCO）。減少系統復雜性將成為降低維護成本的關鍵。

最后，選擇主要基于現成組件架構，且對汽車的適應性要求最低的原始設備制造商（例如，在CPU方面僅要求AEC-Q100認證和擴展產品可用性），將更能適應采購短缺問題：這一點不僅體現在芯片方面，也包括工程和招聘方面。

為未來發展做足準備

幾十年來，原始設備制造商一直致力于打造卓越的內燃機產品，以及各自的品牌定位和識別，但最近，他們發現局勢已截然不同：新的品牌誕生，市場上出現了更快、更動感的電動汽車，而且能創造豐厚的利潤（就特斯拉的市值和利潤而言）。為了迎合這些市場變化，他們推出了多個方面的舉措。但只有未來需要維護部署在某領域的車輛時，他們才能真正履行如今的決議。我們的建議旨在幫助原始設備制造商及其供應商做出正確的決定，以實現可持續發展的未來。







審核編輯：劉清