OPC DA 为什么难部署
OPC DA 基于微软的 COM/DCOM 技术，进程间通信依赖 Windows 的 DCOM 配置。本机用还好，一旦跨机器访问，就要面对一连串安全和网络设置。
典型的 DCOM 坑
- 配置繁琐：要在客户端和服务器两端配组件服务、身份验证、启动/访问权限
- 工作组环境尤其麻烦：没有域，要靠匹配账号密码，稍有不一致就拒绝访问
- 防火墙端口：DCOM 动态端口，不像固定端口好放行
- 系统更新后失效：Windows 更新或安全策略变动后，原本能用的连接突然报 0x80070005（拒绝访问）
- 只能 Windows：无法跨平台，更不可能跑在 Linux 边缘网关
很多工程师在 DCOM 上耗费的时间，比写业务还多。
OPC UA 如何从根本上解决
- 跨平台：不依赖 COM/DCOM，Windows/Linux/嵌入式都行
- 单一端口：通常一个 TCP 端口（如 4840），防火墙友好
- 自带安全：证书、签名、加密、用户认证标准化 -. 模型自描述：客户端能浏览地址空间，可读性强
- 面向服务：读、写、订阅、方法调用，能力更完整
迁移建议
存量系统：
- 老 PLC/老软件只支持 DA 的，可用 OPC UA 网关/隧道（UA Wrapper）把 DA 包成 UA，逐步过渡
- 新采购设备和软件，把“是否支持 OPC UA”写进选型要求
新项目：
- 直接以 OPC UA 为标准，不再新建 DCOM 依赖
- 内网分阶段启用安全策略：先匿名跑通，再上签名加密和证书
过渡期共存策略
在 DA 与 UA 并存阶段，用一个统一采集层（如商业 OPC 服务器或开源栈）同时接 DA 和 UA，对上层只暴露统一数据模型，业务侧不感知底层差异，将来彻底去掉 DA 时应用层无感。
结论很明确：能上 UA 就别再为 DA 的 DCOM 投入新时间，把精力花在数据和业务上更值得。