系统架构

本科毕业设计 · 2027 届 · 计算机工程学院

首页/系统架构

五层结构

系统分层架构：感知层（毫米波雷达、PIR、MQ 系列、语音模块）、本地判定层（STM32F103）、联网层（ESP32-S3）、云端（Node.js、SQLite）、家属端（Vue）
层级组成职责失效影响
感知层HLK-LD6002C-60G 雷达、HC-SR501 PIR、MQ-2、MQ-4、SU-03T 语音跌倒主判定、人体存在、活动辅助、环境超限、固定命令词交互检测能力整体失效
本地判定层STM32F103C8T6二次确认、久滞计时、声光报警、取消按键本地报警失效（最严重）
联网层ESP32-S3TinyFrame 解析、Wi-Fi、MQTT、断网缓存与补传远程推送失效，本地报警仍工作
云端Node.js + TypeScript + SQLite校验、入库、event_id 去重、REST API、WebSocket家属端看不到，事件不丢
家属端Vue 3 + Vite实时报警、历史记录、设备与传感器状态只能靠本地声光

核心设计原则：本地报警不依赖网络

跌倒这件事没有「重试」的机会。所以报警动作必须落在离传感器最近、依赖最少的那一层——也就是 STM32。网络只能用来通知远方的人，不能用来决定要不要响。

这条原则直接决定了架构：STM32 有自己的蜂鸣器与红灯驱动，不经过 ESP32、不经过 MQTT、不经过云端。ESP32 断网、服务器宕机、路由器重启，本地依然会响。反过来说，ESP32 与云端只承担「把已经响过的事件送出去」的职责，它们的故障只会推迟家属知情，不会取消报警。

为什么用双 MCU，而不是一颗

STM32F103C8T6 —— 判定与动作

  • 裸机 + 状态机，响应确定性最好
  • PIR 数字量、MQ 系列 ADC 采样与滤波
  • 雷达候选的本地二次确认（5 秒窗）
  • 久滞三级计时（L1/L2/L3）
  • 蜂鸣器、红灯、取消按键、语音模块
  • 不做雷达内部算法的重写

ESP32-S3 —— 解析与联网

  • TinyFrame 协议帧解析（115200 8N1）
  • 跌倒状态帧 0x0E02、人员存在帧 0x0F09、点云帧 0x0A08
  • 安装高度、阈值、灵敏度等配置下发
  • Wi-Fi 接入、MQTT 发布订阅、心跳
  • 断网缓存与恢复补传
  • 不做报警动作判定

拆成两颗的三条理由

  1. 实时性与网络栈解耦：Wi-Fi 与 TCP/IP 栈会带来不可预期的延迟尖峰。如果把报警动作和网络栈放在同一颗芯片上，网络抖动就可能影响报警时序；拆开后，STM32 的时序完全不受网络影响。
  2. 协议栈负担不同：雷达厂商给的 TinyFrame 解析、点云帧处理对 RAM 与算力有要求，ESP32-S3 更合适；而 STM32 只需要处理已经化简过的状态帧。
  3. 故障域隔离：ESP32 死机或反复重连时，STM32 侧的判定与报警依然独立运行，只是不再上报。
链路协议说明
雷达 ↔ ESP32-S3厂商 TinyFrame起始帧、帧 ID、长度、类型、头校验和、数据、数据校验和；串口 115200 / 8 位 / 1 位停止 / 无校验
STM32 ↔ ESP32-S3本项目自定义二进制帧 + CRC16状态帧、事件帧、配置帧；CRC16 保证帧完整性
ESP32-S3 ↔ 云端MQTT + JSON7 条主题，全部 QoS 1，仅 state 主题 Retain，Clean Session 全程 true

数据链路与三段时间

数据链路：雷达经 UART 送 STM32，经内部帧送 ESP32，经 MQTT 到后端，再经 WebSocket 到家属手机；STM32 另有本地声光报警支路，不经过网络。下方标尺标出三段时间，分别计量、不相加。
图中的标尺把三段时间与链路节点对齐，是为了说明各自从哪到哪，不是为了相加成一个「总延迟」。详见 判定逻辑与报警时效。

MQTT 主题设计

主题方向用途QoS
elder/{device_id}/event/fall设备 → 后端跌倒事件（含 suspected / local_alarm / confirmed / cancelled）1
elder/{device_id}/event/stay设备 → 后端久滞事件（L1/L2/L3）1
elder/{device_id}/event/help设备 → 后端语音呼救1
elder/{device_id}/event/activity设备 → 后端活动量摘要1
elder/{device_id}/event/environment设备 → 后端可燃气体 / 烟雾超限预警（实验性）1
elder/{device_id}/state设备 → 后端设备在线状态与传感器读数1（Retain）
elder/{device_id}/ack后端 → 设备事件确认回执1
首轮 device_id 固定为 bath01。前端不持有 Broker 凭据，家属端一律经 REST API 与 WebSocket 取数。

事件字段

字段含义
device_id设备编号，首轮为 bath01
event_id设备侧生成的唯一编号，后端据此幂等去重
source事件来源：雷达 / PIR / 语音 / 手动
sensor_type传感器类型
timestamp事件发生时间（设备时间，统一到同一时钟域）
severity严重程度（L1/L2/L3）
stay_seconds久滞时长（仅久滞事件）
offline_replayed该事件是否为断网补传（补传标记，便于核对时间戳）
可靠性不是靠一条机制，而是五件事协同：event_id 唯一 → QoS 1 → 设备本地缓存 → 恢复补传 → 后端幂等去重。少了任何一条，「不丢不重」都拿不到。