【摘 要】 針對(duì)異構(gòu)SOC實(shí)時(shí)內(nèi)核部署SOA服務(wù)的性能瓶頸，文章設(shè)計(jì)一種基于車(chē)載異構(gòu)計(jì)算平臺(tái)的SOA服務(wù)部署方法。實(shí)時(shí)內(nèi)核從總線獲取和提供原始數(shù)據(jù)，通過(guò)核間通信協(xié)議傳輸至性能內(nèi)核，性能內(nèi)核基于SOME/IP協(xié)議將原始數(shù)據(jù)封裝為服務(wù)進(jìn)行發(fā)布。與傳統(tǒng)的直接在實(shí)時(shí)內(nèi)核上發(fā)布SOME/IP服務(wù)的方式相比，該方法能顯著降低實(shí)時(shí)內(nèi)核系統(tǒng)的開(kāi)銷(xiāo)，有效解決實(shí)時(shí)內(nèi)核運(yùn)算力不足、無(wú)法支撐大量SOME/IP報(bào)文發(fā)送的問(wèn)題。同時(shí)，由于性能內(nèi)核具有強(qiáng)大的運(yùn)算能力，后續(xù)服務(wù)可以靈活迭代與擴(kuò)展，用戶可以獲得更加便捷的車(chē)控交互體驗(yàn)。

1 研究背景

隨著汽車(chē)硬件配置趨同，整車(chē)廠很難在硬件上打造差異化，軟件定義汽車(chē) （Software Defined Vehicles，SDV）趨勢(shì)愈發(fā)明顯。SDV可以幫助汽車(chē)實(shí)現(xiàn)功能的創(chuàng)新，滿足新生代用戶千人千面、千車(chē)千面的個(gè)性化需求。軟件高速迭代升級(jí)，能不斷為用戶帶來(lái)全新的駕乘體驗(yàn)，提高產(chǎn)品的競(jìng)爭(zhēng)力，增加用戶對(duì)品牌的黏性。面向服務(wù)的軟件架構(gòu)（Service-Oriented Architecture，SOA）在計(jì)算機(jī)領(lǐng)域已經(jīng)被證明是一種高效、靈活的系統(tǒng)軟件架構(gòu)，為汽車(chē)軟件踐行 “軟硬分離，軟軟解耦”的SDV理念提供了重要的理論支撐[1-2]。SOA在汽車(chē)應(yīng)用場(chǎng)景中，將車(chē)端不同軟件的功能及硬件抽象為具有標(biāo)準(zhǔn)接口的服務(wù)，服務(wù)的客戶端和消費(fèi)端通過(guò)既定協(xié)議相互訪問(wèn)、擴(kuò)展組合[3]。服務(wù)調(diào)用通過(guò)系統(tǒng)內(nèi)部IPC或者以太網(wǎng)SOME/IP協(xié)議實(shí)現(xiàn)[4]。當(dāng)前，汽車(chē)電子電氣架構(gòu) （Electrical/Electronic Architecture，EEA）已經(jīng)發(fā)展到集中式架構(gòu) （EEA3.0）階段，EEA3.0可以滿足汽車(chē)業(yè)務(wù)需求與硬件資源解耦，具備實(shí)現(xiàn)SOA的能力。其中，中央車(chē)載計(jì)算平臺(tái)是汽車(chē)應(yīng)用場(chǎng)景中SOA服務(wù)部署的主要載體。中央計(jì)算平臺(tái)主要采用高性能的集成多個(gè)處理器的異構(gòu)SOC芯片，其軟件架構(gòu)是異構(gòu)體分布式操作系統(tǒng)協(xié)同合作的軟件架構(gòu)，不同的操作系統(tǒng)運(yùn)行滿足具有不同功能安全等級(jí)、信息安全等級(jí)及實(shí)時(shí)性要求的應(yīng)用軟件[5]。中央計(jì)算平臺(tái)的性能內(nèi)核和實(shí)時(shí)內(nèi)核分別基于Adaptive AUTOSAR和Classic AUTOSAR標(biāo)準(zhǔn)，可以分別實(shí)現(xiàn)功能的服務(wù)化，對(duì)外發(fā)布服務(wù)或者請(qǐng)求服務(wù)。但限于實(shí)時(shí)內(nèi)核的處理能力和系統(tǒng)CPU、RAM及網(wǎng)絡(luò)資源，在實(shí)時(shí)操作系統(tǒng)上的服務(wù)直接通過(guò)SOME/IP方式提供的開(kāi)銷(xiāo)過(guò)大，當(dāng)服務(wù)數(shù)量達(dá)到一定量級(jí)時(shí)，該方式會(huì)產(chǎn)生明顯的性能瓶頸，甚至導(dǎo)致無(wú)法部署的情況，無(wú)法滿足當(dāng)前車(chē)輛功能全面服務(wù)化的需求。而當(dāng)前的車(chē)載計(jì)算平臺(tái)通常是基于異構(gòu)的SOC芯片開(kāi)發(fā)，實(shí)時(shí)內(nèi)核上大量的車(chē)輛基礎(chǔ)控制能力需要以SOA服務(wù)的形式提供給性能內(nèi)核上POSIX操作系統(tǒng)、車(chē)上其他計(jì)算平臺(tái)或云端的服務(wù)消費(fèi)方使用。所以克服實(shí)時(shí)操作系統(tǒng)的性能瓶頸，解決實(shí)時(shí)操作系統(tǒng)提供服務(wù)的方式和能力，是實(shí)現(xiàn)整車(chē)功能全面服務(wù)化，充分發(fā)揮整車(chē)SOA優(yōu)勢(shì)的關(guān)鍵。

針對(duì)車(chē)載計(jì)算平臺(tái)實(shí)時(shí)內(nèi)核部署SOA服務(wù)的瓶頸，本文將設(shè)計(jì)一種基于異構(gòu)SOC計(jì)算平臺(tái)的SOA服務(wù)部署方案，即一種將實(shí)時(shí)內(nèi)核的服務(wù)通過(guò)核間通信協(xié)議傳輸至性能內(nèi)核，再通過(guò)服務(wù)代理在性能內(nèi)核進(jìn)行部署的方式，能顯著降低實(shí)時(shí)內(nèi)核端的資源開(kāi)銷(xiāo)，提升相關(guān)SOC上可部署服務(wù)的數(shù)量。

2 方案設(shè)計(jì)

2.1 中央計(jì)算平臺(tái)架構(gòu)方案設(shè)計(jì)

本文采用異構(gòu)雙核SOC作為車(chē)載中央計(jì)算平臺(tái)的主控芯片，主要包括性能內(nèi)核和實(shí)時(shí)內(nèi)核。中央計(jì)算平臺(tái)根據(jù)不同業(yè)務(wù)的實(shí)時(shí)性、功能安全及信息安全等要求劃分為3個(gè)分區(qū)：VM1、RT1和RT2。VM1分區(qū)為性能內(nèi)核，搭載Linux操作系統(tǒng)和Adaptive AUTOSAR中間件，用于部署對(duì)算力要求較高的應(yīng)用；RT1、RT2分區(qū)為實(shí)時(shí)內(nèi)核，采用Classic AUTOSAR的實(shí)時(shí)操作系統(tǒng)，用于部署實(shí)時(shí)性和可靠性要求高的應(yīng)用。根據(jù)AUTOSAR設(shè)計(jì)原則，需要進(jìn)行軟件分層設(shè)計(jì)，分層的目的是實(shí)現(xiàn)軟硬解耦，軟軟分離，實(shí)現(xiàn)服務(wù)的靈活部署。本文軟件架構(gòu)劃分為5層，如圖1所示。其中，L1層為硬件相關(guān)的基礎(chǔ)軟件；L2層為操作系統(tǒng)相關(guān)的基礎(chǔ)軟件；L3層為具備跨域通用性，為上層提供基礎(chǔ)功能或服務(wù)的基礎(chǔ)中間件；L4層為專(zhuān)屬于特定域，為上層提供基礎(chǔ)功能或服務(wù)，并做服務(wù)封裝的專(zhuān)用中間件；L5層為用于實(shí)現(xiàn)具體邏輯的應(yīng)用軟件。結(jié)合了高性能和高實(shí)時(shí)性的計(jì)算平臺(tái)，可以承載整車(chē)基礎(chǔ)性功能和智能舒適功能。

圖1 異構(gòu)中央計(jì)算平臺(tái)的軟件架構(gòu)示意圖

2.2 SOA服務(wù)的部署方案設(shè)計(jì)

SOME/IP是一種面向服務(wù)的可伸縮的中間件協(xié)議，是實(shí)現(xiàn)SOA接口契約化的重要的支撐協(xié)議之一[6]。在SOME/IP通信過(guò)程中，通常把提供服務(wù)的一端稱為服務(wù)端 （Server），請(qǐng)求服務(wù)的一端稱為客戶端 （Client）。SOME/IP傳輸?shù)闹黧w是Client和Server，傳輸內(nèi)容為服務(wù)Service。服務(wù)是一個(gè)自包含的、無(wú)狀態(tài)的實(shí)體，一項(xiàng)服務(wù)實(shí)體由事件Event、方 法Methods 和 字 段Fields 等 組 成[7]。SOME/IP 服 務(wù) 發(fā) 現(xiàn)（SOME/IP Service Discovery）是SOME/IP中的服務(wù)發(fā)現(xiàn)機(jī)制，Client可以通過(guò)SOME/IP SD來(lái)查找服務(wù)的位置，判斷服務(wù)的可用性，或者訂閱事件組等，基于SD可以實(shí)現(xiàn)車(chē)內(nèi)節(jié)點(diǎn)的即插即用[8]。Client可以用Request-Response、Fire&Forget模型訪問(wèn)Server所提供的服務(wù)；Server利用Notification推送給Client已經(jīng)訂閱的服務(wù)內(nèi)容。

計(jì)算平臺(tái)性能內(nèi)核通過(guò)部署Adaptive AUTOSAR[9]、實(shí)時(shí)內(nèi)核通過(guò)部署Classic AUTOSAR[10]提供實(shí)現(xiàn)SOME/IP服務(wù)通信的方式分別如圖2和圖3所示。在Adaptive AUTOSAR中，SOA服務(wù)主要通過(guò)標(biāo)準(zhǔn)組件Communication Management（CM）以及VSOMEIP協(xié)議棧實(shí)現(xiàn)。Classic AUTOSAR中服務(wù)主要通過(guò)RTE、COM、PDUR以及SOAD等AUTOSAR標(biāo)準(zhǔn)模塊實(shí)現(xiàn)。

圖2 SOC的性能內(nèi)核SOA服務(wù)架構(gòu)示意圖

圖3 SOC實(shí)時(shí)內(nèi)核的SOA服務(wù)架構(gòu)示意圖

由于提供整車(chē)控制能力的基礎(chǔ)服務(wù)絕大部分來(lái)自于實(shí)時(shí)核上部署的Classic AUTOSAR 的應(yīng)用或者依賴傳統(tǒng)的CAN總線信號(hào)，考慮到實(shí)時(shí)內(nèi)核的算力和核資源，為了盡可能部署更多的服務(wù)，對(duì)外提供更多的整車(chē)車(chē)控的能力，本文設(shè)計(jì)了一種性能內(nèi)核代理實(shí)時(shí)內(nèi)核發(fā)布SOA服務(wù)的部署方案。如圖4所示，為了實(shí)現(xiàn)服務(wù)代理，在性能內(nèi)核和實(shí)時(shí)內(nèi)核的L4層分別部署SOA服務(wù)代理專(zhuān)用中間件和SOA API分發(fā)專(zhuān)用中間件。實(shí)時(shí)內(nèi)核的SOA API分發(fā)中間件從RTE接口獲取服務(wù)Server SWC的功能，通過(guò)L3層核間通信轉(zhuǎn)換模塊Inter core Comm將實(shí)時(shí)內(nèi)核的功能信息傳至性能內(nèi)核的SOA服務(wù)代理中間件；然后性能內(nèi)核的L3層Adaptive AUTOSAR 通 信 管 理 中 間 件（Communication Management，CM）通過(guò)API接口獲取SOA服務(wù)代理的信息，將實(shí)時(shí)內(nèi)核的功能進(jìn)行服務(wù)化；最后，協(xié)議棧以IPC或SOME/IP的方式提供服務(wù)。

圖4 異構(gòu)SOC的SOA服務(wù)架構(gòu)示意圖

實(shí)時(shí)內(nèi)核上的SOA API Convertor組件將AUTOSAR標(biāo)準(zhǔn)接口進(jìn)行語(yǔ)義轉(zhuǎn)換，其中RTE C/S接口轉(zhuǎn)換為服務(wù)接口Method，RTE S/R接口轉(zhuǎn)換為服務(wù)接口Event或Field。轉(zhuǎn)換后的服務(wù)接口參數(shù)、服務(wù)提供方ID、服務(wù)ID等信息序列化后，通過(guò)異構(gòu)計(jì)算平臺(tái)內(nèi)部總線Inter core Comm提供至性能內(nèi)核端。性能內(nèi)核代理實(shí)時(shí)內(nèi)核實(shí)現(xiàn)SOA服務(wù)的接口映射如表1所示。部署于性能內(nèi)核上的SOA服務(wù)代理組件通過(guò)內(nèi)部總線收發(fā)接口獲取SOA API Convertor所提供的服務(wù)信息，對(duì)其進(jìn)行反序列化解析后，將其轉(zhuǎn)換為標(biāo)準(zhǔn)的服務(wù)調(diào)用接口暴露至中央計(jì)算平臺(tái)內(nèi)部IPC通信或外部SOME/IP通信上。中央計(jì)算平臺(tái)內(nèi)部Client通過(guò)系統(tǒng)內(nèi)IPC通信，根據(jù)標(biāo)準(zhǔn)的服務(wù)接口 （Method、Property/Field、Event）調(diào)用服務(wù)。外部Client通過(guò)以太網(wǎng)SOME/IP協(xié)議，根據(jù)標(biāo)準(zhǔn)的服務(wù)接口 （Method、Field、Event）調(diào)用服務(wù)。

表1 性能內(nèi)核代理實(shí)時(shí)內(nèi)核實(shí)現(xiàn)SOA服務(wù)的接口映射表

2.3 基于異構(gòu)計(jì)算平臺(tái)的音樂(lè)律動(dòng)氛圍燈SOA服務(wù)設(shè)計(jì)

基于性能內(nèi)核代理實(shí)時(shí)內(nèi)核實(shí)現(xiàn)SOA服務(wù)的部署方法，本節(jié)以車(chē)載音樂(lè)律動(dòng)氛圍燈服務(wù)為例，介紹異構(gòu)車(chē)載計(jì)算平臺(tái)實(shí)施SOA服務(wù)代理的具體方案。

2.3.1 音樂(lè)律動(dòng)氛圍燈功能需求分析

音樂(lè)律動(dòng)氛圍燈的功能主要為燈光顏色或亮度跟隨音樂(lè)節(jié)奏和響度改變。音樂(lè)律動(dòng)氛圍燈功能交互如圖5所示，發(fā)出激活或退出該功能指令、提供音樂(lè)信息的控制器為信息娛樂(lè)域控制器 （Infotainment Domain Controller，IDC），IDC 上的軟開(kāi)關(guān)控制指令使能該功能，IDC可以提供5種特定的音源類(lèi)型 （USB、BT Music、Car Play Music、Car Life Music、Online Music），中 央 計(jì) 算平臺(tái)收到音樂(lè)信號(hào)后對(duì)音源類(lèi)型進(jìn)行判斷，當(dāng)音源信號(hào)為非指定的音源類(lèi)型時(shí)，音樂(lè)律動(dòng)氛圍燈功能自動(dòng)退出。當(dāng)出現(xiàn)音樂(lè)暫停或停止、音源信號(hào)插播導(dǎo)航、電話等其他效果時(shí)，IDC主動(dòng)將音樂(lè)信號(hào)切換為OFF，退出音樂(lè)律動(dòng)氛圍燈功能。

圖5 音樂(lè)律動(dòng)氛圍燈系統(tǒng)交互圖

氛圍燈隨音樂(lè)律動(dòng)的功能需求為：IDC播放音樂(lè)時(shí)，向中央計(jì)算平臺(tái)發(fā)送每25ms時(shí)間內(nèi)的最大音樂(lè)振幅、最大分貝值和最大分貝值對(duì)應(yīng)的頻率值等音樂(lè)特征。中央計(jì)算平臺(tái)根據(jù)接收到的音樂(lè)特征控制氛圍燈的顏色和亮度跟隨音樂(lè)節(jié)奏進(jìn)行律動(dòng)。

2.3.2 音樂(lè)律動(dòng)氛圍燈服務(wù)設(shè)計(jì)

基于EEA3.0電子電氣架構(gòu)，實(shí)現(xiàn)音樂(lè)律動(dòng)氛圍燈應(yīng)用功能的物理架構(gòu)如圖6所示，IDC是音樂(lè)律動(dòng)氛圍燈服務(wù)的Client，中央計(jì)算單元是服務(wù)Server，區(qū)域控制器是燈光顏色和亮度變化的執(zhí)行單元。中央計(jì)算平臺(tái)與IDC之間的通信采用車(chē)載以太網(wǎng)，氛圍燈的區(qū)域控制器與中央計(jì)算平臺(tái)之間的通信采用CANFD總線，計(jì)算平臺(tái)實(shí)時(shí)內(nèi)核與性能內(nèi)核之間通過(guò)核間通信協(xié)議交互。

圖6 音樂(lè)律動(dòng)氛圍燈應(yīng)用功能的物理架構(gòu)

IDC提供播放音樂(lè)和音量調(diào)節(jié)等功能。作為音樂(lè)燈光秀功能的消費(fèi)方，IDC可直接請(qǐng)求中央處理單元的服務(wù)接口來(lái)判斷進(jìn)入音樂(lè)燈光秀功能條件，并控制音樂(lè)律動(dòng)氛圍燈功能的開(kāi)啟或退出。中央計(jì)算單元作為服務(wù)的提供方，提供服務(wù)調(diào)用的接口，中央計(jì)算平臺(tái)的實(shí)時(shí)內(nèi)核根據(jù)接收到的音樂(lè)特征按照相應(yīng)算法計(jì)算后，向區(qū)域控制器發(fā)出控制燈光顏色和亮度的指令。區(qū)域控制器驅(qū)動(dòng)燈光呈現(xiàn)氛圍燈的效果。

根據(jù)功能需求結(jié)合SOA的設(shè)計(jì)思想，對(duì)音樂(lè)律動(dòng)應(yīng)用涉及到的基礎(chǔ)服務(wù)設(shè)計(jì)如表2所示。IDC提供氛圍燈音樂(lè)律動(dòng)管理服務(wù)包含音源類(lèi)型、所播放音樂(lè)的特征信息設(shè)置功能。中央運(yùn)算平臺(tái)的實(shí)時(shí)內(nèi)核的SWC提供氛圍的控制服務(wù)，性能內(nèi)核的SOA代理模塊通過(guò)核間通信代理該服務(wù)，SOA代理對(duì)外提供氛圍燈控制服務(wù)。音樂(lè)律動(dòng)氛圍燈應(yīng)用通過(guò)消費(fèi)音樂(lè)播放和氛圍燈控制基礎(chǔ)服務(wù)，來(lái)實(shí)現(xiàn)控制車(chē)上的氛圍燈的顏色和亮度隨著音樂(lè)播放的聲音和節(jié)奏變化而變化的功能。

表2 音樂(lè)氛圍燈服務(wù)矩陣

3 試驗(yàn)驗(yàn)證

3.1 測(cè)試方案及測(cè)試環(huán)境

基于SOME/IP的SOA服務(wù)測(cè)試主要包括ECU級(jí)的協(xié)議一致性測(cè)試、系統(tǒng)級(jí)與實(shí)車(chē)級(jí)的通信測(cè)試。本文側(cè)重驗(yàn)證氛圍燈音樂(lè)律動(dòng)服務(wù)的信息交互行為和響應(yīng)實(shí)時(shí)性。音樂(lè)氛圍燈服務(wù)發(fā)布和調(diào)用的過(guò)程如圖7所示，為了測(cè)試服務(wù)鏈路中的數(shù)據(jù)傳輸情況，需要獲取IDC與中央計(jì)算單元之間的SOME/IP報(bào)文，以及中央計(jì)算單元的SOA日志。

圖7 服務(wù)發(fā)布和調(diào)用過(guò)程

臺(tái)架測(cè)試環(huán)境如圖8所示，測(cè)試平臺(tái)包括VN5650和配套軟件CANoe16.0，被測(cè)件為中央運(yùn)算單元，性能內(nèi)核作為服務(wù)端 （Server）提供氛圍燈音樂(lè)律動(dòng)服務(wù)，上位機(jī)作為客戶端 （Client）模擬主機(jī)調(diào)用服務(wù)。VN5650作為以太網(wǎng)接口收發(fā)中央計(jì)算平臺(tái)的以太網(wǎng)報(bào)文，通過(guò)CANoe的報(bào)文Trace觀察中央計(jì)算平臺(tái)與模擬客戶端的SOME/IP信息交互情況，通過(guò)SOA日志、核間通信日志分析服務(wù)發(fā)布和調(diào)用過(guò)程。

圖8 測(cè)試環(huán)境

3.2 結(jié)果與分析

3.2.1 服務(wù)代理方案有效性分析

SOA進(jìn)程及核間通信啟動(dòng)后，服務(wù)發(fā)布過(guò)程的SOME/IP SD報(bào)文及SOA日志信息如圖9所示。性能內(nèi)核的SOA服代理模塊通過(guò)核間通信主動(dòng)連接實(shí)時(shí)內(nèi)核的SOA API分發(fā)模塊，連接成功后，SOA服務(wù)代理調(diào)用CM以SOME/IP的方式發(fā)布服務(wù)，即廣播SOME/IP SD Offer Service報(bào)文，告知氛圍燈律動(dòng)服務(wù) （Service ID：0x10D3）已經(jīng)啟動(dòng)，有需求的Client方可根據(jù)SOME/IP SD報(bào)文中0x10D3服務(wù)所在的IP地址和端口號(hào)等信息與Server方創(chuàng)建連接。

圖9 音樂(lè)氛圍燈服務(wù)發(fā)布過(guò)程日志信息

確認(rèn)氛圍燈服務(wù)為可用狀態(tài)后，如圖10所示，上位機(jī)模擬IDC （Client）發(fā)送SOME/IP Setter報(bào)文，通過(guò)CurAudioSource 接 口 將 音 源USAGE 類(lèi) 型 設(shè) 置 為BTMUSICE 型（Method ID：6001，Payload：0x4），通過(guò)CurToneFolloInfo接口將音樂(lè)的振幅、頻率和分貝設(shè)置為00 00 00 00 00 00 （Method ID：6002，Payload：0x00 00 00 00 00 00）。SOME/IP Setter 報(bào) 文 上 報(bào) 給CM 后，CM 進(jìn) 行Service ID：0x10D3，Method ID=6001或6002的調(diào)用，性能內(nèi)核的SOA代理收到SOME/IP Setter報(bào)文的Payload等參數(shù)信息。接著，SOA代理通過(guò)核間通信向?qū)崟r(shí)內(nèi)核的SOA API分發(fā)發(fā)送Setter報(bào)文，實(shí)時(shí)內(nèi)核的氛圍燈控制SWC通過(guò)RTE接口獲取Setter信息，執(zhí)行相應(yīng)邏輯后，SOA API分發(fā)通過(guò)RTE接口獲取SWC的執(zhí)行結(jié)果，并通過(guò)核間通信發(fā)送回性能內(nèi)核，CM收到后，回復(fù)Setter應(yīng)答，最后由SOME/IP協(xié)議?；貜?fù)IDC的Setter請(qǐng)求。

圖10 音樂(lè)氛圍燈服務(wù)調(diào)用過(guò)程日志信息

3.2.2 服務(wù)代理方案響應(yīng)實(shí)時(shí)性分析

為了保證音樂(lè)節(jié)奏和氛圍燈律動(dòng)的匹配，獲得良好的用戶體驗(yàn)，要求中央運(yùn)算單元收到第1幀音樂(lè)數(shù)據(jù)的時(shí)間要比人耳聽(tīng)到音樂(lè)的時(shí)間早，并且中央運(yùn)算單元對(duì)音樂(lè)節(jié)奏變化的響應(yīng)時(shí)間小于或等于人耳對(duì)音樂(lè)節(jié)奏變化的響應(yīng)時(shí)間。因此，需要分析音樂(lè)氛圍燈服務(wù)響應(yīng)的實(shí)時(shí)性。如圖11所示，以性能內(nèi)核接收Setter請(qǐng)求報(bào)文和發(fā)出應(yīng)答報(bào)文 為 起 止 時(shí) 間，調(diào) 用 一 次Service ID：0x10D3，Method ID=6002的時(shí)間為25ms，符合人體對(duì)音視頻同步的感知要求 （音頻相對(duì)視頻超前20ms到延后90ms的范圍內(nèi)，人體對(duì)音視頻同步不敏感）[11]。

圖11 調(diào)用一次音樂(lè)氛圍燈服務(wù)所需時(shí)間

為了驗(yàn)證IDC以短周期頻繁調(diào)用氛圍燈服務(wù)時(shí)的響應(yīng)實(shí) 時(shí) 性，模 擬IDC 在10min 內(nèi) 以50ms 為 周 期 調(diào) 用 服 務(wù)，10min內(nèi)實(shí)際調(diào)用周期及音樂(lè)氛圍燈服務(wù)響應(yīng)時(shí)間如圖12所示。實(shí)際調(diào)用服務(wù)的平均周期為51ms，服務(wù)響應(yīng)的平均時(shí)間為23ms，符合響應(yīng)實(shí)時(shí)性要求[11]。

圖12 10min內(nèi)模擬IDC調(diào)用服務(wù)周期和10min內(nèi)音樂(lè)氛圍燈服務(wù)響應(yīng)時(shí)間

4 總結(jié)

面向服務(wù)架構(gòu) （SOA）被認(rèn)為是能夠支持未來(lái)汽車(chē)軟件發(fā)展的核心技術(shù)之一，汽車(chē)制造商O(píng)EM向SOA架構(gòu)轉(zhuǎn)型，期望汽車(chē)行業(yè)的商業(yè)模式從一次性購(gòu)車(chē)逐步轉(zhuǎn)變?yōu)閷?duì)智能駕駛體驗(yàn)、智能服務(wù)體驗(yàn)、座艙娛樂(lè)體驗(yàn)的持續(xù)升級(jí)迭代消費(fèi)，智能汽車(chē)成為持續(xù)創(chuàng)造價(jià)值的平臺(tái)。本文提出的基于異構(gòu)SOC的中央計(jì)算平臺(tái)服務(wù)部署的方法，突破了異構(gòu)SOC實(shí)施內(nèi)核提供服務(wù)的性能和資源的限制，大大提升了整車(chē)功能服務(wù)化的水平。試驗(yàn)結(jié)果表明按照異構(gòu)SOC服務(wù)部署的方案可實(shí)現(xiàn)音樂(lè)律動(dòng)應(yīng)用的功能，滿足其功能對(duì)代理服務(wù)實(shí)時(shí)性的要求。

參考文獻(xiàn)：

[6]VUJANI M，TRIFUNOVI N，KA TELAN I，et al.Bitroute OME/IP: Implemetation 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.

[7]KENJI D，IVKOV D，ANTI M.Automated data transferromDAS to Android-bed IVI domain over SOME/IP[J].IEEE Transactions on Intelligent Vehicles，2023，8（4）：3166-3177.