【物联网】工业物联网参考体系架构设计

产业智能官：工业互联网火热开建，工业物联网是其核心骨架，也是实现CPS的必由之路。本文试图揭示工业物联网技术架构的神秘面纱。推荐工业互联网架构师、产品经理重点阅读。参考资料部分源于网络，由产业智能官翻译整理，仅供参考研究学习使用。

工业物联网参考体系架构

1。介绍

物联网包括多个不同类别“物”之相链接:
•无线传感器/执行器
•联网 可穿戴设备
•低功耗嵌入式系统
•rfid启用跟踪
•使用手机与现实世界进行交互(如感应)
•设备通过蓝牙手机连接到互联网
•智能家居
•车联网

目前为止，还没有一个架构能满足所有这些领域的需求。譬如,模块化可扩展的体系结构、支持添加或删减功能插件的能力,以及支持在各种各样设备。当架构师创建物联网解决方案的时候，这些需求是有用和有价值的，它提供了一个基础起点。

本文提出了这样的物联网参考体系结构。物联网参考体系结构必须涵盖多个方面，包括：

• 云或服务器端架构, 允许我们对物联网设备做监视、管理、互动和处理数据;

• 通信网络模型设备;

• 本地设备软件代理代码；

• 要求什么样的设备可以支持这个参考体系结构。

2 。物联网概述

物联网：是指一组互连的设备和系统 ，实体 传感器和执行器网络。包括许多不同的系统 ：

•互联网连接汽车 （车联网）;

•可穿戴设备 ：健康和健身监控设备,手表,甚至人类植入设备（智慧医疗）;
•智能电表和智能物品（智慧能源）;
•家庭自动化系统和照明控制（智能家居）;

•智能手机越来越多地用来测量他们周围的世界；
•无线传感器网络测量天气,洪水防御,潮汐和更多（智慧城市）。

产生和收集数据的设备数量、种类难以置信的快速增长。一项由Cisco的调查估计，在2010年网络设备的数量超过了人口,2020年将有500亿联网设备。 物联网有三个关键层面:

1. 设备本身

2. 服务器端架构

3. 网关(在许多情况下,可能是一个低功率网关执行聚合、事件处理、设备之间的连接等等)。

实际上有三类设备:

1. 最小的嵌入式8位SOC控制器设备。一个很好的例子是开源硬件平台Arduino：Arduino Uno平台和其他8位Arduino  。这些通常没有操作系统。

2. 系统基于非 常有限的32位的Atheros 和ARM芯片架构。这些设备通常包括家里的路由器及其衍生品。通常,这些运行一个精简版或嵌入式Linux平台,如OpenWRT或专用的嵌入式操作系统。在某些情况下他们可能不使用一个操作系统,如ArduinoZero,或ArduinoYUN。

3. 最"能干"的物联网平台是32位或64位的计算平台。如Raspberry Pi 和 BeagleBone,这些系统可以运行一个完整的Linux操作系统 或其他合适的操作系统。

设备之间和互联网或网关的通信包括许多不同的模型:(稍后我们将看看协议)

• 使用TCP或UDP的以太网或WIFI的直接连接

• 低能量蓝牙

• 近场通信 (NFC)

• Zigbee或其他广播网络

• SRF和点对点无线 联系

• uart或串行线

• spi 或I2C链接总线

  
  

下面的图1说明了连接的两种主要模式

本节提供了一个简短的物联网设备和系统的概述, 讨论需求和功能以提供足够的背景支持。

2.1 有价值的物联网参考体系结构

一个物联网参考体系结构带来以下好处 :

•物联网设备本质上是连接 , 我们需要一种方式与他们相联系 ,但是 经常遇到的障碍是防火墙、网络地址转换 (NAT) 和其他障碍。

•有数十亿的这些设备已经和数量增长迅速 , 我们需要一个可伸缩性架构。此外 , 这些设备通常是 24 x7 互动 , 所以我们需要高可用性 (HA) 的方法 , 支持跨数据中心部署 , 可灾难恢复 (DR) 。

•设备可能没有 ui 使用 , 所以我们需要支持自动更新和管理 , 以及能够远程管理这些设备。

•物联网设备用以收集和分析数据。管理物联网设备的身份和访问控制以及数据的发布和消费是关键要求。

我们的目标是提供一个架构用以支持系统和设备之间的集成。 在下一节中 , 我们将深入研究这些需求。

3。参考体系架构要求

参考体系结构的要求： 整个需求我们可以总结成一些关键点 :

•连接和沟通

•设备管理

•数据收集、分析和驱动

•可伸缩性

•安全

•高可用性

•集成

•预测分析

3.1 连接和通信

现有的协议 , 比如 HTTP 在许多设备中占有非常重要的地位。甚至一个 8 位控制器可以创建简单的 HTTP GET 和 POST 请求。然而 ,http 和其他一些传统的网络协议会产生很大的“开销”问题。

• 可以驻留在小型设备上程序的内存大小是一个问题。

• 然而 , 更大的问题是电力需求，为了满足这些需求 , 我们需要一个简单的 二进制协议。

• 需要跨防火墙的能力。

• 直接连接或通过网关连接设备，通过网关连接的设备可能需要两个协议 : 一个连接到网关 , 然后另一个是从网关到云。

• 架构支持传输和协议的桥接 , 例如我们可能希望提供一个二进制协议的设备 , 但允许一个基于 http 的 API 来控制设备 ,以便 我们向第三方公开。

3.2 设备管理

物联网设备管理的要求是什么 ? 下面的列表涵盖了一些广泛的需求

•被盗设备断开连接的能力

•能够在设备上更新软件

•更新安全凭据

•远程启用或禁用某些硬件功能

•定位丢失的设备

•从被盗设备擦拭安全数据

•远程重置 wi - fi 、 gprs 或网络参数

3.3 数据收集、分析和驱动

一些物联网设备有某种形式的 UI, 但总的来说物联网设备的重点是有一个或多个传感器 , 一个或多个驱动器 , 或以上两者的结合。系统的需求是我们可以从大量设备收集数据 , 存储它 , 分析它 , 然后采取行动。

参考体系结构是用来管理非常大量的设备。如果这些设备创建恒流的数据 , 那么这就产生了大量的数据。要求高度可伸缩的存储系统用以处理不同和大量的数据。

近乎实时的动作可能发生 , 所以有很强的实时分析要求。此外 , 该设备必须能够分析和操作数据。在某些情况下 , 这将是简单的嵌入式逻辑，譬如边缘计算。更强大的设备上我们也可以利用更强大的引擎来处理事件和采取行动，譬如雾计算和云计算。

3.4 可伸缩性

任何服务器端具有可伸缩性将是理想的架构 , 并且能够用于支持数以百万计的设备不断发送、接收数据。然而 , 许多“高扩展性的架构”有一个同样高价格——无论是在硬件 , 软件 , 和复杂性。这种架构的一个重要需求是支持从一个小型部署到扩展大量的设备。弹性可伸缩性和部署在云基础设施的能力是至关重要的。

3.5 安全

物联网的安全是最重要的一个方面。物联网设备经常收集高度私有化数据 , 从本质上把现实世界带到互联网上 ( 反之亦然 ) 。这有三个类别的风险 :

•在任何网络系统固有的风险 , 但这产品 / 物联网设计师可能不知道的

•独一无二的物联网设备的特定风险

•安全 , 确保没有造成伤害 , 例如 , 滥用致动器

第一类简单 , 比如锁定设备上的开放端口 ( 比如 Internet-attached 有一个无担保 SMTP 服务器，被用于发送垃圾邮件 ) 。 第二类包括物联网硬件相关的问题 , 如设备可能有其信息阅读安全。例如 , 许多物联网设备太小 , 不足以支持适当的非对称加密。另一个具体的例子是硬件理解别人攻击的能力。 有两个非常重要的具体问题：担忧物联网安全的身份和访问管理。身份这个问题 , 例如 设备的用户 id / 密码和机器对机器 (M2M) 使用清晰文本 / Base64 编码是一种常见的错误。在理想情况下 , 这些应该替换为可管理的令牌如 OAuth /OAuth24 。 另一个常见的问题是到客户端或服务器端访问管理规则代码的硬编码。一个更加灵活和强大的方法是利用模型如“基于属性的访问控制”和“基于策略的访问控制”。其中最广为人知的方法是 XACML standard5 。这样的方法逻辑访问控制决策时去除硬编码，具体标准 如下：

•更强大的和适当的决定 ;

•可以根据上下文等位置 , 或使用网络 , 或一天的时间 , 可以分析

•访问控制和审计 ;

•政策可以更新和改变 , 甚至动态 , 无需重新编码或修改设备。

因此我们的安全需求应该支持 :

•设备足够强大的加密 ;

•现代基于令牌的身份模型 , 而不是用户 id / 密码 ;

•尽可能顺利 / 远程管理密钥和令牌 ;

•基于策略和基于 XACML 的用户管理的访问控制系统

以上总结是我们已确定的参考体系结构。当然 , 任何给定的架构可能会进一步有其他要求。其中的一些可能已经见过 , 一些可能需要进一步添加组件。然而 , 我们的设计是一个模块化的体系结构 , 支持扩展 , 应对这一需求。

4. 体系结构

参考体系结构由一组组件构成。“层级”可以通过特定的技术实现 , 我们将讨论为每个组件实现的选项。也有一些横向 / 垂直层如访问 / 身份管理。

“层级”：

•客户机 / 外部通信层： Web 门户 , 仪表板 ,api

•事件处理和分析层 ( 包括数据存储 )

•聚合 / 总线层： ESB 和 message broker

•相关传输层： MQTT / HTTP /XMPP / CoAP / AMQP, 等

•设备层

“ 交叉层 ”：

•设备管理器

•身份和访问管理

4.1 设备层

架构的底层是设备层。设备可以是各种类型 , 作为物联网设备 , 他们必定有一些交流 , 间接或直接连接到互联网。

直接连接的例子：

• Arduino 和 Arduino 的以太网连接

• Arduino Yun 通过 wi-fi 连接

• Raspberry Pi 通过以太网或 wi - fi 连接

• Intel Galileo 通过以太网或 wi - fi 连接

间接连接设备的例子包括：

• ZigBee 设备通过 ZigBee 网关

•通过手机连接蓝牙或蓝牙低耗能设备

•通过低功率无线电设备与 RaspberryPi 交流

每个设备通常需要一个身份。身份可能是下列之一 :

•写入设备的一个惟一的标识符 (UUID)( 通常是芯片系统的一部分 , 或第二个芯片提供 )

•提供的 uuid 广播子系统 ( 例如蓝牙标识符 ,wi-fi mac 地址 )

• OAuth2 更新 / 无记名令牌

•存储在非易失存储器（譬如 EEPROM ）中的一个标识符

我们推荐的参考体系结构 , 每个设备都有一个 UUID( 最好是一个不变的核心硬件提供的 ID) 以及存储在 EEPROM 中的 OAuth2 更新和无记名令牌。

4.2 通信层

通信层支持连接的设备。在设备和云之间有多个潜在协议通信。最著名的三个潜在的协议：

• HTTP/HTTPS ( 通过这些的 RESTful )

• MQTT 3.1/3.1.1

• CoAP

我们选择的参考体系结构选择 MQTT 作为首选设备通信协议 ,HTTP 作为替代选择。

在这个阶段选择 MQTT 而不是 CoAP 的原因：

•采用更好和更广泛的 MQTT 库支持 ;

•简化连接到现有的事件收集和事件处理系统 ;

•在防火墙和 nat 网络简单连接

然而 , 这两个协议的有特定的优势和弱点 , 所以会有一些情况 CoAP 可能更好 , 可以交换。

为了支持 MQTT 我们需要 MQTT 代理的体系结构以及设备库。我们将围绕着安全性和可伸缩性讨论。 物联网设备的一个重要方面是不仅对设备发送数据到云 / 服务器 , 反之亦然。这是 mqtt 规范的好处之一 : 因为它是一个代理模式 , 客户机连接到代理、设备是否作为一个出版商或用户。这通常可以避免防火墙问题 , 因为这个方法可以在防火墙或通过 nat 工作。

一般的情况下传递的主要信息是基于 HTTP, 发送数据到设备的传统方法是使用 HTTP 轮询。这是非常低效和昂贵的 , 无论是网络流量以及电力需求。现代替代这个 WebSocket 协议，允许 HTTP 连接被升级成一个完整的双向连接。这作为一个套接字通道 ( 类似于一个纯粹的 TCP 通道 ) 在服务器和客户端之间。一旦建立 , 由系统在连接隧道选择一个正在进行的协议。 我们再次推荐用 WebSockets 的 MQTT 协议的参考体系结构。在某些情况下 ,MQTT WebSockets 将是唯一协议。这是因为它是比基础 mqtt 规范有更好的防火墙友好性以及支持纯浏览器 / JavaScript 客户端使用相同的协议。

注意 , 虽然有一些支持 WebSockets 小型控制器 , 如 Arduino 。 HTTP 和 WebSockets会 占用 Arduino 8 位的装置可用的有限的代码空间，因此 , 我们建议较大的 32 位设备上使用 WebSockets 。

4.3 聚合 / 总线层

体系结构的一个重要的层是聚合和代理沟通层。这是一个重要的层有三个原因 :

1 。能够支持与设备 HTTP 服务器和 / 或 MQTT 代理 ;

2 。聚合和组合来自不同的设备和通信路由到一个特定的设备 ( 可能是通过一个网关 )

3 桥和不同协议之间的转换 , 例如提供基于 HTTP 的 api 到设备的 MQTT 消息

聚合 / 总线层提供了这些功能 , 以及适应遗留协议。总线层也可能提供一些简单的相关性和从不同的相关性模型的映射 ( 如设备 ID 映射成一个所有者的 ID 或者相反 )。 最后聚合 / 总线层需要执行两个关键的安全角色。它必须能够充当 OAuth2 资源服务器 ( 不记名令牌验证和相关资源访问范围 ) 。它还必须能够充当策略执行点 (PEP)， 基于策略的访问。在这个模型中 , 总线请求身份和访问管理层，验证访问请求。在这个过程中身份和访问管理层充当策略决策点 (PDP) 。然后总线层实现这些调用 PDP 的结果，要么允许或不允许资源访问。

4.4 事件处理和分析层

这一层需要事件总线和提供这些事件过程和行动的能力。核心能力是需要将数据存储到一个数据库中。这可能发生在三种形式。

1、 这里的传统模式是编写服务端应用程序 , 例如 , 这可能是一个支持数据库的 jax - rs 应用程序。然而 , 有很多更多的敏捷方法我们可以支持。

2、 使用大数据分析平台。这个需要 cloud-scalable 平台支持技术 , 例如 Apache Hadoop 提供来自于设备上高度可伸缩的 mapreduce 分析数据。

3、 基于从设备和其余系统来的数据，支持复杂事件处理启动实时活动和行动。

我们推荐使用以下方法 :

•高度可伸缩的、基于列的数据库来存储事件

•长周期面向批量的处理数据

•基于设备和其他系统的数据和活动，内存中快速处理复杂事件、实时反应和自主行动，

•此外 , 有一层可能支持传统应用程序处理 , 比如 java bean,jax - rs 逻辑 , 消息驱动 bean, 或替代品 , 如 node.js 、 php 、 Ruby 或 Python 。

4.5 客户端 / 外部通信层

参考体系结构需要为这些设备提供了一种与外部系统交流的方法 。这包括三个主要方法：

首先 , 我们需要创建基于 web 前端和门户的能力，与设备交互和事件处理层。

其次 , 我们需要创建仪表板提供视图的能力，分析和事件处理。

最后 , 我们需要能够与系统外的网络通信 (api) 。在 API 管理系统中，这些 API 可以被管理和控制。

构建的 web 前端推荐的方法是利用模块化的前端架构 , 如门户 , 它允许简单的快速合成有用的 ui 。当然架构还支持现有的 Web 服务器端技术 , 比如 Java servlet / JSP 、 PHP 、 Python 、 Ruby, 等等。我们推荐的方法是基于 Java 的框架和最流行的基于 Java 的 Web 服务器 ,Apache Tomcat 。

仪表板是一个可重用的系统，专注于来自于设备和事件处理层的数据来创建图表和其他可视化。

API 的管理层提供了三个主要功能 :

•首先 , 谈到面向开发者它提供了一个云门户 , 开发人员可以从系统和订阅 api 发现 , 探索。也支持"出版商"创建版本、 管理提供和发布 api;

•第二个是管理访问 api, 执行访问控制检查 ( 外部请求 ) 以及基于政策的节流式使用。它还执行路由和负载平衡 ;

•最后一个方面是 , 网关发布数据分析层 , 存储以及处理、洞察如何使用这些 api 。

4.6 设备管理

设备管理 (DM) 是由两部分组成。

• 服务器端系统 ( 设备管理 ) 与通过各种协议通信提供了单个和批量设备控制。它还远程将软件和应用程序部署在设备上。它可以锁和 / 或必要时擦拭设备。设备管理器与设备管理代理一同工作。不同的平台和设备类型有多个不同的代理。

• 设备管理器还需要维护设备的标识列表和映射这些设备的主人即所有者。它还必须联合身份和访问管理层来管理控制设备访问 ( 如设备除了老板谁还可以管理 , 怎么做所有者和管理员的控制权 , 等等 ) 。

有三个级别的设备 : 非受管、半受管、全面管理 (NN 、 SM 、 FM) 。

全面管理设备运行一个完整的 DM 代理。一个完整的 DM 代理支持 :

•管理设备上的软件

•启用 / 禁用设备的功能 ( 如照相机、硬件等 )

•管理安全控制和标识符

•监测设备的可用性

•保持记录设备的位置

•锁定或擦拭设备 , 如果设备损坏 , 等等。

半受管理设备是那些实现 DM 的某些部分功能 ( 如功能控制 , 但不是软件管理 ) 。

非受管设备没有代理 DM ，可以与其他网络通信。这些可能包括 8 位设备的空间太小不足以支持代理程序。设备管理器可能仍然保持设备的可用性和位置信息。

4.7 身份和访问管理

最后一层是身份和访问管理层。这一层需要提供以下服务 :

• oauth2 令牌发放和验证

•其他身份服务包括 SAML2 SSO 和 OpenID 连接，支持识别从 Web 层的入站请求

• xacml PDP

•用户目录 ( 例如 LDAP)

•访问控制策略管理 ( 策略控制点 )

当然对于一个给定的实例化的参考体系结构，身份层可能有其他需求。在本节中 , 我们列出了参考体系结构的主要组件以及我们在技术上的具体决定。这些决策的动机是构建灵活、可发展的、可伸缩的网络架构要求以及最佳实践。

5 。映射到 AI-CPS 平台

参考体系结构是非常有用的。然而 , 如果有一个真正的实例化它将更加有效。在本节中 , 我们提供了一个映射到 AI-CPS 平台来展示可以实现的产品和功能的参考体系结构。

AI-CPS 平台是一个完全模块化的企业平台 , 提供所需的所有功能的服务器端架构。此外 , 我们还提供一些设备层参考组件——提供组件的所有可能的设备这是一个棘手的问题 , 但是我们对于某些流行的设备类型提供的示例代码和 / 或支持代码。

AI-CPS 平台的一个重要方面是它本身是多租户的。这意味着它可以在一个部署就支持多个互相隔离的组织 ( 租户 ) 。这是一个关键的功能部署以实现参考体系结构的软件即服务 (SaaS) 。也被一些组织内部用来支持一组内不同部门。

AI-CPS 平台支持部署在三个不同的目标 :

1 。传统的本地服务器包括 Linux 、 Windows 、 Solaris 和 AIX

2 。公共云部署包括 Amazon EC2, 微软 Azure ，阿里云，腾讯云和华为云

3 。混合或私有云部署平台包括自建 OpenStack私有云和阿里、青云混合云

AI-CPS 平台是基于称为 Carbon 技术 , 进而基于 OSGi 。每个产品在平台基于相同的 Carbon 内核。此外 , 每个产品提供所需的功能、所需的特性可以加减。所有产品一起使用标准的互操作协议 , 比如 HTTP 、 MQTT AMQP 。下图显示了物联网的 AI-CPS 产品功能与相应的参考体系结构分层。

设备层

我们支持任何设备。我们有一个在任何基于 Linux 或基于 android 系统的设备的设备管理能力参考，可以移植到其他 32 位平台。 AI-CPS 还可以帮助提供许多从 Arduino 到 Android 设备平台的 MQTT 客户机代码，。

聚合 / 总线层

我们提供两个核心产品 , 实现这一层 :

• AI-CPS 企业服务总线 (Enterprise Service BUS,ESB), 它提供了H TTP,MQTT,AMQP 和其他协议支持 ,是 协议的中介和桥梁 , 数据转换 ,OAuth2 资源服务器支持 XACML 策略执行点 (PEP) 支持和许多其他功能。 AI-CPS ESB 高度可伸缩提供线性可伸缩性和弹性可伸缩性。一个部署处理超过 20 亿 / 天的请求。

• AI-CPS MessageBroker(MB), 它提供了作为 MQTT 代理的能力。 AI-CPS MB 还提供了 AMQP 功能 , 可以提供持久化的消息。 AI-CPS MB 支持高度可伸缩的弹性。

分析和事件处理层

通过 AI-CPS 数据分析服务器 ( AI-CPS das) 提供了一个完整的分析平台，首先在一个行业分析静态和动态的数据做预测分析。无论是运行本地还是在云端， AI-CPS 的分析平台提供了灵活地扩展，到每秒数以百万计的事件处理。

外部通信层

映射为这一层的功能提供以下产品 :

AI-CPS User Engagement Server (UES)

•本产品支持创建、管理门户或传统的Web ui，包括支持完整的个性化。

•DAS来管理和使用的主机分析仪表盘

AI-CPS APIManager

•管理 API 的生命周期 , 支持 API 出版商 ;

•面向开发者提供了开发人员发现、探索和订阅 API 的一个云门户 ;

•管理 OAuth2 外部开发者令牌 ;

•网关外部请求和提供节流和 PEP 功能 ;

•发布使用 , 版本和为