1 概述
因為工作的内容多與物聯網相關，總結下自己在物聯網通信，資料采集等方面積累的知識和經驗。
總結的主要為水利物聯網行業相關的經驗，我在公司主要負責的是資訊化采集工作，包括各種各樣的水利資訊化裝置的資料采集，像RTU，直連式傳感器，PLC自控資料等。
通過這些年的工作對物聯網也有了些自己的見解。
物聯網，所謂讓物聯網，無非是讓資料聯網。當我能從監控中心擷取到一個裝置的各類資料（監測資料，運作資料等）時，那麼就可以了解為這個物 聯網了。聯網是一個動詞，物聯網也是一個動态的過程。這個過程就是 資料上行和下行 互動的過程。
那麼為了讓這個過程能夠通用，規範，于是出現了各種物聯網通信協定，像大家所熟知的 MQTT 在物聯網通信領域 大放異彩。除此之外還出現了專門的物聯網網關，資料采集器等各種各樣的裝置。
那麼物聯網是一個怎樣的過程呢，接下來 介紹在一個項目上應用為例說明下 物聯網采集過程：
需求是這樣的：
整個項目是一個大型的灌區資訊化項目，需要對灌區的各個泵站的資料實時采集和遠端控制。
泵站使用物聯網網網關發送資料，每個泵站配一個網關，泵站的PLC 自控系統資料通過網關，走4G 發送到遠端控制中心。我在控制中心部署MQTT服務，用來接收網關資料。 在MQTT主要包括兩部分，一部分為上行資料，即網關實時上報的資料；另一部分是下行資料，也就是遠端控制指令下發。使用兩個主題Topic 一個用于資料上報，一個用于指令下發。
在物聯網網關配置上，以提水泵站為例，網關訂閱 主題A用于接收平台控制指令， 網關采集資料配置主題B 用于推送資料。 提水泵站 PLC的運作資料像 電流、電壓、開度、手自動狀态等資料通過物聯網網關發送到 MQTT服務 主題B,
此時平台 訂閱 主題B，接收到實時資料後解析到平台實時展示；同理平台 下發控制指令到 主題A ，此時網關訂閱主題A，接收到指令解析後判斷是發給自己的就執行指令到PLC。
這個過程簡言之就這麼簡單，當然細節很複雜。包括各種指令解析，首先所有的網關監聽相同的 主題，平台下發的指令包含每個網關的唯一ID ，每個網關接收指令後與自己比對，相同則執行。我們這裡統一使用 JSON 格式互動資料；
控制指令封包格式如下：
網關上報資料格式：
這裡隻是舉個例子，具體格式因網關廠家型号不同而不同。
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.結語
整個物聯網架構中，最關鍵之處莫過于與裝置建立連接配接和通信了。
當成功與裝置建立通信後，我們就可以采集我們想要的各種資料了，有了資料支撐，和通信保證後後。我們就可以開發各種好玩有趣的物聯網應用系統了。
随着技術的發展，物聯網已經與我們的生活息息相關，像深受大家喜歡的手環，掃地機器人等等。
相信也會有更多的人加入到物聯網加技術領域中探索其中的奧秘。