金渡江车间里的设备数据采集，一直是个看似简单实际坑很深的事。我做了几年工业上位机，最深的感受是：真正难的往往不是把PLC里的某个寄存器读出来，而是把现场几十上百台设备的数据稳定地采上来、传得走、存得住，最后还能真正用来判断设备健康状态。这两年我一直在做一个C#上位机项目，核心思路就是用OPC UA把车间内部设备数据统一采集，再用MQTT把数据转发到上层平台，最后在上位机里做实时监控和设备健康度评估，逐步实现预测性维护。这篇就把我的落地方案、代码思路和踩过的坑完整梳理出来，给准备做工业IIoT项目的朋友一个可以直接参考的样板。
1. 先搭骨架：IIoT平台的整体架构与协议选型
1.1 四层数据链路：从传感器到决策大屏
工业IIoT平台不神秘，本质上就是一条数据管道：现场设备产生数据，采集层负责把数据拿上来，传输层负责把数据送出去，应用层负责把数据变成决策。
我自己的平台分了四层：
- 设备层：PLC（三菱、西门子、欧姆龙等）、传感器、仪表、变频器、伺服驱动器，或者通过串口服务器485总线汇聚的现场传感器。这一层的通讯协议五花八门，有Modbus RTU、Modbus TCP、S7协议、MC协议、CC-Link等等。
- 采集层：也就是我们的C#上位机。它运行在车间工控机或者边缘计算盒子上，直接和设备层通信。这一层最核心的职责是协议转换和边缘计算。上位机通过各设备的原生协议把数据读上来，统一转换成标准格式，然后在本地做一轮简单的数据处理（越限判断、数据清洗、健康度打分），再向上转发。
- 传输层：我选用了MQTT。上位机作为MQTT客户端，把标准化后的数据发布到Broker（消息代理），上层应用再订阅这些Topic获取数据。这一层的好处是彻底解耦了生产端和消费端，采集程序和展示程序各自独立演进。
- 应用层：监控大屏、数据看板、历史数据库、报警中心、移动端APP。这些程序通过订阅MQTT Topic实时拿到设备数据，同时从历史库里拉取趋势数据做分析。
这种分层方案最大的好处是每一层都能独立替换。现场设备换了通讯协议，改上位机里的驱动就行，上面几层完全不动；展示端要换技术栈，数据源不变，也只是改订阅逻辑。
对我个人来说，做这个平台解决的是“数据孤岛”的老问题。以前车间每台设备各跑各的触摸屏，维修工要一台一台看，效率低不说，有些设备的异常在早期根本看不出来，等真坏了已经是停机事故。所有数据统一汇聚之后，很多问题就有了提前发现的可能性。
1.2 MQTT和OPC UA双协议：谁负责采集，谁负责转发
聊IIoT协议，有两个名字绕不开：OPC UA和MQTT。很多新手容易把这两个搞混，以为选一个就行。实际上在我这个平台里，两者的分工完全不同。
OPC UA是车间内部的“东西”，它解决的是设备数据互通的标准化问题。过去PLC和上位机通信，每家的协议都不一样，西门子用S7，三菱用MC，Modbus虽然通用但数据模型简陋。OPC UA相当于给所有设备定了一个统一的数据表达方式和访问方式，不管底层是什么设备，到了OPC UA这层都是节点(Node)、对象(Object)、方法(Method)。而且OPC UA自带信息模型，可以把设备的结构、参数、报警、历史数据都描述得很完整。它还内置了安全机制，支持证书加密，这在工厂内网环境里是加分项。
MQTT则是车间内外的“快递系统”，它解决的是数据在不可靠网络环境下如何可靠分发的问题。MQTT基于发布/订阅模式，消息通过主题(Topic)路由，Broker负责转发，客户端不需要知道对端是谁。它专门为低带宽、高延迟、网络不稳定的环境设计，有QoS质量等级、遗嘱消息、保留消息这些机制，特别适合设备数据从车间边缘往云端或厂级平台传送。
我在实际选型时用了一张简单的对照表：
| 维度 | OPC UA | MQTT |
|---|---|---|
| 定位 | 设备间数据互操作标准 | 消息传输协议 |
| 典型场景 | 车间内上位机读写PLC数据 | 边缘到云端的遥测数据上行、指令下行 |
| 通信模型 | 客户端/服务器、订阅 | 发布/订阅 |
| 数据模型 | 丰富的信息模型，自带语义 | 纯二进制负载，语义由应用层定义 |
| 安全性 | 内建证书加密、用户认证 | 依赖传输层TLS，应用层自己做认证 |
| 实时性 | 支持亚秒级订阅刷新 | 取决于Broker和QoS设置，通常秒级 |
所以我的平台方案是：车间内部走OPC UA做设备采集，边缘到上层走MQTT做数据转发。OPC UA负责把现场的“方言”翻译成“普通话”，MQTT负责把“普通话”通过邮件系统发出去。
如果你未来要做类似结构，这个双协议组合基本是现在工业IIoT的主流标准搭配，踩坑少、资料多、设备支持也好。
1.3 为什么用C#做上位机：生态成熟度决定的
选C#做上位机，我是有私心的，因为C#在这个领域实在太成熟了。国内工业上位机市场，C#（WinForms/WPF）和LabVIEW是两大主力，但C#在开发者数量、生态库、跨技术栈整合能力上有明显优势。
做上位机你要面对的往往是混合场景：要WinForms或WPF写界面，要用OPC UA SDK连PLC，要用MQTT库做消息收发，要调SQLite或时序库存历史数据，还要处理串口、Socket、Modbus这些底层通讯。C#在这几个场景里都有非常成熟的第三方库，上手快，资料也好搜。而且C#的异步编程模型在处理设备IO时非常好用，不会像传统同步代码那样一卡就死界面。
另外.NET生态对工业协议的支持现在也很全面。OPC UA有OPCFoundation官方维护的Opc.Ua.NetStandard库，MQTT有MQTTnet这种社区明星库，Modbus有NModbus、EasyModbus，三菱、西门子都有对应的开源库。C#随手就能拼出一套完整的上位机平台，这对个人开发者和小团队来说太重要了。
我在企业里也见过用C++做OPC UA客户端的，性能和资源占用确实更好，但开发效率和对开发者的要求高出一大截，迭代成本很高。Python上手快但部署到工控机上总有一种不踏实的感觉，性能和界面也是短板。C#正好站在两者的平衡点上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心模块逐个攻克：采集、转发、算法与展示
2.1 OPC UA客户端采集模块：从连上到订阅数据
OPC UA客户端这块，我用的是OPCFoundation官方提供的Opc.Ua.NetStandard库，它是跨平台的，一个代码库同时支持.NET Framework和.NET Core/5+。我项目里的采集服务是用.NET 6做的Worker Service，部署在工控机上，开机自启、异常重启都很方便。
先把最基本的连接和读取流程过一遍。OPC UA客户端要连上服务器，三件事是必须的：找对Endpoint、建立Session、创建Subscription（如果要订阅数据变化的话）。
Endpoint就是服务器暴露出来的访问地址，例如Prosys OPC UA Simulation Server（一个免费的OPC UA模拟服务器，做测试非常方便）默认地址是：
text复制opc.tcp://localhost:53530/OPCUA/SimulationServer
连上之前需要创建一个ApplicationConfiguration，这是OPC UA库的“应用身份”，它包含了应用名称、证书、安全策略等信息。下面是关键初始化代码：
csharp复制using Opc.Ua;
using Opc.Ua.Client;
var application = new ApplicationConfiguration
{
ApplicationName = "CSharpIIoTCollector",
ApplicationUri = "u