一、架構升級

1、軟件架構：分層解耦、服務化、API 接口標準化

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

圖 1 SOA 服務化架構示意圖

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

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

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

圖 3 軟件分層架構示意圖架構標準化：分層架構，在原有的整車架構中，引入原子服務層和設備抽象層。

設備抽象層負責封裝底層的硬件差異，并把硬件層的特性以服務的方式提供接口， 供原子服務層進行調用，硬件的調整不應導致系統軟件對外提供的接口發生變化， 使得應用邏輯擺脫底層硬件平臺的束縛；

原子服務層作為中間層，與平臺解耦，對上承接應用服務的調用，對下進行設備抽象的訪問，體現車型差異，并配置化適配，使能上層應用跨車型復用；

應用/組合層服務主要負責用戶需求邏輯的實現，通過調用原子服務層提供的接口， 組合出千變萬化的場景化應用。

接口標準化：跨車型、跨零部件供應商，最大化復用，降低軟件定義汽車軟硬件開發復雜度。 在架構標準化的基礎上，如何能實現軟件的跨車企使用？就需要對層與層之間的接口進行標準化，不同整車廠、Tier1、平臺供應商定義同一套服務接口，使得不同整車廠之間，不同 Tier1 之間的軟件可以相互調用，大大增加軟件的復用性，縮短車輛開發周期。 在接口標準化推動方面，中國汽車工業協會已經發布了第三版《軟件定義汽車原子服務 API 接口與設備抽象 API 接口參考規范》，包含 700 多個 API，涵蓋車身控制、熱管理、能量管理、運動控制、智駕域、動力域、底盤域等多個功能域，參與接口標準化定義的成員包含整車廠、零部件、基礎平臺供應商、軟件供應商等 100 多家公司。

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 升級的復雜度。

3、硬件架構：區域接入+算力集中化整車電子電氣架構是實現軟件定義汽車的基石，目前市場上銷售的傳統汽車大部分是分布式電子電氣架構，如下圖所示。

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

在分布式電子電氣架構中，首先將汽車功能劃分為不同的模塊，如動力控制、底盤控制、主動安全、被動安全、智能駕駛、信息娛樂和車身等。然后再將每個模塊的功能再進一步細分，例如車身功能又細分為車燈控制、車門控制、座椅控制等功能。不同的電控功能采用獨立電控單元（ECU）實現，不同ECU 之間通過CAN/CAN FD 進行通信。 因為每個 ECU 由不同的供應商開發，有著不同的嵌入式軟件和底層代碼，所以分布式電子電氣架構在整車層面造成大量的冗余和 BOM 成本。另外，因為車內軟件都分布于各 ECU 上，且 ECU 都由各供應商獨立完成，其軟硬件是緊密耦合的， 整車廠并沒有權限去維護和更新 ECU 上的軟件。 快速滿足用戶需求是整車廠搶占市場份額的關鍵，而分布式電子電氣架構嚴重制約整車廠響應市場需求的速度。假設某車型中設計完成后，用戶提出增加駕駛員位置記憶功能，即駕駛員將車輛的座椅、方向盤、外后視鏡等相關系統調整到舒適的位置后， 可以將其設置為記憶位置，方便后續快速調整。需要對車門控制器、座椅控制器、方向盤控制器、網關等多個部件進行軟件變更，只有當各個零部件供應商完成變更，并且整車廠完成集成測試和整車測試后，才能夠將新功能投放市場，這將造成開發和變更周期長、成本高等問題。 為此，各整車廠早已開始儲備新型電子電氣架構方案，以促進軟件定義汽車的快速實現。新型電子電氣架構的顯著特征是功能（軟件）集中化、硬件標準化。通過中央計算平臺/域控制器對控制功能進行統一管理，從而降低硬件冗余和 BOM 成本，減少整車廠對眾多供應商的依賴。根據功能集中程度不同，新型電子電氣架構主要分為三種類型。

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

在域集中式電子電氣架構中，將整車電子電氣控制功能劃分為N 個功能域，每個功能域設計一個域控制器，其余控制器均為域內控制器，各域內控制器一般為智能傳感器、執行器和傳統控制器。 域集中式電子電氣架構示意圖如下圖所示，示例中將整車電子電氣控制功能劃分為五大功能域：動力域、底盤安全域、智能駕駛域、信息娛樂域和車身舒適域。

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

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

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

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

三域架構分別為車輛控制域、智能駕駛域和智能座艙域，將原來的動力域、底盤安全域和車身舒適域整合為車輛控制域，智能駕駛域和智能座艙域專注實現汽車智能化和網聯化。 三域架構有 3 個域控制器：車輛域控制器負責整車控制，對實時性和安全性要求高；智能駕駛域控制器負責自動駕駛相關感知、規劃、決策相關功能實現；智能座艙域控制器負責 HMI 交互和座艙相關功能實現。

第三種：區域接入+中央集中式電子電氣架構

中央集中式電子電氣架構不再按照功能去部署車內的電子電氣系統，而將整車所有功能域的控制邏輯均集中于中央計算平臺，進一步提升了系統功能集成度。原有分布式和域集中式架構中的 ECU 的控制/計算功能被中央計算平臺收編，轉變為更加簡單的傳感器或執行器。 為了減少線束長度，簡化通信，就近接入和供電，在中央集中式架構下可以按照物理位置劃分區域并在區域內部署區域控制器，形成中央計算平臺和多個區域控制器的架構，中央集中式電子電氣架構的示意圖如下圖所示。

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

硬件架構的升級，同時需要考慮跨域功能的融合、SOA 架構下的軟件功能分層、服務化后的控制實時性、功能安全設計、復雜的硬件設計與集成等等。

二、安全升級：構建多層次的整車縱深防御體系

1、功能安全

隨著電子電氣架構技術的不斷升級，整車越來越多的系統和組件對功能安全產生影響，為此，功能安全也從部分關鍵系統開發，向整車各系統全面開發拓展。 同時，由于域控制器、中央計算平臺等新架構技術的出現，對功能安全提出了新的技術挑戰，功能安全必須建立針對這些復雜系統及軟件的開發和測評手段。 功能安全技術也影響著電子電氣架構技術的發展，從傳統的失效安全（Fail-Safe）向失效運行（Fail-Operational）演變，電子電氣架構設計中引入了更多的冗余（如通信冗余、冗余控制器等）及安全保障措施。 未來，車輛智能化生態的形成，將促進功能安全技術走出單車，向全鏈路延伸，實現整體智能生態的整體安全。

2、預期功能安全

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

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

安全分析技術：通過 STPA 等安全分析手段，識別自動駕駛安全相關功能的不足性能局限及危害觸發條件，制定針對性措施，開展功能更新；

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

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

安全監控技術：通過車載和遠程手段，監測自動駕駛運行過程中的安全表現，識別安全風險并開展必要的風險控制措施，以確保自動駕駛運行安全。

3、網絡安全

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

圖 10 智能汽車全方位網絡安全防御網聯安全網聯接入層主要抵御針對以太網的 DOS、PING 類型、畸形報文、掃描爆破、欺騙、木馬等網絡攻擊。需要具備車云聯動機制的主動安全防護能力，可通過云端系統實時配置防護策略，主要包括接入認證機制、通信保護機制、以太網防火墻機制和入侵檢測與防御（IDPS）機制。

車內網安全

車輛內網安全主要抵御針對車載 CAN/CAN FD、車載以太網的攻擊入侵，包括報文監聽、錯誤注入、報文重放等攻擊。防護的策略包括：總線入侵檢測機制、內網防火墻機制、功能域隔離機制、總線通信保護機制和診斷安全保護機制。

關鍵 ECU 安全

為確保車輛系統或關鍵數據不被破壞，在車輛關鍵ECU 層面需具備安全啟動、關鍵數據安全存儲、系統安全運行的安全能力，并可為應用運行提供權限管理能力。

服務安全

SOA 安全框架需要遵循五個基本原則：機密性、完整性、真實性、授權性和可用性， 通過信息加密、數字簽名、密碼認證、設計訪問控制列表 ACL、DOS 攻擊監控等多種方案及產品實現網絡安全，同時保證這些網絡信息可被發現、被訪問、被通信以及被監測。

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

在服務發現上，設定信息安全分組隔離機制，使得服務廣播消息只發給有需要的的服務使用者；

在服務訪問上，為服務提供方設置信息安全訪問控制機制，認證并授權服務使用方發起的服務請求；

在服務通信上，根據 SOA 服務實際的業務應用場景決定 SOA 消息應采用的信息安全傳輸機制；

在服務監測上，設置服務安全監控機制，發現 SOA 服務相關的異常事件及安全響應處理機制。

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

汽車上的功能日新月異，軟件代碼量日益增加，傳統V 模型下的瀑布式開發已經不堪重負，為了快速交付給客戶最迫切需要的功能，軟件開發流程的轉變至關重要。目 前，越來越多的汽車零部件供應商轉向了敏捷開發。在系統架構實現軟硬件解耦，層次化架構系統軟件、中間件和應用軟件的基礎上，實現軟件功能的快速迭代、發布， 使得整車廠可以快速占領市場。 敏捷開發流程的核心是培養研發人員的協作意識、責任意識、質量意識、學習意識、創新意識，進而提升整個軟件研發團隊的研發能力，高效地開發高質量的軟件產品。特性開發采用以月為研發周期的迭代開發模式，進一步分為詳細設計與評審、特性開發與代碼走讀、代碼質量檢視與評估、測試用例設計與編寫、特性功能聯調、特性合入評審等多個子流程。每個子流程有具體的輸出件（設計文檔、源代碼、評審報告、測試用例、測試報告等）和量化評判體系（設計文檔章節完整性、增量代碼度量報告、評審意見密度、測試用例覆蓋率、缺陷密度等），確保每一個子流程均按照軟件研發質量要求達成，并對所有文檔歸檔以支持軟件質量回溯。 版本發布采用以周為發布周期的軟件版本快速迭代模式，每周從穩定分支發布版本， 對軟件基本功能、新增特性進行充分驗證，對已解決的問題進行回歸測試，均通過之后再發布版本。敏捷開發的業務價值：

用戶體驗能以月為單位發布。

漏洞和補丁按周進行快速發布。

軟件版本按小時迭代，部件與整車同步集成、自動化驗證（7*24h 無人值守）。

四、工具鏈升級：基于 SOA 的整車服務化開發

SOA 的總體思路是設計服務模型，將不同的基礎服務進行抽取，分層解耦定義恰當的API 接口，應用調用服務 API 接口實現業務邏輯。API 接口定義獨立于實現服務的硬件平臺、操作系統和編程語言，確保構建在不同系統中的服務可以以一種統一通用的方式進行交互。 對于汽車行業而言，SOA 是一套新引入的技術，需要一套有效的流程、方法和工具鏈，三者相輔相成，當前業界還沒有一套非常成熟的方法論和工具鏈，大部分整車廠和 Tier1/Tier2 都處于探索階段，下圖展示了一種基于服務的功能開發流程方法。

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

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

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

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

1、整體建議

如前所述，汽車產業正向電動化、智能化演進，技術、用戶體驗等驅動汽車行業快速成長。隨著智能汽車的逐步推進，整車軟硬件復雜度也在持續提升，行業向軟件定義汽車轉型已成產業共識，但軟件定義汽車還處于起步階段，軟件的大量引入給汽車產業從設計、開發、集成、測試、發布和維護都帶來一系列的挑戰。只有管理好軟硬件組合的復雜度，才能持續滿足消費者的體驗需求，形成市場競爭力。 分層解耦是提升軟件復用性，降低軟硬件開發復雜度的關鍵手段，也是邁向軟件定義汽車的必由之路。通過分層解耦，可以實現軟件與硬件分離，應用與基礎平臺分離， 但如何實施成為關鍵挑戰，將直接影響軟件定義汽車的戰略目標和價值達成。從技術層面，架構如何分層，服務如何劃分有利于最大化復用、最簡化開發維護和長期演進是關鍵挑戰。只有合理、穩定、統一的服務劃分才能確保軟件定義汽車價值實現最大化。從產業鏈方面，各方如何定位、分工、協作才能保障各方最大化利益是關鍵難 點，開放、合作、共贏是軟件定義汽車快速落地的基礎。

整體建議：

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

具體建議：

在設備抽象層，實現設備與端口的解耦，屏蔽硬件功能差異和廠家差異，并且該層由行業聯合定義，并實現標準化；

在基礎平臺層，實現基礎軟件與硬件解耦，屏蔽設備與驅動差異；

在原子服務層，實現服務與平臺解耦，提升軟件復用性，并且該層由行業聯合定義并標準化；

在應用/組合服務層，實現應用與服務解耦，應用跨車型復用，聚焦體驗，并且該層建議由整車廠主導。

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

同時，API 規范化并不等于產業競爭同質化，在標準上開放，在產品上競爭。整車廠和各零部件供應商可在關鍵技術上分層構筑核心競爭力，在協同上構筑管理能力提升效率和規模，在商業模式上構筑保護機制確保獨家/先發優勢，從而最終面向用戶提供獨特性、可進化、更高附加值的產品。 同時，不同廠商的硬件、軟件、平臺等具有互操作性，即不同車型和不同部件，能夠用相同的語言完成跨域調用、交換和共享信息的能力，讓產業鏈的每一個企業都受 益。

對于整車廠：

更易管理：向面向對象軟件管理模式轉變，軟件 Onetrack，更易管理更復雜的整車軟件系統和供應商，并可聚焦集成能力構建競爭力；

更快上市：基于 SOA 高效軟件開發，并可預集成服務 API，加速車型上市速度。

對于零部件供應商：

減少定制：減少不增值的繁復工作，降低面向不同車型開發和維護成本；

加速創新：釋放人才聚焦創新，構建差異化技術和產品。

對于軟件開發企業/開發者：

更易上手：容易理解，整合開發資源，快速開發；

更多機會：跨界人才新思維帶入汽車行業，持續挖掘后市場價值，帶來更多變現空間。

2、整車廠

整車廠直接面向終端用戶，提供滿足用戶需求的汽車產品，將軟硬件、應用功能及生態服務等各方集成起來，完成從整車制造到長期出行服務的交付。 整車廠不僅僅是生產汽車的制造商，也會面向消費者提供移動出行相關服務，通過軟件的開發、配置、迭代升級來滿足用戶多種多樣的用車需求。用戶能通過軟件設置汽車產品的不同功能，甚至可以根據個人喜好編輯出行場景或下載需要的特定場景功 能。為此，整車廠需要完成以下平臺的搭建及開發：1）硬件平臺整合硬件平臺是軟件定義汽車的基礎，現階段各個整車廠規劃的電子電氣架構主要有三種：集中功能域、跨域融合、中央計算域+區域接入。為應對智能化汽車和軟件定義汽車的需求， 中央計算域+區域接入將會是未來的主流電子電氣架構。整車廠需要根據自身情況合理分配各域的功能及區域接入硬件的接口。2）軟件集成整車廠需要具備軟件集成能力，構建“軟件中心”或者“用戶體驗中心”，并建立相應的組織架構，提升整車軟件開發能力。 第一階段：關注整車控制應用層軟件和與用戶體驗強相關類軟件，形成品牌特色，提高用戶粘性。搭建軟件開發環境，按照軟件開發流程，例如導入AUTOSAR 規范等， 實現應用層軟件和供應商硬件在開發層面解耦，應用層軟件封裝后交給供應商集成和配置，而不需要對其開放應用層，可以指定幾個硬件供應商。同時可與生態服務商合作，將第三方軟件嵌入應用層。應用層自主掌控后可實現快速移植，提高開發效率， 也為功能持續迭代、用戶常用常新提供基礎。OTA 是核心通道，第一階段實現是邁向軟件定義汽車的第一步。 第二階段：通過購買配置工具逐步實現應用層與底層的集成，硬件供應商提供“白 盒”，在整車廠進行集成和刷寫。實現真正意義上的軟硬件解耦，擴大硬件的采購范圍，降低采購成本。但是底層配置功能需要整車廠大量的投入，整車廠根據自身能力考慮是否入局。 第三階段：逐步進入硬件和底層的自主開發。通過硬件降低整車成本，自主選擇核心芯片，打破硬件平臺化的局限，以成本和客戶體驗為導向，根據整車配置及功能需求進行軟件模塊化移植。3）開放平臺的構建傳統汽車開發完全依托車廠的工程師理念，是一種凌駕于客戶之上的開發模式。開放平臺本著共贏、共生、共創的新模式，能在新形勢下解決供應商、整車以及用戶之間的關系。 開放平臺可以為車企開發工程師、第三方、用戶提供整車車輛能力，這些能力包括一些底層硬件能力、軟件能力、數據及信息，根據這些能力結合使用場景可以開發出多樣化的軟件，為用戶提供定制化、個性化、訂閱式服務，即為用戶和整車廠創造價 值，也獲得自身收益。實現用戶參與車輛軟件的開發，真正實現軟件定義汽車。 通過開放平臺，可以調用汽車上百千個硬件模塊，能提供比手機更強的感知能力，更多的應用場景，更大的覆蓋范圍，更長的生命周期，所以汽車生態圈要比手機生態圈更廣，比手機更加開放，更加貼近用戶。

3、零部件供應商

對于傳統零部件供應商來說，在軟件定義汽車發展趨勢下，整車廠在系統功能開發的話語權越來越大，借助軟硬件解耦和 SOA 架構的落地，整車廠也將逐漸承擔部分零部件供應商應用功能的開發，因此傳統以硬件為主的Tier1 迫切需要轉型尋求新的出路。 目前來看，軟硬件全棧能力的打造，是搶占下一個市場份額制高點的關鍵所在，很多能力非常全面的 Tier1 正在打造“硬件+底層軟件+中間件+應用軟件算法+系統集成”的全棧技術能力，既能為客戶提供硬件、也能提供軟件，同時也提供軟硬一體化的解決方案。但這樣的布局要求Tier1 大量的人力和資金的投入，不是所有Tier1 能夠承擔的。 對此，零部件供應商應將進一步開放硬件端口，對硬件的能力抽象化，為降低面向不同整車廠的定制成本，提高交付效率，需要將接口按照統一標準進行開放，從而降低匹配復雜度，減少軟硬件耦合度，增強靈活性和復用度。并主動聯合整車廠、軟件供應商等多方共同打造零部件生態，吸引和創造更多元更豐富的盈利場景。 在標準接口的前提下，性能的差異性會給零部件供應商帶來競爭，同時也會促進零部件供應商去創新和進步。零部件供應商的重點應該聚焦內部的核心算法，通過內部算法和代碼的優化升級，實現性能和體驗的差異性和持續進化。并通過和整車廠、人工智能、軟件等領域的 IT 公司合作，了解最新的需求和發展方向，調整自己的研發方向和能力，立足硬件，運用積累的行業 Know-How 優勢構建應用功能軟件能力，反哺并帶動差異化硬件銷售，是很多零部件供應商的選擇。

4、基礎平臺提供商

面向軟件定義汽車時代，基礎平臺廠商的目標是運用自身 ICT 技術積累和優勢，幫助整車廠打造適合整車上自身規劃的、差異化的下一代電子電氣架構，降低智能汽車研發復雜度，提高效率，加速智能車開發落地。 但目前從整車廠到一級供應商、二級供應商和三級供應商這樣的供應鏈模式正越來越模糊，而車企越來越希望能夠主導更多的內容，這迫使基礎平臺提供商必須以更加開放的姿態打破邊界，聚焦自身優勢產品，面向上下硬件和應用軟件提供開放API 接口，并為功能軟件提供安全可信的運行環境和易用的服務開發及驗證工具鏈。 建議基礎平臺提供商為整車廠提供一個面向智能汽車可持續進化的架構，在設計理念上應以人為本，圍繞用戶體驗與整車廠商業成功持續創新。

5、軟件供應商/軟件開發者

隨著整車廠自主權和軟件自研能力的不斷加強，整車廠開始尋求與軟件供應商的直接合作，比如整車廠商將首先尋求把座艙 HMI 交互系統功能收回，UI/UX 設計工具、語音識別模塊、音效模塊、人臉識別模塊等應用軟件則直接向軟件供應商購買軟件授權，從而繞過傳統 Tier1，實現自主開發。 隨著軟件定義汽車的變革的推動，汽車硬件體系逐漸趨于標準化，而軟件是汽車里迭代最快、最容易個性化和差異化的部分，同時軟件也將推動硬件創新，二者相輔相成。對于軟件供應商來說，能提供越多的軟件 IP 產品組合，就越可能獲取更高的單車價值。同時，軟件供應商也正尋求進入傳統 Tier1 把持的硬件設計、制造環節，比如域控制器、T-BOX 等，以提供多樣化的解決方案。對智能汽車 APP 應用開發來說，基于原子服務標準 API 開發應用軟件將變得非常便捷，容易上手。對于應用來說不用過多的關注底層的實現，降低不同層次、不同模塊的依賴性，類似基于安卓的開發模式。針對不同的人群、不同的車、不同的生活場景，不同的應用開發商就會做出功能不同、畫面不同、體驗不同的應用。應用開發的門檻變低了，就有更多的軟件供應商/ 開發者能參與到汽車應用 APP 開發中來，隨之而來的就是軟件開發的競爭變大了。軟件供應商應該基于一些調查數據去分析不同人群的偏好，針對不同的車型，開發出適合大眾并具有差異性的應用。用戶可以根據自己的實際情況，選擇性的安裝部分功能和特性應用，通過不同的應用和服務，可以定義自己車輛的一些特性，達到通過軟件進行功能升級或個性化定制的目的。 在競爭的過程中不僅會出現非常受歡迎的應用軟件，也會提升應用軟件供應商提升服務的主動性和精確性，提高產品創新的能力，從而繁榮智能汽車應用生態。

6、行業組織

政府應該從法規、政策、標準等方面來幫助整個汽車行業建立合理高效的管理制度， 監督整個行業有序、平穩的運轉，不斷做大做強，并確保整個行業的公平競爭。 從政策上鼓勵各企業發展新技術，比如可以獎勵對汽車行業有貢獻或者在某些技術方面有突破的企業單位，分享、展示創新成果，實現科技政策和科技創新的深度融合， 并不斷的完善政策，完善反饋體系，發揮政策對發展新技術的推動力，創造出良好的汽車軟件生態系統，以智能網聯汽車帶動智慧交通與智慧城市的建設發展。 從標準上建立解決共性問題的通用接口等規范，實現汽車軟硬件產品的互聯互通，避免各企業在通用標準化接口層面各自為戰，倡導各企業在統一接口下做好自身產品的創新與研發，避免重復和碎片化投入，提高研發效率，推動我國智能網聯汽車發展。

審核編輯：郭婷