1. 物联网基础知识

📝 物联网需要了解的基础知识。

1. 物联网解决的问题

智慧园区的基础，是智慧硬件，将园区内的各个智能设备接入网络，可极大减少对底层操控的人力物力成本。

• 如中台再引入可视化管理，降低操作人员的学习成本，可对园区整体硬件设备集中可视管理。
• 如安装防盗系统，可配合摄像头、喇叭、门磁等多硬件设备形成一系列自动化警告、摄录、报警、通知相关人员等；
• 如监控休息室流量、监控卫生间流量、监控美餐柜等等，提升管理覆盖面积，提升办公效率。

1.1 什么是物联网

IOT（英文）

物联网相比于互联网，参与网络的主体发生了变化， internet 的消费主体是人。而 iot 的主体是是人与设备的共同参与：

1.2 物联网的结构

物联网的三个层次：

1. 设备层，也就是各种硬件设备。

   • 传感器（温度、门磁等）；

   • 执行器（继电器、电机等）；

   • 其他智能设备：含有嵌入式系统芯片的设备，都可以入网（STM32、FPGA）等；

   • 通信设备：Wifi、蓝牙、蜂窝网络等基础通信设备；

2. 网络层，用于设备与物联网平台之间的通信。

   • 机遇计算机网络提供的平台，使物联网设备接入网络，可以有 网络/传输层 TCP/IP 协议、应用层 HTTPS 协议、
   • MQTT / AMQP协议更常用。

3. 应用层，实现具体业务逻辑的地方

   • 接入物联网平台的终端是很多的，采集的数据更是海量的。因此，对应物联网平台的后台相对于普通的服务后台，需要解决海量数据的存储、处理、分析等问题。

2. 数据流

网联网的数据流大概是按照下面这个逻辑：

• 数据采集、数据传输、数据存储、数据处理、数据应用。
• 物联网中台中，主要实现了数据存储，服务于数据应用。硬件设备产生的数据，数据应用产生的指令，都存储在物联网中台中。

2.1 数据采集

每一个原始数据，都有其“生产者”，通常我们称之为“数据源”。

数据源采集和发送数据，通过物联网，传递到应用层。由于物联网的通信特点，可能还需要对数据做一些临时的保存工作。

数据采集具备复杂性。从宏观的角度来看，数据源采集的数据类型多种多样，对应的数据采集设备也多种多样。例如采集温度、湿度等的传感器、采集视频的摄像头、采集声音的录音设备等等。

• 这些终端设备中，需要有 嵌入式系统 进行支撑，这部分工作，在 iot 物联网中台中，通常项目外包，交给外包人员进行实现。
  • 网关 + 数据统一。
• 难点：设备众多、通信协议复杂、需要对接大量的硬件公司和技术人员，参阅大量对应硬件的技术手册。时间成本较高。

对于上层来说，数据采集工作屏蔽了底层硬件设备不同的通信协议、不同的数据存储存方式，使得上层仅需关注硬件产生的信息本身。

2.2 数据传输

采集到的数据，需要上传到物联网中台，这个过程就是数据传输。数据传输的要求是快速、可靠。

从宏观的角度来看，数据传输的难点是 高并发。网联网环境中设备数量众多，并且这些设备都是源源不断的产生和上传数据，因此要求中台具备处理高并发的能力，能够有效、可靠的接收数据。

• 高并发的实现，需要 分布式系统 的支持，同时要引入负载均衡、消息队列、缓存 等相关的技术。

2.3 数据存储

数据传输到物联网中台之后，需要进行存储。这里要解决的问题是 海量异构数据的存储。

比如一个园区遍布的摄像头，每个季度就可以产生数PB级的数据。

在数据量大的同时，数据的类型和格式还多种多样，按照特性可以分为3类：

• 结构化数据：例如用户信息、设备参数等等。
• 半结构化数据：例如日志记录、JSON 结构的数据等。
• 非结构化数据：例如图像、视频、音频等数据。

存储结构：

• 对于海量的结构化数据，可以采用 分布式关系数据库 存储；
• 对于时间敏感的数据，可以采用 时序数据库。
• 对于半结构化数据，可以采用 NoSQL 数据库，比如MongoDB，Neo4j 等来存储。
• 对于非结构化数据，可以采用 HDFS 这样的 分布式文件系统 来处理。

数据库选型的基本原则，就是根据数据的类型和业务使用的方式来选择，数据大体上可以分为3类：

1. 结构化数据 （Structured Data）
2. 半结构化数据 (Semi-Structured Data)
3. 非结构化数据 (Unstructured Data)

针对这些数据的特性，以及使用的业务场景，我们可以选择不同类型的数据库。

2.4 数据应用

前面的数据采集、传输、存储、处理，都是为了最终的数据应用，利用数据创造价值。

数据产生价值的方式，大致有以下几种：

1. 挖掘：分析数据的规律和管理关系，一个经典的应用就是用户画像和购买习惯的分析。在园区中，可以分析员工下班的大致时间。
2. 预测：构建预测模型，比如我们经常可以看到共享单车公司将单车各个地方收集整理后投放到指定的位置，这些位置的选择就是通过预测得出的。
3. 控制决策：例如根据光线变化打开关闭电灯，根据温度变化打开空调等等。
4. 可视化：
   • 单数据的可视化，例如我们使用滴滴打车的时候显示司机的位置。园区的门磁点位信息就是单数据可视化的一种表现。
   • 统计数据的可视化，例如直方图、曲线图等。

所有的这些应用，都是需要通过算法来实现的。由于数据量巨大，使用人工分析是不可能的，因此通常使用机器学习、人工智能来对数据进行统计分析。

这些算法分为监督学习和非监督学习两大类。

• 监督学习：我们需要告诉算法哪些是对的，哪些是错的。
• 非监督学习：算法要自己将数据中的”异常值“区分出来。

3. 网络层

主要讲物联网的通信协议，明白大概就好，重点理解下 kafka 涉及的相关知识。

3.1 网联网通信的特点

物联网通信的特点和物联网设备所处的环境有很大的关系：

1. 设备处在 不可靠、高延迟的网络环境。

比如共享单车，如果使用的NB-IoT这样的通信技术，本身的通信速率就低，如果被停在信号不稳定的地方，通信质量就更差。 这样的情况下，如果使用HTTP这样的协议，需要先建立连接，发出请求，等待响应，很可能连接经常中断，需要多次交互才能够完成一次请求，用户开个锁就需要等待很长时间。

2. 设备数量众多，交互关系复杂。

比如智能家居，家里的多种物联网设备之间是有相互关联的，如果让物联网平台对每个设备做权限控制和数据阈值的限制，基本不现实。这个时候，需要将一个家作为一个整体来处理，简化交互逻辑。

3. 设备流动性大

大的比如共享单车，不断有新设备加入，也不断有设备退出。

小的如智能家居，随时可能新加入设备入网，但不能没当新加入设备，就需要配置一遍参数。因此，网络通信协议需要具备可伸缩性。

3.2 发布-订阅模式

过消息队列就是发布-订阅模式（参考浏览器结构）。

这个模式包含 3 个角色：发布者（Publisher）、经纪人（Broker）、订阅者（Subscriber）：

在物联网场景中，一个传感器数据需要出发多个服务或者终端，并且这种出发需要是可扩展的。

比如我们在窗户上设置防盗系统，目前可能参与的设备有门磁，当检测到有人非法闯入，同时会触发以下事件：

• 在开启期间发现有人开启窗户，需要通知摄像头录像、通知声光报警器报警、推送消息到相关工作人员的手机等等。同时，将来可能还需要有新的防盗设备接入。那么，最好让摄像头、报警器、信息推送等都订阅 “窗户异常开启” 这个 事件 / 消息，将来有新的设备，也可以监听这个 事件 / 消息。这样，消息的生产者和消费者之间就进行了解耦。

3.2.1 MQTT

Message Queuing Telemetry Transport，消息队列遥测传输。

MQTT协议是一个轻量级的网络协议，有3个特点：

1. 采用二进制的消息内容编码格式。
2. 协议头紧凑，交互简单。
3. 支持 3 种消息传递语义（最少一次、最多一次、恰好一次）。

三种语义：

• QoS 0，表示的是“最多一次“送达，也就是消息可能会丢失，但是不会重复。
• QoS 1，表示的是”至少一次“送达，也就是消息可能会重复，但是不会丢失。
• QoS 2， 表示的是”恰好一次“送达，也就是消息有且只有一次送达，不会丢失，也不会重复。

MQTT格式简洁、占用带宽小的特色，非常适合计算能力有限、网络带宽低、信号不稳定的远程设备。另外，由于MQTT几乎支持所有的平台，得到了广泛的应用，基本上是现在物联网系统事实上的网络协议标准。

另：kafka

• kafka 也有最少一次、最多一次、恰好一次。更多知识可以在 kafka 相关文章中了解。

3.2.2 AMQP

全称是 Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准。

AMQP也是采用的二进制消息格式，也支持3种消息传递语义。

AMQP的特点是可靠、通用，但是 AMQP 定义了庞大的特性集，是一个重量级的协议，不适合对功耗要求严格、计算能力有限的设备。但是很多后台的消息队列是支持 AMQP 协议的，比如RabbitMQ。

3.3 请求-响应模式

物联网设备也需要使用请求-响应模式。最典型的就是公司的美餐柜。

• 用户在终端设备（H5 / Web）输入取件码之后，终端设备向服务器发送验证请求，返回验证结果，最后开锁。

3.3.1 HTTP

唯一的优点：可以利用已有的 Web 服务资源。

HTTP协议的报文格式很重，不太适合资源有限的嵌入式设备。但是在资源充足的设备上，还是可以考虑的。

3.3.2 CoAP

全称 Constrained Application Protocal （受限的应用协议）。比 HTTP 轻量级的通信协议。

和HTTP协议一样，CoAP协议也使用URI来标识资源，也有GET,POST,PUT,DELETE等方法，也有响应状态码。

CoAP的消息采用二进制格式，支持可确认消息和不可确认消息两种（最多一次、最少一次）。协议包头小，仅为4个字节。采用 UDP 传输协议，对应设备的计算资源要求更低。

3.3.2 LwM2M

全称是 Lightweight Machine-to-Machine，轻量级物联网协议。

LwM2M协议是基于CoAP协议的，提供了一组轻量级设备关联和交互接口协议。和 CoAP 一样，适用于资源有限的终端设备管理。

3.4 网关

esp 8266 等芯片，或 FPGA 等芯片，可通过 MATT 协议入网；

常用传感器，可以通过 BLE、ZigBee 协议入网；

...

硬件的多种多样，造就了入网方式多种多样，需要有一个平台统一将所有硬件接入网络，同时屏蔽各个设备之间的数据结构差异。

所以，网关解决：

• 屏蔽硬件接入网络的 协议差异；

• 屏蔽硬件接入网络的 数据差异。

目前的物联网中，在逐步尝试将原本在云平台上的计算任务，放到靠近数据原产地的设备上完成。这个过程称为将计算能力下沉到边缘设备，也称为 边缘计算。

• 比如数据差异的处理、数据的粗筛、敏感数据的脱敏（语音语义、家庭摄像）等；

在项目中，物联网中台也涉及到了 南向接口、北向接口、物模型和设备分组。物联网中台是比网关更上层的东西，可以说网关的北向接口才是物联网中台的南向接口。

下面是物联网中台的定义：

• 南向接口：制定统一的南向接口，新设备接入物联网中台无需额外开发，可直接接入。
  • 物模型：用来解析参数，相当于硬件协议，通过物模型中的产品模型解决级联（父子）设备的管理问题。
• 北向接口：采用 penAPI 形式，支持跨域调用，可面向多个环境，解决开发、测试、生产环境的设备分配问题；
  • 设备分组：北向接口提供的 API，可以对设备进行分配：开发、测试、生产？

4 物模型

一套标准化的模型。面对某个硬件终端，操作人员或者其他硬件设备，通过物模型可以精确识别到该终端以及其产生的数据。

在物联网中，提供了 Thing Specification Language，缩写为 TSL，直译过来就是“物规范语言”。TSL 是用来描述物联网中的 物 的一种规范语言。使用 TSL 描述的物联网中的实体模型，就称为 物模型。物模型就是这个中间的标准化接口。

比如，在一个简单的电灯物联网系统中，需要以下组件：

• 数据采集组件：光照传感器。采集光线强度的数据。

• 执行组件：继电器。控制电路的通断，实现电灯的开关；变压器。若要控制亮度，通常需要控制电压（无级调节）或者将发光器件分为几组，分别控制开启和关闭（分级调节）。

• 控制组件：控制组件 产生 执行命令，执行组件 消费 执行命令。

  在物联网中台中，编辑命令的是规则引擎，这个命令本身，就是 各种动作。

  控制组件的实现形式有很多，比如专用的开发板、集成在网关中、嵌入到边缘计算设备中等。

• 网关： 家庭环境中，采用 BLE 技术；接入互联网中，需要有桥接设备，才能实现远程控制。通常我们选择一个设备来桥接家庭中所有的智能设备，这个桥接设备就被称为网关。网关不一定是由路由器来担当，也可以由电视、智能音箱等设备担当网关。

• 用户界面：操作人员的交互界面。可以是App应用，也可以是摄像头、音箱这样的设备。在项目中，是 h5 / web 页面，主要的呈现方式是图和表。

物模型其实就是对现实世界中物的抽象，抽取我们所关注的方面，然后使用TSL描述为计算机能够处理的信息。

• 清楚这个物是什么，可以提供什么信息，能够完成什么事情。

在抽象的过程中，需要提取产品的共同特征，形成模型。例如上面的智能台灯，无论采用哪种类型，都必须有开关属性。将这些共同的特征标准化之后，就形成了智能台灯的物模型。一旦形成标准之后，后续的产品则需要遵循标准。

因为物模型是基于一类产品的共同特征抽取的，因此采用了物模型之后，应用程序就不再耦合于一个具体的产品，而是可以应用于遵循这个规范的所有的产品。就像程序开发中的接口类和实现类一样，这其实也是面向接口编程的一种思路和体现。

在项目中，一个产品的物模型，有产品品类、产品名称、属性、事件、服务等等。

4.1 定义物模型

一个模型的定义，通常我们从 属性、事件、动作 这三种功能元素来定义。

比如一个智能台灯：

• 属性（Property）。描述设备的运行时的状态的数据项。设备可读取和设置的能力。一般用于描述设备运行时的状态，如环境监测设备所读取的当前环境温度等。属性支持 GET 和 SET 请求方式。
  • 比如智能台灯：开 / 关状态、亮度状态，色温状态。
  • 通过 读取属性 了解设备的运行状态；
  • 通过 写入属性 控制设备的运行状态。
• 事件（Event）。由设备 主动 报告 / 发送的消息，对设备本身来说是事件。一个事件中可以包含多个参数信息，对应事件的不同参数。事件可以被订阅和推送。
  • 智能台灯需要主动向物联网中台报告的，如，硬件故障，心跳等等。
  • 某项任务完成的信息，或者设备发生故障或告警时的温度等。
• 动作（Action）/ 服务（Service）。由设备对外提供的服务，也就是外部可以调用的功能（API），有输入、输出参数。相比于属性，服务可通过一条指令实现更复杂的业务逻辑，如执行某项特定的任务。
  • 逐一控制各个属性，比较繁琐，通常可以把常用的状态组合设置为一个预先定义好的场景，或者叫模式。这样在使用的时候，可以通过一个指令修改多个属性的值。
  • 在物联网中台项目中，硬件的动作或服务、多个动作的组合是通过 规则引擎 实现的。

4.2 物模型描述的总体结构

抽取了属性、事件、动作这些特征之后，需要能够描述为计算机能够读懂的信息。在 TSL 中，基本的数据类型有 6 种：

• 布尔型 bool
• 整数型 int
• 字符串 string
• 浮点型 float
• 枚举型 enum
• 时间型 timestamp

结构如下：

{
  "category" : [                                             //产品参数
    "version": "1.0",                                       
      "ProductId": "abcd1234",
      "CategoryId": "141" 
  ],
  "properties": [                      //属性列表
    {......},
    ...
  ],
  "events": [                          //事件列表
    {......},
    ...
  ],
  "actions": [                         //动作列表
    {......}, 
    ...
  ],
}

4.2.1 描述属性

以所有的智能台灯都需要的开关属性为例，这个属性只能有两种值：开 / 关。在TSL中可以如下表示：

{
  "identifier":"powerSwitch",   //属性的唯一id
  "name":"电源开关",      // 属性的名称
  "accessMode":"rw",     //属性的访问模式，r表示可读，w表示可写
  "required":true,    //是否是必须提供的属性，例如色温，并不是每个产品都提供的
  "dataType":{            //属性值的定义
    "type":"bool",    //属性值的类型
    "mapping":{
      "0":"关”,
      "1":"开"
    }
  }
}

4.2.2 描述事件

描述事件的方法和描述属性的方法大同小异。

{
  "identifier":"voltageLow",
  "name":"电压过低",
  "type":"alert",
  "required":false,
  "outputData":[
    {
      "identifier":"voltage",
      "name":"电压",
      "desc": "当前电压",
      "dataType":{
        "type":"int",
        "specs":{
          "min":"0",
          "max":"220"
        }
      }
    }
  ]
}

事件需要向物联网平台上报信息，因此需要 outputData。

5. 数据处理

进一步说说对数据的处理

在数据流的第三步，是数据存储。这一环节就在物联网中台中，涉及到了对数据的存储和处理：

5.1 数据存储

5.1.1 关系型数据库

采用关系型数据库来保存结构化数据。

优点：

• 容易实现数据的 CRUD；
• 容易实现数据的关联插叙；
• 支持事务管理，保证数据操作的 ACID 特性。

缺点：

• 传统的单机型关系型数据库难支撑物联网所产生的海量数据。

解决：

• 对数据库进行分库分表；
• 使用例如 redis 的数据库中间件实现数据库操作；
• 使用分布式关系型数据库，也就是 NewSQL 数据库。开源的 TiDB，CockroachDB，商业化的 OceanBase 等。

5.1.2 时序数据库

物联网中的一些数据具有很强的时间顺序，例如传感器上报的温度信息等。这些数据在读写、存储和分析处理方面有下面的这些特点：

1. 持续不断的写入，写入频率基本固定，数据基本不做更新；
2. 在业务中读取的频率很低，通常是进行数据分析时进行读取；
3. 时效性强，新数据价值高，就数据会迅速失去价值；
4. 旧数据被查询的概率不高，并且一般是按照时间范围的粗颗粒度的读取分析。

时序数据库最开始出现在工业应用中，在物联网中的也广泛使用。开源的 InfluxDB，KairousDB，OpenTSDB 等。

5.1.3 非关系型数据库

半结构化数据，采用非关系型数据库，也就是 NoSQL 来存储。

通常非关系型数据库都是采用键值对来存储，以记录的主键作为 key，value 则是各种各样的。

• 例如 MongoDB 中的 value 是类似 JSON 结构的数据，Redis 中的 value 可以有各种不同的类型。

通常，非关系数据库不强调数据的一致性，不支持事务操作，也不关注关联表查询。并且对数据格式没有固定的要求，便于扩展。

有 CouchDB，Redis，Cassandra，MongoDB 等。

5.1.4 分布式文件系统

非结构化数据，使用分布式文件系统。

• 典型的就是例如图片、音频、视频等数据。

这些数据完全不能按照结构化的方法来描述，也无法预定义数据模型。最出名的是 HDFS，其他的还有 FastDFS 和 Ceph 等。

重要参考：

• 简书：技术的翅膀