淺析車(chē)云協(xié)同通信系統(tǒng)設(shè)計(jì)方案

【摘" 要】車(chē)云協(xié)同通信是智能網(wǎng)聯(lián)汽車(chē)應(yīng)用的關(guān)鍵技術(shù)。文章提出車(chē)云協(xié)同通信系統(tǒng)方案，以應(yīng)對(duì)多系統(tǒng)環(huán)境下的通信問(wèn)題。分析車(chē)云協(xié)同通信的實(shí)際需求，以及面臨的網(wǎng)絡(luò)特性差異、應(yīng)用協(xié)議差異、連接要求差異等挑戰(zhàn)。提出車(chē)云協(xié)同通信的系統(tǒng)方案，包括協(xié)議轉(zhuǎn)換機(jī)制以確保不同系統(tǒng)間的通信，數(shù)據(jù)處理策略以優(yōu)化信息傳遞效率，策略控制方法以實(shí)現(xiàn)靈活的通信管理，以及信息安全措施以保障數(shù)據(jù)傳輸?shù)陌踩浴?/p>

【關(guān)鍵詞】車(chē)載以太網(wǎng)；面向服務(wù)架構(gòu)；車(chē)云協(xié)同

中圖分類(lèi)號(hào)：U463.6" " 文獻(xiàn)標(biāo)識(shí)碼：A" " 文章編號(hào)：1003-8639（2025）03-0022-03

An Analysis of the Design Scheme for Vehicle-cloud Collaborative Communication Systems

【Abstract】Vehicle-cloud collaborative communication is a key technology for the application of intelligent connected vehicles. This paper proposes a vehicle-cloud collaborative communication system scheme to address communication challenges in a multi-system environment. The practical requirements of vehicle-cloud collaborative communication and the challenges faced，such as differences in network characteristics，application protocol，and connection requirements，are analyzed. The system scheme for vehicle-cloud collaborative communication is proposed，which includes a protocol conversion mechanism to ensure communication between different systems，data processing strategies to optimize information transmission efficiency，policy control methods to achieve flexible communication management，and information security measures to ensure the security of data transmission.

【Key words】in-vehicle ethernet；service-oriented architecture；vehicle-cloud collaboration

0" 前言

車(chē)云協(xié)同通信是行業(yè)研究重點(diǎn)之一。由于車(chē)端與云端在體系架構(gòu)、通信協(xié)議等方面存在較大差異，實(shí)現(xiàn)車(chē)云協(xié)同通信需要解決相關(guān)的技術(shù)問(wèn)題和挑戰(zhàn)。

本文圍繞車(chē)云協(xié)同通信相關(guān)的背景、需求分析及設(shè)計(jì)方案進(jìn)行說(shuō)明，旨在為相關(guān)領(lǐng)域的開(kāi)發(fā)提供參考。

1" 概述

1.1" 車(chē)云協(xié)同

車(chē)云協(xié)同是實(shí)現(xiàn)智能網(wǎng)聯(lián)汽車(chē)、自動(dòng)駕駛和智慧交通的關(guān)鍵技術(shù)。車(chē)云協(xié)同通過(guò)網(wǎng)絡(luò)通信技術(shù)實(shí)現(xiàn)車(chē)輛與云端之間的實(shí)時(shí)數(shù)據(jù)交換和智能服務(wù)交互。車(chē)輛作為數(shù)據(jù)采集和處理終端，將車(chē)輛狀態(tài)、駕駛行為、環(huán)境信息等數(shù)據(jù)上傳至云端進(jìn)行存儲(chǔ)、處理和分析。云端對(duì)車(chē)輛數(shù)據(jù)進(jìn)行處理，提供智能診斷、駕駛輔助、交通管理、遠(yuǎn)程控制等智能服務(wù)，并將分析結(jié)果和決策支持反饋給車(chē)輛。

1.2" SOA架構(gòu)

SOA（Service Oriented Architecture，面向服務(wù)架構(gòu)）是一種軟件設(shè)計(jì)方法，將軟件系統(tǒng)的功能劃分為一系列相互獨(dú)立的服務(wù)，服務(wù)通過(guò)標(biāo)準(zhǔn)化的接口進(jìn)行通信[1]。

SOA強(qiáng)調(diào)服務(wù)的互操作性，即不同系統(tǒng)、不同平臺(tái)的服務(wù)可以通過(guò)一致的接口和協(xié)議進(jìn)行交互，以實(shí)現(xiàn)可重用性和靈活性。

在車(chē)云協(xié)同的背景下，SOA設(shè)計(jì)理念的引入使得車(chē)輛內(nèi)部各模塊和云端服務(wù)之間能夠更高效地進(jìn)行數(shù)據(jù)交換和服務(wù)調(diào)用。

1.3" 車(chē)云協(xié)同通信的挑戰(zhàn)

理想情況下，車(chē)輛與云端可以基于SOA通信中間件進(jìn)行通信，實(shí)現(xiàn)互操作性，見(jiàn)圖1。

然而由于車(chē)內(nèi)網(wǎng)絡(luò)與車(chē)外網(wǎng)絡(luò)特性的不同，在設(shè)計(jì)過(guò)程中需要考慮車(chē)內(nèi)網(wǎng)絡(luò)與車(chē)外網(wǎng)絡(luò)的如下差異[2]。

1）網(wǎng)絡(luò)特性差異。車(chē)外網(wǎng)絡(luò)與車(chē)內(nèi)網(wǎng)絡(luò)在可用性、帶寬、延遲、成本等方面存在顯著差異。

2）應(yīng)用協(xié)議差異。車(chē)內(nèi)網(wǎng)絡(luò)應(yīng)用協(xié)議與車(chē)外網(wǎng)絡(luò)應(yīng)用協(xié)議在通信模式、通信機(jī)制方面有較大不同。車(chē)輛與云端之間的通信多采用HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）、MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸）等通信協(xié)議，而車(chē)輛內(nèi)部的服務(wù)通信多采SOME/IP（Scalable service-Oriented MiddlewarE over IP，基于IP可擴(kuò)展的面向服務(wù)的通信中間件協(xié)議）。

3）連接要求差異。車(chē)輛內(nèi)部通信相對(duì)靜態(tài)，通信節(jié)點(diǎn)在設(shè)計(jì)階段預(yù)設(shè)；而車(chē)輛外部通信更為動(dòng)態(tài)，通信節(jié)點(diǎn)在通信過(guò)程中可靈活配置。此外，車(chē)輛外部網(wǎng)絡(luò)還需特別關(guān)注信息安全問(wèn)題。

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

2.1" 需求分析

考慮車(chē)云協(xié)同通信的復(fù)雜性，本文主要考慮以下幾個(gè)關(guān)鍵的設(shè)計(jì)需求。

1）互操作性：車(chē)輛和云端應(yīng)能基于不同的協(xié)議和語(yǔ)言實(shí)現(xiàn)通信。

2）可擴(kuò)展性：支持動(dòng)態(tài)擴(kuò)展，以滿足新的應(yīng)用及服務(wù)不斷增加的需求。

3）安全性：車(chē)云協(xié)同通信涉及信息傳輸和處理，包括用戶個(gè)人信息、車(chē)輛狀態(tài)信息等，安全問(wèn)題尤為重要，在整體設(shè)計(jì)過(guò)程中需要考慮信息安全。

2.2" 系統(tǒng)方案

典型車(chē)云協(xié)同的系統(tǒng)方案如圖2所示。

圖中SOA服務(wù)網(wǎng)關(guān)模塊是車(chē)內(nèi)實(shí)現(xiàn)車(chē)云協(xié)同通信的核心部件，負(fù)責(zé)與車(chē)內(nèi)其他節(jié)點(diǎn)通信及車(chē)云之間的通信，主要功能模塊包括協(xié)議轉(zhuǎn)換、服務(wù)同步、數(shù)據(jù)處理、策略控制、防火墻等。

2.3" 協(xié)議轉(zhuǎn)換

協(xié)議轉(zhuǎn)換涉及到車(chē)內(nèi)傳統(tǒng)網(wǎng)絡(luò)與基于服務(wù)的以太網(wǎng)通信網(wǎng)絡(luò)的協(xié)議轉(zhuǎn)換、車(chē)內(nèi)通信網(wǎng)絡(luò)與車(chē)外通信網(wǎng)絡(luò)的協(xié)議轉(zhuǎn)換。

2.3.1" 車(chē)內(nèi)傳統(tǒng)網(wǎng)絡(luò)與基于服務(wù)的以太網(wǎng)通信網(wǎng)絡(luò)的協(xié)議轉(zhuǎn)換

車(chē)輛內(nèi)部會(huì)存在傳統(tǒng)網(wǎng)絡(luò)協(xié)議和以太網(wǎng)協(xié)議共存的情況，AUTOSAR定義了S2S（Signal to Service，信號(hào)到服務(wù)轉(zhuǎn)換）模塊的概念[2]。S2S模塊的目的是實(shí)現(xiàn)不同網(wǎng)絡(luò)協(xié)議之間的通信和數(shù)據(jù)交換，通過(guò)解析不同協(xié)議的數(shù)據(jù)包，將信號(hào)數(shù)據(jù)與服務(wù)數(shù)據(jù)進(jìn)行相互轉(zhuǎn)換，涉及數(shù)據(jù)的封裝、解封裝、協(xié)議解析和重新編碼。

S2S模塊的部署有多種方案，可以部署在區(qū)域控制器或中央計(jì)算單元中，圖3為S2S部署的方案示例。將S2S部署在AP（Adaptive AUTOSAR，自適應(yīng)AUTOSAR）平臺(tái)，通過(guò)A核和M核之間的IPCF（Inter-Platform Communication Framework，跨平臺(tái)通信框架）實(shí)現(xiàn)信號(hào)收發(fā)，通過(guò)AP平臺(tái)的SOMEIPD（SOME/IP Daemon，SOME/IP通信守護(hù)進(jìn)程）實(shí)現(xiàn)基于服務(wù)的以太網(wǎng)通信，S2S內(nèi)部實(shí)現(xiàn)了IPCF通道的CAN信號(hào)信息對(duì)服務(wù)的轉(zhuǎn)化和封裝。

基于AP平臺(tái)S2S模塊的開(kāi)發(fā)流程如圖4所示。

1）服務(wù)矩陣設(shè)計(jì)。依據(jù)需要進(jìn)行服務(wù)化的車(chē)輛CAN信號(hào)SOME/IP服務(wù)矩陣設(shè)計(jì)，一般將車(chē)輛狀態(tài)類(lèi)信號(hào)定義為Event（事件）、Notify Field（通知值）或Getter Field（獲取值）類(lèi)型，將車(chē)輛設(shè)置類(lèi)、車(chē)輛控制類(lèi)信號(hào)定義為Method（方法）或Setter Field（設(shè)置值）類(lèi)型。

2）ARXML文件生成。通過(guò)AP相關(guān)設(shè)計(jì)工具將SOME/IP服務(wù)矩陣轉(zhuǎn)換為ARXML（AUTOSAR eXtensible Markup Language，AUTOSAR可擴(kuò)展標(biāo)記語(yǔ)言）文件。

3）接口代碼和配置文件生成。將ARXML文件導(dǎo)入AP代碼生成工具鏈，生成服務(wù)的接口代碼。S2S應(yīng)用會(huì)將CAN信息轉(zhuǎn)換為服務(wù)，即此步驟會(huì)生成全部服務(wù)的Skeleton（骨架）代碼。

4）S2S集成。將對(duì)應(yīng)控制器的IPCF框架代碼、AP工具生成的接口代碼、信號(hào)轉(zhuǎn)換服務(wù)的處理邏輯代碼進(jìn)行集成編譯，完成S2S應(yīng)用的開(kāi)發(fā)。

5）S2S應(yīng)用部署。將編譯好的AP應(yīng)用可執(zhí)行文件、配置文件一起刷寫(xiě)到AP平臺(tái)中，完成S2S應(yīng)用部署。

2.3.2nbsp; 車(chē)內(nèi)通信網(wǎng)絡(luò)與車(chē)外通信網(wǎng)絡(luò)的協(xié)議轉(zhuǎn)換

車(chē)輛與外部實(shí)體的通信連接協(xié)議包括HTTP、MQTT、V2X（Vehicle to Everything，車(chē)聯(lián)網(wǎng)）等。以SOME/IP轉(zhuǎn)換為MQTT協(xié)議為例，協(xié)議轉(zhuǎn)換的方案如下。

1）映射關(guān)系。基于具體應(yīng)用場(chǎng)景和設(shè)計(jì)需求進(jìn)行SOME/IP Service（服務(wù)）與MQTT Topic（主題）的映射。可以采用一對(duì)一映射方案，即一個(gè)SOME/IP服務(wù)接口映射到一個(gè)特定的MQTT Topic。

2）SOME/IP Header（報(bào)頭）部分轉(zhuǎn)換。對(duì)應(yīng)SOME/IP Header部分，轉(zhuǎn)換為MQTT數(shù)據(jù)的策略為：將Service ID（服務(wù)編號(hào)）、Method ID（方法編號(hào)）、Client ID（客戶端編號(hào)）、Session ID（會(huì)話編號(hào)）、Protocol Version（協(xié)議版本）、Interface Version（接口版本）、Message Type（消息類(lèi)型）、Return Code（返回編碼）等內(nèi)容分別封裝為同一個(gè)MQTT消息中的Topic，例如，將Service ID封裝為T(mén)opic：Service_ID。

3）SOME/IP Payload（負(fù)載）部分轉(zhuǎn)換。將SOME/IP Payload數(shù)據(jù)轉(zhuǎn)換為同一個(gè)MQTT消息中的Topic：Payload。

2.4" 服務(wù)同步

服務(wù)同步模塊需要解決獲取、發(fā)布、更新服務(wù)可用狀態(tài)的問(wèn)題。

1）獲取服務(wù)狀態(tài)。SOA服務(wù)網(wǎng)關(guān)通過(guò)SOME/IP SD（Service Discovery，服務(wù)發(fā)現(xiàn)）報(bào)文獲取當(dāng)前車(chē)輛SOME/IP服務(wù)的可用狀態(tài)。

2）發(fā)布服務(wù)狀態(tài)。SOA服務(wù)網(wǎng)關(guān)采用SOME/IP Event接口，將車(chē)內(nèi)SOME/IP服務(wù)的可用狀態(tài)進(jìn)行定時(shí)發(fā)布。

3）更新服務(wù)狀態(tài)。云端應(yīng)用通過(guò)訂閱服務(wù)網(wǎng)關(guān)模塊提供的服務(wù)狀態(tài)同步Event接口，定時(shí)獲得并更新車(chē)內(nèi)SOME/IP服務(wù)的可用狀態(tài)。

2.5" 數(shù)據(jù)處理

數(shù)據(jù)處理模塊對(duì)車(chē)云通信數(shù)據(jù)進(jìn)行采集、緩存、更新和分發(fā)，同時(shí)根據(jù)需求對(duì)采集的數(shù)據(jù)進(jìn)行過(guò)濾、聚合。

1）數(shù)據(jù)緩存。臨時(shí)存儲(chǔ)頻繁訪問(wèn)的數(shù)據(jù)，以減少對(duì)后端系統(tǒng)的訪問(wèn)次數(shù)。數(shù)據(jù)處理模塊可進(jìn)行非實(shí)時(shí)性數(shù)據(jù)的緩存。例如，將云端下發(fā)的“天氣信息”數(shù)據(jù)進(jìn)行緩存，當(dāng)有新的服務(wù)請(qǐng)求時(shí)，將緩存中的數(shù)據(jù)向服務(wù)請(qǐng)求方下發(fā)，減少了車(chē)端向云端請(qǐng)求的數(shù)量和網(wǎng)絡(luò)消耗[3]。

2）數(shù)據(jù)過(guò)濾。數(shù)據(jù)過(guò)濾包括基于時(shí)間的過(guò)濾和基于事件的過(guò)濾。以基于時(shí)間的過(guò)濾為例，由于車(chē)端數(shù)據(jù)、云端數(shù)據(jù)的數(shù)據(jù)周期需求可能不同，可以采用基于時(shí)間的數(shù)據(jù)過(guò)濾機(jī)制。例如車(chē)端數(shù)據(jù)上傳場(chǎng)景，車(chē)內(nèi)車(chē)速信號(hào)的更新周期為10ms，車(chē)速數(shù)據(jù)向云端上傳的周期要求為1s，則可以進(jìn)行基于時(shí)間的過(guò)濾，將車(chē)端向云端發(fā)送的數(shù)據(jù)周期設(shè)置為1s。

2.6" 策略控制

策略控制模塊定義了數(shù)據(jù)交換的規(guī)則和策略，使得數(shù)據(jù)按照既定的策略進(jìn)行傳輸和處理。云端可以動(dòng)態(tài)更新JSON（JavaScript Object Notation，JavaScript對(duì)象表示法）格式的配置文件，實(shí)現(xiàn)對(duì)數(shù)據(jù)控制策略的動(dòng)態(tài)配置。

開(kāi)發(fā)人員可在低代碼開(kāi)發(fā)環(huán)境下，根據(jù)設(shè)計(jì)需求更新配置文件，并將更新后的配置文件下發(fā)到車(chē)端，車(chē)端會(huì)按照新的配置文件進(jìn)行相關(guān)數(shù)據(jù)的過(guò)濾、緩存、上傳，實(shí)現(xiàn)按需數(shù)據(jù)上傳，節(jié)省了數(shù)據(jù)上傳的數(shù)據(jù)量，同時(shí)可以根據(jù)不同的需求動(dòng)態(tài)更新策略。此方案可以應(yīng)用在智能診斷、SOA服務(wù)組合等場(chǎng)景[4]，一種應(yīng)用此架構(gòu)的智能診斷數(shù)據(jù)流示例如圖5所示。

2.7" 防火墻

基于安全考慮，車(chē)內(nèi)外通信需具備防火墻功能，以確保數(shù)據(jù)的安全性和有效性，可采用如下機(jī)制[5]。

1）認(rèn)證機(jī)制。車(chē)內(nèi)通信終端對(duì)來(lái)自云端的服務(wù)請(qǐng)求進(jìn)行身份驗(yàn)證，以確保數(shù)據(jù)源自認(rèn)證的云端應(yīng)用程序，同時(shí)阻止未授權(quán)的外部實(shí)體通過(guò)偽造報(bào)文對(duì)車(chē)輛進(jìn)行操控。

2）訪問(wèn)控制。防火墻通過(guò)訪問(wèn)控制列表，實(shí)現(xiàn)數(shù)據(jù)隔離和過(guò)濾，可采用MAC（Media Access Control，媒體訪問(wèn)控制）地址過(guò)濾、IP（Internet Protocol，互聯(lián)網(wǎng)協(xié)議）地址過(guò)濾、傳輸層端口號(hào)過(guò)濾的方式，確保只與授權(quán)的設(shè)備或程序進(jìn)行通信。

3）流量控制。實(shí)時(shí)對(duì)流量進(jìn)行監(jiān)控，當(dāng)檢測(cè)到服務(wù)請(qǐng)求的流量超過(guò)限值時(shí)，采取相關(guān)措施，例如自動(dòng)拒絕超出部分的請(qǐng)求，以避免過(guò)量的流量信息對(duì)云端與車(chē)端通信造成干擾。

3" 結(jié)語(yǔ)

本文在考慮車(chē)云協(xié)同通信協(xié)議轉(zhuǎn)換、互操作性、信息安全等需求的基礎(chǔ)上，提出了車(chē)云協(xié)同通信的設(shè)計(jì)方案，并對(duì)重點(diǎn)模塊的方案進(jìn)行了說(shuō)明。

針對(duì)車(chē)云通信的需求，相關(guān)標(biāo)準(zhǔn)組織也在推進(jìn)。AUTOSAR引入Vehicle API（車(chē)輛接口），致力于整合整車(chē)層面的標(biāo)準(zhǔn)化軟件接口；COVESA（Connected Vehicle Systems Alliance，互聯(lián)車(chē)輛系統(tǒng)聯(lián)盟）提出VISS（Vehicle Information Service Specification，車(chē)輛信息服務(wù)規(guī)范）、W3C（World Wide Web Consortium，萬(wàn)維網(wǎng)聯(lián)盟）提出VSS（Vehicle Signal Specification，車(chē)輛信號(hào)規(guī)范），提供了標(biāo)準(zhǔn)化的定義車(chē)輛信號(hào)的語(yǔ)法和目錄，為實(shí)現(xiàn)車(chē)云通信互操作性提供了基礎(chǔ)[6]。

未來(lái)，隨著標(biāo)準(zhǔn)的逐步完善及應(yīng)用的逐步推廣，車(chē)云協(xié)同通信將在智能網(wǎng)聯(lián)汽車(chē)、智能交通等領(lǐng)域發(fā)揮更大作用。

參考文獻(xiàn)

[1] 李丹，呂穎，李駿，等.面向服務(wù)的體系架構(gòu)[J].汽車(chē)文摘，2021（10）：52-57.

[2] R23-11/CP/AUTOSAR_CP_TPS_SystemTemplate.pdf[Z].

[3] SIM W，LEE S J. End-to-End Connectivity Design with Automotive Ethernet amp; Service- Oriented Architecture[C]//2018 IEEE-SA Ethernet amp; IP @ Automotive Technology Day. London：IEEE，2018.

[4] 辜云，劉欽，張小波，等.面向服務(wù)的車(chē)云一體架構(gòu)方案[J].汽車(chē)電器，2023（12）：38-40.

[5] Rumez M，Grimm D，Kriesten R，et al.An Overview of Automotive Service-Oriented Architectures and Implications for Security Countermeasures[J].IEEE Access，2020（8）：221852.

[6] M. Helmy and A. Mohsen.Vehicle-to-Cloud System New Architecture based on Adaptive AUTOSAR，VSS，and VISS[C]//2023 International Conference on Computer and Applications（ICCA），2023.