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.结语
整个物联网架构中，最关键之处莫过于与设备建立连接和通信了。
当成功与设备建立通信后，我们就可以采集我们想要的各种数据了，有了数据支撑，和通信保证后后。我们就可以开发各种好玩有趣的物联网应用系统了。
随着技术的发展，物联网已经与我们的生活息息相关，像深受大家喜欢的手环，扫地机器人等等。
相信也会有更多的人加入到物联网加技术领域中探索其中的奥秘。