4. 数据采集与接入层：多源异构设备协议适配

这一章，我们聊聊数据怎么从设备端「爬」上云平台。

说实话，做共享储能平台，最头疼的不是算法，不是调度，而是——设备不听话。你想想看，一个储能站里，可能有几十台不同厂家的设备：PCS用Modbus，BMS用IEC104，升压站那边又跑61850。每家的数据格式、通信速率、寄存器地址都不一样。嗯，这就是典型的「多源异构」问题。

我个人习惯把这一层叫做「数据接入的巴别塔」。你得让所有设备都说同一种语言，才能往上走。

4.1 协议适配：三种主流协议的实战经验

先说说最常见的三种协议。我在项目中遇到过不少坑，一个一个来。

4.1.1 Modbus RTU/TCP

Modbus，说白了就是工业界的「普通话」。简单、稳定、老牌。但问题也出在这里——太灵活了。

我记得有一次，某厂家PCS的寄存器地址表，写的是「0x0100-0x01FF为遥测区」。结果实际读出来，第3个寄存器存的是电压，第4个存的是电流，中间跳了一个地址。为什么？因为厂家把第5个寄存器留给了「预留位」。你想想看，这种坑，文档上根本不会写。

所以我的建议是：不要完全相信协议文档。一定要做一次「全寄存器扫描」，把0x0000到0xFFFF所有能读的地址都读一遍，看看哪些地址有数据，哪些是空的。这叫「摸底测试」。

// 伪代码：Modbus全寄存器扫描示例
for (addr = 0x0000; addr <= 0xFFFF; addr++) {
    result = modbus_read_registers(ctx, addr, 1);
    if (result.success && result.value != 0xFFFF) {
        // 记录有效地址
        valid_addresses.push(addr, result.value);
    }
}

4.1.2 IEC104：电力系统的「老大哥」

IEC104，电力行业的老牌协议。它比Modbus复杂得多，但好处是标准化程度高。遥测、遥信、遥控、遥调，四种数据类型都有明确定义。

做IEC104适配时，我个人习惯先抓包看一遍。用Wireshark或者专用的IEC104分析工具，看看主站和子站之间到底在传什么。很多时候，厂家说「我们支持IEC104」，但实际上只实现了其中一部分功能——比如只支持遥测，不支持遥控。

这里有个关键点：IEC104的「公共地址」和「信息对象地址」。不同厂家的地址分配规则完全不同。有的从1开始，有的从0开始，有的中间还留空段。我建议在配置文件中做成可配置的，不要写死。

协议特性	Modbus	IEC104	IEC61850
传输层	RTU/TCP	TCP	MMS+GOOSE+SV
数据模型	寄存器/线圈	信息对象	逻辑节点+数据对象
实时性	中等	高	极高（微秒级）
配置复杂度	低	中	高

4.1.3 IEC61850：变电站的「高速公路」

61850，嗯，这个协议有点「重」。它不仅仅是通信协议，更是一套完整的数据模型。每个设备都被抽象成「逻辑节点」，比如XCBR代表断路器，MMXU代表测量单元。

我第一次接触61850时，被它的SCL配置文件搞晕了。一个变电站的SCL文件，动辄几千行XML。后来我学乖了——不要手动解析SCL，用现成的库。比如libIEC61850或者OpenIEC61850，这些库能帮你把SCL文件解析成内存中的数据结构。

但要注意：61850的GOOSE报文是组播的，不经过TCP。这意味着你的边缘网关必须支持原始套接字（raw socket）才能捕获GOOSE报文。我见过有人用普通TCP socket去收GOOSE，结果什么都收不到——因为GOOSE根本不走TCP/IP协议栈。

4.2 边缘网关数据汇聚：把「方言」翻译成「普通话」

协议适配完了，数据怎么汇聚到边缘网关？

我个人习惯把边缘网关设计成「三层架构」：

1. 采集层：负责和物理设备通信，采集原始数据
2. 转换层：把不同协议的数据统一成标准格式
3. 上传层：把标准化后的数据上传到云平台

这里有个关键设计：数据缓存。你想想看，如果网络断了，云平台收不到数据怎么办？边缘网关必须能本地缓存数据，等网络恢复后再补传。我建议至少缓存7天的数据，用SQLite或者嵌入式时序数据库。

// 边缘网关数据汇聚伪代码
class EdgeGateway {
    function collectData() {
        // 1. 从Modbus设备采集
        modbus_data = modbus_adapter.read_all();
        
        // 2. 从IEC104设备采集
        iec104_data = iec104_adapter.read_all();
        
        // 3. 从61850设备采集
        iec61850_data = iec61850_adapter.read_all();
        
        // 4. 统一格式
        unified_data = {
            "timestamp": now(),
            "device_id": device.id,
            "metrics": {
                "voltage": modbus_data.voltage,
                "current": iec104_data.current,
                "power": iec61850_data.power
            }
        };
        
        // 5. 写入本地缓存
        local_cache.write(unified_data);
        
        // 6. 尝试上传云平台
        upload_to_cloud(unified_data);
    }
}

4.3 数据质量治理：别让「脏数据」毁了你的平台

数据采集上来了，但质量怎么样？

我见过太多项目，数据采了一大堆，结果一分析全是垃圾。比如：

• 电压值突然跳变到9999V（明显是通信错误）
• 电流值连续10分钟都是同一个数（设备死机了）
• 时间戳错乱（设备时钟没同步）

所以，数据质量治理必须前置。我的做法是：在边缘网关就做第一道过滤。

4.3.1 数据清洗规则

我总结了几条常用规则：

1. 范围校验：比如电压正常范围是200V-800V，超出这个范围直接丢弃
2. 变化率校验：比如电流变化率不能超过100A/s，否则可能是毛刺
3. 重复值检测：连续N个采样点数值完全一样，判定为设备死机
4. 时间戳校验：时间戳不能比当前时间晚5分钟以上

4.3.2 数据补全策略

数据丢了怎么办？比如某个时刻电压值没采到。

我的建议是：不要用插值法补全。插值法看起来好看，但会引入虚假信息。比如你用线性插值补了一个电压值，结果这个值恰好触发了保护逻辑——那问题就大了。

更好的做法是：标记缺失。在数据中加一个「quality」字段，标记这个数据是原始值、插值、还是缺失。这样上层应用可以根据质量标签决定是否使用这个数据。

// 数据质量标记示例
{
    "timestamp": "2024-01-15T10:30:00Z",
    "device_id": "PCS-001",
    "metrics": {
        "voltage": {
            "value": 480.5,
            "unit": "V",
            "quality": "good"  // good/warning/bad/missing
        },
        "current": {
            "value": null,
            "unit": "A",
            "quality": "missing"
        }
    }
}

4.4 本章知识体系总览

说了这么多，我画了一张图，帮你把这一章的知识体系串起来。

这张图从左到右、从上到下，就是数据从设备到云平台的完整路径。每一层都有它的职责，缺一不可。

好了，这一章就到这里。数据接入层是共享储能平台的「地基」，地基不牢，上面再漂亮的算法都是空中楼阁。希望这些实战经验能帮你少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321