【摘" 要】車云協(xié)同通信是智能網(wǎng)聯(lián)汽車應用的關(guān)鍵技術(shù)。文章提出車云協(xié)同通信系統(tǒng)方案，以應對多系統(tǒng)環(huán)境下的通信問題。分析車云協(xié)同通信的實際需求，以及面臨的網(wǎ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)；面向服務架構(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)的背景、需求分析及設計方案進行說明，旨在為相關(guān)領(lǐng)域的開發(fā)提供參考。

1" 概述

1.1" 車云協(xié)同

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

1.2" SOA架構(gòu)

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

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

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

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

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

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

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

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

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

2" 設計方案

2.1" 需求分析

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

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

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

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

2.2" 系統(tǒng)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2nbsp; 車內(nèi)通信網(wǎng)絡與車外通信網(wǎng)絡的協(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應用場景和設計需求進行SOME/IP Service（服務）與MQTT Topic（主題）的映射。可以采用一對一映射方案，即一個SOME/IP服務接口映射到一個特定的MQTT Topic。

2）SOME/IP Header（報頭）部分轉(zhuǎn)換。對應SOME/IP Header部分，轉(zhuǎn)換為MQTT數(shù)據(jù)的策略為：將Service ID（服務編號）、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" 服務同步

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

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

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

3）更新服務狀態(tài)。云端應用通過訂閱服務網(wǎng)關(guān)模塊提供的服務狀態(tài)同步Event接口，定時獲得并更新車內(nèi)SOME/IP服務的可用狀態(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ù)進行緩存，當有新的服務請求時，將緩存中的數(shù)據(jù)向服務請求方下發(fā)，減少了車端向云端請求的數(shù)量和網(wǎng)絡消耗[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ù)周期設置為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ù)設計需求更新配置文件，并將更新后的配置文件下發(fā)到車端，車端會按照新的配置文件進行相關(guān)數(shù)據(jù)的過濾、緩存、上傳，實現(xiàn)按需數(shù)據(jù)上傳，節(jié)省了數(shù)據(jù)上傳的數(shù)據(jù)量，同時可以根據(jù)不同的需求動態(tài)更新策略。此方案可以應用在智能診斷、SOA服務組合等場景[4]，一種應用此架構(gòu)的智能診斷數(shù)據(jù)流示例如圖5所示。

2.7" 防火墻

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

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

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

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

3" 結(jié)語

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

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

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

參考文獻

[1] 李丹，呂穎，李駿，等.面向服務的體系架構(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] 辜云，劉欽，張小波，等.面向服務的車云一體架構(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.