3. 调度可行性分析基础：利用率上界、最坏情况执行时间（WCET）、响应时间分析
各位同学，咱们今天聊点实在的。你设计了一个实时系统，任务都安排好了，调度器也跑起来了。但你怎么知道它靠不靠谱？会不会在关键时刻掉链子？
这就是调度可行性分析要干的事。说白了，就是给系统做一次「体检」。我做了十几年嵌入式，见过太多系统上线后才发现调度不过关，那叫一个惨。所以，咱们今天把这几个核心概念掰开揉碎了讲清楚。
3.1 利用率上界：一个简单的「体检指标」
先问个问题：一个CPU到底能跑多少个任务？
你可能会说，这还不简单，看CPU占用率呗。但实时系统里，事情没那么简单。因为任务有截止时间，你不能让CPU一直满负荷跑。
这里有个经典结论：对于固定优先级调度（比如RMS），只要所有任务的利用率之和不超过某个上界，系统就一定可调度。
这个上界是多少？对于n个周期任务，利用率上界U_max = n * (2^(1/n) - 1)。
我刚开始学这个公式时，觉得它挺玄乎。后来在项目中才发现，这玩意儿就是个快速筛选工具。比如你算出来利用率只有0.6，而理论极限是0.69，那基本可以放心了。
核心结论：
- 当n→∞时，U_max → ln2 ≈ 0.693
- 也就是说，固定优先级调度下，CPU利用率超过69.3%就可能出问题
- 这只是一个充分条件，不是必要条件。利用率超过上界，系统不一定不可调度
我的经验：在实际项目中，我一般把利用率控制在60%以内。为啥？留点余量给中断、系统开销、还有那些你没想到的突发任务。我曾经有个项目，利用率算出来68%，觉得没问题，结果一跑起来，中断一多，直接崩了。从那以后，我给自己定了个规矩：理论值打八折。
3.2 最坏情况执行时间（WCET）：最难搞的参数
利用率上界虽然好用，但它依赖一个关键参数：每个任务的执行时间。而且，不是平均执行时间，是最坏情况执行时间（WCET）。
WCET是什么？就是你的代码在最倒霉的情况下，跑完一遍需要的最长时间。
你想想看，一个任务可能因为数据分支不同、缓存命中率不同、甚至因为DMA占用了总线，执行时间天差地别。WCET就是要找出那个「最慢」的情况。
我个人习惯把WCET分析分成三步走：
- 静态分析：看代码，数指令，算路径。工具如aiT、SWEET都能干这事。
- 测量法：在真实硬件上跑，用示波器或逻辑分析仪抓执行时间。但要注意，你测到的可能不是最坏情况。
- 混合法：静态分析加测量，互相验证。我最推荐这种方式。
避坑指南：我曾经在一个项目中，只用了测量法测WCET。结果产品交付后，客户在特定数据组合下触发了从未见过的代码路径，执行时间直接翻倍。嗯，从那以后，我再也不敢只依赖测量了。静态分析虽然麻烦，但能帮你找到那些「隐藏路径」。
这里有个简单的WCET分析示例（伪代码）：
// 任务：数据采集与处理
void task_data_process(void) {
// 路径1：正常数据（WCET = 5ms）
if (data_valid) {
process_normal();
}
// 路径2：异常数据（WCET = 12ms）
else {
process_error();
log_error(); // 写日志，可能涉及I/O
}
// 路径3：校验（WCET = 3ms）
checksum();
}
// WCET = max(5+3, 12+3) = 15ms
// 注意：路径2中的log_error()可能因为缓冲区满而阻塞，实际WCET可能更大你看，代码里藏着多少坑。路径2的log_error()，如果日志缓冲区满了，要等I/O写完，那时间可就不好说了。所以，WCET分析一定要结合硬件特性。
3.3 响应时间分析：真正的「生死线」
利用率上界和WCET都是基础，但最终我们要回答的问题是：每个任务能在截止时间前完成吗？
这就是响应时间分析（RTA）要干的事。它计算的是任务从释放到完成的最长时间，然后跟截止时间比。
对于固定优先级调度，响应时间R的计算公式是：
R = C + Σ(⌈R/T_j⌉ * C_j)
其中：
- C：任务自身的WCET
- T_j：高优先级任务的周期
- C_j：高优先级任务的WCET
- ⌈R/T_j⌉：在响应时间R内，高优先级任务被释放的次数
这个公式看着有点吓人，其实道理很简单：你的任务要等所有高优先级任务都跑完，才能轮到你。
而且，R出现在等式两边，需要迭代求解。我一般这么干：
- 先假设R = C（没有干扰）
- 代入公式算新的R
- 重复，直到R收敛或超过截止时间
举个例子：
假设有三个任务：
| 任务 | 周期T (ms) | WCET C (ms) | 截止时间D (ms) |
|---|---|---|---|
| Task1（最高优先级） | 10 | 2 | 10 |
| Task2 | 20 | 3 | 20 |
| Task3（最低优先级） | 50 | 5 | 50 |
分析Task3的响应时间：
迭代1：R0 = 5
迭代2：R1 = 5 + ⌈5/10⌉*2 + ⌈5/20⌉*3 = 5 + 1*2 + 1*3 = 10
迭代3：R2 = 5 + ⌈10/10⌉*2 + ⌈10/20⌉*3 = 5 + 1*2 + 1*3 = 10
收敛！R = 10ms < 50ms，Task3可调度。
我的建议：RTA分析一定要用工具做。手动算几个任务还行，任务一多，脑子就转不过来了。我常用的是MAST（Modeling and Analysis Suite for Real-Time Applications），开源免费，挺好用。另外，记得把中断处理时间也算进去，很多人会忽略这个。
3.4 三个指标怎么配合使用？
好了，三个核心概念都讲完了。它们不是孤立的，在实际项目中，我一般这么用：
- 第一步：算利用率上界。快速判断系统有没有「硬伤」。如果利用率远低于上界，基本可以放心。
- 第二步：测WCET。这是最花时间的环节。我建议先静态分析，再实测验证，反复迭代。
- 第三步：做RTA。对每个关键任务做响应时间分析，确保截止时间能满足。
你可能会问：利用率上界都过了，为什么还要做RTA？
因为利用率上界是充分条件，不是充要条件。我遇到过利用率只有50%，但某个低优先级任务因为被频繁抢占，响应时间超了。RTA能发现这种「局部问题」。
嗯，今天就先聊到这儿。这三个概念是实时调度的基石，搞懂了它们，后面讲更复杂的调度策略时，你就能游刃有余了。下次咱们聊聊「优先级反转」这个经典问题，那可是个坑，我当年踩得可不轻。