當汽車逐漸從一個硬體驅動的機器逐漸進化成軟體驅動的電子產品， 汽車行業的競爭法則將被重新書寫。
發動機是整個 20 世紀汽車的技術核心和工程核心， 而今天， 強大的算力、高級的感測器們正越來越多的扮演著這樣的角色：從效率、到互聯、到無人駕駛、到電動化、到新型出行解決方案……它們讓更多這樣的時代創新成為可能。
可是， 隨著電子和軟體的重要性變強， 複雜度也升高了。 舉個例子就是現在汽車內部暴增的軟體代碼行數 SLOC（Software Lines of Code， 譯者注）。 2010 年時有些車裡的 SLOC 就有千萬行， 2016 年時這個數字就增長了 15 倍達到大概 1.5 億行。
汽車向提供越來越高級的自動化在定位， 汽車廠商們也把車內軟體的品質和安防當作確保車輛安全的關鍵必要條件。 行業也因此需要重新對現今的車內軟體和電子電氣架構進行構思。
整個行業正在經歷一個車從硬體定義到軟體定義的轉換， 每個車平均的軟體和電子電氣相關內構快速增長。
軟體， 在今天， 能占到一輛 D 級車或說一輛大型車全部內構的 10%（約 $1,200 美元）， 而這一占比的增速將達到每年 11% 的複合增長率：2030 年將達到 30%（約 $5,200 美元）。
於是也毫不奇怪整個數字汽車價值鏈上的每個參與者都想在這些軟體和電子技術帶來的創新中分一杯羹（圖 1）。 軟體公司和其他數位技術公司開始從他們原有的二三級供應商位置跳脫， 成為汽車廠商的一級供應商。 他們開始在汽車技術的“堆疊”（stack）裡擴大自己的參與感， 從提供功能、app 進化到作業系統。
與此同時， 傳統的一級電子系統供應商則大膽踏入由科技巨頭們佔領的功能、app 地盤；高端車廠們則正進入這“堆疊” 下層， 比如作業系統、硬體簡化、信號處理等等——他們須要捍衛他們的技術獨特性和優勢。
圖1
這樣戰略動作帶來的後果之一是車輛架構將變為基於廣義計算平臺的面向服務的SOA（Service-Oriented Architecture，
明日之車將轉向搭載全新差異化因數的平臺（圖 2 ）。 這些因數要素可能包含資訊娛樂創新、自動駕駛能力、以及那些基於“運行失敗” 的智慧安全功能（例如， 系統可以在部分失靈的情況下仍完成關鍵任務）。 軟體將在數位技術的分層裡逐漸下移， 以智慧感測器的形式與硬體相互集成。 “堆疊”將橫向集成， 形成讓車輛架構向 SOA 轉變的新層級。
圖 2
最終， 新的軟體和電子架構會帶來多項改變遊戲規則的新趨勢， 驅動複雜度和相互依賴程度的提升。
比如， 這些新的智慧感測器和應用就會給車輛帶來“資料爆炸” ， 廠商們若想保持競爭力， 就得能更有效率的處理並分析這些資料；
模組化 SOA 和 OTA 更新將成為管理車隊複雜軟體和功能按需（function-on-demand）商業模式可行的關鍵條件；
資訊娛樂以及低級別 ADAS 在越來越多協力廠商開發者提供內容的情況下將進一步被“app化”；
對資料安全的要求從聚焦純存取控制策略向一個可以預測、避免、檢測並防禦網路攻擊的集成安防概念轉向；
高級別自動駕駛能力（HAD，Highly automated driving）的來臨對功能的融合、高算力以及高集成度都提出了要求。
探尋未來電子電氣架構的十個假設技術與商業模式的前路未定，我們還是基於廣泛的研究和專家見解對未來的汽車電子電氣架構做了十個假設並分析了他們對行業的意義。
一、多 ECU 將被整合
汽車行業將轉向整合的 ECU 架構而非與特定功能對應的一大堆特定ECU（即現在這種“加個功能就加個盒子”的模式）。
第一步中，大多數功能將開始被集中在主要車輛域（domain）的集成網域控制站上，這些控制器會部分代替當下在不同分散式 ECU 中運行的功能。
這樣的發展業已開始且將在兩三年內打入市場，這種整合特別適用於跟 ADAS 和 HAD 功能相關的技術層級，基本的車輛功能則可能會繼續保持去中心化的狀態。
在向自動駕駛的進化過程中，軟體功能的虛擬化和硬體的抽象化將變得更加迫切，而這種新的手段可以通過不同幾種形式實現。
情況其一是將硬體合併為針對延遲和可靠性提出不同要求的“堆疊” ，比如支援 HAD 和 ADAS 功能的高性能堆疊以及用於基本安全功能的一個獨立的、時間驅動的低延遲堆疊。
另一種情況，ECU 被一個冗餘的“超級電腦” 替代.
而第三種情況，控制單元概念被徹底放棄以支援一個智慧節點計算網路（smart-node computing network）。
這一變化驅動因素有三：成本、市場新入者、通過 HAD 實現的需求。首先無論對於功能開發還是計算硬體，也包括通信硬體，成本減少都會加速上述整合；新入玩家來到汽車領域，通過軟體導向的車輛架構對整個行業造成的破壞力也是同樣效果；對 HAD 功能以及冗餘性日益增長的需求也需要更高集成化 ECU。
幾家高端車廠和他們的供應商已經在 ECU 整合問題上積極行動，先行一步升級電子架構，儘管明確的行業定式還未出現。
二、汽車行業將限制特定硬體所用的堆疊數量
伴隨整合的將是堆疊限制的規範化，實現車輛功能和 ECU 硬體的分離，提升虛擬化。硬體和嵌入式固件（包括作業系統）將依賴關鍵非車輛功能條件而非被分配到車輛功能域的一部分。要實現這樣的分離和 SOA 架構，以下四個堆疊可能成為未來五到十年內下一代汽車的基本：
·時間（Time-driven）堆疊。在此域中，控制器直接與感測器、執行器連接，系統須支援嚴格的即時要求和低延遲時間；資源調度基於時間。此堆疊包括達到最高汽車安全完整性等級的系統，比如經典汽車開放系統架構域（AUTOSAR, Automotive Open System Architecture, 譯者注）。
·事件-時間（Event/time-driven）堆疊。此混合型堆疊將高性能安全應用相連結，比如和支援ADAS和HAD的功能相接。應用程式和外設通過作業系統分離，應用程式按時間進行調度，應用程式內的資源調度則既可以根據時間或是優先順序。操作環境確保重要安全應用在獨立的容器（container）運行並與其他車內應用明確分隔，現有的例子就是自我調整AUTOSAR。
·事件堆疊（Event-driven）。這以堆疊以資訊娛樂系統為中心，對安全性來說並不關鍵。應用程式與外設將明確分離，資源和調度遵循最優化或基於事件的調度策略。此堆疊中包含使用者可見的、常用的功能且是用戶與車輛形成交互的介質，比如像安卓（Android），Automotive Grade Linux， GENIVI 和 QNX。
·雲堆疊（非板載堆疊）（Cloud-based，off-board）。最後一種堆疊負責和協調從車外獲取車內資料和使用車內功能。於是此堆疊負責溝通，同時還負責對應用的安全性和保護性檢測（即認證），由它建立一個已定義的車的介面（interface），包括遠端診斷。
供應商和技術提供商已經開始在以上堆疊中建立自己的專長，舉個值得注意的例子就是資訊娛樂系統（事件堆疊），公司們已經在推動人車溝通能力的拓展，如3D或增強現實式導航。另一個例子就是人工智慧和感測器在高性能應用程式上的引入，關鍵供應商在此領域已經和主要的汽車廠家進行合作開發計算平臺。
在時驅域，AUTOSAR 和 JASPAR 則在支援著時間堆疊的標準化，而擴展後的中介軟體層（middlewarelayer）將從硬體中將應用進行抽象。
車不斷進化為移動的計算平臺，中介軟體將讓車輛的重新配置成為可能，同時允許軟體的安裝和升級。不像今天在每個不同 ECU 裡的中介軟體只是負責單元間的通訊，下一代汽車中的中介軟體將是網域控制站訪問功能的連結，在 ECU 硬體之上運行的中介軟體層將實現抽象和虛擬化、SOA 和分散式運算。
已有證據表明，汽車廠商正向柔性架構努力，這也包括一個總體的中介軟體。比如 AUTOSAR 的自我調整平臺，它是一個動態的系統，包括中介軟體、對複雜作業系統的支援和最先進的多核微處理器。但是目前這類發展只限制在單個 ECU 中。
三、中期看，車載感測器個數將迅速升高
後面兩到三代汽車產品上，廠商們將通過安裝多個有相似功能的感測器以確保足夠的安全性冗餘（圖 3）。然而從長遠角度，汽車行業將必然開發特有感測器以減少感測器數量以及相關成本。
我們認為接下來的五到八年雷達和攝像頭相結合的方案將佔據主流，而當自動駕駛能力逐漸提升，雷射雷達的引入對於確保物體分析（object analysis）和當地語系化（localization）的冗余成為必要。
以 SAE 的 L4（高級自動）自動駕駛為例，實現 L4 的初期可能需要 4 到 5 顆雷射雷達，包括以城市運營和近 360 度可視為目的的固定在車後方的後置雷射雷達。
圖 3
長期來看，車輛感測器個數問題將會出現不同的情況：繼續增加、數量穩定或數量減少。到底哪一種情況將真正到來則依賴法規要求、不同解決方案的技術成熟度以及在不同用例中使用多個感測器的能力。法規方面，如若要求加強駕駛員監控，則車內感測器必然增多。
可以預見的是汽車內飾中消費電子感測器將會開始應用。動作感測器和用於測心率和困倦成都的健康檢測、面部識別、虹膜追蹤，這些只是多種潛在用例中的一小部分。當然，隨感測器數量上升或穩定，相應的物料成本也將上升，不只是感測器本身的成本，還有車內網路，所以減少感測器數量能帶來的成本節約也一定可觀。
在高級自動駕駛或完全自動駕駛時代到來，未來的高級演算法和機器學習技術將增強感測器的性能和可靠性，結合更強大、性能更高的感測器技術，多餘感測器的數量將有希望減少。今天在用的這些感測器可能由於其功能被高性能感測器淘汰而變得過時（例如，一個基於攝像頭或雷射雷達的停車協助工具將可能取代超聲感測器）。
四、感測器將更加智慧
系統架構的需求，決定了智慧、集成的感測器們需要為管理和處理高級自動駕駛所需的海量資料而存在。如感測器融合或 3D 定位等高級別功能將需要在中心化計算平臺上運行，但資料的預處理、過濾、快速反應等則將更多在感測器周邊或直接在感測器內完成。
有估計稱對於一輛自動駕駛汽車每小時產生的資料量將達到 4TB，因此，智慧化將從 ECU 們逐漸轉移至感測器，靠感測器進行基礎的、要求低延遲、只要求低算力的預處理，尤其是當權衡資料處理成本時，在感測器內處理資料對比將海量資料在車內傳來傳去相比更應把這些工作交給感測器。
而且 HAD 下駕駛決策冗餘無論如何也需要集成的中心化算力，這更可能是基於已經過預處理的資料。智慧感測器將對自身功能進行監督而感測器冗餘則將提升感測器網路的可靠性、可用性和安全性。另外，為確保不同情況下感測器的正確運行，需要新一類感測器清潔方案和應用——如需要除冰能力、除塵除垢能力等。
五、全電力和資料網路冗余成為必須
高可靠性要求的關鍵安全應用和其他類似應用，將充分利用整個冗餘圈來實現與安全操控相關的那些關乎巨大的一切內容，比如資料傳輸和電力供應。
電動車技術、中央電腦以及對電力要求較高的分散式運算網路都會對新的冗餘電量管理網路提出要求。支援線控轉向和其他 HAD 功能的故障運行系統將需要冗餘的系統設計，這也是對現今的故障安全監控實施的巨大架構改進。
六、“汽車乙太網”將崛起並成為車的中堅
今天的車輛網路不足以滿足未來車輛的需求。
HAD 資料速率和冗餘要求的提高，連接環境中的安全性和保障性以及對行業內標準化協議的需求將極可能導致汽車乙太網成為關鍵推動因素，特別是對於冗餘中央資料匯流排。
乙太網解決方案將需要通過添加像音訊 - 視頻橋接（AVB）和時間敏感網路（ TSN ）等乙太網擴展來確保可靠的域間通信並滿足即時要求。行業參與者和 OPEN 聯盟支援採用乙太網技術，許多汽車製造商已經取得了這樣的飛躍進展。
傳統網路（如本地互聯網路和控制器區域網路）將繼續用於車輛內，但僅用於封閉的低級網路，例如感測器和執行器位置。 FlexRay 和 MOST等技術很可能會被汽車乙太網及其擴展，AVB 和 TSN，所取代。
繼續發展的話，我們預計汽車行業也同樣會擁抱未來乙太網技術，比如高延遲寬頻產品（HDBP）和 10 十億位元技術。
七、OEM 將始終嚴格控制用於功能安全和 HAD 的資料連接，但會為協力廠商訪問資料開發介面
發送和接收安全關鍵資料的中央連接閘道將始終直接連接到 OEM 後端，除規定的要求外，協力廠商可以通過這些進行資料訪問。但在資訊娛樂方面，受車輛“ APP 化”的驅動，出現新的開放介面來允許內容和應用程式提供商部署內容，而 OEM 將盡可能保持相應的標準。
今天的車載診斷埠將被車聯網解決方案取代。將不再需要對車輛網路的物理維護但可以通過 OEM 的後端進行維護。 OEM 們將在其車輛後端提供資料埠用於特定用例，如遺失車輛跟蹤或個體保險。但是，售後市場設備對車輛內部資料網路的訪問會越來越少。
大型車隊（fleet）運營將在用戶體驗中發揮更強大的作用，並將為終端客戶創造價值，例如通過在一套服務（例如週末或每日通勤）中為不同目的提供不同的車輛。這要求他們利用不同 OEM 的後端並開始整合其車隊的資料。之後更大型的資料庫將允許車隊運營商在 OEM 級別無法獲取的資料集成和分析上變現。
八、汽車通過雲將車載資訊與車外資料結合
雖然 OEM 以外的其他廠商可用的資料將取決於未來的監管和相關磋商，但對雲計算中不斷增加的非敏感性資料（即非個人資料或安全相關資料）的處理將可以得到更多深入洞察結果。
隨資料量增長，資料分析對於處理資訊並將其轉化為可操作的知識將變得至關重要。利用資料以實現自動駕駛和其他數位化創新的有效果取決於多個玩家之間的資料共用。目前雖然還不清楚這將如何、由誰完成，但主要傳統供應商和技術供應商已經在構建能夠處理這種新資料的集成汽車平臺。
九、汽車將引入雙向通信的可更新元件
車載測試系統將允許汽車自動檢查功能和集成更新，從而實現生命週期管理以及增強或解鎖售後的產品功能。所有 ECU 將向感測器和執行器發送和接收資料，檢索資料集以支援創新用例，例如基於車輛參數的路線計算。
OTA 更新是 HAD 的先決條件; 同時還將因為 OTA 出現新的功能、確保網路安全、並使汽車製造商能夠更快地部署功能和軟體。實際上 OTA 更新功能是前面介紹的許多車輛體系結構重大變化背後的驅動。
此外，OTA 還需要在從車輛外部堆疊每層到車輛中 ECU 們的端到端的安防解決方案。這種安防解決方案仍有待設計，而由誰做、怎麼做都將會是非常有趣的觀察。
要實現像智慧手機那樣的可升級性，業界需要克服限制性經銷商合同、監管要求以及安全和隱私問題。這裡各種汽車廠商也公佈了部署 OTA 服務的計畫，其中包括對它們的車輛的無線更新。
OEM 將在 OTA 平臺上對其車隊進行標準化，並與該領域的技術提供商密切合作。 由於車的互聯性和 OTA 平臺變得越來越重要，我們可以認為 OEM 將在這個細分市場中佔據更多的所有權。
車輛將獲得軟體和功能升級，同時也會收到針對設計使用壽命的安防更新。監管機構可能會強制要求軟體維護以確保車輛設計的安全完整性。這種更新和維護軟體的任務將引出關於車輛維護和運營的新商業模式。
十、評估汽車軟體和電子體系結構的未來影響
影響當今汽車行業的趨勢們為硬體相關的內容帶來很多大的不確定性，對軟體和電子體系結構來說，看來未來的破壞性可能也不會少多少。
許多戰略舉措都有可能：汽車廠商可以選擇建起行業聯盟來規範和標準化車輛架構、數位行業巨頭可以引入車載雲平臺、出行服務商可以自己自己造車或開發開源車輛堆疊和軟體功能，汽車廠商則可以引入日漸複雜的互聯、自動駕駛汽車。
對於傳統的汽車公司來說，從以硬體為中心的產品向以軟體為導向的服務驅動型行業的轉變尤其有挑戰性。然而考慮到本文所述的趨勢和變化，汽車行業內的任何人都沒有其他選擇，只能做好準備。我們能看到幾大戰略推力：
·解耦車輛和車輛功能的開發週期。 OEM 和一級供應商需要從技術和組織兩個角度確定如何開發、提供和部署功能，而且是大部分在車輛開發週期之外。鑒於目前的汽車開發週期，企業需要找到一種管理軟體創新的方法。此外，也應該思考如何為現有車隊創建改造和升級解決方案（例如計算單元）。
·定義軟體和電子產品開發工作的目標增值（ value added ）。 OEM 必須確定他們能夠建立控制點的差異化特徵。另外，明確定義自己軟體和電子產品開發的目標附加價值非常重要，同樣的還有，找到可以形成商品或話題的區域且僅一家供應商或合作夥伴能夠實現。
·圍繞新的電子架構設計一個特定的組織（包括相關的後端）。除了改變內部流程以交付及銷售先進的電子和軟體之外，行業玩家們（ OEM 和供應商）還應該考慮針對車輛電子相關的主題設置一個新的不同的組織。主要是，新的“分層”架構要求有可能打破目前的“垂直”流程並引入新的“橫向”組織單元。再說一句就是，他們也需要為自己的軟體和電子開發團隊提升專門的能力和技能。
·圍繞作為產品的汽車特徵設計商業模式（特別是對汽車供應商來說）。為了保持競爭力並在汽車電子領域分一杯羹，分析哪些功能才是為未來架構增添實際價值並可以變現是致關重要的。隨後，玩家需要為軟體和電子系統的銷售推出新的商業模式，無論當時是作為產品、服務或者全新的東西。
隨著汽車軟體和汽車電子新紀元的開始，它正在徹底改變各種業務模式，客戶需求以及競爭性質的行業既有的確定性。我們對將建起來的收入和利潤池感到樂觀。但要從轉變中受益，業內所有參與者都需要重新思考並在新環境中仔細定位（或重新定位）其價值主張。
資訊娛樂以及低級別 ADAS 在越來越多協力廠商開發者提供內容的情況下將進一步被“app化”；
對資料安全的要求從聚焦純存取控制策略向一個可以預測、避免、檢測並防禦網路攻擊的集成安防概念轉向；
高級別自動駕駛能力（HAD，Highly automated driving）的來臨對功能的融合、高算力以及高集成度都提出了要求。
探尋未來電子電氣架構的十個假設技術與商業模式的前路未定，我們還是基於廣泛的研究和專家見解對未來的汽車電子電氣架構做了十個假設並分析了他們對行業的意義。
一、多 ECU 將被整合
汽車行業將轉向整合的 ECU 架構而非與特定功能對應的一大堆特定ECU（即現在這種“加個功能就加個盒子”的模式）。
第一步中，大多數功能將開始被集中在主要車輛域（domain）的集成網域控制站上，這些控制器會部分代替當下在不同分散式 ECU 中運行的功能。
這樣的發展業已開始且將在兩三年內打入市場，這種整合特別適用於跟 ADAS 和 HAD 功能相關的技術層級，基本的車輛功能則可能會繼續保持去中心化的狀態。
在向自動駕駛的進化過程中，軟體功能的虛擬化和硬體的抽象化將變得更加迫切，而這種新的手段可以通過不同幾種形式實現。
情況其一是將硬體合併為針對延遲和可靠性提出不同要求的“堆疊” ，比如支援 HAD 和 ADAS 功能的高性能堆疊以及用於基本安全功能的一個獨立的、時間驅動的低延遲堆疊。
另一種情況，ECU 被一個冗餘的“超級電腦” 替代.
而第三種情況，控制單元概念被徹底放棄以支援一個智慧節點計算網路（smart-node computing network）。
這一變化驅動因素有三：成本、市場新入者、通過 HAD 實現的需求。首先無論對於功能開發還是計算硬體，也包括通信硬體，成本減少都會加速上述整合；新入玩家來到汽車領域，通過軟體導向的車輛架構對整個行業造成的破壞力也是同樣效果；對 HAD 功能以及冗餘性日益增長的需求也需要更高集成化 ECU。
幾家高端車廠和他們的供應商已經在 ECU 整合問題上積極行動，先行一步升級電子架構，儘管明確的行業定式還未出現。
二、汽車行業將限制特定硬體所用的堆疊數量
伴隨整合的將是堆疊限制的規範化，實現車輛功能和 ECU 硬體的分離，提升虛擬化。硬體和嵌入式固件（包括作業系統）將依賴關鍵非車輛功能條件而非被分配到車輛功能域的一部分。要實現這樣的分離和 SOA 架構，以下四個堆疊可能成為未來五到十年內下一代汽車的基本：
·時間（Time-driven）堆疊。在此域中，控制器直接與感測器、執行器連接，系統須支援嚴格的即時要求和低延遲時間；資源調度基於時間。此堆疊包括達到最高汽車安全完整性等級的系統，比如經典汽車開放系統架構域（AUTOSAR, Automotive Open System Architecture, 譯者注）。
·事件-時間（Event/time-driven）堆疊。此混合型堆疊將高性能安全應用相連結，比如和支援ADAS和HAD的功能相接。應用程式和外設通過作業系統分離，應用程式按時間進行調度，應用程式內的資源調度則既可以根據時間或是優先順序。操作環境確保重要安全應用在獨立的容器（container）運行並與其他車內應用明確分隔，現有的例子就是自我調整AUTOSAR。
·事件堆疊（Event-driven）。這以堆疊以資訊娛樂系統為中心，對安全性來說並不關鍵。應用程式與外設將明確分離，資源和調度遵循最優化或基於事件的調度策略。此堆疊中包含使用者可見的、常用的功能且是用戶與車輛形成交互的介質，比如像安卓（Android），Automotive Grade Linux， GENIVI 和 QNX。
·雲堆疊（非板載堆疊）（Cloud-based，off-board）。最後一種堆疊負責和協調從車外獲取車內資料和使用車內功能。於是此堆疊負責溝通，同時還負責對應用的安全性和保護性檢測（即認證），由它建立一個已定義的車的介面（interface），包括遠端診斷。
供應商和技術提供商已經開始在以上堆疊中建立自己的專長，舉個值得注意的例子就是資訊娛樂系統（事件堆疊），公司們已經在推動人車溝通能力的拓展，如3D或增強現實式導航。另一個例子就是人工智慧和感測器在高性能應用程式上的引入，關鍵供應商在此領域已經和主要的汽車廠家進行合作開發計算平臺。
在時驅域，AUTOSAR 和 JASPAR 則在支援著時間堆疊的標準化，而擴展後的中介軟體層（middlewarelayer）將從硬體中將應用進行抽象。
車不斷進化為移動的計算平臺，中介軟體將讓車輛的重新配置成為可能，同時允許軟體的安裝和升級。不像今天在每個不同 ECU 裡的中介軟體只是負責單元間的通訊，下一代汽車中的中介軟體將是網域控制站訪問功能的連結，在 ECU 硬體之上運行的中介軟體層將實現抽象和虛擬化、SOA 和分散式運算。
已有證據表明，汽車廠商正向柔性架構努力，這也包括一個總體的中介軟體。比如 AUTOSAR 的自我調整平臺，它是一個動態的系統，包括中介軟體、對複雜作業系統的支援和最先進的多核微處理器。但是目前這類發展只限制在單個 ECU 中。
三、中期看，車載感測器個數將迅速升高
後面兩到三代汽車產品上，廠商們將通過安裝多個有相似功能的感測器以確保足夠的安全性冗餘（圖 3）。然而從長遠角度，汽車行業將必然開發特有感測器以減少感測器數量以及相關成本。
我們認為接下來的五到八年雷達和攝像頭相結合的方案將佔據主流，而當自動駕駛能力逐漸提升，雷射雷達的引入對於確保物體分析（object analysis）和當地語系化（localization）的冗余成為必要。
以 SAE 的 L4（高級自動）自動駕駛為例，實現 L4 的初期可能需要 4 到 5 顆雷射雷達，包括以城市運營和近 360 度可視為目的的固定在車後方的後置雷射雷達。
圖 3
長期來看，車輛感測器個數問題將會出現不同的情況：繼續增加、數量穩定或數量減少。到底哪一種情況將真正到來則依賴法規要求、不同解決方案的技術成熟度以及在不同用例中使用多個感測器的能力。法規方面，如若要求加強駕駛員監控，則車內感測器必然增多。
可以預見的是汽車內飾中消費電子感測器將會開始應用。動作感測器和用於測心率和困倦成都的健康檢測、面部識別、虹膜追蹤，這些只是多種潛在用例中的一小部分。當然，隨感測器數量上升或穩定，相應的物料成本也將上升，不只是感測器本身的成本，還有車內網路，所以減少感測器數量能帶來的成本節約也一定可觀。
在高級自動駕駛或完全自動駕駛時代到來，未來的高級演算法和機器學習技術將增強感測器的性能和可靠性，結合更強大、性能更高的感測器技術，多餘感測器的數量將有希望減少。今天在用的這些感測器可能由於其功能被高性能感測器淘汰而變得過時（例如，一個基於攝像頭或雷射雷達的停車協助工具將可能取代超聲感測器）。
四、感測器將更加智慧
系統架構的需求，決定了智慧、集成的感測器們需要為管理和處理高級自動駕駛所需的海量資料而存在。如感測器融合或 3D 定位等高級別功能將需要在中心化計算平臺上運行，但資料的預處理、過濾、快速反應等則將更多在感測器周邊或直接在感測器內完成。
有估計稱對於一輛自動駕駛汽車每小時產生的資料量將達到 4TB，因此，智慧化將從 ECU 們逐漸轉移至感測器，靠感測器進行基礎的、要求低延遲、只要求低算力的預處理，尤其是當權衡資料處理成本時，在感測器內處理資料對比將海量資料在車內傳來傳去相比更應把這些工作交給感測器。
而且 HAD 下駕駛決策冗餘無論如何也需要集成的中心化算力，這更可能是基於已經過預處理的資料。智慧感測器將對自身功能進行監督而感測器冗餘則將提升感測器網路的可靠性、可用性和安全性。另外，為確保不同情況下感測器的正確運行，需要新一類感測器清潔方案和應用——如需要除冰能力、除塵除垢能力等。
五、全電力和資料網路冗余成為必須
高可靠性要求的關鍵安全應用和其他類似應用，將充分利用整個冗餘圈來實現與安全操控相關的那些關乎巨大的一切內容，比如資料傳輸和電力供應。
電動車技術、中央電腦以及對電力要求較高的分散式運算網路都會對新的冗餘電量管理網路提出要求。支援線控轉向和其他 HAD 功能的故障運行系統將需要冗餘的系統設計，這也是對現今的故障安全監控實施的巨大架構改進。
六、“汽車乙太網”將崛起並成為車的中堅
今天的車輛網路不足以滿足未來車輛的需求。
HAD 資料速率和冗餘要求的提高，連接環境中的安全性和保障性以及對行業內標準化協議的需求將極可能導致汽車乙太網成為關鍵推動因素，特別是對於冗餘中央資料匯流排。
乙太網解決方案將需要通過添加像音訊 - 視頻橋接（AVB）和時間敏感網路（ TSN ）等乙太網擴展來確保可靠的域間通信並滿足即時要求。行業參與者和 OPEN 聯盟支援採用乙太網技術，許多汽車製造商已經取得了這樣的飛躍進展。
傳統網路（如本地互聯網路和控制器區域網路）將繼續用於車輛內，但僅用於封閉的低級網路，例如感測器和執行器位置。 FlexRay 和 MOST等技術很可能會被汽車乙太網及其擴展，AVB 和 TSN，所取代。
繼續發展的話，我們預計汽車行業也同樣會擁抱未來乙太網技術，比如高延遲寬頻產品（HDBP）和 10 十億位元技術。
七、OEM 將始終嚴格控制用於功能安全和 HAD 的資料連接，但會為協力廠商訪問資料開發介面
發送和接收安全關鍵資料的中央連接閘道將始終直接連接到 OEM 後端，除規定的要求外，協力廠商可以通過這些進行資料訪問。但在資訊娛樂方面，受車輛“ APP 化”的驅動，出現新的開放介面來允許內容和應用程式提供商部署內容，而 OEM 將盡可能保持相應的標準。
今天的車載診斷埠將被車聯網解決方案取代。將不再需要對車輛網路的物理維護但可以通過 OEM 的後端進行維護。 OEM 們將在其車輛後端提供資料埠用於特定用例，如遺失車輛跟蹤或個體保險。但是，售後市場設備對車輛內部資料網路的訪問會越來越少。
大型車隊（fleet）運營將在用戶體驗中發揮更強大的作用，並將為終端客戶創造價值，例如通過在一套服務（例如週末或每日通勤）中為不同目的提供不同的車輛。這要求他們利用不同 OEM 的後端並開始整合其車隊的資料。之後更大型的資料庫將允許車隊運營商在 OEM 級別無法獲取的資料集成和分析上變現。
八、汽車通過雲將車載資訊與車外資料結合
雖然 OEM 以外的其他廠商可用的資料將取決於未來的監管和相關磋商，但對雲計算中不斷增加的非敏感性資料（即非個人資料或安全相關資料）的處理將可以得到更多深入洞察結果。
隨資料量增長，資料分析對於處理資訊並將其轉化為可操作的知識將變得至關重要。利用資料以實現自動駕駛和其他數位化創新的有效果取決於多個玩家之間的資料共用。目前雖然還不清楚這將如何、由誰完成，但主要傳統供應商和技術供應商已經在構建能夠處理這種新資料的集成汽車平臺。
九、汽車將引入雙向通信的可更新元件
車載測試系統將允許汽車自動檢查功能和集成更新，從而實現生命週期管理以及增強或解鎖售後的產品功能。所有 ECU 將向感測器和執行器發送和接收資料，檢索資料集以支援創新用例，例如基於車輛參數的路線計算。
OTA 更新是 HAD 的先決條件; 同時還將因為 OTA 出現新的功能、確保網路安全、並使汽車製造商能夠更快地部署功能和軟體。實際上 OTA 更新功能是前面介紹的許多車輛體系結構重大變化背後的驅動。
此外，OTA 還需要在從車輛外部堆疊每層到車輛中 ECU 們的端到端的安防解決方案。這種安防解決方案仍有待設計，而由誰做、怎麼做都將會是非常有趣的觀察。
要實現像智慧手機那樣的可升級性，業界需要克服限制性經銷商合同、監管要求以及安全和隱私問題。這裡各種汽車廠商也公佈了部署 OTA 服務的計畫，其中包括對它們的車輛的無線更新。
OEM 將在 OTA 平臺上對其車隊進行標準化，並與該領域的技術提供商密切合作。 由於車的互聯性和 OTA 平臺變得越來越重要，我們可以認為 OEM 將在這個細分市場中佔據更多的所有權。
車輛將獲得軟體和功能升級，同時也會收到針對設計使用壽命的安防更新。監管機構可能會強制要求軟體維護以確保車輛設計的安全完整性。這種更新和維護軟體的任務將引出關於車輛維護和運營的新商業模式。
十、評估汽車軟體和電子體系結構的未來影響
影響當今汽車行業的趨勢們為硬體相關的內容帶來很多大的不確定性，對軟體和電子體系結構來說，看來未來的破壞性可能也不會少多少。
許多戰略舉措都有可能：汽車廠商可以選擇建起行業聯盟來規範和標準化車輛架構、數位行業巨頭可以引入車載雲平臺、出行服務商可以自己自己造車或開發開源車輛堆疊和軟體功能，汽車廠商則可以引入日漸複雜的互聯、自動駕駛汽車。
對於傳統的汽車公司來說，從以硬體為中心的產品向以軟體為導向的服務驅動型行業的轉變尤其有挑戰性。然而考慮到本文所述的趨勢和變化，汽車行業內的任何人都沒有其他選擇，只能做好準備。我們能看到幾大戰略推力：
·解耦車輛和車輛功能的開發週期。 OEM 和一級供應商需要從技術和組織兩個角度確定如何開發、提供和部署功能，而且是大部分在車輛開發週期之外。鑒於目前的汽車開發週期，企業需要找到一種管理軟體創新的方法。此外，也應該思考如何為現有車隊創建改造和升級解決方案（例如計算單元）。
·定義軟體和電子產品開發工作的目標增值（ value added ）。 OEM 必須確定他們能夠建立控制點的差異化特徵。另外，明確定義自己軟體和電子產品開發的目標附加價值非常重要，同樣的還有，找到可以形成商品或話題的區域且僅一家供應商或合作夥伴能夠實現。
·圍繞新的電子架構設計一個特定的組織（包括相關的後端）。除了改變內部流程以交付及銷售先進的電子和軟體之外，行業玩家們（ OEM 和供應商）還應該考慮針對車輛電子相關的主題設置一個新的不同的組織。主要是，新的“分層”架構要求有可能打破目前的“垂直”流程並引入新的“橫向”組織單元。再說一句就是，他們也需要為自己的軟體和電子開發團隊提升專門的能力和技能。
·圍繞作為產品的汽車特徵設計商業模式（特別是對汽車供應商來說）。為了保持競爭力並在汽車電子領域分一杯羹，分析哪些功能才是為未來架構增添實際價值並可以變現是致關重要的。隨後，玩家需要為軟體和電子系統的銷售推出新的商業模式，無論當時是作為產品、服務或者全新的東西。
隨著汽車軟體和汽車電子新紀元的開始，它正在徹底改變各種業務模式，客戶需求以及競爭性質的行業既有的確定性。我們對將建起來的收入和利潤池感到樂觀。但要從轉變中受益，業內所有參與者都需要重新思考並在新環境中仔細定位（或重新定位）其價值主張。