3、边界值检查基础：什么是边界值、有效范围、数据类型限制，以及为什么边界检查是防护的第一道防线

TinyML 设备通常部署在物理环境不可控的嵌入式系统中，传感器采集到的数据是系统决策的唯一依据。然而，传感器数据在真实世界中并不总是“干净”的——电磁干扰、电源波动、机械振动、老化漂移，甚至恶意攻击者通过物理手段（如强光照射摄像头、扬声器播放超声波、磁场干扰磁力计）注入的伪造信号，都会导致输入值偏离正常物理规律。边界值检查（Boundary Value Check）正是抵御这类异常的第一道闸门：它不依赖复杂的机器学习模型，也不消耗大量算力，仅通过比对输入数据是否落在预先定义的合法区间内，就能拦截绝大多数明显异常的数据包。本章将系统讲解边界值的核心概念、有效范围与数据类型限制的关系，以及为什么这项看似简单的技术是 TinyML 安全防护体系中性价比最高的基础防线。

上图展示了边界值检查在 TinyML 数据流中的核心位置。传感器原始数据首先经过边界检查引擎，只有落在有效范围内的数据才能进入后续的模型推理环节。这个看似简单的“闸门”实际上包含了三个维度的约束：物理极限、数据类型限制和业务逻辑约束。下面我们将逐一深入剖析这些概念。

3.1 核心原理：边界值的本质与构成

边界值（Boundary Value）是指一个变量在特定上下文中被允许取值的上下限。在 TinyML 系统中，边界值并非随意设定，而是由三个层次共同决定的：物理层边界、数据层边界和业务层边界。物理层边界由传感器硬件规格决定，例如一个典型的 MEMS 加速度计（如 MPU6050）量程为 ±2g、±4g、±8g、±16g，当配置为 ±2g 时，输出值理论上不应超过 ±2g 对应的数字量。数据层边界由编程语言的数据类型决定，例如 int8_t 的取值范围是 -128 到 127，如果传感器输出被强制转换为 int8_t，任何超出该范围的值都会发生溢出或截断。业务层边界则与应用场景相关，例如一个室内温度监测系统，即使温度传感器量程为 -40°C 到 125°C，业务上合理的范围可能只有 0°C 到 50°C。

有效范围（Valid Range）是这三个边界集合的交集。换句话说，一个输入值必须同时满足物理可行性、数据类型可表示性和业务合理性，才能被视为“有效”。例如，一个 16 位 ADC 采集的光照传感器，其原始输出范围是 0~65535，但物理上光照强度不可能为负，且业务上可能只关注 0~1000 lux 的范围，那么有效范围就是 0~1000（经过线性映射后）。边界值检查的核心任务就是定义这个交集，并在运行时对每个输入样本进行快速比对。

3.2 数据类型限制：隐形的边界陷阱

数据类型限制是边界值检查中最容易被忽视的环节。在 TinyML 中，为了节省内存和计算资源，开发者常常使用小位宽的数据类型（如 int8_t、uint16_t），这本身就引入了隐形的边界。考虑以下场景：一个温度传感器输出 -30°C 到 80°C 的浮点值，开发者将其缩放并转换为 int8_t 存储。如果缩放因子选择不当，例如将 1°C 映射为 1 个 LSB，那么 -30°C 映射为 -30，80°C 映射为 80，这都在 int8_t 范围内。但如果传感器因故障输出 150°C，转换为 int8_t 后会发生溢出，变成 -106，这个值反而落在“看似合理”的范围内，从而绕过检查。

上表总结了 TinyML 中常见数据类型及其边界。值得注意的是，溢出并不总是产生随机值——在 C/C++ 中，有符号整数溢出是未定义行为，可能导致任意值；而无符号整数溢出则回绕（wrap around）。例如 uint16_t 的 65535 加 1 会变成 0。这种回绕特性可能被攻击者利用：如果攻击者知道系统使用 uint16_t 存储 ADC 值，他们可以注入一个 65535 的值，使其回绕为 0，从而绕过“最小值检查”。因此，边界检查必须在数据类型转换之前对原始数据进行验证，或者在转换后立即进行二次验证。

3.3 判断方法与操作流程：如何实施有效的边界检查

实施边界值检查并非简单地写两个 if 语句。一个健壮的边界检查流程应包含以下步骤：

1. 定义边界常量：在代码中明确声明 #define SENSOR_MIN_VALID -30.0f 和 #define SENSOR_MAX_VALID 80.0f，而不是在比较时硬编码数字。这样便于维护和审计。
2. 选择检查时机：边界检查应在数据进入系统后的最早阶段执行。对于传感器中断驱动的采集，应在中断服务程序（ISR）中或紧随其后进行检查；对于 DMA 批量传输，应在数据拷贝到处理缓冲区后立即检查。
3. 处理异常值：定义超出边界时的行为。常见策略包括：丢弃该样本并计数、用上一次有效值替代、饱和截断（clamp）到边界值、或者触发系统告警。对于安全关键系统（如医疗设备），应选择丢弃并告警；对于非关键系统（如环境监测），饱和截断可能更合适。
4. 记录异常日志：即使只是简单的计数器递增，也能为后续调试提供线索。例如 g_anomaly_count++，当计数超过阈值时触发更高级别的防护。

// 示例：带边界检查的传感器数据读取
#define TEMP_MIN_VALID   -30.0f
#define TEMP_MAX_VALID    80.0f

float read_temperature_sensor() {
    float raw = sensor_read();  // 假设返回浮点温度值
    
    // 边界检查：在数据类型转换之前执行
    if (raw < TEMP_MIN_VALID || raw > TEMP_MAX_VALID) {
        g_anomaly_count++;
        // 策略：丢弃并返回上次有效值
        return g_last_valid_temp;
    }
    
    g_last_valid_temp = raw;
    return raw;
}

上述代码展示了边界检查的基本模式。注意检查发生在 sensor_read() 返回原始浮点值之后、任何量化或类型转换之前。这样可以避免因类型转换引入的溢出问题。

3.4 案例拆解：智能家居温控器的传感器欺骗攻击

让我们通过一个完整的案例来理解边界值检查的实际价值。假设我们正在开发一款智能家居温控器，使用 NTC 热敏电阻测量室内温度，ADC 采样值为 12 位（0~4095），通过查表映射为温度值（-20°C 到 60°C）。系统使用 int16_t 存储温度值，并设定业务有效范围为 10°C 到 35°C（舒适区间）。

攻击场景：攻击者使用一个信号发生器向温控器的模拟前端注入一个 3.3V 的直流电压，模拟 NTC 电阻短路的故障状态。此时 ADC 输出满量程 4095，查表映射后得到 60°C。如果系统没有边界检查，温控器会认为室内温度过高，从而启动制冷模式，造成能源浪费甚至设备损坏。

分析过程：我们检查三个层次的边界：物理层边界（ADC 量程 0~4095，对应 -20°C 到 60°C）——60°C 在物理层是合法的；数据层边界（int16_t 范围 -32768~32767）——60 在范围内；业务层边界（10°C 到 35°C）——60°C 超出了业务合理范围。因此，业务层边界检查能够拦截这次攻击。

实施步骤：

1. 在温度映射函数后添加业务边界检查：if (temp < 10.0f || temp > 35.0f) { handle_anomaly(); }
2. 在 handle_anomaly() 中，将温度值饱和截断到 35°C，并设置告警标志。
3. 连续 3 次异常后，系统进入安全模式，关闭制冷/加热输出，并通知用户。

结果对比：未加边界检查时，系统在攻击后 2 秒内启动制冷压缩机；加入边界检查后，系统在 10ms 内识别异常，并在 3 次异常后（约 30ms）进入安全模式，避免了设备损坏。

风险与代价：边界检查增加了约 5 行代码和 2 次浮点比较，CPU 开销可忽略不计。但需要注意，如果业务边界设置过窄（例如将 10°C 设为下限），在寒冷地区冬季室内温度可能合法地低于 10°C，导致误报。因此，业务边界的设定需要结合历史数据和场景分析。

3.5 常见误区与总结复盘

在实际项目中，开发者常犯以下错误：

• 误区一：只检查物理边界，忽略业务边界。物理边界只能防止传感器损坏或极端干扰，无法防止针对业务逻辑的攻击。
• 误区二：在类型转换之后才做检查。如 3.2 节所述，转换可能引入溢出或回绕，导致异常值“伪装”成正常值。
• 误区三：边界值硬编码在代码深处。当传感器更换或业务需求变化时，难以定位和修改。
• 误区四：异常处理策略单一。所有异常都丢弃或都截断，没有根据异常频率和严重程度分级处理。