简介面向工业自动化开发者的OPC UA C#通信示例资源适合需要掌握C#客户端与PLC数据采集的工程师。内容围绕UA客户端初始化、服务器连接、节点浏览、数据订阅、读写操作和异常处理等关键环节展开涵盖55个cs源码文件、工程配置、资源文件以及可运行的dll、exe和示例界面截图压缩包共135个文件约1.61MB目录结构清晰便于对照学习。目前已有3584人学习使用。通过研读代码示例可快速理解OPC UA异步编程模型及UA-.NETStandard库的典型用法并在实际项目中复用连接、订阅与读写逻辑有效缩短工业上位机开发周期。 做上位机开发的这几年我最大的感受是设备越多通讯方案的选型就越重要。以前做项目时遇到三菱PLC、西门子1200还要对接一套视觉检测结果每台设备用各自的私有协议光维护通讯文档就够喝一壶的。后来统一换成OPC UA整个项目清爽了很多。OPC UA就是一个把设备数据“标准化”的通讯框架——不管设备内部是什么协议对外都暴露成统一的节点结构C#上位机通过一套客户端API就能读写。这篇文章不讲虚的直接用C#写一个可运行的OPC UA客户端示例从连接模拟服务器、读写节点、订阅数据变化再到生产环境必须处理的断线重连和证书问题一次讲透。适合刚开始接触OPC UA、正在做C#上位机或MES对接的同行参考。1. OPC UA到底解决了什么问题C#上位机开发者的视角1.1 私有协议为什么越做越累很多人一开始做上位机对接设备第一反应是Socket直连、Modbus TCP、或者厂商给的DLL。单台设备没问题但现场往往不是单台西门子PLC、三菱伺服、海康相机、温控器、扫码枪每个设备的协议都不一样。A设备的报文格式是十六进制按字节偏移B设备又要先发一个握手帧才能收数据这套代码写完过半年自己看着都头疼。换人维护更是灾难——交接文档里写一句“这里有个隐性的时序要求”后面的人抓瞎。如果只是数量多也还好更麻烦的是每个设备对接方式都不一样有人用DLL有人用TCP有人用串口。MES系统要数据上位机就得给每个设备写一套转发的代码。这本质上不是代码问题是缺少一个统一的“数据出口”。OPC UA就是来解决这个问题的它在设备层之上定义了一套标准的数据访问方式客户端只需要学会一套玩法就能连接任意支持OPC UA的服务器。1.2 OPC UA和旧版OPC DA的差别先理清概念。很多老工程师说的OPC其实是指OPC DAData Access它依赖Windows的COM/DCOM机制。DCOM那个穿透配置防火墙上开端口、注册服务、设置身份验证稍微复杂一点的网络环境就能把人折腾到怀疑人生而且只能在Windows上用。我记得早年做一个项目OPC DA服务器在工控机上客户端在办公室电脑上光是DCOM权限和防火墙规则就调了两天。OPC UAUnified Architecture统一架构是后来的重写版底层不依赖COM走的是TCP或HTTPS跨平台Linux的网关、嵌入式的盒子都能跑。它不只是“能传数据”还带信息模型——设备在服务器端是用对象、属性、方法组织的不是裸奔的一堆字节。比如一台机器的状态在UA里是一个对象的属性客户端读到的不只是“1”或“2”还能知道这个属性代表“运行中”还是“故障”。C#开发者实际上很幸福因为官方有完整的.NET实现而且代码风格和日常用的异步API很像上手成本不算高。1.3 C#侧库选型别被一堆包绕晕说句实在话我刚开始搜OPC UA C#也容易被各种NuGet包弄花眼。现在主流的选择就两条路官方包OPCFoundation.NetStandard.Opc.Ua源码托管在GitHub的OPCFoundation/UA-.NETStandard。功能最全客户端、服务器、发布订阅都有而且文档和示例能对应上官方规范。缺点是API偏底层刚开始会有些不习惯。社区封装库比如OpcUaHelper它把官方库常用的Session创建、读写、订阅又包了一层接口更贴近传统上位机习惯适合赶速度和简单场景。我的建议是正式项目优先用官方库。原因很简单——越底层的东西出了问题能查到的资料越多而且官方库的代码可以直接调试进去看协议交互。等官方库用熟了回头看封装库一眼就能知道它包了什么、省了什么。2. 10分钟搭好客户端从连接模拟服务器到读写节点2.1 环境准备模拟服务器与调试工具写客户端之前得先有一个能连的服务器。生产环境一般是PLC的OPC UA服务器但调试阶段建议用模拟服务器不然连不上设备就只能干瞪眼。我用得比较多的是Prosys OPC UA Simulation Server注册一下就能下免费版够用自带一堆模拟变量启动后默认监听opc.tcp://localhost:53530/OPCUA/SimulationServer。另外强烈建议装一个UA客户端调试工具我用的是UaExpert免费另一个是Prosys OPC UA Browser。这俩东西在调试阶段就像数据库的Navicat——先用它连上服务器把节点树、命名空间、数据类型都摸清楚确认能读写再写代码能省掉很多“明明代码没问题但就是读不到数据”的困惑。C#侧新建一个控制台项目就行不需要界面跑通逻辑后再移植到WinForms/WPF。NuGet安装Install-Package OPCFoundation.NetStandard.Opc.Ua注意装完包之后如果VS提示有依赖冲突一般把目标框架切到.NET 6或.NET Framework 4.7.2以上就能解决。这是新手最容易卡住的第一关——报错报在好几个系统库上实际上只是框架版本太低。2.2 最小可运行的客户端代码直接上代码这是我调试时用的最小客户端using Opc.Ua; using Opc.Ua.Configuration; // 1. 服务器地址用模拟服务器实测过 string endpointUrl opc.tcp://127.0.0.1:53530/OPCUA/SimulationServer; // 2. 创建一个应用实例 var application new ApplicationInstance { ApplicationName MyOpcUaClient, ApplicationType ApplicationType.Client }; // 3. 建立会话 var session await Session.Create( application, new ConfiguredEndpoint(null, new EndpointDescription(endpointUrl)), updateBeforeConnect: false, checkDomain: false, sessionName: CSharpDemoSession, sessionTimeout: 30000, identity: new UserIdentity(), preferredLocales: null); Console.WriteLine($会话已建立: {session.ValidFrom:yyyy-MM-dd HH:mm:ss}); // 4. 读取一个节点模拟服务器的机器状态 var nodeId new NodeId(ns2;sSimulation_Machine_1.MachineStatus); DataValue value await session.ReadValueAsync(nodeId); Console.WriteLine($读取结果: Value{value.Value}, StatusCode{value.StatusCode}); // 5. 写一个节点模拟服务器的运行速率 var writeNodeId new NodeId(ns2;sSimulation_Machine_1.Speed); await session.WriteValueAsync(writeNodeId, new DataValue(1500d)); Console.WriteLine(写入完成); session.Close();这段代码做完四件事建立会话、读取一个节点、写入一个节点、关闭。跑通之后你对OPC UA的“服务器/客户端”模型就有感觉了。2.3 NodeId和命名空间第一次接触最容易迷糊我见过太多人第一次写OPC UA代码卡在NodeId上。NodeId就是“节点身份证”在OPC UA里用它定位地址空间里的每一个数据点。常见两种格式ns2;sSimulation_Machine_1.MachineStatusns表示命名空间索引s表示字符串标识。这里的“ns2”不是固定的不同服务器命名空间索引不一样。ns0;i2258ns0是OPC UA内置的标准命名空间i是数值标识。2258是ServerStatus这个系统节点所有UA服务器都有可以用来测试连接是否正常。命名空间为什么重要因为OPC UA服务器可以加载不同的信息模型工业自动化模型、设备厂商扩展等每个模型占用一个命名空间索引。同样是“温度”A服务器在ns2B服务器可能在ns5。所以不要硬编码别人的节点字符串到处复用先看UaExpert里服务器的命名空间表再写。常见的坑拿模拟服务器的节点去连另一个品牌PLC的服务器提示BadNodeIdUnknown。不是代码问题是NodeId写错了对象。我自己的习惯是连接后先读取ns0;i2258这个节点所有UA服务器都有确认协议层是通的再去找业务节点。3. 数据监控的正确方式订阅推送替代定时轮询3.1 轮询为什么不好读和写跑通后很多人下一个需求自然是“我要监控这个变量变了就弹出来”。新手习惯用Timer每500ms去读一次这也太粗暴了。想象一下现场有100个变量每个变量假设500ms读一次服务器端每次都要处理请求、查数据、回包客户端要等IO、解析、触发。数据量一大连接数一多延迟上来了服务器CPU也陪着空转。OPC UA提供了订阅Subscription机制客户端告诉服务器“你盯着这个变量值变了就通知我”服务器是主动推送方客户端只处理自己订阅的数据。一来一回的占用少了实时性反而更好。3.2 订阅的代码实现订阅涉及两个对象Subscription和MonitoredItem。把它当成“快递订阅”理解Subscription是“订阅合同”多久发一次通知MonitoredItem是“合同里要监控的具体地址”哪个快递员送、送到哪。代码里先建合同再往里加地址然后等着收通知。// 1. 创建订阅发布间隔1000ms var subscription new Subscription(session.DefaultSubscription) { PublishingInterval 1000, PublishingEnabled true, Priority 100 }; session.AddSubscription(subscription); subscription.Create(); // 2. 创建监控项监控机器状态节点 var monItem new MonitoredItem { StartNodeId new NodeId(ns2;sSimulation_Machine_1.MachineStatus), AttributeId Attributes.Value, SamplingInterval 300, // 底层采样间隔毫秒 QueueSize 10 // 缓冲区长度 }; // 3. 数据变化事件 monItem.Notification (item, args) { var notif args.NotificationValue as MonitoredItemNotification; if (notif ! null) { Console.WriteLine($[{DateTime.Now:HH:mm:ss}] {item.StartNodeId} {notif.Value.Value}); } }; // 4. 把监控项加到订阅里并生效 subscription.AddItem(monItem); subscription.ApplyChanges(); Console.WriteLine(订阅已建立按回车退出); Console.ReadLine(); session.Close();跑起来之后你会在控制台看到值变化时立刻打出来没变化时没有任何输出。这种“静默”恰恰说明订阅在工作。3.3 采样和发布间隔怎么设这里有两个时间参数容易混SamplingInterval服务器从设备/底层获取数据的间隔。设300ms就是服务器每300ms检查一下这个变量。PublishingInterval服务器向客户端推送通知的间隔。设1000ms就是最多每1秒发一批变化通知。合理组合是SamplingInterval小于PublishingInterval让服务器在同一个发布周期内把多次变化合并打包数据实时性和网络占用都比较均衡。如果现场对实时性要求高比如要求几十毫秒看到变化那是另外一套精调方案需要把PublishingInterval压到100ms档位并确认服务器扛得住。千万别两个都设成10ms对一个变量没问题几百个变量就是自己给服务器上强度。4. 从Demo到产线必踩的五个坑和对应的处理方案4.1 断线重连上线后第一个大麻烦开发环境一切正常一到车间就掉线这是OPC UA客户端最常见的戏剧性转折。车间网络抖动、交换机重启、有人拔错网线路由器上就能给你断出各种花样。断线之后客户端表面看起来还连着实际上收不到任何数据了。处理思路是关注KeepAlive机制。客户端和服务器之间有心跳包连续收不到心跳就判定连接异常。官方库里有KeepAlive事件工程上常用的做法是连续两次丢失心跳主动触发重连。重连时先尝试Session.Reconnect()如果抛异常就重新走Session.Create()。注意后者等于重新建会话之前创建的订阅全部要重新添加。这里有个容易忽略的点Session.Reconnect()表面上成功实际订阅可能已经失效。我的习惯是重连成功后先清掉旧订阅重新Create一套虽然代码多一点但状态可预期好排查。4.2 证书和安全模式选None还是签证书开发阶段为了省事大家都喜欢SecurityMode.None 匿名本地和模拟服务器没有任何阻力。但生产环境我不建议这样裸奔。车间里如果网络环境相对封闭短期用None可以接受但凡网络里有其他系统就至少开Basic256Sha256签名加密哪怕用户名密码简单点也比明文强。第一次配证书会遇到BadCertificateUntrusted这类报错这是客户端和服务器之间的信任链没建立。思路很直接把客户端证书导入服务器的受信任列表或者反过来把服务器证书导入本机受信任列表。OPC Foundation的证书默认放在programdata/OPC Foundation/pki目录UaExpert的证书管理和手动拷贝都能完成。最省事但不推荐的做法是在代码里把所有证书回调直接return true建议只在纯测试环境这么干。4.3 异步回调别碰UI线程用订阅方式接收数据时Notification事件是在后台线程池线程上触发的。如果你把event里的数据直接丢给WinForms的Label.Text大概率收到一个跨线程异常表现是不定时的崩。官方做法是用Control.BeginInvoke切回UI线程。另外订阅事件回调里尽量不要写async void。我自己栽过一次以为加个await就没事了结果异常被吞掉连日志都没有。改成async Task用try/catch包住主体逻辑出问题至少能定位。4.4 数据质量判定Value不是唯一要读的东西只读Value不做质量判断也是一个容易被忽略的细节。OPC UA的DataValue不只包含Value还有StatusCode它代表数据的有效性。典型场景是设备停机或者传感器断线时服务器照样把旧值推送过来但如果只看Value不看StatusCode你会以为现场还正常运行。判断逻辑很简单拿到DataValue后先看StatusCode是否等于GoodStatusCode.IsBad()为false是Good才进入业务逻辑。我在实际项目里还会把StatusCode本身记到日志里方便事后排查是设备问题还是通讯问题。4.5 一组可以直接抄的参数参数推荐值说明OperationTimeout10000ms超出此时间未收到响应视为超时太短容易被慢服务器误伤SessionTimeout30000ms服务端清理无效会话的时间不宜过短KeepAliveInterval5000ms心跳间隔兼顾发现速度和网络负载PublishingInterval1000ms默认发布周期按业务实时性调整SamplingInterval200~500ms底层采集间隔无需小于100msQueueSize10通知缓冲太大延迟高太小易丢通知连接超时5000ms建链阶段超时控制这组参数是我在多个项目里调过之后比较稳的基线拿到项目里先跑再按现场情况微调。5. 下一步值得研究的方向服务器、信息模型和视觉集成5.1 自己写一个UA服务器做客户端玩熟练之后你会发现另一个大坑怎么把自己的数据暴露给MES这时候你就需要一个UA服务器。官方库同样支持Server端新建一个Console项目引用OPCFoundation.NetStandard.Opc.Ua启动时加载节点管理器把设备状态、加工数据都注册成节点MES那边直接用标准客户端订阅。自己做服务器最大的好处是能完全控制节点结构和权限比依赖第三方网关踏实。5.2 信息模型不只是传输值OPC UA的“UA”里带了Unified Architecture它带来的不只是通信还有统一的建模语言。比如一台机器人在UA服务器里不只是一个“坐标值”节点而是一个对象有属性当前坐标、方法回零、启动、事件报警。MES系统通过信息模型拿到的不再是“散装的数值”而是“设备业务对象”集成效率完全不同。这也是为什么很多厂商PLC、驱动器、视觉系统都在提供自己的UA信息模型。5.3 和视觉系统对接的一点想法很多同行在问海康VisionMaster和C#上位机之间用什么协议通讯。如果只是单机集成用视觉软件自带的SDK回调最直接性能也最好但如果要做整线集成视觉结果要供多台设备或MES消费我倾向用OPC UA把视觉判定结果OK/NG、坐标、测量值发布成标准节点其他系统统一订阅避免“一套视觉结果给三个系统就要写三套对接”的尴尬。思路可以开阔一点不必为一个功能绑定一种通讯方式按数据消费方的数量来决定。最后说点我个人体会。OPC UA这套东西刚上手会觉得概念多但只要把一个客户端示例真正跑起来读、写、订阅都过一遍后面就是熟练工了。调试阶段我有个习惯先不写重连和业务逻辑挂UaExpert观察一个晚上确认服务器在什么时间点容易掉线、哪个节点读不出来再针对性写代码。按这个顺序来的项目上线后基本都能睡得着觉。本文还有配套的精品资源点击获取 C#上位机开发OPC UA客户端实战：从连接到订阅、断线重连与证书处理
简介面向工业自动化开发者的OPC UA C#通信示例资源适合需要掌握C#客户端与PLC数据采集的工程师。内容围绕UA客户端初始化、服务器连接、节点浏览、数据订阅、读写操作和异常处理等关键环节展开涵盖55个cs源码文件、工程配置、资源文件以及可运行的dll、exe和示例界面截图压缩包共135个文件约1.61MB目录结构清晰便于对照学习。目前已有3584人学习使用。通过研读代码示例可快速理解OPC UA异步编程模型及UA-.NETStandard库的典型用法并在实际项目中复用连接、订阅与读写逻辑有效缩短工业上位机开发周期。 做上位机开发的这几年我最大的感受是设备越多通讯方案的选型就越重要。以前做项目时遇到三菱PLC、西门子1200还要对接一套视觉检测结果每台设备用各自的私有协议光维护通讯文档就够喝一壶的。后来统一换成OPC UA整个项目清爽了很多。OPC UA就是一个把设备数据“标准化”的通讯框架——不管设备内部是什么协议对外都暴露成统一的节点结构C#上位机通过一套客户端API就能读写。这篇文章不讲虚的直接用C#写一个可运行的OPC UA客户端示例从连接模拟服务器、读写节点、订阅数据变化再到生产环境必须处理的断线重连和证书问题一次讲透。适合刚开始接触OPC UA、正在做C#上位机或MES对接的同行参考。1. OPC UA到底解决了什么问题C#上位机开发者的视角1.1 私有协议为什么越做越累很多人一开始做上位机对接设备第一反应是Socket直连、Modbus TCP、或者厂商给的DLL。单台设备没问题但现场往往不是单台西门子PLC、三菱伺服、海康相机、温控器、扫码枪每个设备的协议都不一样。A设备的报文格式是十六进制按字节偏移B设备又要先发一个握手帧才能收数据这套代码写完过半年自己看着都头疼。换人维护更是灾难——交接文档里写一句“这里有个隐性的时序要求”后面的人抓瞎。如果只是数量多也还好更麻烦的是每个设备对接方式都不一样有人用DLL有人用TCP有人用串口。MES系统要数据上位机就得给每个设备写一套转发的代码。这本质上不是代码问题是缺少一个统一的“数据出口”。OPC UA就是来解决这个问题的它在设备层之上定义了一套标准的数据访问方式客户端只需要学会一套玩法就能连接任意支持OPC UA的服务器。1.2 OPC UA和旧版OPC DA的差别先理清概念。很多老工程师说的OPC其实是指OPC DAData Access它依赖Windows的COM/DCOM机制。DCOM那个穿透配置防火墙上开端口、注册服务、设置身份验证稍微复杂一点的网络环境就能把人折腾到怀疑人生而且只能在Windows上用。我记得早年做一个项目OPC DA服务器在工控机上客户端在办公室电脑上光是DCOM权限和防火墙规则就调了两天。OPC UAUnified Architecture统一架构是后来的重写版底层不依赖COM走的是TCP或HTTPS跨平台Linux的网关、嵌入式的盒子都能跑。它不只是“能传数据”还带信息模型——设备在服务器端是用对象、属性、方法组织的不是裸奔的一堆字节。比如一台机器的状态在UA里是一个对象的属性客户端读到的不只是“1”或“2”还能知道这个属性代表“运行中”还是“故障”。C#开发者实际上很幸福因为官方有完整的.NET实现而且代码风格和日常用的异步API很像上手成本不算高。1.3 C#侧库选型别被一堆包绕晕说句实在话我刚开始搜OPC UA C#也容易被各种NuGet包弄花眼。现在主流的选择就两条路官方包OPCFoundation.NetStandard.Opc.Ua源码托管在GitHub的OPCFoundation/UA-.NETStandard。功能最全客户端、服务器、发布订阅都有而且文档和示例能对应上官方规范。缺点是API偏底层刚开始会有些不习惯。社区封装库比如OpcUaHelper它把官方库常用的Session创建、读写、订阅又包了一层接口更贴近传统上位机习惯适合赶速度和简单场景。我的建议是正式项目优先用官方库。原因很简单——越底层的东西出了问题能查到的资料越多而且官方库的代码可以直接调试进去看协议交互。等官方库用熟了回头看封装库一眼就能知道它包了什么、省了什么。2. 10分钟搭好客户端从连接模拟服务器到读写节点2.1 环境准备模拟服务器与调试工具写客户端之前得先有一个能连的服务器。生产环境一般是PLC的OPC UA服务器但调试阶段建议用模拟服务器不然连不上设备就只能干瞪眼。我用得比较多的是Prosys OPC UA Simulation Server注册一下就能下免费版够用自带一堆模拟变量启动后默认监听opc.tcp://localhost:53530/OPCUA/SimulationServer。另外强烈建议装一个UA客户端调试工具我用的是UaExpert免费另一个是Prosys OPC UA Browser。这俩东西在调试阶段就像数据库的Navicat——先用它连上服务器把节点树、命名空间、数据类型都摸清楚确认能读写再写代码能省掉很多“明明代码没问题但就是读不到数据”的困惑。C#侧新建一个控制台项目就行不需要界面跑通逻辑后再移植到WinForms/WPF。NuGet安装Install-Package OPCFoundation.NetStandard.Opc.Ua注意装完包之后如果VS提示有依赖冲突一般把目标框架切到.NET 6或.NET Framework 4.7.2以上就能解决。这是新手最容易卡住的第一关——报错报在好几个系统库上实际上只是框架版本太低。2.2 最小可运行的客户端代码直接上代码这是我调试时用的最小客户端using Opc.Ua; using Opc.Ua.Configuration; // 1. 服务器地址用模拟服务器实测过 string endpointUrl opc.tcp://127.0.0.1:53530/OPCUA/SimulationServer; // 2. 创建一个应用实例 var application new ApplicationInstance { ApplicationName MyOpcUaClient, ApplicationType ApplicationType.Client }; // 3. 建立会话 var session await Session.Create( application, new ConfiguredEndpoint(null, new EndpointDescription(endpointUrl)), updateBeforeConnect: false, checkDomain: false, sessionName: CSharpDemoSession, sessionTimeout: 30000, identity: new UserIdentity(), preferredLocales: null); Console.WriteLine($会话已建立: {session.ValidFrom:yyyy-MM-dd HH:mm:ss}); // 4. 读取一个节点模拟服务器的机器状态 var nodeId new NodeId(ns2;sSimulation_Machine_1.MachineStatus); DataValue value await session.ReadValueAsync(nodeId); Console.WriteLine($读取结果: Value{value.Value}, StatusCode{value.StatusCode}); // 5. 写一个节点模拟服务器的运行速率 var writeNodeId new NodeId(ns2;sSimulation_Machine_1.Speed); await session.WriteValueAsync(writeNodeId, new DataValue(1500d)); Console.WriteLine(写入完成); session.Close();这段代码做完四件事建立会话、读取一个节点、写入一个节点、关闭。跑通之后你对OPC UA的“服务器/客户端”模型就有感觉了。2.3 NodeId和命名空间第一次接触最容易迷糊我见过太多人第一次写OPC UA代码卡在NodeId上。NodeId就是“节点身份证”在OPC UA里用它定位地址空间里的每一个数据点。常见两种格式ns2;sSimulation_Machine_1.MachineStatusns表示命名空间索引s表示字符串标识。这里的“ns2”不是固定的不同服务器命名空间索引不一样。ns0;i2258ns0是OPC UA内置的标准命名空间i是数值标识。2258是ServerStatus这个系统节点所有UA服务器都有可以用来测试连接是否正常。命名空间为什么重要因为OPC UA服务器可以加载不同的信息模型工业自动化模型、设备厂商扩展等每个模型占用一个命名空间索引。同样是“温度”A服务器在ns2B服务器可能在ns5。所以不要硬编码别人的节点字符串到处复用先看UaExpert里服务器的命名空间表再写。常见的坑拿模拟服务器的节点去连另一个品牌PLC的服务器提示BadNodeIdUnknown。不是代码问题是NodeId写错了对象。我自己的习惯是连接后先读取ns0;i2258这个节点所有UA服务器都有确认协议层是通的再去找业务节点。3. 数据监控的正确方式订阅推送替代定时轮询3.1 轮询为什么不好读和写跑通后很多人下一个需求自然是“我要监控这个变量变了就弹出来”。新手习惯用Timer每500ms去读一次这也太粗暴了。想象一下现场有100个变量每个变量假设500ms读一次服务器端每次都要处理请求、查数据、回包客户端要等IO、解析、触发。数据量一大连接数一多延迟上来了服务器CPU也陪着空转。OPC UA提供了订阅Subscription机制客户端告诉服务器“你盯着这个变量值变了就通知我”服务器是主动推送方客户端只处理自己订阅的数据。一来一回的占用少了实时性反而更好。3.2 订阅的代码实现订阅涉及两个对象Subscription和MonitoredItem。把它当成“快递订阅”理解Subscription是“订阅合同”多久发一次通知MonitoredItem是“合同里要监控的具体地址”哪个快递员送、送到哪。代码里先建合同再往里加地址然后等着收通知。// 1. 创建订阅发布间隔1000ms var subscription new Subscription(session.DefaultSubscription) { PublishingInterval 1000, PublishingEnabled true, Priority 100 }; session.AddSubscription(subscription); subscription.Create(); // 2. 创建监控项监控机器状态节点 var monItem new MonitoredItem { StartNodeId new NodeId(ns2;sSimulation_Machine_1.MachineStatus), AttributeId Attributes.Value, SamplingInterval 300, // 底层采样间隔毫秒 QueueSize 10 // 缓冲区长度 }; // 3. 数据变化事件 monItem.Notification (item, args) { var notif args.NotificationValue as MonitoredItemNotification; if (notif ! null) { Console.WriteLine($[{DateTime.Now:HH:mm:ss}] {item.StartNodeId} {notif.Value.Value}); } }; // 4. 把监控项加到订阅里并生效 subscription.AddItem(monItem); subscription.ApplyChanges(); Console.WriteLine(订阅已建立按回车退出); Console.ReadLine(); session.Close();跑起来之后你会在控制台看到值变化时立刻打出来没变化时没有任何输出。这种“静默”恰恰说明订阅在工作。3.3 采样和发布间隔怎么设这里有两个时间参数容易混SamplingInterval服务器从设备/底层获取数据的间隔。设300ms就是服务器每300ms检查一下这个变量。PublishingInterval服务器向客户端推送通知的间隔。设1000ms就是最多每1秒发一批变化通知。合理组合是SamplingInterval小于PublishingInterval让服务器在同一个发布周期内把多次变化合并打包数据实时性和网络占用都比较均衡。如果现场对实时性要求高比如要求几十毫秒看到变化那是另外一套精调方案需要把PublishingInterval压到100ms档位并确认服务器扛得住。千万别两个都设成10ms对一个变量没问题几百个变量就是自己给服务器上强度。4. 从Demo到产线必踩的五个坑和对应的处理方案4.1 断线重连上线后第一个大麻烦开发环境一切正常一到车间就掉线这是OPC UA客户端最常见的戏剧性转折。车间网络抖动、交换机重启、有人拔错网线路由器上就能给你断出各种花样。断线之后客户端表面看起来还连着实际上收不到任何数据了。处理思路是关注KeepAlive机制。客户端和服务器之间有心跳包连续收不到心跳就判定连接异常。官方库里有KeepAlive事件工程上常用的做法是连续两次丢失心跳主动触发重连。重连时先尝试Session.Reconnect()如果抛异常就重新走Session.Create()。注意后者等于重新建会话之前创建的订阅全部要重新添加。这里有个容易忽略的点Session.Reconnect()表面上成功实际订阅可能已经失效。我的习惯是重连成功后先清掉旧订阅重新Create一套虽然代码多一点但状态可预期好排查。4.2 证书和安全模式选None还是签证书开发阶段为了省事大家都喜欢SecurityMode.None 匿名本地和模拟服务器没有任何阻力。但生产环境我不建议这样裸奔。车间里如果网络环境相对封闭短期用None可以接受但凡网络里有其他系统就至少开Basic256Sha256签名加密哪怕用户名密码简单点也比明文强。第一次配证书会遇到BadCertificateUntrusted这类报错这是客户端和服务器之间的信任链没建立。思路很直接把客户端证书导入服务器的受信任列表或者反过来把服务器证书导入本机受信任列表。OPC Foundation的证书默认放在programdata/OPC Foundation/pki目录UaExpert的证书管理和手动拷贝都能完成。最省事但不推荐的做法是在代码里把所有证书回调直接return true建议只在纯测试环境这么干。4.3 异步回调别碰UI线程用订阅方式接收数据时Notification事件是在后台线程池线程上触发的。如果你把event里的数据直接丢给WinForms的Label.Text大概率收到一个跨线程异常表现是不定时的崩。官方做法是用Control.BeginInvoke切回UI线程。另外订阅事件回调里尽量不要写async void。我自己栽过一次以为加个await就没事了结果异常被吞掉连日志都没有。改成async Task用try/catch包住主体逻辑出问题至少能定位。4.4 数据质量判定Value不是唯一要读的东西只读Value不做质量判断也是一个容易被忽略的细节。OPC UA的DataValue不只包含Value还有StatusCode它代表数据的有效性。典型场景是设备停机或者传感器断线时服务器照样把旧值推送过来但如果只看Value不看StatusCode你会以为现场还正常运行。判断逻辑很简单拿到DataValue后先看StatusCode是否等于GoodStatusCode.IsBad()为false是Good才进入业务逻辑。我在实际项目里还会把StatusCode本身记到日志里方便事后排查是设备问题还是通讯问题。4.5 一组可以直接抄的参数参数推荐值说明OperationTimeout10000ms超出此时间未收到响应视为超时太短容易被慢服务器误伤SessionTimeout30000ms服务端清理无效会话的时间不宜过短KeepAliveInterval5000ms心跳间隔兼顾发现速度和网络负载PublishingInterval1000ms默认发布周期按业务实时性调整SamplingInterval200~500ms底层采集间隔无需小于100msQueueSize10通知缓冲太大延迟高太小易丢通知连接超时5000ms建链阶段超时控制这组参数是我在多个项目里调过之后比较稳的基线拿到项目里先跑再按现场情况微调。5. 下一步值得研究的方向服务器、信息模型和视觉集成5.1 自己写一个UA服务器做客户端玩熟练之后你会发现另一个大坑怎么把自己的数据暴露给MES这时候你就需要一个UA服务器。官方库同样支持Server端新建一个Console项目引用OPCFoundation.NetStandard.Opc.Ua启动时加载节点管理器把设备状态、加工数据都注册成节点MES那边直接用标准客户端订阅。自己做服务器最大的好处是能完全控制节点结构和权限比依赖第三方网关踏实。5.2 信息模型不只是传输值OPC UA的“UA”里带了Unified Architecture它带来的不只是通信还有统一的建模语言。比如一台机器人在UA服务器里不只是一个“坐标值”节点而是一个对象有属性当前坐标、方法回零、启动、事件报警。MES系统通过信息模型拿到的不再是“散装的数值”而是“设备业务对象”集成效率完全不同。这也是为什么很多厂商PLC、驱动器、视觉系统都在提供自己的UA信息模型。5.3 和视觉系统对接的一点想法很多同行在问海康VisionMaster和C#上位机之间用什么协议通讯。如果只是单机集成用视觉软件自带的SDK回调最直接性能也最好但如果要做整线集成视觉结果要供多台设备或MES消费我倾向用OPC UA把视觉判定结果OK/NG、坐标、测量值发布成标准节点其他系统统一订阅避免“一套视觉结果给三个系统就要写三套对接”的尴尬。思路可以开阔一点不必为一个功能绑定一种通讯方式按数据消费方的数量来决定。最后说点我个人体会。OPC UA这套东西刚上手会觉得概念多但只要把一个客户端示例真正跑起来读、写、订阅都过一遍后面就是熟练工了。调试阶段我有个习惯先不写重连和业务逻辑挂UaExpert观察一个晚上确认服务器在什么时间点容易掉线、哪个节点读不出来再针对性写代码。按这个顺序来的项目上线后基本都能睡得着觉。本文还有配套的精品资源点击获取