简介：面向C#工业通信开发者的OPC UA读取设备数据示例工程，完整展示了基于VS2017与UA .NET Standard SDK连接OPC UA服务器、查找设备节点、订阅并读取实时数据的过程，适合有C#基础、正在做工业数据采集或上位机开发的读者，也可供自动化集成与物联网项目入门参考。压缩包共1204个文件、约40.56MB，以dll、xml运行库及程序集为主，并包含cs源码、sln与csproj工程文件、config配置和exe可执行文件，解压后可直接在VS2017中编译运行，目录与依赖结构清晰。已有2258人浏览学习。通过该示例可掌握OPC UA客户端程序的连接管理、节点操作、数据订阅与异常处理等关键实现，理解安全认证与通信配置的落地方式。结合PlasticOPc模拟服务器可快速验证读取逻辑，节省搭建环境的时间，为对接真实设备提供清晰可复用的代码框架。
1. 项目整体设计思路
1.1 为什么是OPC UA
做上位机开发这些年，我接触过的设备通讯协议不下十种。早期做MES数据采集，设备层全是Modbus RTU、Modbus TCP、三菱MC协议、西门子S7协议，每个品牌一个玩法，每换一台设备就得重写一版驱动。最痛苦的还不是写驱动，而是和现场工程师对地址表——PLC里一个地址写错一位，采集上来的数据就全是乱的，排查半天才发现是地址偏移了一位。
OPC UA（OPC Unified Architecture，统一架构）解决的就是这个问题。它把设备的数据模型标准化了，不再是你传一个寄存器地址、我读一个数据块这种裸通讯，而是以“节点”为单位组织数据。每个节点有唯一的NodeId，有类型、有属性、有单位，甚至还有历史数据。现场设备是什么品牌不重要，重要的是它是否支持OPC UA Server。只要支持，客户端这边就是一套代码全搞定，不用再关心底层是走TCP还是走别的传输。
我做这个示例项目的初衷很简单：给团队里新来的上位机开发同事一份能直接跑起来的参考代码，同时也给自己留一个可复用的基础模块。因为每次接新项目都要翻老代码、删逻辑、改地址，时间全耗在重复劳动上了。花一晚上整理一个清爽的版本，后面对接设备直接复制这个框架，效率会高很多。
1.2 为什么用C#/.NET做上位机
选C#纯粹是务实考虑。工业现场最常见的上位机环境就是Windows，而C#在Windows生态下的开发效率确实高。WinForm拖几个按钮、写几行事件就能出一个能用的采集界面，串口、TCP、OPC UA的库也都是现成的，NuGet上直接装。相比C++写界面，C#的开发周期要短得多，调试也方便。
再一个原因是OPC UA官方的开源库质量很好。OPCFoundation维护的UA-.NETStandard库，从会话管理、订阅、历史读取到复杂数据类型解析都覆盖了，社区活跃度高，GitHub上的issue处理也及时。有现成的高质量库，就没必要自己从协议栈开始写了。
有一点我得提前说明：OPC UA本身是一个大而全的规范，官方库里的API非常多，但实际做数据采集用到的其实就那么几个核心功能——连接、读值、订阅、写值。这个示例我只挑最实用的部分展开，先把主线跑通，再谈复杂玩法。
1.3 示例程序的功能范围
我规划的示例程序包含三个核心能力：
- 连接一个OPC UA Server，建立会话（Session）
- 按NodeId批量读取设备测点值（比如温度、压力、转速这些实时数据）
- 订阅指定的测点，当设备端数据变化时主动推给客户端
这三个能力覆盖了绝大多数上位机数据采集场景。连续读取适合周期轮询，订阅适合实时变化监测，两者结合基本够用了。项目里我还会带上UAExpert的调试方法，这个工具在排查节点地址问题时几乎是必用的，后面会细说。
2. OPC UA核心概念与数据访问模型
2.1 节点模型：从Server到Variable
先花点时间把OPC UA的数据组织方式讲清楚，因为新手最容易在这块卡住。你可以把OPC UA Server想象成一棵文件目录树，根节点下面是Objects，Objects下面再挂各种设备对象，设备对象下面才是具体的测点。
每个节点都有一个NodeId，格式长这样：ns=2;s=Device1.Temperature。ns是命名空间索引，说白了就是给这个节点分个组，避免不同厂家的节点ID撞车；s=表示这是一个字符串标识符，后面跟的是节点在地址空间里的路径。
读数据的时候，我们关心的是Variable类型的节点。这个节点的Value属性里存的就是实际数值，配套的还有多个属性，比如DataType（数据类型）、EngineeringUnits（工程单位）、StatusCode（数据质量码）。其中StatusCode特别重要，它告诉你读上来的这个值到底可不可信——设备正常输出的时候状态码是Good，如果设备在报警或者通讯中断，即使Value字段还有数据，状态码也是Bad，上位机如果不管状态码直接拿值参与逻辑判断，是要出事故的。
2.2 如何定位要读的测点
定位测点有两种方式。一种是在UAExpert里浏览整个地址空间树，慢慢展开找到想要的节点，然后查看它的NodeId。另一种是设备厂商直接提供一份节点表给你，PDF或者Excel都行，告诉你要读的测点对应哪个NodeId。
我在实际项目中，这两种方式都会用。厂商提供的节点表是首选，但偶尔会有表里的NodeId和实际设备不一致的情况，这时候就得上UAExpert去比对，以实际浏览到的为准。UAExpert的浏览功能做得比较好，可以看节点属性、数据类型，还能直接测试读取，非常适合用来排查节点地址问题。
2.3 会话、订阅与数据变化通知
OPC UA的Session我类比成你在服务器端的登录凭证。客户端连接Server之后，第一步就是建立Session，之后的读、写、订阅操作都基于这个Session。如果设备端限制并发会话数（很多设备默认2到5个），会话泄漏就是个很头疼的问题，后面我会讲怎么避免。
Subscription是OPC UA的推送机制。你在Client端创建一个Subscription，往里面添加MonitoredItem，然后指定发布间隔（PublishingInterval），Server就会按这个周期检查所有被监控的节点，一旦发现数值变化，就推送给客户端。这里有个关键概念叫采样间隔（SamplingInterval），它决定了Server多久检查一次数据有没有变，而发布间隔决定了缓存的数据多久推一次。两者配合使用，可以做到既及时又省网络流量。
3. 实操步骤：从建项目到跑通第一个数据
3.1 新建项目和引入NuGet包
我用Visual Studio 2022创建一个.NET 6的WinForms项目。为什么不选.NET Framework？因为新项目用LTS版本更有保障，UA-.NETStandard库对.NET 6的支持已经很成熟了，而且依赖项的处理更干净。如果你的电脑装的是.NET Framework 4.6.1以上的老环境，用Framework版也能跑，但升级维护会麻烦很多。
引入OPC UA的官方库，在NuGet包管理器里搜索OPCFoundation.NetStandard.Opc.Ua.Client，注意不是Opc.Ua，要带.Client后缀，这个是含客户端API的版本。安装的时候会自动带上Opc.Ua.Core、Opc.Ua.Client这些依赖包，不用额外手动装。
3.2 最简连接与读值
下面是最基础的一段代码，完成连接Server并读取一个节点的值：
using Opc.Ua; using Opc.Ua.Client; // 1. 配置Endpoint var endpointUrl = "opc.tcp://192.168.1.100:4840"; var endpointDescription = CoreClientUtils.SelectEndpoint(endpointUrl, useSecurity: false); var endpointConfiguration = EndpointConfiguration.Create(); // 2. 创建Session var session = await Session.Create( configuration: new ApplicationConfiguration(), endpoint: endpointDescription, updateBeforeConnect: false, checkDomain: false, sessionName: "MyCollectorSession", sessionTimeout: 60000, identity: new UserIdentity(new AnonymousIdentityToken()), preferredLocales: null); // 3. 读一个节点 var nodeId = new NodeId("ns=2;s=Device1.Temperature"); var value = await session.ReadValueAsync(nodeId); Console.WriteLine($"温度 = {value.Value}，质量码 = {value.StatusCode}");这里有几个关键参数说一下。useSecurity: false表示不启用加密和签名，这在局域网内做设备调试是可以的，但如果数据要跨公网传输，建议开启安全策略（Basic256Sha256），后面会提一下怎么配置。AnonymousIdentityToken是匿名身份，如果设备配置了用户名密码，换成new UserIdentity("username", "password")就行。
3.3 订阅实时数据变化
轮询方式简单但不高效，而且对设备端有一点压力。OPC UA的订阅机制更优雅，设备数据一变，客户端立刻就能收到通知，延迟可以做到百毫秒级。创建订阅的代码如下：
// 创建订阅 var subscription = new Subscription(session) { PublishingInterval = 500, // 发布间隔500ms KeepAliveCount = 10, LifetimeCount = 100 }; session.AddSubscription(subscription); subscription.Create(); // 添加监控项 var monItem = new MonitoredItem(subscription.DefaultItem) { StartNodeId = new NodeId("ns=2;s=Device1.Temperature"), SamplingInterval = 200, // 采样间隔200ms QueueSize = 1, // 缓存队列大小 DiscardOldest = true }; monItem.Notification += MonItem_Notification; subscription.AddItem(monItem); subscription.ApplyChanges(); // 数据变化回调 private static void MonItem_Notification(MonitoredItem item, MonitoredItemNotificationEventArgs e) { var notification = e.NotificationValue as MonitoredItemNotification; if (notification != null) { var value = notification.Value; Console.WriteLine($"{item.StartNodeId} 新值 = {value.Value}，时间戳 = {value.SourceTimestamp}"); } }这里要理解两个时间参数的区别：PublishingInterval是服务端向客户端推送消息的周期，SamplingInterval是服务端检查数值是否变化的周期。我习惯把采样间隔设得比发布间隔短一些，这样能保证在每次发布时，队列里缓存的是最新的数据，而不会因为采样太慢错过数据变化。
3.4 断线重连的处理
工业现场网络抖动是常事，断线重连是必须处理的。OPC UA库自带ReconnectHandler机制，当检测到连接异常时会触发Session.Reconnecting事件，你可以在这里做重连逻辑：
session.Reconnecting += (sender, e) => { Console.WriteLine($"连接异常，尝试重连... 第{e.ReconnectCount}次"); }; session.KeepAlive += (sender, e) => { if (e.Status == ServiceResult.Good) { Console.WriteLine("连接正常"); } else { Console.WriteLine($"连接异常：{e.Status}"); } };我的习惯是同时订阅KeepAlive事件做心跳监控，一旦状态不是Good就记录日志，连续几次都不是Good就直接调用session.Reconnect()主动重连，比被动等库自己恢复要可靠一些。重连之后，原来创建的Subscription和MonitoredItem通常会自动恢复（取决于库版本和设备端行为），但保险起见我在重连成功后检查一下订阅状态，必要时重建订阅。
4. 常见问题与排查技巧实录
4.1 报错速查表
| 错误现象 | 原因分析 | 解决办法 |
|---|---|---|
BadNodeIdUnknown | 节点ID不存在 | 用UAExpert浏览确认NodeId拼写和命名空间索引是否正确 |
BadSessionIdInvalid | Session已失效（超时或被Server端回收） | 检查SessionTimeout设置，大于60秒；捕获SessionReconnect事件 |
BadSecurityModeRejected | 客户端与Server的安全策略不匹配 | 对比双方支持的安全策略，先用None调试通再换加密 |
BadCertificateUntrusted | 客户端证书不被Server信任 | 把客户端证书导入到Server的信任列表，或用checkDomain: false绕过域名校验 |
BadUserAccessDenied | 匿名身份无权限 | 改用账号密码认证，或者在Server端给匿名用户授权 |
| 订阅收不到数据 | 发布间隔太长/节点值未变化/订阅被服务端回收 | 确认设备端有数据变化、缩短PublishingInterval为1000ms以下，查看Subscription的PublishingEnabled属性 |
| 中文乱码 | 节点编码格式不匹配 | 检查ns前缀的使用和字符串标识符，确认编码为UTF-8 |
连上了读值却全是BadWaitingForInitialData | 设备端还在初始化，数据尚未就绪 | 等待设备运行稳定后再读取，或对这类节点设置宽松的重试逻辑 |
遇到问题先别急着改代码，抓包和看服务端日志往往能更快定位。OPC UA的支持比较规范，服务端日志里一般会有明确的原因描述。
4.2 连不上Server时先排除环境问题
连不上Server的时候，有七成概率不是代码问题，而是环境问题。我自己排查的顺序是先确认Server是否正常启动，可以用UAExpert去连一次，能连上说明Server没问题、协议层面是通的，问题大概率出在客户端配置。然后再检查防火墙是否放行了4840端口，用telnet ip 4840试一下通不通。接着确认Endpoint地址是否正确，有些设备开放了多个Endpoint（比如一个安全加密、一个不加密），选错也可能连不上。最后再看安全策略是否匹配。按这个顺序排查，大部分连接问题都能解决。
这里提醒一下：在生产环境，useSecurity: false确实方便，但不安全。如果是采集生产数据、数据要进数据库或云平台的，务必启用加密和签名。
4.3 基于实际踩坑补充的几个经验
坑一：Session不释放导致Server端并发会话被占满。有些设备限制并发会话数为2~5个，调试期间频繁中断程序、重新运行，旧Session没有被正确释放，新Session又建不起来，就会报BadTooManySessions。解决方法是在程序退出或重新连接前显式调用session.Close()，并且做好try-catch-finally。
坑二：订阅的队列大小设置不当导致丢数据。QueueSize = 1意味着只在缓存里保留最新一条数据，如果你发布间隔500ms，但数据处理逻辑耗时超过500ms，数据就会被覆盖丢弃。对实时监控来说通常没问题，但如果要做数据存证，最好把QueueSize调大点，比如10或者更大，然后在Notification里快速把数据放到内存队列，让后台线程慢慢写库。
坑三：批量读多个节点比循环读快得多。市面上主流设备的响应能力有限，你一条一条读100个节点，每条消息的等待时间累加起来差距就出来了。用session.ReadAsync一次传一个ReadValueIdCollection批量读，往往比循环读快3到5倍。代码里用ReadValueIdCollection构造一批要读的节点，一次性发出去，性能会好很多。
坑四：不要在Notification回调里做耗时操作。订阅回调跑在客户端库的工作线程上，如果你在回调里写数据库、做复杂计算，会阻塞这个线程，影响后续消息的接收，严重时甚至导致订阅超时被服务端关闭。正确做法是回调里把数据丢到ConcurrentQueue<T>或Channel<T>里，由独立的后台线程去消费。
坑五：用UAExpert当“字典”是最靠谱的。厂商给的节点表格式再规范，也挡不住设备固件版本不一致的坑。在UAExpert里连上设备，直接看地址空间树里真实的节点路径和NodeId，复制出来用，比我刚入行时对着文档猜NodeId不知道高效了多少倍。
我在实际项目里还养成了一个习惯：把系统中所有节点ID集中存放在一个配置类里，用常量或者静态只读字段定义，避免在业务代码里到处散落字符串。这样万一现场设备的节点路径变了，只需要改配置类，不用全局搜索替换。
另外，上位机程序的日志一定要打好。不是Debug.WriteLine那种，而是要记录到文件。OPC UA采集这块，我强烈建议用NLog或者Serilog，按天或者按文件大小滚动，记录每次连接、断线、重连、读值异常这些关键事件。我曾经在客户现场排查一个偶发的采集中断问题，来回跑了好几趟，最后是靠日志里的一条Reconnecting记录才发现是设备端在半夜做了重启，导致会话被重置。没有日志，这类问题根本没法定位。
最后再分享一个小技巧：如果设备端的OPC UA Server在启动之后需要几十秒才能完成初始化，客户端在这期间去连接，经常会报各种奇怪的错误。这时候加一个启动延迟或者重试机制，等设备准备就绪后再连，就能避免很多莫名其妙的问题。我做采集程序时，首选项里一般会加一个“启动延迟N秒”的配置项，方便现场调试时灵活调整。
这个示例项目我现在已经固化成团队内部的采集框架了，后续还计划扩展历史数据读取（ReadHistory）、方法调用（Call）这些功能。如果你也在折腾OPC UA采集，建议先把这篇文章里的基础代码跑通，再根据自己的业务场景去扩展，会比直接从文档啃协议高效得多。
本文还有配套的精品资源，点击获取
