跨网络OPC数据采集，这件事我做了快十年，踩过的坑比吃过的盐还多。经常有同行来问：“现场设备在车间环网，上位机在办公网，中间隔了防火墙，OPC数据怎么才能又快又稳地过来？”以前的标准答案是“调DCOM、开端口、配路由”，麻烦不说，还动不动就断。后来我把方案换成DataHub Tunnellers之后，这类需求才算是真正有了一个让我自己满意的“最优解”。

这篇文章就把我对DataHub Tunnellers的理解、实际部署步骤、以及用下来的几点坑一次性说清楚。内容适合正在做工业数据采集、SCADA系统集成或者MES对接的朋友，包括那些对OPC跨网络传输没什么经验、想少走弯路的入门者。先给结论：DataHub Tunnellers不是把OPC“转发”过去，而是把OPC数据“搬运”过来，架构不同，稳定性完全是两回事。

1. 跨网络采集的痛点与Tunnellers的破局思路

1.1 为什么OPC跨网络这么难搞

OPC协议在工业自动化里的地位不用多说，PLC、DCS、仪表基本都靠它往上送数据。但OPC Classic这套东西，底层依赖Windows的COM/DCOM，天生就是为了“同一台机器或同一个局域网内的进程通信”设计的。一旦你把一个OPC Server部署在一台机器上，想让另一网段的OPC Client去连它，DCOM的权限配置、身份验证、动态端口分配这一套组合拳下来，没点功底的人根本搞不定。

更麻烦的是，DCOM通信会动态申请TCP端口，防火墙很难预先放行。很多项目组为了省事，直接把防火墙关掉，或者干脆把服务器暴露在更大范围的网络上。安全一点的企业网络干脆不允许这种方式存在，然后工艺系统就要数据，两边一卡，项目就僵住了。

我印象特别深的一个项目，车间控制网是192.168.1.x，办公网是172.16.8.x，中间还有一台工业防火墙。研发那边的同事一开始用OPC远程直连，结果每周调度系统都要断一两次，查到最后都是DCOM的“身份验证令牌过期”在作怪。后来我们直接把方案换掉，不再走“OPC Client远程连OPC Server”这条路，问题才彻底翻篇。

1.2 DataHub Tunnellers到底是什么

DataHub是工业数据集成平台里比较特殊的一款软件，它最擅长做的事情是把不同来源的数据（OPC、数据库、Modbus等）拉进自己的内存实时库，然后再以OPC Server或者其他形式对外发布。而Tunnellers是DataHub里的一个专用通信隧道功能，核心思路一句话就能讲明白：

本地DataHub连接现场的OPC Server，把点位数据读进来后，不直接暴露OPC，而是通过一条自定义的TCP链路由另一端的DataHub来拉取或接收，两端的DataHub通过隧道同步数据，我们再从对端DataHub上以OPC Server的方式取数。

也就是说，真正跨网络的不是OPC协议本身，而是DataHub和DataHub之间的私有隧道协议。TCP链路是单向出站的，只需要防火墙放行一个端口，OPC那套DCOM动态端口、身份验证问题全部绕开了。这一下，跨网段采集的复杂度从天级降到小时级。

1.3 为什么说是“最优解”

我用过或者评估过几种常见的跨网络采集方式，DataHub Tunnellers的优势不是一点半点：

表格能看出来，Tunnellers在配置复杂度、跨防火墙能力和断线恢复三个维度上做得相当均衡。尤其是断线重连这一点，很多项目选型时不会注意，实际运行起来的差别巨大。后面我会专门讲这个部分。

2. 部署前必须想清楚的三件事

2.1 网络拓扑与点位归属规划

拿到需求后别急着装软件，第一件事是把网络拓扑画清楚。需要明确哪边是数据源端（放置OPC Server、现场PLC），哪边是数据目标端（上位机、SCADA、数据库连接端）。

我的建议是：在网络的每一侧各部署一套DataHub，数据源端的DataHub负责连接现场OPC Server，目标端的DataHub负责对接上层应用。两边DataHub之间建立隧道。如果你有多个车间、多个网段，可以考虑把数据源端的多个DataHub分别与目标端的一个DataHub建立隧道，也可以做链式串联，具体取决于点位数量和故障隔离需求。我自己偏向“一车间一源端”的办法，这样单个车间的通信出问题不会牵连其他车间。

点位规划上，一次性把几个万点全量同步过去是非常不理智的。Tunnellers支持按需订阅，建议中控室真正要显示的、储存的点位才同步，其余点位留在源端本机内。这样隧道带宽占用小，对端DataHub的内存压力也小，排查点位异常的时候，源和目的对照起来也清晰。

2.2 端口与防火墙策略设计

隧道通信的端口是可以自定义的，官方默认值我记得是某个固定端口，但我自己在生产环境里都习惯改成比较冷门的大端口号，比如39000以上。原因很简单，用默认端口的话，内网如果有安全扫描软件，容易被打到并提示风险，虽说DataHub隧道本身有加密能力，但减少暴露面总是好的。

防火墙策略只要记住一个原则：目标端DataHub所在机器需要放行该端口的入站TCP，源端DataHub所在机器只需要出站即可。如果中间还有工业防火墙做白名单，那你需要在防火墙上加一条“允许A机器到B机器，TCP端口XXXXX”的规则。这一点和OPC DCOM要放行一堆动态端口相比，清爽了不知道多少。

2.3 加密与认证早点定下来

Tunnellers隧道通信本身支持加密和认证。有人觉得内网环境不用加密，这个想法我不太同意。工业网络里存在很多不可控因素，万一有第三方设备接入，数据被嗅探就麻烦了。我建议一开始就把加密打开，两边配置同一个预共享密钥，这样隧道即使被截获，也没法直接看到点位数据。

如果项目对合规性有硬指标，除了隧道加密之外，建议对上位机的OPC连接也启用OPC UA安全策略。这一层配置工作量不大，但在安全评审的时候能省很多口舌。

3. 真实部署流程：从安装到数据跑通

3.1 软件安装与基础配置

DataHub的安装过程在Windows环境下基本是“下一步”式，唯一要注意的是安装时选择完整的服务端组件，否则后续有些隧道选项可能不会出现。完整安装后，数据源端和目标端各启动一个DataHub服务。

安装完毕先别急着配隧道，第一步是确认两台机器之间网络能通。我喜欢先做一次简单的端口连通性测试，确认从源端能TCP访问目标端的指定端口。这个测试没必要搞得多高级，用一个通用的端口测试工具就能完成。网络不通的话，后续一切配置都是白费功夫。

3.2 源端：连接现场OPC Server

在源端DataHub的管理界面中，新建一个OPC连接。这地方注意一个坑，现在很多现场OPC Server实际上是OPC UA的，而老牌设备可能还是OPC DA，DataHub对两类都支持，但配置界面不一样。你自己得先确认现场用的是哪种协议，免得选错连接类型。

连接类型选好后，填写OPC Server的ProgID或者Endpoint URL。OPC DA的话一般写“某品牌.OPC.1”这类字符串，OPC UA则要写完整的Endpoint地址。填好之后点连接，等状态变成“已连接”，然后就可以从“浏览”里面把需要的点位拖拽过来。

点位拖过来之后，建议在DataHub里把点位的名称整理一遍，不要直接用PLC原始的“DB1.DBW20”这种难以理解的名字，改成“反应釜温度A”“循环泵电流”这类业务名称。这一步看似费时间，后面做报表、查故障的时候你会感激自己。

3.3 目标端：建立隧道并接收数据

目标端DataHub新建一个“隧道”类型的连接。这里需要填源端DataHub的机器地址和之前规划好的端口，再填上双方约定的预共享密钥。提交之后，目标端会向源端发起隧道连接请求，只要两端的密钥一致、网络通畅，连接状态马上会变成正常。

此时源端DataHub会看到多了一个“隧道对端”的节点，你可以在这个节点下把刚才整理好的业务点位绑定到隧道上。绑定完成后，目标端DataHub的内存库里会自动出现对应的点位。

我在第一次做这个操作的时候还不太放心，特意在目标端建立了一个OPC Server对外服务，然后拿第三方的OPC客户端去连目标端DataHub的OPC Server读取点位。结果打开客户端，点位列表里真的出现了远端车间的数据，那一刻确实挺有成就感的。

3.4 验证数据准确性与时间戳

数据“通”了不算完，“准”才是关键。我会拿源端DataHub的点位值和目标端读取到的点位值做一次批量比对，抽十几个点，连看几次，确认值完全一致，时间戳的延迟在可接受范围内。

时间戳问题容易被忽略。跨网络采集时，如果两端机器的系统时间不同步，你会在历史库里看到数据时间忽前忽后，做数据分析的时候非常痛苦。解决方式有两个：一是把源端和目标端的Windows时间同步服务都指向同一个时间源，二是在DataHub里选择“保留源端时间戳”或者“使用接收端时间戳”策略，具体根据你的需求。我通常都用保留源端时间戳，并且把两端时间通过NTP校正到同一个基准上。

4. 高频问题排查与性能调优

4.1 隧道连不上的排查顺序

我在群里见过不少人问“为什么我隧道建了半天还是红的”，原因五花八门。这里给一个排查顺序，按这个顺序走最快：

1. 先ping对端机器IP，确认基础网络通。
2. 再测试端口是否能telnet通，不通则检查防火墙策略。
3. 确认两端的预共享密钥完全一致。
4. 检查目标端DataHub是否绑定了正确的监听网卡（多网卡机器容易绑错）。
5. 最后看DataHub日志，日志会明确提示是连接超时还是认证失败。

步骤2是最容易出问题的环节。很多企事业内部的工业防火墙会做“应用层过滤”，即使端口通了，也会因为“未识别的应用流量”直接切断。遇到这种情况，你需要和设备管理员沟通，把该端口的流量按TCP协议放行，不要做DPI。

4.2 数据不同步或延迟偏高

如果你发现目标端的数据刷新有一两秒的滞后，先别怪DataHub。Tunnellers本身是事件驱动推送，点位值一旦变化就会立即同步，正常延迟在毫秒级。滞后一般出在OPC Server的采集周期上，现场设备上报周期如果是500ms或者1000ms，那数据刷新自然也就这个频率。

另外一个隐藏问题：DataHub和上位机之间的OPC DA连接，默认可能存在某种“按需读取”机制，如果上位机没有订阅点位更新，DataHub不会主动推送。这种时候要确认上位机侧的DataHub接口配置为“订阅/主动上报”，而不是“请求/响应”。

4.3 隧道频繁断开的问题

做久了你会发现，隧道频繁断开的原因基本就两类：网络不稳定，或者两端DataHub服务的内存占满。

网络不稳定这个好理解，但常见的是“中间防火墙闲置连接超时”。很多防火墙会把一段时间不活动的TCP会话回收掉，而DataHub的隧道平时数据量不大，看起来就像“空闲”，于是被防火墙杀掉。解决方法是启用Tunnellers的心跳功能，也就是每隔一段时间发一个保活包。心跳间隔我一般设成30秒或者60秒，既能保持连接活性，也不会产生多少网络负担。

内存占满的问题则和点位缓存有关。如果断网时间较长，源端DataHub会积攒大量缓存数据等待同步，一旦网络恢复，瞬间的数据流量可能导致目标端内存暴涨。这时候在配置里要设置缓存上限，超出时间的数据可以选择丢弃或者压缩，避免两端的服务被拖垮。

4.4 点位映射错误

点位绑定到隧道的时候，不小心绑错、漏绑的情况也时有发生。我的经验是绑定完一批点位后，在源端用“点位置换”功能统一检查一遍名称是否都对应上了。DataHub里点位名称是唯一的，如果源端和目标端点位名称不一致，接收端数据会出现找不到点位的错误日志。命名规范从项目一开始就要定好，否则几百个点位改起来会改到崩溃。

5. 和几个备选方案对比后的最终建议

除DataHub之外，市面上类似的工业跨网络数据同步产品还有很多，比如各种“OPC UA网关盒子”“工业协议转换器”等。网关盒子的思路是硬件端完成OPC到OPC UA的转换，再把OPC UA传过去。这方案在“跨网闸”或者“跨安全区”场景下确实好用，因为它天然支持把OPC UA流量封装在HTTP里穿透。但局限也很明显：点位越多、需要转换的协议类型越杂，硬件的配置就越繁琐，而且扩展新点位的时候灵活性差。

DataHub Tunnellers更像是纯软件上的数据交换枢纽，点位增删改在界面里就能完成，而且它可以对接的不只是OPC，还可以接数据库、Modbus、甚至用户自定义数据源。也就是说，后期你如果要新增一套第三方系统的数据接口，不需要再动硬件，直接在现有的DataHub配置层面就能搞定。

所以我的建议很明确：

• 如果你的场景是“固定的几个点位、链路很标准、几台设备”，用硬件网关盒子完全可以。
• 如果你的场景是“点位多、会频繁调整、需要同时对接多种数据源、且后续还想往MES/ERP方向扩展”，DataHub这套方案在你手里会变得更顺手。

6. 真实项目中值得记录的几条经验

最后聊点平时文档里不会写的东西。

第一，源端DataHub机器一定要装正版的稳定运行环境，不要三天两头打补丁重启。我见过一个现场，IT部门每周末自动更新系统并重启，结果导致源端DataHub服务经常晚于目标端起来，隧道建立总是滞后。后来给这台机器单独设了“系统更新时段之外重启”的策略，问题才消失。这种IT配合的问题讲起来不是技术难点，但现场协调起来最耗时间。

第二，目标端DataHub数据库的缓存策略要提前设计。DataHub本身可以保留历史的质站点数据，方便目标端只读时从前一段开始补采。但是如果缓存时间设置得太长，数据量大了以后，DataHub的启动时间会变得很长，因为启动时要加载缓存。我建议历史缓存按业务需求设置成“只保留需要补采的时长”，比如4小时，多余的数据交给历史库去归档，不要把DataHub当成永久数据库用。

第三，一定要给隧道监控留一个“出口”。隧道状态是否在线，建议单独用一个点位映射到上位机报警画面里。这个点位由目标端DataHub编写逻辑生成，比如隧道在线时写入1，离线写入0。这样中控室的人第一时间就能看到采集链路是否健康，不用等数据断了半天才发现源头出了问题。我经历过一次，隧道半夜断开，结果系统一直显示的是缓存的老数据，早上巡检才发现问题，从那以后每个项目我都要加这个点。

做个总结的话，DataHub Tunnellers在我手里解决的最核心问题，就是不用再去和DCOM较劲，不用去求网络管理员放开一堆端口。它让“跨网络采集”从一件需要专门攻坚的活儿，变成了一件配置层面的流水线工作。如果你现在正被跨网络OPC采集折磨，这方案真的值得试一下。