雾里看花——工业物联网(IIoT)

工业物联网(IIoT)正在从概念逐渐变成现实。廉价传感器, 从数据到云端, 以及在浏览器上的仪表盘可以看到更细致和更现实的模型,仿若无处不在。 一些文章通过对雾或边缘计算的讨论也探讨了这一趋势[1]。 这是一个很好的开始,但并不完整。 成熟的 IIoT 系统也将包括雾计算,这是一种接近传感器的计算方法, 超出了通常认为的雾计算。 在任何给定的应用程序中, IIoT的部署可能包括这些概念的混合, 包括雾云、雾雾和雾雾云等等。 随着在微控制器、芯片系统和低成本通信能力的不断提高, 薄雾计算将成为数百万解决方案的重要组成部分。

丢失的遥控器

有一则电视广告显示, 一家人争先恐后地寻找电视遥控器。 在这一情景下, 一个家人使用亚马逊的 Alexa 选择了正确的频道。 处理请求并将命令发送到 Dish TV Hopper。 没过多久, 这家人就安顿下来看电视了, 遥控器仿佛被遗忘了。

处理电视控制所花的时间可能比找到错误的遥控器所需要的时间要快(特别是如果狗把遥控器带到另一个房间的话)。 这是好事, 但是如果核电站以这种方式控制呢? 化工厂的空中交通管制系统或紧急警报系统会是这样吗?

这个例子说明了物联网至少分裂成两个主要模型: 消费者模型和工业模型。 消费者模式通常包括数据集中化, 然后在云中进行决策。 这是一个完美的模式, 提供免费或低成本的功能或服务, 在这些服务中收集的大量数据可以通过其他方式实现货币化。 典型的例子是谷歌, 搜索或电子邮件是免费提供的, 但所收集的数据在广告服务中被货币化呈现。 还有些不太明显的例子, 比如智能电表。 计价器在你的房间里, 但是数据是集中收集的, 用户只能通过一个经过精心设计的公用网站才能访问。 多数数据被公用事业用于其他目的, 主要是降低成本、需求响应、故障诊断和系统规划(图1)。

图1 | 工业物联网与消费者物联网的对比

IIoT的不同点

在 IIoT 应用中还有其他的考量: 控制循环中的延迟, 决策过程中涉及的一系列元素, 数据传输和存储成本, 以及敏感操作数据的安全性等等。

为了缓解这些矛盾, ARM、 Cisco、 Intel、 Microsoft 和其他公司已经提出了将边缘计算作为一种替代方案。 在这里, 一个边缘设备或一组边缘设备包含业务逻辑, 可以在本地或区域内作出决策, 而不需要参考或与中心核心合作。 这个概念通常被称为雾计算, 它注意到了分散的性质, 并将它与集中的云服务区分开来。 雾计算可能涉及一个单边设备或多个边缘设备一起操作。 有许多组合, 大多数示例将与云资源一起工作(图2)。

图2 | IIoT 架构中雾、薄雾和云计算之间的关系。最常见的无线连接与手持和网络人机界面(HMI)一起被识别出来。

然而, 还有另一个重要的因素。 通过收集所有的传感器数据, 有可能以相关和不相关的数据混合来压垮系统。 系统收到了如此多的数据, 以至于很难弄清楚该如何处理。 这与飞行员在飞机驾驶舱或者医院重症监护室的医务人员所遭受的"惊恐疲劳"问题相似。

更好的方法是从传感器数据中获取智能, 只将情报传送到决策系统(雾或云)。 在理想情况下, 智能是靠近传感器的, 而不是在边缘或云计算的位置。 这个概念被称为薄雾(mist)计算(图3)。

图3 | 数据, 智能 和洞察力。 传感器数据与雾计算资源共享,派生的智能传递给薄雾计算资源。 只有基本的智能和 / 或数据被发送到云端。

这一想法是使用低成本的微控制器来做更多的事情, 而不仅仅是数据转换和简单的通信。 处理能力被用来观察来自多个传感器的数据流, 并得出结论或复杂的见解。 同时,也可以观察传感器本身的状况。 这种方法可能会使系统进一步了解该地点正在发生的情况或协助维修周期。

传感器平台进行助力

幸运的是, 像 cratus / fujitsu BlueBrain 系统这样的传感器平台, 以及像 ARM Cortex 系列这样强大的微控制器家族, 使得这种方法经济而直接。 这样的平台包含了传感器、 i / o、计算资源、通信和开发资源的组合, 使得为个别问题或应用解决方案的原型变得更加容易。 如果所需的体积很小, 传感器平台可以作为最终的解决方案。 如果体积很大, 则可以通过降低平台硬件和软件的成本来精心设计一个自定义设计(图4)。