第3章：协议栈架构设计——OSI模型与医疗协议栈映射

好，咱们进入协议栈架构设计这一章。说实话，这是整个课程里最「骨架」的部分。你想想看，一个医疗贴片要跟手机、网关、云端通信，没有一套清晰的协议栈，那代码写出来就是一锅粥。我个人习惯，在动手写一行代码之前，先把架构图画清楚。

3.1 OSI七层模型，我们到底用几层？

OSI模型大家上学都背过：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。但在医疗贴片这种资源受限的嵌入式系统里，你不可能把七层全跑一遍。我见过一些团队，硬要把完整的TCP/IP协议栈塞进Cortex-M0芯片里，结果RAM爆了，功耗也压不下去。

那怎么办？我的做法是——裁剪。说白了，我们只取最核心的四层：

OSI层	医疗贴片协议栈映射	我的备注
物理层	BLE射频 / NFC / 私有2.4G	选型时注意医疗频段合规
数据链路层	BLE Link Layer / 私有MAC	重传机制必须做，医疗数据丢包会出大事
网络层	通常跳过（BLE直接点对点）	如果走Wi-Fi或蜂窝，需要IP层
传输层	ATT/GATT（BLE）或自定义可靠传输	这里最容易踩坑，后面细说
会话层+表示层	合并到应用层处理	医疗设备通常不需要复杂会话管理
应用层	医疗数据模型 + 命令集	这是咱们自己定义的核心

你看，实际上我们只用了四层半。为什么是半层？因为会话层和表示层的功能，我习惯直接揉进应用层里。这样做的好处是——减少协议开销，降低代码复杂度。

3.2 分层设计原则——我的三条铁律

做协议栈分层设计，我给自己定了三条铁律。这些年做过的医疗项目，凡是出问题的，回头看基本都是违反了其中一条。

铁律一：层间接口要「薄」

什么叫薄？就是层与层之间传递的数据结构尽量简单。我见过有人把整个数据包从物理层一路传到应用层，每层都加个头部，最后包体膨胀了3倍。在医疗贴片上，每一字节都珍贵。我建议：层间接口只传必要信息，比如数据指针+长度+状态码，就够了。

铁律二：错误处理不下放

这个坑我踩过。曾经有个项目，物理层丢包了，我让物理层自己重传。结果物理层重传了三次还是丢，它也不知道该不该告诉上层。最后数据丢了，病人监护仪上显示的心率曲线断了三秒。嗯，这事后来被写进了公司的设计规范。

正确的做法是：每层只处理自己能力范围内的错误，处理不了的，必须上报。比如物理层只管信号检测和比特错误，丢包重传交给数据链路层，数据完整性校验交给应用层。

铁律三：配置参数要「可调」

医疗贴片的应用场景千差万别。ICU里用的贴片，要求低延迟；家庭康复用的贴片，要求低功耗。你不能写死。我习惯在每层都留一个配置结构体，比如：

// 数据链路层配置示例
typedef struct {
    uint8_t  retry_count;      // 重传次数，ICU场景设5次，家用设2次
    uint16_t timeout_ms;       // 超时时间
    bool     enable_crc;       // 是否启用CRC校验
    uint8_t  priority;         // 数据优先级，0-3
} dl_config_t;

这样，同一个协议栈，换一套配置就能适配不同场景。我管这叫「一套代码，多场景适配」。

3.3 医疗协议栈参考架构——我常用的模板

好了，理论讲完，咱们看一个实际可用的参考架构。这是我最近一个心电贴片项目里用的，经过FDA审核，没问题。

整体分四层，从上到下：

1. 医疗应用层：负责数据打包、命令解析、事件上报。比如心电数据每包包含：时间戳+导联号+采样值+质量标志。
2. 传输适配层：这是我自己加的一层。为什么加？因为底层通信方式可能会变。今天用BLE，明天可能用NFC，后天可能用Wi-Fi。加这一层，上层代码不用改。
3. 链路管理层：负责连接管理、重传、流控。医疗数据要求可靠，所以这里我实现了「确认重传+超时重传」双机制。
4. 物理接口层：直接操作射频芯片的寄存器。这一层尽量薄，只做收发和信号质量检测。

来看一个实际的数据流示例。假设贴片采集到一组心电数据：

// 医疗应用层打包
med_packet_t pkt;
pkt.type = MED_DATA_ECG;
pkt.timestamp = get_sys_tick();
pkt.payload = ecg_samples;  // 256个采样点
pkt.len = 512;              // 2字节一个采样点

// 传输适配层封装
tx_adapter_send(&pkt, TX_CHANNEL_BLE);

// 链路管理层添加序列号和CRC
dl_send(pkt_buf, pkt_len, DL_FLAG_ACK_REQUIRED);

// 物理接口层发送
phy_tx(pkt_buf, pkt_len, PHY_CHANNEL_37);

你看，每一层各司其职。应用层不知道数据走的是BLE还是NFC，物理层也不知道数据是心电还是体温。这就是分层的好处——改一层，不影响其他层。

3.4 避坑指南——我踩过的三个坑

最后，分享几个真实踩过的坑，希望能帮你省点时间。

• 坑一：层间耦合太紧。 我曾经把链路层的重传计数器和应用层的超时定时器写在一起。结果改应用层超时时间，链路层重传逻辑也乱了。后来强制规定：层间只能通过接口函数通信，不能直接访问对方变量。
• 坑二：忽视配置参数的默认值。 有个版本我忘了初始化配置结构体，结果重传次数默认是0，等于不重传。测试时没发现，直到临床试用时数据丢了。从那以后，我每个配置结构体都写一个 dl_config_default() 函数。
• 坑三：协议栈测试只测正常流程。 医疗设备最怕异常。我建议测试时重点测：物理层断连、数据包乱序、重复包、超长包。这些场景在OSI模型里都有对应层级的处理逻辑，一定要逐层验证。

嗯，这一章的内容就这些。协议栈架构设计，说白了就是「分而治之」——把复杂问题拆成小块，每块做好自己的事。下一章咱们会深入每一层的具体实现，包括代码怎么写、测试怎么跑。