简介：OPC UA是工业自动化领域广泛采用的跨平台通信标准，这份代码资源基于.NET Standard实现了一套通用架构，并附带可运行的DEMO，专门面向想要在.NET环境中快速搭建OPC UA客户端或服务器、理解其数据模型与安全机制的开发者。压缩包约10.72MB，内部以源代码、工程文件及相关配置文件为主，结构完整清晰，便于直接查看核心实现、本地编译并运行演示应用，也可作为后续二次开发的基础框架。已有342人学习下载，通过DEMO可以逐步上手连接服务器、读写节点数据、订阅实时变化等典型操作，从而掌握OPC UA与工业设备交互的关键流程。此外，资源还体现了跨平台特性，代码可在.NET Core、.NET Framework等多种实现中复用，降低了集成门槛。对于物联网、制造业自动化及远程监控等实际场景，这份通用架构代码具有较高的参考价值，尤其适合初学者快速建立对OPC UA的整体认知并投入实际项目。

1. 现场几十台设备，每种协议写一个采集程序，这种日子该到头了：OPC UA 统一架构 DEMO 到底解决什么

做过产线数据采集的工程师大概都有过这种经历：PLC 走 Modbus 要写一套，数控机床走厂商私有协议又要写一套，传感器走以太网口再写一套，最后每台设备的数据格式还不一样，MES 那边等着要，你只能熬夜写转换脚本。OPC UA 不是某个厂商的新协议，而是把“读设备数据”这件事统一成一套地址空间模型。UA-.NETStandard-master 这个目录名对应的就是 OPC Foundation 发布的 .NET 参考实现，里面带的 opc_ua_demo 可以让你在几分钟内用同一套代码对接 PLC、传感器、数控机床，把设备运行状态数据读成统一结构。这篇笔记不聊泛泛的概念，直接带你把这个通用架构代码拆开、跑通、改到能上产线。

2. 先看懂 UA-.NETStandard 通用架构：OPC UA 协议栈的地址空间与订阅模型

2.1 为什么是 .NETStandard：跨框架的 OPC UA 客户端该怎么选型

很多第一次接触 UA-.NETStandard 的人会把它当成一个“库”，其实它是一个协议栈的 .NET 实现。OPC UA 的完整通信涉及安全策略、证书管理、数据编码、会话管理、订阅调度，这不是一个普通的通信库能覆盖的。.NETStandard 是这个协议栈的兼容层，这意味着你编译出来的客户端 DLL 既能在 .NET Framework 4.7 上用，也能在 .NET Core 3.1、.NET 5/6/7/8 上跑。我经常被问到“服务端在 Linux，客户端在 Windows，能不能用”，答案是能，因为 .NETStandard 只是把底层 OS API 抽象掉了，OPC UA 的二进制协议和加密逻辑完全跨平台。

选型时优先看项目里已有的 .NET 环境。如果你们 MES 是 .NET Framework，那用 UA-.NETStandard 编译出的标准版最稳；如果是新项目，建议直接上 .NET 8，因为官方参考实现对新版本的支持越来越激进，而且内存占用明显比 Framework 低。不要自己去封装 Socket 报文，OPC UA 的报文结构里光扩展对象头就有好几种，手写等于给自己挖坑。你要做的只是引用 Opc.Ua.Client 和 Opc.Ua.Core 这两个包，把精力花在节点解析和数据映射上。

2.2 从节点模型到地址空间：先跑通一次服务器浏览

OPC UA 的核心抽象是“地址空间”，它把设备里的所有数据组织成一棵树，树的每个节点都有 NodeId、BrowseName、Value 等属性。PLC 里的 DB 块、传感器的温度寄存器、数控机床的轴坐标，全部被映射成这棵树上的叶子节点。UA-.NETStandard 里浏览地址空间的方法很直接：先建立会话，再调用 Browse 或 BrowseNext。下面是最小可用的服务器浏览代码：

// 引入必要命名空间 using Opc.Ua; using Opc.Ua.Client; // 1. 配置终端 var endpointUrl = "opc.tcp://192.168.1.10:4840"; var config = new ApplicationConfiguration { ApplicationName = "MyDemoClient", ApplicationUri = "urn:MyDemoClient", SecurityConfiguration = new SecurityConfiguration { ApplicationCertificate = new CertificateIdentifier { StoreType = "Directory", StorePath = @"C:\certs\client" }, TrustedPeerCertificates = new CertificateTrustList { StoreType = "Directory", StorePath = @"C:\certs\trusted" } } }; await config.LoadAsync(); // 加载证书配置 // 2. 创建会话 var endpointDescription = CoreClientUtils.SelectEndpoint(endpointUrl, useSecurity: false); using var session = await Session.Create( config, endpointDescription, clientCertificate: null, sessionName: "MySession", sessionTimeout: 60000, identity: new UserIdentity("anonymous"), preferredLocales: null); // 3. 浏览根节点，找到“设备”分支 var browseResult = await session.BrowseAsync( session.NamespaceUris.ToArray(), new BrowseDescription { NodeId = ObjectIds.RootFolder, BrowseDirection = BrowseDirection.Forward, ReferenceTypeId = ReferenceTypeIds.HierarchicalReferences, IncludeSubtypes = true, NodeClassMask = (uint)NodeClass.Object | (uint)NodeClass.Variable, ResultMask = (uint)BrowseResultMask.All }); // 4. 打印第一层节点的名称 foreach (var refItem in browseResult.References) { Console.WriteLine($"节点：{refItem.DisplayName}"); }

这段代码里有几个关键参数要解释一下。useSecurity: false是方便本地调试，真正上产线一定要开启安全策略；UserIdentity("anonymous")是匿名认证，现场如果开启了用户名密码就换成new UserIdentity("user", "pass")。BrowseDescription里的NodeClassMask决定了你关心的是对象还是变量，一般采集会同时要 Object 和 Variable。BrowseAsync返回的是引用集合，不住的层次结构可以继续对每个子节点递归调用。

跑通这一步就说明你的环境没问题，接下来才进入真正的业务：读取数据。

3. 把 DEMO 跑起来：用 OPC UA 协议读取 PLC 与数控机床运行状态

3.1 最小可用客户端代码：连接、认证、读值

很多人拿到 UA-.NETStandard-master 的 demo 工程，第一反应是找Program.cs然后按 F5。如果什么都没发生，那是因为 demo 默认只是一个模拟服务器，并没有连接真实设备。你需要把里面读取的节点替换成现场 PLC 或数控机床的变量节点。对于一个在车间的西门子 S7-1200，只要它启用了 OPC UA 服务器功能，你就可以像读本地内存一样读它的 DB 块。下面这段代码是实际生产里我常用的最小读值方式：

// 已经建立 session，下面直接读取指定节点 var nodeId = new NodeId("ns=2;s=DB1:Temperature", session.NamespaceUris[0]); try { var value = await session.ReadValueAsync(nodeId, CancellationToken.None); Console.WriteLine($"温度：{value.Value}，质量：{value.StatusCode}"); } catch (ServiceResultException ex) { Console.WriteLine($"读取失败，状态码：{ex.StatusCode}，原因：{ex.Result}"); }

这里最需要留神的是NodeId的写法。ns=2表示命名空间索引是 2，s=DB1:Temperature是服务器端的字符串标识符。不同 PLC 厂商的节点 ID 格式完全不同，有的用整数 ID，有的用字符串，最好先用服务器自带的 OPC UA 客户端浏览工具确认一下这个节点真实存在，再写进代码。ReadValueAsync返回的DataValue里包含 Value、StatusCode、SourceTimestamp 三个核心字段。StatusCode 是八位的质量码，Good 才代表数据有效。

读取单个值只是验证连通性，车间里几十台设备不可能一个一个轮询。OPC UA 真正的优势是订阅，让数据自己送上门。

3.2 订阅实时变化：让传感器数据自动推送

OPC UA 订阅模型由三部分组成：订阅（Subscription）、监控项（MonitoredItem）、通知（Notification）。你在客户端创建一个订阅，把感兴趣的节点作为监控项加进去，服务器会按你设定的采样间隔检查值，如果变化超过死区就推送给你。这样比 Modbus 轮询高效得多，尤其适合传感器这种高频变化的数据。

// 创建订阅，设置发布间隔 var sub = new Subscription(session.DefaultSubscription) { PublishingInterval = 1000, // 每 1000ms 发布一次通知 LifetimeCount = 120, // 会话断开后保持 120 个发布周期 MaxKeepAliveCount = 10 }; session.AddSubscription(sub); sub.Create(); // 添加监控项，监听两个节点的变化 var monitor = new MonitoredItem { StartNodeId = new NodeId("ns=2;s=DB1:Temperature", session.NamespaceUris[0]), AttributeId = Attributes.Value, SamplingInterval = 500, // 每 500ms 采样一次 QueueSize = 10, // 队列长度 DiscardOldest = true // 数据旧了直接丢弃，保证拿到最新 }; monitor.Notification += (MonitoredItem item, MonitoredItemNotification evt) => { var val = evt.GetValue(0); Console.WriteLine($"推送：{item.StartNodeId} = {val.WrappedValue.Value}"); }; sub.AddItem(monitor); sub.ApplyChanges();

参数这里有几个坑要提前讲。PublishingInterval是服务器把通知打包发给客户端的周期，如果设成 0 表示按服务器最快速度推送，现场网络不好时很容易打满带宽。SamplingInterval是服务器读取底层设备数据的周期，它必须大于等于设备能承受的轮询频率，有些老 PLC 采样太快会丢数据。QueueSize决定了两次发布之间如果积压太多变化，只保留最新的还是全留着。采集类场景我一般会设DiscardOldest = true，因为你要的是实时状态，不是补历史账。

订阅要触发通知，还需要另一个关键动作：调用sub.PublishAsync()或者让客户端在后台自动发布。UA-.NETStandard 的Session在创建后会自动管理发布请求，如果你用的是上面的代码，不需要额外处理；如果你是自己写的传输层，必须在循环里周期调用发布，否则服务器永远不会推送。

3.3 从 DEMO 到生产：把读到的数据写成统一结构

demo 里读出来的值只是零散的DataValue，要对接 MES 或数据库，你需要把这些不同设备的数据统一成一个结构体。我习惯先定义一张“设备状态表”，把设备编号、变量名、值、时间戳、质量码全部放进去。这样下游系统不管接什么设备，看到的都是同一个字段。

public class DeviceDataPoint { public string DeviceId { get; set; } // 设备唯一编号，比如 PLC1/CNC02 public string VariableName { get; set; } // 变量名，比如 Temperature public object Value { get; set; } // 实际数值 public DateTime Timestamp { get; set; } // 服务器时间戳 public bool QualityGood { get; set; } // 质量是否合格 public string Source { get; set; } // 来源节点，方便排查 } // 在监控项通知回调里填充结构 DeviceDataPoint data = new DeviceDataPoint { DeviceId = "PLC1", VariableName = item.StartNodeId.Identifier.ToString(), Value = val.WrappedValue.Value, Timestamp = evt.Value.SourceTimestamp, QualityGood = Opc.Ua.StatusCode.IsGood(val.StatusCode), Source = item.StartNodeId.ToString() };

这里有一个容易忽略的细节：Timestamp一定要用evt.Value.SourceTimestamp而不是DateTime.Now。因为服务器和设备之间可能有延迟，用源时间戳才能真实反映数据产生的时间。质量码不是 Good 的数据建议原样保留，不要直接丢弃，否则排查数据漂移时你根本不知道源头发生了什么。

到了这一步，你已经能稳定地从设备上采到数了。但 demo 里跑通和产线上 7x24 小时跑是两码事。下一章我们聊怎么把这套临时脚本重构成通用采集服务。

4. 通用架构代码落地：如何把 OPC UA 封装成可复用的采集服务

4.1 封装连接管理与重连机制

工程上最大的敌人是“进程活着，连接死了”。OPC UA 的会话有超时时间，服务器可能在网络抖动时悄悄断掉连接，如果客户端不处理，ReadValueAsync会抛异常，整个采集程序就卡死在那里。我见过很多新手在 Program.cs 里写一个 while(true) 循环，遇到异常就退出，然后靠 Windows 计划任务重启进程——这叫治标不治本。

更好的做法是把“创建会话”和“执行采集”分开。用一个后台线程专门维护会话状态，每隔几秒检查一次Connected属性，发现断开就重新初始化。注意不要直接调用Session.Create就扔在那儿，因为 OPC UA 的握手过程要交换证书，重连前要清掉旧会话状态。

private Session _session; private async Task<bool> EnsureSessionAsync() { if (_session != null && _session.Connected) return true; if (_session != null) _session.Dispose(); try { var endpointDescription = CoreClientUtils.SelectEndpoint(_endpointUrl, useSecurity: false); _session = await Session.Create(_config, endpointDescription, null, "采集服务", 60000, new UserIdentity(_username, _password), null); _session.KeepAlive += Session_KeepAlive; return true; } catch (Exception ex) { Log.Error("会话创建失败: {0}", ex.Message); return false; } } private void Session_KeepAlive(Session session, KeepAliveEventArgs e) { if (!e.Status.ServiceResult.IsBad()) return; Log.Warn("连接保活失败，等待重连"); }

KeepAlive事件是 UA-.NETStandard 提供的救命稻草。服务器会周期性发保活消息，如果客户端连续几个周期没收到，就说明连接断了。在这个事件里不要直接重连，因为事件回调有可能在阻塞线程里，最好只置个标志位，由后台循环去处理。

4.2 设计数据路由：不同设备映射到同一张状态表

不同设备的节点 ID 不同、数据类型也不同，有的温度是Double，有的开关量是Boolean。通用架构代码的价值在于，你只需要维护一张“设备点表”，把每个设备的变量名映射成标准字段，业务层就完全不感知底层差异。这张点表可以是 JSON 或数据库表，结构大致是：设备编号、协议类型、节点ID、采集名称、数据类型。

// 点表映射示例 var pointMap = new Dictionary<string, DevicePointConfig> { ["PLC1.Temp"] = new DevicePointConfig { NodeId = "ns=2;s=DB1:Temperature", TargetName = "Temperature", DataType = typeof(double) }, ["CNC01.Speed"] = new DevicePointConfig { NodeId = "ns=3;s=AxisX.Speed", TargetName = "SpindleSpeed", DataType = typeof(float) } }; // 回调里根据映射写入标准字段 var config = pointMap[dataPointKey]; object convertedValue = Convert.ChangeType(val.WrappedValue.Value, config.DataType);

这套映射方案最实际的好处是，当新增一台设备时，你不需要改代码，只需要在点表里加几行配置。生产现场换设备、加测点是非常频繁的事，如果不做映射层，每次改完连编译发布都来不及，更别提热更新了。

4.3 用性能参数反向调优：会话超时、队列长度与发布间隔

很多人把 UA-.NETStandard 的参数照抄一遍就不管了，实际上这些参数直接影响采集服务能不能长时间稳定运行。我调试过一台数控机床，采集频率一高服务器就不响应，最后发现是客户端的发布请求队列太短导致服务器停止推送。我当时用几个关键参数做了组合调整，你可以按这个思路调试：

记住一个原则：OPC UA 的设计初衷是“数据变化时才上报”，不是让你高频轮询。如果某几个点是慢变量（比如每小时变一次），你完全可以把 SamplingInterval 设为 30 秒，这样服务器和 PLC 的负载都会降下来。对照性能监控看 CPU 和网卡占用，当 CPU 稳定低于 15%、网卡利用率低于 3% 时，基本就是合理的。

5. OPC UA 实践避坑：从连接失败到节点读不到的 5 个真实坑

5.1 坑一：浏览器里能看到节点，代码却读不到——命名空间索引对不上

现象：用 UA Expert 之类的工具浏览服务器，能看到 “Temperature” 而且能读出值，但把 NodeId 填到自己代码里就报 BadNodeIdUnknown。

原因：OPC UA 的命名空间索引不是在协议里固定的，而是每次连接时动态协商的。UA Expert 里看到的ns=2是它自己的会话分配的，你的会话里命名空间数组可能完全不一样，尤其当服务器有多个命名空间时。

解决：不要硬编码 NodeId，而是连接后先读取服务器的NamespaceArray属性，找到命名空间 URI 再反查索引。或者用相对路径的方式引用节点：var nodeId = await session.FindNodeIdsAsync("2:Device1", "1:Temperature")，这样避开索引变化。

5.2 坑二：证书一换就连不上——安全策略与证书存储路径的玄学

现象：开发时一直用useSecurity: false，一切正常。上了产线，IT 要求必须开安全策略，结果打开后客户端一直报证书不受信任。

原因：UA-.NETStandard 的证书验证逻辑很死板，它要求客户端的证书必须在服务器的信任列表里，服务器的证书也必须出现在客户端的信任列表里。你如果只是把.pfx丢到一个文件夹里，而不去更新TrustedPeerCertificates的存储路径，验证永远失败。

解决：把服务器导出的 .der 证书放到TrustedPeerCertificates指向的目录，同时把客户端的公钥证书导出给服务器管理员安装。调试时可以先把SecurityConfiguration里的AutoAcceptUntrustedCertificates设为 true，确认连接成功后，再改回严格验证。

5.3 坑三：高频订阅把网卡打满——发布间隔与队列长度设错

现象：订阅 100 个监控项，服务器每 100ms 发布一次，客户端程序 CPU 没事，但交换机的端口流量暴涨，整个车间网络都卡顿。

原因：每个监控项的数据变化都会占一个通知，如果你把PublishingInterval设得过低，而底层设备又是高速变化的，服务器会在每个发布周期内把大量变化数据打包给你。这不是协议的问题，是参数没有匹配场景。

解决：增大PublishingInterval到 1000ms，同时把QueueSize从 1 提高到 10，让数据积压后只推最新值。另外，可以把不重要的点的SamplingInterval拉大，很多 OPC UA 服务器允许按监控项单独配置，利用这个能力降低整体负载。

5.4 坑四：服务器重启后客户端假死——重连不是简单包一层 try-catch

现象：PLC 断电重启后，采集程序不抛异常，也没有新数据，就像死了一样。重启程序又能恢复。

原因：OPC UA 的会话在 TCP 层断开时不会立刻通知应用层，如果你没有注册KeepAlive事件，客户端会一直以为连接还在。Session 对象的Connected属性也可能显示 true，因为它只是表示本地会话状态。

解决：必须在客户端建立一个独立的重连逻辑，检测到KeepAlive丢失后，调用session.CloseAsync()并重新走一遍Create流程。不要尝试复用旧序列号之类的技巧，OPC UA 服务端在重新启动后会清空所有旧会话状态，重新创建会话是最稳妥的做法。

5.5 坑五：DEMO 能跑，一接多个设备就崩——多会话共用一个通道的问题

现象：demo 程序只连一台 PLC 时很稳定，加入第二台设备后，程序运行几分钟就报ServiceResultException或者直接内存溢出。

原因：有些采集程序为了图省事，一个Session对象里塞了多台设备的节点，然后共用同一个订阅。当设备数量多时，订阅通知的发布频率受限于最慢的那台设备，而且一个通道里的所有订阅共享发布队列，很容易挤爆。

解决：按设备粒度拆分订阅。每台 PLC 创建独立的 Session，或者至少每个订阅只服务同一台设备的节点。如果设备数量超过 50，建议用Session池，每个 Session 上的订阅数量不超过 10 个。这样隔离故障域，一台设备协议栈出问题不影响其他设备。

6. 从 DEMO 到可交付的采集网关：最后一公里怎么补

6.1 给采集服务加一张“健康检查表”，比报业务数据更重要

很多 DEMO 止步于“数据能读到”，但产线运维要的是“当数据读不到时，我能立刻知道是设备问题还是采集服务问题”。我习惯给每个采集会话维护一张健康表，记录最后成功读值的时间、最后收到通知的时间、累计失败次数。用定时任务扫描这张表，超过 30 秒没收到任何更新，就触发报警。这个技巧救过我好几次，让你的网关看起来更专业。

6.2 用回放开源数据验证稳定性，再接入真实设备

如果你要交付给客户，建议在进厂前先做一个模拟压力测试。UA-.NETStandard 自带一个Opc.Ua.SampleServer，我一般会写一个测试脚本连上去，模拟 100 个监控项，按 100ms 间隔随机变化数值，跑 8 小时看有没有内存泄漏。测试通过后再去现场换真实 IP 和节点。接入真实设备时，第一件事不是核对数据，而是用 UA Expert 抓一遍地址空间树，确认所有要采集的变量刷新率都是“实时”，而不是“静态”。有些传感器的变量是上电时才更新一次，订阅了也不会推送，这种就要改成定时读值。

6.3 最后一点血泪教训

我最初做的第一个 OPC UA 网关就是因为忽略的 KeepAlive 导致凌晨 2 点所有数据停止更新，直到第二天早会才发现。现在我在任何新项目的第一天就先把重连逻辑写好，并刻意在网络断开的条件下验证，而不是等到现场翻车。条件允许的话，把监控项的DiscardOldest设为 true，把发布间隔从 500ms 改到 1000ms，优先保证连接稳定。希望这套思路能帮你把 DEMO 快速变成能扛 7x24 小时的采集服务，少走那些我差点半夜跑回车间处理的弯路，希望帮到你。

本文还有配套的精品资源，点击获取