1. 实时性概述：麻醉机为什么需要实时性？

大家好，我是老张。做麻醉机嵌入式开发十几年了，今天咱们聊聊实时性。

很多人刚入行时会问：麻醉机不就是个打气送药的机器吗？要那么快干嘛？

嗯，这个问题问得好。我当年也这么想过，直到有一次在实验室里亲眼看到——因为一个任务调度延迟了50毫秒，呼吸阀没能在呼气相结束时及时关闭，结果病人气道压力瞬间飙到了40 cmH₂O。虽然只是模拟测试，但那个报警声我现在还记得。

所以，麻醉机为什么需要实时性？说白了，因为人命关天。

1.1 麻醉机为什么需要实时性？

麻醉机不是普通的嵌入式设备。它直接连着病人的呼吸回路，控制着病人的每一次呼吸。

你想想看，一个成年人在静息状态下，每分钟呼吸12到20次。每次吸气、屏气、呼气，机器都要精确配合。如果控制指令晚了几十毫秒，会发生什么？

• 吸气相延迟：病人想吸气，机器没及时打开吸气阀。病人会感到憋气，严重时导致人机对抗。
• 呼气相延迟：病人想呼气，呼气阀没及时打开。气道压力升高，可能造成气压伤。
• 麻醉药浓度控制延迟：挥发罐的反馈调节跟不上，病人可能过深或过浅。
• 报警响应延迟：气道压力过高、氧浓度过低等危险情况，报警必须在几百毫秒内触发。

我记得有一次做产品认证，检测机构要求我们证明：从传感器采集到执行器动作，整个闭环的延迟不超过10毫秒。当时我们花了整整两周，用逻辑分析仪一条一条地抓时序，才把问题定位到中断优先级配置上。

1.2 实时系统的定义

什么是实时系统？教科书上的定义很绕口。我用自己的话来说：

实时系统，就是必须在规定时间内完成规定任务的系统。

注意，这里有两个关键词：「规定时间」和「规定任务」。时间过了，任务就算做完了，也没用了。

举个例子。麻醉机里的压力传感器每5毫秒采集一次气道压力。如果采集任务因为某种原因延迟了10毫秒才执行，那这10毫秒内的压力数据就丢了。更可怕的是，如果连续丢几次，控制算法就会基于错误的数据做决策——这才是真正的灾难。

实时系统有三个基本特征：

• 时间确定性：任务的执行时间是可预测的，不是「越快越好」，而是「必须在这个时间内完成」。
• 可靠性：系统不能因为偶尔的负载波动就错过截止时间。
• 可验证性：你能通过测试或分析，证明系统在最坏情况下也能满足时间要求。

1.3 硬实时 vs 软实时

实时系统又分两种：硬实时和软实时。这个分类很重要，因为它直接决定了你的设计策略。

特性	硬实时	软实时
错过截止时间的后果	系统失效，甚至危及生命	性能下降，但系统仍可运行
典型应用	麻醉机、呼吸机、心脏起搏器	视频播放、网络通信、人机界面
时间要求	必须100%满足	允许偶尔超时
设计策略	预留余量，最坏情况分析	统计平均性能优化

麻醉机属于典型的硬实时系统。为什么？因为错过一次呼吸周期的控制，病人就可能出问题。

我举个例子你就明白了。麻醉机的呼吸频率设定为12次/分钟，意味着每个呼吸周期是5秒。在这5秒内，吸气相、屏气相、呼气相的时间分配是固定的。如果吸气相的控制任务因为某个中断而延迟了200毫秒，那整个呼吸周期就乱了。病人可能刚吸到一半，机器就切换到呼气相了。

这可不是视频播放卡顿一下那么简单。这是硬实时，错过就是事故。

1.4 麻醉机中的实时性需求分布

麻醉机里不是所有任务都需要硬实时。我习惯把任务分成三类：

1. 硬实时任务（毫秒级）：
   • 呼吸相控制（吸气阀、呼气阀的开关）
   • 气道压力、流量传感器采集
   • 麻醉药浓度闭环控制
   • 安全报警检测（压力上限、氧浓度下限等）
2. 软实时任务（十毫秒到百毫秒级）：
   • 人机界面刷新（屏幕显示波形、参数）
   • 数据记录与日志存储
   • 通信协议处理（如CAN、以太网）
3. 非实时任务（秒级或更慢）：
   • 自检与校准
   • 固件升级
   • 历史数据回放

你看，麻醉机的实时性需求是分层的。你不能把所有任务都当成硬实时来处理，那样CPU会不堪重负。但你也绝对不能把硬实时任务当成软实时来设计。

我个人习惯的做法是：先列出所有任务，给每个任务打上「硬实时」「软实时」「非实时」的标签。然后根据这个标签，决定任务的优先级、调度策略和资源分配。

好了，这一章就聊到这里。下一章我们深入讲讲麻醉机的实时任务模型，看看这些任务到底是怎么调度和运行的。