工业互联网：3 网络层（1）

3    网络层
3.1    工业物联网网络的选择
3.1.1    工业物联网数据的实时性
工业物联网的网络层实际上和互联网差异不大。这一点可能和出乎很多人的意料。这些人感到意外的原因，多半是因为从工业控制的角度出发，直觉上认为工业物联网必然也和工业控制一样，在通信和数据采集的过程中强调实时性，但是就目前和可预料的应用而言，行业技术人员在选择通信的电气形式和协议的时候，实时性并没有得到和在工业控制系统中的那样的地位，这是因为：
1、工业物联网的应用以管理和协同为主
远程联网的目的和出发点往往就不是为了实时的控制，而是更多的是为了多系统之间的协同工作。这两类目的本身对时间的延迟就缺乏过高的诉求，尤其是联网的另一端是人类的时候。即使毫秒甚至几秒的误差，对于另一端的人类做出的判断并没有本质上的影响。

这里面需要澄清的就是仿真。基于物联网的仿真和基于仿真的各种在线诊断应用，表面上看的确需要实时数据。但是很多时候，此类应用所需要的只是高频采集的时序数据，而这些数据是否在第一时间传递到云端并不是问题的关键。很多人之所以有这样的误解，更多是把数据采集的频率的高低和实时性混淆到了一起。在实际实现中，可以是这样：设备端以满足仿真和诊断的高采样频率将数据采集下来并存储在本地，然后以一定的策略间歇性地将本地缓存的数据压缩、打包后发到云端。发送的周期需要根据对仿真和诊断的结果反馈的速度的期望，以及云端计算的速度来调试以达到最优。这里提到了本地的数据压缩，实际上还有另一个层面的“压缩”就是数据的聚合。也就是，不是将设备本地采集到的数据机械地按照某个预定的压缩算法无差别地压缩，而是将采集到的数据就地

2、历史和使用习惯使然
这方面的确有一点自我证明的味道。就云端尤其是公有云而言，目前的技术在实时性上、时序性上，以及连接的可靠性上都比在工业现场的私有网络有一定的差距。所以历史遗留的系统中已经将需要实时数据的功能基本上已经留给了位域现场的工业控制系统，而不是放在云端。尤其是，这种需要实时反应的功能放在现场的工业控制系统上的部署成本往往也最低。既然已经形成了这样的格局，也就没有什么特别的理由非要移植到云端上。

3、安全和设备可用率上的考量
控制回路当中如果有云端的服务器，就可能因为网络不稳、黑客攻击等元婴造成联网设备的安全问题。这种安全问题可不是简单的设备数据的丢失，而是可能被非法控制而酿成大祸，甚至人身伤亡。而如果控制回路都在本地，和云端交流的只是部分数据，甚至这部分数据也是单向交流的，那么风险就小得多。同时，也不会造成因为设备没有联网就不能使用的情况。

4、减轻云端负载的压力
即便以上的问题都不存在，我们也没有什么必要把一些都放在云端。这对云端服务器的网络带宽和计算能力而言都是很大的负载。既然现场的设备上具有的计算能力已经可以解决这些问题，又何必要转移到云端呢？既然这种强调“边缘计算”的部署方式将实时数据相关的计算留在了本地，也就没有了为远程应用制定实施协议的需要了。

3.1.2    开发效率
开发效率的选择在先进的信息行业的技术决策的总要性越来越突出了。这主要是整个社会所能供给的计算能力已经多的超过了某个临界值：在这个临界值之内，计算能力的成本要超过开发过程的成本，属于更稀缺的资源；而超过了这个临界点之后，开发过程中的人力成本才是更为稀缺的资源。工业物联网也不例外。这是为什么工业物联网领域近年来诞生的标准化协议都偏爱采用已经在互联网领域成熟的技术，或者以此类成熟的技术为基础来构建。比如HTTP协议、XML和JSON等。这也是偏爱强调实时性的人们所“痛恨”的，不是么？

3.1.3    应用协议标准化
国际上和各国从事工业物联网协议标准化的组织层出不穷、由来已经。有些甚至出现在工业物联网概念出现之前。这是因为工业物联网这个概念实际上是应用拉动出来的，即：是现有相关应用，才逐渐形成一个抽象的、统一的概念的。

在智能电网领域，有IEEE指定的一系列相关标准。机床的联网有美国主导的MTConnect，并有望成为国际标准。OPC UA是一个更为广泛的应用协议，用于多种离散和流程制造业。MODBUS/TCP实际上是历史遗留的工业控制协议，但是因其简单的结构仍然被很多物联网系统高集成商使用，甚至很多物联网云平台提供其透传功能。其他的各领域的应用协议很多，这里就不一一列举了。

 

上一篇：工业物联网：2 设备端（4）

下一篇：工业物联网：3 网络层（2）