3. 分层架构总览
TinyML工程的核心挑战在于：资源极度受限（KB级RAM、MHz级主频）、硬件平台碎片化（不同厂商的MCU、传感器、通信模块）、以及算法迭代频繁（模型压缩、量化策略、前处理参数调整）。如果将所有逻辑揉杂在一个main函数或单文件中，初期开发看似迅速，但一旦进入产品化阶段——需要适配新传感器、调整推理频率、排查偶发故障——代码的脆弱性便会集中爆发。分层架构设计的本质，是通过明确的职责边界和依赖方向，将“易变的部分”与“稳定的部分”隔离，从而在资源受限的前提下，依然获得可测试性、可维护性与可扩展性。本章将围绕高内聚低耦合、可测试性、可维护性三大原则，结合TinyML特有的约束（如中断上下文、内存池、实时性要求），给出可落地的设计方法与判断标准。
上图展示了TinyML四层架构（驱动层、前处理层、推理层、业务逻辑层）之间的依赖关系与设计原则映射。箭头方向表示“上层依赖下层接口”，而非“上层直接操作下层内部数据”。这种单向依赖是低耦合的基础。值得注意的是，驱动层与业务逻辑层之间不直接通信，而是通过前处理层和推理层间接交互，这避免了硬件变更对业务逻辑的冲击。下面从三个核心原则展开论述。
3.1 高内聚低耦合：在资源受限下的边界划分
核心原理：内聚与耦合的量化理解
高内聚指模块内部的元素（函数、变量、数据结构）紧密关联，共同完成单一职责。低耦合指模块之间的依赖关系简单、明确、最小化。在TinyML中，由于RAM和Flash有限，不能像服务器开发那样引入重量级框架，但分层思想依然适用。关键在于：每个层只做一件事，且通过接口通信。例如，驱动层只负责“读取传感器原始值”，不关心这个值是用于跌倒检测还是环境监测；业务逻辑层只负责“根据推理结果决定是否报警”，不关心模型是CNN还是决策树。
耦合度的判断标准可以量化：依赖方向是否单向？依赖是否通过接口而非直接变量访问？修改一个模块时，是否需要同时修改其他模块？在TinyML中，常见的耦合问题包括：业务逻辑直接操作寄存器、前处理代码硬编码传感器采样率、推理层与驱动层共享全局缓冲区等。
判断方法：依赖方向与接口稳定性检查
实际操作中，可以通过以下步骤评估耦合度：
- 绘制依赖图：列出所有模块，画出调用关系。如果出现循环依赖（A调用B，B又调用A），则耦合度过高。
- 检查接口参数：接口传递的是“数据”还是“硬件资源”？例如，驱动层向上传递的是
int16_t raw_value，而不是SPI_HandleTypeDef*，后者会暴露硬件细节。 - 模拟变更测试：假设更换传感器（如从BMI160换成LSM6DSO），需要修改哪些文件？如果只需修改驱动层，则耦合度合理；如果业务逻辑或前处理也要改动，则说明耦合过紧。
实战经验：在C语言中，使用static关键字限制模块内部函数的可见性，只暴露必要的接口函数。例如，驱动层头文件只声明void drv_accel_init(void)和int16_t drv_accel_read_x(void)，而将寄存器配置、DMA回调等函数设为static。这从编译层面强制了封装。
案例拆解：智能门锁的振动检测模块
某智能门锁产品需要检测“暴力撬锁”事件，使用加速度计（ADXL345）和MCU（STM32L0）。初始设计将所有代码写在main.c中：读取传感器、计算振动幅度、判断阈值、触发报警。当产品需要增加“倾斜检测”功能时，发现原有代码无法复用，且修改阈值时容易误触报警。
重构方案：
- 驱动层：封装
accel_init()、accel_read()，返回三轴原始值。 - 前处理层：实现
preproc_calc_magnitude()，计算振动幅度；preproc_calc_tilt()，计算倾斜角。 - 业务逻辑层：定义
app_detect_intrusion()，调用前处理层接口，结合阈值判断。
结果对比：重构后，新增倾斜检测只需在业务逻辑层增加一个状态判断，前处理层增加一个函数，驱动层完全不变。代码量减少约20%，且单元测试覆盖率从30%提升到75%。
3.2 可测试性：在无硬件环境下验证逻辑
核心原理：测试的层次与策略
TinyML的可测试性面临双重挑战：硬件依赖（传感器、时钟、外设）和资源限制（无法运行完整测试框架）。分层架构的价值在于：每一层都可以独立测试，而不需要真实硬件。驱动层可以通过模拟寄存器映射测试；前处理层可以输入固定数组验证算法输出；推理层可以使用已知模型和输入张量比对输出；业务逻辑层可以注入模拟的推理结果。
可测试性的核心是依赖注入。在C语言中，可以通过函数指针或条件编译实现。例如，驱动层提供drv_accel_read()，测试时用mock_accel_read()替换，返回预设的传感器数据序列。
操作流程：构建分层测试策略
| 测试层次 | 测试对象 | 测试方法 | 所需环境 |
|---|---|---|---|
| 单元测试 | 前处理算法、业务逻辑状态机 | 直接调用函数，传入边界值 | PC + 编译器 |
| 接口测试 | 层间接口契约（如驱动返回数据范围） | Mock驱动，验证上层对异常数据的处理 | PC + 模拟器 |
| 集成测试 | 驱动+前处理+推理的联合流程 | 使用录制好的传感器数据回放 | 开发板 + 调试器 |
| 硬件在环测试 | 真实传感器+真实模型 | 运行完整固件，采集实际输出 | 目标硬件 |
在PC上进行单元测试时，需要注意浮点与定点的一致性。如果目标MCU不支持FPU，前处理层应使用定点运算，测试时需用定点模拟器。
经验提醒：为前处理层设计“黄金向量”测试集。从真实传感器采集一组典型数据（如静止、运动、冲击），保存为C数组。每次修改算法后，运行测试比对输出是否在容差范围内。这比随机测试更有效，能捕捉回归问题。
案例拆解：语音唤醒词的前处理测试
某TinyML语音唤醒项目，前处理层包含：音频帧缓冲、FFT、梅尔滤波器组、归一化。由于MCU上无法直接调试浮点FFT，开发者在PC上使用Python脚本生成测试向量，然后导入C代码进行单元测试。
关键步骤：
- 在PC上运行相同的C代码（通过CMake构建），输入一段16kHz/16bit的PCM音频数据。
- 将输出与Python参考实现（使用NumPy）对比，设置误差阈值（如
1e-4）。 - 将测试向量和预期结果固化为C头文件，在MCU上运行同样的测试，验证定点实现与浮点实现的偏差。
结果：发现定点FFT在低频段误差较大，通过调整缩放因子解决了问题。如果没有分层设计，这类问题将难以定位——因为无法区分是传感器问题、FFT问题还是模型输入格式问题。
3.3 可维护性：应对需求变化与缺陷修复
核心原理：可维护性的三个维度
可维护性体现在三个方面：可理解性（代码结构清晰，命名规范）、可修改性（修改一个功能不影响其他功能）、可扩展性（新增功能不需要重写现有代码）。在TinyML中，可维护性往往被忽视，因为产品一旦部署，很少OTA升级。但实际中，传感器漂移需要重新校准、模型需要更新阈值、新法规要求调整报警逻辑——这些都需要快速修改。
分层架构通过稳定的接口和明确的模块边界来保证可维护性。例如，驱动层接口drv_accel_read()一旦定义，就不应改变；如果传感器更换，只需在驱动层内部修改寄存器配置，接口保持不变。
判断方法：维护性指标与代码坏味道
可以通过以下问题评估可维护性：
- 修改一个传感器采样率，需要改动几个文件？理想情况是1个（驱动层配置）。
- 新增一个“低功耗模式”，是否需要修改推理层？理想情况是不需要，业务逻辑层调用驱动层的
drv_sleep()即可。 - 代码中是否存在
#ifdef嵌套超过3层？这通常意味着平台耦合过紧。 - 全局变量是否被多个模块直接读写？如果是，则破坏了封装。
风险提示：在TinyML中，过度设计也是可维护性的敌人。如果为每个传感器都抽象出“设备树”或“插件机制”，会消耗大量Flash和RAM，且增加调试复杂度。建议采用“轻量分层”：每个层只提供3-5个核心接口，避免泛化。
案例拆解：工业预测性维护的传感器更换
某工厂部署了振动监测节点，使用ST的IIS3DWB加速度计（支持高频采样）。半年后，因供应链问题需要更换为ADI的ADXL357。两种传感器的寄存器配置、量程、输出格式均不同。
维护过程：
- 驱动层：新增
drv_adxl357.c，实现相同的接口drv_accel_init()、drv_accel_read()。 - 前处理层：无需修改，因为输入数据格式已由驱动层统一为
int32_t三轴值。 - 业务逻辑层：无需修改，阈值和状态机保持不变。
- 编译时通过链接脚本选择使用哪个驱动文件。
结果：整个更换过程耗时2小时（主要是驱动调试），而如果采用单文件架构，需要排查所有引用传感器寄存器的地方，预计耗时2天。此外，由于驱动层接口稳定，自动化测试用例全部复用，无需重新编写。
3.4 常见误区与设计权衡
误区一：为了分层而分层，导致性能下降
有些开发者将每个函数都封装成“层”，导致函数调用嵌套过深，增加栈开销和调用延迟。在TinyML中，性能与架构的平衡需要量化：如果一次函数调用增加5个周期，而推理本身需要10万周期，则分层开销可忽略；但如果前处理是高频调用（如每毫秒一次），则需考虑内联或宏。
正确做法：将“热路径”（高频调用）的函数标记为inline，或直接放在同一编译单元中。例如，驱动层的drv_accel_read()如果只是读取一个寄存器，可以定义为static inline，既保持接口清晰，又避免调用开销。
误区二：接口设计过于抽象，丢失硬件特性
为了“通用”，有些驱动层接口设计为void drv_sensor_read(uint8_t* buf, uint32_t len)，将传感器数据当作字节流。这导致前处理层需要解析字节序、对齐等细节，反而增加了耦合。
正确做法：接口应体现“领域语义”。例如，加速度计驱动应返回accel_data_t结构体，包含int32_t x, y, z和uint32_t timestamp。这样前处理层直接使用结构体字段，无需关心底层字节布局。
误区三：忽视中断上下文与主循环的边界
驱动层通常在中断中读取传感器数据，而前处理和推理在主循环中执行。如果中断处理函数直接调用前处理或业务逻辑函数，会导致数据竞争和不可重入问题。
正确做法：驱动层只负责将数据放入环形缓冲区（Ring Buffer），并通过标志位通知主循环。前处理层从缓冲区读取数据，而不是直接访问寄存器。这保持了层间时序解耦。
总结复盘：分层架构的落地清单
| 原则 | 关键动作 | 验证标准 |
|---|---|---|
| 高内聚 | 每个模块只做一件事，内部函数用static隐藏 | 修改一个功能时，不涉及其他模块 |
| 低耦合 | 层间通过接口传递数据，不暴露硬件类型 | 更换传感器/通信模块时，只改驱动层 |
| 可测试性 | 为每层设计mock接口，使用黄金向量回归 | PC上可运行80%以上的逻辑测试 |
| 可维护性 | 接口稳定，新增功能通过扩展而非修改 | 代码坏味道检查（全局变量、深层ifdef） |
在TinyML工程中，分层架构不是“银弹”，但它提供了在资源受限下管理复杂度的有效路径。关键在于：识别哪些部分会变化（传感器型号、算法参数、业务规则），哪些部分稳定（接口契约、数据流方向），然后将变化的部分隔离在层内。通过高内聚低耦合、可测试性、可维护性三大原则的落地，即使是最小的MCU项目，也能获得接近大型软件工程的健壮性。