云端采集器(如何解决这套系统具有什么优缺点呢？(二)(图))

　　云端采集器(如何解决这套系统具有什么优缺点呢？(二)(图))

　　文章目录

　　系统整体结构

　　本节主要介绍远程运维系统的典型功能和总体结构。

　　用户的故事

　　A公司是做螺栓连接技术的公司，他们生产的螺栓用于机械设备。这些螺栓的作用是加强设备，保证机器的稳定性。

　　这些螺栓用于大型设备。可想而知，这些设备的连接一定要稳固，否则就会松动，造成事故。但是如何监控螺栓的松紧度呢？安装时如何将螺栓拧紧到合适的水平？等等，这些都是问题。

　　所以客户在N年前就请人开发了一个监控系统：即一个采集器上安装了四个压力传感器，四个压力传感器放置在需要螺栓连接的设备连接处，用于监控采集器的拧紧程度。螺栓。采集

器定期采集

传感器数据并将其显示在自己的屏幕上。这样工作人员就可以实时查看采集器的数据，判断螺栓的拧紧程度。

　　到目前为止，您认为这个系统的优点和缺点是什么？

　　优点包括但不限于：简单、成本低。

　　主要缺点如下：

　　(1） 必须到现场才能看到采集到的数据

　　(2） 一定要主动检查采集

到的数据，判断是否是松散的

　　(3） 由于第二点，无法及时收到松动的消息

　　(4） 人工成本高

　　（5）无法计算出从安装螺栓到松开螺栓的螺栓拧紧度数据趋势，因此很难有针对性地提高螺栓质量。

　　(6） ....

　　客户在使用系统一段时间后也发现，如果继续使用系统，上述问题无法解决，痛苦还会持续。那么如何解决客户的痛点呢？

　　通过对比原系统，其实核心需求可以归纳为以下几个核心点：

　　（1） 不用去现场看数据，即无人值守工作

　　（2）可以通过浏览器、APP等远程查看设备的实时数据。

　　(3） 可以看到历史数据曲线

　　（4） 可以被动接收推送消息，无需轮询即可及时知道螺栓松动。

　　其他要求实际上是附加要求。

　　那么如何实现这些需求呢？

　　上诉分析 上诉 1

　　采集

器需要能够将传感器数据传输到云端，而不是简单地将其显示在屏幕上。在不改变采集器硬件的情况下，只能通过采集器现有的硬件接口连接新的传输设备。*敏*感*词*如图1.1：

　　

　　图1.1 采集*敏*感*词*

　　传输设备的作用是最终将设备数据传输到云端。其中，网关和节点都可以作为传输设备。两者最大的区别在于网关可以连接外部网络，也就是一般意义上的互联网，而节点只能与网关配合组成局域网。它们的通信是通过无线通信，这里用虚线表示。网络的层次结构如图1.2所示：

　　

　　图1.2 网络图

　　整体采集传输级*敏*感*词*如图1.3所示：

　　

　　图1.3 采集传输整体*敏*感*词*

　　图1.3 忽略连接到采集

器的传感器。节点负责将各个采集器的数据发送到中央网关，再由网关上报到云端，使数据最终能够存储到云端。

　　只有底层有了这样的采集和通信结构，才能将设备数据发布到云端，权利要求1才有实现的基础。

　　上诉 2

　　需要开发网页、APP等应用。这些应用程序从云端获取设备采集的实时数据并显示在页面上。

　　上诉 3

　　云端需要能够保存设备采集的所有数据，方便历史数据的查询。当然，应用程序还需要具备查询和显示历史数据的功能。

　　上诉 4

　　云需要能够建立推送机制，即当检测到某个螺栓传感器的数据满足触发条件时，例如当传感器2上报的值大于50时，用户可以自动通知。

　　这样，当数据满足推送条件时，用户就可以收到消息通知，比如报警消息，从而知道某个螺栓松动了。

　　追求关键概念实现关键点理解整体数据抽象

　　

　　图1.4 数据抽象

　　图1.4 显示了围绕数据打开了整体链接。原创

数据被采集，然后通过传输层并存储在云端。最终数据返回给客户，进行分析或汇总等，并展示给客户。

　　从这个数据抽象层面来看，图3中局域网中的采集层和传输层不必考虑其技术细节，只要通过底层硬件设备采集数据并传输到云端即可。

　　二手书店和图书馆的区别之一是图书馆是分门别类的。不同楼层的不同房间收录

不同类型的书籍。同一个房间也被书架细分。所有书籍都遵循一套编号规则，每本书都有自己唯一的编号。二手书店就不一样了。一堆书杂乱无章地堆放着，从中找书费时费力。

　　如果把书籍看成数据，那么云存储就不能向二手书店学习，而是向图书馆学习，所以图1.4将云存储标记为结构化存储（这种结构化的非数据库名词概念）。

　　下面，我们以数据为书，搭建我们自己的图书馆。

　　云“图书馆”

　　现在云库开通了，但是面对底层报出的这么多乱七八糟的数据，我们不得不遵循杭州电气库先进的管理方法。

　　我们首先定义每个数据的“唯一编号”。因为直接与云端交互的是网关设备，我们不考虑网关连接什么设备等一切。这也是分层解耦思想和单一职责原则的体现。因此，对于不同的网关，我们为它定义了一个唯一的ID，这里定义为deviceId，这样我们就可以区分哪些数据是哪个网关上传的。

　　但是在一个网关下可以采集多种数据，比如采集压力、湿度，或者采集四地温度信息，那么这些数据在云端上报时如何区分呢？

　　比如压力。随着时间的流逝，压力的数据呈现在我们面前的是一个“数据流”，就像无数水滴汇聚的河流。只是河流流经地球，数据流经时间。

　　再抽象一下，网关下还有很多这样的“数据流”。随着时间的推移，从我们云库的角度来看，网关下的数据分类是按照数据流向来区分的。因此，我们需要为数据流制定一个唯一的ID，我们将其命名为：streamId，stream的意思是水流，streamId是高端大气。

　　至此，一条数据流通过deviceId+streamId进行了唯一定位，以时间为参考坐标，我们云库中一条数据（点）的唯一编号为：deviceId+streamId+timestamp。

　　云“库”扩展功能的触发器

　　该库了解到，有客户想要开发触发功能，即通过监控某个数据流中的最新实时数据，在数据满足条件时触发逻辑，将当前情况通知客户。

　　经过不懈的努力，我们创造了“触发”系统。客户只需要简单配置，告诉我们他要监控的数据流（即deviceId+streamId），当数据值满足任何条件（比如大于或小于）时通知他。通知地址可以是电子邮件地址或客户通信地址。

　　这样，触发规则就配置好了。因为非常好用，很多客户制定了很多规则，这些规则太难管理了，只好重新编号，编码方式可以从1开始增加，代号叫“ruleId”，但是很容易混淆它。简单地称之为“triggerId”。触发器的意思是触发。

　　扩容云“库”

　　这么多有用的功能和清晰的结构，连接着越来越多的客户。那么有没有办法隔离每个客户的设备呢？

　　我们借鉴图书馆的房间分隔方式，确立了“产品”的概念。每个客户在这个大厅里可以创建多个产品，每个产品收录

多个网关（设备）。通过这种分层，库的最终结构如下：

　　扳机

　　由于触发器最终与某个数据流相关联，因此它与数据流处于同一级别。

　　基于这种分层方式，可以很好地实现对大量设备和数据的访问和管理。

　　呼吁实现重点理解平台化

　　每个人都想成为一个平台。例如，微信需要建立自己的生态和平台。图书馆也想建立自己的平台。平台不仅意味着可以访问设备，可以上报数据，还意味着需要开发者或相关公司入驻，才能在这个平台上进行开发。

　　基于这个考虑，库公开了一些开放的API接口，并提供了相关的demo和SDK包供大家使用。同时提供简单的设备等管理界面，客户可以在平台上查看自己的设备、数据等信息。

　　总之，这个平台的目的是让客户更容易开发物联网应用，专注于应用层的处理，不考虑网关接入、数据存储、触发等复杂问题。

　　平台化后，这个平台运行良好，我们有了一个响亮的名字：OneNET平台。

　　由于近两年物联网发展迅猛，所有传统企业都想结合物联网进行转型，各大企业也开始嫉妒物联网平台的巨大潜在价值. 最终，中国移动收购了我们的平台，所以我们最新的名字是“中国移动OneNET物联网平台”！

　　注意：以上图书馆故事纯属虚构。

　　再次注意：

　　OneNET平台地址