2、实时系统基础：实时性指标、硬实时与软实时、实时任务调度模型

实时系统（Real-Time System）的核心并非“快”，而是“确定性”。在Linux内核被应用于工业控制、机器人、航空航天、车载系统、医疗设备等场景时，系统必须在严格的时间约束内对外部事件做出响应。理解实时性的本质，需要从三个维度展开：衡量实时性的量化指标、系统对时间约束的承诺等级（硬实时与软实时），以及支撑这些承诺的任务调度模型。本章将逐一剖析这些基础概念，为后续的Linux内核实时化配置（如PREEMPT_RT补丁、CPU隔离、中断线程化）奠定理论基础。

2.1 实时性指标：延迟、抖动与吞吐量

核心原理

实时系统的性能评估不能仅看平均处理速度，而必须关注时间行为的最坏情况。三个核心指标构成了实时性评估的基石：

• 延迟（Latency）：从事件发生（如中断信号到达、数据包接收）到系统完成响应（如任务开始执行、输出信号翻转）所经历的总时间。在Linux中，延迟通常分解为：中断延迟（硬件中断到中断处理程序开始执行）、调度延迟（任务就绪到被调度上CPU）以及执行时间。实时系统关注的是最坏情况延迟（Worst-Case Latency），而非平均值。
• 抖动（Jitter）：指多次任务执行周期中，实际响应时间相对于理想周期时间的偏差。例如，一个控制周期为1ms的任务，实际执行周期可能在0.98ms到1.05ms之间波动，这0.07ms的偏差就是抖动。抖动是衡量系统稳定性的关键指标，对于音视频同步、电机控制等场景，过大的抖动会导致数据断裂或控制精度下降。
• 吞吐量（Throughput）：单位时间内系统成功处理的任务数量或数据量。虽然实时系统不追求极致吞吐，但吞吐量过低会导致任务积压，进而引发延迟超限。在实时系统中，吞吐量通常作为约束条件而非优化目标——必须在满足延迟和抖动要求的前提下，尽可能提升吞吐量。

判断方法与测量工具

在Linux环境中，测量这些指标需要借助专用工具和内核接口：

1. 延迟测量：使用 cyclictest（来自rt-tests套件）测量线程唤醒延迟。该工具通过创建高优先级实时线程，记录线程实际唤醒时间与理论唤醒时间的差值，从而量化调度延迟和中断延迟。
2. 抖动分析：通过 trace-cmd 或 ftrace 记录内核事件时间戳，分析任务唤醒时间戳序列的分布。重点关注最大抖动值和抖动分布直方图。
3. 吞吐量评估：使用 perf 工具统计上下文切换次数、CPU利用率，或通过 iostat 观察I/O吞吐。对于网络实时应用，可使用 netperf 测试报文处理速率。

# 使用 cyclictest 测量实时线程调度延迟（运行5分钟，输出直方图）
cyclictest -t 1 -p 95 -i 1000 -l 300 -h 200 -q
# 参数说明：-t 线程数，-p 优先级(95为SCHED_FIFO高优先级)，-i 间隔(微秒)，-l 循环次数，-h 直方图桶数

案例拆解：工业以太网伺服驱动器的延迟预算

某伺服驱动器项目要求位置环控制周期为250μs，且抖动不超过±5μs。系统基于x86平台运行Linux + PREEMPT_RT补丁。初始测试发现，平均延迟为80μs，但最大延迟达到320μs，远超250μs周期，导致偶发控制超时。

分析过程：通过 trace-cmd 抓取延迟超过200μs的事件，发现延迟主要来源于：① 网卡中断处理占用CPU时间过长（中断合并导致）；② 内核的 ksoftirqd 在软中断处理中执行了耗时操作；③ 另一个实时线程因优先级反转被阻塞。

优化措施：

• 将网卡驱动中断合并（coalescing）参数调低，减少单次中断处理的数据量；
• 将控制线程绑定到独立CPU核心（isolcpus），并设置 threadirqs 内核参数将中断处理线程化；
• 使用优先级继承协议（通过 pthread_mutexattr_setprotocol 设置PTHREAD_PRIO_INHERIT）解决优先级反转。

结果对比：优化后最大延迟降至180μs，抖动控制在±3μs以内，满足控制周期要求。代价是CPU占用率从30%提升至45%，但换来了确定性的时间行为。

2.2 硬实时与软实时的区别

核心原理

实时系统根据错过截止期（Deadline）的后果严重程度，分为硬实时和软实时两类。这一分类决定了系统设计策略、调度算法选择以及Linux内核的配置方向。

判断方法：如何确定系统属于哪一类

在实际工程中，可以通过以下问题来判定：

1. 后果评估：如果任务在截止期后完成，是否会导致系统崩溃、数据不可恢复或安全事故？如果是，则为硬实时。
2. 容错机制：系统是否设计了超时重试、数据缓存或降级策略？如果超时后可以通过重试恢复，则偏向软实时。
3. 行业标准：参考行业规范，如IEC 61508安全完整性等级（SIL）要求硬实时保证，而ITU-T Y.1541仅要求网络延迟的统计上限。

案例拆解：自动驾驶中的混合实时性需求

自动驾驶域控制器同时包含硬实时和软实时任务：

• 硬实时任务：安全气囊触发控制（截止期1ms，错过则可能导致乘员伤亡）、制动压力调节（截止期5ms）。
• 软实时任务：摄像头图像识别（帧率30fps，允许偶发丢帧）、路径规划（周期100ms，超时后可使用上一帧规划结果）。

在Linux实现中，硬实时任务被分配至独立CPU核心，使用SCHED_FIFO优先级90以上，并关闭该核心的调度器tick（通过 nohz_full 参数）。软实时任务则运行在其余核心，使用SCHED_OTHER配合cgroup进行CPU带宽限制。这种混合设计既保证了安全关键任务的确定性，又充分利用了多核资源。

2.3 实时任务调度模型

核心原理

实时调度模型的核心是决定“哪个任务在何时运行”。Linux内核提供了多种调度策略，但实时任务主要依赖以下模型：

• 固定优先级调度（Fixed-Priority Scheduling）：每个任务分配一个静态优先级，调度器始终选择最高优先级的就绪任务运行。Linux的 SCHED_FIFO 和 SCHED_RR 即属于此类。其中SCHED_FIFO任务一旦运行，除非主动让出CPU或被更高优先级任务抢占，否则将持续运行；SCHED_RR在相同优先级任务间采用时间片轮转。
• 速率单调调度（Rate Monotonic, RM）：一种经典的固定优先级分配算法，任务的优先级与其周期成反比——周期越短，优先级越高。RM在理论上被证明是固定优先级调度中的最优算法（对于周期任务且截止期等于周期的情况）。
• 最早截止期优先（Earliest Deadline First, EDF）：动态优先级调度算法，每次调度时选择截止期最近的任务运行。EDF在理论上是最优的动态优先级算法，能够实现100%的CPU利用率（在理想条件下），但Linux原生内核并未直接支持EDF，需要借助实时补丁或用户态调度框架（如SCHED_DEADLINE，自Linux 3.14起已支持）。
• 优先级继承协议（Priority Inheritance）：用于解决优先级反转问题——当高优先级任务被低优先级任务持有的锁阻塞时，低优先级任务临时继承高优先级任务的优先级，从而避免中优先级任务无限期抢占CPU。

调度模型选择与配置流程

1. 任务特征分析：列出所有实时任务的周期、执行时间、截止期、资源依赖（锁、I/O）。
2. 可调度性分析：使用RM的充分条件（CPU利用率 ≤ n(2^(1/n)-1)）或EDF的充分必要条件（总利用率 ≤ 1）进行初步验证。
3. 选择调度策略：对于周期固定的控制任务，优先选择SCHED_FIFO并手动分配优先级（基于RM原则）；对于突发性强、截止期动态变化的任务，考虑SCHED_DEADLINE。
4. 配置内核参数：设置 isolcpus 隔离实时任务核心，使用 nohz_full 关闭隔离核心的时钟中断，通过 rcu_nocbs 将RCU回调迁移至非实时核心。

# 内核启动参数示例（/etc/default/grub 中修改 GRUB_CMDLINE_LINUX）
GRUB_CMDLINE_LINUX="isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3 threadirqs"
# 说明：将CPU2和CPU3隔离给实时任务，关闭其时钟中断，并线程化中断处理

案例拆解：多轴运动控制器的调度模型设计

某六轴机器人控制器需要同时处理六个伺服轴的插补计算（周期1ms）和一个视觉定位任务（周期10ms）。所有任务运行在四核x86 Linux平台上。

初始设计：将所有任务运行在CPU0-1上，使用SCHED_FIFO，优先级从高到低依次为：轴1-6插补任务（优先级80-85）、视觉任务（优先级70）。测试发现，当视觉任务运行时，轴3的插补延迟偶尔超过1ms。

问题分析：通过 perf sched 查看调度记录，发现视觉任务虽然优先级较低，但其执行时间较长（约3ms），且持有某个全局锁，导致轴3任务在等待锁时被阻塞。此外，CPU0上还运行着内核线程（如 kworker），干扰了实时任务的调度。

优化方案：

• 将六个轴任务分别绑定到CPU2和CPU3（每个CPU三个任务），视觉任务绑定到CPU1，CPU0保留给内核线程和中断处理。
• 为轴任务设置优先级：轴1-3在CPU2上优先级85、84、83；轴4-6在CPU3上同理。
• 将视觉任务改为SCHED_DEADLINE，设置运行时间2ms、周期10ms、截止期10ms，确保其不会长时间占用CPU。
• 使用 pthread_mutexattr_setprotocol 为共享数据锁启用优先级继承。

结果：轴任务最大延迟从1.2ms降至0.6ms，抖动从±0.15ms降至±0.03ms。视觉任务虽然偶发超时（约0.1%概率），但可通过缓存上一帧结果进行补偿，不影响整体控制性能。