RTE 提供了多种标准接口类型，在 AUTOSAR 的 arxml 配置文件中通过不同 XML 元素声明。日常开发中最常用的是以下三种：
1 Sender-Receiver（SR 通信）：信号传递的标配
SR 接口是 AUTOSAR 中使用最广泛的通信方式，专门用于“信号传递”——就像快递员把包裹从一个地方送到另一个地方。
在 SR 通信中，存在：
- 发送方（PPort）：负责生产数据的一方，通过 Rte_Write() 把数据“发送”出去
- 接收方（RPort）：负责消费数据的一方，通过 Rte_Read() 从 Buffer 中读取数据
SR 通信又分为显式（Explicit）和隐式（Implicit）两种方式，这个区别在实际开发中非常重要：
| 特性 | 显式通信（Explicit） | 隐式通信（Implicit） |
| arxml 定义 | DATA-SEND-POINT | Data read/write access |
| 生成代码 | 函数调用（Rte_IWrite） | 宏定义（Rte_IRead） |
| 是否支持队列 | ✅ 支持 | ❌ 不支持 |
| 适用场景 | 数据需要异步传输、多包缓冲 | 周期性强一致性数据（如 CAN 信号组） |
| 数据一致性 | 在函数调用时读取 | 在 Runnable 入口自动复制到本地 Buffer |
隐式通信为什么能保证一致性？因为 RTE 在 Runnable 开始执行前，会把要读取的所有信号一次性复制到该 Runnable 的本地缓存中——在整个 Runnable 执行过程中，外部对 Buffer 的写入不会影响本地缓存的数据，从而保证了数据的“时间一致性”。
这解决了一个实际问题：一帧 CAN 报文包含 8 个信号，在一个 Runnable 处理这 8 个信号的过程中，如果其中一个信号被外部更新了（新的报文到达），会导致 8 个信号的“时间戳”不一致。隐式通信彻底避免了这个问题。
2 Client-Server（CS 通信）：函数调用的桥梁
CS 接口用于“函数调用”——不是传递数据，而是执行一段逻辑。
典型应用如看门狗喂狗服务：应用 SWC 调用 Rte_Call_WdgM_Checkpoint()，触发 WdgM 模块的检查点函数执行。如果检查通过，WdgM 认为系统“运行正常”，继续正常运行；如果超时，WdgM 触发系统复位。
CS 通信的特点：
- 调用方是 Client（客户端），被调用方是 Server（服务器）
- 可以是同步（调用后等待返回）或异步（调用后立即返回，通过回调通知结果）
- Server 端可以有队列，防止高频调用丢失
SR 和 CS 的核心区别一句话总结：SR 传的是数据，CS 调的是功能。在配置 arxml 时，先判断这个交互是“传递数据”还是“触发函数”，就能决定用哪种接口。
 agent和组件)