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.結語
整個物聯網架構中，最關鍵之處莫過於與設備建立連接和通信了。
當成功與設備建立通信后，我們就可以采集我們想要的各種數據了，有了數據支撐，和通信保證后后。我們就可以開發各種好玩有趣的物聯網應用系統了。
隨着技術的發展，物聯網已經與我們的生活息息相關，像深受大家喜歡的手環，掃地機器人等等。
相信也會有更多的人加入到物聯網加技術領域中探索其中的奧秘。