3. 通信架构总览
工业物联网（IIoT）与消费物联网的本质差异在于其严苛的确定性、安全性与可用性要求。本章作为通信架构的总览，旨在帮助工程师建立从物理设备到云端平台的全局视野。我们将首先剖析“端-边-云”三层架构的职责边界与数据流逻辑，随后深入解析三种核心通信模式（请求/响应、发布/订阅、消息队列）的适用场景与权衡，最后聚焦于工业场景下最关键的实时性与确定性指标。理解这三者之间的耦合关系，是设计高可靠工业通信系统的前提。
3.1 端-边-云分层架构：职责边界与数据流逻辑
工业物联网的物理与逻辑拓扑通常被抽象为三层：端层（感知与执行）、边缘层（就近计算与控制）、云层（集中式分析与存储）。这种分层并非简单的物理位置划分，而是基于时延预算、数据量级、安全域和计算密度的工程决策。
3.1.1 核心原理：各层的功能定位
- 端层（Device/Field）：包含传感器、变送器、执行器、PLC、RTU等。其核心职责是物理信号的采集与动作执行。该层通常采用硬实时通信（如EtherCAT、PROFINET IRT），数据包小（8-64字节），周期固定（如1ms/10ms）。端层设备资源受限（MCU主频<200MHz，RAM<512KB），通常不具备TCP/IP协议栈，依赖网关进行协议转换。
- 边缘层（Edge）：位于端与云之间，包含边缘网关、边缘控制器、工业PC。其核心价值在于消除网络抖动和降低云端负载。边缘层执行数据清洗（去除异常值）、协议转换（Modbus RTU→OPC UA）、实时控制（PID闭环）、以及轻量级AI推理（振动频谱分析）。边缘节点通常运行Linux或RTOS，具备双网口（一端口接现场总线，一端口接以太网）。
- 云层（Cloud）：提供海量存储、复杂事件处理、数字孪生与机器学习训练。云层不参与实时控制，其通信模式以异步消息为主。云层需要处理来自数千个边缘节点的数据汇聚，因此必须采用高吞吐、可持久化的消息队列（如Kafka）。
3.1.2 判断方法：如何确定数据应流向哪一层？
工程师在设计数据流时，可依据以下决策树判断：
- 该数据是否用于闭环控制？ 若是，则必须留在边缘层（或端层），且通信周期需满足控制律要求（如伺服控制需1kHz刷新率）。
- 该数据是否需要跨工厂/跨地域聚合？ 若是，则需上传云端，但应先在边缘层进行降频（如从1kHz降为1Hz）和特征提取（如RMS值、峰值）。
- 该数据是否涉及安全联锁？ 安全相关数据（如急停信号）必须走独立的硬接线或安全总线（如PROFIsafe），不得与常规数据混传。
3.1.3 案例拆解：汽车焊装车间的数据分层
某汽车焊装车间拥有200台机器人，每台机器人有6个伺服轴。初始方案将所有振动数据（每轴2kHz采样）直接上传云端，导致网络带宽占用达800Mbps，且云端分析延迟超过5秒，无法及时预警焊枪磨损。
优化方案：
- 端层：伺服驱动器内置FFT（快速傅里叶变换）算法，仅输出特征值（1Hz频率下的1阶/2阶幅值），数据量从2kHz×6轴降为1Hz×6轴。
- 边缘层：边缘网关（采用Intel Atom x7-E3950）运行OPC UA Server，将特征值映射为标准信息模型。同时，边缘层部署轻量级异常检测模型（孤立森林算法），当特征值偏离基线20%时，触发本地报警并缓存原始波形数据（仅缓存故障前10秒）。
- 云层：仅接收报警事件和每日聚合统计（每台机器人每天约50KB），用于训练全局预测模型。
结果对比：带宽占用从800Mbps降至2Mbps，报警响应时间从5秒缩短至200ms（边缘层本地决策），云端存储成本降低95%。
3.2 通信模式：请求/响应、发布/订阅、消息队列
三种通信模式对应不同的工业场景需求。选择错误的模式会导致系统耦合度过高、实时性下降或数据丢失。
| 维度 | 请求/响应 (Request/Response) | 发布/订阅 (Publish/Subscribe) | 消息队列 (Message Queue) |
|---|---|---|---|
| 通信模型 | 点对点，同步阻塞 | 异步，一对多，解耦 | 异步，点对点或一对多，持久化 |
| 典型协议 | HTTP/REST, OPC UA (Client/Server), Modbus TCP | MQTT, OPC UA PubSub, DDS | AMQP, Kafka, RabbitMQ |
| 实时性 | 中（受网络往返时间影响） | 高（基于UDP或共享内存） | 低（依赖Broker转发和磁盘写入） |
| 数据可靠性 | 高（需应答） | 中（QoS 0/1/2可选） | 高（消息持久化，可重放） |
| 适用场景 | 参数配置、设备诊断、按需读取 | 实时状态广播、遥测数据流 | 跨系统数据集成、事件驱动架构 |
3.2.1 请求/响应模式：适用于配置与诊断
该模式中，客户端发起请求并等待服务器响应。在工业场景中，常用于非周期性操作，例如：修改PLC的PID参数、读取设备固件版本、触发一次性的自检。其优点是简单直观、易于调试；缺点是客户端必须等待服务器处理，若服务器繁忙或网络拥塞，会造成阻塞。
工程要点：在工业以太网中，请求/响应模式应设置超时时间（通常为100ms-1s），并采用“连接池”机制避免频繁建立TCP连接。对于OPC UA，应使用Session复用，避免每次请求都重新握手。
3.2.2 发布/订阅模式：适用于实时数据分发
发布者（如传感器网关）将数据发送到Broker（如MQTT Broker），订阅者（如HMI、SCADA）根据主题（Topic）接收数据。该模式的核心优势是空间解耦（发布者不知道订阅者存在）和时间解耦（订阅者离线时数据可暂存）。
在工业现场，MQTT over TCP通常用于边缘到云的数据上传，而DDS（数据分发服务）用于端到端的实时控制（如机器人协同）。DDS支持“以数据为中心”的QoS策略（如DEADLINE、LIVELINESS），可保证数据在指定周期内到达。
3.2.3 消息队列：适用于跨系统异步集成
消息队列（如Kafka）与发布/订阅的核心区别在于消息持久化和消费者组机制。Kafka将消息写入磁盘分区，消费者可重放历史数据（offset回溯）。这在工业场景中至关重要：当云端应用升级或故障恢复时，可以从断点继续消费，不丢失数据。
典型应用：工厂MES（制造执行系统）需要从多个边缘网关采集生产计数、质量数据。使用Kafka作为中间层，边缘网关作为Producer，MES和数据分析平台作为Consumer。即使MES停机2小时，Kafka仍保留消息，恢复后MES可继续处理。
3.3 实时性与确定性要求
实时性（Real-time）指系统在规定时间内完成操作的能力，而确定性（Determinism）指操作完成时间的可预测性。工业通信中，我们更关注最坏情况执行时间（WCET），而非平均时延。
3.3.1 实时性分级与指标
- 硬实时（Hard Real-time）：超过截止时间会导致灾难性后果。如伺服驱动的位置环（周期1ms）、安全急停（响应<10ms）。衡量指标：抖动（Jitter）< 1μs。
- 软实时（Soft Real-time）：偶尔超时可接受，但会影响质量。如过程控制（PID调节周期100ms），超时可能导致产品报废。衡量指标：超时概率 < 0.1%。
- 非实时（Non Real-time）：如历史数据备份、报表生成，无严格时间约束。
3.3.2 影响确定性的关键因素
在以太网通信中，确定性主要受以下因素影响：
- 网络拥塞：标准以太网采用CSMA/CD（载波侦听多路访问/冲突检测），当多个节点同时发送数据时会产生冲突和重传。解决方案：使用工业以太网协议（如PROFINET IRT、EtherCAT）或时间敏感网络（TSN）的802.1Qbv时间感知整形器。
- 协议栈处理延迟：TCP/IP协议栈在操作系统内核中的处理时间不确定（受中断、调度影响）。解决方案：使用实时操作系统（RTOS）或FPGA硬件协议栈。
- 时钟同步精度：分布式控制需要所有节点共享同一时间基准。IEEE 1588v2 (PTP) 可实现亚微秒级同步，但需网络交换机支持透明时钟（TC）或边界时钟（BC）。
3.3.3 实战场景：基于TSN的确定性通信设计
某半导体制造设备需要同时传输实时运动控制数据（周期250μs，数据包64字节）和视频监控流（带宽100Mbps）。若使用标准以太网，视频流会阻塞控制数据，导致运动轨迹偏差。
实施方案：
- 采用TSN交换机，配置802.1Qbv门控列表：为控制数据保留专用时间片（如每250μs周期内预留50μs），视频流仅在剩余时间片传输。
- 所有终端设备启用802.1AS（）时钟同步，精度±100ns。
- 控制数据使用VLAN ID 100，优先级设为7（最高）；视频流使用VLAN ID 200，优先级设为3。
验证结果：在满负载（视频流+其他背景流量）下，控制数据的最大时延为180μs，抖动为±2μs，满足运动控制要求。
3.3.4 常见误区与复盘
- 误区一：认为“带宽高=实时性好”。实际上，千兆以太网的带宽优势在突发流量下反而会增加排队延迟。实时性取决于调度机制，而非带宽。
- 误区二：将所有数据都上云。云端处理必然引入网络抖动和排队延迟，无法满足控制回路需求。应遵循“数据就近处理”原则。
- 误区三：忽略Broker的单点故障。在发布/订阅模式中，若MQTT Broker宕机，所有通信中断。需部署Broker集群（如EMQX Enterprise）并配置会话持久化。
复盘案例：某风电场的SCADA系统采用Modbus TCP轮询方式采集风机数据（每台风机100个寄存器，轮询周期1s）。当风机数量从50台增加到200台时，轮询周期延长至4s，导致偏航控制响应滞后。改造方案：将通信模式改为OPC UA PubSub，风机控制器主动发布数据（周期100ms），SCADA订阅数据。改造后，数据刷新率提升至10Hz，且网络负载降低60%。