# 供热数采网关总在几个月后死机一次从封闭网关换成 Linux Node-REDAI平台 的实践供热和工控项目的数据采集现场常见两种做法。一种是 DTU。很多低功耗、低成本的 DTU 不运行 Windows、Linux 这类通用操作系统程序只跑一个采集固件、循环或中断任务。它功能很窄没有桌面系统也没有一堆后台服务所以只要采集逻辑和通信链路写得稳长期运行往往比较省心。另一种是工业网关。网关通常运行 Linux能同时接 PLC、仪表、电表、串口设备和第三方系统支持 MQTT、OPC UA、S7 等多种协议还能在本地做一定处理。功能确实强但软件栈也复杂了系统、驱动、采集服务、转发服务、远程升级和配置程序任何一个环节处理不好都可能让整台设备卡死。我做过的一个供热项目就遇到过“运行几个月突然一批站点没数据重启后又好了”的问题。后来我们把原来的封闭网关换成 Linux 加 Node-RED云平台也重新写了一遍。这篇文章把当时的判断、方案和结果完整讲清楚。先说明一句这篇文章里的客户信息、站点名称和现场截图都做过脱敏。文中不公开真实客户数据。一、DTU 和网关稳定性不能只看有没有操作系统很多人会把问题简化成没有操作系统的 DTU 更稳定Linux 网关更容易死机。这话只对了一半。DTU 的优势是功能单一、外部依赖少。它通常只负责采集和上报不需要同时处理太多协议、本地存储、脚本、远程维护和第三方插件。任务越少出问题的入口通常也越少。但这不代表 DTU 永远不出故障。电源、串口、4G 模块、天线、固件和服务器连接都可能出问题。只是它的故障边界相对容易判断。工业网关的优势是功能全对比项常见 DTU工业网关系统形态固件、RTOS 或精简系统通常运行 Linux 等通用系统主要任务固定采集和上传多协议转换、缓存、本地处理和转发稳定性关键固件、电源、通信链路系统、程序、资源、日志和升级策略协议扩展通常较有限MQTT、OPC UA、S7 等协议支持更多维护方式多数以配置为主可查看日志、服务状态和运行资源适合场景点位少、逻辑固定的远程采集多设备接入、复杂协议和本地处理所以关键不是简单地说“DTU 比网关稳”或者“网关一定高级”而是先看你的现场需要什么。如果只是把几台仪表的固定点位采上来通信地址和上报规则长期不变DTU 往往更直接。如果需要同时接不同品牌 PLC、电表、串口设备需要做点位换算、断线缓存、本地报警和多种协议转发网关更合适。但你必须接受一件事网关的稳定不是买来就有的而是整套软件方案设计出来的。二、为什么很多网关会“跑几个月就死机”数据中心设备重启一下影响可能只是某个接口暂时不可用供热现场的数据网关一旦死机值班室的大屏可能整片发灰调度看不到温度、流量和报警历史曲线还会出现缺口。常见的表现很像一开始运行很稳几周或几个月后开始卡重启以后恢复过一段时间又犯单站数据偶尔异常严重时同一网关下的多个站一起掉线厂家远程查看时说“网络问题”换卡、换电源后问题仍然存在。这时候不能只凭感觉判断是硬件坏了。要至少看四类数据网关程序的内存有没有持续上涨断线时有没有正确探活和重连网络恢复后缓存数据是否一次性全量补传日志有没有把存储写满或者把真正错误淹没。这个项目原来的网关是厂家封闭方案。现场能配置点表也能看到一些状态但系统内部到底怎么管理连接、缓存和日志外部看不到。问题偶尔出现重启后现场又恢复正常排查窗口很短。我们当时有两个怀疑方向网关内部程序存在连接管理、缓存或内存问题平台接收补传数据时处理不当导致网关重试越来越频繁。在没有完整日志的情况下很难把责任准确归到单一环节。但可以确定的是这套链路对我们来说不够透明出问题以后只能依赖厂家而且修复速度不可控。三、为什么最后选择 Linux 加 Node-RED换平台不是为了追新技术而是为了解决现场长期运行和维护的问题。我们最后选择了 Linux 加 Node-RED。Node-RED 最早由 IBM 团队发起后来成为开源项目目前由 OpenJS Foundation 维护。它在工业、物联网和设备数据转发里用得比较多一个重要原因是流程可以可视化搭建MQTT、HTTP、串口和数据库等节点都有成熟方案。选择它主要有三个原因。1. 自己的长期运行经验我们在阿里云的 Ubuntu 环境里长期运行 Node-RED用于设备数据转发和接口处理几年下来没有遇到因为 Node-RED 本身导致服务整体不可用的问题。这不是说 Node-RED 永远不会出错。任何长期运行的系统都要看内存、日志、连接和存储。但至少我们熟悉它的运行方式知道出问题时该从哪里看。2. 编程和现场维护更直接原来的封闭网关出了问题只能等厂家。换成 Linux 加 Node-RED 后采集流程、协议转换、缓存和转发逻辑都在自己的掌握范围内。现场可以看服务状态、系统资源、程序日志和 MQTT 连接情况。哪个环节断开至少知道该先查什么。3. 多协议转换方便供热项目常见的数据来源包括换热站 PLC温度、压力、流量和热量表电表、水表和其他能耗设备Modbus RTU 或 Modbus TCP 设备需要 OPC UA 或 S7 接入的控制器通过 MQTT 上传的平台。Node-RED 适合把这些来源先统一成标准消息再做清洗、单位换算、缓存和转发。但这里要特别强调Node-RED 本身不是稳定的保证。把流程拖到画布上不等于现场就能长期运行。真正决定稳定性的是后面的工程细节断线探活重连退避本地缓存补传限速数据去重日志限频和切割进程监控配置备份版本固定远程升级失败后的回退方案。如果只是从“厂家黑盒”换成“自己拖一堆节点”没有补上这些能力问题只会换一种形式出现。四、Node-RED 在供热数采里做什么这次改造后的链路可以简化成现场仪表和 PLC ↓ 串口 / Modbus / S7 / OPC UA ↓ Linux Node-RED ├── 数据标准化 ├── 单位换算 ├── 本地缓存 ├── 断线重连 └── MQTT 上传 ↓ 数据平台 ├── 实时数据 ├── 报警判断 ├── 历史曲线 ├── 报表 └── 手机端和大屏Node-RED 适合做数采链路里的“现场组织者”不适合承担安全控制和高实时闭环。它不负责决定阀门怎么开、泵怎么启停也不参与安全联锁。它做的是采集、整理、缓存、转发和记录。控制逻辑仍然应该放在 PLC 或专门的控制系统里。这一点非常重要。不能因为网关能写流程就让脚本直接控制现场设备。数据采集平台和控制系统的责任必须分开。五、平台为什么也重新写了只换网关不够。原平台的很多逻辑对我们来说不透明出问题后只能从页面现象猜。比如数据到底有没有到达服务器是 MQTT 断了还是平台没有落库报警没有出来是规则没触发还是计算任务卡住历史曲线缺一段是设备没采还是查询接口有问题。这些都需要日志、状态和可控的代码结构。这次平台是用 AI 辅助重写的。AI 在这里承担了代码生成、接口整理、页面搭建和问题定位的工作但架构、数据规则、现场验收和上线测试仍然由人来负责。AI 编程的价值不是“自动生成一个平台”而是把原来写代码、改接口和查错误的周期缩短。系统必须保留自己的日志、数据模型和故障处理方式不能变成另一个看不见内部逻辑的黑盒。底层代码掌握在自己手里以后出现问题时可以沿着下面这条链查现场设备 - 网关采集日志 - MQTT 连接状态 - 平台接收记录 - 数据库落库结果 - 页面查询结果每一段都有记录问题至少能定位到区间而不是只能重启碰运气。六、一个供热项目的实际结果这是一个供热数据采集与监控项目涉及近 200 个站点、约 10 万个测点。具体站点和客户信息已脱敏。原来的情况是封闭网关运行一段时间后偶尔会出现整片站点数据掉线重启后恢复但过一段时间又可能出现。现场更换过电源和通信卡问题并没有从根本上消失。改造时主要做了几件事把现场网关换成 Linux 加 Node-RED重新整理采集、缓存、重连和 MQTT 转发流程增加进程监控和自动恢复对断网后的积压数据进行限速补传重新编写数据平台补齐接收、存储、报警、历史曲线和页面展示保留各段日志出现问题时能定位到设备、网关、通信链路或平台。上线前做过长时间连续运行和断网测试。一次模拟断网 6 小时的测试中缓存积累了约 2 万条数据恢复网络后按顺序补传核对结果没有发现缺失也没有看到重复入库。后续运行中网关和服务器没有再出现原来那种运行一段时间就整片掉线的循环。这里不能承诺“工业系统永远不会故障”电源、光纤、运营商网络和现场仪表仍然可能出问题。真正的改善是偶发断网不再需要人工重启才能恢复积压数据有秩序地补传不会瞬间压垮平台出现问题时能看到日志和链路状态我们不再完全依赖厂家解释问题大多数故障可以自己定位和处理。对供热企业来说最直接的价值不是页面做得多花哨而是数据不再频繁断档考核、上报和调度有连续的数据可用。七、什么场景适合做这样的改造如果你现在用的是 DTU而且点位不多、协议固定、现场没有本地处理需求不一定非要换网关。原来稳定运行就没必要为了“看起来先进”增加复杂度。但下面这些情况值得认真评估网关运行几个月就卡重启只能暂时恢复现场接入了多种协议厂家每次改点表都很慢断网后数据无法可靠补传平台出现数据缺口但没有完整日志厂家不给代码、不给日志也不支持二次开发现有系统无法方便地接大屏、手机端、报表和报警站点规模上来了原来的采集和平台结构开始吃力。这类项目真正需要的不只是买一台新网关而是一套包含现场采集、可靠传输、数据缓存、平台存储和可视化展示的完整方案。