隨著智能汽車的發(fā)展，車云通信的功能場景及數(shù)據(jù)量也逐漸增多，具有輕量化、可靠性等特點的MQTT協(xié)議成為很多OEM車云通信協(xié)議的選擇。本文主要介紹。

什么是MQTT？

MQTT（Message Queuing Telemetry Transport）是由OASIS發(fā)布的應用層協(xié)議，采用訂閱/發(fā)布的通信模式，下層基于TCP/IP進行傳輸。該標準在工業(yè)物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等領域有廣泛應用。

MQTT主要有以下特點：

發(fā)布/訂閱模式：實現(xiàn)Client之間的解耦

輕量：非常小的通信開銷，最小的消息大小為2字節(jié)

可靠：基于TCP可靠通信，并可以提供三種消息發(fā)布服務質(zhì)量等級QoS，以適應不穩(wěn)定網(wǎng)絡的傳輸需求

開源：存在較多開源代碼工程，支持各種流行編程語言，成熟度高

MQTT在通信過程中包括兩種角色Client和Broker：

Client：MQTT客戶端，交互應用數(shù)據(jù)的節(jié)點，發(fā)布數(shù)據(jù)的角色為Publisher，接收數(shù)據(jù)的角色為Subscriber

Broker：MQTT服務器，中轉通信數(shù)據(jù)，將從Publisher收到的應用數(shù)據(jù)轉發(fā)給Subscriber

MQTT的通信過程：Subscriber向Broker以Topic的形式訂閱數(shù)據(jù)，Publisher以Topic的形式向Broker發(fā)布應用數(shù)據(jù)，Broker接收Publisher發(fā)送的Topic后，再發(fā)送給已訂閱相關Topic的Subscriber，如此實現(xiàn)Publisher和Subscriber的通信過程。

圖1 MQTT通信示意圖

MQTT系統(tǒng)設計

MQTT協(xié)議在車載通信領域的典型應用場景是車云通信，因此本文以車內(nèi)節(jié)點與云端的通信場景為示例，介紹MQTT系統(tǒng)設計的主要流程和方法。

圖2 MQTT系統(tǒng)設計流程

MQTT系統(tǒng)設計需要依賴前期完成的車云UC（Use Case）描述、通信矩陣、車內(nèi)拓撲以及云端架構部署等作為輸入，針對MQTT的特點，完成通信設計，主要輸出產(chǎn)物為基于特定車型或平臺的MQTT通信矩陣。車端和云端的開發(fā)工程師需要根據(jù)設計輸出產(chǎn)物，完成相關功能的軟件開發(fā)，測試工程師也需要以設計輸出為基礎，開展MQTT測試驗證工作。

MQTT通信系統(tǒng)設計涉及以下方面：

MQTT角色設計：基于功能需求為通信節(jié)點部署角色

Topic設計：明確Topic定義和數(shù)量

數(shù)據(jù)類型設計：為每個Topic指定傳輸信息

QoS設計：為Topic匹配QoS策略

MQTT角色定義

基于MQTT協(xié)議的特點，需要首先明確車云通信拓撲中各節(jié)點的MQTT角色。

由于各節(jié)點間需要交互的數(shù)據(jù)均需要經(jīng)過Broker，因此一般將性能較好的云端的服務器部署為Broker，車內(nèi)需要與云端通信的節(jié)點為Client，云端后臺/APP等節(jié)點為Client。

圖3 MQTT角色部署

Topic設計

MQTT系統(tǒng)內(nèi)各節(jié)點用Topic來交互應用數(shù)據(jù)，Topic的劃分可以從數(shù)據(jù)內(nèi)容或者功能角度劃分，例如車況上傳的數(shù)據(jù)在一個Topic，遠程車輛控制的數(shù)據(jù)在一個Topic。

除此之外，MQTT的Topic名稱設計也應遵循一定的原則，例如：命名長度不應超過65535 Bytes，建議采用統(tǒng)一的命名規(guī)則，并且按照分級符“/”進行層級劃分。例如針對某平臺的車況上傳數(shù)據(jù)，其Topic可設計為：{vehicle_platform}/{vehicle_model}/{ECU}/vehicle_info/{vin}/up 。

數(shù)據(jù)類型設計

MQTT協(xié)議單幀報文支持的最大傳輸數(shù)據(jù)為256M Bytes，因此一次性傳輸需求超過該大小的數(shù)據(jù)不適合采用MQTT進行傳輸。

MQTT數(shù)據(jù)格式?jīng)]有嚴格定義，只要收發(fā)雙方采用統(tǒng)一的編碼/解碼規(guī)則即可，常采用JSON數(shù)據(jù)格式，需要傳輸?shù)膽脭?shù)據(jù)信息，用“key-value”進行描述，key的定義以及value的數(shù)據(jù)類型需要參考車內(nèi)的通信矩陣，可以保持一致。

使用JSON格式的好處是只要求數(shù)據(jù)收發(fā)雙方對同一個key的理解是一致的，對“key-value”組合的排布順序無嚴格要求，如果有擴展需求，可以直接添加“key-value”組合定義，并且“key-value”組合是可選的，按照時間/事件情況選擇發(fā)送/不發(fā)生即可，無需額外制定協(xié)議層策略，兼容性和靈活性較高。

圖4 Topic數(shù)據(jù)定義

QoS設計

MQTT具備QoS策略以保證不同情況下的通信服務質(zhì)量，因此需要根據(jù)功能場景需求為不同的數(shù)據(jù)Topic設計匹配的QoS策略，整體原則如下：

對于實時性要求較高，且允許一定程度丟幀的場景，QoS推薦設計為0，例如用于實時顯示用的周期上傳的數(shù)據(jù)

對于不允許丟幀、可重復傳輸?shù)膱鼍?，QoS推薦為1，例如反饋云端下發(fā)指令是否正常接收的信號

對于具有嚴格傳輸需求（不允許丟幀、不允許重復傳輸）的場景，QoS推薦為2，例如安全相關的數(shù)據(jù)

總結

本文首先介紹了MQTT協(xié)議，再從MQTT角色設計、Topic設計、數(shù)據(jù)類型設計、QoS設計幾個方面出發(fā)，介紹MQTT系統(tǒng)設計流程和方法，車端ECU及云端的開發(fā)工程師需要根據(jù)MQTT系統(tǒng)設計的輸出完成后續(xù)軟件開發(fā)，實現(xiàn)車云功能的通信。

經(jīng)緯恒潤作為OPEN聯(lián)盟會員和AUTOSAR聯(lián)盟的高級合作伙伴，長期為國內(nèi)外各大OEM和供應商提供涵蓋TCP/IP、SOME/IP、DoIP、AVB、TSN、DDS等技術領域的設計和測試咨詢服務，積極研發(fā)和探索車載網(wǎng)絡前沿技術的工程應用。通過多個項目的實踐經(jīng)驗，已建立了高質(zhì)量、本土化的設計與測試一體化解決方案，為整車網(wǎng)絡架構提供可靠支持。