隨着物聯網的蓬勃發展，萬物互聯已經不是新概念，滴滴物聯網平臺致力於車聯網及交通相關領域，爲各類場景提供物聯網解決方案及基礎服務。
平臺服務支持包括設備的快速物聯網化、設備管理、數據交通、直播/點播、地圖服務、存儲服務等能力。解決方案諸如車輛監控、運營管理、交通周邊管理、交通運輸安全、數據分析等。
01特性
安全的通訊鏈路
採用分級的安全模式，設備廠商可根據設備計算能力選擇，提供設備鑑權以及鏈路加密方式，保障數據不被篡改。
快速接入
針對設備端提供兩種接入方案加速縮短設備廠商接入平臺週期：
1）提供接入SDK，可根據實際廠商接入情況作爲Demo寫代碼。
2）與支持MQTT協議指令的通訊模組廠商合作，以原生支持物聯網平臺的接入，並通過簡易的AT指令方式提供給廠商調用，省去廠商需要理解通訊協議的麻煩，從而提高接入速度。
穩定性
平臺各個模塊採用全分佈式結構，無單點問題。SLA保障消息99.99%的可用及99.99%服務穩定性。
消息延遲
全鏈路採用無阻塞結構，有消息則立即觸發發送，即消息“即達即推送”。
多服務兼容
無縫對接存儲服務，如Fusion、Redis、Hbase、Hive、HDFS、Flink，後續產品持續開放中。
無縫對接基礎服務，如座標服務、直播/點播服務、AI分析服務，更多服務對接中。
02物聯網是一種什麼場景?
如上圖各種物聯網場景：地下停車場、高山電塔、擁擠的共享單車、共享汽車等等。總結幾個特點：
-
弱聯網
-
大量設備24小時在線
-
實時控制
-
通訊安全
03平臺架構
04平臺基礎能力
維護設備與服務端的長連接，消息收發，保障與設備的安全通道。支持標準的MQTT(同時兼容v3.1和v3.1.1兩個版本)以及JT808協議。
作爲交通運輸的大平臺，我們更注重車聯網的各種接入環境，目前很多車載、汽車、交通等相關設備的硬件產品以JT808協議爲標準與服務端通訊。傳統設備廠商面臨不熟悉車聯網環境，不熟悉MQTT協議，現有的設備又已運行很多年驗證了設備的穩定性，改造成本過大的各種問題，平臺可提供JT808協議兼容存量設備的技術方案。
爲什麼選擇MQTT協議?
1）MQTT基於訂閱/發佈模式，設備端可獨立訂閱一個Topic從而實現單點消息的發送實現點對點，如針對某輛共享汽車進行開鎖。當設備量很多時可按組劃分實現多對點，如同一型號共享汽車或同一批次發送自檢指令可以“批次標識”作爲Topic訂閱，則針對該批次進行發一條消息實現批量控制。
2）MQTT協議流量小。頭部字節以bit位爲單位標記功能，且附加頭信息字段作爲可變頭信息裏，只有需要時纔會佔用字節，以及2個字節的心跳等，協議主觀設計上極大精簡包的大小。
3）MQTT協議天然支持在公網下的弱網環境處理，比如網絡延遲、掉線時的消息質量保障、1.5倍的心跳保活機制等。
消息如何得到保障？
藉助MQTT協議自帶消息質量(QOS)的協議定義，平臺暫支持Qos=0、1兩個等級。
Qos邏輯同時適用於上行/下行消息，Qos=0時也會盡力將消息發送給對方，僅當發送消息時突然掉線纔會丟失，若消息發送之前設備不在線則先存儲起來，設備上線時發送下去。
Qos=1時同樣試用，優先持久化存儲，再發送給設備，等待PubAck包，若超時5秒沒收到則繼續下發，直到收到PubAck報文。
如何保障通訊安全?
安全級別分爲兩級：
1）純TCP鏈接，適用於計算能力較差，數據並非重要的場景，如隱藏式GPS、閥門檢測器等小型產品，本身體積較小、電量較低、功耗低不適於做過多計算。
2）帶TLS鏈接，適用於有一定計算能力的設備，且數據保密性要求高的場景，如共享汽車車控、行車記錄儀等，汽車開鎖、熄火、行車記錄儀錄像傳輸等都是需要強力的安全控制及保密。
平臺支持設備端、服務端雙向鑑權。設備端鑑權服務端採用SSL證書，通過TLS鏈接加密傳輸。服務端鑑權設備端通過設備攜帶username、password校驗。
//password簽名算法
hmacsha1(deviceSecret, “clientId+deviceName+productKey+timestamp”)
平臺會爲每一個設備生成獨立的deviceSecret，通過hmacsha1簽名算法得到密碼。爲保障密碼隨機性，簽名內容包含設備的唯一deviceName以及用戶自定義的唯一clientId，但只對這兩個條件簽名還不夠，因爲簽名的內容爲固定內容總有一天會泄露出去，當泄露後將是一個永久有效的密碼，就像給了別人一張永久的通行證。因此需要再在設備里加一個隨機碼使簽名得到的密碼每次都會變，我們這裏採用時間戳(timestamp)作爲隨機碼，通過該時間戳服務端可以通過時間戳攔截過早時間的密碼，如只允許一天內的有效密碼可以授權通過。
05流媒體服務
物聯網平臺提供基礎的視頻直播/點播能力，結構圖如下：
視頻編碼傳輸裸流到Connsvr並經過推流服務器處理（如需要轉碼則進行轉碼，不需要則透傳），一方面進行實時推流起到直播作用，一方面存儲到存儲服務起到錄製作用。
在該結構中直播流是在播放時才進行轉碼而非寫入時轉碼，因此適用於傳輸量大，但播放量少的場景，例如：有大量設備在給服務端上報音視頻數據，播放端監控調用指定的設備實時畫面，以及查看歷史畫面。
推流服務器可支持RTMP、Http兩種拉流方式。
06配置中心
在許多應用場景中，開發者需要更新設備的配置信息，包括設備的系統參數、網絡參數等等。一般情況下更新設備的配置信息是通過固件升級的方式完成的，但這將加大固件版本的維護成本，並且需要設備中斷運行以完成更新。爲了解決以上問題，物聯網平臺提供了配置中心以解決遠程配置更新的問題，設備無需重啓或中斷運行即可在線完成配置信息的更新。
07OTA
設備固件升級又稱OTA，是物聯網通信服務的重要組成部分。當物聯設備有新功能或者需要修復漏洞時，設備可以通過OTA服務快速的進行固件升級。
在實際的物聯網應用場景中，一般會部署百萬、千萬甚至億級別的物聯網設備。這些設備部署到生產系統後，如何安全管理設備，例如遠程升級設備這些常見操作，會成爲一個難題。物聯網設備往往沒有屏幕，也沒有工作人員在設備前進行手動管理。升級操作如何觸發？升級失敗後如何回滾，並上報升級狀態？這種場景需要提前設計一套OTA管理系統，自動化進行設備管理。通過OTA管理系統，可以監控設備，快速查找設備，排查設備功能故障，遠程更新設備固件，遠程重新啓動、修復以及將設備恢復到出廠設置，大大降低管理大量物聯網設備的成本和工作量。
物模型
車輛越來越普及，越來越多人喜歡在車內安裝各種設備，娛樂的、安全的、車控的、監控的，這些車裝零散安裝在車裏各有各自的功能作用，對於用戶管理是個麻煩的事情，因此平臺抽象出來一個“物模型”概念，目的是把一輛車裏的所有設備抽象成一個“物”，將設備的功能作爲“物”的一項功能或屬性。車載安裝時設備作爲車的一個組件加入到"物模型"裏。如下圖：
通過物模型，管理端只需要指定"物名稱"(例子中的車牌號)進行諸如獲取GPS、油量、電量、行車記錄視頻以及對車的開鎖、關鎖、關車窗控制等。至於在車裏面是什麼設備上報的信息並不需要關心。管理交互如下：
物模型有個特性：當用戶想給設備端發送一個狀態改變消息時，有可能這個設備不在線，下行消息無法下發給設備，此時物模型會記錄狀態等待設備上線下發下去，對於用戶來說只需要知道消息是否送達，以及當前的最新狀態，設備所有的上報的狀態也可通過物模型查詢，即使設備不在線。在弱網環境下這樣有個好處，當查詢設備狀態時，並不需要實質設備在線也可查詢到近期的狀態。
08數據交通(DTS)
DTS作爲網關與後端存儲和基礎服務的數據傳輸中間件，基於DDMQ實現數據配置化的多線路的分發，把同一份數據無縫對接到不同存儲及後端服務支持業務處理。
數據交通支持簡易的數據處理：
1）依據關鍵詞過濾。
2）消息格式化，實現到後端的協議統一或者定製。
3）寫入限速，保護後端負載等。
總結
滴滴物聯網平臺的架構考慮從設備端到接入層再到後端數據+服務一站式打通，結合各個基礎服務能力一起打造車聯、交通領域的方案輸出，爲業務快速的接入以及穩定性的保障打基礎，同時未來在後端連接更多的服務生態，提供豐富的業務形態支持。
轉載來自公衆號“滴滴技術”：https://mp.weixin.qq.com/s/BHdKQWtOuuE9DHEn3_TFwQ