AUTOSAR Classic：RTE 执行图 / 隐式访问 / OS-Application 保护

AUTOSAR Classic 里**大量真正的控制流是配置驱动 + 代码生成出来的**：

TimingEvent / DataReceivedEvent / OperationInvokedEvent / ...
        ↓
       RTE（生成的胶水代码）
        ↓
   AUTOSAR Task 或 ISR2
        ↓
 RunnableEntity（业务函数）

所以：

void Runnable_10ms(void);   ← 0 个交叉引用

绝不能直接判死代码。 先找 Rte_* 包装、OS Task、ActivateTask / SetEvent / WaitEvent / Alarm / ScheduleTable，以及生成配置。 </CORE RULE>

一、执行图：RTE 没有独立调度能力

RunnableEntity 由 RTEEvent 激活；事件类型包括定时、数据接收/接收错误、数据发送完成/写入完成、操作调用、异步服务调用返回、模式切换（及其确认/错误）、外部与内部触发、初始化事件、OS 任务执行事件等
RTE 不做调度：每个 RTE Event 必须映射到一个具体的 OS Task，RTE 在该 Task 被 OS 调度时按配置顺序调用相应 runnable；映射必须写进 ECU 配置描述，作为 RTE 生成器的输入
RunnableEntity 在 OS Task 或 ISR2 中执行
区分两个时刻：activation（RTEEvent 指向的事件发生）与 start（它的 C 函数在已启动的 task/ISR2 内被调用）
若某 runnable 没有被任何 RTEEvent 以 startOnEvent 角色引用，RTE 永远不会激活它（但映射到 BSW 可调度实体的 runnable 仍可由 BSW 调度器激活）

二、隐式访问：消费者看到"旧值"可能是设计

隐式读生成 Rte_IRead_<port>_<data_element>；隐式写生成 Rte_IWrite_<port>_<data_element>；显式读是 Rte_Read_<port>_<data_element>(DataType*)
隐式通信下，RTE 在 runnable 被调用前自动读数据、在 runnable 结束后写回；runnable 自身不主动发起传输；写操作在 runnable 结束时才算完成
可观察到的顺序：先为隐式读做数据元素拷贝，之后才触发 runnable 调用事件；runnable 终止事件先于隐式写回
隐式 S/R 通信不支持 RTE API 的 trace 事件

所以：

Producer:  x = 10;  x = 20;
Consumer runnable 执行期间一直看到 x = 10

可能完全符合 RTE 语义，不是 cache/一致性 bug。

分析要求：区分 Rte_Read_* / Rte_IRead_* / Rte_Write_* / Rte_IWrite_*，而不是只追底层 RAM 地址。通信形式由配置固定，不能事后在代码里"改掉"。

三、`E_OS_ACCESS` 不一定是"对象坏了"

AUTOSAR OS 的分区表示是 OS-Application，带所有权与保护状态：

若某 OS 对象标识被传给系统服务（例如 ActivateTask），而调用方在配置时没有被授予对该对象的访问权（如 OsTaskAccessingApplication），服务返回 E_OS_ACCESS
若服务调用针对属于另一个、且不处于可访问状态的 OS-Application 的对象，同样返回 E_OS_ACCESS
信任（trusted）与非信任（non-trusted）应用一视同仁：默认拒绝，只有配置显式授予才能跨应用访问
例外：检查类服务（CheckObjectAccess 等）不需要授权——可用于调用前预判
信任级别只影响少数服务（例如终止应用：受信任应用的任务/中断可终止任意 OS-Application）
访问错误也可能触发保护钩子

所以排查顺序是：

对象属于哪个 OS-Application？应用状态？trusted / non-trusted？
内存保护？当前调用上下文？
        ↓
而不是先判"task ID 写错了"

另外：Category 1 ISR 并不由 OS 完整管理，因此常规 OS 保护不能简单覆盖这种上下文

四、并发问题多半在 OS 配置，不在应用逻辑

大量互斥区处理是生成的（RTE 自动保护、OS 资源、BSW 临界区），而不是手写。出现并发异常时，先核对 OS 配置：runnable 映射到哪个 Task、优先级、ISR 抢占关系，再看应用代码。

决策树

拿到 AUTOSAR Classic 目标
├─ 某个 runnable 没有调用者
│    ├─ 找 Rte_* 包装与 RTEEvent 映射
│    ├─ 找它被映射到的 OS Task（ActivateTask/SetEvent/Alarm/ScheduleTable）
│    └─ 别标 dead code
├─ 变量值与预期不符
│    ├─ 区分显式访问（Rte_Read_/Rte_Write_）与隐式访问（Rte_IRead_/Rte_IWrite_）
│    ├─ 隐式访问在 runnable 边界做快照/写回 → "看到旧值"可能是语义
│    └─ 别先判 cache 一致性或内存损坏
├─ 服务调用返回 E_OS_ACCESS
│    ├─ 查对象所属 OS-Application 与其实例状态
│    ├─ 查当前调用上下文（哪个 task/ISR）与信任级别
│    └─ 别先判参数错误
├─ 进程/任务不运行
│    ├─ 查 runnable 到 Task 的映射与 Task 是否被激活
│    └─ 查初始化/模式相关事件
└─ 并发异常
     └─ 先核对 OS 配置（Task 映射、优先级、抢占），再谈应用逻辑

工具与验证

执行图：ECU 配置描述（runnable → RTEEvent → OS Task 的映射）与生成的 RTE 胶水代码
访问语义：Rte_Read_* / Rte_IRead_* / Rte_Write_* / Rte_IWrite_* 的调用点与端口配置
保护：OS-Application 归属与访问权配置、状态检查服务、保护钩子
验证：能同时说清「runnable 由谁激活、在哪个 Task 里跑 + 数据是显式还是隐式访问 + 跨应用访问是否被授权」

该平台的坑（汇总）

把没有 caller 的 runnable 当死代码：它由 RTEEvent 经 RTE 激活，映射在配置里
以为 RTE 会自己调度：RTE 无独立调度能力，事件必须映射到 OS Task
混淆 activation 与 start 两个时刻
把隐式访问的"旧值"当 cache/一致性 bug：隐式访问在 runnable 边界做快照与写回
只追 RAM 地址不看 Rte_I 系列*：无法区分显式/隐式语义
把 E_OS_ACCESS 当参数错误：先查 OS-Application 归属与访问权配置
以为 trusted 应用可以随意跨应用访问：默认拒绝，授权来自配置
忽略 Category 1 ISR 不受 OS 完整管理：常规保护假设在这里不成立
在应用代码里找并发根因：先核对 Task 映射、优先级与抢占配置

6.2 KiB Raw Blame History Unescape Escape