2、实时系统核心特征：确定性、可预测性、时间约束、可靠性

好，咱们今天聊聊实时系统的四个核心特征。这四个词，说白了就是实时系统的「命根子」。你想想看，一个系统如果连这几个基本点都做不到，那它凭什么敢叫「实时」？

我刚开始接触实时系统那会儿，总觉得这些概念太抽象。直到有一次，我在一个工业控制项目里栽了跟头——系统偶尔会延迟几十毫秒响应，结果整条产线都停了。嗯，从那以后，我才真正理解了这四个特征的分量。

2.1 确定性：系统行为必须「说一不二」

什么是确定性？说白了就是：同样的输入，同样的系统状态，每次执行的结果和路径必须完全一致。

你可能会问：「这不是废话吗？所有程序不都应该这样？」

还真不是。普通桌面系统里，你点一下鼠标，系统可能 10ms 响应，也可能 50ms 响应，这都算正常。但在实时系统里，这种「随缘」行为是致命的。

我举个例子。假设你写了一个控制电机转速的任务：

// 非确定性代码：循环次数取决于数据
void control_motor() {
    while (data_available()) {
        process_data();  // 处理时间不确定
    }
    set_motor_speed();  // 什么时候执行？不知道！
}

// 确定性代码：固定时间片
void control_motor_fixed() {
    for (int i = 0; i < MAX_SAMPLES; i++) {
        if (data_available()) {
            process_sample(i);  // 每个样本处理时间固定
        }
    }
    set_motor_speed();  // 保证在固定时间点执行
}

看到区别了吗？第一个版本里，set_motor_speed() 什么时候执行完全取决于数据量。第二个版本，我强制规定了处理窗口，不管有没有数据，都在固定时间点输出控制信号。

2.2 可预测性：我能提前知道「最坏情况」

可预测性和确定性是孪生兄弟。确定性说的是「行为一致」，可预测性说的是「我能提前算出边界」。

你想想看，如果你设计一个刹车系统，你敢说「大部分情况下 100ms 内能刹住」吗？当然不敢。你必须保证「最坏情况下也在 100ms 内」。这就是可预测性的核心——知道最坏情况执行时间（WCET）。

我个人习惯，在设计阶段就会做 WCET 分析。怎么分析？几个关键点：

1. 路径分析：找出所有可能的执行路径，包括分支、循环、异常处理
2. 指令级分析：考虑缓存缺失、流水线停顿、分支预测失败
3. 资源竞争分析：考虑总线争用、DMA 抢占、中断嵌套

这里有个常见的误区：很多人觉得「平均响应时间 1ms，那最坏情况顶多 2ms」。我告诉你，真实情况可能让你大跌眼镜。

可预测性还体现在资源使用上。比如内存占用、总线带宽、堆栈深度，这些都必须有上界。我见过一个项目，因为递归调用导致堆栈溢出，系统在运行 72 小时后突然崩溃。嗯，这种问题最难排查。

2.3 时间约束：死线就是生命线

时间约束，就是给每个任务定一个「死线」（deadline）。过了这个时间点，结果就没用了——甚至可能造成灾难。

时间约束分几种：

约束类型	说明	典型场景
硬实时	错过死线 = 系统失效	安全气囊、飞行控制
软实时	偶尔错过可以接受，但质量下降	视频播放、音频处理
固实时	错过死线的结果被丢弃，但系统继续运行	数据采集、传感器融合

你可能会问：「怎么保证任务都能在死线前完成？」

这就涉及到调度策略了。我个人比较喜欢用速率单调调度（RMS）和最早截止时间优先（EDF）。RMS 适合周期任务，EDF 适合混合周期任务。但要注意，EDF 在过载时表现很差——所有任务一起崩。

// 一个典型的时间约束设计模式
typedef struct {
    uint32_t period_ms;      // 周期
    uint32_t deadline_ms;    // 相对死线
    uint32_t wcet_us;        // 最坏执行时间
    void (*task_func)(void); // 任务函数
} realtime_task_t;

// 调度器检查：必须满足 wcet <= deadline <= period
bool validate_task(realtime_task_t *task) {
    if (task->wcet_us > task->deadline_ms * 1000) {
        return false;  // 不可能满足时间约束
    }
    // 还要考虑调度开销、中断延迟等
    return true;
}

这个公式我建议你记下来。我在做系统设计时，第一件事就是算这个——如果利用率超过 70%，我就知道要小心了。

2.4 可靠性：不出错，或者出错也能扛

可靠性，说白了就是「系统不能挂」。但现实世界没有不出错的系统，所以可靠性更准确的定义是：在规定的条件下，在规定的时间内，完成规定功能的能力。

怎么实现可靠性？我总结了几条：

• 冗余设计：硬件冗余（双机热备）、软件冗余（N 版本编程）、时间冗余（重试机制）
• 故障检测：看门狗定时器、心跳检测、CRC 校验、奇偶校验
• 故障隔离：内存保护单元（MPU）、时间分区、空间分区
• 优雅降级：出故障时不是直接崩溃，而是降级到安全模式

我记得有个项目，客户要求系统连续运行 10 年不重启。10 年啊！87600 小时。我们做了大量的故障注入测试，发现最脆弱的地方竟然是——看门狗本身。如果看门狗芯片坏了，系统就彻底失控了。

还有一个容易被忽略的点：时间上的可靠性。系统运行久了，晶振会漂移、电容会老化、内存会出现位翻转。这些都会影响时间约束。所以，可靠性设计必须考虑时间维度的退化。

2.5 四个特征的关系：缺一不可

这四个特征不是孤立的。我画个简单的逻辑链：

确定性 → 可预测性 → 时间约束 → 可靠性

没有确定性，你就无法预测行为。无法预测行为，你就无法保证时间约束。时间约束保证不了，可靠性就是空谈。

反过来也一样。一个高可靠性的系统，必然要求每个任务都有明确的时间约束。而时间约束的满足，又依赖于可预测的调度分析。可预测性，最终要落实到确定性的代码实现上。

好，这一章就到这里。下一章我们聊聊实时系统的调度算法——那是真正有意思的部分。