3. AUTOSAR诊断架构总览

在AUTOSAR分层架构中，诊断通信并不是单一模块独立完成的功能，而是由应用层、服务层、ECU抽象层和通信抽象层多个模块协同实现。理解这些模块的职责边界与交互路径，是后续学习诊断服务配置、故障事件管理、传输协议调优和刷写流程设计的基础。本节以经典平台与自适应平台共有的诊断栈为主线，梳理DCM、DEM、FIM、DET、CAN TP、DoIP等核心模块的定位与协作关系。

一、核心模块职责划分

AUTOSAR诊断架构可以按“服务处理—事件管理—功能抑制—传输承载—开发诊断”五个维度理解。每个模块只解决一类问题，模块之间通过标准化接口交互，避免诊断逻辑散落在应用代码中。

从职责看，DCM是诊断服务的“总调度”，DEM是故障数据的“账本”，FIM是功能可用性的“闸门”，DET是开发阶段的“报警器”，CAN TP与DoIP则是诊断报文在不同物理介质上的“运输通道”。它们共同构成从总线报文到应用功能的完整诊断链路。

二、模块交互关系与数据流

当诊断仪发送一条UDS请求时，报文首先经过CAN驱动或以太网驱动，再由CAN TP或DoIP完成传输层重组，随后交给DCM。DCM根据服务标识符判断是会话控制、安全访问、读写数据还是例程控制，并调用相应的服务处理函数。若请求涉及故障码读取，DCM会通过DEM接口获取DTC状态；若涉及功能抑制状态，则可能查询FIM。DEM在运行过程中持续接收来自SWC或BSW的事件上报，更新事件状态并决定是否存储DTC。DET则贯穿各模块，在开发配置下捕获非法调用。

图中可以看到，诊断请求自下而上进入DCM，诊断事件与抑制状态则在服务层内部横向流动。CAN TP与DoIP位于DCM之下，对上层屏蔽了CAN多帧与以太网路由的差异。DET以虚线方式贯穿各层，表示它主要面向开发阶段，不参与量产诊断服务的正常响应。

三、典型场景：读取故障码并判断功能抑制

假设诊断仪通过CAN发送服务0x19 02，请求读取当前故障码。报文经CAN TP重组后交给DCM，DCM解析服务标识符并调用DEM接口。DEM返回已存储的DTC列表及其状态字节，DCM将其封装为肯定响应。若某个DTC同时触发了FIM抑制条件，FIM会向相关SWC输出功能禁止信号，例如禁止某执行器动作。此时诊断仪读取到的DTC状态与车辆实际功能表现需要一致，否则说明DEM事件配置或FIM映射存在偏差。

诊断请求: 19 02
CAN TP重组后: 03 19 02
DCM处理: 读取DEM DTC状态
DEM返回: DTC1 status=0x2F, DTC2 status=0x08
DCM响应: 59 02 2F 08 ...
FIM动作: 若DTC1满足抑制条件，禁止功能A

这个场景说明，DCM负责“问答”，DEM负责“记录”，FIM负责“执行抑制”，三者必须通过一致的DTC编号和事件映射关联起来。任何一处配置错误，都会导致诊断结果与整车行为不一致。

四、常见误区与复盘要点

复盘时建议按“物理层—传输层—DCM—DEM/FIM—应用层”的顺序逐段排查：先确认CAN或以太网链路是否正常，再确认CAN TP或DoIP是否完成重组，然后检查DCM服务配置，最后核对DEM事件与FIM抑制映射。这样可以把复杂问题定位到具体模块，而不是在整车层面反复猜测。