工业物联网参考体系架构设计
1。介绍
物联网包括多个不同类别“物”之相链接:
•无线传感器/执行器
•联网可穿戴设备
•低功耗嵌入式系统
•rfid启用跟踪
•使用手机与现实世界进行交互(如感应)
•设备通过蓝牙手机连接到互联网
•智能家居
•车联网
目前为止,还没有一个架构能满足所有这些领域的需求。譬如,模块化可扩展的体系结构、支持添加或删减功能插件的能力,以及支持在各种各样设备。当架构师创建物联网解决方案的时候,这些需求是有用和有价值的,它提供了一个基础起点。
本文提出了这样的物联网参考体系结构。物联网参考体系结构必须涵盖多个方面,包括:
· 云或服务器端架构,允许我们对物联网设备做监视、管理、互动和处理数据;
· 通信网络模型设备;
· 本地设备软件代理代码;
·要求什么样的设备可以支持这个参考体系结构。
2。物联网概述
物联网:是指一组互连的设备和系统,实体传感器和执行器网络。包括许多不同的系统:
•互联网连接汽车(车联网);
•可穿戴设备:健康和健身监控设备,手表,甚至人类植入设备(智慧医疗);
•智能电表和智能物品(智慧能源);
•家庭自动化系统和照明控制(智能家居);
•智能手机越来越多地用来测量他们周围的世界;
•无线传感器网络测量天气,洪水防御,潮汐和更多(智慧城市)。
产生和收集数据的设备数量、种类难以置信的快速增长。一项由Cisco的调查估计,在2010年网络设备的数量超过了人口,2020年将有500亿联网设备。物联网有三个关键层面:
a. 设备本身
b. 服务器端架构
c. 网关(在许多情况下,可能是一个低功率网关执行聚合、事件处理、设备之间的连接等等)。
实际上有三类设备:
a. 最小的嵌入式8位SOC控制器设备。一个很好的例子是开源硬件平台Arduino:Arduino Uno平台和其他8位Arduino 。这些通常没有操作系统。
b. 系统基于非常有限的32位的Atheros 和ARM芯片架构。这些设备通常包括家里的路由器及其衍生品。通常,这些运行一个精简版或嵌入式Linux平台,如OpenWRT或专用的嵌入式操作系统。在某些情况下他们可能不使用一个操作系统,如ArduinoZero,或ArduinoYUN。
c. 最"能干"的物联网平台是32位或64位的计算平台。如Raspberry Pi 和 BeagleBone,这些系统可以运行一个完整的Linux操作系统或其他合适的操作系统。
设备之间和互联网或网关的通信包括许多不同的模型:(稍后我们将看看协议)
·使用TCP或UDP的以太网或WIFI的直接连接
· 低能量蓝牙
· 近场通信(NFC)
·Zigbee或其他广播网络
·SRF和点对点无线联系
·uart或串行线
·spi 或I2C链接总线
下面的图1说明了连接的两种主要模式
图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.体系结构
参考体系结构由一组组件构成。“层级”可以通过特定的技术实现,我们将讨论为每个组件实现的选项。也有一些横向/垂直层如访问/身份管理。
图2
“层级”:
•客户机/外部通信层: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产品功能与相应的参考体系结构分层。
图3
设备层
我们支持任何设备。我们有一个在任何基于Linux或基于android系统的设备的设备管理能力参考,可以移植到其他32位平台。AI-CPS还可以帮助提供许多从Arduino到Android设备平台的MQTT客户机代码,。
聚合/总线层
我们提供两个核心产品,实现这一层:
•AI-CPS企业服务总线(Enterprise Service BUS,ESB),它提供了HTTP,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功能;
•发布使用,版本和为DAS提供其他数据;
•与AI-CPS ESB集成
设备管理层
AI-CPS Enterprise Mobility Management (EMM)提供:
•移动设备管理:iOS、Android和物联网设备
•一个完整的应用商店来管理设备上的应用程序和配置应用程序
•与身份层以及移动分析DAS集成
身份和访问管理层
AI-CPS身份认证服务器支持这方面,提供了以下功能:
•oauth2身份提供商、发布、撤销和管理令牌;
•单点登录支持包括SAML2 SSO和OpenID连接支持;
•支持其他身份协议包括ws -federation(被动),2.0OpenID,Kerberos,Windows集成验证(IWA),和其他
•完全支持XACML(包括版本2.0和3.0),作为一个 PDP, PIP, and PAP;
•不同的身份提供者和服务提供者之间的整合能力,包括身份代理
•支持身份配置SPML和SCIM。
AI-CPS是提供所有这些功能(以及更多)的模块化平台。因此它是创建和部署物联网的理想的参考体系基础结构。
另外一个非常值得考虑的方面是使用平台即服务(PaaS)。AI-CPS提供私有PaaS产品。提供了弹性可伸缩的管理和部署上述产品,譬如租赁管理,自助服务订阅和许多其他方面。它还支持许多其他有用的服务器端管理功能。
6。结论
在本文中,我们列出了以下几点:
•我们的物联网的定义是什么
•为什么参考体系结构是宝贵的
•参考体系结构需求
•实例化的参考体系结构,以及它如何满足这些需求
•参考体系结构映射到AI-CPS平台
工业物联网(互联网)市场空间正迅速发展,而我们希望本文和相关技术发展保持同步。尽管这是个新兴市场,本文参考体系结构是基于我们与客户部署支持物联网功能的实际项目。因此,我们有很大的信心,这是一个有用的,可部署,有效的参考体系结构。
相关新闻
版权声明
1、凡本网注明“来源:中国轻工业网” 的作品,版权均属于中国轻工业网,未经本网授权,任何单位及个人不得转载、摘编或以其它方式使用。已经本网授权使用作品的,应在授权范围内使用,并注明“来源:中国轻工业网”。违反上述声明者,本网将追究其相关法律责任。
2、凡本网注明 “来源:XXX(非中国轻工业网)” 的作品,均转载自其它媒体,转载目的在于信息之传播,并不代表本网赞同其观点和对其真实性负责。
3、如因作品内容、版权和其它问题需要同本网联系的,请于转载之日起30日内进行。