AUTOSAR CP 从上电到 Runnable

AUTOSAR CP 从上电到 Runnable：EcuM、OS、BswM 与 RTE 启动调度机制深度解析

本文面向已经具备 C 语言、MCU 中断和 RTOS 基础，希望真正理解 AUTOSAR Classic Platform ECU 为什么能"从复位跑到应用"的工程师。

版本说明：本文以 AUTOSAR Classic Platform R25-11 为背景。不同基础软件供应商的生成函数名、调用封装和配置界面会有差异，文中的 C 代码是用于解释机制的等价伪代码，不应直接替换量产工程中的生成代码。

1. 先给结论：Runnable 不是被 RTE 凭空调度的

在 AUTOSAR CP 中，真正拥有 CPU 调度权的是 AUTOSAR OS 。RTE 的作用是把模型中的 TimingEvent、DataReceivedEvent、OperationInvokedEvent 等事件，转换为 OS 可以执行的实体，例如：

激活一个 Basic Task；
为 Extended Task 设置 Event；
在某个 Task 的函数体中按静态顺序调用 Runnable；
在跨核或跨分区场景下，经 IOC、RTE Buffer 或受保护的通信路径传递数据。

因此，分析"Runnable 为什么没有运行"时，不能只盯着 SWC 代码。完整因果链是：

text 复制代码

Reset
  |
  v
启动文件 / C Runtime
  |  建栈、初始化 .data/.bss、时钟和最小硬件环境
  v
EcuM_Init()                     [StartPreOS]
  |  选择配置、初始化 OS 启动所需驱动
  v
StartOS(AppMode)
  |  OS 初始化、StartupHook、启动自动对象、进入调度
  v
Init Task -> EcuM_StartupTwo()  [StartPostOS]
  |  SchM_Init、BswM_Init
  v
BswM 执行模式仲裁与动作列表
  |  启动 RTE、通信栈及其他 BSW
  v
OS Task / Alarm / ScheduleTable / Event
  |
  v
RTE 生成的 Task Body
  |
  v
Runnable

只要其中任何一段未建立，应用层就可能表现为"ECU 已经启动，但业务逻辑不运行"。

2. 复位到 `EcuM_Init`：此时还没有 OS 保护

MCU 从复位向量进入启动代码后，通常先完成以下工作：

设置初始栈指针和异常向量；
初始化最小可用时钟、RAM/ECC 等芯片相关资源；
将 .data 从 ROM 复制到 RAM，清零 .bss；
执行编译器运行库初始化；
进入 main() 或集成商定义的启动入口；
调用 EcuM_Init()。

这部分主要由 MCU 启动文件、链接脚本、编译器运行库和芯片启动代码负责，不属于 RTE。一个典型的逻辑结构如下：

c 复制代码

int main(void)
{
    /* 此前已完成 C Runtime 初始化。 */
    EcuM_Init();

    /* 正常情况下 StartOS 不返回，因此通常不会到达这里。 */
    for (;;) {
        EcuM_ErrorHook(ECUM_E_UNEXPECTED_EXECUTION);
    }
}

这一阶段要特别注意三个约束：

OS 尚未启动，不能假设 Task、Alarm、Resource、OS Counter 已可用；
中断环境尚未完全建立，启动规范要求 PreOS 序列尽可能短；
初始化顺序必须服从依赖关系，例如使用 PLL 时钟的外设不能早于 Mcu 时钟切换完成。

很多启动异常本质上不是 EcuM 问题，而是启动文件、链接地址、ECC RAM 初始化或时钟切换失败。若程序连 EcuM_Init() 入口都没有到达，应先检查 Reset Reason、PC、SP、向量表和链接映射，不要直接从 BswM 开始排查。

3. `EcuM_Init` 与 StartPreOS：为什么驱动初始化要分块

EcuM_Init() 负责执行 StartPreOS 序列。其核心目标不是"初始化全部 BSW"，而是建立足以选择配置并启动 OS 的最小环境。

3.1 `EcuM_AL_DriverInitZero`

EcuM_AL_DriverInitZero() 很早被调用。这个阶段只能依赖 Pre-Compile 或 Link-Time 配置，因为 Post-Build 配置尚未确定。常见工作包括：

初始化读取 Post-Build 配置所必需的底层资源；
完成极早期的芯片相关设置；
初始化早期错误记录所需的最小模块；
建立后续配置选择函数可以使用的硬件条件。

不要简单地把所有 MCAL 初始化都塞进 InitZero。判断标准应是：该模块是否是选择或校验 Post-Build 配置、启动 OS 的必要依赖。

3.2 选择并校验 Post-Build 配置

同一份可执行镜像可能对应多个 ECU 变体。EcuM_DeterminePbConfiguration() 可以根据引脚、电阻编码、NVRAM、启动参数或其他条件选择 Post-Build 配置集。

c 复制代码

const EcuM_ConfigType *EcuM_DeterminePbConfiguration(void)
{
    uint8 variant = Board_ReadVariantCode();

    if (variant == BOARD_VARIANT_HIGH) {
        return &EcuM_Config_High;
    }

    return &EcuM_Config_Base;
}

量产工程必须保证以下对象来自同一个一致的配置集合：

EcuM 配置；
OS 配置；
RTE 生成物；
BSW 模块的 Post-Build 配置；
PduId、NetworkHandle、Channel、Core/Partition 等跨模块 ID。

仅仅"指针非空"并不代表配置一致。错误的配置变体可能直到通信开始后才表现为 PDU 路由错位、控制器索引越界或 Runnable 映射错误。

3.3 `EcuM_AL_DriverInitOne`

确定 Post-Build 配置后，EcuM_AL_DriverInitOne() 可以初始化启动 OS 所需、且可能依赖该配置的模块或硬件。其具体清单由项目依赖决定，不能机械照抄其他 ECU。

可以把 PreOS 初始化看成一个有向无环图：

text 复制代码

晶振/内部时钟
   |
   v
Mcu_Init -> Mcu_InitClock -> Mcu_DistributePllClock
   |                              |
   |                              v
   |                         外设功能时钟
   v                              |
Port_Init                         v
   |                         Gpt/Wdg/Os Counter Source
   v
配置选择引脚 / 唤醒源

真正可靠的初始化列表应由依赖图推导，而不是按模块名字母顺序排列。

3.4 `StartOS(AppMode)` 是控制权切换点

PreOS 序列最后进入 StartOS(AppMode)。AppMode 决定哪些配置为 AutoStart 的 Task、Alarm 和 ScheduleTable 在本次启动中生效。

c 复制代码

StartOS(OSDEFAULTAPPMODE);

StartOS() 成功后不会像普通函数那样返回给 EcuM_Init()；OS 完成内部初始化、执行启动 Hook，并把控制权交给调度器。这就是为什么 EcuM 的启动被拆成 PreOS 和 PostOS 两段。

4. OS 启动后：`EcuM_StartupTwo` 如何重新接管流程

常见集成方式是配置一个自动启动的 Init Task，并在该 Task 中调用 EcuM_StartupTwo()：

c 复制代码

TASK(OsTask_Init)
{
    EcuM_StartupTwo();
    TerminateTask();
}

这段代码虽短，却有三个关键配置前提：

OsTask_Init 在当前 AppMode 中配置为 AutoStart；
Task 所属 OS-Application 已启动且 Core 映射正确；
没有更高优先级的 Task 或 Cat2 ISR 永久占用 CPU。

如果 Init Task 没有执行，SchM_Init()、BswM_Init() 和后续模式动作都不会发生。此时 MCU 可能仍有系统 Tick，中断也可能正常，但应用和通信栈始终没有进入可用状态。

4.1 SchM 到底负责什么

SchM 是 BSW Scheduler。它为 BSW 的 Schedulable Entity 和 Exclusive Area 提供集成接口，但 CPU 的抢占与任务切换仍由 OS 完成。

常见生成代码会把 BSW MainFunction 放入周期 Task：

c 复制代码

TASK(OsTask_Bsw_5ms)
{
    Can_MainFunction_Write();
    Can_MainFunction_Read();
    Com_MainFunctionRx();
    Com_MainFunctionTx();
    BswM_MainFunction();
    TerminateTask();
}

实际函数是否存在、采用轮询还是中断、调用顺序如何，均由模块配置和供应商实现决定。不能因为调用了 SchM_Init()，就认为所有 BSW MainFunction 已自动开始周期运行；必须继续验证对应 OS Task、Alarm 或 ScheduleTable。

4.2 BswM 是模式仲裁器，不是简单的初始化函数列表

BswM 接收来自 EcuM、ComM、CanSM、NvM、DCM、WdgM 等模块的模式请求或状态通知，通过 Arbitration Rule 选择并执行 Action List。典型启动动作可能包括：

启动 RTE；
初始化或启动剩余 BSW；
启动 COM I-PDU Group；
请求网络进入 Full Communication；
启动 OS ScheduleTable；
切换应用 Mode；
在 NvM ReadAll 完成后放行业务功能。

一个工程化的启动门控可以表示为：

text 复制代码

RUN_ALLOWED = EcuM == RUN
           && NvM_ReadAll == FINISHED
           && WdgM_GlobalStatus != FAILED
           && RequiredNetwork == FULL_COMMUNICATION

当 RUN_ALLOWED 为真时，BswM 才执行 Rte_Start、启动 PDU Group 或切换应用模式。这样做能避免应用读取尚未恢复的 NVRAM 数据，或在 CAN 控制器仍离线时发送报文。

需要注意：不同项目的动作归属不同。有的工具链在 EcuM/PostOS 集成代码中启动 RTE，有的通过 BswM Action List 启动。判断依据应是本项目生成代码和配置，而不是经验截图。

5. 从 `TimingEvent` 到 10 ms Runnable

假设一个 SWC 中存在 Runnable_Control10ms，由周期为 10 ms 的 TimingEvent 触发。模型还需要把该 RTE Event 映射到 OS Task。

逻辑模型如下：

text 复制代码

TimingEvent(period = 0.010 s)
            |
            v
RteEventToTaskMapping
            |
            v
OsTask_App_10ms
            |
            v
Runnable_Control10ms()

RTE/OS 生成后，效果接近：

c 复制代码

TASK(OsTask_App_10ms)
{
    Runnable_SensorAcquire10ms();
    Runnable_Control10ms();
    Runnable_ActuatorOutput10ms();
    TerminateTask();
}

周期来源可能是：

OS Alarm 到期后 ActivateTask；
ScheduleTable 的 Expiry Point 激活 Task；
一个基础节拍 Task 在内部执行倍频分频；
供应商生成的其他等价机制。

因此，TimingEvent = 10 ms 只描述设计意图，并不自动保证物理时间精度。最终抖动还取决于：

text 复制代码

Jitter_total = Jitter_counter
             + Interference_higher_priority_tasks
             + Interference_ISR
             + Blocking_resource
             + Cross_core_or_memory_delay

5.1 一个 Task 映射多个 Runnable 时的顺序

同一 Task 内的 Runnable 通常由 RTE 生成静态调用顺序。顺序可能来自 RtePositionInTask、数据依赖和工具生成规则。它们之间不会发生 OS 级抢占，因为当前执行实体仍是同一个 Task；但整个 Task 可以被更高优先级 Task 或中断抢占。

如果控制算法要求"采样 -> 计算 -> 输出"，必须在模型或集成配置中显式保证顺序，不能依靠 ARXML 文件中的偶然排列。

5.2 周期相同不代表应放在同一个 Task

把所有 10 ms Runnable 塞进一个 Task 会减少激活和切换开销，但也会带来：

Task 的 WCET 变长；
一个低 ASIL 或非关键信号处理阻塞整条控制链；
Runnable 之间难以独立配置保护与监控；
超时定位只能看到 Task 超时，难以快速定位具体 Runnable。

拆分 Task 则会增加栈、上下文切换、OS 对象和同步成本。工程上应围绕端到端时限、ASIL 分解、数据依赖、内存保护和 WCET 证据做聚类，而不是只按周期分组。

6. 事件触发 Runnable：Basic Task 与 Extended Task 的差异

对于 DataReceivedEvent 或异步服务调用，RTE 常见映射方式有两类。

6.1 激活 Basic Task

text 复制代码

接收中断
  -> CanIf_RxIndication
  -> PduR_CanIfRxIndication
  -> Com_RxIndication
  -> RTE 数据可用
  -> ActivateTask(Task_RxProcess)
  -> Runnable_RxProcess

Basic Task 被激活后运行至终止。若事件到达速度高于任务处理能力，会消耗 Activation Limit；超过配置上限可能产生 E_OS_LIMIT。所以高频信号不应无条件"一帧激活一次任务"。

6.2 为 Extended Task 设置 Event

c 复制代码

TASK(OsTask_EventDriven)
{
    for (;;) {
        WaitEvent(Ev_RxData | Ev_ModeChanged);

        EventMaskType events;
        GetEvent(OsTask_EventDriven, &events);
        ClearEvent(events);

        if ((events & Ev_RxData) != 0U) {
            Runnable_RxData();
        }

        if ((events & Ev_ModeChanged) != 0U) {
            Runnable_ModeChanged();
        }
    }
}

Extended Task 可以进入 Waiting 状态，适合多个事件复用一个 Task。但 Event 是位语义：同一位在清除前被设置多次，通常不会累计为多个消息。若业务要求"不丢每一次到达"，需要 Queued Sender-Receiver、显式队列或其他计数机制，不能把 OS Event 当消息队列使用。

7. 优先级、资源与最坏响应时间

AUTOSAR OS 以固定优先级调度为核心。高优先级 Task 可以抢占低优先级 Task，Cat2 ISR 又通常高于 Task。对任务 i，经典的最坏响应时间分析可写成：

text 复制代码

R_i^(n+1) = C_i + B_i + sum(ceil(R_i^n / T_j) * C_j)
                             j in hp(i)

其中：

C_i：任务自身 WCET；
B_i：被低优先级任务持有资源造成的最大阻塞；
hp(i)：所有高于任务 i 的任务集合；
T_j、C_j：高优先级任务的周期和 WCET；
收敛后的 R_i 必须不大于 Deadline。

这条公式至少揭示了三个常见误区：

CPU 平均负载低，不代表关键 Task 一定满足 Deadline；
给关键 Task 提高优先级，可能把超时转移到其他任务；
Exclusive Area 越大，阻塞项 B_i 越大。

7.1 Exclusive Area 的代价

RTE 或 SchM 的 Exclusive Area 可能映射为：

OS Resource；
SuspendOSInterrupts/SuspendAllInterrupts；
自旋锁或跨核锁；
供应商实现的短临界区。

如果在 Exclusive Area 内执行 NvM 写入、轮询硬件、复杂 CRC 或大块内存复制，会显著放大中断延迟或高优先级任务阻塞。临界区只应保护最小共享状态；耗时计算应移到临界区外。

7.2 不要在 Task 中无界等待

下面的代码会破坏整个静态调度假设：

c 复制代码

/* 错误示例：高优先级 Task 中无超时轮询。 */
while (Spi_GetStatus() == SPI_BUSY) {
    /* wait forever */
}

应改为异步状态机、通知事件或有界超时，并把等待时间纳入 WCET/故障反应分析。

8. 多核 ECU：不是把单核启动代码复制两份

多核 AUTOSAR OS 要处理 Core、OS-Application、EcuPartition 和共享资源之间的关系。启动时需关注：

哪个 Core 是主核，谁负责启动其他 Core；
每个受 OS 控制的 Core 是否都正确进入 StartOS；
多核是否使用一致的 Application Mode；
StartupHook、应用级 StartupHook 和调度开始前的同步点；
Init Task、BswM 实例、RTE Partition 分别映射到哪个 Core；
跨核通信使用 IOC、RTE 机制还是显式共享内存；
跨核 Exclusive Area 是否需要 Spinlock，以及锁顺序是否一致。

一个危险场景是：主核已经进入 OS，同步点却一直等待某个已启动但没有调用 StartOS() 的从核。此时系统看起来像"卡死在 StartOS 内部"，普通 Task 断点永远不会命中。

跨核共享还会改变时序模型。即使两个 Runnable 都是 10 ms 周期，它们在不同 Core 上也没有天然的先后关系。若控制链要求严格顺序，需要显式同步、数据年龄检查或将强依赖 Runnable 合理共置。

9. 三类最常见的"启动了但没跑"故障

9.1 `EcuM_StartupTwo()` 从未执行

现象： OS Tick 正常，Init Task 之后的 BswM、RTE 初始化断点均不命中。

检查顺序：

StartOS() 使用的 AppMode 是否正确；
Init Task 是否在该 AppMode 中 AutoStart；
Init Task 所属 OS-Application/Core 是否正确；
是否有更高优先级 Task 不终止或 Cat2 ISR 风暴；
OS ProtectionHook/ErrorHook 是否已报告错误。

9.2 RTE 已启动，但周期 Runnable 不执行

现象： Rte_Start() 成功，其他 Runnable 正常，特定周期 Runnable 无调用。

检查顺序：

TimingEvent 是否引用正确 Runnable；
RTE Event 是否存在 RteEventToTaskMapping；
目标 Task 是否由 Alarm/ScheduleTable/自动启动机制激活；
Counter 的 Tick、Alarm 周期和 ScheduleTable Duration 是否换算正确；
目标 Task 是否触发 Activation Limit 或被 Timing Protection 终止；
Runnable 是否被模式禁用或只在特定 Mode 中启用。

9.3 Runnable 在执行，但收不到有效数据

现象： Runnable 断点周期命中，Rte_Read 一直得到初值或旧值。

检查顺序：

COM I-PDU Group 是否已经启动；
CanSM/ComM 是否进入允许接收的通信模式；
CanIf ControllerMode/PduMode 是否正确；
PduR 路由和 Com Rx I-PDU ID 是否一致；
Update Bit、Deadline Monitoring、Invalid Value 或 E2E 校验是否拒绝了数据；
Sender-Receiver 是 Explicit 还是 Implicit 访问，读取时刻是否符合预期。

10. 建立可观测的启动时间线

启动问题最怕只靠断点，因为暂停某个 Core 可能改变看门狗、网络和多核同步行为。建议预留低扰动测量点：

c 复制代码

void StartupTrace(uint16 checkpoint)
{
    TraceBuffer[TraceWriteIndex].id = checkpoint;
    TraceBuffer[TraceWriteIndex].timestamp = Gpt_GetTimeElapsed(...);
    TraceWriteIndex++;
}

推荐检查点：

text 复制代码

0x0100  Enter EcuM_Init
0x0110  DriverInitZero done
0x0120  Post-Build config selected
0x0130  DriverInitOne done
0x0140  Before StartOS
0x0200  StartupHook entered
0x0210  Init Task entered
0x0220  EcuM_StartupTwo done
0x0230  BswM initialized
0x0240  RTE started
0x0300  First 10 ms Task
0x0310  First target Runnable

配合以下证据可以快速闭环：

Reset Reason 与启动次数；
OS Task/ISR Trace；
BswM Rule 的输入值、仲裁结果和 Action List 执行记录；
DET、DEM、ErrorHook、ProtectionHook；
RTE VFB Trace 或 Runnable 入口计数器；
GPIO 翻转和示波器，用于测量真实启动时间与周期抖动。

不要在高频 Runnable 中直接 printf。格式化输出、串口阻塞和锁竞争会改变被测系统本身。

11. 启动与调度配置审查清单

启动链路

EcuM_Init 之前已完成栈、.data/.bss、向量表和必要 RAM/ECC 初始化；
InitZero/InitOne 中的模块顺序有明确依赖依据；
Post-Build 配置选择、兼容性和失败策略已验证；
StartOS 的 AppMode 与 AutoStart 对象一致；
Init Task 一定能调用 EcuM_StartupTwo；
BswM 启动条件不会因某个永远不到达的模式而死锁；
看门狗在长启动流程中有合法监督策略。

调度链路

每个 RTE Event 都有预期的 Task 映射；
周期来源、Counter Tick 和取整误差已确认；
同 Task 内 Runnable 顺序与数据依赖一致；
Task Activation Limit、栈和优先级已做最坏情况分析；
Exclusive Area 足够短且映射机制明确；
ISR、BSW MainFunction 和应用 Task 的干扰已进入响应时间分析；
多核同步、IOC、Spinlock 顺序和分区访问权限已验证。

12. 总结

AUTOSAR CP 的启动不是一串"模块 Init 函数"，而是三次控制权交接：

启动代码把控制权交给 EcuM；
EcuM 在 StartOS() 处把控制权交给 OS；
Init Task 通过 EcuM_StartupTwo() 建立 SchM/BswM，随后由模式管理启动 RTE 和业务调度。

Runnable 的周期性和实时性最终由 OS Task、Counter、Alarm/ScheduleTable、优先级、资源和 WCET 共同决定。RTE 负责把应用模型落实到这些执行实体，但不替代 OS 调度器。

一旦用这条因果链分析问题，"Runnable 不运行"就不再是模糊现象，而可以被拆成：启动阶段未完成、模式条件未满足、事件未映射、Task 未激活、调度受阻或数据路径未启动。每一类问题都有明确的观测点和证据。

参考资料

版权提示：本文为技术解读，未替代 AUTOSAR 官方规范。项目设计应以所采用 Release、供应商实现说明及 OEM/Tier 1 的集成约束为准。

AUTOSAR CP 从上电到 Runnable