一文聊聊軟體定義汽車落地的五大關鍵要素

1 架構升級

1.1 軟體架構：分層解耦、服務化、API 介面標準化

隨著企業向軟體定義汽車開發方法的轉變，軟體架構也需要同步進行升級，引入服務導向的架構（Service-Oriented Architecture，簡稱SOA）方法論。汽車 SOA 是對整車智慧化的底層能力進行組織。將車端的硬體能力和各種功能服務化，這些服務根據 SOA 標準進行介面設計，基於 SOA 標準協定進行通訊。這樣，各服務組件之間就可以相互訪問，從而擴展了服務的組合形式。

圖1 SOA 服務化架構示意圖

SOA 的引入使汽車傳統封閉、固化的軟體系統逐漸成為具備開放性、重複使用性的軟體生態。在新一輪的軟體架構升級中，基於分層解耦的SOA 服務化架構，利用設備抽象和原子服務實現硬體能力的充分服務化，具體對象包括控制器週邊的傳感器、執行器、傳統總線通信，以及控制器本身的診斷、儲存設備。同時，基於「邏輯語意轉換」的設計思想，完成介面標準化，實現不同平台、不同車型的介面重用性目標。

圖2 SOA 架構下的基礎服務範例

隨著基礎架構及開發方式的變化，「軟體定義汽車」會顛覆整個汽車開發流程，基於SOA 的軟體架構方案為智慧汽車系統提供了重要的服務抽象化。嚴謹的封裝和分層結構支援使用敏捷開發方法和針對介面進行測試，並降低了系統的複雜性，將大大簡化軟體組件在車輛更新換代時的重複使用。

#圖3 軟體分層架構示意圖

架構標準化：

分層架構，在原​​有的整車架構中，引入原子服務層和裝置抽象層。

• 設備抽象層負責封裝底層的硬體差異，並把硬體層的特性以服務的方式提供接口，供原子服務層進行調用，硬體的調整不應導致系統軟體對外提供的介面變化，使得應用邏輯擺脫底層硬體平台的束縛；
• 原子服務層作為中間層，與平台解耦，對上承接應用服務的調用，對下進行設備抽象的訪問，體現車型差異，並配置化適配，使能上層應用跨車型復用；
• 應用/組合層服務主要負責用戶需求邏輯的實現，透過呼叫原子服務層提供的接口，組合出千變萬化的場景化應用。

介面標準化：

跨車型、跨零件供應商，最大化復用，降低軟體定義汽車軟硬體開發複雜度。

在架構標準化的基礎上，如何實現軟體的跨車廠使用？就需要對層與層之間的接口進行標準化，不同整車廠、Tier1、平台供應商定義同一套服務接口，使得不同整車廠之間，不同Tier1 之間的軟體可以相互調用，大大增加軟體的復用性，縮短車輛開發週期。

在介面標準化推動方面，中國汽車工業協會已經發布了第三版《軟體定義汽車原子服務API 介面與設備抽象API 介面參考規範》，包含700 多個API ，涵蓋車身控制、熱管理、能量管理、運動控制、智駕域、動力域、底盤域等多個功能域，參與介面標準化定義的成員包含整車廠、零件、基礎平台供應商、軟體供應商等100 多家公司。

1.2 通訊架構：基於車載乙太網路的技術應用

#隨著車輛功能的不斷增加，特別是自動駕駛、智慧座艙的不斷發展，需要傳遞的信號已爆炸式增長，車輛功能不斷升級更新，用戶對於OTA 升級體驗提出更高的要求，傳統的CAN 總線通信的方式已不能滿足車輛功能的增長速度，採用基於以太網服務的通訊方式，可實現功能的靈活重組，有效解決傳統面向訊號的通訊架構中因個別訊號增減/變更，而導致功能相關的所有系統均產生變更的問題。

車載乙太網路及其支援的上層協定架構如下圖所示，車載乙太網路主要涉及OSI 的1、2層技術，車載乙太網路同時支援AVB、TCP/IP 、DoIP、SOME/IP、DDS 等多種協定或應用形式。

圖4車載乙太網路及其支援的上層協定架構

SOME/IP 的全稱為：Scalable service-Oriented MiddlewarE over IP，基於IP 的可擴展的面向服務的中間件，已於2013 年納入AUTOSAR 4.1 規範。

圖5 支援服務導向的SOME/IP中間件

通訊架構升級之後帶來的變化：

• 更靈活的溝通機制：CAN 總線為廣播式通信，多主方式的工作使得每個節點發送的訊息都可能佔據所有的通訊媒介，只是接收節點可以選擇是否接收該訊息。而乙太網路以一對一或一對多兩種方式進行通信，一對一的方式發送節點的報文中涵蓋自己和一個接收節點的地址；一對多的方式中發送節點的報文中涵蓋自己和多個接收節點的位址。二者都不影響其他節點的通訊。
• 更高的頻寬，更低的延遲：車內資料傳輸總量及對傳輸速度的要求持續提升，以及在跨產業的標準協定需求的驅動下，支援更多應用場景、更高速的乙太網路取代CAN/LIN 等傳統汽車車內通訊網路已經成為必然。
• 更多的應用場景，易互聯易擴展：車載乙太網路與車外網路基於相同協議，在與車外網路進行通訊時，介面過渡更加平滑。傳統車內通訊網路是基於獨有的網路協議，且介面標準化差；與車外網路互動時，需要對不同系統的協定進行轉換。在網路聯化趨勢下，車載乙太網路的協定轉換成本更小。
• 更快的OTA 升級速度，更容易使用的體驗：採用乙太網路進行OTA 升級，通訊速度相對傳統的CAN 升級，提升了10 倍以上，大大降低了用戶等待的時間。採用以服務為基礎的通訊SOME/IP，可實現功能的靈活重組，有效解決傳統以功能需求為核心的架構中因個別功能增減/變更，而導致功能相關係統均需變更的問題，降低系統OTA 升級的複雜度。

1.3 硬體架構：區域存取算力集中化

##整車電子電氣架構是實現軟體定義汽車的基石，目前市場上銷售的傳統汽車大部分是分散式電子電氣架構，如下圖所示。

圖6 傳統分散式電子電氣架構示意圖

在分佈在式電子電氣架構中，首先將汽車功能劃分為不同的模組，如動力控制、底盤控制、主動安全、被動安全、智慧駕駛、資訊娛樂和車身等。然後再將每個模組的功能再進一步細分，例如車身功能又細分為車燈控制、車門控制、座椅控制等功能。不同的電控功能採用獨立電控單元（ECU）實現，不同 ECU 之間透過 CAN/CAN FD 進行通訊。

因為每個 ECU 由不同的供應商開發，有著不同的嵌入式軟體和底層程式碼，所以分散式電子電氣架構在整車層面造成大量的冗餘和 BOM 成本。另外，因為車內軟體都分佈在各 ECU 上，且 ECU 都由各供應商獨立完成，其軟硬體是緊密耦合的，整車廠並沒有權限去維護和更新 ECU 上的軟體。

快速滿足用戶需求是整車廠搶佔市場份額的關鍵，而分散式電子電氣架構嚴重限制整車廠響應市場需求的速度。假設某款車型中設計完成後，使用者提出增加駕駛位置記憶功能，即駕駛者將車輛的座椅、方向盤、外後視鏡等相關係統調整到舒適的位置後，可以將其設定為記憶位置，方便後續快速調整。需要對車門控制器、座椅控制器、方向盤控制器、網關等多個部件進行軟體變更，只有當各個零件供應商完成變更，並且整車廠完成整合測試和整車測試後，才能夠將新功能推出市場，將造成開發和變更週期長、成本高等問題。

為此，各整車廠早已開始儲備新型電子電氣架構方案，以促進軟體定義汽車的快速實現。新型電子電氣架構的顯著特徵是功能（軟體）集中化、硬體標準化。透過中央運算平台/網域控制器對控制功能進行統一管理，從而降低硬體冗餘和 BOM 成本，減少整車廠對眾多供應商的依賴。依功能集中程度不同，新型電子電氣架構主要分為三種。

第一種：域集中式電子電氣架構

#在域集中式電子電氣架構中，將整車電子電氣控制功能分為N 個功能域，每個功能域設計一個網域控制器，其餘控制器均為域內控制器，各域內控制器一般為智慧感測器、執行器和傳統控制器。

域集中式電子電氣架構示意圖如下圖所示，範例中將整車電子電氣控制功能劃分為五大功能域：動力域、底盤安全域、智慧駕駛域、資訊娛樂域和車身舒適域。

圖7 域集中式電子電氣架構示意圖

第二種：跨域集中式電子電氣架構

在網域集中式電子電氣架構中，網域控制站只負責一個網域的功能集中控制；而在跨域集中式電子電氣架構中，有些網域控制站負責兩個或兩個以上域的功能集中控制，進一步提升了系統功能整合度。較常見的跨域集中式電子電氣架構是三域架構，跨域集中式電子電氣架構的示意圖如下圖所示。

圖8 跨域集中式電子電氣架構示意圖

三域架構分別為車輛控制域、智慧駕駛域和智慧座艙域，將原有的動力域、底盤安全域和車身舒適域整合為車輛控制域，智慧駕駛域和智慧座艙域專注實現汽車智慧化和網聯化。

三域架構有3 個網域控制器：

車輛網域控制器負責整車控制，對即時性和安全性需求高；

智慧型駕駛座控制器負責自動駕駛相關感知、規劃、決策相關功能實現；

智慧座艙控制器負責HMI 互動和座艙相關功能實現。

第三種：區域存取 中央集中式電子電氣架構

中央集中式電子電氣架構不再依照功能去部署車內的電子電氣系統，而將整車所有功能域的控制邏輯均集中於中央運算平台，進一步提升了系統功能整合度。原有分散式和域集中式架構中的 ECU 的控制/運算功能被中央運算平台收編，轉變為更簡單的感測器或執行器。

為了減少線束長度，簡化通信，就近接入和供電，在中央集中式架構下可以按照物理位置劃分區域並在區域內部署區域控制器，形成中央計算平台和多個區域控制器的架構，中央集中式電子電氣架構的示意圖如下圖所示。

圖9 中央集中式電子電氣架構示意圖

硬體架構的升級，同時需要考慮跨域功能的融合、SOA 架構下的軟體功能分層、服務化後的控制即時性、功能安全設計、複雜的硬體設計與整合等等。

2 安全性升級：建立多層次的整車縱深防禦系統

2.1 功能安全性

隨著電子電氣架構技術的不斷升級，整車越來越多的系統和組件對功能安全產生影響，為此，功能安全也從部分關鍵系統開發，向整車各系統全面開發拓展。

同時，由於網域控制器、中央運算平台等新架構技術的出現，對功能安全提出了新的技術挑戰，功能安全必須建立針對這些複雜系統及軟體的開發和測評手段。

功能安全技術也影響電子電氣架構技術的發展，從傳統的失效安全（Fail-Safe）向失效運作（Fail-Operational）演變，電子電氣架構設計中引入了更多的冗餘（如通訊冗餘、冗餘控制器等）及安全保障措施。

未來，車輛智慧化生態的形成，將促進功能安全技術走出單車，朝向全鏈路延伸，實現整體智慧生態的整體安全。

2.2 預期功能安全性

#電子電氣架構相關的預期功能安全指的是規避由於功能不足、或可合理預見的人員誤用所導致的人身危害。預期功能安全技術屬於汽車技術的一部分，對應的標準為 ISO 21448。根據自動駕駛功能及其運作設計域，分析符合預期功能安全要求的系統配置方案，基於系統配置方案確定或選擇合適的電子電氣架構方案。預期功能安全關鍵技術點：

（1）自動駕駛安全準則制定技術：針對自動駕駛已知場景和未知場景下的安全表現，制定客觀量化準則，科學判定自動駕駛的安全水準；

（2）安全分析技術：透過STPA 等安全分析手段，辨識自動駕駛安全相關功能的不足性能限制及危害觸發條件，制定針對性措施，進行功能更新；

（3）多支柱法測試技術：由模擬測試、定場景測試和真實道路測試組成的自動駕駛預期功能安全測試系統；

（4）安全論證技術：基於安全開發、分析、測試等結果，制定預期功能安全檔案策略，透過GSN 等論證手段，評估自動駕駛安全風險，完成預期功能安全發布；

（5）安全監控技術：透過車載和遠端手段，監控自動駕駛運行過程中的安全表現，識別安全風險並進行必要的風險控制措施，以確保自動駕駛運行安全。

2.3 網路安全

#

智慧型汽車車輛端、通訊管道、雲端平台以及行動應用均面臨一系列的資安威脅。從汽車網路空間維度出發，透過多重技術協同、不同手段互補、從外到內多層次部署安全防線，滿足車輛資訊安全防護的縱深性、均衡性、完整性的要求。需依據新一代車輛電子電氣架構，從網聯安全、內網安全、ECU 安全角度實施部署對應防護措施。

圖10 智慧型汽車全方位網路安全防禦

網路連線安全

網路存取層主要抵禦針對乙太網路的DOS、PING 類型、畸形封包、掃描爆破、欺騙、木馬等網路攻擊。需具備車雲連動機制的主動安全防護能力，可透過雲端系統即時配置防護策略，主要包括接取認證機制、通訊保護機制、乙太網路防火牆機制和入侵偵測與防禦（IDPS）機制。

車內網安全

#車輛內網安全主要抵禦針對車載CAN/CAN FD、車載乙太網路的攻擊入侵，包括封包監聽、錯誤注入、封包重播等攻擊。防護的策略包括：匯流排入侵偵測機制、內網防火牆機制、功能域隔離機制、匯流排通訊保護機制和診斷安全保護機制。

關鍵ECU 安全

#為確保車輛系統或關鍵資料不會被破壞，在車輛關鍵ECU 層面需具備安全啟動、關鍵資料安全儲存、系統安全運作的安全能力，並可為應用程式運作提供權限管理能力。

服務安全性

SOA 安全框架需要遵循五個基本原則：機密性、完整性、真實性、授權性和可用性，透過資訊加密、數位簽章、密碼認證、設計存取控制清單ACL、DOS 攻擊監控等多種方案及產品實現網路安全，同時確保這些網路資訊可被發現、被存取、被通訊以及被監測。

圖11 車載SOA 服務網路安全原則

• 在服務發現上，設定資訊安全分組隔離機制，使得服務廣播訊息只發給有需要的服務使用者；
• 在服務存取上，為服務提供者設定資訊安全存取控制機制，認證並授權服務使用方發起的服務請求；
• 在服務通訊上，根據SOA 服務實際的業務應用程式場景決定SOA 訊息應採用的資訊安全傳輸機制；
• 在服務監控上，設定服務安全監控機制，發現SOA 服務相關的異常事件及安全回應處理機制。

3 流程變革：敏捷開發，迭代發布

汽車上的功能日新月異，軟體程式​​碼日益增加，傳統V模型下的瀑布式開發已經不堪重負，為了快速交付給客戶最迫切需要的功能，軟體開發流程的轉變至關重要。目前，越來越多的汽車零件供應商轉向了敏捷開發。在系統架構實現軟硬體解耦，層次化架構系統軟體、中介軟體和應用軟體的基礎上，實現軟體功能的快速迭代、發布，使得整車廠可以快速佔領市場。

敏捷開發流程的核心是培養研發人員的協作意識、責任感、品質意識、學習意識、創新意識，進而提升整個軟體研發團隊的研發能力，高效地開發高品質的軟體產品。特性開發採用以月為研發週期的迭代開發模式，進一步分為詳細設計與評審、特性開發與程式碼走讀、程式碼品質檢視與評估、測試案例設計與編寫、特性功能聯調、特性合入評審等多個子流程。每個子流程都有具體的輸出件（設計文件、原始碼、評審報告、測試案例、測試報告等）和量化評判系統（設計文件章節完整性、增量程式碼度量報告、評審意見密度、測試案例覆蓋率、缺陷密度等），確保每個子流程均按照軟體研發品質要求達成，並對所有文件歸檔以支援軟體品質回溯。

版本發布採用以周為發布週期的軟體版本快速迭代模式，每週從穩定分支發布版本，對軟體基本功能、新增特性進行充分驗證，對已解決的問題進行迴歸測試，均通過之後再發布版本。敏捷開發的業務價值：

• 使用者體驗能以月為單位發布。
• 漏洞和修補程式按週進行快速發布。
• 軟體版本是按小時迭代，零件與整車同步整合、自動化驗證（7*24h 無人值守）。

4 工具鏈升級：基於SOA 的整車服務化開發

SOA 的整體想法是設計服務模型，將不同的基礎服務進行抽取，分層解耦定義恰當的API 接口，應用呼叫服務API 接口實現業務邏輯。 API 介面定義獨立於實作服務的硬體平台、作業系統和程式語言，確保建置在不同系統中的服務可以以統一通用的方式進行互動。

對於汽車產業而言，SOA 是一套新引進的技術，需要一套有效的流程、方法和工具鏈，三者相輔相成，目前業界還沒有一套非常成熟的方法論和工具鏈，大部分整車廠和Tier1/Tier2 都處於探索階段，下圖展示了一種基於服務的功能開發流程方法。

圖12 基於服務的功能開發流程方法

首先對功能進行需求分析，輸出場景定義和特性設計，以及對應的物理拓撲和模組功能定義接著繼續進行系統設計，包括服務架構設計、服務設計和通訊設計，服務定義需依據中國汽車工業協會軟體定義汽車工作群組發布的API 介面參考規格。

5 產業分工升級：合理分工、開放協同

#面向未來的智慧汽車時代，隨著原有產業價值鏈開始被打破，傳統車企紛紛轉型，新生力量奮力崛起，技術進步日新月異，跨界玩家悉數入局，產業競爭的要素和形態正在悄然變化，一方面驅動著新產業格局的形成，另一方面也催生著新產業生態的出現。智慧汽車產業朝著更多元化、更能化的方向發展，出現許多不曾涉獵的新科技領域，開放合作才能實現共贏，優勢互補才能形成合力。

5.1 整體建議

#如前所述，汽車產業正向電動化、智慧化演進，技術、使用者體驗等驅動汽車產業快速成長。隨著智慧汽車的逐步推進，整車軟硬體複雜度也持續提升，產業向軟體定義汽車轉型已成產業共識，但軟體定義汽車仍處於起步階段，軟體的大量引入給汽車產業從設計、開發、整合、測試、發布和維護都帶來一系列的挑戰。管理好軟硬體組合的複雜度，才能持續滿足消費者的體驗需求，形成市場競爭力。

分層解耦是提升軟體復用性，降低軟硬體開發複雜度的關鍵手段，也是邁向軟體定義汽車的必經之路。透過分層解耦，可以實現軟體與硬體分離，應用與基礎平台分離，但如何實施成為關鍵挑戰，將直接影響軟體定義汽車的策略目標和價值達成。從技術層面，架構如何分層，服務如何劃分有利於最大化復用、最簡化開發維護和長期演進是關鍵挑戰。只有合理、穩定、統一的服務劃分才能確保軟體定義汽車價值最大化。從產業鏈方面，各方如何定位、分工、協作才能保障各方最大化利益是關鍵困難點，開放、合作、共贏是軟體定義汽車快速落地的基礎。

整體建議：

從技術規範統一性和產業合理分工兩方面，加強汽車產業鏈上下游企業合作協同，共同推動智慧汽車軟硬體介面標準化，建構原子服務和設備抽象層，實現應用、基礎平台和硬體的分層解耦；建立SOA 服務架構和介面規範化統一化，實現跨車型、跨零件供應商最大化復用，減少客製化加速創新，提升智慧汽車產業協同效率。同時，結合產業鏈各方訴求與優勢，基於分層架構，形成合理分工從而通力合作。

具體建議：

• 在裝置抽象層，實作裝置與連接埠的解耦，屏蔽硬體功能差異與廠商差異，並且該層由行業聯合定義，並實現標準化；
• 在基礎平台層，實現基礎軟體與硬體解耦，屏蔽設備與驅動差異；
#在基礎平台層，實現基礎軟體與硬體解耦，屏蔽設備與驅動差異；
#在原子服務層，實現服務與平台解耦，提升軟體復用性，並且該層由行業聯合定義並標準化；
在應用/組合服務層，實現應用與服務解耦，應用跨車型復用，聚焦體驗，並且該層建議由整車廠主導。

圖13 軟體定義汽車產業合作整體建議

同時，API 規範化並不等於產業競爭同質化，在標準上開放，在產品上競爭。整車廠和各零件供應商可在關鍵技術上分層構築核心競爭力，在協同上構築管理能力提升效率和規模，在商業模式上構築保護機制確保獨家/先發優勢，從而最終面向用戶提供獨特性、可進化、更高附加價值的產品。

同時，不同廠商的硬體、軟體、平台等具有互通性，即不同車型和不同部件，能夠用相同的語言完成跨域調用、交換和共享資訊的能力，讓產業鏈的每個企業都受益。

對於整車廠：

#更容易管理：朝向物件導向軟體管理模式轉變，軟體Onetrack，更容易管理更複雜的整車軟體系統和供應商，並可聚焦整合能力建構競爭力；
更快上市：基於SOA 高效能軟體開發，並可預先整合服務API，加速車型上市速度。

對於零件供應商：

#減少客製化：減少不增值的繁複工作，降低面向不同車型開發與維護成本;
加速創新：釋放人才聚焦創新，建構差異化技術與產品。

#對軟體開發企業/開發者：

#更容易理解，整合開發資源，快速開發;
更多機會：跨界人才新思維帶入汽車產業，持續挖掘後市場價值，帶來更多變現空間。

5.2 整車廠

#######

整車廠直接面向終端用戶，提供滿足用戶需求的汽車產品，將軟硬體、應用功能及生態服務等各方整合起來，完成從整車製造到長期出行服務的交付。

整車廠不僅是生產汽車的製造商，也會為消費者提供行動出行相關服務，透過軟體的開發、配置、迭代升級來滿足用戶多種多樣的用車需求。使用者能透過軟體設定汽車產品的不同功能，甚至可以依照個人喜好編輯出行場景或下載所需的特定場景功能。為此，整車廠需要完成以下平台的建置及開發：

1) 硬體平台整合

硬體平台是軟體定義汽車的基礎，現階段各整車廠規劃的電子電氣架構主要有三種：集中功能域、跨域融合、中央運算域區域存取。為因應智慧化汽車和軟體定義汽車的需求， 中央運算域 區域存取將會是未來的主流電子電氣架構。整車廠需依自身狀況合理分配各域的功能及區域接入硬體的介面。

2) 軟體整合

#整車廠需要具備軟體整合能力，建立「軟體中心」或「使用者體驗中心”，並建立對應的組織架構，提升整車軟體開發能力。

第一階段：專注於整車控制應用層軟體和與使用者體驗強相關類軟體，形成品牌特色，提高使用者黏性。建立軟體開發環境，依照軟體開發流程，例如導入AUTOSAR 規範等，實現應用層軟體和供應商硬體在開發層面解耦，應用層軟體封裝後交給供應商整合和配置，而不需要對其開放應用層，可以指定幾個硬體供應商。同時可與生態服務商合作，將第三方軟體嵌入應用層。應用層自主掌控後可快速移植，提升開發效率，也為功能持續迭代、使用者常用常新提供基礎。 OTA 是核心通道，第一階段實現是邁向軟體定義汽車的第一步。

第二階段：透過購買配置工具逐步實現應用層與底層的集成，硬體供應商提供“白盒”，在整車廠進行集成和刷寫。實現真正意義上的軟硬體解耦，擴大硬體的採購範圍，降低採購成本。但是底層配置功能需要整車廠大量的投入，整車廠根據自身能力考慮是否入局。

第三階段：逐步進入硬體和底層的自主開發。透過硬體降低整車成本，自主選擇核心晶片，打破硬體平台化的限制，以成本和客戶體驗為導向，根據整車配置及功能需求進行軟體模組化移植。

3) 開放平台的建造

#傳統汽車開發完全依托車廠的工程師概念，是一種凌駕於客戶之上的開發模式。開放平臺本著共贏、共生、共創的新模式，能在新情勢下解決供應商、整車以及使用者之間的關係。

開放平台可以為車企開發工程師、第三方、用戶提供整車車輛能力，這些能力包括一些底層硬體能力、軟體能力、數據及信息，根據這些能力結合使用場景可以開發出多樣化的軟體，為用戶提供客製化、個人化、訂閱式服務，即為用戶和整車廠創造價值，也獲得自身收益。實現使用者參與車輛軟體的開發，真正實現軟體定義汽車。

透過開放平台，可以呼叫汽車上百千個硬體模組，能提供比手機更強的感知能力，更多的應用場景，更大的覆蓋範圍，更長的生命週期，所以汽車生態圈比手機生態圈更廣，比手機更開放，更貼近用戶。

5.3 零件供應商

#

對於傳統零件供應商來說，在軟體定義汽車發展趨勢下，整車廠在系統功能開發的話語權越來越大，借助軟硬體解耦和SOA 架構的落地，整車廠也將逐漸承擔部分零件供應商應用功能的開發，因此傳統以硬體為主的Tier1 迫切需要轉型尋求新的出路。

目前來看，軟硬體全端能力的打造，是搶佔下一個市場份額制高點的關鍵所在，很多能力非常全面的Tier1 正在打造「硬體底層軟體中間件應用軟體演算法系統整合」的全端技術能力，既能為客戶提供硬體、也能提供軟體，同時也提供軟硬整合的解決方案。但這樣的佈局要求 Tier1 大量的人力和資金的投入，不是所有 Tier1 能夠承擔的。

對此，零件供應商應將進一步開放硬體端口，對硬體的能力抽象化，為降低面向不同整車廠的定製成本，提高交付效率，需要將介面依照統一標準進行開放，從而降低匹配複雜度，減少軟硬體耦合度，增強靈活性和復用度。並主動聯合整車廠、軟體供應商等多方共同打造零件生態，吸引和創造更多樣化、更豐富的獲利場景在標準介面的前提下，性能的差異性會為零件供應商帶來競爭，同時也會促進零件供應商去創新和進步。零件供應商的重點應該聚焦內部的核心演算法，透過內部演算法和程式碼的最佳化升級，實現效能和體驗的差異性和持續進化。並透過與整車廠、人工智慧、軟體等領域的IT 公司合作，了解最新的需求和發展方向，調整自己的研發方向和能力，立足硬件，運用累積的產業Know-How 優勢建構應用功能軟體能力，反哺並帶動差異化硬體銷售，是許多零件供應商的選擇。

5.4 基礎平台供應商

#以軟體定義汽車時代，基礎平台廠商的目標是運用自身ICT技術累積與優勢，幫助整車廠打造適合整輛車上自身規劃的、差異化的下一代電子電氣架構，降低智慧汽車研發複雜度，提高效率，加速智慧車開發落地。

但目前從整車廠到一級供應商、二級供應商和三級供應商這樣的供應鏈模式正越來越模糊，而車企越來越希望能夠主導更多的內容，這迫使基礎平台提供者必須以更加開放的姿態打破邊界，聚焦自身優勢產品，面向上下硬體和應用軟體提供開放API 接口，並為功能軟體提供安全可信的運行環境和易用的服務開發及驗證工具鏈。

建議基礎平台供應商為整車廠提供一個以智慧汽車永續演化為導向的架構，在設計概念上應以人為本，圍繞著使用者體驗與整車廠商業成功持續創新。

5.5 軟體供應商/軟體開發者

#隨著整車廠自主權與軟體自研能力的不斷加強，整車廠開始尋求與軟體供應商的直接合作，例如整車廠商將首先尋求把座艙HMI 互動系統功能收回，UI/UX 設計工具、語音辨識模組、音效模組、人臉辨識模組等應用軟體則直接向軟體供應商購買軟體授權，從而繞過傳統Tier1，實現自主開發。

隨著軟體定義汽車的變革的推動，汽車硬體體系逐漸趨於標準化，而軟體是汽車裡迭代最快、最容易個性化和差異化的部分，同時軟體也將推動硬體創新，二者相輔相成。對於軟體供應商來說，能提供越多的軟體 IP 產品組合，就越可能取得更高的單車價值。

同時，軟體供應商也正尋求進入傳統 Tier1 把持的硬體設計、製造環節，例如網域控制器、T-BOX 等，以提供多樣化的解決方案。對智慧汽車 APP 應用開發來說，基於原子服務標準 API 開發應用軟體將變得非常便利，容易上手。對於應用來說不用過多的關注底層的實現，降低不同層次、不同模組的依賴性，類似基於安卓的開發模式。針對不同的人群、不同的車子、不同的生活場景，不同的應用程式開發人員就會做出功能不同、畫面不同、體驗不同的應用。

應用程式開發的門檻變低了，就有更多的軟體供應商/開發者能參與到汽車應用 APP 開發中來，隨之而來的就是軟體開發的競爭變大了。軟體供應商應該基於一些調查數據來分析不同族群的偏好，針對不同的車型，發展出適合大眾且具有差異性的應用。使用者可以根據自己的實際情況，選擇性的安裝部分功能和特性應用，透過不同的應用和服務，可以定義自己車輛的一些特性，達到透過軟體進行功能升級或個人化的目的。

在競爭的過程中不僅會出現非常受歡迎的應用軟體，也會提升應用軟體供應商提升服務的主動性和精確性，提高產品創新的能力，從而繁榮智慧汽車應用生態。

5.6 產業組織

#政府應該從法規、政策、標準等方面來幫助整個汽車產業建立合理高效率的管理制度，監督整個產業有序、平穩地運轉，不斷做大做強，並確保整個產業的公平競爭。

從政策上鼓勵各企業發展新技術，例如可以獎勵對汽車產業有貢獻或在某些技術方面有突破的企業單位，分享、展示創新成果，實現科技政策與科技創新的深度融合，並不斷完善政策，完善回饋體系，發揮政策對發展新技術的推動力，創造出良好的汽車軟體生態系統，以智慧網聯汽車帶動智慧交通與智慧城市的建設發展。

從標準建立解決共通性問題的通用介面等規範，實現汽車軟硬體產品的互聯互通，避免各企業在通用標準化介面層面各自為戰，倡導各企業在統一介面下做好自身產品的創新與研發，避免重複與分散投入，提高研發效率，推動我國智慧網聯汽車發展。

以上是一文聊聊軟體定義汽車落地的五大關鍵要素的詳細內容。更多資訊請關注PHP中文網其他相關文章！