跨网络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的优势不是一点半点方案配置复杂程度跨防火墙能力断线恢复能力数据实时性DCOM远程直连极高易踩坑差需开放大量动态端口差重连慢一般写OPC UA网关映射中高需逐点位映射好443可穿透中等好数据库中转写库再读库中需开发好一般差延迟高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 DADataHub对两类都支持但配置界面不一样。你自己得先确认现场用的是哪种协议免得选错连接类型。连接类型选好后填写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 隧道连不上的排查顺序我在群里见过不少人问“为什么我隧道建了半天还是红的”原因五花八门。这里给一个排查顺序按这个顺序走最快先ping对端机器IP确认基础网络通。再测试端口是否能telnet通不通则检查防火墙策略。确认两端的预共享密钥完全一致。检查目标端DataHub是否绑定了正确的监听网卡多网卡机器容易绑错。最后看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采集折磨这方案真的值得试一下。 
长河君 · 2026/10/22 14:19:01 · 阅读 1.2k 跨网络OPC数据采集最优解：DataHub Tunnellers部署与实战
跨网络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的优势不是一点半点方案配置复杂程度跨防火墙能力断线恢复能力数据实时性DCOM远程直连极高易踩坑差需开放大量动态端口差重连慢一般写OPC UA网关映射中高需逐点位映射好443可穿透中等好数据库中转写库再读库中需开发好一般差延迟高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 DADataHub对两类都支持但配置界面不一样。你自己得先确认现场用的是哪种协议免得选错连接类型。连接类型选好后填写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 隧道连不上的排查顺序我在群里见过不少人问“为什么我隧道建了半天还是红的”原因五花八门。这里给一个排查顺序按这个顺序走最快先ping对端机器IP确认基础网络通。再测试端口是否能telnet通不通则检查防火墙策略。确认两端的预共享密钥完全一致。检查目标端DataHub是否绑定了正确的监听网卡多网卡机器容易绑错。最后看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采集折磨这方案真的值得试一下。