固件逻辑解析：以太网 TCP 温湿度记录仪在存储满时的环形队列覆盖策略

固件逻辑解析：以太网 TCP 温湿度记录仪在存储满时的环形队列覆盖策略

一、问题背景：存储满了的“沉默风险”

在带本地存储的以太网温湿度记录仪中，Flash 或 SD 卡容量总是有限的。工程上常见一个被忽视的问题：

当存储区写满后，设备是停止记录、报错停机，还是静默覆盖？覆盖逻辑是否会导致关键数据丢失？

如果策略设计不当，会带来两类严重问题：

• 合规风险：金融、医疗、机房等场景要求环境数据“不可篡改、完整可追溯”，随意覆盖可能违反审计要求。
• 运维盲区：设备“看起来在线”，但实际上新数据已不再写入，平台却毫无感知。

因此，环形队列（Ring Buffer）覆盖策略是固件设计的核心逻辑之一。

二、环形队列：固件层面的“逻辑结构”

1. 物理存储 vs 逻辑视图

在固件中，物理 Flash/SD 卡通常被抽象为一个线性地址空间，再逻辑上映射为环形队列：

物理存储（Flash/SD）
|---- 扇区 0 ----|---- 扇区 1 ----| ... |---- 扇区 N-1 ----|
逻辑环形队列：
Head → [数据块0][数据块1] ... [数据块N-1] → Tail

• Head（读指针）：最旧数据的起始位置
• Tail（写指针）：下一个待写入位置
• 队列长度：固定为 N 个数据块（由存储容量和单条记录大小决定）

2. 单条记录的典型结构

为便于覆盖和校验，每条记录通常采用固定长度二进制结构：

[时间戳 4B][温度 2B][湿度 2B][状态码 1B][序列号 2B][CRC 2B] = 13B

• 时间戳：Unix 时间或相对时间
• 序列号：单调递增，用于检测丢包和覆盖
• CRC：校验数据完整性

三、存储满时的三种固件策略对比

1. 策略一：停止写入（Stop-on-Full）

逻辑：

• 当 Tail 追上 Head（队列满）时，停止写入新数据
• 设备状态寄存器置位“存储满”标志
• 需人工干预（导出数据、擦除存储）后才能恢复

优点：

• 数据零覆盖，符合严格审计要求
• 实现简单，逻辑清晰

缺点：

• 新数据丢失，监控出现盲区
• 需运维人员定期干预，不适合无人值守场景

适用场景：金融、医疗等强合规场景，且有明确的数据导出流程。

2. 策略二：整体擦除后重写（Erase-and-Rewrite）

逻辑：

• 存储满后，触发 Flash 整片擦除（或 SD 卡文件重建）
• Tail 重置为 0，重新开始写入

优点：

• 逻辑简单
• 不存在“碎片化”问题

缺点：

• 擦除期间（数百毫秒到数秒）数据丢失
• Flash 频繁整片擦除，寿命急剧缩短
• 擦除失败可能导致数据全丢

适用场景：已基本被工业级设计淘汰，仅见于早期低成本方案。

3. 策略三：环形覆盖（Circular Overwrite，主流方案）

逻辑：

• 队列满后，Tail 继续向前，覆盖 Head 指向的最旧数据
• Head 自动前移一位，始终保持“最新 N 条数据”
• 覆盖以“数据块”为单位，而非单条记录

优点：

• 数据连续，无监控盲区
• 擦写均衡，延长 Flash 寿命
• 适合无人值守、长期运行场景

缺点：

• 最旧数据被静默覆盖，需通过机制规避关键数据丢失
• 实现逻辑相对复杂（需处理指针回绕、掉电保护）

适用场景：工业监控、机房动环、边缘节点等绝大多数场景。

四、工业级固件的环形覆盖增强机制

成熟的以太网温湿度记录仪固件，不会“裸奔”式覆盖，而是叠加多层保护机制。

1. 双指针 + 哨兵值（Sentinel）

• 写指针（Tail）：指向下一个写入位置
• 读指针（Head）：指向最旧有效数据
• 哨兵值：每个数据块头部写入特定魔数（如 0xAA55）
• 覆盖逻辑：
  • 写入前检查哨兵值，确认为“已使用块”才覆盖
  • 写入完成后更新哨兵值，避免掉电导致半写数据

2. 掉电保护：原子操作与日志

Flash 写入过程中若掉电，可能导致数据损坏。工业固件通常采用：

• 原子写入：单条记录写入为原子操作，要么完整写入，要么无效
• 写前日志（Journal）：先写日志区，标记“即将写入”，写入完成后再清除日志
• 启动自检：上电时扫描队列，根据哨兵值和 CRC 修复不一致状态

3. 关键数据“写保护窗口”

为避免刚发生的告警数据被立即覆盖，固件通常实现时间窗口保护：

• 最近 T 分钟（如 30 分钟）的数据标记为“受保护”
• 覆盖时跳过受保护块，直到窗口过期
• 平台侧可通过 SNMP/Modbus 读取“受保护窗口大小”和“最早有效时间戳”

4. 存储水位告警（Water Mark）

固件维护两个阈值：

价值：运维人员可在数据被覆盖前介入（导出、备份）。

5. 序列号与覆盖检测

每条记录包含 2 字节序列号（0–65535，溢出回绕）：

• 平台读取数据时，检测序列号连续性
• 发现跳变（如 100 → 200），判定为发生覆盖
• 结合时间戳，精确计算覆盖的数据量

五、平台侧如何“感知”覆盖行为

仅靠设备本地逻辑不够，平台侧需具备覆盖感知能力：

1. 设备状态寄存器映射（Modbus TCP 示例）

2. 数据补传时的“覆盖标记”

设备补传历史数据时，在协议头中增加标志位：

[数据标志:1B]
  bit0: 0=实时数据, 1=历史补传
  bit1: 0=正常, 1=来自覆盖区

平台据此区分数据来源，避免将补传数据误判为实时异常。

3. 覆盖事件告警联动

• 设备触发“存储满，开始覆盖”事件时，主动上报 Trap 或 MQTT 消息
• 平台记录覆盖事件日志，关联责任人
• 关键区域设备可联动短信/邮件通知运维人员

六、工程选型时的固件逻辑核查清单

在采购以太网温湿度记录仪时，建议通过以下方式验证固件覆盖策略：

1. 文档核查

• [ ] 产品手册是否明确说明存储满后的行为？
• [ ] 是否支持环形覆盖？是否可配置为“停止写入”？
• [ ] 是否提供存储水位阈值配置接口？

2. 实测验证

• [ ] 填满存储，观察设备是否继续在线、新数据是否可查
• [ ] 读取 Head/Tail 时间戳，确认覆盖逻辑符合预期
• [ ] 模拟掉电，重启后检查数据完整性（CRC、哨兵值）
• [ ] 导出覆盖区数据，验证平台是否能正确识别“覆盖标记”

3. 平台对接

• [ ] 平台是否能读取存储状态（容量、水位、覆盖标志）？
• [ ] 覆盖事件是否能触发告警？
• [ ] 历史数据补传是否区分“覆盖区”与“正常区”？

七、典型固件逻辑伪代码（简化版）

// 环形队列初始化
void ringbuf_init() {
    head = 0;
    tail = 0;
    for (int i = 0; i < N; i++) {
        block[i].sentinel = SENTINEL_FREE;
    }
}

// 写入一条记录
int ringbuf_write(record_t *rec) {
    // 1. 检查 tail 指向块是否可覆盖
    if (block[tail].sentinel == SENTINEL_INUSE) {
        // 队列满，触发覆盖
        head = (head + 1) % N;  // Head 前移
        set_overwrite_flag();    // 置位覆盖标志
        log_event("Overwrite at %d", tail);
    }

    // 2. 写入数据（原子操作）
    block[tail].sentinel = SENTINEL_WRITING;
    memcpy(&block[tail].data, rec, sizeof(record_t));
    block[tail].crc = calc_crc(rec);
    block[tail].sentinel = SENTINEL_INUSE;

    // 3. 更新 tail
    tail = (tail + 1) % N;

    // 4. 更新水位状态
    update_water_mark();

    return SUCCESS;
}

// 启动时自检
void ringbuf_self_check() {
    for (int i = 0; i < N; i++) {
        if (block[i].sentinel == SENTINEL_WRITING) {
            // 发现未完成的写入，标记为损坏
            block[i].sentinel = SENTINEL_CORRUPT;
        }
    }
}

八、小结：覆盖策略的“三个透明”

1. 行为透明：设备必须明确告知“存储满后做什么”，不能静默处理
2. 状态透明：平台必须能实时读取存储水位、覆盖标志、最早/最新数据时间
3. 数据透明：补传数据必须标记来源，避免误判

一句话选型原则：

无人值守选环形覆盖，强合规场景选停止写入；无论哪种策略，必须“水位告警 + 覆盖标记 + 平台联动”三件套齐全。

本文基于工业级以太网温湿度记录仪固件逆向分析与工程实测整理，适用于带本地存储的物联网终端、环境监测设备的固件逻辑评估与选型参考。