Core0 每 10 ms 更新一帧传感器数据，Core1 每 20 ms 读取一次。刚好在 Core1 读取到一半时，Core0 又开始写入：时间戳已经变了，数据数组却仍属于上一帧。程序并不会立刻崩溃，但控制算法拿到的是不一致的快照。

再换一种场景：三个 Core 分别初始化通信、数据和控制模块。Core0 两毫秒就完成，而 Core2 要八毫秒。所有 Core 都完成初始化之后才能开放后续功能，单靠保护共享数据的 Spinlock 还不够。

这两个例子分别对应临界区互斥与阶段会合。前者常用 Spinlock，后者可以用 Barrier 组织；二者都建立在正确的原子操作、内存访问顺序和调度前提之上。我们从 AURIX TC3xx 的底层能力出发，再看 AUTOSAR OS 能提供哪些同步服务。

通用测量核心与 ECU 工程之间的连接集中在平台适配层：它识别实际执行者，读取 STM 时间，形成串行事件，并把统计副本交给报告路径。

对于 TC397 与 AUTOSAR，可以按“Host 模型 → 时间源 → 调度和中断边界 → 周期采样 → 多核发布 → 目标验证”的顺序完成接入。各步骤分别建立一项明确的契约，组合后得到可解释的每核时间账本。

本文使用配套模块中的独立 Hook 模型讲解接口。C99 核心与 Mock 示例已通过 Host 验证；具体 MICROSAR/TASKING/TC397 接入处于 Experimental / Unverified，目标参数和实际 Hook 顺序由工程配置确定。

运行时测量可以分成三个职责：平台产生执行事件，核心维护时间归属，报告路径输出统计结果。显式的分工使同一个算法可以在 PC、裸机和 RTOS 环境中运行。

embedded-runtime-observer 采用 C99 和静态内存实现这一模型。Task、Idle、ISR、调度空档和函数点共用明确的事件边界，在线统计与可选 Trace 各自保留输出状态。v0.2.0 增加独立 Stack Observer，将栈内存需求接入同一报告层。

本文承接时间模型，沿着事件进入核心后的处理过程介绍框架设计。

多核嵌入式开发里有一种容易产生误判的现象：共享变量放在 NonCached RAM，读写都是简单赋值，两边也都进入了 SchM Exclusive Area，但事件队列和业务状态仍可能不一致。

这里不需要先假设硬件缓存出错。更值得追问的是：

“事件已发布”与“事件对应的数据已就绪”，是不是同一个不可分割的状态转换？

本文以 AUTOSAR Classic COM 的一种 Deferred Rx + EventCache 实现为例，借助一个可构造的双核交错，讨论缓存可见性、原子性、内存顺序与跨核互斥之间的区别，以及事件驱动系统该怎样维护状态不变量。

文中的代码是根据实际函数关系抽象的示意性伪代码，不是 AUTOSAR 对所有 COM 实现的统一规定。具体项目还应遵循所使用组件的多核部署和并发访问约束。