简介OPC UA作为工业通信领域的新一代标准普遍应用于PLC互联、设备数据采集、工业物联网等场景。.NET工程师在接入OPC UA服务器时常会碰到连接配置、安全验证、证书处理、订阅更新等繁琐细节这套示例工程针对这些痛点完整覆盖连接、断开、读写、订阅和心跳监听五大核心流程。资源包共含2000个文件压缩后约87.75MB其中1218个XML多为UA节点描述与配置文件252个DLL配合28个NuGet包组成项目依赖与运行时10个C#源码及sln工程可直接打开阅读另有百余个文本与说明文档辅助环境配置和协议理解。已有673人学习说明该Demo对工程实操有不错的参考价值。通过PLC_TEST等演示代码读者可以清楚看到客户端实例创建、服务器URL与安全策略设置、ReadValue/WriteValue调用、订阅监视项添加以及心跳周期回调的具体写法既能快速复制到自己的项目中也能对照示例排查连接不稳定、订阅不推送等常见问题减少从零开始的摸索成本。1. 一条OPC UA链路80%的问题不在协议本身做上位机、MES数据采集或者设备对接的工程师电脑里几乎都装过UAExpert也都经历过那种“晚上十点、现场PLC就在机柜里客户端却报BadCertificateUntrusted”的瞬间。OPC UA协议本身是标准化的证书、会话、订阅都有明确的规范但真正折磨人的不是协议——第一次连不上、证书被拒、订阅没回调、程序退出了服务器还显示在线这些才是日常。这套.Net OPC UA通信Demo把客户端最常见的五个操作串成一个完整闭环连接、断开、读写、订阅、监听心跳代码量不大但把会话生命周期里容易翻车的地方都覆盖到了。适合用C#对接PLC、工业网关或OPC UA服务器的工程师也适合刚接触OPC UA、想找一份能跑通全流程参考实现的.NET开发者。下面按“先跑通、再拆参数、最后看坑”的顺序来拆。2. 环境与库选型为什么用官方库而不是自研协议栈2.1 三条技术路线各有什么代价写OPC UA客户端摆在面前的有三条路。第一条是OPC基金会官方的开源库OPCFoundation.NetStandard.Opc.Ua也就是这套Demo用的库。它跟UAExpert同源协议栈完整证书校验、会话管理、订阅发布这些复杂逻辑都已经实现好.NET和.NET Framework都能用。第二条是商业库功能更封装、支持更及时但授权费用不低而且很多场景用不到那层封装。第三条是自研协议栈只做二进制编码和TCP通道看起来能“掌控一切”但OPC UA的握手、证书校验、订阅续保这些细节足够消耗掉一个工程师几周时间还未必稳定。我一般建议直接走官方库。原因有三个一是它把UAExpert里看到的那些节点、订阅概念直接映射成C#对象学习成本低二是证书和加密手段是原生支持的不用自己拼算法三是出问题时Stack Overflow和GitHub issues上有大量同类案例排查路径成熟。这套Demo本身也是围绕官方库写的所以后面所有代码都以它为底座。2.2 环境准备四个东西备齐再动手开始之前需要准备四样东西。第一是.NET环境.NET 6或更高版本都可以如果还在用.NET Framework 4.7.2官方库也有对应的NuGet包只是API命名空间略有差异。第二是集成开发环境Visual Studio 2022或Rider都行关键是能正常还原NuGet包。第三是OPC UA调试客户端UAExpert是事实标准后面核对节点ID、看端点信息都要靠它。第四是一台能连的OPC UA服务器现场PLC不方便动的话可以先连公共演示服务器比如opcua.demo-this.com的51210端口只要能通外网就能跑通这套Demo。工程创建好后先引入NuGet包。包名如下dotnet add package OPCFoundation.NetStandard.Opc.Ua dotnet add package OPCFoundation.NetStandard.Opc.Ua.Client dotnet add package OPCFoundation.NetStandard.Opc.Ua.Configuration命令行还原后项目里会出现OPCFoundation.NetStandard.Opc.Ua这个依赖项。需要注意Opc.Ua.Client和Opc.Ua.Configuration这两个包在最新版本里可能已经合并进主包装完看一眼依赖如果版本较新只需要OPCFoundation.NetStandard.Opc.Ua一个包就够了不要重复引用导致程序集冲突。装包这一步看似简单实际上版本不匹配导致的FileLoadException我见过不止一次。2.3 最小连接骨架先别管业务让会话能建起来环境就绪后先写一个最小连接。这段代码只做一件事加载配置、选端点、创建会话。// 加载应用配置第二个参数表示不需要校验配置签名 var application new ApplicationInstance { ApplicationName OpcUaDemoClient, ApplicationType ApplicationType.Client }; var config await application.LoadApplicationConfiguration(Config.xml, false); // 从服务器地址中自动选择可用端点 var endpointDescription CoreClientUtils.SelectEndpoint( config, opc.tcp://192.168.1.100:4840, false); // 基于选中的端点创建ConfiguredEndpoint var endpointConfig EndpointConfiguration.Create(config); var endpoint new ConfiguredEndpoint(null, endpointDescription, endpointConfig); // 创建会话null表示匿名身份60000是会话超时毫秒数 var session await Session.Create( config, endpoint, false, DotNetOpcUaClientSession, 60000, null, null);这段代码关键是CoreClientUtils.SelectEndpoint。它的作用是去服务器上拉取端点列表然后按安全策略排序返回第一个可用的端点。false表示不强制要求加密但这只是为了让Demo先跑起来生产环境这里应该传true并让证书校验走正式流程。Session.Create里的60000是会话超时时间单位毫秒如果服务端超过这个时间没收到客户端的任何请求会主动回收会话这也是后面心跳监听的依据之一。到这里最小连接就通了。跑通之后要做的第一件事不是写读写而是把UAExpert连上同一个服务器对比两边看到的端点列表是否一致——不一致的原因十有八九是安全策略或证书信任问题这在下一章专门讲。3. 连接与断开证书信任、会话建立和一次干净的Dispose3.1 第一次连接就被拒证书信任链是怎么运作的OPC UA和HTTP不同它默认做双向证书校验。第一次连接时客户端会把自己的应用证书发给服务器同时拿到服务器的证书。如果服务器不信任客户端的证书或者客户端不信任服务器的证书握手就会失败错误码通常是BadCertificateUntrusted。很多第一次接触OPC UA的人卡在这里以为是服务器地址写错或端口不通。实际上端口是通的UAExpert也能连上但自己写的程序怎么都连不上。原因就是程序生成的证书是自签名的还没被加入服务器的信任列表。解决方式分两步。第一步让程序把生成的证书放到指定目录官方库默认放在%CommonApplicationData%\OPC Foundation\pki\own下面。第二步把证书添加到服务器的信任列表。以UAExpert为例在UAExpert的连接对话框里可以看到服务器证书添加信任即可。如果目标是Windows上的UA仿真服务器直接在服务器配置里导入客户端证书。还有一种省事但不推荐的办法把config里的SecurityToken校验关掉或者用false跳过端点安全策略这等于放弃了OPC UA的加密能力现场审计过不去。3.2 匿名和用户名密码两种会话建立的写法差别演示服务器通常允许匿名访问但现场PLC或者OPC UA网关几乎都要用户名密码。Session.Create里的身份参数就是干这个的。匿名的写法已经在上面看到了null就是匿名。带用户名密码的写法是在创建会话时传一个UserIdentity对象// 用户名密码身份 var userIdentity new UserIdentity(admin, password123); var session await Session.Create( config, endpoint, false, DotNetOpcUaClientSession, 60000, userIdentity, null);如果是证书身份UserIdentity还可以接受X509Certificate2。需要注意用户名密码模式下如果服务器配置为Basic256Sha256之外的安全策略密码在网络上是明文传输的所以生产环境一定要选带加密的安全策略。还有一个容易忽略的点UserIdentity在会话创建后就被快照了如果后续修改了密码必须重建会话才生效。3.3 断开与生命周期Dispose的顺序比你想的重要断开连接看起来就是一行session.Dispose()但实际工程里经常出现一种情况程序已经退出服务器管理界面里那个会话还是Active状态过几分钟才被服务端按超时回收。这就是没有正确清理会话导致的。Session对象内部不只有业务数据还有一个TCP通道和一个安全通道。直接Dispose会关闭业务会话但底层资源是否释放取决于调用顺序。我习惯用一个finally块来保证清理try { // 业务代码读写、订阅等 } finally { // 先摘订阅再断开会话最后释放TCP通道 subscription?.Delete(true); session?.Close(); session?.Dispose(); }Delete(true)里的true表示删除服务器端的订阅不只是本地取消。如果漏了这一步服务器端会残留订阅对象直到LifetimeCount过期才回收。Close是优雅断开会通知服务器主动释放会话资源Dispose是本地兜底。两个都调才能保证下一秒服务器上查不到这个会话。4. 读写与订阅把节点读写、订阅回调、心跳监听拆开看4.1 节点ID不是字符串是“命名空间标识”的组合OPC UA里的每个数据点都是一个节点节点由NodeId标识。最常见的两种写法是ns2;i1001和ns2;sTag_1。ns是命名空间索引i后面是数字IDs后面是字符串ID。同一个服务器上的不同设备或不同数据块往往有不同的命名空间。所以一个节点ID写错最常见的报错是BadNodeIdUnknown意思是服务器上根本找不到这个节点。写代码之前一定要先用UAExpert浏览一下目标服务器找到要读的节点的命名空间索引。不同PLC的OPC UA服务器命名空间索引可能完全不同西门子的S7-1500和倍福的TwinCAT就经常不一样。定位到具体节点后在UAExpert里复制它的NodeId字符串再写进代码。读写的代码本身很简洁// 读取ns2;sTag_1 是仿真服务器上的一个模拟量 var nodeId new NodeId(ns2;sTag_1); var readValue await session.ReadValueAsync(nodeId); Console.WriteLine($读取结果: {readValue.Value} (状态码: {readValue.StatusCode})); // 写入把42写进 ns2;sTag_Write var writeNodeId new NodeId(ns2;sTag_Write); var dataValue new DataValue(new Variant(42)) { StatusCode StatusCodes.Good, SourceTimestamp DateTime.UtcNow, ServerTimestamp DateTime.UtcNow }; var writeResult await session.WriteValueAsync(writeNodeId, dataValue); if (writeResult.StatusCode.Code 0) { Console.WriteLine(写入成功); }ReadValueAsync返回值里的StatusCode很关键。即使是读取成功也不能只看Value还要确认StatusCode是Good。如果服务器返回BadWaitingForInitialData这类状态码Value可能是空的或者是一个过期的缓存值。写入时同样要检查WriteValueAsync返回的状态码Code 0表示Good其他值都需要去StatusCode表里查。常见问题是写入一个只读节点会返回BadNotWritable这不是程序bug是节点权限问题。4.2 订阅把推送机制和采样间隔讲透读写的模式是“客户端主动问服务器被动答”这在高频采集时效率很低。OPC UA的订阅机制正好反过来客户端创建一个Subscription往里面添加MonitoredItem服务器按采样间隔检测这些节点的值变化一旦变化就推送给客户端。创建订阅的代码和参数如下// 1. 创建一个订阅对象 var subscription new Subscription { PublishingInterval 1000, // 发布间隔单位毫秒 KeepAliveCount 5, // 连续几个周期没数据就发KeepAlive包 LifetimeCount 1000, // 订阅在服务器上的生命期计数 PublishingEnabled true }; // 2. 把订阅挂到会话上 session.AddSubscription(subscription); // 3. 创建MonitoredItem监视 ns2;sTag_1 的值变化 var item new MonitoredItem { StartNodeId new NodeId(ns2;sTag_1), AttributeId Attributes.Value, SamplingInterval 500, // 采样间隔单位毫秒 QueueSize 10 // 本地排队大小防止服务器推送过快丢失 }; // 4. 订阅通知回调 item.Notification (monitoredItem, args) { var value args.NotificationValue; Console.WriteLine($[订阅] {monitoredItem.StartNodeId} - {value}); }; subscription.AddItem(item); // 5. 创建订阅在服务器端生效 subscription.Create();这里最难理解的是PublishingInterval和SamplingInterval的区别。SamplingInterval是服务器检查节点值有没有变化的频率比如500毫秒检查一次PublishingInterval是服务器把变化数据打包发给客户端的频率比如1000毫秒发一次。如果SamplingInterval比PublishingInterval小很多同一个值变化可能在一个发布周期内被合并成一条消息。这也是后面排查“订阅丢数据”时要考虑的第一个参数。KeepAliveCount和LifetimeCount的关系也要讲清楚。KeepAliveCount的意思是连续N个发布周期都没有数据变化服务器就发送一个KeepAlive报文告诉客户端“订阅还活着”。LifetimeCount的意思是如果连续这么多周期连KeepAlive都没发出去服务器就认为订阅死了直接回收。通常LifetimeCount要大于KeepAliveCount一般设置3到10倍的KeepAliveCount。4.3 监听心跳没有“心跳API”就用监视周期节点OPC UA协议里没有专门的心跳接口这是新人最容易到处找也没找到的东西。所谓“心跳”本质上就两种实现思路第一种是二阶会话级心跳利用Session.KeepAlive事件第二种是数据级心跳订阅一个周期性变化的节点比如服务器状态节点。完整方案是两者一起做。// 会话级心跳服务端周期性发KeepAlive重置这个事件就说明通道还活着 session.KeepAlive (s, e) { Console.WriteLine($[会话心跳] status{e.Status} lastContact{e.LastContactTime:O}); }; // 数据级心跳订阅服务器的当前时间节点这个节点每秒都在变 var heartbeatItem new MonitoredItem { StartNodeId new NodeId(Objects.Server_ServerStatus_CurrentTime), AttributeId Attributes.Value, SamplingInterval 1000, QueueSize 1 }; heartbeatItem.Notification (m, args) { var currentTime args.NotificationValue as DataValue; Console.WriteLine($[数据心跳] 服务器时间 {currentTime?.Value}); }; subscription.AddItem(heartbeatItem); subscription.Create();Objects.Server_ServerStatus_CurrentTime是官方库提供的一个内置节点代表服务器当前时间。大多数OPC UA服务器会每秒更新这个节点所以它天然就是一个心跳源。实际工程里如果服务器不允许读这个系统节点也可以退一步订阅自己要采集的那个实时值节点只要它有周期性变化就能起到心跳作用。数据级心跳比会话级心跳更敏感。TCP连接断开时会话级KeepAlive可能要等好几秒甚至几十秒才能感知而数据级心跳只要一个订阅周期就能发现“很久没收到推送了”。判断逻辑不写在回调里而是在回调里记录DateTime.Now另外用一个定时器去检查“最后一次回调时间”距今是否超过阈值超过就判定链路有问题触发重连。5. OPC UA避坑实录5个翻车现场现象、原因、解决5.1 连接与证书阶段的三个坑坑一程序能跑但连接总报BadCertificateUntrusted。现象是控制台输出Error: BadCertificateUntrustedUAExpert却连接正常。原因是程序第一次运行时会生成自签名证书服务器不认识这个证书。解决方法是把%CommonApplicationData%\OPC Foundation\pki\own目录下生成的.der证书导入服务器的信任列表测试阶段也可以在ApplicationConfiguration里把证书校验设为None但现场千万别这么干。坑二SelectEndpoint选出来的端点和UAExpert里看到的不一致。现象是程序连的是A安全策略UAExpert连的是B安全策略两边读写行为不一致。原因是SelectEndpoint默认按安全等级排序而UAExpert默认显示的是第一个端点。解决方法是打印endpointDescription.EndpointUrl和SecurityPolicyUri确认选中的是哪个端点必要时直接指定EndpointUrl而不依赖自动选择。坑三程序退出后服务器上会话还挂着。现象是服务器管理界面里能同时看到多个DotNetOpcUaClientSession。原因是finally块里只调了Dispose没有调Close或者直接Environment.Exit导致finally没执行。解决方法是严格控制退出流程先subscription.Delete(true)再session.Close()最后session.Dispose()确保每次退出都走同一个清理方法。5.2 读写与订阅阶段的坑坑四写入返回成功但服务器上的值没有变。现象是WriteValueAsync返回Good但UAExpert里这个节点还是原来的值。原因是写入时DataValue的时间戳填的是当前时间但服务器端节点的SourceTimestamp要求更早的时间或者服务器对写入值有范围限制。解决方法是先读一次这个节点看ValueRank和DataType如果值是Int16而你写的是Int32服务器虽然接收但会截断或丢弃。另外检查写入的节点是否在服务器端配置了WriteMask有些只读变量即使状态码返回Good实际写入也会被忽略。坑五订阅创建成功但回调一直不触发。现象是subscription.Create()没有报错控制台却没有任何订阅输出。原因通常是PublishingInterval或SamplingInterval设置得太快超出了服务器支持的上限或者LifetimeCount设置得比KeepAliveCount还小订阅刚建立就被服务器认为超时而回收。解决方法是先用UAExpert连同一台服务器在订阅设置面板里看服务器支持的发布间隔范围然后在代码里把PublishingInterval调整到服务器支持的范围KeepAliveCount设成3到8LifetimeCount设成KeepAliveCount的5倍以上。5.3 工程化阶段的坑坑六特别提醒在WinForm或WPF里直接操作UI线程抛异常。现象是订阅回调里写textBox.Text value程序跑几秒钟就崩报跨线程操作无效。原因是订阅回调运行在线程池线程上不是UI线程。解决方法是回调里只做数据搬运把值塞进一个线程安全的队列或ConcurrentQueueUI线程用定时器去队列里取数据更新控件最低效但能用的办法是用Control.BeginInvoke封送回调的更新部分。这一章是这套Demo里实际价值最高的部分——五个坑对应的是五个最常被搜索的问题。把它们背下来至少能省掉三个晚上的排查时间。6. 验证这套Demo是否靠谱UAExpert联动、回调日志、断链重连6.1 用UAExpert做联动验证让代码和工具互相印证代码写完第一件事不是直接对接现场PLC而是先用UAExpert连上演示服务器手动修改一个节点的值看自己程序的订阅回调会不会打印出来。具体做法是程序跑起来订阅ns2;sTag_1后打开UAExpert连同一台服务器找到这个节点右键写入一个新值然后看程序控制台是否出现对应的订阅日志。如果出现说明从“服务器推送”到“客户端回调”这条链路是通的如果没出现回到上一章的坑五去查PublishingInterval和SamplingInterval。读写的验证也用一样的方法。程序写入ns2;sTag_Write后在UAExpert里看这个节点的值有没有变化程序读取ns2;sTag_1时先在UAExpert里把这个节点的值改成已知数再看程序读出来的对不对。这种双端互验的方式能很快定位问题在客户端还是服务端是排查OPC UA问题最高效的手段。6.2 断链重连把Demo从“能跑”推到“能用”最后一个值得做的验证是断链重连。把服务器的网线拔掉或者直接把演示服务器进程停掉看程序会发生什么。会话级心跳会在几秒后发出告警但TCP连接断开后Session.KeepAlive事件不会立刻触发因为底层TCP要等超时才能感知。实际工程里我会在心跳线程里维护一个“最近一次收到数据的时间”每5秒检查一次如果超过N秒没收到任何数据和KeepAlive就主动认为链路异常进入重连流程。重连的推荐做法不是重新Create整个Session而是先尝试session.Reconnect()因为这样能保留原有的节点缓存和订阅配置。Reconnect失败再走完整的新建会话流程。从那以后我每次写OPC UA客户端都会强制走一遍这套流程先用UAExpert核对节点ID和端点安全策略再把证书导入信任列表然后按服务器支持的发布间隔设置订阅参数最后做一次拔线重连测试。这套流程帮我避开了绝大多数现场问题希望帮到你。本文还有配套的精品资源点击获取 .NET OPC UA客户端开发实战：连接、读写、订阅与避坑指南
简介OPC UA作为工业通信领域的新一代标准普遍应用于PLC互联、设备数据采集、工业物联网等场景。.NET工程师在接入OPC UA服务器时常会碰到连接配置、安全验证、证书处理、订阅更新等繁琐细节这套示例工程针对这些痛点完整覆盖连接、断开、读写、订阅和心跳监听五大核心流程。资源包共含2000个文件压缩后约87.75MB其中1218个XML多为UA节点描述与配置文件252个DLL配合28个NuGet包组成项目依赖与运行时10个C#源码及sln工程可直接打开阅读另有百余个文本与说明文档辅助环境配置和协议理解。已有673人学习说明该Demo对工程实操有不错的参考价值。通过PLC_TEST等演示代码读者可以清楚看到客户端实例创建、服务器URL与安全策略设置、ReadValue/WriteValue调用、订阅监视项添加以及心跳周期回调的具体写法既能快速复制到自己的项目中也能对照示例排查连接不稳定、订阅不推送等常见问题减少从零开始的摸索成本。1. 一条OPC UA链路80%的问题不在协议本身做上位机、MES数据采集或者设备对接的工程师电脑里几乎都装过UAExpert也都经历过那种“晚上十点、现场PLC就在机柜里客户端却报BadCertificateUntrusted”的瞬间。OPC UA协议本身是标准化的证书、会话、订阅都有明确的规范但真正折磨人的不是协议——第一次连不上、证书被拒、订阅没回调、程序退出了服务器还显示在线这些才是日常。这套.Net OPC UA通信Demo把客户端最常见的五个操作串成一个完整闭环连接、断开、读写、订阅、监听心跳代码量不大但把会话生命周期里容易翻车的地方都覆盖到了。适合用C#对接PLC、工业网关或OPC UA服务器的工程师也适合刚接触OPC UA、想找一份能跑通全流程参考实现的.NET开发者。下面按“先跑通、再拆参数、最后看坑”的顺序来拆。2. 环境与库选型为什么用官方库而不是自研协议栈2.1 三条技术路线各有什么代价写OPC UA客户端摆在面前的有三条路。第一条是OPC基金会官方的开源库OPCFoundation.NetStandard.Opc.Ua也就是这套Demo用的库。它跟UAExpert同源协议栈完整证书校验、会话管理、订阅发布这些复杂逻辑都已经实现好.NET和.NET Framework都能用。第二条是商业库功能更封装、支持更及时但授权费用不低而且很多场景用不到那层封装。第三条是自研协议栈只做二进制编码和TCP通道看起来能“掌控一切”但OPC UA的握手、证书校验、订阅续保这些细节足够消耗掉一个工程师几周时间还未必稳定。我一般建议直接走官方库。原因有三个一是它把UAExpert里看到的那些节点、订阅概念直接映射成C#对象学习成本低二是证书和加密手段是原生支持的不用自己拼算法三是出问题时Stack Overflow和GitHub issues上有大量同类案例排查路径成熟。这套Demo本身也是围绕官方库写的所以后面所有代码都以它为底座。2.2 环境准备四个东西备齐再动手开始之前需要准备四样东西。第一是.NET环境.NET 6或更高版本都可以如果还在用.NET Framework 4.7.2官方库也有对应的NuGet包只是API命名空间略有差异。第二是集成开发环境Visual Studio 2022或Rider都行关键是能正常还原NuGet包。第三是OPC UA调试客户端UAExpert是事实标准后面核对节点ID、看端点信息都要靠它。第四是一台能连的OPC UA服务器现场PLC不方便动的话可以先连公共演示服务器比如opcua.demo-this.com的51210端口只要能通外网就能跑通这套Demo。工程创建好后先引入NuGet包。包名如下dotnet add package OPCFoundation.NetStandard.Opc.Ua dotnet add package OPCFoundation.NetStandard.Opc.Ua.Client dotnet add package OPCFoundation.NetStandard.Opc.Ua.Configuration命令行还原后项目里会出现OPCFoundation.NetStandard.Opc.Ua这个依赖项。需要注意Opc.Ua.Client和Opc.Ua.Configuration这两个包在最新版本里可能已经合并进主包装完看一眼依赖如果版本较新只需要OPCFoundation.NetStandard.Opc.Ua一个包就够了不要重复引用导致程序集冲突。装包这一步看似简单实际上版本不匹配导致的FileLoadException我见过不止一次。2.3 最小连接骨架先别管业务让会话能建起来环境就绪后先写一个最小连接。这段代码只做一件事加载配置、选端点、创建会话。// 加载应用配置第二个参数表示不需要校验配置签名 var application new ApplicationInstance { ApplicationName OpcUaDemoClient, ApplicationType ApplicationType.Client }; var config await application.LoadApplicationConfiguration(Config.xml, false); // 从服务器地址中自动选择可用端点 var endpointDescription CoreClientUtils.SelectEndpoint( config, opc.tcp://192.168.1.100:4840, false); // 基于选中的端点创建ConfiguredEndpoint var endpointConfig EndpointConfiguration.Create(config); var endpoint new ConfiguredEndpoint(null, endpointDescription, endpointConfig); // 创建会话null表示匿名身份60000是会话超时毫秒数 var session await Session.Create( config, endpoint, false, DotNetOpcUaClientSession, 60000, null, null);这段代码关键是CoreClientUtils.SelectEndpoint。它的作用是去服务器上拉取端点列表然后按安全策略排序返回第一个可用的端点。false表示不强制要求加密但这只是为了让Demo先跑起来生产环境这里应该传true并让证书校验走正式流程。Session.Create里的60000是会话超时时间单位毫秒如果服务端超过这个时间没收到客户端的任何请求会主动回收会话这也是后面心跳监听的依据之一。到这里最小连接就通了。跑通之后要做的第一件事不是写读写而是把UAExpert连上同一个服务器对比两边看到的端点列表是否一致——不一致的原因十有八九是安全策略或证书信任问题这在下一章专门讲。3. 连接与断开证书信任、会话建立和一次干净的Dispose3.1 第一次连接就被拒证书信任链是怎么运作的OPC UA和HTTP不同它默认做双向证书校验。第一次连接时客户端会把自己的应用证书发给服务器同时拿到服务器的证书。如果服务器不信任客户端的证书或者客户端不信任服务器的证书握手就会失败错误码通常是BadCertificateUntrusted。很多第一次接触OPC UA的人卡在这里以为是服务器地址写错或端口不通。实际上端口是通的UAExpert也能连上但自己写的程序怎么都连不上。原因就是程序生成的证书是自签名的还没被加入服务器的信任列表。解决方式分两步。第一步让程序把生成的证书放到指定目录官方库默认放在%CommonApplicationData%\OPC Foundation\pki\own下面。第二步把证书添加到服务器的信任列表。以UAExpert为例在UAExpert的连接对话框里可以看到服务器证书添加信任即可。如果目标是Windows上的UA仿真服务器直接在服务器配置里导入客户端证书。还有一种省事但不推荐的办法把config里的SecurityToken校验关掉或者用false跳过端点安全策略这等于放弃了OPC UA的加密能力现场审计过不去。3.2 匿名和用户名密码两种会话建立的写法差别演示服务器通常允许匿名访问但现场PLC或者OPC UA网关几乎都要用户名密码。Session.Create里的身份参数就是干这个的。匿名的写法已经在上面看到了null就是匿名。带用户名密码的写法是在创建会话时传一个UserIdentity对象// 用户名密码身份 var userIdentity new UserIdentity(admin, password123); var session await Session.Create( config, endpoint, false, DotNetOpcUaClientSession, 60000, userIdentity, null);如果是证书身份UserIdentity还可以接受X509Certificate2。需要注意用户名密码模式下如果服务器配置为Basic256Sha256之外的安全策略密码在网络上是明文传输的所以生产环境一定要选带加密的安全策略。还有一个容易忽略的点UserIdentity在会话创建后就被快照了如果后续修改了密码必须重建会话才生效。3.3 断开与生命周期Dispose的顺序比你想的重要断开连接看起来就是一行session.Dispose()但实际工程里经常出现一种情况程序已经退出服务器管理界面里那个会话还是Active状态过几分钟才被服务端按超时回收。这就是没有正确清理会话导致的。Session对象内部不只有业务数据还有一个TCP通道和一个安全通道。直接Dispose会关闭业务会话但底层资源是否释放取决于调用顺序。我习惯用一个finally块来保证清理try { // 业务代码读写、订阅等 } finally { // 先摘订阅再断开会话最后释放TCP通道 subscription?.Delete(true); session?.Close(); session?.Dispose(); }Delete(true)里的true表示删除服务器端的订阅不只是本地取消。如果漏了这一步服务器端会残留订阅对象直到LifetimeCount过期才回收。Close是优雅断开会通知服务器主动释放会话资源Dispose是本地兜底。两个都调才能保证下一秒服务器上查不到这个会话。4. 读写与订阅把节点读写、订阅回调、心跳监听拆开看4.1 节点ID不是字符串是“命名空间标识”的组合OPC UA里的每个数据点都是一个节点节点由NodeId标识。最常见的两种写法是ns2;i1001和ns2;sTag_1。ns是命名空间索引i后面是数字IDs后面是字符串ID。同一个服务器上的不同设备或不同数据块往往有不同的命名空间。所以一个节点ID写错最常见的报错是BadNodeIdUnknown意思是服务器上根本找不到这个节点。写代码之前一定要先用UAExpert浏览一下目标服务器找到要读的节点的命名空间索引。不同PLC的OPC UA服务器命名空间索引可能完全不同西门子的S7-1500和倍福的TwinCAT就经常不一样。定位到具体节点后在UAExpert里复制它的NodeId字符串再写进代码。读写的代码本身很简洁// 读取ns2;sTag_1 是仿真服务器上的一个模拟量 var nodeId new NodeId(ns2;sTag_1); var readValue await session.ReadValueAsync(nodeId); Console.WriteLine($读取结果: {readValue.Value} (状态码: {readValue.StatusCode})); // 写入把42写进 ns2;sTag_Write var writeNodeId new NodeId(ns2;sTag_Write); var dataValue new DataValue(new Variant(42)) { StatusCode StatusCodes.Good, SourceTimestamp DateTime.UtcNow, ServerTimestamp DateTime.UtcNow }; var writeResult await session.WriteValueAsync(writeNodeId, dataValue); if (writeResult.StatusCode.Code 0) { Console.WriteLine(写入成功); }ReadValueAsync返回值里的StatusCode很关键。即使是读取成功也不能只看Value还要确认StatusCode是Good。如果服务器返回BadWaitingForInitialData这类状态码Value可能是空的或者是一个过期的缓存值。写入时同样要检查WriteValueAsync返回的状态码Code 0表示Good其他值都需要去StatusCode表里查。常见问题是写入一个只读节点会返回BadNotWritable这不是程序bug是节点权限问题。4.2 订阅把推送机制和采样间隔讲透读写的模式是“客户端主动问服务器被动答”这在高频采集时效率很低。OPC UA的订阅机制正好反过来客户端创建一个Subscription往里面添加MonitoredItem服务器按采样间隔检测这些节点的值变化一旦变化就推送给客户端。创建订阅的代码和参数如下// 1. 创建一个订阅对象 var subscription new Subscription { PublishingInterval 1000, // 发布间隔单位毫秒 KeepAliveCount 5, // 连续几个周期没数据就发KeepAlive包 LifetimeCount 1000, // 订阅在服务器上的生命期计数 PublishingEnabled true }; // 2. 把订阅挂到会话上 session.AddSubscription(subscription); // 3. 创建MonitoredItem监视 ns2;sTag_1 的值变化 var item new MonitoredItem { StartNodeId new NodeId(ns2;sTag_1), AttributeId Attributes.Value, SamplingInterval 500, // 采样间隔单位毫秒 QueueSize 10 // 本地排队大小防止服务器推送过快丢失 }; // 4. 订阅通知回调 item.Notification (monitoredItem, args) { var value args.NotificationValue; Console.WriteLine($[订阅] {monitoredItem.StartNodeId} - {value}); }; subscription.AddItem(item); // 5. 创建订阅在服务器端生效 subscription.Create();这里最难理解的是PublishingInterval和SamplingInterval的区别。SamplingInterval是服务器检查节点值有没有变化的频率比如500毫秒检查一次PublishingInterval是服务器把变化数据打包发给客户端的频率比如1000毫秒发一次。如果SamplingInterval比PublishingInterval小很多同一个值变化可能在一个发布周期内被合并成一条消息。这也是后面排查“订阅丢数据”时要考虑的第一个参数。KeepAliveCount和LifetimeCount的关系也要讲清楚。KeepAliveCount的意思是连续N个发布周期都没有数据变化服务器就发送一个KeepAlive报文告诉客户端“订阅还活着”。LifetimeCount的意思是如果连续这么多周期连KeepAlive都没发出去服务器就认为订阅死了直接回收。通常LifetimeCount要大于KeepAliveCount一般设置3到10倍的KeepAliveCount。4.3 监听心跳没有“心跳API”就用监视周期节点OPC UA协议里没有专门的心跳接口这是新人最容易到处找也没找到的东西。所谓“心跳”本质上就两种实现思路第一种是二阶会话级心跳利用Session.KeepAlive事件第二种是数据级心跳订阅一个周期性变化的节点比如服务器状态节点。完整方案是两者一起做。// 会话级心跳服务端周期性发KeepAlive重置这个事件就说明通道还活着 session.KeepAlive (s, e) { Console.WriteLine($[会话心跳] status{e.Status} lastContact{e.LastContactTime:O}); }; // 数据级心跳订阅服务器的当前时间节点这个节点每秒都在变 var heartbeatItem new MonitoredItem { StartNodeId new NodeId(Objects.Server_ServerStatus_CurrentTime), AttributeId Attributes.Value, SamplingInterval 1000, QueueSize 1 }; heartbeatItem.Notification (m, args) { var currentTime args.NotificationValue as DataValue; Console.WriteLine($[数据心跳] 服务器时间 {currentTime?.Value}); }; subscription.AddItem(heartbeatItem); subscription.Create();Objects.Server_ServerStatus_CurrentTime是官方库提供的一个内置节点代表服务器当前时间。大多数OPC UA服务器会每秒更新这个节点所以它天然就是一个心跳源。实际工程里如果服务器不允许读这个系统节点也可以退一步订阅自己要采集的那个实时值节点只要它有周期性变化就能起到心跳作用。数据级心跳比会话级心跳更敏感。TCP连接断开时会话级KeepAlive可能要等好几秒甚至几十秒才能感知而数据级心跳只要一个订阅周期就能发现“很久没收到推送了”。判断逻辑不写在回调里而是在回调里记录DateTime.Now另外用一个定时器去检查“最后一次回调时间”距今是否超过阈值超过就判定链路有问题触发重连。5. OPC UA避坑实录5个翻车现场现象、原因、解决5.1 连接与证书阶段的三个坑坑一程序能跑但连接总报BadCertificateUntrusted。现象是控制台输出Error: BadCertificateUntrustedUAExpert却连接正常。原因是程序第一次运行时会生成自签名证书服务器不认识这个证书。解决方法是把%CommonApplicationData%\OPC Foundation\pki\own目录下生成的.der证书导入服务器的信任列表测试阶段也可以在ApplicationConfiguration里把证书校验设为None但现场千万别这么干。坑二SelectEndpoint选出来的端点和UAExpert里看到的不一致。现象是程序连的是A安全策略UAExpert连的是B安全策略两边读写行为不一致。原因是SelectEndpoint默认按安全等级排序而UAExpert默认显示的是第一个端点。解决方法是打印endpointDescription.EndpointUrl和SecurityPolicyUri确认选中的是哪个端点必要时直接指定EndpointUrl而不依赖自动选择。坑三程序退出后服务器上会话还挂着。现象是服务器管理界面里能同时看到多个DotNetOpcUaClientSession。原因是finally块里只调了Dispose没有调Close或者直接Environment.Exit导致finally没执行。解决方法是严格控制退出流程先subscription.Delete(true)再session.Close()最后session.Dispose()确保每次退出都走同一个清理方法。5.2 读写与订阅阶段的坑坑四写入返回成功但服务器上的值没有变。现象是WriteValueAsync返回Good但UAExpert里这个节点还是原来的值。原因是写入时DataValue的时间戳填的是当前时间但服务器端节点的SourceTimestamp要求更早的时间或者服务器对写入值有范围限制。解决方法是先读一次这个节点看ValueRank和DataType如果值是Int16而你写的是Int32服务器虽然接收但会截断或丢弃。另外检查写入的节点是否在服务器端配置了WriteMask有些只读变量即使状态码返回Good实际写入也会被忽略。坑五订阅创建成功但回调一直不触发。现象是subscription.Create()没有报错控制台却没有任何订阅输出。原因通常是PublishingInterval或SamplingInterval设置得太快超出了服务器支持的上限或者LifetimeCount设置得比KeepAliveCount还小订阅刚建立就被服务器认为超时而回收。解决方法是先用UAExpert连同一台服务器在订阅设置面板里看服务器支持的发布间隔范围然后在代码里把PublishingInterval调整到服务器支持的范围KeepAliveCount设成3到8LifetimeCount设成KeepAliveCount的5倍以上。5.3 工程化阶段的坑坑六特别提醒在WinForm或WPF里直接操作UI线程抛异常。现象是订阅回调里写textBox.Text value程序跑几秒钟就崩报跨线程操作无效。原因是订阅回调运行在线程池线程上不是UI线程。解决方法是回调里只做数据搬运把值塞进一个线程安全的队列或ConcurrentQueueUI线程用定时器去队列里取数据更新控件最低效但能用的办法是用Control.BeginInvoke封送回调的更新部分。这一章是这套Demo里实际价值最高的部分——五个坑对应的是五个最常被搜索的问题。把它们背下来至少能省掉三个晚上的排查时间。6. 验证这套Demo是否靠谱UAExpert联动、回调日志、断链重连6.1 用UAExpert做联动验证让代码和工具互相印证代码写完第一件事不是直接对接现场PLC而是先用UAExpert连上演示服务器手动修改一个节点的值看自己程序的订阅回调会不会打印出来。具体做法是程序跑起来订阅ns2;sTag_1后打开UAExpert连同一台服务器找到这个节点右键写入一个新值然后看程序控制台是否出现对应的订阅日志。如果出现说明从“服务器推送”到“客户端回调”这条链路是通的如果没出现回到上一章的坑五去查PublishingInterval和SamplingInterval。读写的验证也用一样的方法。程序写入ns2;sTag_Write后在UAExpert里看这个节点的值有没有变化程序读取ns2;sTag_1时先在UAExpert里把这个节点的值改成已知数再看程序读出来的对不对。这种双端互验的方式能很快定位问题在客户端还是服务端是排查OPC UA问题最高效的手段。6.2 断链重连把Demo从“能跑”推到“能用”最后一个值得做的验证是断链重连。把服务器的网线拔掉或者直接把演示服务器进程停掉看程序会发生什么。会话级心跳会在几秒后发出告警但TCP连接断开后Session.KeepAlive事件不会立刻触发因为底层TCP要等超时才能感知。实际工程里我会在心跳线程里维护一个“最近一次收到数据的时间”每5秒检查一次如果超过N秒没收到任何数据和KeepAlive就主动认为链路异常进入重连流程。重连的推荐做法不是重新Create整个Session而是先尝试session.Reconnect()因为这样能保留原有的节点缓存和订阅配置。Reconnect失败再走完整的新建会话流程。从那以后我每次写OPC UA客户端都会强制走一遍这套流程先用UAExpert核对节点ID和端点安全策略再把证书导入信任列表然后按服务器支持的发布间隔设置订阅参数最后做一次拔线重连测试。这套流程帮我避开了绝大多数现场问题希望帮到你。本文还有配套的精品资源点击获取