OPC UA通用架构代码实战：基于.NET Standard的C#客户端/服务器开发

简介基于.NET Standard规范编写的OPC统一架构通用代码工程面向需要在不同.NET环境中实现工业数据交换的开发者、初学者以及自动化项目集成人员。压缩包大小约10.72MB内附完整的DEMO演示项目与工程源码目录结构清晰便于快速定位客户端、服务器和配置相关模块。该资源已有342人学习下载具备一定的参考热度。通过运行与分析演示程序读者可以逐步掌握建立安全连接、读写节点数据、订阅实时变化、处理异常与安全策略等核心操作并能够将这套通用架构迁移到自己的工业自动化、物联网或远程监控项目中。代码基于标准化接口实现具备良好的跨平台复用性在不同.NET实现上均可运行可显著降低后续二次开发与适配成本亦便于团队内部共享与迭代维护。1. 先把话说明白这份 OPC UA 通用架构代码到底能帮你走到哪一步做工业上位机或者 MES 对接的人迟早会撞上同一堵墙设备端和信息系统之间要通数据但西门子走 S7 协议、三菱走 MC 协议、老设备还挂着 Modbus每接一种新设备就要重新写一套通信层。OPC UA 就是来解决这个问题的——它把不同厂商的通信协议统一成一个标准化的数据交换模型客户端只需要认识一种协议就能读写任意支持 OPC UA 的服务器。但这个压缩包不是给你讲概念的它是一份基于 .NET Standard 实现的完整 OPC UA 客户端/服务器架构源码自带可运行的 DEMO核心目的只有一个让你在不接触底层协议细节的前提下用 C# 快速写出能连接真实 OPC UA 服务器的程序。适合两类人一类是被 PLC 数据对接逼着上手的.NET 工程师另一类是正在评估 OPC UA 技术选型、想先花半天跑通一个最小验证的架构师。打开压缩包里面是标准 Git 仓库结构源码、配置、DEMO 一个不少下面我带你把这条路走通。2. OPC UA 与 .NET Standard先搞懂这套架构代码为什么能跨平台跑起来2.1 OPC UA 不只是协议栈数据模型、安全模型与服务集是三个层次很多初次接触 OPC UA 的人容易把它理解成「一种比 Modbus TCP 高级一点的通信格式」这个认知会在你真正写代码时带来麻烦。OPC UA 不是一个报文格式它是三个层次叠加的规范。最底层是传输协议默认走 TCP 端口 4840也支持 HTTPS 与 WebSocket 封装往上一层是数据模型也就是地址空间Address Space的组织方式——服务器里的每个变量、对象、方法都以节点Node的形式挂在一棵节点树NodeTree上节点之间有引用关系客户端通过遍历这棵树就能发现设备的能力而不是靠一份写死的寄存器地址表最上层是服务集Service Set定义了客户端与服务器之间的交互动作比如读取Read、写入Write、订阅Subscribe、浏览Browse。这三个层次对应到 UA-.NETStandard 的代码结构里就是 Transport、UaModeler 生成的数据结构以及 ISession 接口上的那十几个方法。明白了这层关系你就知道为什么二手 OPC 教程总在强调「先 Browse 再 Read」——因为在 OPC UA 的世界里你面对的不是一张寄存器表而是一棵带语义的树。生产线上的一台电机在地址空间里可能是一个 Motor 对象节点下面挂 Current、Speed、Temperature 三个属性节点每个属性节点带单位、工程值范围、时间戳。这种设计带来的好处是自描述客户端不需要提前知道设备的寄存器分布通过 Browse 就能拿到整棵设备数据树。坏处是概念多新手容易被 NodeId、ReferenceType、DataType 这些名词绕晕。UA-.NETStandard 这套架构的价值在于它把这三个层次封装成了相对好用的 API你不需要手写二进制报文只需要调用ReadValueAsync或者Subscribe这类方法。2.2 UA-.NETStandard 的工程结构从 NuGet 依赖到启动配置解压UA-.NETStandard-master之后先别急着用 Visual Studio 打开花两分钟看一下目录结构。这个仓库是 OPC Foundation 官方 .NET 实现的镜像核心解决方案文件在根目录里面大致分几类工程Opc.Ua.Core是核心库包含协议栈、地址空间模型、序列化与安全通道Opc.Ua.Client是客户端高级封装Session、Subscription、MonitoredItem这几个你马上会用到的类都在这里Opc.Ua.Server是服务端封装如果要写一个模拟器或者网关重点关注剩下的Applications目录里放着各种示例工程DEMO 就在这个目录下。用 Visual Studio 2022 打开解决方案先编译Opc.Ua.Core项目。这里有个新手常踩的坑如果你是第一次拉取源码NuGet 还原可能会报错因为部分依赖包需要指定源。我一般会在解决方案上右键「管理 NuGet 程序包」确认程序包源里有nuget.org然后重新还原一次。编译完成后找到 DEMO 对应的客户端工程通常是UA Sample Client这类名字设为启动项目直接 F5。跑起来后你会看到一个连接配置界面需要填服务器地址、安全策略、用户名密码如果是匿名模式就留空。这套结构的好处是DEMO 工程本身就是最好的学习入口读它的MainForm或Program.cs就能看到整个客户端生命周期的骨架——创建ApplicationConfiguration、建立Session、执行操作、释放资源。// 初始化 ApplicationConfiguration这是所有 OPC UA 操作的起点 var config new ApplicationConfiguration { ApplicationName MyOpcUaClient, ApplicationUri urn:MyOpcUaClient, SecurityConfiguration new SecurityConfiguration { // 应用证书路径首次运行会自动生成 ApplicationCertificate new CertificateIdentifier { StoreType Directory, StorePath pki }, // 信任对方服务器证书DEMO 阶段建议先信任所有 TrustedPeerCertificates new CertificateTrustList { StoreType Directory, StorePath pki/trusted }, // 安全策略列表None 表示不加密不签名 SecurityPolicies new ListSecurityPolicy { SecurityPolicy.Basic256Sha256, SecurityPolicy.None } }, TransportConfigurations new ListTransportConfiguration(), TransportQuotas new TransportQuotas { MaxMessageSize 65536 } };这段代码是 DEMO 里初始化配置的典型写法。ApplicationName和ApplicationUri用于标识客户端身份服务器端会记录这两项到会话日志SecurityConfiguration里的证书路径决定密钥对存到哪里首次运行会自动生成自签名证书SecurityPolicies列表可以理解为「我愿意用哪些加密方式跟服务器握手」Basic256Sha256是目前工业场景最常用的安全策略None是明文模式调试时省事但生产环境别用。参数按需调整如果连接国外服务器或特殊设备可能还要加Aes128_Sha256_RsaOaep之类的策略但 DEMO 阶段保持这三行就能覆盖大多数场景。3. 把 DEMO 跑通客户端连接、节点读取与写入的完整链路3.1 创建 SessionEndpointUrl、超时参数与证书处理是三个最常改的地方配置对象准备好之后下一步是建立会话。OPC UA 的会话Session本质上是客户端与服务器之间的一条逻辑连接等价于 HTTP 的 Keep-Alive 连接——物理 TCP 通道可以断开重连但 Session 维持了认证状态和订阅关系。UA-.NETStandard 里创建 Session 的典型代码分三步加载配置、选择端点、创建会话对象。// 加载配置 await config.ApplicationCertificate.LoadPrivateKey(config); // 选择端点 var endpoint await CoreClientUtils.SelectEndpointAsync( config, opc.tcp://192.168.1.100:4840, useSecurity: true); // 创建 Session var session await Session.Create( config, endpoint, false, MySession, 60000, new UserIdentity(user, password), null);SelectEndpointAsync这一步干了件重要的事它向服务器发送 GetEndpoints 请求拿回服务器支持的端点列表然后按你传的useSecurity参数挑选一个匹配的端点。注意endpoint里的EndpointUrl可能是服务器内部网卡地址跟外部客户端不在同一网段时会出现「能连上但选择端点超时」的诡异问题后面避坑章节会细说。Session.Create的参数里60000是会话超时时间毫秒意思是如果超过这个时间没有任何请求服务器会回收会话UserIdentity支持匿名、用户名密码、证书三种模式DEMO 里最常见的是UserIdentity(user, password)这种。会话创建成功后的第一件事我建议先调用session.ReadValueAsync读取服务器的时间节点这个节点的 NodeId 是i2253官方定义的 Server 对象下的 2553 号节点。它能确认两件事一是会话确实建立成功了二是你的读写链路是通的。很多新手跳过我这一步直接去读设备变量结果报错BadNodeIdUnknown时根本分不清是会话问题还是节点路径写错了。// 读取服务器时间节点确认会话链路通畅 try { var serverTime await session.ReadValueAsync( new ReadValueId { NodeId new NodeId(2253), AttributeId Attributes.Value }); Console.WriteLine($服务器时间: {serverTime.Value}); } catch (ServiceResultException e) { Console.WriteLine($读取失败, 状态码: {e.Result.StatusCode}, 原因: {e.Result}); }ReadValueAsync返回的是一个DataValue对象它的.Value属性里装的是真正的数据值但要注意类型可能是DateTime、string或Variant封装的任意类型。Attributes.Value是你要读取的属性——OPC UA 的节点有多个属性Value 是数据值DisplayName 是显示名Description 是描述但 90% 的场景你只关心 Value。ServiceResultException是 UA-.NETStandard 里最核心的异常类型它的Result属性里带StatusCode和符号名比如BadNodeIdUnknown表示节点不存在BadUserAccessDenied表示权限不够、BadTimeout表示请求超时。排错时盯着这个状态码就够了不用看堆栈。3.2 读节点与写节点NodeId 定位和 DataValue 类型转换是核心读取服务器时间只是热身真正上场的是设备变量。在 OPC UA 地址空间里每个变量节点有一个唯一的 NodeId格式最常用的是ns和i或s的组合——ns是命名空间索引i是整数节点 IDs是字符串节点 ID。比如西门子 S7-1500 的 OPC UA 服务器里一个 DB 块变量可能长这样ns3;sDB_1.IntVar1。这个地址哪来的不是猜的是你用 UA Expert 之类的客户端工具 Browse 出来的或者来自设备厂商的 OPC UA 地址表文档。// 读取设备变量节点 var nodeId new NodeId(DB_1.IntVar1, 3); // ns3, sDB_1.IntVar1 DataValue value await session.ReadValueAsync( new ReadValueId { NodeId nodeId, AttributeId Attributes.Value }); // 取出原始值并做类型转换 if (value.Value is int intVal) { Console.WriteLine($DB_1.IntVar1 {intVal}); } else if (value.Value is float floatVal) { Console.WriteLine($DB_1.IntVar1 {floatVal}); } else { // 常见情况是服务器返回的是 Variant 包装类型 var variant (Variant)value.Value; Console.WriteLine($DB_1.IntVar1 {variant.Value}); }写入是类似的操作区别在于你要构造一个DataValue再塞给WriteAsync。这里有两个高频翻车点一是写数据类型不匹配比如节点定义是Float你传了个int进去服务器直接返回BadTypeMismatch二是写权限不够匿名会话访问很多工业服务器时只有读权限写操作返回BadNotWritable。// 写入节点值类型必须严格匹配否则服务器返回 BadTypeMismatch var writeValue new WriteValue { NodeId new NodeId(DB_1.IntVar1, 3), AttributeId Attributes.Value, Value new DataValue(new Variant(42)) }; var results await session.WriteAsync(new WriteValueCollection { writeValue }); // 返回值是一个状态码集合逐个检查 foreach (var result in results) { if (StatusCode.IsBad(result.StatusCode)) { Console.WriteLine($写入失败: {result.StatusCode}); } else { Console.WriteLine($写入成功); } }WriteValue里的Value必须用new Variant()包装这是 UA-.NETStandard 的类型系统要求——所有传递给协议栈的值都得是Variant类型。StatusCode.IsBad是判断操作是否成功的标准方式不要用 StatusCode.Good去比较因为 Result 里可能带额外诊断信息IsBad会正确识别所有失败状态。写入的工程值范围校验在服务器端做客户端传值超出量程服务器返回BadOutOfRange这点跟 Modbus 那种「你写什么我就收什么」完全不同。4. 订阅与浏览从「读一次」到「持续监听」的工程化跳跃4.1 用 Subscription 和 MonitoredItem 实现报警级别的高效采集轮询读变量虽然简单但十个变量以上就暴露出两个致命短板一是网络开销随变量数量线性增长二是数据变化时序可能被轮询间隔错位——你永远不知道自己错过了一次瞬时变化。OPC UA 的订阅机制Subscription就是为了解决这个问题设计的客户端创建订阅往订阅里添加监控项服务器在监控项的值变化时主动推送通知客户端不需要反复发请求。UA-.NETStandard 里用起来非常直接创建订阅对象、添加监控项、绑定回调函数大概二十行代码。需要注意的核心参数是PublishingInterval发布周期和SamplingInterval采样周期前者是服务器检查订阅是否该发通知的时间间隔后者是服务器采集底层数据的时间间隔。两者不是一回事比如采样间隔 100ms、发布间隔 1000ms意味着服务器每 100ms 检查一次值有没有变但有变化后不是立刻推给你而是攒到 1000ms 的发布周期才统一推送。// 创建订阅发布周期设为 500ms var subscription new Subscription { PublishingInterval 500, PublishingEnabled true, MaxNotificationsPerPublish 100 }; session.AddSubscription(subscription); subscription.Create(); // 创建监控项指定采样间隔 100ms var monitoredItem new MonitoredItem { StartNodeId new NodeId(DB_1.IntVar1, 3), AttributeId Attributes.Value, SamplingInterval 100, QueueSize 10, // 队列长度值变化太快来不及处理时先缓存 DiscardOldest true // 队列满了丢最旧的数据 }; // 绑定通知回调这是数据到达客户端的真正入口 monitoredItem.Notification (MonitoredItem item, MonitoredItemNotificationEventArgs e) { var update item.LastValue; Console.WriteLine($新值: {update.Value}); }; subscription.AddItem(monitoredItem); subscription.ApplyChanges();QueueSize和DiscardOldest这两个参数是处理高频变化量的关键。假设采样间隔 100ms但客户端处理一次通知要 300ms队列就能在这段延迟里先缓存数据。QueueSize 10表示最多缓存 10 条第 11 条到达时根据DiscardOldest的取值决定丢最旧还是丢最新——采集趋势数据选DiscardOldest true比较合理因为旧值的价值低于新值如果是在做报表每条都得留那就要加大队列或者把采样间隔调大。monitoredItem.Notification回调里拿到的item.LastValue直接是DataValue但要注意这个回调跑在服务器通信线程上不要在回调里做耗时操作否则会阻塞后续通知的接收正确做法是把数据丢进线程安全的ConcurrentQueue让业务线程自己去消费。4.2 Browse 节点树从 Server 根节点出发找到你的目标变量写 OPC UA 客户端时最烦的一件事是你知道设备上有个变量叫温度可 NodeId 是多少藏在地址空间哪一层答案是靠 Browse 去探索。UA-.NETStandard 里 Browse 操作的基本流程是从某个起始节点通常是 Objects 文件夹出发拿到它的所有子节点引用然后递归或按需逐层展开。// 执行一次浏览从 Objects 文件夹开始只查一层 var browseResult await session.BrowseAsync( new BrowseDescriptionCollection { new BrowseDescription { NodeId new NodeId(ObjectIds.ObjectsFolder), BrowseDirection BrowseDirection.Forward, ReferenceTypeId ReferenceTypeIds.HierarchicalReferences, IncludeSubtypes true, NodeClassMask (uint)(NodeClass.Object | NodeClass.Variable), ResultMask (uint)BrowseResultMask.All } }); // 遍历引用结果打印子节点信息 foreach (var reference in browseResult.Results[0].References) { Console.WriteLine($NodeId: {reference.NodeId}, DisplayName: {reference.DisplayName}, NodeClass: {reference.NodeClass}); }BrowseDirection.Forward意味着拿到起始节点的子节点而不是父节点ReferenceTypeId用HierarchicalReferences表示只看层级引用过滤掉那些属性引用、类型引用等非结构关系NodeClassMask限制只返回对象和变量节点跳过方法节点——实际设备里有些方法节点是写参数用的浏览时返回一堆方法会干扰你的判断ResultMask.All表示返回结果里带上显示名、类型定义等全部元数据。这段代码跑出来后你会看到一个类似文件系统的目录结构一层层展开直到找到DB_1或者Motor这类你想读的对象。浏览时有个容易忽略的细节一台大型 PLC 的地址空间可能有几千个节点一次 Browse 返回不下会给你一个ContinuationPoint。这个续传点是 UA-.NETStandard 里比较隐蔽的概念——如果一次返回结果太多服务器会截断并返回一个不透明指针下次请求时带上它就能从上次中断的地方继续取剩下的节点。实际写代码时一定要检查结果里有没有ContinuationPoint有就循环调用BrowseNextAsync直到取完。不然你会看到「节点树浏览了一半就没了」的诡异现象还以为是服务器有问题。5. 避坑OPC UA 客户端开发最常见的五个翻车现场5.1 现象一代码在本地跑得好好的部署到现场连不上服务器原因几乎可以锁定在证书信任上。开发环境用的是自己签发的应用证书现场服务器的证书信任列表里没有你的证书握手阶段直接失败。UA-.NETStandard 的证书管理逻辑是你的客户端证书要加到服务器的信任列表里服务器的证书也要被客户端信任两边的信任列表缺一个都不行。解决方法是先做证书交换。找到客户端程序目录下的pki/trusted文件夹里面是它生成的公钥证书把这个证书拷到服务器端程序的trusted目录反之亦然。如果两台机器时间不同步证书有效期校验也会失败——先对一下系统时间再查证书。我在现场遇过一次特别隐蔽的开发机的系统时间跟现场服务器差了 8 小时刚好把证书的有效期卡在边界上折腾了半天才发现是时区配错了。5.2 现象二能 Ping 通服务器 IP但创建 Session 时永远超时这个问题的经典原因是SelectEndpointAsync返回的端点 URL 是服务器的主机名或内网 IP客户端无法解析。OPC UA 服务器的端点 URL 是服务器自己声明的比如服务器声明自己是opc.tcp://PLC01:4840但你的客户端在另一台机器上PLC01这个主机名解析不了TCP 连接就卡在 DNS 解析这一步。解决思路是强制用服务器 IP 地址覆盖端点 URL。拿到endpoint对象后手动更新它的EndpointUrl属性把主机名替换成 IP再传给Session.Create。更省事的办法是直接在配置里把服务器地址写成 IP 形式但有些服务器只监听主机名绑定的地址从 IP 连会被服务器拒绝。这种情况我会先用EndpointDescription里的Server.Uri字段检查服务器声明的身份再决定是否覆盖 URL。5.3 现象三写入操作返回值不是错误但数据就是没写进 PLC可能原因有两个。第一个是写入的工程值溢出了变量量程PLC 的 DB 块变量如果定义是 INT范围 -32768 到 32767你写个 50000 进去服务器不会报网络错误但会返回BadOutOfRange。第二个是写地址错了——你写的是变量的 Value 属性但有些 PLC 的 OPC UA 映射要求写Value属性之前必须先设置EngineeringUnits或者EURange两个属性是联动的。解决方法是先读取EURange属性确认量程再构造写入值。用 UA Expert 连接同一台服务器手动写一次值看返回的状态码是什么——这个工具能显示完整的StatusCode符号比在代码里靠猜快得多。写进去但设备没反应的情况还要检查UserIdentity的权限等级很多 PLC 默认只给读权限写权限要在 PLC 程序里单独开。5.4 现象四订阅回调不触发或者触发后数据明显滞后订阅回调不触发先查两件事。第一PublishingInterval和SamplingInterval是不是设成了 0——这在 UA-.NETStandard 里表示「客户端不指定完全由服务器决定」而很多服务器实际实现里会把这种配置当成最小间隔来处理导致发布频率极低。第二检查订阅是否成功添加到 Sessionsubscription.Create()之后再确认subscription.Id不是InvalidId。数据滞后的问题更隐蔽。默认情况下MonitoredItem的QueueSize是 1服务器每次只保留最新值如果你的回调函数处理速度跟不上发布速度数据会持续覆盖。把QueueSize调大、DiscardOldest设为false可以看到完整的序列。我在实际项目里碰到过一次滞后 5 秒的情况排查后发现是回调函数里同步调了一个数据库写操作把通信线程堵住了后来改成丢队列异步消费才解决。5.5 现象五从网上下载的官方 DEMO 编译通过但打开就崩溃这是最让人火大的一种翻车代码没毛病环境有问题。UA-.NETStandard 对 .NET Runtime 版本有要求老版本仓库要 .NET Framework 4.8 或 .NET 6 以上装了个 4.7.2 就跑不起来。另外有些 DEMO 依赖Opc.Ua.Configuration来生成自签名证书首次运行要写文件到证书目录如果你的程序安装目录在Program Files下没有写权限就会崩溃。解决方法是先看崩溃日志里的异常类型DirectoryNotFoundException就是证书路径问题FileLoadException多半是 .NET 版本问题。我自己的习惯是第一时间把证书目录指向AppDomain.CurrentDomain.BaseDirectory下的pki子目录确保有写权限并且所有依赖包通过 NuGet 统一还原到最新稳定版不贪图老版本——某些老版本的 UA-.NETStandard 在 .NET 8 下有序列化兼容问题升级到最新版一般都能解决。6. 进阶技巧把 DEMO 改造成你的第一个 OPC UA 网关服务DEMO 跑通只是第一步真实场景里你不会只想在控制台里打印变量。最常见也最实用的改造方向是把它做成一个网关服务——把多台 PLC 的 OPC UA 数据汇聚起来转发给 MES/数据库/云端。我自己做过的方案是用 .NET 的BackgroundService承载 OPC UA 客户端把采集到的数据经过转换后写入一个中间层供上层系统统一消费。改造的关键不是写代码是想清楚数据流。OPC UA 客户端只负责跟服务器通信它产出的是一堆DataValue网关需要一个统一的内部数据模型比如DeviceData { DeviceId, TagName, Value, Timestamp, Quality }这个结构把所有设备的数据归一化成同一种格式再交给下游。订阅回调在通信线程上触发不能直接写数据库我一般会在回调里把DeviceData丢进ConcurrentQueue单独起一个消费者线程批量入库。还有一个细节是断线重连OPC UA 服务器重启或者网络闪断Session 会失效网关需要监听session.KeepAlive事件收到ServiceResultException时销毁旧 Session、重新走一遍连接流程。很多新手会忽略这个导致网关跑了两天突然数据全停进程没崩但状态已经死了。// 网关服务核心骨架断线重连 数据转发队列 public class OpcGatewayWorker : BackgroundService { private readonly ConcurrentQueueDeviceData _queue new(); protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { try { // 建立会话并订阅 await ConnectAndSubscribeAsync(stoppingToken); // 等待会话断开事件断开后重新循环 await _sessionClosed.Task.WaitAsync(stoppingToken); } catch (Exception ex) { // 记录并等待几秒后重连 Console.WriteLine($连接断开: {ex.Message}); await Task.Delay(5000, stoppingToken); } } } }代码里没有花哨技巧但工程化价值极高。_sessionClosed是一个TaskCompletionSource挂在session.KeepAlive事件上——正常期间一直在续期一旦会话真的断了这个 Task 完成外层循环捕获异常并重连。ConcurrentQueue是临界资源任何线程都可以安全入队消费者线程通常是一个Channel或者单独的读写循环取出数据落库。这套骨架我后来在三个项目里复用唯一的改动是对接的服务器地址和变量地址表不同。从那以后我每次拿到任何 OPC UA 相关的 demo 或者源码都会强制自己先走一遍「配置初始化 → 建立会话 → Browse 发现 → 读取验证 → 订阅监听」这五步完整跑通才开始改业务代码。因为 OPC UA 的问题永远藏在链路最底层不把基础链路摸干净后面做的所有封装都是在沙子上盖楼。希望这份源码和这篇文章帮到你也是少走这些弯路的开始。本文还有配套的精品资源点击获取