4. CDD内部行为(Internal Behavior)：Runnable Entity的概念、触发事件(Event)类型、Runnable与Task的映射
好，咱们继续往下聊。上一章我们把CDD的架构和接口理清楚了，这一章要深入它的“内脏”——也就是内部行为（Internal Behavior）。说白了，就是CDD这个“黑盒子”里面，到底是怎么动起来的。
我个人习惯把CDD比作一个“微型操作系统”。它里面跑着一个个小任务，这些小任务在AUTOSAR里有个专门的名字——Runnable Entity（可运行实体）。你想想看，没有这些Runnable，CDD就是一具空壳，啥也干不了。
4.1 Runnable Entity：CDD的“最小执行单元”
Runnable Entity，我通常简称它为“Runnable”。它是什么？它就是一段C函数代码。但这段代码不是你想调就能随便调的，它必须被AUTOSAR的运行时环境（RTE）调度执行。
每个Runnable都有明确的“入口”和“出口”。它不能像普通函数那样无限循环，也不能在里面阻塞等待。为什么？因为RTE要保证整个系统的实时性。你一个Runnable卡住了，整个Task就崩了。
核心要点：Runnable是CDD内部行为的原子单位。一个CDD可以包含多个Runnable，每个Runnable负责一个特定的功能片段。
我在项目中遇到过这样一个坑：有个同事把整个SPI通信的收发逻辑写在一个Runnable里，结果这个Runnable执行时间超过了10ms，直接把调度周期给拖垮了。后来我建议他把收发拆成两个Runnable，一个负责发，一个负责收，用事件触发来同步，问题就解决了。
4.2 触发事件(Event)类型：谁叫醒了Runnable？
Runnable不能自己跑，它需要被“触发”。AUTOSAR定义了多种触发事件类型，我挑几个最常用的给你讲讲。
| 事件类型 | 触发条件 | 典型应用场景 |
|---|---|---|
| Timing Event | 周期性定时器到期 | 周期性采样传感器数据、状态机轮询 |
| Data Received Event | 接收到来自其他SWC或BSW模块的数据 | 收到CAN报文后立即处理 |
| Operation Invoked Event | 其他SWC调用了本CDD提供的服务接口 | 上层应用请求执行某个硬件操作 |
| Mode Switch Event | 系统模式（如RUN、SLEEP）发生切换 | 进入低功耗模式前关闭外设 |
| Init Event | CDD初始化完成 | 执行一次性的硬件初始化配置 |
嗯，这里要注意：Timing Event是最常用的，但也是最容易被滥用的。我曾经见过一个项目，里面80%的Runnable都用Timing Event触发，结果系统负载高得吓人。其实很多场景用Data Received Event就够了——有数据来了再处理，没数据就歇着，多省资源。
我的建议：能用事件驱动就别用轮询。事件驱动是“按需干活”，轮询是“没事找事”。在嵌入式系统里，省电和省CPU周期同样重要。
4.3 Runnable与Task的映射：谁在跑？
Runnable定义好了，事件也配好了，那谁来执行它？答案是Task。在AUTOSAR里，Runnable必须映射到某个Task上才能运行。
Task是操作系统（OS）的调度单位。AUTOSAR OS通常支持两种Task类型：
- Basic Task（基础任务）：执行完就结束，不能等待事件。适合短小精悍的Runnable。
- Extended Task（扩展任务）：可以等待事件，支持挂起和恢复。适合需要等待外部条件的Runnable。
映射关系其实很简单：一个Task可以包含多个Runnable，这些Runnable按照配置的顺序依次执行。但这里有个关键点——优先级。高优先级的Task会抢占低优先级的Task。如果你的高优先级Task里放了一个耗时很长的Runnable，那低优先级的Task可能永远得不到执行。
避坑指南：我曾经在一个项目中，把所有的Runnable都塞进了一个Task里，结果发现某个Runnable执行时间过长，导致其他Runnable的实时性完全无法保证。后来我按照功能紧急程度，把Runnable分散到了不同优先级的Task中，才解决了问题。
4.4 实战中的映射策略
说了这么多理论，咱们来点实际的。我一般按照以下原则来做Runnable到Task的映射：
- 按实时性分组：对时间要求苛刻的Runnable（比如中断级别的处理）放到高优先级Task；对时间不敏感的（比如日志记录）放到低优先级Task。
- 按功能域分组：同一个外设相关的Runnable尽量放在同一个Task里，减少跨Task的数据同步开销。
- 控制单个Task的负载：单个Task内所有Runnable的总执行时间，不能超过该Task的周期。留出20%的余量，防止极端情况。
下面我画了一张图，帮你理清Runnable、Event和Task之间的关系：
从这张图你可以看到：每个Runnable通过特定的事件触发，最终被映射到不同优先级的Task中执行。这就是CDD内部行为调度的核心逻辑。
4.5 代码层面的体现
说了这么多，咱们看看代码里长什么样。在AUTOSAR配置工具（比如Vector DaVinci、EB tresos）里，你会看到类似这样的配置：
// 伪代码：Runnable定义
RunnableEntity Runnable_Read {
Event = TimingEvent(10ms); // 每10ms触发一次
Mapping = Task_High; // 映射到高优先级Task
Function = CDD_ReadSensor(); // 实际执行的C函数
}
RunnableEntity Runnable_Write {
Event = DataReceivedEvent(CanIf_Message); // 收到CAN消息时触发
Mapping = Task_Mid; // 映射到中优先级Task
Function = CDD_WriteOutput();
}嗯，这里要注意：配置工具生成的代码里，Runnable的函数签名是固定的。你不能随意修改参数列表，否则RTE无法正确调用。我见过有人手痒改了函数参数，结果编译通过但运行时直接崩了——因为RTE传参的地址对不上了。
我的习惯：在配置工具里把Runnable的命名和注释写清楚。比如“Runnable_Read_10ms”一看就知道是10ms周期的读操作。别偷懒，后期维护的时候你会感谢自己的。
好了，这一章的内容就到这里。Runnable、Event和Task的映射关系，是CDD内部行为设计的核心。搞懂了这些，你就能像搭积木一样，灵活地组织CDD的功能逻辑了。