4. 边缘计算与IoT：边缘网关部署、协议解析（Modbus/OPC UA）、断点续传
说实话，搞风电数字化转型这几年，我踩过最大的坑就是「数据上不来」。
风机装了一堆传感器，网络一断，数据全丢。或者协议不兼容，PLC 的数据死活读不出来。嗯，今天咱们就聊聊边缘计算和 IoT 这块硬骨头。
4.1 边缘网关部署：别把鸡蛋放一个篮子里
我个人习惯，把边缘网关部署在风机塔筒底部或者机舱里。为什么？因为离数据源近，延迟低。
你想想看，如果所有数据都往云端送，网络抖动一下，整个监控系统就瘫痪了。边缘网关的作用，说白了就是「本地先处理一遍，挑重要的往上送」。
部署原则：
- 就近部署：网关离 PLC/传感器不超过 100 米，用工业以太网或 RS485 连接
- 冗余设计：关键场站配双网关，一台挂了另一台自动接管
- 环境适应：IP65 防护等级，-40℃~70℃ 宽温设计
我在项目中遇到过一件事：某风场把网关放在塔筒底部，结果夏天机舱温度 60℃，网关直接过热重启。后来换了带散热鳍片的工业网关，再没出过问题。
4.2 协议解析：Modbus 和 OPC UA 怎么选？
风电现场最常见的协议就两个：Modbus 和 OPC UA。一个老当益壮，一个后起之秀。
4.2.1 Modbus RTU/TCP
Modbus 这东西，说白了就是「问一句答一句」。你发个读寄存器指令，它返回数据。简单、稳定、占用资源少。
但有个坑：Modbus 没有时间戳。数据到了网关，你根本不知道它是 1 秒前采集的还是 10 秒前采集的。
我的做法：在网关层给每条 Modbus 数据打上本地时间戳，再上传。这样即使网络延迟，数据时序也是对的。
// Modbus 读取示例（C 语言风格）
uint16_t read_holding_register(int slave_id, int reg_addr) {
uint8_t cmd[8] = {slave_id, 0x03, (reg_addr >> 8) & 0xFF, reg_addr & 0xFF, 0x00, 0x01};
// 计算 CRC
uint16_t crc = calc_crc(cmd, 6);
cmd[6] = crc & 0xFF;
cmd[7] = (crc >> 8) & 0xFF;
// 发送并接收
send_serial(cmd, 8);
uint8_t resp[8];
recv_serial(resp, 8);
return (resp[3] << 8) | resp[4];
}4.2.2 OPC UA
OPC UA 就高级多了。它自带时间戳、数据质量、安全认证。说白了，它不光告诉你「数值是多少」，还告诉你「这个数据靠不靠谱」。
但 OPC UA 也有缺点：资源消耗大。老一点的 PLC 根本跑不动。我建议新场站用 OPC UA，老场站用 Modbus 加网关转换。
| 对比项 | Modbus | OPC UA |
|---|---|---|
| 资源占用 | 低 | 高 |
| 时间戳 | 无 | 自带 |
| 安全性 | 弱 | 强（加密+认证） |
| 适用场景 | 老设备、简单采集 | 新设备、复杂系统 |
4.3 断点续传：数据不能丢
风电场的网络，说实话，经常断。风机转着转着，4G 信号没了，或者光纤被挖断了。这时候断点续传就派上用场了。
我曾经遇到一个风场，网络每天断 3~4 次，每次 5~10 分钟。如果没有断点续传，一天要丢几千条数据。
注意：断点续传不是简单的「存下来再发」。你要考虑存储空间、数据去重、时序对齐。
4.3.1 实现思路
- 本地缓存：网关用 SQLite 或环形缓冲区存数据
- 断线检测：心跳包 3 秒没回应，判定断线
- 续传策略：先传最新数据，再补旧数据（保证实时性）
- 去重机制：每条数据带唯一 ID，云端按 ID 去重
// 断点续传伪代码
if (network_ok()) {
send_to_cloud(latest_data);
if (buffer_not_empty()) {
send_old_data_from_buffer(); // 补传历史数据
}
} else {
save_to_local_buffer(data); // 存到本地
mark_data_with_timestamp_and_id();
}4.4 知识体系总览
下面这张图，是我自己总结的边缘计算核心逻辑。你看一眼就明白了。
4.5 避坑指南
我曾经犯过的错：
- Modbus 轮询频率太高（100ms 一次），导致 PLC 负载飙升。后来改成 500ms，问题解决。
- OPC UA 安全证书没配好，网关连不上服务器。折腾了两天，才发现是证书过期了。
- 断点续传没做去重，云端数据重复了 30%。后来每条数据加 UUID，完美解决。
嗯，边缘计算这块，说白了就是「本地先扛住，云端再汇总」。你只要把协议解析和断点续传做好了，数据就不会丢，系统就稳了。