名詞解釋

一、概述

1. 背景

在IoT行業(yè)中整體解決方案包括很多方向。不同業(yè)務(wù)的公司提供不同方向的解決方案。現(xiàn)階段公司提供的解決方案方向?yàn)闃?biāo)準(zhǔn)化、定制化硬件內(nèi)容。故為了提高公司在行業(yè)內(nèi)的競爭力，需要可以為客戶提供一體化的解決方案建設(shè)設(shè)備管理系統(tǒng)。方便以后客戶進(jìn)行設(shè)備管理的工作。

解決了客戶的基本需求之后，為了提高公司以及IoT行業(yè)的整體運(yùn)營水平。可以為IoT行業(yè)提供通用的設(shè)備管理平臺，并在設(shè)備管理平臺的基礎(chǔ)上構(gòu)建特定業(yè)務(wù)的能力。為IoT業(yè)界建立底層的基礎(chǔ)設(shè)施，并幫助企業(yè)進(jìn)入IoT快速發(fā)展階段。

作為一個開放的IoT平臺，需要可以幫助第三方設(shè)備的接入能力。為第三方設(shè)備提供管理，業(yè)務(wù)支撐的功能。所以，需要將IoT云平臺的協(xié)議部分定義完成并提供給第三方。

2. 目標(biāo)

為設(shè)備管理平臺提供統(tǒng)一的對接協(xié)議，并制定協(xié)議設(shè)計中的規(guī)則。以方便開發(fā)人員、測試人員、第三方廠商進(jìn)行相關(guān)的實(shí)現(xiàn)工作。

3. 讀者范圍

研發(fā)人員，測試人員。

二、概要設(shè)計

IoT協(xié)議是云平臺上管理設(shè)備的基礎(chǔ)部分。在IoT平臺上負(fù)責(zé)設(shè)備端與云服務(wù)端的通信，并可以通過協(xié)議進(jìn)行設(shè)備的認(rèn)證，鑒權(quán)，控制等等功能。

圖片.png

上圖中箭頭指向的內(nèi)容即是本協(xié)議使用的地方。具體協(xié)議使用地方為：

• 設(shè)備與邊緣計算之間；
• 設(shè)備與LBS服務(wù)器之間；
• 邊緣計算與LBS服務(wù)器之間；
• 設(shè)備與LBS服務(wù)器間。

IoT平臺協(xié)議會涉及到多個方面的內(nèi)容。其中包括：協(xié)議需要處理的業(yè)務(wù)、協(xié)議的流程、協(xié)議支持的負(fù)載均衡方式、協(xié)議通信周期、協(xié)議體規(guī)范、協(xié)議的異常處理、協(xié)議的安全性等。以下具體說明這里的項(xiàng)的具體內(nèi)容。

1. 設(shè)備狀態(tài)機(jī)

設(shè)備端與服務(wù)端的狀態(tài)有完整的機(jī)制去保證。具體狀態(tài)機(jī)為：

圖片.png

狀態(tài)機(jī)說明設(shè)備的狀態(tài)以及狀態(tài)切換規(guī)則，便于之后在服務(wù)端進(jìn)行展示。設(shè)備狀態(tài)切換如圖上所示，圖中箭頭說明狀態(tài)切換的方向。單向箭頭說明只能切換到箭頭指向的狀態(tài)，不能切換回來。雙向箭頭都是在兩個狀態(tài)之間切換。

這里的升級態(tài)沒有區(qū)分版本下載和升級版本這兩個階段，所以在升級過程中是不允許接收命令的操作。升級和命令指令操作是排他關(guān)系。

2. 協(xié)議完成的業(yè)務(wù)

IoT平臺上協(xié)議需要完成的業(yè)務(wù)有：設(shè)備上線、設(shè)備下線、配置下發(fā)、設(shè)備狀態(tài)上報、命令下發(fā)、設(shè)備心跳、設(shè)備升級。這些業(yè)務(wù)中需要考慮的內(nèi)容有很多需要考慮系統(tǒng)的安全性，可靠性，在章節(jié)中會詳細(xì)介紹其中內(nèi)容。

3. 信令規(guī)范

信令是組成協(xié)議的原子單元，信令的流程以及處理策略形成完成的協(xié)議。每條信令可以由設(shè)備端或者服務(wù)端發(fā)送，然后由對端接收。每條信令都只有兩端，但在整體的設(shè)計中會包括四個終端：設(shè)備端，邊緣計算端，LBS服務(wù)端，云端。在這四個終端上的通信，只能在上面所說明的幾個終端間通信。不允許其他的終端間通訊。

在本節(jié)中定義通用的協(xié)議內(nèi)容，具體如下：

• 通信協(xié)議
  基礎(chǔ)通信協(xié)議使用在TCP/IP之上的MQTT，并在MQTT的基礎(chǔ)上使用MQTT的SSL進(jìn)行安全通信的支持。在MQTT協(xié)議的支持下，使用TLV（二進(jìn)制流）的方式進(jìn)行上層業(yè)務(wù)的通信。
  通信過程如上圖所示，通過MQTT的Broker作為中間的消息交換，將消息發(fā)送到所有設(shè)備或者部分設(shè)備。整體MQTT使用訂閱發(fā)布者模式進(jìn)行消息通信，與Http的請求響應(yīng)方式不同。所以，使用MQTT過程中可以主動向設(shè)備端推送消息，不需要必須等待某一次請求之后再做響應(yīng)。
  
  圖片.png

針對MQTT協(xié)議的特性，需要對設(shè)備端與服務(wù)端使用MQTT的方式進(jìn)行定義。MQTT協(xié)議需要使用Topic進(jìn)行消息的發(fā)送與接收操作。故這里定義云服務(wù)平臺上使用到的Topic以及使用方式：

MQTT的使用方式定義如下：
1. 訂閱者使用MQTT的Topic訂閱的方式進(jìn)行消息接收。
2. 發(fā)送者需要將消息發(fā)送到特定的Topic中。Topic的定義如上圖所示。
3. 訂閱者在收到消息之后，必須發(fā)送消息確認(rèn)。可以攜帶消息已收到，處理已成功等內(nèi)容作為響應(yīng)。
4. 消息的發(fā)送和接收應(yīng)該盡量的不帶無關(guān)字段，保證業(yè)務(wù)的同時，降低流量。

• 協(xié)議頭定義
  在通信協(xié)議中已經(jīng)定義協(xié)議使用MQTT協(xié)議作為承載協(xié)議，使用TLV（二進(jìn)制流）的方式作為應(yīng)用層處理業(yè)務(wù)的協(xié)議。并在消息接受和發(fā)送過程中不允許使用ASCII編碼之外的字符進(jìn)行通信。
  協(xié)議頭規(guī)定協(xié)議通信過程中所必須攜帶的內(nèi)容。這些內(nèi)容用于在通信過程中判定最基本的信息。具體協(xié)議頭的定義使用整體規(guī)劃的TLV方式。下面定義協(xié)議頭：

消息頭中的有具體的使用的長度為6個字節(jié)。這些字節(jié)都是使用網(wǎng)絡(luò)字節(jié)序進(jìn)行網(wǎng)絡(luò)傳輸?shù)摹＞唧w的字節(jié)流方式為：

圖片.png

• 協(xié)議體定義
  協(xié)議體的內(nèi)容由每個消息具體定義。消息體中也是使用TLV的方式進(jìn)行編解碼，然后在設(shè)備端與云服務(wù)端都需要編解碼操作。所以，需要實(shí)現(xiàn)一套Java版的協(xié)議編解碼包然后提供給設(shè)備端和云服務(wù)端使用，使用jar包版本控制協(xié)議版本。

4. 協(xié)議通信周期

在協(xié)議通信過程中，消息的上報與下發(fā)都需要遵循某種周期。這些周期定義通信過程中的各種事件的發(fā)生頻率、以及異常的處理情況。在通信過程中可能會遇到各種各樣的周期，IoT云平臺上使用周期的方式基本上可以定義為以下兩種：

• 設(shè)備上存儲的固定周期配置；
• 服務(wù)端下發(fā)的周期配置；

使用這些周期的優(yōu)先級為服務(wù)端下發(fā)的配置優(yōu)先級最高，其次是設(shè)備端上的配置。在上線過程中會伴隨著配置下發(fā)，如果配置沒有下發(fā)或者下發(fā)錯誤。可以使用設(shè)備上本地存儲的配置進(jìn)行。

這里定義設(shè)備上的默認(rèn)事件周期：

5. 協(xié)議流程

協(xié)議流程主要用來描述設(shè)備和服務(wù)在交互過程中的交互流程。即在怎樣的上下文上等待還是發(fā)送怎樣的消息。

這里定義的協(xié)議都是有兩端和多端的情況。Peer-To-Peer是進(jìn)行兩個設(shè)備間的通信。多端的是進(jìn)行廣播消息。一般情況下認(rèn)為服務(wù)端為一個端，因?yàn)樵诜?wù)端需要處理大量請求時使用的多節(jié)點(diǎn)是用來做負(fù)載的。而設(shè)備端定義每一個設(shè)備為一端，因?yàn)槊恳粋€設(shè)備上的情況都是不一致的，操作過程中需要對每一個設(shè)備進(jìn)行管理。

從整體上規(guī)劃的內(nèi)容是設(shè)備端都是單個服務(wù)端發(fā)送消息。服務(wù)端可能向一個設(shè)備，一組設(shè)備，全部設(shè)備發(fā)送消息。具體的消息發(fā)送由業(yè)務(wù)確定，但整體上一條消息發(fā)送必須由另外一條消息確認(rèn)。

消息流程可以由設(shè)備端和服務(wù)端功能協(xié)商出具體的流程，主要為了滿足業(yè)務(wù)即可。在之后的章節(jié)中每個協(xié)議定義都會有流程說明。

6. 負(fù)載均衡

云平臺的地域分布相對來說比較廣泛，設(shè)備數(shù)相對來說也是比較多的。所以，在規(guī)劃和設(shè)計過程中使用LBS和LB解決整體的負(fù)載。如下圖所示：

使用Local的主機(jī)完成地域性的接入工作。使用設(shè)備接入層負(fù)責(zé)vpc上行數(shù)據(jù)的接入。兩種方式完成系統(tǒng)整體的業(yè)務(wù)需求。

7. 協(xié)議安全

從協(xié)議角度考慮協(xié)議被劫持，在MQTT的基礎(chǔ)上使用SSL的方式加強(qiáng)數(shù)據(jù)傳輸方案的安全性。并使用TLV的方式將消息進(jìn)行序列化。

從承載層和業(yè)務(wù)層都對數(shù)據(jù)進(jìn)行了保密處理。

8. 協(xié)議異常處理

協(xié)議中的異常：整體策略上以重試為主，如果重試多次仍失敗后則重新上線。并在這個基礎(chǔ)之上輔以異常處理策略解決。

異常處理需要將異常記錄到服務(wù)端，并在服務(wù)端可以展示出在什么時間，發(fā)生了什么樣的異常，怎樣處理恢復(fù)的。

在異常的處理過程中比較重要的點(diǎn)是需要記錄用戶操作。防止在之后用戶操作問題造成系統(tǒng)的異常。

9. 開發(fā)方法

開發(fā)方式需要有Mock服務(wù)完成兩端的對接工作。并使用協(xié)議Jar的方式統(tǒng)一設(shè)備端與服務(wù)端的協(xié)議。

10. 測試方式

測試方式需要進(jìn)行MQTT客戶端模擬器進(jìn)行協(xié)議包的發(fā)送與接收。在模擬器上模擬客戶端在發(fā)生異常以及處理異常時對端的處理。

11. 其他

-流量獲取

對接過程基本上都一樣的，過程是：

• 聯(lián)系客戶經(jīng)理，向客戶經(jīng)理提供申請開通平臺賬號。
• 從技術(shù)上對接平臺，獲取流量信息。

然后，咱購買sim卡的時候不是通過客戶經(jīng)理，是通過中間代理商的。代理商不會給咱賬號。

在IoT云平臺上對設(shè)備上的流量使用情況，以及流量使用過程的統(tǒng)計暫時使用設(shè)備上上報的內(nèi)容。在設(shè)備上可能統(tǒng)計不準(zhǔn)確，之后考慮形成規(guī)模之后對Sim卡的購買，銷售也做相關(guān)的控制。

• 版本編碼
  現(xiàn)在系統(tǒng)上使用兩個版本號完成版本管理工作。
  • 內(nèi)部版本號
    事例：

customer=zhilai
project=fengchao
require=R001
hardware=RSC-1320-AB412
baseline=imx6-android4.4-v1
version=0100

內(nèi)部版本號使用上面6個字段定義。從英文明上既可以指導(dǎo)具體意義。每個字段的長度如下表所示：

• 外部版本號

外部版本號即呈現(xiàn)給客戶的版本號，這里以其中的一個舉例：

MTB-911 F010 A712C001B021-20180713

這個版本號總長度為34個字節(jié)，我們在協(xié)議制定過程中使用40個字節(jié)存儲外部版本號。
因外部版本號是根據(jù)客戶的要求確定的，所以不再規(guī)定版本號的編碼規(guī)則。

• 型號編碼
  型號編碼用來規(guī)范之后在協(xié)議中使用版本號的方式。

三、信令定義表

1. 協(xié)議定義

協(xié)議是由信令以及信令間的流程組成的。所以，這里對信令的編碼進(jìn)行定義。在TLV格式中有一個字節(jié)專門標(biāo)識信令號。

對信令號進(jìn)行統(tǒng)一的編碼后，還可以進(jìn)行擴(kuò)展。一個字節(jié)一共256個編號可以使用，現(xiàn)在使用了12個編號后面的編號留給協(xié)議擴(kuò)展使用。這里的編號順序基本上按照交互過程中信令使用的順序進(jìn)行的編號，可以從一個側(cè)面反映出設(shè)備的整體處理過程。

協(xié)議擴(kuò)展時使用順序編號的方式，不允許跳過某一個編號進(jìn)行下一個編號的使用。并在擴(kuò)展信令時需要考慮對一個Modle的雙端可獲取的問題。即對某一件事物設(shè)備端既可以主動通知服務(wù)端，也需要服務(wù)端可以從設(shè)備端讀取到。這樣對于某些客戶關(guān)心的內(nèi)容，而上報不是那么及時時就可以采用服務(wù)端手動觸發(fā)的方式將設(shè)備數(shù)據(jù)獲取到。

因?yàn)镮oT云平臺是需要設(shè)備常態(tài)化在線的，不在線就說明出現(xiàn)故障。所以，在信令定義中不可以出現(xiàn)“設(shè)備下線”信令。

2. 協(xié)議錯誤碼定義

錯誤碼用來標(biāo)識錯誤原因。在代碼層次可以一目了然的判斷錯誤原因。并且在響應(yīng)信令中還包括具體內(nèi)容，都可以進(jìn)行相關(guān)的錯誤原因標(biāo)識工作。

3. 協(xié)議分類

接下來對上面信令列表中的信令進(jìn)行了分類，大概分為：

• 設(shè)備上線
• 設(shè)備配置
• 設(shè)備命令
• 設(shè)備狀態(tài)
• 設(shè)備心跳
• 設(shè)備升級

從名稱上就可以知道這些分類負(fù)責(zé)那些內(nèi)容。這里概要的說明這些信令都需要流程、處理策略、觸發(fā)機(jī)制、周期、方向，在每一個章節(jié)中都會有詳細(xì)的說明。

四、設(shè)備上線協(xié)議定義

設(shè)備上線是第一條信令，但是不是設(shè)備上線準(zhǔn)備工作的開始。設(shè)備上線過程需要在IoT云平臺上配置完成后才允許發(fā)送上線消息。設(shè)備在IoT平臺上包括很多信息，例如：設(shè)備型號，MAC地址，告警閾值，升級策略等等。所以，第一步請先到IoT平臺上將設(shè)備導(dǎo)入，或配置形成一條允許上線的設(shè)備后再進(jìn)行接下來的步驟。

1. 流程

上線過程可以擴(kuò)展到更前端的協(xié)議。上線的設(shè)備需要有協(xié)議棧的支持，在協(xié)議棧的支持下接收和發(fā)送TCP/IP數(shù)據(jù)。然后還需要有MQTT的功能庫的支持，這樣可以保證業(yè)務(wù)協(xié)議的支撐。再接著才是本文檔內(nèi)定義的協(xié)議。

上線過程分兩個步驟：設(shè)備認(rèn)證和設(shè)備上線。

• 設(shè)備認(rèn)證

上線策略：只有通過設(shè)備認(rèn)證的設(shè)備才允許上線。如果沒有通過設(shè)備認(rèn)證，則不允許上線操作。

因?yàn)樵陂_放的IoT平臺上會對設(shè)備的歸屬、設(shè)備的使用情況做統(tǒng)計。最終呈現(xiàn)給客戶形成收費(fèi)依據(jù)。所以，針對沒有通過認(rèn)證的設(shè)備是無法得知設(shè)備的歸屬的，無歸屬的設(shè)備是不允許上線的。

在這里定義的認(rèn)證過程最好是可以完成LBS的工作。使用如下圖所示的方式是最好的LBS協(xié)議過程。這樣可以在返回認(rèn)證Token的同時順帶返回相關(guān)的LBS服務(wù)器信息。

初期階段在實(shí)現(xiàn)MVP時，最好的方式是使用DNS動態(tài)獲取的方式獲得MQTT服務(wù)器相關(guān)位置然后通過User：Password的方式進(jìn)行相關(guān)的認(rèn)證工作。具體內(nèi)容下一節(jié)介紹。

• 設(shè)備上線

設(shè)備上線場景有多重方式觸發(fā)：升級，上電，掉線，重啟。

在做固件升級時，升級完成也伴隨著重啟的過程。在重啟完成后，系統(tǒng)還是會將業(yè)務(wù)進(jìn)程進(jìn)行啟動。在業(yè)務(wù)進(jìn)程啟動完成就需要進(jìn)行設(shè)備上線信令的發(fā)送。

設(shè)備加電或者上電后，也伴隨著設(shè)備上系統(tǒng)的啟動。如升級一樣，設(shè)備啟動后的第一要務(wù)就是進(jìn)入上線流程。

設(shè)備掉線的原因非常多，設(shè)備的流量用完、設(shè)備的網(wǎng)絡(luò)不可用、設(shè)備故障都是可能的情況。

2. 認(rèn)證過程

在進(jìn)行MVP模式平臺開發(fā)時，我們使用的認(rèn)證過程為使用MQTT協(xié)議中的用戶名，密碼方式進(jìn)行。用戶名密碼具體存儲在MongoDB中Device_Auth_Info集合中。密碼是設(shè)備端發(fā)送過來的密碼的sha256哈希后的值。

因?yàn)樵O(shè)備現(xiàn)實(shí)情況的限制，在這里可以定義。定義可以使用MAC地址作為用戶名，然后使用MD5哈希過的MAC+型號+“IoT”實(shí)現(xiàn)。

在進(jìn)行IoT云平臺全平臺開發(fā)過程需要使用上面介紹的方案進(jìn)行設(shè)備認(rèn)證。

3. 信令

• 設(shè)備上線信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：1（Online）
  信令體：
  本信令是變長信令。信令中會根據(jù)網(wǎng)絡(luò)接入類型填寫不同的字段。

• 設(shè)備上線確認(rèn)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：2（Result）
  信令：

五、設(shè)備配置協(xié)議定義

1. 流程

存儲

設(shè)備上線完成后設(shè)備端需要知道相關(guān)的配置參數(shù)。設(shè)備根據(jù)配置參數(shù)再去進(jìn)行下面相關(guān)的設(shè)備操作等動作。這里先說明配置的存儲方式，幫助之后在設(shè)備端、服務(wù)端加載配置時使用。配置的存儲方式分為三種：
1. 設(shè)備端需要存儲默認(rèn)的設(shè)備配置信息；
2. 服務(wù)端會存儲一份默認(rèn)配置，這份配置可以針對每個設(shè)備型號，每個軟件版本進(jìn)行維護(hù)。
3. 服務(wù)端會存儲特定的配置。例如：運(yùn)維人員給設(shè)備設(shè)置的特殊參數(shù)，給一批設(shè)備設(shè)置的參數(shù)。

加載

存儲在不同的位置的配置信息是需要加載或者生效才可以真正的應(yīng)用到具體場景中。下面說明加載機(jī)制：
1. 設(shè)備上電之后直接加載設(shè)備上的默認(rèn)存儲的配置信息；
2. 上線流程通過后，服務(wù)端會下主動的下發(fā)配置信息到設(shè)備端。設(shè)備端在接收到配置信息后應(yīng)該馬上加載配置信息；
3. 設(shè)備處于在線狀態(tài)后，如果服務(wù)端發(fā)生了配置變更，會主動的發(fā)送配置信息給設(shè)備。這個時候設(shè)備端也是需要馬上加載配置信息的。

2. 配置項(xiàng)

配置信息里面可以分為很多種配置項(xiàng)。配置項(xiàng)里面又可以定義具體的配置內(nèi)容。因?yàn)樵O(shè)備上配置的內(nèi)容較多，需要進(jìn)行分類管理。

具體的配置包括的項(xiàng)目：

3. 配置項(xiàng)編碼

在信令碼流中定義使用配置項(xiàng)組合的方式進(jìn)行配置下發(fā)。可以進(jìn)行配置的選擇行下發(fā)，以支撐流量控制的情況盡量減少數(shù)據(jù)的傳輸。所以，必須對配置項(xiàng)進(jìn)行編碼，以接收方和發(fā)送方判斷具體碼流中的配置項(xiàng)。配置項(xiàng)編碼如下：

每個編碼段都只是用了部分號碼。其他的號碼可以在之后擴(kuò)展時使用。

4. 配置項(xiàng)默認(rèn)值

默認(rèn)值具體如下圖所示：

5. 信令

設(shè)備配置信令采用選擇組合的信令組織方式進(jìn)行。具體為選擇一些配置項(xiàng)，將這些項(xiàng)的配置加載到二進(jìn)制流中。在解析的時候按照二進(jìn)制流前端所說明配置項(xiàng)類型進(jìn)行解析。

每個配置項(xiàng)在一個信令中盡量不要重復(fù)出現(xiàn)。重復(fù)出現(xiàn)以最后一次的配置為準(zhǔn)。

• 配置下發(fā)
  信令方向：服務(wù)端->設(shè)備端
  信令編號：3（Config）
  信令：

• 配置下發(fā)響應(yīng)
  信令方向：設(shè)備端->服務(wù)端
  信令編號：2（Result）

六、設(shè)備命令協(xié)議定義

設(shè)備命令都是從服務(wù)端下發(fā)命令到設(shè)備端。具體命令的處理過程由業(yè)務(wù)執(zhí)行方式定義。這里說明命令的規(guī)范。在協(xié)議擴(kuò)展中如涉及到其他方式的通信，協(xié)議中不予支持。其他通信方式具體使用的通信協(xié)議，通信過程由業(yè)務(wù)確定。例如：抓日志命令，在抓取了日志命令后日志的傳輸不得使用MQTT協(xié)議，具體是使用的協(xié)議需要有抓日志業(yè)務(wù)確定。

設(shè)備端必須可以識別命令，并按照命令的動作進(jìn)行執(zhí)行。故之后擴(kuò)展時需要通知服務(wù)端和設(shè)備端同時進(jìn)行支持，并在版本號中進(jìn)行升級。

1. 分類

2. 流程

有服務(wù)端下發(fā)命令信令到設(shè)備端。設(shè)備端收到命令信令之后發(fā)送響應(yīng)信令。設(shè)備端發(fā)送響應(yīng)后再進(jìn)行命令的處理流程。處理完成之后的流程還是需要具體業(yè)務(wù)進(jìn)行定義的。

3. 信令

• 命令下發(fā)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：8（Command）

信令：

• 命令下發(fā)響應(yīng)信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：2（Result）

七、設(shè)備狀態(tài)協(xié)議定義

設(shè)備的狀態(tài)可以分為正常狀態(tài)、異常狀態(tài)和故障狀態(tài)。設(shè)備上的狀態(tài)機(jī)在第二章中已經(jīng)說明。在設(shè)備處于正常狀態(tài)下發(fā)送的狀態(tài)信令，設(shè)備處于異常狀態(tài)下需要上報狀態(tài)信令和告警信令。在設(shè)備處于故障狀態(tài)時無法完成通信，所以，只能處于下線狀態(tài)。

狀態(tài)信令中包括設(shè)備上主要的一些狀態(tài)，不攜帶非主要信息。以這樣的方式降低系統(tǒng)對流量，帶寬的要求。在告警信令中也是只包含產(chǎn)生告警的告警項(xiàng)，所以，告警信令需要由告警項(xiàng)組織成整體的二進(jìn)制流。

1. 告警分類

針對設(shè)備上不同的部分設(shè)計了不同的告警。以及在不同的設(shè)備上也會產(chǎn)生設(shè)備所特有的告警。告警閾值的計算方式上分為兩種：

• 數(shù)值型告警
• 百分比型告警
  這兩種的計算方式或者觸發(fā)方式定義了告警中的數(shù)值的上報方式。
  在這里定義一些設(shè)備的告警分類：

2. 流程

設(shè)備上線后再隔一個狀態(tài)上報周期，開始上報狀態(tài)信息。在設(shè)備上線后，需要進(jìn)行告警掃描動作，在任何時候告警掃描出告警后，就需要上報告警信息。

設(shè)備的告警在上報過程中不需要考慮告警是否已經(jīng)上報過。告警是否已經(jīng)上報，是否重復(fù)由服務(wù)端進(jìn)行判斷。

3. 信令

• 狀態(tài)上報信令

信令方向：設(shè)備端->服務(wù)端
信令編號：4（Status）
信令：

• 狀態(tài)上報響應(yīng)信令

信令方向：服務(wù)端->設(shè)備端
信令編號：2（Result）

• 告警上報信令

信令方向：設(shè)備端->服務(wù)端
信令編號：6（Alarm）
信令：

• 告警上報響應(yīng)信令

信令方向：服務(wù)端->設(shè)備端
信令編號：2（Result）

• 告警恢復(fù)信令

信令方向：設(shè)備端->服務(wù)端
信令編號：7（Recovery）
信令：

• 告警恢復(fù)響應(yīng)信令

信令方向：服務(wù)端->設(shè)備端
信令編號：2（Result）

八、設(shè)備心跳協(xié)議定義

設(shè)備狀態(tài)保持策略為在一個狀態(tài)周期內(nèi)如果有任何消息就說明狀態(tài)在線，不需要再對設(shè)備的狀態(tài)進(jìn)行維護(hù)。服務(wù)端會認(rèn)為設(shè)備在這個迭代內(nèi)是在線的。在MQTT協(xié)議中有相關(guān)的心跳保持支持，可以認(rèn)為在MQTT協(xié)議上存在的設(shè)備就是在線的設(shè)備。

1. 流程

上線后，隔1.5隔周期后發(fā)送第一個心跳。

2. 信令

• 心跳信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：9（Heartbeat）

信令：

• 心跳響應(yīng)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：2（Result）

九、設(shè)備升級協(xié)議定義

設(shè)備端升級主要涉及到版本管理功能。版本管理功能在服務(wù)端使用全量包，差分包，APP包三種管理方式進(jìn)行版本包的管理。在MVP實(shí)現(xiàn)過程中，使用FTP方式作為文件發(fā)布的方式。在實(shí)現(xiàn)IoT云平臺開放式最好的方式需要進(jìn)行先同步到就近服務(wù)器上，再由設(shè)備去就近服務(wù)器上進(jìn)行獲取。

1. 分類

設(shè)備升級可以有多種分類：從系統(tǒng)升級、APP升級。從差分升級、全量升級。以下面表格說明具體意義：

在設(shè)備升級過程中的APP和差分升級的組合現(xiàn)階段不支持，因?yàn)锳PP包本來就比較小。如果需要可以直接進(jìn)行，對流量的影響較小。

設(shè)備升級還可以按照發(fā)起端的不同進(jìn)行區(qū)分。發(fā)起端主要可以分為：設(shè)備端觸發(fā)，服務(wù)端觸發(fā)。以下表說明具體意義：

設(shè)備端盡量不要觸發(fā)系統(tǒng)升級，因?yàn)橄到y(tǒng)升級可能會造成運(yùn)營人員在未知的情況下對設(shè)備進(jìn)行了升級操作。然后如果升級出現(xiàn)故障，則需要手動恢復(fù)。不想APP升級可以重新在升級一遍即可。

2. 流程

• 設(shè)備端觸發(fā)

設(shè)備端可以發(fā)送NewVersion信令給服務(wù)端，用以查詢服務(wù)端的最新版APP版本。這種場景主要為了滿足上層業(yè)務(wù)在快速的發(fā)生變化的情況。可以滿足系統(tǒng)快速迭代，快速升級的需求。

服務(wù)端在接收到設(shè)備端發(fā)送的NewVersion信令后，立即響應(yīng)設(shè)備結(jié)果信息。響應(yīng)完成之后，再進(jìn)行比較與判斷，如果判斷有新版本就需要再次下發(fā)版本升級命令給設(shè)備端。

• 服務(wù)端觸發(fā)

服務(wù)端觸發(fā)的版本升級，即為運(yùn)營人員手動觸發(fā)。運(yùn)營人員可以根據(jù)各種方式選擇要升級的設(shè)備，并對設(shè)備進(jìn)行批量，單個升級操作。

設(shè)備端升級完成APP后，需要立即上報升級結(jié)果。

3. 設(shè)備上升級點(diǎn)

設(shè)備上有很多內(nèi)容可以升級，這里定義升級過程中可能會升級到的點(diǎn)。以方便在升級命令中攜帶，并指明需要升級的軟件。下面是設(shè)備上的可以升級的升級點(diǎn)：

4. 信令

• 新版本查詢信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：A（NewVersion）
  信令：

• 新版本查詢響應(yīng)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：2（Result）

• 版本升級信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：B（Upgrade）
  信令：

• 版本升級響應(yīng)信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：2（Result）

• 版本進(jìn)度信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：C（Progress）
  信令：

• 新版本查詢響應(yīng)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：2（Result）

• 版本升級結(jié)果信令
  信令方向：設(shè)備端->服務(wù)端
  信令編號：B（Upgrade）
  信令：

• 版本升級結(jié)果響應(yīng)信令
  信令方向：服務(wù)端->設(shè)備端
  信令編號：2（Result）

十、遺留問題

1. MQTT客戶端選擇

https://github.com/mqtt/mqtt.github.io/wiki/libraries