简介这份 Kepware 使用教程聚焦 OPC DA Client 功能面向物联网开发者与工业通信集成人员讲解如何利用 Kepware 建立与各类 IoT 设备的连接并完成数据交换配置。资源共 1 个 PDF 文件约 614KB内容精炼、结构紧凑适合快速查阅。目前已有 5917 人学习下载是入门工业通信的常见参考资料。教程从新建项目Project切入逐步演示 Channel 的创建与 Optimization Method 参数选择如只写最新值优化通信、Duty Cycle 设置、Device 驱动选择与 IP 地址配置并完整覆盖 KEPServerEX 动态监测中 QC 显示的数据质量识别方法。读者可据此系统掌握 Channel、Device 的核心配置流程并借助 QC 动态监测快速定位数据异常为后续物联网应用的开发与维护打下扎实基础。1. Kepware的OPC DA Client当老服务器只会说DA而新系统只要UA谁来当那个翻译官很多人第一次看到“Kepware 的 OPC DA Client 用法”这个说法时第一反应是Kepware 不是一直当 OPC 服务器么把 PLC、仪表的几十个点采上来再把 OPC DA/UA 接口开放给 SCADA 和 MES 读。这确实是它最常见的身份但系统集成做到一定阶段你会碰上另一种需求车间里那套老系统只对外提供 OPC DA 接口而新平台只愿意消费 OPC UA或者你想把两套独立系统的数据汇总到同一份点表里再做转发。这时候 Kepware 就要反客为主作为 OPC DA Client 去连接别人的 OPC 服务器把数据读进自己的标签空间。这篇教程围绕这个身份把选型、配置、排错和验收整条链路讲完适合现场自动化工程师和系统集成项目的前期调研者。2. 先从两个角色和对象模型说起Kepware把读进来的和发出去的数据放在同一张点表里2.1 Kepware的双重身份Server面与Client面之间有同一条数据总线KepwareKEPServerEX本身是一个数据采集网关安装完成后它自动开启 OPC UA Server 接口。默认监听opc.tcp://IP:49320上层系统可以通过 UA 协议直接订阅它内部的全部标签。这个“Server 面”面向的是数据消费者比如 MES、Historian、云平台。而“Client 面”不是默认开启的它对应的是驱动列表里的 OPC 客户端类驱动。你要在 Configuration 里手动添加一个走 OPC 协议的新通道设置好对端服务器的地址然后 Kepware 就会像读 PLC 一样去读那个服务器。读进来的数据最终落在同一个标签缓存里之后上层用 UA/DA 去读这些标签也行用 MQTT、SQL 模块转发也行。这个“读进来”和“发出去”共用同一张点表的设计是 Kepware 能当协议转换网关的根本原因。理解了这一点你就不会把 OPC DA Client 想象成一个独立软件了。它只是 Kepware 众多通道驱动中的一种接入方式数据进来之后Kepware 的所有对外接口都能引用它。所以做系统汇总时不需要再单独写一份采集程序Kepware 本身就充当了那个中转站。2.2 OPC DA与OPC UA的分歧为什么老的DA客户端驱动正在被替换OPC DA 是 COM 时代的产物底层依赖 Windows 的 DCOM 做远程调用。它的优点是普及率极高大量在运行的 WinCC、Intouch 和自研系统都通过 DA 接口对外共享数据缺点是跨平台困难、远程配置受 Windows 账户体系约束、枚举服务器还要靠 OPCEnum 服务来盘点整个网络的 COM 组件。这些约束在工厂网络里表现得非常明显防火墙要放行动态 RPC 端口DCOM 权限要一项一项授权换了登录账号整个链路就断。OPC UA 则完全抛弃了 COM/DCOM改成基于 TCP 的二进制协议服务器地址用一个端点 URI 描述安全策略、用户认证都在握手阶段处理不再依赖 Windows 域权限。正因如此新版 Kepware 把客户端驱动收敛成 OPC UA Client老版本里那个直接叫“OPC DA Client”的驱动不再默认提供。这个变化带来一个现实问题如果你的对端服务器只有 DA 接口那么“Kepware 做 OPC DA Client”就必须分两条路走——要么用老版本 Kepware 的 DA Client 驱动直连要么用 UA 网关把 DA 转成 UA 后再让新版 Kepware 去连。对比维度OPC DAOPC UA传输基础COM/DCOMTCP 二进制协议跨平台能力Windows 为主跨平台服务器发现OPCEnum 扫描 COM 注册表端点 URL 直连时间戳语义客户端打包时刻服务器/源时间戳新版Kepware支持客户端驱动被替代驱动列表默认提供2.3 驱动选型决策DA直连、UA直连还是套一层网关在实际项目里我一般会按下面这张表做决策场景推荐做法关键前提对端只有 OPC DA且手头 Kepware 是老版本新建 OPC DA Client 通道直连有 DA Client 驱动授权对端只有 OPC DA手头 Kepware 是新版本加一台老 Kepware 或网关做 DA 转 UA再用 UA Client 连接多一段网络链路对端是 OPC UA 服务器直接新建 OPC UA Client 通道端点、安全策略一致即可研发验证用 OPC 模拟器做假 DA 服务器无需真实 PLC“套一层网关”听起来绕其实在工作中很常见。常见做法是一台老 Kepware 实例自己扮演 DA Client把 DA 数据读进内部标签同时它又开着 UA Server 接口对外把同一批标签发布成 UA另一台新版 Kepware 再用 UA Client 去连它。这样做还有一个好处网关那台机器可以放在隔离区减少 DCOM 暴露面。如果你手头只有新版本 Kepware请优先考虑这个链路而不是到处去翻老驱动包。3. 实操配置一条OPC DA Client链路从添加客户端通道到点表映射先说明无论新旧版本配置顺序都是“建通道 → 加设备 → 映射点表 → 验证”。真正容易出问题的是第三步很多人在这一步直接把 ItemID 写错导致整个链路看起来连通了但数据全是 Bad。3.1 老版本Kepware直连OPC DA服务器通道与设备属性打开 KEPServerEX Administration Console在左侧树的 Connectivity 上右键选择“Add Channel”。驱动列表里找到“OPC DA Client”下一步后给通道起个名字比如DA_Inbound。通道级的参数里我一般只改两个地方Communication Timeout 保持默认 30000msRetry Attempts 改成 3其余不动。通道建完右键通道添加设备弹出设备属性页。这里填的是对端 DA 服务器的核心信息属性填写内容说明Server Node对端机器名或 IP建议写 IP避免 DNS 解析干扰Server Program IDMatrikon.OPC.Simulation 等必须和对端 COM 注册的 ProgID 完全一致Server Version留空自动一般不填Update Rate1000ms客户端订阅更新周期Deadband0%全量上报后续按需调Request Timeout30000ms数据请求超时保存后设备会显示为灰色双击设备或右键“Connectivity Test”能测试与对端服务器的连接。能通过不代表点表就对这一步只验证 DCOM 通道和 ProgID 注册情况。老版本里这个驱动直接走 COM 调用所以对端机器的 OPCEnum 服务必须正常运行这在第 4 章会专门讲。3.2 新版Kepware用OPC UA Client接住DA网关配置过程新版 Kepware 的配置思路更简单。新建通道时驱动列表里选“OPC UA Client”通道名建议写成UA_Gateway_A。添加设备后主要参数只有几个属性常见值说明Endpoint URLopc.tcp://192.168.10.20:49320目标 UA 服务器端点Security PolicyNone 或 Basic256Sha256内网隔离环境用 None 稳定User Identity匿名或用户名密码以对端服务器设置为准Publishing Interval1000ms订阅发布周期Requested Session Timeout30000ms会话超时我把 Publishing Interval 默认设成 1000ms。现场经常有人为了“实时性”改成 50ms结果点表一多 CPU 立刻吃满最后还得改回来。对这个参数的取舍第 5 章会专门讲。连接测试时点设备右键的 Test ConnectionKepware 会去解析端点并完成握手。测试通过后设备图标变绿。要注意的是这节说的“接住 DA 网关”对端可以是老版本 Kepware 的 UA Server 接口也可以是第三方 DA/UA 转换网关。对端如果是老 Kepware它的 UA Server 默认端口同样也是 49320你只需要在 Endpoint URL 里填对这台机器的地址即可。3.3 点表映射ItemID、命名空间与导入Tags这一步是整个 OPC DA Client 配置里最核心的部分。老版本直连 DA 时Tag 的 Address 写的是对端的 ItemID格式像Group1.Item1或者Bucket Brigade.Int4。Matrikon 这种模拟器的 ItemID 里会带空格手工抄的时候很容易把大小写和空格弄错我习惯先把对端 ItemID 在 Quick Client 里复制出来再粘到 Kepware 的 Address 字段绝不手打。新版走 UA Client 时Tag Address 的格式变成了ns2;s通道名.设备名.标记名。这里的ns2是命名空间索引s后面跟的是字符串标识。如果对端是另一台 Kepware 的 UA Server字符串标识就是它对内发布的内部标签路径比如Channel1.Device1.Tag1。批量映射不要一个个手敲。在设备节点上右键选“Import Tags”会弹出对端服务器的浏览树。勾选你需要的 Item 集合Kepware 会自动生成对应的本地 Tag 名。映射完成后在 Quick Client 里连本地 Kepware逐个确认每个 Tag 的 Value 和 Quality。提示DA 接口没有强制类型描述Kepware 按默认类型解释时可能和你对端实际类型不一致。遇到值读不出来但 Quality 是 Good 的情况先把 Tag 数据类型改成对端实际类型比如 UInt16、Float再刷新看结果。4. DCOM、Windows账户与动态RPC端口OPC DA直连绕不开的工程三件套OPC DA 之所以让很多人头疼不是因为 Kepware 配置复杂而是因为它建立在 COM/DCOM 之上。你配好了通道和点表对端不让你连就是不让连而且日志里给的信息非常有限。这一章值得花时间读完因为它决定了你现场是 2 小时排完还是 2 天排完。4.1 DCOMCNFG里的三处授权启动、激活和访问权限一起配在 DA 服务器所在机器上运行dcomcnfg依次展开“组件服务 → 计算机 → 我的电脑 → DCOM 配置”。在列表里找到对端 OPC 服务器的 ProgID 条目比如Matrikon.OPC.Simulation。右键打开属性重点看两个选项卡安全选项卡里把“启动和激活权限”“访问权限”“配置权限”都改成自定义然后把负责连接的 Windows 账号加进去。具体加谁取决于 Kepware 服务以什么身份运行。如果 Kepware 和对端 DA 服务器在同一台机器上加本机登录用户就行如果跨机器必须加 Kepware 服务账号对应的域账号或本地账号。三个权限最好一起配只配访问权限不配启动权限客户端能枚举到服务器却无法唤起来。标识选项卡里选“交互式用户”还是“指定用户”是个关键决策。交互式用户适合两边同一台机器且桌面常驻的情况但服务器锁屏或 RDP 登出后会话可能被回收。长期稳定运行建议选“指定用户”填一个不会被随意改密码的专用服务账号。4.2 OpcEnum注册与列表空白从服务状态到注册表权限OPCEnum 是 OPC DA 体系里的“服务器枚举器”客户端连 DA 服务器之前先通过它扫描本机和网段内注册的 COM 服务器列表。Kepware 设备属性页里那个“浏览服务器”的按钮底层就是在问 OpcEnum。常见故障是装了 OPC Core Components但服务没起来或者机器上有 64 位和 32 位两套组件只注册了一半。建议在 DA 服务器上以管理员执行这几条命令把两套都注册上# 查看 OPCEnum 服务状态服务名固定为 opcenum sc query opcenum net start opcenum # 注册 64 位视角的枚举组件 cd $env:WINDIR\system32 .\opcenum.exe /regserver # 注册 32 位视角的枚举组件 cd $env:WINDIR\syswow64 .\opcenum.exe /regserver逻辑说明opcenum.exe 是 OPC 基础组件自带的注册程序/regserver参数会重建 COM 注册表项。64 位和 32 位两个路径下的版本都要注册因为 DCOM 客户端可能是 64 位进程而部分老 DA 服务器组件是 32 位两边注册表视角不一致就会导致列表空白。注册完只是第一步OPCEnum 自身的 DCOM 访问权限也常被忽略。回到 dcomcnfg找到名为“OpcEnum”的条目AppID 对应的组件名在安全选项卡里给实际运行账号至少加上“远程启动”“远程激活”“远程访问”三项权限。很多“能看到本机但看不到远程服务器”的问题都是卡在 OpcEnum 这个中转站上。4.3 防火墙与动态RPCDA链路比UA多一个端口维度OPC UA 只有一个固定端口比如 49320防火墙规则写好就完事。OPC DA 不行。DCOM 先连 TCP 135 固定端口完成协商真正的数据流走动态 RPC 端口默认范围通常是 49152 到 65535。只放行 135 端口结果是客户端可以枚举到服务器但一建会话就超时。在 DA 服务器上我一般先把动态端口范围收敛到一个可控区间再针对这个区间写防火墙规则# 放行 DCOM 固定端口 netsh advfirewall firewall add rule nameDCOM_FIX_135 dirin actionallow protocolTCP localport135 # 把动态 RPC 端口收敛到 49152-50152 netsh int ipv4 set dynamicport tcp start49152 num1000 # 放行收敛后的动态端口段 netsh advfirewall firewall add rule nameDCOM_RPC_DYN dirin actionallow protocolTCP localport49152-50152 # 查看实际端口占用情况 netstat -an | findstr 49152 49320逻辑说明netsh int ipv4 set dynamicport tcp start49152 num1000把动态端口范围限定在 1000 个端口里方便防火墙收敛。注意改完动态端口范围后最好重启系统或重启相关服务才能完全生效。客户端机器不需要改端口范围但要保证能访问服务器端的 135 和 49152-50152 段。这里多提一句Kepware 自带的 UA Server 监听 49320那个端口和 DA 链路无关。如果你看到 49320 通着就以为 DA 也能通那就会掉进“端口通但连不上”的坑里。5. OPC DA Client现场避坑从现象到根因的五条踩坑记录5.1 服务器列表里什么都看不到OpcEnum没启动还是DCOM权限卡住现象Kepware 设备属性页里点击浏览对端服务器列表一直是空的。更诡异的是本机能列出自己一加远程机器就空白。原因OpcEnum 服务没有运行或者注册表视角没对齐另一种可能是 DCOM 安全选项卡里启动/激活权限根本没给当前账号授权。还有一种隐蔽情况两边防火墙把 TCP 135 孤立地放行了动态端口段没放行枚举能过但连接建立不起来。解决先在 DA 服务器上执行sc query opcenum确认服务状态再按 4.2 的两条 regserver 命令把 64/32 位组件都注册一遍。然后检查 dcomcnfg 里 OpcEnum 和具体 OPC 服务器 ProgID 的安全权限确认 Kepware 运行账号具备远程启动和远程访问权限。最后回到 Kepware 机器上用netstat -an | findstr 135确认到对端的 135 连接能建立。5.2 连上了但Tags全是红色Bad别急着怀疑网络现象设备图标是绿色连接测试通过但点表一刷新全部红色 Bad值要么是 0 要么干脆不更新。这时候很多人开始查防火墙、查网线其实方向错了。原因ItemID 写错了。OPC DA 的 ItemID 是字符串寻址大小写、空格、路径全要严格一致。比如模拟器里真实 ID 是Bucket Brigade.Int4你写成BucketBrigade.Int4外观上几乎一样但 DA 服务器就是找不到这个 Item。另一个常见原因是数据类型不匹配Kepware 默认按 Int32 解释对端实际上是 Int16读出来结果就是坏的。解决先把对端 ItemID 从 Quick Client 里原样复制出来再粘到 Kepware 的 Tag Address 里。如果确认地址无误还报 Bad把 Tag 的数据类型改成对端实际类型再测试。这块没有捷径只能一个点一个点对着过。5.3 时间戳比现场时间晚几秒DA的时间戳本来就是客户端打包时刻现象数据值本身是对的但趋势图上时间戳和实际发生时间对不上最明显的是跳变信号晚了几秒才出现。原因OPC DA 协议里原始 DA 服务器返回的时间戳很多情况下不是设备产生时刻而是客户端订阅组打包更新时生成的时间。Kepware 作为客户端拿到这包数据后再写入内部标签整个链路多一跳延迟就叠加了。OPC UA 则不同UA 服务器会保留数据源的源时间戳。解决不要用 DA 链路上的时间戳做精确事件分析它只适合监控量趋势。如果项目需要精确时间戳把链路改成 UA 段来承载或者在对端设备侧把时间信息作为普通值传上来不要让 DA 层误导你。5.4 换服务账号后连接全断凭据跟着服务走不跟桌面走现象头一天链路还正常IT 同事把 Kepware 服务从 LocalSystem 改成域账号后重启所有 DA 客户端通道全部 Bad。GUI 里看起来登录用户没变但数据就是不通。原因DCOM 授权列表里存的是原来的账号。改成新服务账号后这个账号在对端 DA 服务器的 DCOM 安全配置里没有“远程启动”和“远程访问”权限等于带着没盖章的通行证去访问。解决把所有相关机器的 dcomcnfg 里 OPC 服务器和 OpcEnum 的安全权限全部重新编辑一次把新服务账号加进去。我一般直接用“指定用户”方案一劳永逸不用交互式用户省得 RDP 登出后整个链路跟着断。5.5 高频点表把客户端CPU跑满发布间隔调的比传感器还快现象几十个模拟量点数据频繁波动Kepware 主进程 CPU 持续 80% 以上甚至导致其他设备通道响应变慢。原因OPC UA Client 驱动的 Publishing Interval 被设成 50ms 甚至更小Kepware 为了满足这个频率每一轮都要打包分发所有订阅点。同时模拟量 Tag 没有设置死区任何微小抖动都触发更新订阅负载成倍增长。解决把 Publication Interval 调回 500ms 以上模拟量 Tag 在设备属性或 Tag 属性里设置 Deadband比如 0.5%只有数值变化超过这个百分比才对外发布。现场数据变化快的开关量用 200ms模拟量 1000ms 足够。不要追求“越快越实时”OPC 链路是订阅模型而不是硬实时采集通道。6. 验证与进阶用质量码、Quick Client和二次分发把链路验收到位链路通了不等于验收通过。我用一个质量码对比表和 Quick Client 做最终确认然后才把链路交出去。6.1 用质量码做底DA的192和UA的0不是一回事OPC 的质量码是判断链路和数据是否可信的第一道关口。DA 和 UA 的质量语义不一样很多人直接拿数字比对结果把好数据当坏数据。数值语义OPC DA QualityOPC UA StatusCodeGood1920Uncertain640x40000000Bad00x80000000在 Kepware 自带的 OPC Quick Client 里连接本地 Kepware 的服务器接口逐个读取映射进来的 Tag确认 Value、Quality、Timestamp 三个字段。Quality 是 Good 不代表时间戳可信尤其是 DA 链路这点上面已说过。Quick Client 读到 Good 之后再用你的上位机或 MES 侧客户端去读一遍两边数字一致才叫真正通。6.2 一条进阶落地链路DA数据经Kepware二次分发给上游验证完基本链路后我常用的一条进阶路径是老版本 Kepware 作为 DA Client 读第三方 DA 服务器再以 UA Server 发布新版 Kepware 用 UA Client 连老实例继续向 MES 提供 UA 接口。这样既保住了老系统又避免在上位机侧引入 COM 依赖。如果你想省掉商业网关直接用 Python 脚本验证这条 UA 链路可以用 opcua 库读 Kepware 的 UA Serverfrom opcua import Client # 连接 Kepware 的 UA Server 接口 client Client(opc.tcp://127.0.0.1:49320) client.connect() try: node client.get_node(ns2;sChannel1.Device1.Tag1) value node.get_data_value() print(数值:, value.value) print(UA状态码:, value.status_code) # 0 表示 Good finally: client.disconnect()这段脚本验证的是“Kepware 对外以 UA Server 服务其他系统”这一环。ns2;sChannel1.Device1.Tag1是 Kepware 内部标签在 UA 地址空间里的典型映射格式实际操作时替换成你点表里的真实路径。脚本能读到数值并且状态码为 0说明从 DA Client 接入到 UA Server 输出的整条链路是通的。这条链路我自己做过很多次最大的教训是开局就把“对端协议版本 防火墙放行段 服务账号 授权归属”画成一张表贴在交接文档首页。Kepware 本身只是一个加工厂数据能不能进得来、出得去决定权往往在这些 Windows 层参数上。不要等到现场连不上再从黑匣子里翻日志先把 DCOM、OpcEnum 和防火墙三件事配齐顺序一定不会错。希望帮到你。本文还有配套的精品资源点击获取