去年 2 月在甘肃一个 50MW 的地面站跑现场那天正好赶上沙尘天气。我们在中控室盯着监控屏眼睁睁看着逆变器的数据一条接一条地断开运维小哥急得满头汗。这并不是逆变器停机了而是现场的 4G 信号在极端天气下出现了严重的衰减和抖动也就是我们常说的「弱网环境」。那时候我们接了 200 多台不同品牌的 DTU有的是导轨式的有的是插卡式的。很多 EPC 工程师在选型时觉得 DTU 只是个「串口转网络」的透明搬运工只要能通就行。但等项目到了运维阶段你会发现那些没做缓存机制、心跳包设计极其敷衍的 DTU简直就是运维平台的灾难。数据断断续续、曲线全是断点、告警延迟半小时才报上来这时候再想换硬件成本可就不是几百块钱的事了。我们要解决的核心问题其实就两个第一网络断了数据能不能存下来网络通了能不能补回来第二网络没断但「假死」了系统能不能第一时间发现并重连缓存机制给数据一个「避风港」在光伏透传方案中DTU 扮演的是 Modbus RTU 到 Modbus TCP 的转换角色。一个典型的场景是逆变器每 5 分钟上报一次运行参数。如果此时网络断开没有缓存能力的 DTU 会直接丢弃这条串口报文。等网络 15 分钟后恢复你看到的历史曲线就会有一个巨大的缺口。我们对主流 DTU 的调研发现缓存的设计水平参差不齐。有的厂家宣称支持「断线续传」但你仔细拆解逻辑会发现它只给 RAM 分配了不到 100KB 的空间。这意味着如果断网超过半小时旧的数据会被新的直接覆盖。优秀的方案应该采用 Flash 存储至少能支持 1000 到 5000 条报文的循环存储。{storage_type:Flash,max_records:2000,policy:FIFO,trigger:Network_Disconnect_Event}这里有个隐蔽的坑Flash 的擦写寿命。如果 DTU 设计得不够精细频繁地在 Flash 上进行小碎片写入可能用不到一年硬件就挂了。我们通常建议在软件层做一层逻辑优先写 RAM 缓冲只有当检测到链路真正全面断开比如连续 3 次心跳失败时才将缓冲批量转存到 Flash 中。等到网络恢复PING 成功或 TCP 连接建立再按照 FIFO先入先出的原则在主业务数据上报的空隙分批次把历史数据「塞」回服务端。注意这里一定要限制补传的速率否则瞬间的高并发流量可能会直接把后端接入服务器冲垮。心跳包设计拒绝「僵尸连接」很多工程师会问TCP 本身不是有 Keep-Alive 吗为什么还要在应用层设计心跳包在复杂的电站环境下运营商的基站可能会因为长时间无流量而强行释放你的链路或者防火墙会把不活跃的连接杀掉。这时候TCP 协议栈可能还没反应过来但链路实际上已经不通了。我们称之为「僵尸连接」。我们团队常用的心跳包间隔通常设在 30 秒到 60 秒之间。心跳包不宜过大通常就是几个字节的 HEX 码比如0xFE 0x01 0x02 0xFD。心跳包的作用不仅是保活更重要的是「探测」。如果连续 3 个心跳周期没有收到服务端的 ACKDTU 必须主动断开当前的 socket 并发起重连。这里分享一个踩坑经验千万不要把心跳包和业务数据包混在一起处理。我们曾遇到过某品牌的 DTU在发送缓存数据时会停止心跳。结果服务端因为没收到心跳判定设备离线并强制关闭了连接导致缓存数据发到一半又断了。这种逻辑上的死循环如果不通过抓包分析很难发现根本原因。数据安全与干扰防护透传不代表「裸奔」DTU 实现网络数据透传安全性是很多甲方架构师最担心的。毕竟 Modbus RTU 协议本身没有任何加密机制。如果有人在公网上拦截了你的 TCP 报文电站的运行数据就全泄露了甚至对方可以伪造指令下发给逆变器进行调控。在硬件层面我们要求 DTU 必须支持硬件级别的 CRC 校验过滤掉串口侧的电磁干扰噪声。在网络传输层面虽然让低端的单片机跑 TLS 加密不太现实但至少要支持自定义的包头加扰或者简单的 XOR 异或运算。防护维度常见手段我们的建议物理干扰屏蔽双绞线 120Ω 终端电阻500 米以上长距离通信必加协议安全固定 IP 白名单 端口映射尽量使用 VPN 或专网卡数据完整性CRC16 长度校验丢弃所有字节数不匹配的畸形包接入控制设备独有的 IMEI/SN 动态鉴权禁止使用默认密码或简单 ID 登录对于一些对安全性要求极高的工商业电站我们会采用「一机一密」的方案。DTU 在出厂时烧录独有的的证书每次建立连接时进行双向握手。虽然这增加了对接的复杂度但在面对网络攻击时这层屏障是最后的底线。我们的思考与取舍做了这么多年的多品牌接入我们深深感受到DTU 选型绝对不是看谁便宜那十块二十块。一个好的 DTU 应该是「透明但有感知」的它对业务协议透明但对网络环境有敏锐的感知和自愈能力。在实际的项目交付中我们为了省去给每个不同品牌的 DTU 写一遍重传逻辑和心跳维护专门开发了一套数据接入中间件内部叫 ZenovaConnect。它把底层的这些心跳频率、缓存策略、重连机制全部抽象成了一套标准的配置。无论是华为、阳光还是古瑞瓦特的设备只要通过 DTU 接入在我们这层看过来都是统一的归一化数据流。这让我们在面对上百个站点的运维时不再需要去关心到底是哪台 DTU 抽了风因为中间件已经把这些「脏活累活」全干了。说到底光伏 IoT 的核心不在于你接了多少台设备而在于你在极端环境下能保住多少有效数据。如果你的电站也经常出现「断点曲线」不妨查查 DTU 的心跳间隔和缓存设置或许答案就在那几个字节的配置里。你们在现场遇到过最离谱的数据丢失原因是什么欢迎在评论区聊聊那些年我们一起踩过的坑。
去年 2 月在甘肃一个 50MW 的地面站跑现场那天正好赶上沙尘天气。我们在中控室盯着监控屏眼睁睁看着逆变器的数据一条接一条地断开运维小哥急得满头汗。这并不是逆变器停机了而是现场的 4G 信号在极端天气下出现了严重的衰减和抖动也就是我们常说的「弱网环境」。那时候我们接了 200 多台不同品牌的 DTU有的是导轨式的有的是插卡式的。很多 EPC 工程师在选型时觉得 DTU 只是个「串口转网络」的透明搬运工只要能通就行。但等项目到了运维阶段你会发现那些没做缓存机制、心跳包设计极其敷衍的 DTU简直就是运维平台的灾难。数据断断续续、曲线全是断点、告警延迟半小时才报上来这时候再想换硬件成本可就不是几百块钱的事了。我们要解决的核心问题其实就两个第一网络断了数据能不能存下来网络通了能不能补回来第二网络没断但「假死」了系统能不能第一时间发现并重连缓存机制给数据一个「避风港」在光伏透传方案中DTU 扮演的是 Modbus RTU 到 Modbus TCP 的转换角色。一个典型的场景是逆变器每 5 分钟上报一次运行参数。如果此时网络断开没有缓存能力的 DTU 会直接丢弃这条串口报文。等网络 15 分钟后恢复你看到的历史曲线就会有一个巨大的缺口。我们对主流 DTU 的调研发现缓存的设计水平参差不齐。有的厂家宣称支持「断线续传」但你仔细拆解逻辑会发现它只给 RAM 分配了不到 100KB 的空间。这意味着如果断网超过半小时旧的数据会被新的直接覆盖。优秀的方案应该采用 Flash 存储至少能支持 1000 到 5000 条报文的循环存储。{storage_type:Flash,max_records:2000,policy:FIFO,trigger:Network_Disconnect_Event}这里有个隐蔽的坑Flash 的擦写寿命。如果 DTU 设计得不够精细频繁地在 Flash 上进行小碎片写入可能用不到一年硬件就挂了。我们通常建议在软件层做一层逻辑优先写 RAM 缓冲只有当检测到链路真正全面断开比如连续 3 次心跳失败时才将缓冲批量转存到 Flash 中。等到网络恢复PING 成功或 TCP 连接建立再按照 FIFO先入先出的原则在主业务数据上报的空隙分批次把历史数据「塞」回服务端。注意这里一定要限制补传的速率否则瞬间的高并发流量可能会直接把后端接入服务器冲垮。心跳包设计拒绝「僵尸连接」很多工程师会问TCP 本身不是有 Keep-Alive 吗为什么还要在应用层设计心跳包在复杂的电站环境下运营商的基站可能会因为长时间无流量而强行释放你的链路或者防火墙会把不活跃的连接杀掉。这时候TCP 协议栈可能还没反应过来但链路实际上已经不通了。我们称之为「僵尸连接」。我们团队常用的心跳包间隔通常设在 30 秒到 60 秒之间。心跳包不宜过大通常就是几个字节的 HEX 码比如0xFE 0x01 0x02 0xFD。心跳包的作用不仅是保活更重要的是「探测」。如果连续 3 个心跳周期没有收到服务端的 ACKDTU 必须主动断开当前的 socket 并发起重连。这里分享一个踩坑经验千万不要把心跳包和业务数据包混在一起处理。我们曾遇到过某品牌的 DTU在发送缓存数据时会停止心跳。结果服务端因为没收到心跳判定设备离线并强制关闭了连接导致缓存数据发到一半又断了。这种逻辑上的死循环如果不通过抓包分析很难发现根本原因。数据安全与干扰防护透传不代表「裸奔」DTU 实现网络数据透传安全性是很多甲方架构师最担心的。毕竟 Modbus RTU 协议本身没有任何加密机制。如果有人在公网上拦截了你的 TCP 报文电站的运行数据就全泄露了甚至对方可以伪造指令下发给逆变器进行调控。在硬件层面我们要求 DTU 必须支持硬件级别的 CRC 校验过滤掉串口侧的电磁干扰噪声。在网络传输层面虽然让低端的单片机跑 TLS 加密不太现实但至少要支持自定义的包头加扰或者简单的 XOR 异或运算。防护维度常见手段我们的建议物理干扰屏蔽双绞线 120Ω 终端电阻500 米以上长距离通信必加协议安全固定 IP 白名单 端口映射尽量使用 VPN 或专网卡数据完整性CRC16 长度校验丢弃所有字节数不匹配的畸形包接入控制设备独有的 IMEI/SN 动态鉴权禁止使用默认密码或简单 ID 登录对于一些对安全性要求极高的工商业电站我们会采用「一机一密」的方案。DTU 在出厂时烧录独有的的证书每次建立连接时进行双向握手。虽然这增加了对接的复杂度但在面对网络攻击时这层屏障是最后的底线。我们的思考与取舍做了这么多年的多品牌接入我们深深感受到DTU 选型绝对不是看谁便宜那十块二十块。一个好的 DTU 应该是「透明但有感知」的它对业务协议透明但对网络环境有敏锐的感知和自愈能力。在实际的项目交付中我们为了省去给每个不同品牌的 DTU 写一遍重传逻辑和心跳维护专门开发了一套数据接入中间件内部叫 ZenovaConnect。它把底层的这些心跳频率、缓存策略、重连机制全部抽象成了一套标准的配置。无论是华为、阳光还是古瑞瓦特的设备只要通过 DTU 接入在我们这层看过来都是统一的归一化数据流。这让我们在面对上百个站点的运维时不再需要去关心到底是哪台 DTU 抽了风因为中间件已经把这些「脏活累活」全干了。说到底光伏 IoT 的核心不在于你接了多少台设备而在于你在极端环境下能保住多少有效数据。如果你的电站也经常出现「断点曲线」不妨查查 DTU 的心跳间隔和缓存设置或许答案就在那几个字节的配置里。你们在现场遇到过最离谱的数据丢失原因是什么欢迎在评论区聊聊那些年我们一起踩过的坑。
