隨著車聯網的快速發展，其應用場景也越來越豐富。除了在車輛行駛中進行相關資料傳輸上報，在車輛熄火狀態下也可實現遠端控車（遠端啟動、開啟空調與開後備箱等）、OTA 升級等場景需求。為了給車主提供低時延、高成功率的使用體驗，需要通過車聯網平臺與車機的心跳保活機制，保持長連線狀態，並在車輛熄火的情況下快速遠端喚醒車機，實現遠端控車。
本篇文章將介紹車聯網平臺中 MQTT 的心跳保活和遠端喚醒設計。
MQTT 車聯網通訊訊息保活
構建大型車聯網平臺時，為了實現車機與平臺的高效實時通訊，我們通常採用長連線方式通訊（如 MQTT、HTTP、私有化 TCP 長連線等），本文主要圍繞 MQTT 協議長連線通訊與遠端車控喚醒場景進行詳細介紹。
業務場景
MQTT 本身也是採用 TCP 長連線的方式進行通訊保活，TCP 長連線是指通過傳輸層三層握手建立的連線並長期保持，這樣在應用層做訊息傳遞請求的時候免去了 DNS 解析、連線建議等時間，大大加快了請求的速率，有利於訊息的實時性。但同時我們需要端對端連線的維護和連線的保活。
MQTT 是標準的 RFC 協議，相比私有協議更加標準。同時 MQTT 協議面向物聯網場景設計，具有如下功能優勢：
- 完善的心跳機制
- 支援遺囑訊息
- QoS 質量等級+離線訊息
- 基於訂閱釋出的非同步機制
- 低功耗，可以實現長連線低功耗保活和遠端快速喚醒
- 採用 Topic 主題、支援安全擴充套件
使用 MQTT 協議建立車機與 TSP 等平臺的長連線通訊，可以有效解決物件唯一性與實時性等問題。其所具備的完善功能特性支援，適用於快速構建車聯網業務，因此廣泛應用於車聯網 TSP 平臺車控資料上報、遠端控車、道路救援、高精地圖、ADAS 和 C-V2X 等場景。
MQTT 訊息心跳保活
MQTT Keep Alive 心跳機制
MQTT 協議設計了一套 Keep Alive 心跳機制。車機在與 Broker 建立連線的時候，我們可以傳遞一個 Keep Alive 引數，它的單位為秒。MQTT 協議中約定：在 1.5 倍 Keep Alive 的時間間隔內，如果 Broker 沒有收到來自車機端的任何資料包，那麼 Broker 認為它和車機端之間的連線已經斷開；同樣地，如果車機端沒有收到來自 Broker 的任何資料包，那麼車機端認為它和 Broker 之間的連線已經斷開。
MQTT 還有一對 PINGREQ/PINGRESP 資料包，當 Broker 和車機端之間沒有任何資料包傳輸的時候，可以通過 PINGREQ/PINGRESP 來滿足 Keep Alive 心跳通訊和連線狀態檢測。
PINGREQ
PINGREQ 資料包沒有可變頭（Variable header）和訊息體（Payload），當 Client（車機端）在一個 Keep Alive 時間間隔內沒有向 Broker 傳送任何資料包，比如 Publish 和 Subscribe 的時候，它應該向 Broker 傳送 PINGREQ 資料包。
PINGRESP
PINGRESP 資料包沒有可變頭（Variable header）和訊息體（Payload），當 Broker 收到來自 Client 的 PINGREQ 資料包，它應該回復 Client 一個 PINGRESP 資料包。
對於 MQTT Keep Alive 機制，我們還需要注意以下幾點：
- 如果在一個 Keep Alive 時間間隔內，車機端和 Broker 有過資料包傳輸，比如 Publish，車機端就沒有必要再使用 PINGREQ 了，在網路資源比較緊張的情況下這點很重要；
- Keep Alive 值是由 Client 指定的，不同的 Client 可以指定不同的值，我們可以根據車機硬體和業務特性使用不同的 Keep Alive 值；
- Keep Alive 的最大值為 18 小時 12 分 15 秒（65535 秒），預設一般為 60s，我們可以根據車機的效能選擇 10s、30s、60s 等值；
- Keep Alive 如果設為 0，則代表不使用 Keep Alive 機制。
MQTT 心跳保活車聯網場景設計
通訊保活
例如，假設我們選擇了 30s 作為 Keep Alive 的心跳週期，我們在車機端建立與 Broker 連線的時候傳送 Keep Alive 值為 30s。
Broker 判斷車機離線：
在 1.5 倍 Keep Alive 的時間間隔即 45s 內，如果 Broker 沒有收到來自車機端的任何資料包（包括PINGREQ），那麼 Broker 認為它和車機端之間的連線已經斷開，這個時候 Broker 就會把車機端狀態離線，如果客戶端有遺囑訊息，Broker 就向某個主題 Publish 這個遺囑訊息。
車機判斷與 Broker 斷開連線：
同理，在 Keep Alive 週期內，如果車機端沒有收到來自 Broker 的任何資料包（包括 PINGRESP），那麼車機端認為它和 Broker 之間的連線已經斷開，這個時候車機端可以設定重連機制，重新連線上 Broker。
當車輛熄火後，在一定週期內為了實現快速的遠端控車響應，車機端的 T-Box 會自動進入低功耗的休眠模式，這時 T-Box 主控模組關閉，只保留通訊模組工作（低功耗模式，一般在微安級），採用定時喚醒的方式給 Broker 傳送心跳報文以保持長連線 Socket 通道。
遠端喚醒
之前為了實現車輛離線狀態下遠端控車場景，平臺通常採用簡訊或電話振鈴的方式對車機端 T-Box 進行遠端喚醒。這種傳統方式存在以下弊端：
- 時延大且成功率不高：通過簡訊方式往往會有運營商簡訊延時，T-Box 喚醒後往往需要一定的時間啟動，這個時候遠端控車的訊息有可能因為 T-box 未啟動完成導致執行失敗。
- 運營成本較高：假如業務場景 1sms/車/天，100 萬車機的系統簡訊產生的費用成本將會很高。
所以現在主機廠大多結合越來越成熟的 T-Box 終端採用 4G/5G 網路通訊（MQTT訊息）喚醒方式，通過低功耗的保活訊息實現車機長連線（有些主機厂部分車型還採用雙連線），當平臺有車控訊息下發時，車機端 T-Box 收到訊息後迅速喚醒對應的 ECU 執行對應的車控指令，有效縮短了遠端控車的訊息時延，提升車主的使用感知，同時大大降低主機廠的運營成本。
基於 EMQX 的心跳保活系統架構
系統架構
我們已在本系列之前的文章中介紹了如何基於 EMQX 構建千萬級的車聯網平臺架構。EMQX 支援 MQTT 3.1、3.1.1、5.0 全協議棧，基於 EMQX 構建的訊息 Broker 叢集可以完美實現 Keep Alive 心跳、遺囑訊息、保留訊息等 MQTT 協議特性，支撐車聯網平臺的長連線保活和遠端喚醒場景。
EMQX 能力擴充套件
除了基本的心跳保活和遠端喚醒場景支援外，根據車聯網場景下的實際業務需求，EMQX 還增加了如下擴充套件功能，幫助車聯網使用者構建更加適應各類場景的平臺應用。
增加心跳超時確認機制
考慮到車聯網場景車輛經常處於地下車庫、隧道等網路不穩定的環境中，EMQX 增加了心跳超時確認機制，（可配置啟用）在標準的 1.5 倍的 Keep Alive 週期之上再增加 1 倍的心跳時間，即在 2.5 個 Keep Alive 週期沒收到心跳報文才會認為車機端因網路中斷斷開連線，可以優化在弱網場景客戶端頻繁上下線的問題。
心跳週期 Keep Alive 值支援 API 遠端設定
例如在某知名主機廠的車聯網場景中，為了更好地控制電瓶饋電情況，當車主在熄火後，平臺可以通過 EMQX 的離線訊息功能感知車輛離線，這時 T-Box 自動進入休眠模式，並且 Keep Alive 時間間隔從 30s 自動設定為 300s。但由於 Broker 與車機建立連線時 Keep Alive 設定的是 30s，所以需要平臺通知 Broker 同步將 Keep Alive 值修改為 300s。
EMQX 通過定製化能力擴充套件方式，提供標準化的 REST API 原子能力，TSP 在獲取車機熄火的事件後第一時間呼叫 EMQX 提供的原子能力，將 Broker 與該車機的 Keep Alive 心跳週期設定為 300s，確保車機端 T-Box 進行低功耗休眠場景依然能夠實現長連線保活。
結語
基於 MQTT 協議完善的長連線保活通訊機制和 EMQX 強大的產品能力，車聯網平臺開發者可以快速構建高可用、低時延的車聯網應用平臺。隨著 T-Box 的不斷完善，通過雙 APN 通訊鏈路、提前喚醒（車主 APP 進入控車模式時提前喚醒 T-Box）或基於車機控車行為大資料分析更高效的饋電控制等方式，車企可以為廣大車主提供更加優質的車聯網業務體驗。
版權宣告： 本文為 EMQ 原創，轉載請註明出處。
原文連結：https://www.emqx.com/zh/blog/mqtt-keep-alive-design-in-the-internet-of-vehicles