端侧数据校验机制：以太网温湿度变送器 CRC 校验与异常值过滤逻辑分析

端侧数据校验机制：以太网温湿度变送器 CRC 校验与异常值过滤逻辑分析

在前几篇中，我们讨论了传输协议、边缘联动和时序存储。但有一个底层问题始终贯穿其中：传感器节点如何确信自己“采到的是对的”、“发出去的是真的”？

在智慧档案馆、医药冷库等合规场景，一个错误的温湿度值（如传感器受潮导致湿度飙升至 99% RH）可能引发误告警、误联动，甚至导致合规审计失败。因此，端侧（Edge/Device Side）数据校验是第一道质量防线。

本文聚焦以太网温湿度变送器的CRC 校验与异常值过滤逻辑，解析数据在离开 MCU 之前，如何被“清洗”和“自证清白”。

一、为什么端侧校验不可替代？

有人会问：TCP/IP 本身有校验和（Checksum），平台侧也可以做阈值判断，为什么还要在端侧做？

原因有三：

1. 链路层校验不保应用层正确：TCP 校验和只能保证数据在传输过程中比特未翻转，但无法检测传感器老化、ADC 漂移或内存位翻转（Bit Flip）导致的逻辑错误。
2. 平台侧无法区分“坏数据”与“真超限”：如果平台收到 99% RH，它无法判断是库房真的进水了，还是传感器坏了。端侧通过自诊断可以给出“数据质量戳”。
3. 合规要求源头可信：GSP、档案馆十防要求数据具有“可追溯性”和“防篡改性”。端侧校验是数据可信链的起点。

二、第一道防线：CRC 校验 —— 确保“数据没坏”

CRC（Cyclic Redundancy Check，循环冗余校验）是嵌入式领域最常用的错误检测码。它用于检测数据在内存拷贝、总线传输、网络发送过程中是否发生意外改变。

1. 校验对象：什么需要 CRC？

在以太网温湿度变送器中，CRC 通常应用于两个层面：

A. 应用层数据帧 CRC（防网络传输错误）

当节点通过 UDP 或私有 TCP 协议发送数据时，报文结构通常如下：

[帧头][长度][设备ID][时间戳][温度][湿度][CRC16][帧尾]

• CRC 作用域：覆盖从“长度”到“湿度”的所有字节。
• 目的：防止网线干扰、交换机错包导致的数据错误。
• 算法：CRC-16-MODBUS 或 CRC-CCITT (0x1021) 最为常见。

B. 配置参数 CRC（防 Flash 读写错误）

节点内部 Flash 中存储着校准参数、阈值配置、设备 ID 等。

• CRC 作用域：配置结构体。
• 目的：防止 Flash 位翻转导致配置“变异”（如报警阈值从 60% 变为 160%）。
• 做法：存储配置时，计算 CRC 并一同存入；上电加载时，重新计算 CRC 并与存储值比对，不一致则恢复出厂设置或使用默认值。

2. 代码实现：硬件加速与查表法

在资源受限的 MCU 中，CRC 计算需兼顾速度与性能。

示例：CRC-16-MODBUS 查表法（高效）

// CRC16 查找表（部分）
static const uint16_t crc16_table[256] = {...};

uint16_t calc_crc16(const uint8_t *data, uint16_t length) {
    uint16_t crc = 0xFFFF; // MODBUS CRC 初始值
    while (length--) {
        crc = (crc >> 8) ^ crc16_table[(crc ^ *data++) & 0xFF];
    }
    return crc;
}

// 发送前打包
void build_packet(env_data_t *data, uint8_t *buf) {
    // ... 填充数据 ...
    uint16_t crc = calc_crc16(buf + 1, data_len); // 假设帧头不算CRC
    buf[total_len - 3] = crc & 0xFF; // 低字节在前
    buf[total_len - 2] = (crc >> 8) & 0xFF; // 高字节在后
}

平台侧校验：

平台收到报文后，对相同字段计算 CRC，与报文尾部的 CRC 字段比对。若不一致，直接丢弃该包并记录“CRC Error”计数，不向上层业务传递。

三、第二道防线：异常值过滤 —— 确保“数据不傻”

即使 CRC 校验通过，数据在物理层面是正确的（0/1 没变），但在逻辑层面可能是荒谬的（如温度 -100℃）。异常值过滤旨在剔除物理上正确但逻辑上荒谬的数据。

1. 物理极限过滤（Hard Limit）

这是最基础的过滤，基于传感器的物理特性。

• 温度：-40℃ ~ +85℃（工业级传感器典型范围）。
• 湿度：0% ~ 100% RH（电容式湿度传感器物理极限）。
• 露点：不可能高于当前温度。

逻辑：

if (temp < -40.0 || temp > 85.0) {
    data_quality = QUALITY_OUT_OF_RANGE;
    discard_data();
}
if (humi < 0.0 || humi > 100.0) {
    data_quality = QUALITY_OUT_OF_RANGE;
    discard_data();
}

2. 变化率过滤（Rate-of-Change Filter）

温湿度是慢变信号。如果 1 秒内温度变化 5℃，极大概率是噪声或传感器故障，而非真实环境变化。

逻辑：

float temp_change = fabs(current_temp - last_valid_temp);
float max_change_per_sec = 2.0; // 假设最大变化率 2℃/s

if (temp_change > max_change_per_sec * sample_interval_sec) {
    // 变化过快，标记为可疑，但不一定丢弃，可能触发内部自检
    data_quality = QUALITY_SUSPICIOUS;
    // 可选：保留旧值，或触发传感器重新校准流程
} else {
    last_valid_temp = current_temp;
}

3. 静默区间过滤（Deadband Filter）

对于极其稳定的环境（如档案馆恒温恒湿），连续读取到完全相同的值（如连续 100 次都是 25.60℃），可能意味着 ADC 卡死或数据通路故障（尽管 CRC 可能通过）。

逻辑：

if (current_temp == last_temp) {
    identical_count++;
    if (identical_count > 100) { // 阈值可配置
        data_quality = QUALITY_STUCK;
        trigger_self_test(); // 触发自检
    }
} else {
    identical_count = 0;
}

4. 统计滤波（Statistical Filtering）

在 ADC 采样后、数据输出前，进行软件滤波，去除随机噪声。

• 中值滤波（Median Filter）：连续采样 N 次（如 5 次），取中间值。对脉冲干扰抑制效果好。
• 滑动平均滤波（Moving Average）：new_val = 0.7 * old_val + 0.3 * current_val。平滑曲线，但会引入滞后。
• 卡尔曼滤波（Kalman Filter）：高级算法，能根据系统噪声和测量噪声动态调整权重，适合对精度要求极高的场景，但计算量大。

推荐：工业传感器常用 中值+滑动平均组合，兼顾实时性与稳定性。

四、数据质量戳（Quality Stamp）：给数据贴上“标签”

经过上述校验与过滤后，节点应输出带有数据质量戳的数据，而不仅仅是数值。

定义质量枚举：

typedef enum {
    QUALITY_GOOD = 0,          // 数据有效
    QUALITY_CRC_ERROR,         // CRC 校验失败
    QUALITY_OUT_OF_RANGE,      // 超出物理极限
    QUALITY_RATE_LIMIT,        // 变化率超限
    QUALITY_STUCK,             // 数值卡死
    QUALITY_SENSOR_FAULT,      // 传感器自检失败
    QUALITY_UNCERTAIN          // 不确定（如边缘值）
} data_quality_t;

报文携带质量戳：

{
  "device_id": "TH-20-031",
  "temp": 25.6,
  "humi": 53.2,
  "quality": 0, // QUALITY_GOOD
  "timestamp": 1700000000
}

平台侧处理：

• GOOD：入库，参与告警判断。
• UNCERTAIN：入库，但不触发告警，平台界面特殊标记（如黄色感叹号）。
• BAD（CRC/Out_of_Range/Stuck）：直接丢弃，不入库，但记录日志，并触发“传感器故障”告警。

💡 关键原则：坏数据不入历史库，但坏数据要入告警库。​ 即数据本身不能用于趋势分析，但数据缺失或异常事件必须被记录，用于运维审计。

五、传感器自检（Built-in Self-Test, BIST）

除了对采集的数据进行校验，变送器还应具备自检能力，定期或在异常时验证自身健康状态。

1. 上电自检

• RAM 测试：写入并回读特定模式（如 0x55、0xAA），检测内存位翻转。
• Flash 测试：读取配置区 CRC，验证存储完整性。
• ADC 测试：断开传感器，接入内部基准电压（如 1.2V），检查 ADC 转换是否准确。

2. 周期性自检

• 传感器 ID 读取：尝试读取温湿度芯片的电子 ID，失败则判定传感器脱落。
• 加热测试（部分高端传感器）：短暂加热湿度传感器，观察读数变化，判断湿度探头是否失效（如受潮后无响应）。

3. 通信自检

• PHY 环路测试：检查以太网 PHY 是否正常。
• Ping 网关：定期 Ping 默认网关，检测网络连通性。

自检结果通过 SNMP Trap​ 或 MQTT​ 主动上报，或通过特定寄存器（如 Modbus 40003）供平台轮询。

六、工程落地中的“坑”与对策

坑 1：CRC 算法不一致

• 现象：平台侧 CRC 校验永远失败。
• 原因：多项式、初始值、输入输出反转（RefIn/RefOut）定义不一致。
• 对策：双方使用标准算法（如 CRC-16-MODBUS），并交换测试向量（如字符串 "123456789" 的 CRC 应为 0x4B37）。

坑 2：误把“异常值”当“真超限”

• 现象：库房并未进水，但系统频繁触发“湿度过高”告警。
• 原因：未启用变化率过滤，传感器受潮漂移导致读数缓慢爬升。
• 对策：启用变化率过滤，并结合历史趋势判断（如过去 1 小时均值是否异常）。

坑 3：质量戳丢失

• 现象：平台收到数据，但不知道质量好坏。
• 原因：私有协议未定义质量字段，或 Modbus 寄存器未预留状态字。
• 对策：协议设计初期预留 1～2 个寄存器或 JSON 字段专门用于数据质量。

七、小结

端侧数据校验机制是以太网温湿度变送器的“免疫系统”。它通过 CRC 校验​ 确保数据在传输链路上“没坏”，通过 异常值过滤​ 确保数据在逻辑上“不傻”，通过 数据质量戳​ 为平台提供决策依据，通过 自检机制​ 确保自身“健康”。

设计 Checklist：

• [ ] 应用层协议是否包含 CRC 校验字段？
• [ ] Flash 中的关键配置是否带有 CRC？
• [ ] 是否实现了物理极限过滤？
• [ ] 是否实现了变化率过滤（防止突变）？
• [ ] 是否实现了静默区间检测（防止卡死）？
• [ ] 数据报文是否携带数据质量戳？
• [ ] 设备是否具备上电自检和周期性自检能力？

💡 核心思想：让错误死在端侧，让真相流向平台。​ 只有经过严格校验的数据，才配得上“智慧档案馆”的“智慧”二字。