4、RTE运行时调度：Runnable的调度策略、周期性调度与事件触发、调度表与任务映射
好，咱们进入RTE最核心的部分——运行时调度。
说白了，Runnable怎么跑起来？什么时候跑？谁来决定它跑多久？这些问题，就是这一章要解决的。我个人习惯把RTE调度比作一个“交通指挥系统”，Runnable就是路上的车，调度策略就是红绿灯和交警的指挥手势。
4.1 Runnable的调度策略：三种基本模式
在AUTOSAR里，Runnable的调度策略其实就三种。嗯，别被各种文档绕晕了，我帮你捋清楚。
- 周期性调度：固定时间间隔执行。比如每10ms跑一次。
- 事件触发调度：某个事件发生了才执行。比如数据到达、错误发生。
- 混合调度：既有周期，又可以被事件唤醒。这是实际项目中最常见的。
我在项目中遇到过一种情况：一个传感器采集Runnable，既需要每5ms采集一次数据，又需要在收到“校准命令”时立即执行。这时候就必须用混合调度。你想想看，如果只用纯周期调度，命令来了得等到下一个周期才能响应，那实时性就没了。
核心要点：Runnable的调度策略不是由Runnable自己决定的，而是由它在SWC中的配置和Task的映射关系决定的。说白了，Runnable只是“被调度”的对象。
4.2 周期性调度：定时器的艺术
周期性调度，听起来简单，但坑不少。
每个周期Runnable，都需要配置一个“周期时间”。这个时间通常以毫秒或微秒为单位。RTE会为每个周期Runnable维护一个定时器，到期就触发执行。
但这里有个问题：多个周期Runnable的周期时间可能不同。比如一个10ms，一个20ms，还有一个50ms。RTE怎么管理？
我建议你记住一个原则：周期时间必须是基础时间片的整数倍。比如基础时间片是1ms，那10ms、20ms、50ms都没问题。但如果有人配了个7ms，那就麻烦了——RTE要么向上取整到8ms，要么向下取整到6ms，总之会引入误差。
避坑指南：我曾经在一个项目中，看到同事把周期配成了13ms和17ms。结果两个Runnable的相位差一直在漂移，导致数据采集不同步。后来我强制要求所有周期时间必须是1ms的整数倍，并且尽量使用最小公倍数来对齐。问题才解决。
4.3 事件触发调度：响应式编程的基石
事件触发调度，说白了就是“有事叫我，没事别烦我”。
RTE支持多种事件类型：
- DataReceivedEvent：数据接收事件。当某个端口收到新数据时触发。
- DataSendCompletedEvent：数据发送完成事件。
- OperationInvokedEvent：服务调用事件。当Client调用Server的接口时触发。
- ModeSwitchEvent：模式切换事件。比如从“正常模式”切换到“省电模式”。
- ErrorEvent：错误事件。比如超时、数据校验失败。
事件触发的好处很明显：节省CPU资源。没有事件发生时，Runnable不执行，CPU可以干别的事。但坏处也很明显：响应时间不确定。如果多个事件同时发生，RTE需要排队处理，优先级高的先执行。
嗯，这里要注意：事件触发Runnable的优先级配置非常关键。我曾经见过一个系统，把所有事件Runnable都配成了同一个优先级，结果高频率的事件把低频率的事件活活饿死了。后来我引入了“优先级继承”机制，才把问题压下去。
4.4 调度表：周期调度的“时间表”
调度表（Schedule Table），是AUTOSAR里管理周期性任务的一种高级机制。我个人觉得，它就像一张“火车时刻表”，规定了每个Runnable在什么时间点执行。
调度表的核心概念：
| 概念 | 说明 |
|---|---|
| 调度表 | 一个包含多个“到期点”的表格 |
| 到期点 | 每个到期点对应一个或多个Runnable的启动时间 |
| 重复周期 | 调度表可以配置为单次执行或循环执行 |
| 同步策略 | 调度表可以与全局时间同步，也可以独立运行 |
举个例子：
调度表：EngineControl_Table
到期点0ms：Runnable_A（采集曲轴位置）
到期点2ms：Runnable_B（计算喷油量）
到期点4ms：Runnable_C（控制喷油嘴）
到期点5ms：Runnable_D（检查故障码）
重复周期：10ms这个调度表每10ms循环一次。每个到期点的时间是相对于调度表启动时间的偏移量。RTE会严格按照时间点触发Runnable。
个人经验：调度表特别适合“时间确定性”要求高的场景。比如发动机控制、电机控制。我在做动力域控制器时，所有关键Runnable都通过调度表管理，确保执行顺序和时间点完全可控。调试时也方便，直接看调度表就知道哪个Runnable应该在什么时候跑。
4.5 任务映射：Runnable到Task的“搬家”
Runnable不能直接跑在CPU上，它必须被映射到Task里。Task才是OS调度的基本单位。
任务映射的原则，我总结为三条：
- 相同优先级的Runnable尽量放在同一个Task里。减少Task切换开销。
- 不同周期的Runnable尽量分开。比如10ms的放一个Task，100ms的放另一个Task。
- 事件触发的Runnable单独放一个Task。避免阻塞周期Task。
你想想看，如果把一个10ms的周期Runnable和一个100ms的周期Runnable放在同一个Task里，会发生什么？Task的周期只能取最小值10ms，那100ms的Runnable每10ms被检查一次，浪费CPU。或者取最大值100ms，那10ms的Runnable就得不到及时执行。
最佳实践：我建议每个Task只包含一个Runnable，或者一组“执行频率相同、优先级相同”的Runnable。这样调度逻辑最清晰，也最容易调试。
4.6 调度表与任务映射的协同
调度表和任务映射不是孤立的。它们需要协同工作。
通常的做法是：
- 调度表负责“时间触发”的Runnable。
- 任务映射负责“事件触发”的Runnable。
- 两者通过RTE的“混合调度机制”整合在一起。
举个例子：一个Runnable既在调度表里配置了周期执行，又配置了事件触发。那它什么时候执行？答案是：谁先到就谁触发。如果周期时间到了，就周期执行；如果事件先来了，就事件执行。但要注意，如果两者同时发生，RTE会按照优先级决定。
避坑指南：我曾经在一个项目中，把同一个Runnable同时配成了周期触发和事件触发，结果两个触发源互相竞争，导致Runnable被重复执行。后来我强制要求：一个Runnable只能有一个“主触发源”，其他触发源只能作为“辅助唤醒”。这样才避免了混乱。
4.7 总结与思考
好，这一章的内容就这些。我帮你理一下思路：
- Runnable的调度策略有三种：周期、事件、混合。
- 周期性调度依赖定时器，注意周期时间的对齐。
- 事件触发调度节省CPU，但要注意优先级和响应时间。
- 调度表是管理周期Runnable的“时间表”，适合确定性场景。
- 任务映射是Runnable到Task的“搬家”，要遵循“同频同优”原则。
下一章，我们会深入RTE的通信机制，看看数据是怎么在SWC之间传递的。嗯，那又是一个大坑，到时候我慢慢给你讲。
公众号:蓝海资料掘金营，微信deep3321