📚 课程目录第2章实时系统基础

2. 实时系统基础

在通用计算中，我们通常用“平均响应时间”和“每秒处理量”来评价系统性能；但在实时系统中，评价标准完全不同——正确性不仅取决于计算结果，还取决于结果产生的时间。一个在截止时间之后才输出的正确结果，在实时语义下往往等同于错误。因此，理解硬实时与软实时、确定性、抖动、延迟、吞吐量和截止时间这些基本概念，是设计 RTOS 任务架构的第一块基石。

一、硬实时与软实时：错过截止时间的代价不同

实时系统按“错过截止时间的后果”分为两类。硬实时（Hard Real-Time）要求任务必须在截止时间前完成，一旦超时，后果可能是灾难性的，例如安全气囊点火、电机换相控制、飞行姿态调整。软实时（Soft Real-Time）允许偶尔超时，超时只导致服务质量下降，例如视频播放卡顿、界面刷新延迟、日志上报滞后。

两者在架构上的关键差异在于：硬实时系统必须进行最坏情况执行时间（WCET）分析，并预留足够的资源余量；软实时系统则更关注统计意义上的响应表现，允许通过优先级调度、缓存和队列来平滑偶发延迟。下表给出典型对比：

维度	硬实时	软实时
截止时间约束	必须满足，不可协商	尽量满足，可偶尔超时
超时后果	安全事故、设备损坏、人员伤亡	体验下降、数据延迟、画面卡顿
分析方法	WCET + 响应时间分析	统计分布 + 平均/分位延迟
资源策略	保守预留，禁止不可控阻塞	动态调度，允许排队与丢弃
典型场景	刹车控制、飞控、医疗输液泵	音视频播放、HMI、数据采集展示

二、确定性、抖动与延迟：时间行为的三个关键词

确定性（Determinism）指系统在相同输入和相同状态下，响应时间具有可预测的上界。确定性不等于“快”，而是“最坏情况可界定”。一个平均响应 1ms 但偶尔跳到 50ms 的系统，对硬实时而言是不可接受的；而一个稳定在 5ms 内完成的系统，反而更容易通过验证。

延迟（Latency）通常指从事件发生到系统开始响应或完成响应的时间。在 RTOS 中，延迟可细分为中断延迟、调度延迟和任务执行时间。中断延迟是从硬件中断触发到 ISR 第一条指令执行的时间；调度延迟是从 ISR 唤醒任务到该任务真正获得 CPU 的时间。

抖动（Jitter）是响应时间的波动范围，即最坏响应时间与最好响应时间之差。抖动越小，系统越确定。对于周期性控制任务，抖动会直接影响控制环路的采样间隔稳定性，进而影响控制质量。

  核心关系：响应时间 = 中断延迟 + 调度延迟 + 执行时间 + 阻塞时间。硬实时设计的目标不是让每一项都最小，而是让总和的最坏值小于截止时间。

三、吞吐量与截止时间：两种不同的优化目标

吞吐量（Throughput）指单位时间内完成的任务数量或处理的数据量。它衡量的是“效率”，而截止时间衡量的是“及时性”。两者经常冲突：提高吞吐量可能引入批处理、缓存和长临界区，从而增大最坏延迟和抖动。

截止时间（Deadline）是任务必须完成的时间点。按约束形式可分为：相对截止时间（从释放时刻算起）、绝对截止时间（具体时刻）和周期任务的隐式截止时间（等于周期）。在实时调度中，常用“截止时间满足率”和“最坏响应时间”来评价系统是否可调度。

下面这张图展示了从事件触发到任务完成的完整时间链，以及抖动和截止时间在其中的位置：

四、案例：电机控制中的硬实时与日志上报中的软实时

假设一个基于 RTOS 的电机控制节点，控制周期为 1ms，电流环任务必须在每个周期内完成采样、计算和 PWM 更新。若该任务因低优先级日志任务长时间占用 CPU 而延迟 300μs，控制环路相位裕度下降，电机可能产生明显抖动甚至失稳。这里，电流环任务是硬实时任务，其截止时间等于周期 1ms，最坏响应时间必须严格小于 1ms。

同一系统中，日志上报任务只需在 100ms 内把运行数据写入缓冲区并发送，偶尔延迟到 150ms 只影响后台监控的实时性，不会影响电机运行。因此它是软实时任务，可以用较低优先级、允许被抢占，甚至允许在缓冲区满时丢弃旧数据。

/* 伪代码：硬实时电流环任务与软实时日志任务的优先级配置 */
#define PRIO_CURRENT_LOOP   10   /* 最高优先级，硬实时 */
#define PRIO_SPEED_LOOP     8    /* 中优先级，硬实时 */
#define PRIO_LOG_UPLOAD     2    /* 低优先级，软实时 */

void current_loop_task(void) {
    while (1) {
        wait_period(1000);        /* 1ms 周期，截止时间 = 1ms */
        sample_current();
        pid_calculate();
        update_pwm();
    }
}

void log_upload_task(void) {
    while (1) {
        if (log_buffer_ready()) {
            send_log_nonblocking();  /* 允许超时或丢弃 */
        }
        delay_ms(50);
    }
}

五、常见误区与复盘要点

误区一：平均响应快就是实时性好。硬实时看最坏情况，平均值再小也无法保证安全。
误区二：提高主频就能解决所有实时问题。主频提升可能缩短执行时间，但中断延迟、调度延迟和阻塞时间未必同步下降。
误区三：忽略抖动。控制类任务对抖动敏感，抖动过大等价于采样周期不稳定。
误区四：把吞吐量当作实时指标。吞吐量高不代表截止时间能满足，二者需要分别度量。
复盘要点：先识别任务属于硬实时还是软实时，再确定截止时间、周期和最坏执行时间，最后用响应时间分析验证可调度性。

在 RTOS 任务架构设计中，建议为每个任务明确标注：类型（硬/软实时）、周期或触发方式、截止时间、WCET 估算值、优先级和阻塞来源。这张“任务时间档案”是后续优先级分配和可调度性分析的基础。

不要在没有 WCET 数据的情况下宣称系统满足硬实时。最坏执行时间必须通过测量、静态分析或两者结合获得，并考虑缓存、分支预测、中断嵌套和临界区带来的不确定性。

总结来说，硬实时与软实时决定了设计的严格程度；确定性、抖动和延迟描述了时间行为的可预测性；吞吐量衡量效率；截止时间则是最终约束。只有把这些指标放在同一张时间链上统一分析，RTOS 的任务架构才能真正做到“既正确又及时”。