1.3 实时系统分类与应用版图

1.3 实时系统分类与应用版图

本节摘要：本节把 1.1 节的分类标准落到行业场景中：一张按实时等级与行业分布的应用版图，加上一个输液泵案例的完整拆解，演示「从需求条款倒推系统设计」的完整思路——这是后续所有章节机制学习的应用背景。

一家做医疗器械的小厂接到输液泵的改型需求时，项目经理在评审会上说的第一句话是「这不就是加个屏幕么」。真正让项目难度上台阶的，是需求文档深处的一条：无论用户怎么操作界面，药液输送速率的偏差不得超过设定值的正负百分之五。界面是体验问题，这条是安全问题——它把整个项目拖进了硬实时的世界。本节作为第一章收尾，就是把这种「从条款到架构」的推演方法讲清楚，并用一张版图让你对 RTOS 的用武之地有全局感。

版图：按行业看实时需求

不同行业对实时的要求呈现出清晰的梯度。消费电子几乎全是软实时：手表界面晚刷新一帧无人在意。工业自动化的传感与执行链路是固实时到硬实时：PLC 扫描周期错一次，产线或许还能救回来；运动控制插补周期错一次，工件直接报废。汽车与医疗、航空是硬实时最密集的区域，因为后果直接挂钩人身安全。

图：应用版图——实时等级与典型行业分布

版图的用法是「入口粗筛」：先按行业找到自己的位置，再回到 1.1 节用后果判定法确认。行业习惯只能参考，不能替你做决定——同一个 CAN 网关，装在信息娱乐系统里是软实时，装在底盘网络里就是硬实时。

完整案例：输液泵的输送任务

把开头那家厂商的需求当例子，完整走一遍「背景、操作、结果、解读、变式」，让分类方法落到地上。

背景。输液泵通过步进电机挤压泵管送药，需求条款要求速率偏差不超过正负百分之五。换算下来：以最大速率每小时一百毫升计算，电机每转一圈对应零点零五毫升，控制任务必须在每个步进节拍（约 18 毫秒）内发出脉冲，且节拍间隔的漂移要控制在两毫秒以内，否则瞬时流速会超出偏差带。同时设备还有一个并发需求：彩色触摸屏界面、报警声管理、与护士站的无线上报。

操作。团队最终的软件结构是分层的：底层用 RTOS 提供固定优先级抢占调度；输送任务设为最高优先级，用 3.1 节会讲到的绝对延时 API 锚定 18 毫秒节拍；界面任务、通信任务依次降低优先级；显示缓冲与无线报文的共享数据用互斥量保护并开启优先级继承（第四章）。控制系统上电后先做自检，输送任务启动前由看门狗和任务统计接口确认节拍稳定，才开始允许给药。

结果。实验室测试中，空载与满载（界面连续刷屏、无线持续重发）两种工况下，脉冲间隔的最大漂移分别为零点三毫秒与一点一毫秒，速率偏差稳定在百分之一以内。压力测试中人为给界面任务制造死循环，输送节拍依然保持，界面失去响应触发看门狗级别的任务监控告警——这正是设计想要的行为：低优先级烂掉，高优先级照常。

解读。这个案例展示了三层方法。第一，需求条款被翻译成了可度量的时间指标（节拍 18 毫秒、漂移小于 2 毫秒），没有这一步翻译，后面的设计无从谈起。第二，硬实时任务的「硬」是通过优先级体系与最坏情况预算兑现的，而不是靠把代码写得紧凑。第三，资源争抢点（显示缓冲）被识别出来并用同步机制加以约束——这些机制分别是第三、四章的主题。

变式。如果同一套硬件要出口到要求双通道给药的场景，节拍时间减半到 9 毫秒，团队需要的不再是「把任务写快点」，而是重新审视 WCET 预算与抢占干扰，甚至把双通道分到双核上各跑一核——这就自然接到了第七章的多核话题。如果产品增加胰岛素给药的闭环算法，安全等级上升，还要按第七章的功能安全流程补全文档与验证链。

三个容易走偏的判断

一是把「贵」当成硬实时的信号。花钱多的项目（比如航天）确实普遍硬实时，但反过来不成立：几十块钱的电动窗帘控制器里也可能藏着夹手保护的硬实时判定。判断永远看后果，不看标价。

二是把「快」当成硬实时的替代品。用主频堆出一微秒的平均响应，敌不过一次毫秒级的偶发抢占——1.1 节的抖动概念在这里再次生效。

三是把全系统都按最紧急任务对待。把所有任务都设成最高优先级，等于没有优先级，调度器退化为先进先出，实时性反而全面失守。分级是实时设计的起点，第九章的复盘案例里会看到这条被违反后的现场。

本节要点回顾

• 行业版图用于入口粗筛，最终归类必须回到「超时后果」判定法；
• 需求条款要翻译成可度量的时间指标（节拍、漂移、偏差带），这是设计起点；
• 输液泵案例展示了分层优先级 + 绝对延时节拍 + 同步保护的标准组合；
• 硬实时不等于贵、不等于快，分级失败的系统等于没有实时设计；
• 案例的三条变式分别通向多核（第七章）、功能安全（第七章）与预算重审（第三章）。

常见问题

问：一个系统里能同时存在三种实时等级吗？ 不仅可行，而且是常态。一台设备里，控制环是硬实时、数据记录是固实时、界面与远程上报是软实时，三者靠优先级与缓冲分层共存。把全系统按最严等级对待反而是浪费——以最高等级验证一切，成本呈指数上涨，第七章会展开这笔账。

问：判定为软实时之后，还需要 RTOS 吗？ 不一定。软实时的判定只说明「不必为最坏情况做设计」，并发复杂度才是上不上 RTOS 的判据：任务多、共享资源多、时间关系复杂时，RTOS 的任务模型本身就是开发效率工具，与硬不硬无关。

问：行业版图里没有我的应用怎么办？ 版图只列了密度高的区域。回到判定法本身：任何新应用，按「超时后果」四问走一遍，结论比版图可靠。版图会过时，判定法不会。

从分类到规格书

分类的终点是一份实时需求规格：每项功能一行，写明等级、指标数值、验证方法三栏。规格书的价值在团队对齐——「这个功能是硬实时」与「这个功能按最坏五毫秒验证」是两种完全不同的承诺，前者是形容词，后者能写进合同与测试报告。1.1 节的判定清单、本节的版图、加上这份规格书，构成了后续所有设计工作的需求侧地基。第一章到此完成了它的使命：让你在写下第一行任务代码之前，先知道自己对时间的承诺是什么。

问：规格书里的验证方法一栏怎么填？ 三选一：实测（压力边界用例加探针读数）、分析（响应时间迭代或排队估算）、检验（评审对照物理过程推算）。硬实时指标优先用实测加分析双保险，软实时指标用实测即可——验证方法与指标硬度匹配，成本才花在刀刃上。