📚 课程目录第3章分层架构思想

3、分层架构思想：理解传感器层、模型层、应用逻辑层的职责划分，以及分层带来的可维护性、可扩展性和可测试性优势

在Arduino TinyML项目中，我们面对的不再是单一的“读取传感器-处理数据-输出结果”简单循环，而是一个包含数据采集、信号调理、特征提取、模型推理、结果决策、执行器控制、状态上报等多环节的嵌入式智能系统。如果将所有代码堆叠在loop()函数中，项目初期或许能快速运行，但随着功能增加、传感器更换或模型迭代，代码将迅速腐化，变得难以阅读、调试和扩展。分层架构正是解决这一问题的核心工程方法论。它将系统按职责划分为传感器层、模型层和应用逻辑层，每层只关注自己的任务，通过清晰的接口进行通信，从而让TinyML项目具备真正的产品级品质。

上图清晰地展示了三层架构的核心数据流：传感器层负责将物理世界转换为数字特征向量，通过接口A传递给模型层；模型层完成推理后，将结果通过接口B交给应用逻辑层；应用逻辑层根据业务规则做出最终决策并驱动执行器。同时，应用逻辑层可以通过反馈通道对传感器层进行配置校准（如调整采样率、修改滤波参数），形成闭环控制。下面我们深入剖析每一层的职责边界与工程实践要点。

3.1 核心原理：为什么TinyML项目必须分层

分层架构的本质是关注点分离。在TinyML场景下，这种分离尤为重要，因为嵌入式系统的资源极度受限，且硬件迭代频繁。如果不分层，传感器驱动代码、TensorFlow Lite Micro的调用代码、业务逻辑判断代码会交织在一起，产生以下典型问题：

耦合度过高：更换一个传感器型号，可能需要修改模型输入预处理、应用逻辑中的阈值判断，甚至影响执行器控制时序。
测试困难：无法单独验证模型推理的正确性，因为每次测试都必须依赖真实传感器数据和完整执行链路。
复用性差：从项目A复制代码到项目B时，不得不剥离大量无关逻辑，且容易引入隐藏依赖。

分层架构通过定义稳定的接口，将这三类变化隔离。传感器层的变化（如从DHT11换为SHT30）不影响模型层和应用层；模型层的变化（如从MobileNetV1换为MobileNetV2）不影响传感器层和应用层；应用逻辑层的变化（如从“超阈值报警”改为“超阈值且持续3秒才报警”）不影响底层。这种隔离带来的直接收益是：每个层都可以独立开发、独立测试、独立演进。

工程经验：在Arduino Uno这类仅有2KB SRAM的平台上，分层带来的代码体积开销通常小于5%，但可维护性提升是数量级的。建议在项目一开始就建立分层结构，而不是等代码膨胀后再重构——嵌入式环境下的重构成本远高于PC端。

3.2 传感器层：从物理信号到标准化特征向量

传感器层是系统与物理世界交互的边界。它的职责不是简单的“读取数据”，而是完成从原始物理量到标准化特征向量的转换。这一层通常包含四个子模块：

硬件驱动：封装具体的传感器通信协议（I2C、SPI、单总线等），对外提供统一的读取接口。例如，无论使用MPU6050还是LSM6DS3，都提供readAccel()和readGyro()函数。
信号调理：包括滑动平均滤波、中值滤波、高通/低通滤波、传感器校准（如零点漂移补偿、温度补偿）。这些操作在时域或频域上进行，目的是提高信噪比。
特征提取：从调理后的信号中计算有意义的特征。对于时间序列数据，常见特征包括均值、方差、峰值、过零率、FFT频谱能量等。特征提取是TinyML中最关键的一步——好的特征可以显著降低模型复杂度。
数据帧封装：将特征向量打包成固定长度的数组，并附带时间戳、数据质量标志等元信息，通过接口A传递给模型层。

传感器层的设计要点是接口稳定性。无论底层硬件如何变化，向上层输出的特征向量格式必须保持一致。例如，定义一个结构体：

typedef struct {
  float features[6];      // 例如: [accX_mean, accY_mean, accZ_mean, gyroX_var, gyroY_var, gyroZ_var]
  uint32_t timestamp_ms;  // 数据采集时间戳
  uint8_t quality;        // 数据质量标志: 0=正常, 1=饱和, 2=异常
} SensorFrame_t;

这样，当传感器从MPU6050更换为BMI160时，只需要修改驱动和信号调理部分，特征提取和上层代码完全不受影响。

3.3 模型层：推理引擎与张量生命周期管理

模型层是TinyML项目的核心智能所在，它负责加载预训练的TFLite模型，管理输入输出张量，并执行推理计算。这一层需要关注以下关键点：

模型加载与内存分配：在Arduino上，模型通常以C数组形式存储在Flash中。使用tflite::GetModel()加载，并通过tflite::MicroInterpreter分配Tensor Arena内存。需要精确计算所需内存大小，避免溢出。
输入张量预处理：传感器层传来的特征向量往往需要经过归一化、缩放或维度变换才能匹配模型的输入要求。例如，模型输入是[1, 6]的float数组，且要求数值范围在[-1, 1]之间，则需要在填充张量前进行转换。
推理执行与输出解析：调用interpreter->Invoke()执行推理，然后从输出张量中读取结果。对于分类模型，输出通常是各类别的概率分数；对于回归模型，输出可能是连续数值。
错误处理：推理过程中可能出现内存不足、算子不支持等问题。模型层应捕获这些错误并向上层返回明确的状态码，而不是让系统静默崩溃。

模型层的设计目标是无状态性——它不关心数据从哪里来，也不关心结果用到哪里去。每次调用model_predict(features, result)，输入特征向量，输出推理结果，内部不保存任何业务状态。这种设计使得模型层可以被单独测试：你可以编写一个测试脚本，喂入已知的特征向量，验证输出是否符合预期。

实践建议：在模型层中封装一个ModelResult_t结构体，包含float scores[CLASS_NUM]、uint8_t top_class、float confidence等字段。这样应用逻辑层无需了解张量细节，直接使用语义化的结果。

3.4 应用逻辑层：业务规则与执行决策

应用逻辑层是系统的“大脑皮层”，它根据模型层的推理结果，结合业务规则和系统状态，做出最终决策。这一层通常包含：

结果解析与置信度判断：模型输出的是概率分布，应用层需要决定“当置信度超过多少时才认为有效”。例如，在跌倒检测中，如果“跌倒”类别的概率大于0.8才触发报警，否则视为误检。
状态机管理：许多TinyML应用需要多状态转换。例如，一个手势识别系统可能有“待机-识别中-已确认-执行动作”等状态。状态机让逻辑清晰且易于调试。
执行器控制：根据决策结果驱动LED、电机、蜂鸣器、振动马达等外设。控制逻辑应包含防抖、超时保护、错误恢复等机制。
通信与上报：通过串口、BLE或WiFi将结果上报给上位机或云端。上报格式应独立于内部实现，例如使用JSON或简单的二进制协议。

应用逻辑层是业务变化最频繁的地方。例如，产品经理要求“将报警阈值从0.8改为0.6”，或者“增加连续3次检测到异常才报警”的规则。如果这些逻辑分散在代码各处，修改将非常痛苦；而在分层架构中，只需修改应用逻辑层的决策函数，传感器层和模型层完全不动。

3.5 分层带来的三大核心优势

优势维度	具体表现	工程价值
可维护性	每层代码职责单一，文件结构清晰；修改传感器驱动不影响模型推理；修改业务规则不影响数据采集。	降低Bug修复成本，新工程师能快速定位问题模块，代码评审更有针对性。
可扩展性	增加新传感器只需扩展传感器层；更换模型只需替换模型层；增加新功能（如远程升级）只需在应用层添加模块。	支持产品快速迭代，适应硬件平台迁移（从Arduino到ESP32），复用已验证的层模块。
可测试性	可以单独测试传感器层（用模拟数据代替真实硬件）；可以单独测试模型层（喂入固定特征向量）；可以单独测试应用层（模拟推理结果）。	实现持续集成，在硬件就绪前即可开发上层逻辑，自动化测试覆盖率显著提升。

3.6 案例拆解：智能穿戴跌倒检测项目重构

我们以一个典型的TinyML项目——基于IMU的跌倒检测手环为例，展示分层架构的实际应用。项目硬件：Arduino Nano 33 BLE Sense（集成IMU）、LED指示灯、蜂鸣器、振动马达。原始代码将所有功能写在loop()中，导致以下问题：

更换IMU传感器时，需要修改数据读取、特征计算、模型输入预处理三处代码。
无法单独验证模型准确性，每次测试都必须佩戴手环实际跌倒。
增加“跌倒后自动发送BLE通知”功能时，不得不重构整个主循环。

重构后，代码结构如下：

// sensor_layer.h
SensorFrame_t read_sensor_frame();  // 采集+滤波+特征提取

// model_layer.h
ModelResult_t model_predict(const float* features, uint8_t len);

// app_layer.h
void app_handle_result(const ModelResult_t& result);
void app_state_machine_update();

在loop()中，调用流程变得非常简洁：

void loop() {
  SensorFrame_t frame = read_sensor_frame();
  ModelResult_t result = model_predict(frame.features, 6);
  app_handle_result(result);
  delay(50);  // 20Hz采样
}

重构后的效果对比：

指标	重构前	重构后
代码行数	约800行（全部在ino文件）	约600行（分3个模块+主文件）
更换传感器耗时	约2天（需调试多处）	约2小时（仅修改sensor_layer.cpp）
模型测试效率	需真实跌倒实验，每次约10分钟	可编写PC端测试脚本，秒级完成
新增BLE上报功能	需理解全部代码后插入逻辑	在app_layer中新增一个函数，不影响其他层

这个案例充分说明，分层架构虽然初期需要多花一些时间设计接口，但在项目生命周期内带来的效率提升是巨大的。

3.7 常见误区与总结复盘

误区一：过度设计。对于只有几百行代码的极简TinyML项目，强行分层可能显得繁琐。但建议至少将传感器驱动和业务逻辑分离，为后续扩展留有余地。

误区二：接口定义模糊。如果层与层之间传递的是“裸数据”（如直接传递float数组），而没有结构体封装，那么层之间的耦合依然存在。务必定义清晰的数据结构。

误区三：忽略错误传播。传感器读取失败、模型推理异常等情况必须通过返回值或状态码向上层传递，而不是在层内部静默处理或直接复位。

误区四：层内再分层混乱。有些开发者会在传感器层内部直接调用模型层函数，破坏了单向依赖原则。记住：依赖方向必须是从上到下，应用层可以依赖模型层和传感器层，但传感器层绝不能依赖模型层。

总结来说，分层架构是TinyML项目从“原型”走向“产品”的必经之路。它通过职责隔离、接口标准化和单向依赖，让嵌入式AI系统变得可维护、可扩展、可测试。在实际项目中，建议从传感器层开始，逐步向上构建，每完成一层就编写对应的测试用例，确保每一层的正确性后再进行集成。这样，当系统最终运行时，你会发现自己对每一行代码的行为都有清晰的预期——这正是分层架构带来的最大信心保障。