1 概述
因為工作的內容多與物聯網相關，總結下自己在物聯網通訊，資料採集等方面積累的知識和經驗。
總結的主要為水利物聯網行業相關的經驗，我在公司主要負責的是資訊化採集工作，包括各種各樣的水利資訊化裝置的資料採集，像RTU，直連式感測器，PLC自控資料等。
通過這些年的工作對物聯網也有了些自己的見解。
物聯網，所謂讓物聯網，無非是讓資料聯網。當我能從監控中心獲取到一個裝置的各類資料（監測資料，執行資料等）時，那麼就可以理解為這個物 聯網了。聯網是一個動詞，物聯網也是一個動態的過程。這個過程就是 資料上行和下行 互動的過程。
那麼為了讓這個過程能夠通用，規範，於是出現了各種物聯網通訊協議，像大家所熟知的 MQTT 在物聯網通訊領域 大放異彩。除此之外還出現了專門的物聯網閘道器，資料採集器等各種各樣的裝置。
那麼物聯網是一個怎樣的過程呢，接下來 介紹在一個專案上應用為例說明下 物聯網採集過程：
需求是這樣的：
整個專案是一個大型的灌區資訊化專案，需要對灌區的各個泵站的資料實時採集和遠端控制。
泵站使用物聯網網閘道器傳送資料，每個泵站配一個閘道器，泵站的PLC 自控系統資料通過閘道器，走4G 傳送到遠端控制中心。我在控制中心部署MQTT服務，用來接收閘道器資料。 在MQTT主要包括兩部分，一部分為上行資料，即閘道器實時上報的資料；另一部分是下行資料，也就是遠端控制指令下發。使用兩個主題Topic 一個用於資料上報，一個用於指令下發。
在物聯網閘道器配置上，以提水泵站為例，閘道器訂閱 主題A用於接收平臺控制指令， 閘道器採集資料配置主題B 用於推送資料。 提水泵站 PLC的執行資料像 電流、電壓、開度、手自動狀態等資料通過物聯網閘道器傳送到 MQTT服務 主題B,
此時平臺 訂閱 主題B，接收到實時資料後解析到平臺實時展示；同理平臺 下發控制指令到 主題A ，此時閘道器訂閱主題A，接收到指令解析後判斷是發給自己的就執行命令到PLC。
這個過程簡言之就這麼簡單，當然細節很複雜。包括各種指令解析，首先所有的閘道器監聽相同的 主題，平臺下發的指令包含每個閘道器的唯一ID ，每個閘道器接收指令後與自己匹配，相同則執行。我們這裡統一使用 JSON 格式互動資料；
控制指令報文格式如下：
{"did":"FD5170315680","utime":"2021/11/02 18:34:05","content":[{"pid":"1","addr":"LCU5_SZDQH","addrv":"0"}]}
閘道器上報資料格式：
{"did":"FF8030932752","utime":"2021/11/14 13:31:27","content":[{"pid":"1","type":"1","addr":"LCU3_BJXY","addrv":"0","ctime":"2021/11/14 13:31:27"},{"pid":"1","type":"0","addr":"LCU3_SSLL","addrv":"0.000000","ctime":"2021/11/14 13:31:27"},{"pid":"1","type":"0","addr":"LCU3_LJLL","addrv":"0.000000","ctime":"2021/11/14 13:31:27"}]}
這裡只是舉個例子，具體格式因閘道器廠家型號不同而不同。
2.物聯網裝置
這裡說到物聯網閘道器，其實它在物聯網通訊中是非常重要的一個裝置，它的強大 在於整合了海量裝置協議，並且具有邊緣計算的功能，像我們這裡PLC 使用的是Modbus TCP協議，使用了閘道器後，平臺就不需要關心Modbus解析的問題了，這些工作都由閘道器完成。平臺只需要傳送一個json字串就能控制泵站的開啟關閉。而不需要關心 平臺json格式的 指令與modbus 報文之間的轉換。
物聯網採集裝置很多，像我這個專案裡就用到了，閘道器和RTU，RTU從事水利資訊化行業可能瞭解的比較多一點，因為經常需要RTU裝置傳輸 水文，水質等監測資料。
RTU裝置多數使用TCP傳輸協議。報文通訊協議有國標水文協議，水資源協議，汙染物傳輸協議等等，這些應用層協議與使用閘道器傳輸時的 Json 協議類似，是用來封裝資料包文的。
除此之外還有直連式的感測器裝置。這類裝置整合了傳輸模組，使用物聯網路卡，或藍芽，wifi等方式傳輸資料。
3.物聯網服務
同樣的物聯網服務同樣分為三個部分，分別是資料接收和下發，資料處理、資料庫或訊息佇列服務。
資料收發部分通常是指我們的採集軟體的前端部分，它支援多種協議，從閘道器或裝置接收資料。
資料處理部分指的是資料解析儲存。這裡的儲存包括將解析資料儲存至資料庫也包括將資料傳送至訊息中介（訊息佇列，Redis等），也可以將相應的指令封裝成報文下發到裝置。
資料庫服務指的是資料庫系統，包括關係型資料庫，快取資料庫或訊息佇列。這部分為整個物聯網平臺提供資料儲存備份服務。
4.物聯網通訊協議
MQTT可以說是物聯網領域的明星協議了，使用很廣泛。主要還是MQTT 很強大，關鍵很好用，我之前寫過一篇部落格 使用RabbitMQ 搭建MQTT服務，很簡單，使用Rabbit也很穩定。 這裡就不展開了，感興趣的可以看下 ：使用RabbitMQ搭建MQTT服務
這裡介紹下MQTT：
4.1 MQTT
MQTT是目前物聯網領域的標準協議，它可以工作在低頻寬、不可靠網路環境下。MQTT是一對多的通訊協議，它包括了中介（broke），釋出者（publisher）,訂閱者（subscriber）三大主體。
中介MQTT Broker承擔著通訊伺服器的作用，而釋出者與消費者則屬於客戶端。在這三大主體中釋出者與訂閱者通過主題（Topic）交換資訊。MQTT傳輸的訊息分為主題（Topic）和負載（Payload）兩部分。把Broker比喻成郵局的話，Topic就是寄件地址，Payload就是我要寄出的信件。
需要注意的是在這裡釋出者和訂閱者都是相對而言的，釋出者也可以同時是訂閱者；訂閱者也是這樣，因為MQTT通訊是雙向的。
4.2 MQTT中的QOS
QoS 是 Quality of Service（服務質量）的簡稱，MQTT提供三個級別的質量保證，分別是QoS 0、QoS 1、QoS2。QoS存在於釋出者與中介之間，也存在與中介和訂閱者之間，
這裡需要注意當中介和訂閱者之間的QoS小於釋出者和中介之間的等級時，訂閱者的QoS會被降級。
QoS 0 指的是最多傳送一次訊息（at most once） ，傳送要遵循 TCP/IP 通訊的“盡力而為”。訊息分兩種情況，即到達了一次中介處，或沒有到達中介處。
QoS 1 指的是至少傳送一次，中介在收到訊息時會給釋出者回復“PUBACK”訊息確認響應。然後根據訂閱者的QoS給訂閱者釋出訊息。當發正故障沒能及時回覆“PUBACK”時，釋出者會再次釋出訊息。
QoS 2 是確保傳送一次訊息。QoS 2 能保證傳送一次訊息，且不會重複傳送。他的原理與TCP通訊的三次握手類似。QoS 2 傳送的訊息裡面含有訊息 ID。中介收到訊息後會將訊息儲存，然後給釋出者傳送 PUBREC 訊息。釋出者再給中介傳送 PUBREL 訊息，
然後中介會給釋出者傳送 PUBCOMP 訊息。接下來中介才會依據訂閱者指定的 QoS，向訂閱者傳遞接收到的訊息。
4.3 MQTT中的Retain
當我們使用MQTT客戶端釋出訊息（PUBLISH）時，如果將RETAIN標誌位設定為true，那麼MQTT伺服器會將最近收到的一條RETAIN標誌位為true的訊息儲存在伺服器端（記憶體或檔案）。
特別注意：MQTT伺服器只會為每一個Topic儲存最近收到的一條RETAIN標誌位為true的訊息！也就是說，如果MQTT伺服器上已經為某個Topic儲存了一條Retained訊息，當客戶端再次釋出一條新的Retained訊息，那麼伺服器上原來的那條訊息會被覆蓋！
每當MQTT客戶端連線到MQTT伺服器並訂閱了某個topic，如果該topic下有Retained訊息，那麼MQTT伺服器會立即向客戶端推送該條Retained訊息。
4.4 MQTT CleanSession 標記
CleanSession ：0 開啟會話重用機制。網路斷開重連後，恢復之前的Session資訊。需要客戶端和伺服器有相關Session持久化機制。
CleanSession ：1 關閉會話重用機制。每次Connect都是一個新Session，會話僅持續和網路連線同樣長的時間。
客戶端 Session
已經傳送給服務端，但是還沒有完成確認的 QoS 1 和 QoS 2 級別的訊息
已從服務端接收，但是還沒有完成確認的 QoS 2 級別的訊息
伺服器端 Session
會話是否存在，即使會話狀態的其它部分都是空 (SessionFlag)
客戶端的訂閱資訊 (ClientSubcription)
已經傳送給客戶端，但是還沒有完成確認的 QoS 1 和 QoS 2 級別的訊息
即將傳輸給客戶端的 QoS 1 和 QoS 2 級別的訊息
已從客戶端接收，但是還沒有完成確認的 QoS 2 級別的訊息
(可選)準備傳送給客戶端的 QoS 0 級別的訊息
5.結語
整個物聯網架構中，最關鍵之處莫過於與裝置建立連線和通訊了。
當成功與裝置建立通訊後，我們就可以採集我們想要的各種資料了，有了資料支撐，和通訊保證後後。我們就可以開發各種好玩有趣的物聯網應用系統了。
隨著技術的發展，物聯網已經與我們的生活息息相關，像深受大家喜歡的手環，掃地機器人等等。
相信也會有更多的人加入到物聯網加技術領域中探索其中的奧祕。