2. 数据采集体系：传感器数据、日志数据、API数据

设备画像这东西，说白了就是给设备做“体检报告”。但报告准不准，全看原始数据靠不靠谱。我做了这么多年设备管理，见过太多“垃圾进、垃圾出”的案例——模型再漂亮，数据源一塌糊涂，最后全是白费功夫。

今天咱们就聊聊数据采集的三大来源：传感器、日志、API。这三条腿缺一不可，但每条腿的脾气都不一样。

2.1 传感器数据：设备的“神经末梢”

传感器是离设备最近的数据源。温度、振动、压力、电流……这些物理量直接反映设备的真实状态。我个人习惯把传感器数据分成两类：

• 高频连续信号：振动加速度、电流波形，采样率通常在1kHz以上
• 低频状态量：温度、压力、液位，几秒到几分钟采集一次就够了

这里有个坑——采样频率不是越高越好。我记得有个项目，客户要求振动传感器开到10kHz，结果一天产生2TB数据，存储成本直接爆炸。后来我们做了频谱分析，发现设备故障特征频率集中在500Hz以内，降到2kHz采样完全够用。

传感器数据采集的典型架构是这样的：

传感器 → 信号调理 → ADC转换 → 边缘计算节点 → 数据总线 → 存储层
  │            │            │            │              │
  │  滤波/放大   │   模数转换   │   特征提取    │   Kafka/   │  时序数据库
  │  隔离/保护   │   分辨率    │   降采样     │   MQTT    │  (InfluxDB等)

嗯，这里要注意一点：边缘计算节点一定要做数据质量标记。我在项目里遇到过传感器漂移，温度值从80℃慢慢飘到120℃，但设备实际温度没变。如果边缘节点能打上“传感器健康度”标签，下游建模时就能自动过滤掉这些脏数据。

2.2 日志数据：设备的“病历本”

日志数据跟传感器数据不一样。传感器告诉你“现在怎么样”，日志告诉你“刚才发生了什么”。

设备日志主要分三类：

我曾经踩过一个坑——报警日志的重复率极高。某个设备一小时内报了3000次“油温偏高”，但实际只有一次是真正的异常。如果不做去重和聚合，日志数据会把模型训练带偏。我的做法是：

1. 按时间窗口（比如5分钟）做报警合并
2. 提取报警序列模式，而不是单条报警
3. 给每条日志打上“首次/重复/恢复”标签

2.3 API数据：设备的“社交网络”

API数据是设备画像里最容易忽略的一块。设备不是孤岛，它跟MES系统、ERP系统、质量系统都有交互。这些交互数据通过API接口暴露出来，能补全设备画像的“上下文信息”。

常见的API数据源包括：

• 生产排程API：设备当前加工什么产品？批次号是多少？
• 质量检测API：该设备生产的产品合格率如何？缺陷模式是什么？
• 能耗管理API：设备的实时功率、累计用电量、能效比
• 备件库存API：该设备关联的备件库存水位、采购周期

API采集的难点在于接口协议不统一。有的用RESTful，有的用OPC UA，有的干脆是自定义TCP报文。我建议的做法是：

# 伪代码：API数据采集适配器模式
class DeviceAPICollector:
    def __init__(self, device_type):
        # 根据设备类型加载对应的适配器
        self.adapter = AdapterFactory.get(device_type)
    
    def collect(self):
        # 统一返回标准化的数据字典
        raw = self.adapter.fetch()
        return self.normalize(raw)
    
    def normalize(self, raw):
        # 字段映射、单位转换、时间戳对齐
        return {
            "timestamp": raw["time"],
            "metrics": {
                "product_id": raw.get("product_code"),
                "yield_rate": raw.get("pass_rate"),
                "energy_consumption": raw.get("power_kwh")
            }
        }

说白了，API采集的核心就是适配器模式 + 数据标准化。不管底层接口多乱，上层建模看到的都是统一格式。

2.4 三源融合：数据的时间对齐难题

传感器数据是毫秒级的，日志数据是秒级或分钟级的，API数据可能是小时级的。三个数据源的时间粒度不一样，怎么对齐？

我常用的策略是“降采样对齐 + 事件窗口”：

• 以设备画像的更新周期（比如5分钟）为基准
• 传感器数据：取5分钟内的均值、最大值、最小值、标准差
• 日志数据：统计5分钟内的报警次数、运行状态占比
• API数据：取最近一次有效值，或最近一个批次的统计量

下面这张图展示了三源数据在设备画像中的融合逻辑：

2.5 数据质量：采集体系的“生命线”

数据采集做得再好，质量不行等于零。我总结了一套数据质量五维评估法：

嗯，数据采集体系就聊到这儿。记住一句话：设备画像的质量，上限由建模算法决定，下限由数据采集决定。把采集体系打扎实了，后面的建模工作才能事半功倍。