📚 课程目录第1章医疗可穿戴设备与BLE互联概述

1. 医疗可穿戴设备与BLE互联概述

医疗可穿戴设备正在把过去只能在医院完成的连续监测，搬到人的皮肤上、衣服里和日常生活中。心率带贴在胸口记录每一次心搏，动态心电贴连续工作数天捕捉偶发心律失常，血氧腕表在夜间睡眠中监测血氧饱和度，血糖仪则通过皮下传感器把组织液中的葡萄糖浓度换算成血糖值。这些设备的共同点是：传感器贴身、数据连续、使用场景远离诊室。而它们几乎都选择蓝牙低功耗（Bluetooth Low Energy，BLE）作为与手机、网关或云端通信的无线手段。理解BLE在医疗可穿戴中的角色，是后续所有互联工程工作的起点。

BLE为什么成为医疗可穿戴的首选

医疗可穿戴对无线通信的要求可以归纳为四条：功耗足够低、体积足够小、连接足够稳、数据足够可信。BLE在这四条上都有针对性设计。它把通信拆成“广播—扫描—连接”三个阶段，设备大部分时间处于睡眠，只在极短的广播事件或连接事件中收发数据。以典型心率带为例，采用1秒连接间隔、每次连接事件交换几十字节，平均电流可以做到几百微安量级，一枚纽扣电池就能支撑数月到一年。相比之下，经典蓝牙或Wi-Fi的持续连接功耗高出一个数量级以上，难以满足贴片式设备对电池体积的限制。

BLE的另一个优势是标准化程度高。蓝牙技术联盟定义了大量面向医疗健康的GATT服务，例如心率服务（Heart Rate Service，HRS，UUID 0x180D）、血氧服务（Pulse Oximeter Service，PLX，UUID 0x1822）、健康温度计服务（Health Thermometer Service，HTS，UUID 0x1809）以及连续血糖监测服务（Continuous Glucose Monitoring Service，CGMS，UUID 0x181F）。设备只要按规范暴露特征值，手机端或网关端就能用通用方式读取和订阅，不必为每个厂商写一套私有协议。这为多设备、多品牌的互联工程提供了基础。

典型设备形态与数据特征

不同形态的医疗可穿戴，其BLE使用方式差异很大，工程上必须区别对待。

心率带：通常采用纽扣电池，广播中包含心率值，连接后通过HRS的Heart Rate Measurement特征值以Notify方式推送。数据率低（约1Hz），但对丢包敏感，因为漏掉一次心搏可能影响心率变异性分析。
动态心电贴：采样率可达250Hz甚至更高，原始心电数据量大，通常先在设备端做压缩或特征提取，再通过BLE分批传输。对连接稳定性和吞吐量要求最高，断连重连后需要补传缓存数据。
血氧腕表：周期性测量SpO₂和脉率，数据以秒级或分钟级上报。设备往往同时承担显示、计步等功能，BLE连接需要与本地任务共享资源。
血糖仪：连续血糖监测设备每1～5分钟产生一个血糖值，通过CGMS服务上报，并带有趋势、校准和质量标志。医疗合规要求数据带时间戳且不可篡改，对时间同步和记录完整性要求高。

这些差异意味着，互联工程不能只写一套“连接—读数据”的代码，而要针对设备的数据率、实时性、可靠性和合规要求分别设计。

互联工程的核心挑战

把BLE医疗设备接入系统，真正的难点往往不在“连上”，而在“连得稳、传得准、断得可恢复”。常见挑战包括：

连接参数与功耗的权衡：连接间隔越短，延迟越低但功耗越高；从设备延迟（Slave Latency）可以跳过若干连接事件省电，但会增大响应时间。心率带可以容忍1秒间隔，而心电贴可能需要更短间隔来保证吞吐。
多设备共存与干扰：2.4GHz频段拥挤，Wi-Fi、其他BLE设备都会造成干扰。自适应跳频和合理的连接间隔能缓解，但需要在现场验证。
断连与数据补传：人体活动、遮挡、距离变化都会导致断连。设备端需要缓存未发送数据，重连后按时间戳补传，否则连续监测会出现空洞。
时间同步与数据对齐：多设备同时采集时，各设备时钟独立，必须通过时间戳或同步机制对齐，才能做多模态分析。
安全与隐私：医疗数据属于敏感信息，BLE连接需要配对、加密，防止窃听和中间人攻击，同时满足相关法规对数据存储和传输的要求。

工程实践中，建议先明确设备的“数据率—延迟—可靠性”三角需求，再反推BLE连接参数和缓存策略，而不是先写连接代码再调参数。

课程项目总览

本课程围绕一个贯穿始终的项目展开：构建一套“多设备医疗可穿戴数据采集与上传系统”。系统包含三类角色：BLE从设备（心率带、血氧腕表、血糖仪等）、BLE中心节点（手机或嵌入式网关）、以及云端数据服务。中心节点负责扫描、连接、订阅、解析、缓存和上传；云端负责存储、展示和告警。课程将依次覆盖BLE协议栈、GATT服务解析、连接参数优化、断连重连与补传、时间同步、安全配对、功耗测试、异常排查等主题，最终形成可运行、可测试、可复现的工程实现。

上图把课程项目的三层结构、典型设备及其对应GATT服务、中心节点的关键处理环节，以及云端职责放在同一张视图中。可以看到，从设备到中心节点主要走BLE的Notify通道，中心节点到云端走IP网络；而“断连补传”“时间同步”“安全配对”这些挑战，恰好落在中心节点的处理链上，也是后续章节逐一展开的重点。

需要特别说明的是，图中标注的数据率（如心率约1Hz、血糖1～5分钟一次）是典型量级的示例，用于说明不同设备对连接参数和缓存策略的需求差异，并非某一具体型号的实测指标。实际工程中应以设备规格书和现场测试为准。课程后续会给出具体的连接参数配置示例、缓存队列设计、时间戳对齐方法和测试用例，帮助读者把这张架构图逐步落地为可运行的系统。