4 数据平台
为何会有物联网的数据平台呢？从某种程度上说，数据平台才是最具物联网特点的东西。虽然提到物联网，不少人脑海中第一个闪现的是传感网络，但实际上，若是你读过前几章就会发现，实际上所谓物联网，得到表征物体的数据是关键，而表征物体数据的获取办法不少，并不见得要另外加装传感网络——这一点在工业领域尤其明显。这是由于，由于工业领域自动化控制的需求，实际上不少关于机器的数据已经被获取了，只不过，这些数据暂时还局限在直接控制机器的控制系统中，没有被更大内涵的系统所用于更普遍的目的罢了。既然物联网的而核心在于表征物体的数据的使用，那么数据平台位于核心地位也就瓜熟蒂落了。算法
数据平台还有一个使其成为物联网核心商业模式和产品形态的潜质：数据平台是最容易产品化的。没错，虽然不一样的业务对数据的最终利用方式千差万别，而不一样行业现场对数据的采集获取手段也千差万别，可是数据的获取、存储和基本处理逻辑倒是惊人的类似。数据库
4.1 数据收发方式
在第1章中，咱们把数据分为如下几类，从平台的角度上看，其手法方式通常也不一样。
4.1.1 时序数据
时序数据是物联网数据平台的基本数据，也是物联网之区别于普通的面向人的联网应用的地方。时序数据的特色是，通常是均匀的数据流。也就是说，对于一个物体、设备，一旦开始发送数据，则通常是按照必定的采样周期发送的均匀、持续的数据。可是这并非说物联网就没有通常面向人的互联网那种数据峰值-估值的变化。就以工业互联网为例，由于多数工厂是白天工做，因此很明显白天的平常工做时间端，好比说从8点到18点之间，数据处于一个高位的平台，由于通常这个时候设备都在上电运行。可是这种高位相对难以出现尖峰，由于设备时序数据通常都是均匀采集并发送到平台的。可是这也形成了另一个问题：相似电网的峰谷差，咱们在构建数据平台的时候，计算能力和带宽也必须按照预测的峰值来设计。对于油气管道之类的物联网，这个数据峰谷差可能基本上是不存在的，由于油气、城市水网等系统是全天24小时都处于工做状态的，其相关的数据也一直在向平台提交，并且和水网、油气的负载没有关系。可是对于离散制造业，通常是白天你们都在加工，全部的机器都在提交数据，而晚上只有少部分工厂在轮班工做，才会提交数据。总之，在构建数据接收模块乃至整个服务端的时候，物联网系统所服务的业务和客户的特色须要加以考虑。缓存
时序数据在出现的时候通常是一个均匀的数据流。借鉴实时数据库的实现方式，咱们在接收过程当中要考虑数据在内存中的缓存，以防由于云端系统的算力问题丢失数据。所幸的是，目前大多数数据库都具备这种缓存能力。安全
另外须要注意的一点就是数据的重发。数据重发是数据平台和设备端之间的互动。当网络通道出现问题的时候，设备端可能会选择丢弃数据，但更好的实现方法也许是在就地存储未能发送到服务端的数据，并在网络信道畅通后集中发出。这样的策略虽然没法缓解数据的实时性所面临的挑战，但至少保证了数据在时间轴上的完整性。考虑到物联网服务端不少应用四基于统计和分析的，这种对数据完整性的保障常常是值得投资的，甚至是必须的。服务器
4.1.2 事件数据
相似设备告警等数据是偶发的，虽然也带有时间戳，可是其通常没有特别的规律。此类数据的接受对及时性和完整性都很是强调，由于一个没能及时收到或者干脆被丢失的报警数据多是致命的。固然也未必须要过分地追求，由于不少场合下并无那么糟糕：现场的自动化控制系统还有第一道防线。也正是如此，在设计自动化系统的时候，必需要注意不能由于有更上一个层次的物联网系统而有任何的疏忽；而将本来属于自动化系统的安全保障工做转移到物联网系统中，更是不可原谅的错误。网络
4.1.3 指令数据
指令数据主要是从服务器发送到设备的。可能并不带时间戳，可是建议最好是带有，由于有时指令的有效性和时间可能有关系：互联网并无保证数据包按照你预想的次序到达的能力，若是你的应用中很强调这一点就要本身创建识别指令次序或指令发出的时间的机制，以便抛弃过时的指令，或者按照正确的次序来执行指令。架构
4.1.4 文件数据
文件类数据是双向的，可是通常不强调及时性。只要文件被完整无误地传递便可。FTP等现成的协议不少，因此此类数据通常并不须要过多关注。可是不管如何，“无误”仍是要关注的，起码的校验，如MD5，仍是有必要的。并发
4.1.5 媒体数据
实际上为了配合组建完整的业务平台，有时还要加上媒体数据。主要是视频、音频的采集。此类数据，尤为是视频数据，实际上已经有很完善的解决方案。可是以前通常是在安防等领域应用的，并不太被理解为物联网数据。可是最近几年，随着AI识别等技术的应用，从视频图像中自动识别设备状态也成为一项设备故障诊断技术，因此此类数据也开始和物联网平台发生关联。好比某数控机床厂商开发的关于断刀的在线诊断，就是在加工中心中附加一个摄像头采集实时视频上传到服务器，由服务器判断是否发生了刀具断裂的事故。一旦系统断定发生断刀，会当即向加工中心发送停机指令以防止故障影响的进一步扩大。工具
4.2 数据存储
固然是采用各类数据库来实现。此时的选项其实不少。不管是SQL类关系型数据库仍是NoSQL类菲关系型数据库都有本身的用武之地。典型的状况是将两者结合，两个数据库分别存储不一样的数据类型，以期达到整个系统的最优化。物联网业务目前在各种企业中都还处于较新的业务，因此不肯定性较大，数据库内部架构也可能会所以发生持续的调整。所以在设计关系型数据库表结构的时候要有必定的预见性，或者采用某些对此类情景有设计考量的数据库。优化
4.3 数据模型
为何要提到数据模型？主要是咱们要考虑到进一步的数据整合、交换和业务开发的过程。实际上数据模型在非物联网业务中已经开始了应用，由于你们都在力图寻找一种能够对不断变化的业务具备必定自适应能力的系统。而一个具备必定自解释能力的数据模型对开发普适的数据处理工具相当重要。以制造业为例，OPC UA协议就包含了一个能够自定义数据模型的机制，可是遗憾的是其并无为各行业提供标准或者流行的模型。这种模型通常是某个企业、行业协会甚至国家标准组织来定义并在必定范围内执行的。而MTConnect协议则自带了一个建议的标准的机床模型，使得开发机床联网系统的时候，作一个能够对接不一样厂商的机床的系统成为一种可能。
数据模型方面的工做迄今为止仍是须要各行业不断努力去完善。
4.4 数据整合
数据整合的发起者其实是上层的应用平台的各种业务逻辑，虽然人们由于这个过程叫作数据整个而将其归为数据平台。固然，这么作的缘由也由于数据整合虽然与具体的业务逻辑息息相关，但其实是能够抽象为各类可配置的算法和自动触发的服务的。市场上这种面向开开发者的物联网平台，其核心技术之一，若是不是最核心的技术的话，就是各类数据自动处理的引擎。这些引擎有的能够在人机界面上进行配置，相似工业自动化中普遍使用的组态软件，也有的只是一系列的API，须要采用某种开发语言去调用。然后一种状况下，开发者每每会在应用平台为数据整合提供一个本身定义的配置界面。
4.5 数据平台的计费
较早出现的数据平台通常采起虚拟机销售的方式。因此其实是按照虚拟机的配置来收费的。虚拟机上的服务不管你是否使用、使用的量如何，并不影响费用的计算。而随着可配置化的数据整合引擎的出现和各种功能的服务化，愈来愈多的物联网平台开始采用按照服务收费的，更加细的粒度的收费模式。
4.6 数据平台案例
实际上，不少互联网背景的物联网平台基本上都是数据平台模式。如Amazon的AWS云。国内一些电信运营商的物联网平台，如中国移动的OneNET也是。此类业务的运营主体的特色是自身并无可最终交付的物联网业务，可是具备网络带宽、计算能力等资源，另外业务层面追求规模，因此通常会走这条道路，也每每只能走这条道路。
上一篇：工业物联网：3 网络层（2）
下一篇：工业物联网：5 业务平台