1.1 什么是实时：截止期、确定性与抖动

1.1 什么是实时：截止期、确定性与抖动

本节摘要：实时性描述的不是速度而是承诺——任务必须在截止期之前完成，且每一次都完成。本节给出截止期、确定性、抖动三个核心定义，并提供一套把需求归类的判定方法，为全书后续机制讨论立好标尺。

「抖动」是工控现场的老工程师最恨的一个词：他们不在乎系统平均能跑多快，在乎的是「上一次 3 毫秒、这一次 30 毫秒」这种说不清的波动。这个口语化的抱怨，恰好指向了实时性定义的核心。本节是全书第一节，任务是把你头脑里「实时等于快」的直觉替换成可度量的工程概念——后面所有章节的机制，都是在为这几个概念服务。

先把三个词分开

截止期（deadline）：任务从被触发到必须完成的时间上限。电机控制环里每次 PWM 周期开始前必须算好下一拍的占空比，这个「下一拍开始前」就是截止期。截止期可以是绝对的（每天零点前出报表），更常见的是相对的（被中断唤醒后 2 毫秒内输出结果）。

确定性（determinism）：给定相同的输入与起始状态，系统的时间行为是否可预测。注意确定性与速度无关：一颗跑 48MHz 的单片机，若每次中断响应都稳定在固定周期数上，它比一颗「平均很快但偶尔卡顿」的 1GHz 处理器更实时。通用操作系统做不到确定性，根源不在代码质量，而在设计目标——缓存、预取、动态调频、后台守护任务，每一个提升平均性能的手段都在给最坏情况埋雷。

抖动（jitter）：同一事件多次发生时，响应时间的波动幅度。设响应时间的观测序列为 r 的若干次取值，抖动常用最大值减最小值或标准差刻画。对一个周期 10 毫秒的采样任务，启动时刻若在 9.99 到 10.03 毫秒之间漂移，抖动就是 40 微秒——这个数字直接进入你的控制环路带宽预算。

三个词合起来才是完整的实时定义：在所有可能的情况下，包括最坏情况，任务都能在截止期前完成。最坏情况执行时间（WCET）因此成了实时系统的基石指标，它是本册反复出现的行话。

硬实时与软实时的分界

判定标准只有一条：错过截止期会发生什么。

• 硬实时（hard real-time）：错过即失败，且失败不可挽回。安全气囊点爆指令晚到几十毫秒，碰撞已经结束；线控制动指令超时，制动距离已经超出。这类系统的特点是失效后果不可逆，因此设计目标是最坏情况可证，宁可牺牲平均性能与吞吐量。
• 固实时（firm real-time）：偶尔错过可以容忍，但结果作废。视频编码里丢一帧，画面闪一下但流不中断；统计采样里丢一个点，曲线仍然可用。这类系统通常要求错失率低于某个比例，比如每千次不超过一次。
• 软实时（soft real-time）：晚到的结果仍然有价值，只是价值递减。网页响应、界面刷新属于此类，通用操作系统配合合理的工程手段就能覆盖。

下面这张图直观展示了两种系统的差别：软实时系统追求分布的中心位置靠左（平均快），硬实时系统追求分布的右边缘可控（最坏情况有界）。

图：硬实时与软实时的响应时间分布对比

一个常见的误判是把「偶尔超时」当成软实时问题。判断依据不是超时频率，而是超时后果：哪怕一年才发生一次，只要那一次会撞坏设备或伤人，它就是硬实时需求，就必须按最坏情况做设计与验证。

用一个采集任务算一遍

拿一个具体数字把它走通。某振动监测设备要求以固定周期采样：采样周期 T 等于 10 毫秒，即每 10 毫秒要完成一次「读传感器、滤波、更新显示缓冲」的完整动作，产品定义的截止期 D 为 8 毫秒（留出余量给更紧急的告警任务）。

在 RTOS 下这个周期任务通常这样写：

/* 周期性采样任务：用绝对延时锚定节拍，避免误差累积 */
void SamplingTask(void *arg)
{
    TickType_t xLastWakeTime = xTaskGetTickCount();
    const TickType_t xPeriod = pdMS_TO_TICKS(10);   /* 10 毫秒周期 */

    for (;;) {
        uint16_t raw  = ADC_Read(CH_VIBRATION);      /* 读传感器 */
        int32_t  filt = IIR_Filter(raw);             /* 滤波，纯计算 */
        Display_Push(filt);                          /* 写共享缓冲，需互斥 */

        vTaskDelayUntil(&xLastWakeTime, xPeriod);    /* 睡到下一拍 */
    }
}
​

vTaskDelayUntil 与 vTaskDelay 的区别值得停一下：前者按「上一次该醒的时刻」推算下一次唤醒，节拍不会漂移；后者按「现在」往后推，每一拍都会把前面浪费的时间累加进周期，采集时间线越跑越歪。很多「莫名其妙的采样抖动」，根源就是把 Until 写成了普通 Delay。

测得的执行时间数据：滤波在数据平稳时 0.6 毫秒，冲击到来时达到 1.8 毫秒；写显示缓冲因要与 GUI 任务争抢互斥量，最坏多等 2.5 毫秒。于是 WCET 约 4.3 毫秒，小于 8 毫秒截止期，单个任务看是可行的。但这只是可行性分析的第一步——它还没算上被更高优先级任务抢占的时间。完整的响应时间分析在 3.2 节展开，这里先记住方法骨架：执行时间取最坏，加上一切可能的抢占与阻塞，再去和截止期比。

工程上的判定清单

拿到新需求时，按下面的顺序提问，基本能完成归类：

1. 这个动作有没有明确的时间上限？没有上限的需求直接归入非实时。
2. 上限是多少、由谁定义？由物理过程定义的（控制环、通信帧时隙）比由产品文档定义的更硬。
3. 超过上限的后果是什么？不可逆损害为硬实时，结果作废为固实时，体验下降为软实时。
4. 后果能否用重试掩盖？能重试的都不是硬实时。

把这份清单的结论写进设计文档，后面选操作系统、定优先级、做测试预算时，它就是依据。需求阶段的含糊，会在联调阶段加倍偿还。

本节要点回顾

• 实时性的定义是「最坏情况下仍满足截止期」，与平均速度无关；
• 截止期、确定性、抖动三个概念各有度量方式，混用会掩盖真正的设计矛盾；
• 硬实时的判定依据是超时后果的不可逆性，不是超时频率；
• 周期任务用绝对延时锚定节拍，普通相对延时会让误差逐拍累积；
• 单任务的 WCET 只是可行性分析的起点，完整分析还要计入抢占与阻塞，方法在第三章展开。