4. 通信栈架构
AUTOSAR通信栈是整车软件中负责“把信号从应用层送到总线、再从总线送回应用层”的完整软件集合。它并不是单一模块，而是由服务层、ECU抽象层、微控制器抽象层以及复杂驱动共同构成的分层体系。理解通信栈的关键，不是记住模块名称，而是看清每一层“为谁服务、暴露什么接口、数据以什么形式流动”。
一、分层结构：从应用到硬件的四段式
通信栈自上而下可划分为四个逻辑段：应用层、服务层、ECU抽象层、微控制器抽象层。应用层通过RTE访问通信服务；服务层包含Com、PduR、CanIf、CanTp、Dcm、Dem等模块，负责信号打包、路由、诊断与错误管理；ECU抽象层包含CanIf、LinIf、FrIf等，屏蔽具体控制器差异；微控制器抽象层包含Can、Lin、Spi等驱动，直接操作寄存器与硬件对象。复杂驱动可绕过部分层级直接访问硬件，用于特殊时序或高实时场景。
二、各模块职责与接口关系
Com模块是通信栈的“信号中枢”，负责信号的打包/解包、超时监控、更新位与发送模式控制。PduR是“路由表”，根据PduId把上层PDU分发到CanIf、CanTp、LinIf或FrIf。CanIf是CAN抽象接口，管理硬件对象、发送缓冲与接收指示。CanTp负责ISO-TP分段与重组，支撑诊断长帧。Can驱动则完成报文收发、中断处理与硬件过滤。接口关系上，Com调用PduR_Transmit，PduR调用CanIf_Transmit，CanIf调用Can_Write，形成一条清晰的调用链。
三、数据流：发送与接收的双向路径
发送方向：SWC调用Rte_Write写入信号，Com按配置周期或事件触发打包成PDU，调用PduR_Transmit；PduR根据路由表选择CanIf，CanIf将PDU写入硬件对象并触发Can驱动发送。接收方向则相反：Can驱动中断接收报文，CanIf做接收指示，PduR路由到Com，Com解包并更新信号，RTE通知SWC读取。诊断数据流则走CanTp与Dcm，形成独立于应用信号的通道。
关键接口调用链：
Rte_Write(Signal)
→ Com_SendSignal()
→ PduR_ComTransmit(PduId)
→ CanIf_Transmit(TxPduId)
→ Can_Write(Hth, PduInfo)
→ CAN控制器发送四、案例场景：车门信号从采集到总线
以车门开关信号为例：车门SWC采集到“门开”状态，通过Rte_Write写入Com信号；Com按10ms周期打包为PDU，经PduR路由到CanIf；CanIf选择硬件对象HTH_0，调用Can_Write发送到CAN总线。接收端BCM的Can驱动收到报文后，CanIf指示接收，PduR路由到Com，Com解包后RTE通知BCM应用读取。整个过程涉及信号映射、PduId路由、硬件对象选择三个关键配置点。
五、常见误区与复盘
- 误区一：认为Com直接调用Can驱动。实际上中间必须经过PduR和CanIf，否则无法实现多总线路由与硬件抽象。
- 误区二：忽略PduR的路由表配置。PduId与目标模块的映射错误，会导致报文“发不出”或“收不到”。
- 误区三：把CanTp与Com混用。诊断长帧必须走CanTp，应用信号走Com，两者PDU类型不同。
- 复盘建议：集成时先确认调用链是否完整，再检查PduId映射，最后用CANoe或示波器验证总线波形。
| 层级 | 典型模块 | 核心职责 | 关键接口 |
|---|---|---|---|
| 服务层 | Com、PduR、CanTp、Dcm | 信号打包、路由、诊断 | Com_SendSignal、PduR_Transmit |
| ECU抽象层 | CanIf、LinIf | 硬件对象管理、发送缓冲 | CanIf_Transmit、CanIf_RxIndication |
| 微控制器抽象层 | Can、Spi、Port | 寄存器操作、中断处理 | Can_Write、Can_Read |
| 复杂驱动 | CDD | 特殊时序、高实时外设 | 直接硬件访问 |
集成提示：通信栈配置工具通常生成Com、PduR、CanIf、Can四份配置代码。集成时务必保证PduId在四层之间一致，否则数据流会在某一层“断链”。建议用总线仿真工具逐层打点验证。
排障提醒：若应用信号无法发出，优先检查Com的发送模式是否被禁用、PduR路由是否使能、CanIf硬件对象是否被占用、Can控制器是否处于Bus-Off状态。四层中任意一层异常，都会表现为“总线无报文”。
掌握通信栈的分层结构、模块职责与数据流，是后续配置Com、PduR、CanIf和Can驱动的基础。只有把调用链和PDU路由关系理清，才能在集成阶段快速定位问题，避免“改一层、坏三层”的连锁故障。