2. 工业物联网体系架构

工业物联网（IIoT）体系架构是构建从物理世界到数字世界的完整链路。理解其分层模型，是进行网关开发、系统集成与项目交付的前提。本章将深入剖析感知层、网络层、平台层、应用层的职责边界与交互逻辑，并重点定位工业网关在其中的枢纽位置，明确其作为“数据关口”与“边缘大脑”的核心职责。

上图展示了工业物联网的四层标准架构。感知层负责数据采集，网络层负责数据传输，平台层负责数据汇聚与处理，应用层负责数据消费与决策。而工业网关横跨网络层与感知层边界，向下连接异构设备，向上接入多种网络，是唯一同时处理“南向设备协议”与“北向网络协议”的物理节点。理解这一位置，是后续开发网关功能模块的基础。

2.1 四层架构的核心原理与职责边界

2.1.1 感知层：数据产生的源头

感知层是IIoT的“五官”，由各类工业现场设备构成。它不仅包含传统的传感器（温度、压力、振动、流量），还包括PLC（可编程逻辑控制器）、变频器、伺服驱动器、机器人控制器、智能电表、视觉相机等具有数据输出能力的智能设备。这些设备通过RS-485、RS-232、CAN、以太网、IO-Link等物理接口输出数据。

感知层的核心挑战在于协议碎片化。Modbus RTU/TCP、PROFINET、EtherNet/IP、EtherCAT、OPC UA、S7comm、三菱MC协议等数十种工业协议并存。以Modbus为例，其寄存器地址映射、字节序、功能码在不同厂商设备中定义各异。网关开发的首要任务，就是屏蔽这种异构性，将不同协议的数据统一为内部标准格式。

2.1.2 网络层：连接与传输的管道

网络层解决“数据如何从现场传到平台”的问题。它包含两种通道：南向接入网络（网关到设备）和北向传输网络（网关到平台）。南向通常采用工业现场总线或工业以太网，北向则依赖5G/4G、光纤、Wi-Fi 6、LoRa等广域或局域网络。

在实际部署中，网络层面临三大矛盾：带宽与实时性（如TSN与普通以太网的冲突）、覆盖与成本（5G覆盖好但资费高，LoRa成本低但带宽小）、安全与便利（公网传输需VPN/加密，专网成本高）。网关需要在网络层做出智能选择——例如，在5G信号不稳定时自动切换至4G，或通过双SIM卡实现链路冗余。

2.1.3 平台层：数据汇聚与大脑

平台层是IIoT的“中枢神经系统”，通常部署在云端或企业私有数据中心。它负责设备注册与管理、海量时序数据存储（如InfluxDB、TDengine）、流式计算（如Kafka Streams、Flink）、规则引擎（如Node-RED）、数字孪生建模以及向北向应用提供API服务。

平台层与网关的交互遵循特定协议，最常见的是MQTT（消息队列遥测传输）和OPC UA。MQTT基于发布/订阅模式，适合大量设备上报数据；OPC UA则提供更丰富的信息模型和语义互操作性。网关需要实现这些协议栈，并处理QoS（服务质量）级别、会话保持、遗嘱消息等细节。

2.1.4 应用层：价值实现的终端

应用层面向最终用户，提供可视化界面和决策工具。典型应用包括：设备健康度看板、能源消耗分析、产品质量追溯、预测性维护工单、生产KPI实时监控等。应用层通过RESTful API或WebSocket从平台层获取数据，并将控制指令下发至设备。

应用层与网关存在直接交互的场景：当平台层下发控制指令（如修改设备参数、触发紧急停机）时，指令通过MQTT/HTTP到达网关，网关再转换为设备协议下发至现场。这要求网关具备双向通信能力，而不仅仅是单向数据上报。

2.2 网关在架构中的核心职责

2.2.1 协议转换：从“方言”到“普通话”

协议转换是网关最基础、最核心的职责。一个典型的工业现场可能同时存在Modbus RTU设备（通过串口）、Modbus TCP设备（通过以太网）、S7-1200 PLC（通过Profinet）以及非标UDP协议的定制设备。网关需要为每种协议编写驱动，将数据点映射到统一的“标签”体系。

以Modbus RTU转MQTT为例，网关需要完成以下步骤：

1. 解析Modbus RTU帧（地址码、功能码、数据、CRC校验）。
2. 根据配置的寄存器映射表（如保持寄存器40001对应温度），读取原始值。
3. 进行数据转换（如将原始值乘以0.1得到实际温度）。
4. 将结果封装为MQTT消息，发布到指定Topic（如factory/zone1/temperature）。

// 伪代码示例：Modbus数据采集与上报
void poll_modbus_device() {
    uint16_t raw_value = modbus_read_holding_reg(0x01, 40001);
    float temperature = raw_value * 0.1; // 缩放因子
    char payload[64];
    snprintf(payload, sizeof(payload), "{\"temp\":%.1f}", temperature);
    mqtt_publish("factory/zone1/temperature", payload, QOS1);
}

2.2.2 边缘计算：在源头处理数据

网关不仅是数据管道，更是边缘计算节点。在带宽有限或实时性要求高的场景下，网关需要执行本地数据处理。典型操作包括：

• 数据过滤：丢弃无效或重复数据，只上报变化量（死区设置）。
• 聚合计算：计算平均值、最大值、最小值，减少上报频率。
• 本地告警：当温度超过阈值时，网关直接触发继电器输出或发送告警消息，无需等待云端响应。
• 轻量级AI推理：在网关CPU/GPU上运行振动分析模型，判断设备是否异常。

2.2.3 数据缓存与断网续传

工业现场网络环境并不总是稳定。网关必须具备本地数据缓存能力，确保在网络中断时数据不丢失。实现机制通常为：

1. 数据先写入本地SQLite或环形缓冲区。
2. 后台线程尝试连接MQTT Broker。
3. 连接成功后，按时间戳顺序补发缓存数据。
4. 缓存容量满时，采用“先进先出”或“覆盖最旧”策略。

断网续传的难点在于消息去重。当网络恢复后，网关可能重复发送数据，平台需要根据消息ID或时间戳进行幂等处理。

2.2.4 安全防护：边缘安全的第一道门

网关是工业网络与外部网络之间的边界，必须承担安全防护职责。具体包括：

• 设备认证：确保只有合法的设备才能接入网关（如通过MAC地址白名单）。
• 数据加密：北向通信使用TLS/DTLS加密，防止数据被窃听。
• 访问控制：限制对网关Web管理界面的访问，使用强密码和双因素认证。
• 安全启动：校验固件签名，防止恶意固件植入。

2.3 案例拆解：某汽车零部件工厂的设备数据采集与监控项目

2.3.1 项目背景与约束

某汽车零部件工厂有3条装配线，共涉及45台设备，包括：30台PLC（西门子S7-1200和S7-1500）、10台变频器（ABB ACS580）、5台智能电表（Modbus RTU）。工厂希望实现设备OEE（设备综合效率）实时计算、能耗监控和异常告警。现有IT网络与OT网络物理隔离，且车间内无Wi-Fi覆盖，只有有线以太网。

2.3.2 初始现象与目标

工厂之前采用人工抄表方式，每2小时记录一次产量和电表读数，数据滞后严重，无法及时发现设备停机。项目目标是将数据采集频率提升至每5秒一次，并实现告警响应时间小于30秒。

2.3.3 关键输入数据与参数

• PLC数据点：设备状态（运行/停止/故障）、当前产量计数、循环时间。
• 变频器数据点：输出频率、输出电流、母线电压。
• 电表数据点：三相电压、电流、有功功率、累计电量。
• 网络约束：车间到机房距离约200米，需通过光纤连接。

2.3.4 分析判断与方案设计

由于设备协议不同（Profinet、Modbus TCP、Modbus RTU），且需要统一上报至云端平台，我们选择了一款支持多协议转换的工业网关。网关南向接口配置为：

• Port 1：Profinet主站，连接S7-1200/1500。
• Port 2：Modbus TCP客户端，连接ABB变频器。
• Port 3：RS-485主站，连接智能电表（Modbus RTU）。

北向接口通过光纤连接至机房交换机，再通过工厂防火墙接入云端MQTT Broker。网关内配置了边缘计算规则：每5秒采集一次数据，计算OEE的可用率指标；当变频器电流超过额定值120%时，立即生成告警并发送至平台。

2.3.5 实际操作步骤

1. 在网关Web界面配置设备连接参数（IP、端口、寄存器映射）。
2. 编写简单的数据转换脚本（如将电表原始值除以1000得到kWh）。
3. 配置MQTT连接参数（Broker地址、Topic前缀、QoS级别）。
4. 设置断网缓存策略：缓存容量200MB，断网时数据写入本地，恢复后按序补发。
5. 部署后，通过平台观察数据流，验证数据点映射是否正确。

2.3.6 结果对比与复盘

项目上线后，数据采集延迟从2小时缩短至5秒内，OEE计算实现自动化。告警响应时间从人工发现（平均1小时）缩短至30秒内。但复盘发现两个问题：

• 问题1：部分S7-1500 PLC的DB块地址映射错误，导致产量数据偶尔跳变。原因是字节序（Big-Endian vs Little-Endian）未正确配置。解决方法是使用网关的“数据预览”功能，逐字节比对原始值。
• 问题2：断网续传时，由于MQTT QoS设置为0，导致部分缓存消息丢失。后将QoS提升至1，并启用Broker端的持久化会话，问题解决。

2.4 常见误区与总结复盘

2.4.1 误区一：将网关视为简单的“协议转换器”

很多项目初期只要求网关做协议转换，但实际运行后发现平台层计算压力过大、带宽成本过高。正确的做法是在网关侧分担部分计算任务。例如，对于高频振动数据，网关先计算FFT特征，再上传特征值而非原始波形。

2.4.2 误区二：忽视网关的“北向”能力

网关不仅要支持多种南向协议，还要灵活适配北向平台。有些网关只支持MQTT，但企业平台要求使用OPC UA或自定义TCP协议。选型时应确认网关是否支持脚本二次开发或SDK扩展。

2.4.3 误区三：忽略网络安全配置

网关默认配置往往不安全。必须修改默认密码、关闭未使用的USB/SSH端口、启用防火墙规则。在等保2.0或企业安全审计中，网关安全配置是重点检查项。

2.4.4 总结：网关开发的核心能力模型