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

什么是MQTT？

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

MQTT主要有以下特點(diǎn)：

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

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

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

開(kāi)源：存在較多開(kāi)源代碼工程，支持各種流行編程語(yǔ)言，成熟度高

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

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

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

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

圖1 MQTT通信示意圖

MQTT系統(tǒng)設(shè)計(jì)

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

圖2 MQTT系統(tǒng)設(shè)計(jì)流程

MQTT系統(tǒng)設(shè)計(jì)需要依賴前期完成的車云UC（Use Case）描述、通信矩陣、車內(nèi)拓?fù)湟约霸贫思軜?gòu)部署等作為輸入，針對(duì)MQTT的特點(diǎn)，完成通信設(shè)計(jì)，主要輸出產(chǎn)物為基于特定車型或平臺(tái)的MQTT通信矩陣。車端和云端的開(kāi)發(fā)工程師需要根據(jù)設(shè)計(jì)輸出產(chǎn)物，完成相關(guān)功能的軟件開(kāi)發(fā)，測(cè)試工程師也需要以設(shè)計(jì)輸出為基礎(chǔ)，開(kāi)展MQTT測(cè)試驗(yàn)證工作。

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

MQTT角色設(shè)計(jì)：基于功能需求為通信節(jié)點(diǎn)部署角色

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

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

QoS設(shè)計(jì)：為T(mén)opic匹配QoS策略

MQTT角色定義

基于MQTT協(xié)議的特點(diǎn)，需要首先明確車云通信拓?fù)渲懈鞴?jié)點(diǎn)的MQTT角色。

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

圖3 MQTT角色部署

Topic設(shè)計(jì)

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

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

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

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

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

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

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

QoS設(shè)計(jì)

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

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

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

對(duì)于具有嚴(yán)格傳輸需求（不允許丟幀、不允許重復(fù)傳輸）的場(chǎng)景，QoS推薦為2，例如安全相關(guān)的數(shù)據(jù)

總結(jié)

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

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