面向服務的智能座艙軟件架構

面向信號的軟件架構

隨著汽車電子電氣架構向中央計算-域控制器的方向演進，甚至向車云一體化的方向邁進，適用于汽車的軟件平臺也需要進行相應的進化。

在傳統的觀念中，座艙域即娛樂域，座艙軟件架構即運行在座艙域控制器上，主要處理各種娛樂系統的信息，為汽車用戶提供豐富多彩且方便可用的娛樂信息系統。

與之相對應的，是基于信號架構的座艙軟件體系。

軟件架構演進

面向信號的軟件架構，匹配的是分布式ECU的電子電氣架構。但隨著EE架構的演進，自動駕駛域，車身控制域，智能座艙域逐步融合成統一的中央計算平臺。此時的智能座艙軟件系統已經不僅僅承載娛樂域功能，還將融合車身控制HMI，車內外通信，ADAS信息顯示等一系列的功能。與之所匹配的軟件架構，需要演進到面向服務的軟件體系架構。座艙軟件不是一個獨立的域控制器軟件體系，而是面向服務的整車軟件架構中的一環。

參考一個以用戶為中心的融合式智能服務場景，如下：

圖片來源：<汽車軟件全景圖(2022)>

針對上述汽車軟件的演進趨勢，面向服務的基礎軟件架構逐漸成為業界共識。相比面向信號的軟件架構，面向服務的軟件架構主要增加了信息分發和基礎服務框架等中間件內容。

其中一個正在進行的范例是ASF軟件架構。

ASF是AUTOSEMO Service Framework的縮寫，AUTOSEMO (中國汽車基礎軟件生態委員會)聯盟攜手行業內主流車企和零部件企業， 針對整車通用基礎服務研制的整車服務框架規范。通過該規范統一服務和接口，實現高效的整車控制器 設計、開發，讓跨廠商集成更便捷、可靠。

圖片來源：中國汽車基礎軟件發展白皮書3.0

ASF 是一組為功能服務開發、使用和集成而設計的通用化中間件服務集群，服務集群可以被所有的功能服務調用，用于對功能服務在整車平臺的能力進行擴展，并實現整車各系統之間的協同，保證整車軟件平臺的整體性并進行統一管控。

ASF 主要可分為原子服務、SOA 增強型服務、系統級基礎服務、整車級基礎服務。軟件架構設計師需基于各服務類型進行服務定義、設計，使 ASF 分層和功能定義更加清晰。在服務設計過程中遵循以下原則：

SOA 增強型服務具有通用性：即可為所有的應用服務提供通用功能，應用服務基于服務自身需求可使用該類服務，如數據存儲、服務信號轉換、服務調試等諸如此類的通用化功能。

系統級基礎服務，具有一定范圍的（如某操作系統或控制器之上）通用性，且具有抽象性：即對基礎軟件開發平臺（如 AUTOSAR Adaptive/Classic、Android 等）提供的通用化功能進行抽象，并提供給應用服務使用，如健康管理服務、網絡管理服務、時鐘服務、電源管理服務等。

整車級系統服務具有全局性：即該類服務的設計更多關注的是整車層面對車內所有系統的通用化功能進行協同和管控，該層服務是對系統基礎服務在整車層面的抽象和管控，即通過該層服務可以配置和控制系統基礎服務，如整車健康管理服務、整車網絡管理服務、整車時鐘服務、整車電源 管理服務等。

動態服務具有動態配置性：即應用服務在運行過程中可對服務進行配置，并基于配置輸入執行動態服務的功能。

原子服務具有獨立性：即其設計應與硬件配置和實現無關，與上層功能服務層和下層的硬件驅動層解耦，完全獨立。

原子服務具有原子性：即設計的服務不可再拆分，作為服務的最小單位和執行實體，為功能服務提供最基礎的執行或采集等功能

SOA 增強型服務

SOA 增強服務是在國際共同討論的基礎平臺進行服務框架擴展，封裝通用化的基礎功能。應用服務調用此類服務的接口更加方便完善其功能軟件邏輯、便于系統集成和敏捷測試。 該類服務為一組服務集群，以 Lib 庫的形式集成在應用服務中，并提供滿足國際共同討論的自適應 性標準的服務接口，使接口標準完整統一。主要包含模塊：服務調試、服務轉換、服務權限、服務同步、 SOA For Android、日志管理、動態數據收集、診斷管理。

系統級基礎服務

系統級基礎服務描述車端各類域控及網關節點，基于通用基礎軟件提供的底層支持，進行相應的封 裝和擴展，實現各類通用化服務功能和框架及在此基礎上形成的面向上層應用的各類服務接口（SDK接口、 API 接口、IPC 接口、RPC 接口等）。

系統基礎服務包括通用支撐類服務和公共框架類服務。通用支撐類服務包括服務治理（服務發布及發現）及服務容器、服務訪問及限流降級、數據訂閱及發布、集群管理、消息總線等。公共框架類服務包 括升級管理服務、健康管理服務、網絡配置服務、資源管理服務、時鐘同步服務、安全管理服務、測試服 務、電源管理服務、日志服務、診斷服務、數據收集等。

整車級系統基礎服務

整車級系統基礎服務是將各控制器節點的能力，通過跨域、跨核組合成整車級別的業務功能，以對應用層提供整車級統一的調用。整車級系統基礎服務包含整車電源管理服務、整車健康管理服務、整車時鐘 服務、整車診斷 Master、整車版本管理服務、整車數據采集服務、整車日志管理服務。

動態服務

動態服務工作流通常由車云一體的云端平臺（ 比如：開發者平臺）提供工具鏈支持，對接技術生態 及運營，從而在運行態具備靈活更新的能力。動態服務開發流程以邏輯組合建模為主，因此工具鏈需要 支持可視化 UML 建模，輸出模型腳本，并與車端建立同步機制。 動態服務開發面對的角色，不再局限于傳統的 OEM/ 供應商角色，而是拓展面向第三方開發者，甚 至是車主。

原子服務

原子服務是執行單一操作功能的服務，具有硬件功能上的不可拆分性。例如獲取一個數值或者執行 一個I/O操作。通過將域控制器的硬件功能，拆分為最小功能的原子服務，并統一定義原子服務的訪問接口， 從而實現軟硬件的完全隔離。軟硬件隔離后，車載硬件不再綁定特定的功能，應用軟件得以自由使用車 載硬件，實現更加靈活多樣化的功能。例如方向盤在正常行駛過程中，用于控制車輛的轉向，當車輛處 于非駕駛模式時，又可以成為中控大屏游戲應用的控制手柄。

面向服務的軟件架構

根據上述的描述，我們可以抽象得出面向服務的座艙軟件架構，如下：

紅色部分主要是從SOA的角度，在座艙軟件的中間件部分增加相關服務框架和信息分發機制。一個較詳細的分解可以參考汽車軟件全景圖文檔。

圖片來源：<汽車軟件全景圖(2022)>

SOA Framework目前已經是行業內各廠家正在主攻的方向，隨著中央計算-區域控制架構的逐步實現，SOA 中間件將發揮出重要的作用。

參考文獻

2021中國汽車座艙智能化發展市場需求研究報告.pdf -- 億歐智庫

汽車軟件全景圖(2022).pdf -- 國科礎石

中國汽車基礎軟件發展白皮書3.0 -- 中國汽車工業協會軟件分會

————————————————

版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

 原文鏈接：https://blog.csdn.net/joanna_xiao/article/details/134487544