机器人系统里常有这样的现象：Publisher 按计划周期发送消息，Subscriber 也能够收到，但控制器仍然感到“慢半拍”。把原因归结为网络延时很容易，问题却可能出在消息队列、Executor 回调、线程调度，或者指令本身已经过期。

这里从一个简单场景展开：规划节点发送某个关节的目标位置，执行节点检查命令后交给控制接口。 我们不预设运行平台、不声称这是任何实机的实现；用公开的 ROS2 机制和一个虚拟案例，建立可以逐步验证的时序模型。

1. 先看清消息经过的几段路

Planner Node                         Control Node
   │
   │ ① 生成 joint target、seq、stamp
   │
   ├── ② rclcpp Publisher::publish()
   │          │
   │          ▼
   │    RMW / DDS（匹配QoS、缓存与传输）
   │          │
   │          └──────────────────► ③ 消息变为可获取
   │                                  │
   │                             ④ Executor 发现就绪
   │                                  │
   │                             ⑤ 调用 Subscription 回调
   │                                  │
   │                             ⑥ 检查时效、状态与限幅
   │                                  │
   │                             ⑦ 交给控制接口
   │                                  │
   │                             ⑧ 控制循环 / 驱动写入
   │                                  │
   ◄────────────── ⑨ 关节状态或异常反馈 ────┘

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

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

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

Switch 的运行状态由已经完成的初始化和管理操作共同形成。XML 描述期望配置，C 代码表达软件动作，运行时寄存器与表项反映当前硬件状态。看见配置值、找到 API 名称和确认配置已经生效，是三件不同的事。 沿着配置消费、构建、执行、硬件访问和读回建立连续关系，才能解释它们之间的差异。

本文是车载以太网 Switch 专栏的第三篇，结合硬件连接与二层转发，说明配置生效、UMSD/MDIO 管理与 AUTOSAR 集成。所有代码均为自行构造的示意代码，不引用内部驱动、配置原件或专有寄存器序列。

运行时测量可以分成三个职责：平台产生执行事件，核心维护时间归属，报告路径输出统计结果。显式的分工使同一个算法可以在 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 实现的统一规定。具体项目还应遵循所使用组件的多核部署和并发访问约束。