当我们理解了网关，理解所谓智能设备就容易得多了。

如果一个网关仅连接了一个传统设备，我们甚至就可以将这个设备和网关的新的组合成为智能设备。

这些正是一些小型、廉价的工业网关被用于设备智能化的附加部件的情形。

对于原本已经具有了必要的硬件（如可连接网络层的网口）的传统数字化设备（如机床的数控系统），因为其本身就已经是一个计算设备，那么只要增加必要的软件就可以在其中实现网关的功能。

边缘计算


有一个很普遍的误解，就是认为物联网系统中既然数据主要向服务端汇聚，那么业务逻辑一定也都是在部署在服务端。

实际上并不是这样，一些业务逻辑实际上主要面对该网关管理的感知层的局部的几个设备，这几个设备之间的数据流转和相互协作，没有什么必要一定要通过服务端来实现。

比如：一个车间内除了机床还有一个可燃物报警器，当可燃物报警器报警的时候，需要机床必须停机以避免事故。
如果在这种情况下，报警信号要从服务端绕一圈再下发到各个机床，那么如果此时连接服务端的网络有问题，那么这个报警信号的作用可能因为时间延迟损失了应对时间，甚至因为网络问题干脆就丢了-这显然是不可接受的。

工业网关必须具有一定业务逻辑的就地处理能力，而这种能力又被称为边缘计算。

总的来说，边缘计算有以下作用：

  1. 确切而及时地响应就地业务逻辑。这一点前面已经说明。不同的业务场景的业务不同，有的工业网关甚至为此内置PLC常用的梯形图等逻辑编程工具，从而可以实现更加复杂的就地逻辑。而一些成熟的商用基础云服务平台，如亚马逊AWS云服务，所提供的面向物联网的边缘计算工具中也明确提供了相关的脚本编程和部署工具。
  2. 降低服务端计算和存储负载。这个很好理解，既然部分业务逻辑从服务端转移到设备端的网关上运行，服务器计算负载自然也就减轻了。有些情况下，甚至因为部分数据仅对就地业务逻辑有关而无需上传和存储在服务端，从而有而节省了服务端的存储压力。
  3. 降低网络层带宽需求。
  4. 数据安全和保密考量。有些数据本身比较敏感，不适合直接传输到部署在云端的服务端中。但是因为就地业务逻辑本身和云端有协同作用，所以还是需要将本地业务逻辑的一些较为宏观的运行状态和结果反馈给服务端-因为这些边缘计算的状态和结果没有暴露原始数据的细节，对数据安全和保密的需求就大大降低了
  5. 分布式存储。这一点和前面的情况有一定的差别，而时仅仅针对就地的数据的。一些情况下，就地数据的价值很稀薄，表现在仅仅是在偶然的情况下才对物联网系统中的其他组成部分有用。如系统在收集设备的运行状态，但仅仅在发生事故时才有必要分析事故前半小时之内的数据。如果这些数据一直在向服务端传输和存储，浪费的资源可能是巨大的。这种情况下可以选在在设备端存储足够可回溯的历史数据，但仅在设备故障时再选择向服务端发送，以便提黑部署在服务端的故障分析应用使用和作为系统的故障诊断知识库使用。

那么是不是计算负载应该追求尽可能地下放到边缘（工业网关或者智能设备）呢？回答是否定的。这主要有几方面的原因：

  1. 系统总成本控制。将计算负载过度下方到设备端可能会造成设备端的计算能力需求大幅度提升，而作为嵌入式设备，超过一定的计算负荷，如果再提升，其代价可能要远高于服务端。
  2. 算法的数据依赖性。有些数据分析过程，比如人工智能，为了拥有一个大样本来训练算法，也必须利用整个系统内的所有个体设备的数据，而这些数据及其分析程序也许只有部署在服务端才是可行。

由于边缘计算的兴起，在某些应用场景下物联网服务端变得很“薄”，甚至仅具有关键数据存储和子系统之间的沟通、监控作用，而这些存储于服务端的关键数据的组成可能是以设备端边缘计算得出的结果为主而不是以原始数据为主。

如一些基于区块链技术的分布式能源结算系统，所谓的中心主要负责接入设备的身份验证和用电量结算结果的存储，有关结算的大量非结算点的原始数据已经在设备端（智能电表）的边缘计算中随用随弃了。