2. IIoT基础
工业物联网（IIoT）不是把消费级物联网简单搬进工厂，而是围绕“设备—数据—计算—应用”构建的一套面向生产现场的数字化基础设施。理解 IIoT，需要同时看清四件事：系统分成哪几层、设备如何接入、数据从哪里采集、计算为什么必须下沉到边缘。这四件事共同决定了设备影子与数字资产能否获得稳定、实时、可信的数据底座。
一、四层体系架构：从现场到云端的分工
典型的 IIoT 体系架构可划分为现场设备层、边缘计算层、平台服务层和应用层。现场设备层包含 PLC、CNC、机器人、传感器、仪表、变频器等，它们产生原始信号与工艺数据；边缘计算层由工业网关、边缘控制器或边缘服务器组成，负责协议转换、数据清洗、本地缓存和实时判断；平台服务层承担设备接入管理、时序数据存储、规则引擎、设备模型与影子管理；应用层则面向具体业务，如远程监控、预测性维护、能耗优化和数字孪生。
分层的意义在于职责隔离：现场层保证“采得到”，边缘层保证“算得快”，平台层保证“管得住”，应用层保证“用得好”。如果所有数据都直接上云，网络抖动会直接导致控制失效；如果所有计算都留在现场，又难以形成跨厂区、跨设备的全局资产视图。
二、设备连接：协议多样性与接入方式
工业现场最大的现实是“协议不统一”。底层常见 Modbus RTU/TCP、Profibus、Profinet、EtherCAT、CANopen，上层常见 OPC UA、MQTT、HTTP/REST。设备连接的核心任务，是把这些异构协议统一成平台可理解的数据模型。
接入方式通常有三类：一是通过工业网关做协议转换，把 Modbus 寄存器映射为 MQTT 主题；二是设备原生支持 OPC UA 或 MQTT，可直接接入；三是对老旧设备加装传感器或 IO 模块，间接采集电流、振动、温度等信号。选择接入方式时，要同时评估实时性、改造成本、网络隔离要求和数据完整性。
# 边缘网关采集配置示例（Modbus → MQTT）
device: cnc-01
protocol: modbus-tcp
host: 192.168.10.21
port: 502
poll_interval_ms: 500
points:
- name: spindle_speed
address: 40001
type: uint16
scale: 1
- name: spindle_temp
address: 40002
type: int16
scale: 0.1
publish:
topic: factory/cnc-01/telemetry
qos: 1三、数据采集：从信号到可用数据
数据采集不是“把值读出来”这么简单。完整链路包括信号获取、采样、量纲转换、时间戳对齐、质量码标注和缓存补传。工业数据常见三类：高频波形（振动、电流）、中频过程量（温度、压力、转速）、低频状态量（开关、报警、工单）。不同频率的数据，采集周期、存储策略和传输方式都不同。
采集设计要重点关注四点：采样频率是否满足分析需求；时间戳是否统一时钟源；断网时是否有本地缓存与补传；异常值是否有质量码标记。否则，后续设备影子会出现“数据到了但不可信”的问题。
line1.cnc01.spindle_temp，并绑定设备模型中的属性名，避免同一物理量在不同系统中出现多个别名。四、边缘计算：为什么计算要下沉
边缘计算的价值体现在三个“来不及”：控制来不及上云、带宽来不及传输、隐私来不及外发。典型边缘任务包括：毫秒级联锁判断、振动频谱特征提取、图像缺陷初筛、数据降采样与聚合、断网续传。边缘节点通常部署在车间机柜或产线旁，具备本地存储、容器化运行和远程运维能力。
边缘与云的关系不是替代，而是分工：边缘负责实时、局部、高频；云平台负责全局、历史、跨设备分析。设备影子正是两者之间的“状态同步器”——边缘把最新状态写入影子，云端应用读取影子获得设备当前视图。
五、典型场景与常见误区
| 场景 | 采集对象 | 边缘任务 | 平台/应用价值 |
|---|---|---|---|
| 数控机床健康监测 | 主轴振动、电流、温度 | 频谱特征提取、阈值报警 | 预测性维护、减少非计划停机 |
| 产线能耗优化 | 电表、气表、运行状态 | 分钟级聚合、峰谷判断 | 能耗看板、单位产品能耗分析 |
| 远程设备运维 | PLC 状态、报警码、日志 | 协议转换、断网缓存 | 远程诊断、工单联动 |
| 视觉质检 | 工业相机图像 | 本地推理、缺陷初筛 | 只上传可疑图像，降低带宽 |
复盘时可以用一条主线检查：现场设备是否被正确识别？采集点是否绑定到设备模型？边缘是否具备清洗、缓存和本地判断能力？平台影子是否与真实设备状态保持一致？只有这条链路闭合，IIoT 才真正从“连上网”走向“可运营的数字资产”。