异常振动监测终端系统架构：多任务协作与双通道遥测

本文基于真实项目脱敏整理。文中函数签名和接口名称为说明架构而设计，与实际业务代码不完全对应，请关注设计思路而非具体 API 命名。

我负责了一款工业振动异常监测终端的系统架构设计。设备运行 RT-Thread，搭载 4G LTE Cat.1 模组和三轴 MEMS 加速度计，内置 ST 边缘 AI 库。核心业务是：采集振动数据 → AI 本地推理识别异常模式 → 将状态和原始波形上报云端。本文从顶层视角复盘系统的任务划分、调用链和数据通路设计。

一、硬件与软件底座

二、系统任务架构

系统按职责划分为四个任务，优先级从高到低：

任务间通过事件和函数调用协作，不直接共享数据：

传感器中断
    │
    ▼
数据采集任务 ──(事件)──→ 配置管理任务（参数变更时）
    │
    │ (调用通讯 API)
    │
    ▼
4G 通讯任务 ──→ MQTT / TCP ──→ 云端

数据采集任务生产上报数据后，调用通讯层 API 将数据交给通讯任务；通讯任务通过 4G 模组发往云端。业务代码只跟函数打交道，不感知模组的存在。

除了 4G 远程通道，设备还提供 NFC 本地配置接口。NFC 芯片与 MCU 通过 FIFO 交换数据，我封装了一个轻量级同步协议，支持读卡器近距离读写设备参数——无需 4G 联网、无需设备上电，在生产调试和现场维护场景下尤其实用。

三、数据采集与 AI 推理链路

设备日常处于深度休眠状态，CPU 降频运行，4G 模组断电。振动检测链路分四个阶段：

1. 稀疏唤醒。加速度计配置了运动阈值，振动超过阈值时产生硬件中断，将 MCU 从休眠中唤醒。此时只记录唤醒时间戳，不启动采集，立即重新入睡。这个阶段功耗极低，仅靠中断计数感知环境振动密度。

2. 频率判定与模组预上电。当短时间内唤醒次数超过预设频率阈值，说明振动事件具有持续性——不是偶发的环境扰动，而是真正需要关注的异常振动模式。此时设备正式唤醒：提高 CPU 主频，传感器切换到高采样率模式，同时 4G 模组开始上电入网。4G 模组从冷启动到驻网成功大约需要十几秒，恰好与振动持续采集窗口重叠——等到 AI 推理完成、确认需要上报时，模组已经就绪，无需额外等待。

3. AI 推理。以高采样率持续采集三轴加速度原始数据，喂入 ST 边缘 AI 库 模型进行本地推理。推理是计算密集型任务，短暂的 CPU 升频窗口刚好覆盖计算需求，输出分类结果和置信度后立即降回低功耗频率。

4. 上报决策。如果推理结果需要关注且上传功能已使能，走双通道上报流程：先通过 TCP 将原始波形数据发送到 AI 分析服务，服务端返回一个上报 ID；再将这个 ID 打包进 MQTT 报文，通过 MQTT 通道发送。云端根据上报 ID 将两次上报关联。上报完成后 4G 模组断电，系统恢复深度休眠。

这条链路的设计原则是按需唤醒，用完即退——传感器阈值做第一道筛选，频率判定做第二道筛选，AI 推理做最终裁决。三层递进保证 CPU 高频和 4G 模组只在真正需要时才工作，最大限度压缩高功耗窗口。

四、双通道遥测：控制面与数据面分离

设备需要上报两类数据，特性截然不同：

MQTT 通道承载常规遥测和远程控制。上行报文包含设备标识、信号强度、GPS 位置、电池电量、报警等级等信息；下行支持两类指令：运行参数热更新和 OTA 固件升级。

TCP 通道专用于 AI 原始波形数据。采用自定义二进制帧协议：固定头 → JSON 元数据（采样率、AI 分类结果、置信度等）→ 原始三轴加速度数组 → CRC32 校验。比走 MQTT broker 中转更高效，也避免大数据冲击信令通道。

两路数据通过服务端返回的上报 ID 在业务层关联——MQTT 报文携带这个 ID，云端据此把设备状态和 AI 分析结果串成闭环。

五、通讯层 API 封装

通讯任务对上暴露一组函数式 API，业务任务不感知 4G 模组的存在：

// MQTT 发布
comm_mqtt_pub(topic, payload, len);

// TCP 直连（AI 波形上报）
comm_tcp_connect(addr, port);
comm_tcp_send(chunk, len, is_last);

// 信息查询
comm_gps_query();
comm_signal_query();

// 回调注册
comm_register_recv(topic, callback_fn);
comm_register_sub(topic, callback_fn);

调用方只需调用函数，函数内部自动完成 AT 命令执行和重试。所有与 4G 模组的交互细节——AT 时序、超时重试、URC 处理——全部封装在通讯任务内部，业务代码零锁、零 AT 命令。

六、配置与云端协同

设备支持两种配置途径——远程 MQTT 和本地 NFC：

• NFC 本地配置：通过 NFC 芯片的 FIFO 与读卡器双向交换数据，封装了轻量级同步协议。无需 4G 联网即可读写设备参数，适用于生产调试和现场维护。
• 远程参数热更新：采集周期、报警阈值、使能开关等通过 MQTT 实时下发，设备收到后即时生效并持久化到 Flash。
• OTA 固件升级：MQTT 通知升级 → 断开 MQTT → HTTP 下载固件包 → CRC 校验 → 写入 Flash → 自动重启。
• 时间同步：利用 4G 网络时间自动校准设备 RTC，保证事件时间戳准确。
• 数据关联：MQTT 状态报文和 TCP 波形报文通过上报 ID 关联，云端统一展示。

七、设计总结

这套架构的核心思路是按职责拆分任务，按数据特性分流通道。数据采集、AI 推理、通讯传输、配置管理各司其职，任务间通过事件和 API 调用解耦。双通道设计将控制面和数据面分离，MQTT 保证实时双向通信，TCP 保证大数据吞吐效率。

面向资源受限的嵌入式设备做系统设计，核心是把每个模块的边界划清楚，让调用链简单、数据流向可控。

本文由 AI 辅助生成，可能存在错误或遗漏，请以实际资料和官方文档为准。