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

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

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

中圖分類號：U463.6" " 文獻標識碼：A" " 文章編號：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" 前言

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

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

1" 概述

1.1" 車云協(xié)同

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

1.2" SOA架構(gòu)

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

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

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

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

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

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

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

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

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

2" 設(shè)計方案

2.1" 需求分析

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

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

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

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

2.2" 系統(tǒng)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）映射關(guān)系?；诰唧w應(yīng)用場景和設(shè)計需求進行SOME/IP Service（服務(wù)）與MQTT Topic（主題）的映射?？梢圆捎靡粚σ挥成浞桨?，即一個SOME/IP服務(wù)接口映射到一個特定的MQTT Topic。

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

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

2.4" 服務(wù)同步

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

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

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

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

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

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

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

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

2.6" 策略控制

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

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

2.7" 防火墻

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

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

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

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

3" 結(jié)語

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

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

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

參考文獻

[1] 李丹，呂穎，李駿，等.面向服務(wù)的體系架構(gòu)[J].汽車文摘，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ù)的車云一體架構(gòu)方案[J].汽車電器，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.