【摘 要】?針對異構SOC實時內核部署SOA服務的性能瓶頸，文章設計一種基于車載異構計算平臺的SOA服務部署方法。實時內核從總線獲取和提供原始數據，通過核間通信協議傳輸至性能內核，性能內核基于SOME/IP協議將原始數據封裝為服務進行發布。與傳統的直接在實時內核上發布SOME/IP服務的方式相比，該方法能顯著降低實時內核系統的開銷，有效解決實時內核運算力不足、無法支撐大量SOME/IP報文發送的問題。同時，由于性能內核具有強大的運算能力，后續服務可以靈活迭代與擴展，用戶可以獲得更加便捷的車控交互體驗。
隨著汽車硬件配置趨同，整車廠很難在硬件上打造差異化，軟件定義汽車 （Software Defined Vehicles，SDV）趨勢愈發明顯。SDV可以幫助汽車實現功能的創新，滿足新生代用戶千人千面、千車千面的個性化需求。軟件高速迭代升級，能不斷為用戶帶來全新的駕乘體驗，提高產品的競爭力，增加用戶對品牌的黏性。面向服務的軟件架構（Service-Oriented Architecture，SOA）在計算機領域已經被證明是一種高效、靈活的系統軟件架構，為汽車軟件踐行 “軟硬分離，軟軟解耦”的SDV理念提供了重要的理論支撐[1-2]。SOA在汽車應用場景中，將車端不同軟件的功能及硬件抽象為具有標準接口的服務，服務的客戶端和消費端通過既定協議相互訪問、擴展組合[3]。服務調用通過系統內部IPC或者以太網SOME/IP協議實現[4]。當前，汽車電子電氣架構 （Electrical/Electronic Architecture，EEA）已經發展到集中式架構 （EEA3.0）階段，EEA3.0可以滿足汽車業務需求與硬件資源解耦，具備實現SOA的能力。其中，中央車載計算平臺是汽車應用場景中SOA服務部署的主要載體。中央計算平臺主要采用高性能的集成多個處理器的異構SOC芯片，其軟件架構是異構體分布式操作系統協同合作的軟件架構，不同的操作系統運行滿足具有不同功能安全等級、信息安全等級及實時性要求的應用軟件[5]。中央計算平臺的性能內核和實時內核分別基于Adaptive AUTOSAR和Classic AUTOSAR標準，可以分別實現功能的服務化，對外發布服務或者請求服務。但限于實時內核的處理能力和系統CPU、RAM及網絡資源，在實時操作系統上的服務直接通過SOME/IP方式提供的開銷過大，當服務數量達到一定量級時，該方式會產生明顯的性能瓶頸，甚至導致無法部署的情況，無法滿足當前車輛功能全面服務化的需求。而當前的車載計算平臺通常是基于異構的SOC芯片開發，實時內核上大量的車輛基礎控制能力需要以SOA服務的形式提供給性能內核上POSIX操作系統、車上其他計算平臺或云端的服務消費方使用。所以克服實時操作系統的性能瓶頸，解決實時操作系統提供服務的方式和能力，是實現整車功能全面服務化，充分發揮整車SOA優勢的關鍵。
針對車載計算平臺實時內核部署SOA服務的瓶頸，本文將設計一種基于異構SOC計算平臺的SOA服務部署方案，即一種將實時內核的服務通過核間通信協議傳輸至性能內核，再通過服務代理在性能內核進行部署的方式，能顯著降低實時內核端的資源開銷，提升相關SOC上可部署服務的數量。
本文采用異構雙核SOC作為車載中央計算平臺的主控芯片，主要包括性能內核和實時內核。中央計算平臺根據不同業務的實時性、功能安全及信息安全等要求劃分為3個分區：VM1、RT1和RT2。VM1分區為性能內核，搭載Linux操作系統和Adaptive AUTOSAR中間件，用于部署對算力要求較高的應用；RT1、RT2分區為實時內核，采用Classic AUTOSAR的實時操作系統，用于部署實時性和可靠性要求高的應用。根據AUTOSAR設計原則，需要進行軟件分層設計，分層的目的是實現軟硬解耦，軟軟分離，實現服務的靈活部署。本文軟件架構劃分為5層，如圖1所示。其中，L1層為硬件相關的基礎軟件；L2層為操作系統相關的基礎軟件；L3層為具備跨域通用性，為上層提供基礎功能或服務的基礎中間件；L4層為專屬于特定域，為上層提供基礎功能或服務，并做服務封裝的專用中間件；L5層為用于實現具體邏輯的應用軟件。結合了高性能和高實時性的計算平臺，可以承載整車基礎性功能和智能舒適功能。
圖1 異構中央計算平臺的軟件架構示意圖
SOME/IP是一種面向服務的可伸縮的中間件協議，是實現SOA接口契約化的重要的支撐協議之一[6]。在SOME/IP通信過程中，通常把提供服務的一端稱為服務端 （Server），請求服務的一端稱為客戶端 （Client）。SOME/IP傳輸的主體是Client和Server，傳輸內容為服務Service。服務是一個自包含的、無狀態的實體，一項服務實體由事件Event、方 法Methods 和 字 段Fields 等 組 成[7]。SOME/IP 服 務 發 現（SOME/IP Service Discovery）是SOME/IP中的服務發現機制，Client可以通過SOME/IP SD來查找服務的位置，判斷服務的可用性，或者訂閱事件組等，基于SD可以實現車內節點的即插即用[8]。Client可以用Request-Response、Fire&Forget模型訪問Server所提供的服務；Server利用Notification推送給Client已經訂閱的服務內容。
計算平臺性能內核通過部署Adaptive AUTOSAR[9]、實時內核通過部署Classic AUTOSAR[10]提供實現SOME/IP服務通信的方式分別如圖2和圖3所示。在Adaptive AUTOSAR中，SOA服務主要通過標準組件Communication Management（CM）以及VSOMEIP協議棧實現。Classic AUTOSAR中服務主要通過RTE、COM、PDUR以及SOAD等AUTOSAR標準模塊實現。
圖2 SOC的性能內核SOA服務架構示意圖
圖3 SOC實時內核的SOA服務架構示意圖
由于提供整車控制能力的基礎服務絕大部分來自于實時核上部署的Classic AUTOSAR 的應用或者依賴傳統的CAN總線信號，考慮到實時內核的算力和核資源，為了盡可能部署更多的服務，對外提供更多的整車車控的能力，本文設計了一種性能內核代理實時內核發布SOA服務的部署方案。如圖4所示，為了實現服務代理，在性能內核和實時內核的L4層分別部署SOA服務代理專用中間件和SOA API分發專用中間件。實時內核的SOA API分發中間件從RTE接口獲取服務Server SWC的功能，通過L3層核間通信轉換模塊Inter core Comm將實時內核的功能信息傳至性能內核的SOA服務代理中間件；然后性能內核的L3層Adaptive AUTOSAR 通 信 管 理 中 間 件（Communication Management，CM）通過API接口獲取SOA服務代理的信息，將實時內核的功能進行服務化；最后，協議棧以IPC或SOME/IP的方式提供服務。
圖4 異構SOC的SOA服務架構示意圖
實時內核上的SOA API Convertor組件將AUTOSAR標準接口進行語義轉換，其中RTE C/S接口轉換為服務接口Method，RTE S/R接口轉換為服務接口Event或Field。轉換后的服務接口參數、服務提供方ID、服務ID等信息序列化后，通過異構計算平臺內部總線Inter core Comm提供至性能內核端。性能內核代理實時內核實現SOA服務的接口映射如表1所示。部署于性能內核上的SOA服務代理組件通過內部總線收發接口獲取SOA API Convertor所提供的服務信息，對其進行反序列化解析后，將其轉換為標準的服務調用接口暴露至中央計算平臺內部IPC通信或外部SOME/IP通信上。中央計算平臺內部Client通過系統內IPC通信，根據標準的服務接口 （Method、Property/Field、Event）調用服務。外部Client通過以太網SOME/IP協議，根據標準的服務接口 （Method、Field、Event）調用服務。
表1 性能內核代理實時內核實現SOA服務的接口映射表
基于性能內核代理實時內核實現SOA服務的部署方法，本節以車載音樂律動氛圍燈服務為例，介紹異構車載計算平臺實施SOA服務代理的具體方案。
2.3.1 音樂律動氛圍燈功能需求分析
音樂律動氛圍燈的功能主要為燈光顏色或亮度跟隨音樂節奏和響度改變。音樂律動氛圍燈功能交互如圖5所示，發出激活或退出該功能指令、提供音樂信息的控制器為信息娛樂域控制器 （Infotainment Domain Controller，IDC），IDC 上的軟開關控制指令使能該功能，IDC可以提供5種特定的音源類型 （USB、BT Music、Car Play Music、Car Life Music、Online Music），中 央 計 算平臺收到音樂信號后對音源類型進行判斷，當音源信號為非指定的音源類型時，音樂律動氛圍燈功能自動退出。當出現音樂暫停或停止、音源信號插播導航、電話等其他效果時，IDC主動將音樂信號切換為OFF，退出音樂律動氛圍燈功能。
圖5 音樂律動氛圍燈系統交互圖
氛圍燈隨音樂律動的功能需求為：IDC播放音樂時，向中央計算平臺發送每25ms時間內的最大音樂振幅、最大分貝值和最大分貝值對應的頻率值等音樂特征。中央計算平臺根據接收到的音樂特征控制氛圍燈的顏色和亮度跟隨音樂節奏進行律動。
2.3.2 音樂律動氛圍燈服務設計
基于EEA3.0電子電氣架構，實現音樂律動氛圍燈應用功能的物理架構如圖6所示，IDC是音樂律動氛圍燈服務的Client，中央計算單元是服務Server，區域控制器是燈光顏色和亮度變化的執行單元。中央計算平臺與IDC之間的通信采用車載以太網，氛圍燈的區域控制器與中央計算平臺之間的通信采用CANFD總線，計算平臺實時內核與性能內核之間通過核間通信協議交互。
圖6 音樂律動氛圍燈應用功能的物理架構
IDC提供播放音樂和音量調節等功能。作為音樂燈光秀功能的消費方，IDC可直接請求中央處理單元的服務接口來判斷進入音樂燈光秀功能條件，并控制音樂律動氛圍燈功能的開啟或退出。中央計算單元作為服務的提供方，提供服務調用的接口，中央計算平臺的實時內核根據接收到的音樂特征按照相應算法計算后，向區域控制器發出控制燈光顏色和亮度的指令。區域控制器驅動燈光呈現氛圍燈的效果。
根據功能需求結合SOA的設計思想，對音樂律動應用涉及到的基礎服務設計如表2所示。IDC提供氛圍燈音樂律動管理服務包含音源類型、所播放音樂的特征信息設置功能。中央運算平臺的實時內核的SWC提供氛圍的控制服務，性能內核的SOA代理模塊通過核間通信代理該服務，SOA代理對外提供氛圍燈控制服務。音樂律動氛圍燈應用通過消費音樂播放和氛圍燈控制基礎服務，來實現控制車上的氛圍燈的顏色和亮度隨著音樂播放的聲音和節奏變化而變化的功能。
表2 音樂氛圍燈服務矩陣
基于SOME/IP的SOA服務測試主要包括ECU級的協議一致性測試、系統級與實車級的通信測試。本文側重驗證氛圍燈音樂律動服務的信息交互行為和響應實時性。音樂氛圍燈服務發布和調用的過程如圖7所示，為了測試服務鏈路中的數據傳輸情況，需要獲取IDC與中央計算單元之間的SOME/IP報文，以及中央計算單元的SOA日志。
圖7 服務發布和調用過程
臺架測試環境如圖8所示，測試平臺包括VN5650和配套軟件CANoe16.0，被測件為中央運算單元，性能內核作為服務端 （Server）提供氛圍燈音樂律動服務，上位機作為客戶端 （Client）模擬主機調用服務。VN5650作為以太網接口收發中央計算平臺的以太網報文，通過CANoe的報文Trace觀察中央計算平臺與模擬客戶端的SOME/IP信息交互情況，通過SOA日志、核間通信日志分析服務發布和調用過程。
圖8 測試環境
3.2.1 服務代理方案有效性分析
SOA進程及核間通信啟動后，服務發布過程的SOME/IP SD報文及SOA日志信息如圖9所示。性能內核的SOA服代理模塊通過核間通信主動連接實時內核的SOA API分發模塊，連接成功后，SOA服務代理調用CM以SOME/IP的方式發布服務，即廣播SOME/IP SD Offer Service報文，告知氛圍燈律動服務 （Service ID：0x10D3）已經啟動，有需求的Client方可根據SOME/IP SD報文中0x10D3服務所在的IP地址和端口號等信息與Server方創建連接。
圖9 音樂氛圍燈服務發布過程日志信息
確認氛圍燈服務為可用狀態后，如圖10所示，上位機模擬IDC （Client）發送SOME/IP Setter報文，通過CurAudioSource 接 口 將 音 源USAGE 類 型 設 置 為BTMUSICE 型（Method ID：6001，Payload：0x4），通過CurToneFolloInfo接口將音樂的振幅、頻率和分貝設置為00 00 00 00 00 00 （Method ID：6002，Payload：0x00 00 00 00 00 00）。SOME/IP Setter 報 文 上 報 給CM 后，CM 進 行Service ID：0x10D3，Method ID=6001或6002的調用，性能內核的SOA代理收到SOME/IP Setter報文的Payload等參數信息。接著，SOA代理通過核間通信向實時內核的SOA API分發發送Setter報文，實時內核的氛圍燈控制SWC通過RTE接口獲取Setter信息，執行相應邏輯后，SOA API分發通過RTE接口獲取SWC的執行結果，并通過核間通信發送回性能內核，CM收到后，回復Setter應答，最后由SOME/IP協議棧回復IDC的Setter請求。
圖10 音樂氛圍燈服務調用過程日志信息
3.2.2 服務代理方案響應實時性分析
為了保證音樂節奏和氛圍燈律動的匹配，獲得良好的用戶體驗，要求中央運算單元收到第1幀音樂數據的時間要比人耳聽到音樂的時間早，并且中央運算單元對音樂節奏變化的響應時間小于或等于人耳對音樂節奏變化的響應時間。因此，需要分析音樂氛圍燈服務響應的實時性。如圖11所示，以性能內核接收Setter請求報文和發出應答報文 為 起 止 時 間，調 用 一 次Service ID：0x10D3，Method ID=6002的時間為25ms，符合人體對音視頻同步的感知要求 （音頻相對視頻超前20ms到延后90ms的范圍內，人體對音視頻同步不敏感）[11]。
圖11 調用一次音樂氛圍燈服務所需時間
為了驗證IDC以短周期頻繁調用氛圍燈服務時的響應實 時 性，模 擬IDC 在10min 內 以50ms 為 周 期 調 用 服 務，10min內實際調用周期及音樂氛圍燈服務響應時間如圖12所示。實際調用服務的平均周期為51ms，服務響應的平均時間為23ms，符合響應實時性要求[11]。
圖12 10min內模擬IDC調用服務周期和10min內音樂氛圍燈服務響應時間
面向服務架構 （SOA）被認為是能夠支持未來汽車軟件發展的核心技術之一，汽車制造商OEM向SOA架構轉型，期望汽車行業的商業模式從一次性購車逐步轉變為對智能駕駛體驗、智能服務體驗、座艙娛樂體驗的持續升級迭代消費，智能汽車成為持續創造價值的平臺。本文提出的基于異構SOC的中央計算平臺服務部署的方法，突破了異構SOC實施內核提供服務的性能和資源的限制，大大提升了整車功能服務化的水平。試驗結果表明按照異構SOC服務部署的方案可實現音樂律動應用的功能，滿足其功能對代理服務實時性的要求。
參考文獻：
OME/IP: Impleme
tation of a Scalable and Service Oriented Communication Middleware[C]//Jubilee International Convention on Information，Communication and Electronic Technology（MIPRO），New York：Institute of Electrical and Electronics Engineers，2022：1426-1429.
rom
DAS to Android-b
ed IVI domain over SOME/IP[J].IEEE Transactions on Intelligent Vehicles，2023，8（4）：3166-3177.
