C# OPC UA 客户端实战：.NET Core 跨平台连接、订阅与避坑指南

简介：这份资源面向工业自动化与物联网方向的 C# 开发者，提供基于 .NET Core 的 OPC UA 完整开发环境，覆盖 OPC UA 规范 1.03 版本，适合希望快速上手或验证 OPC UA 通信机制的中初级工程师。压缩包共 195 个文件，以 179 个 dll 类库为核心，辅以 4 个 exe 示例程序、4 个 config 配置文件、4 个 xml 与 4 个 ico 图标，整体约 15.06MB，结构紧凑便于直接运行调试。内容包含 SDK 核心库以及 SampleClient、BoilerClient 等客户端示例和 BoilerServer、ReferenceServer 等服务端示例，可帮助读者理解数据读写、变量订阅、方法调用及安全传输等关键环节，并借助参考服务端验证客户端行为。目前已有 557 人学习下载，适合作为学习 OPC UA 通信与搭建跨平台工业数据交换方案的实践起点。

1. 从一次产线联调说起：这份 C# OPC UA 客户端资源到底能干什么

去年冬天帮一家做注塑车间的朋友排查数据采集问题，现场三台西门子 S7-1500、一台汇川 PLC、还有一套老旧的 DCS，上位机是别人用 C# 写的，跑着跑着就断连，重启服务能撑两小时。翻代码发现用的是某个第三方 OPC DA 封装，DCOM 配置一塌糊涂，跨网段基本靠玄学。后来换成 OPC UA，问题才算压下去。这次要拆的这份资源，就是一套基于 .NET Core 的 C# OPC UA 客户端实现，覆盖 1.03 版规范，包含连接管理、会话保持、节点读写、订阅发布这几块核心能力。它解决的不是"能不能连"的问题，而是"连上之后怎么稳、怎么批量、怎么在 .NET Core 跨平台环境下跑起来"的问题。适合正在做 C# 上位机、产线数据采集、SCADA 对接的从业者，尤其是被 DCOM 和旧版 OPC DA 折磨过的人。下面按"资源是什么 → 怎么用 → 坑在哪"的顺序拆开讲。

2. 先搞清楚 OPC UA 1.03 与 .NET Core 的选型逻辑：为什么不是随便找个库

2.1 OPC UA 1.03 规范里，客户端真正要落地的四件事

很多人一提 OPC UA 就想到"比 OPC DA 高级"，但真到写代码，规范里几百页文档能看晕。落到客户端实现，核心就四块：安全通道（SecureChannel）、会话（Session）、服务调用（Service Call）、订阅（Subscription）。1.03 版和更早的 1.02 相比，在安全策略和证书处理上更明确，比如 Basic256Sha256 成为主流，匿名连接在很多服务端默认被关掉。

这份资源的价值在于，它没有停留在"能连上"的 demo 层面，而是把 SecureChannel 的重连、Session 的保活、Subscription 的断线恢复都做了处理。我见过太多项目，连接代码就一行Session.Create()，断线了直接崩，现场运维只能重启。资源里对这几个环节有封装，这是它和网上随手搜的示例代码最大的区别。

选型上，.NET Core 而不是 .NET Framework，理由很直接：跨平台。现在不少边缘网关跑 Linux，.NET Framework 绑死 Windows。用 .NET Core 写客户端，同一套代码能在 Windows 工控机和 Linux 网关上跑，部署灵活。代价是部分老旧的 OPC UA 库对 .NET Core 支持不完整，需要挑维护活跃的版本。

2.2 环境准备与依赖确认：别急着写代码

动手前先把环境理清楚。这份资源基于 .NET Core，建议用 .NET 6 或 .NET 8 的 LTS 版本，SDK 装好之后用dotnet --list-sdks确认。OPC UA 库常见做法是引用OPCFoundation.NetStandard.Opc.Ua系列包，它把核心、客户端、配置拆成几个 NuGet 包。

# 确认 SDK 版本，建议 6.0 或 8.0 LTS dotnet --list-sdks # 新建一个控制台项目做验证，避免直接塞进生产工程 dotnet new console -n OpcUaClientDemo cd OpcUaClientDemo # 添加 OPC UA 客户端核心包，版本按项目实际锁定 dotnet add package OPCFoundation.NetStandard.Opc.Ua.Client dotnet add package OPCFoundation.NetStandard.Opc.Ua.Configuration

这里几个参数要说明：Opc.Ua.Client提供Session、Subscription这些高层封装；Opc.Ua.Configuration负责应用配置和证书管理。版本不要盲目追新，OPC UA 库不同版本之间 API 有 breaking change，尤其是Session.Create的参数签名。我一般会先在 demo 项目里跑通，再往生产工程迁移。

提示：如果目标服务端是西门子、施耐德这类品牌 PLC，先确认它支持的 SecurityPolicy。很多现场默认只开 None 或 Basic256Sha256，选错策略连不上，报错还特别含糊。

2.3 连接与安全策略配置：证书这关绕不过去

OPC UA 和普通 TCP 最大的区别就是证书。客户端要生成自己的应用实例证书，服务端要信任它，反过来客户端也要信任服务端证书。这一步是新手翻车重灾区。

// 应用配置：定义应用名、应用URI、证书存储路径 var appConfig = new ApplicationConfiguration { ApplicationName = "OpcUaClientDemo", ApplicationUri = $"urn:{Utils.GetHostName()}:OpcUaClientDemo", ApplicationType = ApplicationType.Client, SecurityConfiguration = new SecurityConfiguration { // 客户端自己的证书 ApplicationCertificate = new CertificateIdentifier { StoreType = CertificateStoreType.Directory, StorePath = "pki/own", SubjectName = "CN=OpcUaClientDemo" }, // 信任列表，服务端证书要放这里 TrustedPeerCertificates = new CertificateIdentifier { StoreType = CertificateStoreType.Directory, StorePath = "pki/trusted" }, // 吊销列表，测试环境可先不配 RevocationList = new CertificateIdentifier() }, // 传输配额，批量读写时这几个值要调 TransportConfigurations = new TransportConfigurationCollection(), TransportQuotas = new TransportQuotas { OperationTimeout = 15000 }, ClientConfiguration = new ClientConfiguration { DefaultSessionTimeout = 60000 } }; await appConfig.Validate(ApplicationType.Client);

逻辑说明：ApplicationUri必须全局唯一，重复会导致服务端拒绝；StorePath指向的目录要可写，Linux 下注意权限；OperationTimeout默认值偏小，批量请求时容易超时，我一般设到 15000 毫秒以上。DefaultSessionTimeout是会话保活周期，设太短会频繁重连，太长断线感知慢，60000 毫秒是个折中。

证书生成后，第一次连接服务端大概率被拒，因为服务端还没信任客户端证书。常见做法是把pki/own/certs下的.der文件导出，导入服务端的信任列表。西门子的 OPC UA 服务器一般在 TIA Portal 或专门的配置工具里管理信任证书。

3. 会话、读写与订阅：把客户端真正跑起来的三段代码

3.1 建立 Session 与断线重连：别让一次断网毁掉整条产线

连接建立只是开始，现场网络抖动、PLC 重启、交换机抽风都是常态。Session 的保活和重连必须自己兜底。

// 创建端点描述，Url 换成实际服务端地址 var endpointDescription = CoreClientUtils.SelectEndpoint( "opc.tcp://192.168.1.10:4840", useSecurity: true); var endpointConfiguration = EndpointConfiguration.Create(appConfig); var endpoint = new ConfiguredEndpoint(null, endpointDescription, endpointConfiguration); // 创建会话，注意 sessionName 和 timeout 参数 var session = await Session.Create( appConfig, endpoint, updateBeforeConnect: false, sessionName: "ProductionLineClient", sessionTimeout: 60000, identity: new UserIdentity(new AnonymousIdentityToken())); // 断线重连：监听 KeepAlive 事件，触发时重建会话 session.KeepAlive += async (s, e) => { if (e.CurrentState == ServerState.Bad) { // 先关闭旧会话，避免句柄泄漏 await session.CloseAsync(); // 重建逻辑，实际项目里建议加退避重试 session = await Session.Create(appConfig, endpoint, false, "ProductionLineClient", 60000, new UserIdentity(new AnonymousIdentityToken())); } };

参数说明：useSecurity: true表示走加密通道，测试阶段可以先设 false 排查是不是证书问题；sessionTimeout和配置里的DefaultSessionTimeout保持一致；KeepAlive事件里判断ServerState.Bad才重连，正常心跳不要动。血泪经验是重连一定要加退避，否则服务端刚重启，客户端疯狂重连会把服务端打挂。

3.2 节点读写与批量请求：单点读是性能杀手

OPC UA 的节点用 NodeId 标识，格式类似ns=2;s=Machine1.Temperature。单点读写在数据量大时性能很差，每个请求一个往返。批量请求是必须掌握的技能。

// 构造批量读请求 var nodesToRead = new ReadValueIdCollection { new ReadValueId { NodeId = new NodeId("ns=2;s=Machine1.Temperature"), AttributeId = Attributes.Value }, new ReadValueId { NodeId = new NodeId("ns=2;s=Machine1.Pressure"), AttributeId = Attributes.Value }, new ReadValueId { NodeId = new NodeId("ns=2;s=Machine1.Speed"), AttributeId = Attributes.Value } }; session.Read(null, 0, TimestampsToReturn.Both, nodesToRead, out DataValueCollection results, out DiagnosticInfoCollection diagnostics); // 批量写 var nodesToWrite = new WriteValueCollection { new WriteValue { NodeId = new NodeId("ns=2;s=Machine1.SetPoint"), AttributeId = Attributes.Value, Value = new DataValue(new Variant(75.5)) } }; session.Write(null, nodesToWrite, out StatusCodeCollection writeResults, out DiagnosticInfoCollection writeDiagnostics);

逻辑说明：Read的第二个参数0是maxAge，0 表示强制从服务端取最新值，缓存场景可以设大；TimestampsToReturn.Both同时返回源时间戳和服务端时间戳，做数据追溯时有用。批量写要注意，部分服务端对单次请求的节点数量有限制，常见是几百个，超了会报BadTooManyOperations，需要分批。

注意：批量请求不是越多越好。节点数太多，单次响应体变大，网络抖动时整体失败率上升。我一般按 100 到 200 个节点一批，实测比较稳。

3.3 订阅与数据变化通知：产线采集的正确姿势

轮询读适合低频、少量数据。产线实时采集应该用订阅，服务端数据变化时主动推送，省带宽也省 CPU。

// 创建订阅，publishingInterval 是服务端推送周期 var subscription = new Subscription(session.DefaultSubscription) { PublishingInterval = 500, // 毫秒 KeepAliveCount = 10, // 心跳周期数 LifetimeCount = 30, // 订阅存活周期数 MaxNotificationsPerPublish = 1000, PublishingEnabled = true }; session.AddSubscription(subscription); await subscription.CreateAsync(); // 添加监控项 var monitoredItem = new MonitoredItem(subscription.DefaultItem) { StartNodeId = new NodeId("ns=2;s=Machine1.Temperature"), AttributeId = Attributes.Value, SamplingInterval = 250, // 采样周期，应小于推送周期 QueueSize = 10, // 队列深度，防丢数据 DiscardOldest = true }; monitoredItem.Notification += (item, e) => { // 数据变化回调，e.NotificationValue 里是 DataValue Console.WriteLine($"值变化: {e.NotificationValue}"); }; subscription.AddItem(monitoredItem); await subscription.ApplyChangesAsync();

参数说明：PublishingInterval是服务端推送节奏，SamplingInterval是服务端采样节奏，后者要小于等于前者，否则没意义；QueueSize决定断线期间缓存多少条，太小会丢数据，太大占内存；DiscardOldest为 true 时队列满了丢最旧的，实时性优先选 true，完整性优先选 false。这几个参数是订阅调优的核心，现场要根据数据变化频率调。

4. 避坑与排查：那些让我加班到凌晨的 OPC UA 问题

4.1 连接报 BadSecurityChecksFailed：证书信任链没配全

现象：客户端连服务端，报BadSecurityChecksFailed或BadCertificateUntrusted。原因：客户端证书没被服务端信任，或者服务端证书没被客户端信任，信任是双向的。解决：把客户端pki/own/certs下的证书导入服务端信任列表，同时把服务端证书放进客户端pki/trusted/certs。西门子 PLC 还要注意证书的 ApplicationUri 要匹配，不匹配照样拒。

4.2 订阅收不到数据：SamplingInterval 大于 PublishingInterval

现象：订阅创建成功，但回调一直不触发。原因：SamplingInterval设得比PublishingInterval大，服务端采样比推送还慢，自然没数据。解决：把SamplingInterval调到小于等于PublishingInterval，一般取一半。另外检查QueueSize是不是设成了 0，0 表示不缓存，某些服务端会直接不推。

4.3 批量读报 BadTooManyOperations：单次请求节点超限

现象：批量读几百个节点，报BadTooManyOperations。原因：服务端对单次请求的 Operation 数量有上限，不同品牌不一样，有的 500，有的 1000。解决：把节点分批，每批 100 到 200 个，循环调用。别指望一次读完，分批反而更稳。

4.4 .NET Core 下证书存储路径权限不足

现象：Linux 网关部署，启动时报证书写入失败。原因：pki目录权限不对，.NET Core 进程没写权限。解决：给运行用户赋目录写权限，或者把StorePath指到用户目录下。Windows 下一般没这问题，Linux 下是高频坑。

4.5 会话频繁掉线：KeepAlive 判断逻辑写错

现象：会话每隔几十秒断一次，日志里全是重连。原因：KeepAlive事件里没判断状态，正常心跳也触发重连。解决：只在ServerState.Bad或CommunicationError时重连，正常Good状态直接返回。另外重连要加退避，别裸奔。

5. 进阶技巧：用配置化把 OPC UA 客户端做成可复用组件

写到这儿，连接、读写、订阅、避坑都覆盖了。最后说个我踩过坑之后养成的习惯：把 OPC UA 客户端做成配置驱动，而不是硬编码。早期项目里 NodeId 全写在代码里，现场换个 PLC 型号，改代码重新编译，运维根本搞不定。

常见做法是把服务端地址、安全策略、节点清单、订阅参数抽到 JSON 配置里，程序启动时加载。节点清单用表格维护，现场工程师改配置就行，不用碰代码。

{ "endpointUrl": "opc.tcp://192.168.1.10:4840", "securityPolicy": "Basic256Sha256", "publishingInterval": 500, "samplingInterval": 250, "nodes": [ { "name": "温度", "nodeId": "ns=2;s=Machine1.Temperature", "queueSize": 10 }, { "name": "压力", "nodeId": "ns=2;s=Machine1.Pressure", "queueSize": 10 } ] }

加载配置后动态创建 MonitoredItem，节点增删只改 JSON。验证方法很简单：改配置里的节点，重启程序，看订阅回调是否按新清单触发。再进一步，可以把配置热加载做进去，改完不用重启。

从那以后我每次做 OPC UA 客户端，都强制走一遍"配置化 + 分批 + 退避重连"这三板斧，现场运维省心太多。希望帮到你。

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