实时系统基础（Real-Time Systems）
实时系统的关键，不只是计算结果是否正确，还包括结果是否在规定的时间约束内产生。 实时性关注的是任务对时间的要求，以及系统能否在明确的工作负载和运行条件下满足这些要求。 理解实时系统，需要从截止时间、执行时间、响应时间、中断和调度机制共同分析。
一、什么是实时系统？
实时系统（Real-Time System）是其正确性或服务质量与时间约束密切相关的计算系统。 一个任务即使最终得出了正确结果，如果结果产生得太晚，也可能无法满足系统需求。
例如，控制系统需要在规定时间内处理传感器输入并更新控制输出； 通信设备需要在协议规定的时间窗口内完成相应处理。 具体允许的延迟取决于应用需求，而不是由“RTOS”这个名称自动决定。
二、任务的时间约束模型
实时任务通常需要描述任务何时释放、需要多少处理器执行时间，以及最晚何时完成。 这为调度分析和截止时间验证提供了基础。
这里的执行时间 C 是任务实际占用处理器执行的时间； 响应时间 R 则从任务释放开始计算，通常还会受到排队等待、抢占、阻塞和系统开销的影响。 两者不能直接视为同一个指标。
执行时间（Execution Time）
任务在处理器上实际执行所消耗的时间。 在实时分析中，需要关注与指定输入、路径和目标平台相关的执行时间上界。
响应时间（Response Time）
从任务释放到任务完成所经过的时间。 它包括任务自身执行时间，也可能包含等待、阻塞和被其他工作打断所产生的时间。
截止时间（Deadline）
任务必须完成的时间界限。 截止时间可以相对于任务释放时刻定义，也可以表示为具体的绝对时刻。
周期与释放间隔
周期任务会按一定周期重复释放；事件驱动任务则可能在外部事件发生时释放。 不同释放模式会影响调度分析的方法和假设。
三、硬实时、固实时与软实时
实时系统常根据错过截止时间的后果进行分类。 分类重点在于超时意味着什么，而不是处理器速度或操作系统名称。
硬实时（Hard Real-Time）
对规定的关键任务而言，错过截止时间属于不可接受的系统失效。 设计需要在明确假设下证明或充分验证相关时间约束能够得到满足。
固实时（Firm Real-Time）
结果超过截止时间后通常失去使用价值，但偶发超时不一定意味着整个系统立即失效。 是否允许超时以及允许多少次，取决于具体应用要求。
软实时（Soft Real-Time）
超时会降低服务质量或使用体验，但结果通常仍有一定价值。 系统往往关注延迟分布、超时比例和整体服务质量。
非实时系统
系统可能更关注吞吐量、交互体验、公平性或资源利用率， 但仍然可能存在延迟目标和性能要求。
四、实时系统的关键评价指标
| 指标 | 含义 | 主要用途 |
|---|---|---|
| WCET | 最坏情况执行时间（Worst-Case Execution Time） | 分析任务或代码路径的执行时间上界。 |
| WCRT | 最坏情况响应时间（Worst-Case Response Time） | 评估任务在指定假设下，从释放到完成可能经历的最长时间。 |
| 中断延迟 | 从中断请求产生到处理程序开始执行之间的延迟，具体边界需明确 | 分析外部事件进入系统后的响应起点。 |
| 调度延迟 | 调度请求产生到目标任务获得执行机会之间的延迟，具体定义依实现而定 | 评估任务状态变化、调度判断和任务交接的开销。 |
| 抖动（Jitter） | 事件、任务释放或输出时刻相对于理想时序的变化 | 分析周期任务和控制输出的时间稳定性。 |
| 截止时间裕量 | 截止时间与实际或分析得到的完成时间之间的余量 | 判断任务是否满足时间约束，以及剩余时间预算。 |
WCET 是实时分析的重要基础，但它并不等于最坏响应时间。 即使任务自身执行时间很短，如果需要等待资源、受到高优先级任务干扰， 或者经历较长的中断屏蔽区，也可能无法及时完成。
五、从事件到任务完成：系统执行链
对事件驱动的嵌入式实时系统，可以从事件发生开始，沿着中断处理、任务就绪、 调度决策、上下文切换和任务执行逐步分析时间开销。 这是一种通用分析模型，具体内核可能采用不同的执行路径。
并非每次中断都会引起任务切换，也并非所有任务都由中断触发。 对周期任务，释放事件可能来自系统时钟；对轮询任务，执行机会则可能由主循环或调度机制决定。
六、确定性不等于速度快
确定性强调系统行为是否具有明确、可预测或可分析的边界。 一个系统即使平均执行速度很快，如果关键路径存在无法约束的延迟， 仍然难以证明它能满足严格的实时要求。
平均性能
反映常见工作负载下的执行效率， 适合用于评估吞吐量和典型运行表现。
最坏情况分析
关注明确分析范围内的最不利执行路径、任务干扰和系统开销， 用于判断时间约束是否能够得到满足。
可预测性
要求关键执行行为有清楚的条件、边界和状态转换， 使系统行为能够被理解、测试和分析。
时间保证
需要结合执行时间上界、调度策略、资源访问约束和运行假设， 不能仅凭一次测试或平均值作出结论。
七、调度模型会影响哪些时间约束？
抢占式与协作式调度采用不同的任务交接机制，因此会影响等待时间、任务干扰和分析方法。 但任何一种调度模型都需要明确任务执行时间和系统运行约束。
抢占式调度
高优先级任务可以在符合内核规则的时机抢占当前任务。 分析时需要考虑抢占开销、优先级干扰、阻塞和不可抢占区。
协作式调度
任务通常在主动交接或进入等待状态后才释放执行权。 分析时需要特别关注最长连续执行时间和最迟交接点。
调度机制决定任务如何竞争处理器资源，但系统能否满足截止时间， 仍然取决于任务集、执行时间、释放模式、资源竞争和具体调度规则。
八、实时系统分析如何落地到 HRTOS？
对运行在 8051 等资源受限平台上的 RTOS，时间分析需要进一步落实到具体处理器、 编译器、内核版本和配置。仅知道任务优先级或系统时钟频率， 还不足以确定真实的最坏响应时间。
代码与反汇编
C 语言代码的结构不一定能直接体现实际指令执行路径。 对时间敏感代码，需要结合编译产物和目标处理器指令周期分析。
中断与上下文
需要确认中断入口、寄存器保存、返回路径和任务上下文切换的实际实现， 而不是直接套用其他处理器的机制。
资源约束
RAM、堆栈、寄存器组和临界区设计会影响可用的执行机制， 也可能影响最坏执行路径和系统响应。
分析结论的边界
应说明目标配置、输入范围、分析假设和未覆盖路径。 只有结论的适用范围清晰，时间分析结果才有工程意义。
九、总结：从时间要求到可验证的系统行为
实时系统不只是一个软件类别，也是一种围绕时间约束组织和验证计算行为的工程方法。 对 HRTOS 而言，理解这一模型有助于把内核机制与可测量、可分析的时间指标联系起来， 并为后续的 WCET 和系统响应时间研究建立统一基础。