1. 课程导入与AURIX诊断系统概览
欢迎进入《英飞凌AURIX车载诊断系统开发与整车故障管理》课程。在开始接触寄存器、诊断栈和故障码之前，我们需要先建立一张"全局地图"：诊断系统在整车电子电气架构中处于什么位置，AURIX TC3xx微控制器为诊断提供了哪些硬件资源，软件上又由哪些模块协同完成一次诊断交互。只有把这张地图看清楚，后续的配置、编码和排障才不会变成零散知识点的堆砌。
1.1 学习目标
完成本课程后，学习者应能够独立完成以下任务：理解车载诊断在法规与整车功能两个层面的定位；掌握AURIX TC3xx中与诊断相关的硬件资源及其访问方式；能够基于AUTOSAR诊断栈或英飞凌提供的驱动，搭建一条从诊断仪到应用层的完整数据通路；能够实现UDS服务处理、DTC管理与故障去抖；能够分析诊断通信异常并定位到具体层级。本课程强调"可执行"，因此每一章都会给出具体的对象、参数、代码片段或判断依据，而不是停留在概念描述。
1.2 车载诊断系统在整车EEA中的位置
现代整车的电子电气架构（EEA）通常由若干域控制器、网关和大量末端ECU组成。诊断仪（外部测试设备）通过OBD接口接入，经网关路由，最终到达目标ECU。对于AURIX这类作为域控制器主控芯片的场景，诊断链路可以概括为：诊断仪 → OBD接口 → 网关 → CAN/CAN FD或以太网 → 目标ECU的通信控制器 → AURIX内部诊断栈 → 应用层故障处理。
这条链路上，AURIX承担的是"最后一公里"的角色：它既要完成物理层与数据链路层的收发，也要完成网络层、传输层、会话层和应用层的协议处理。理解这一点非常关键——当诊断仪报"无法连接"时，问题可能出在网关路由、总线物理层、AURIX通信控制器配置或诊断栈状态机中的任意一环。后续章节会逐层拆解，但本节先建立整体认知。
从法规角度看，排放相关的OBD-II、重型车的WWH-OBD以及面向全车的UDS（ISO 14229）共同构成了诊断的规范基础。AURIX诊断系统开发的核心工作，就是把ISO 14229定义的服务映射到具体硬件与软件资源上。
1.3 AURIX TC3xx诊断相关硬件资源
AURIX TC3xx系列（如TC397、TC387、TC377等）为诊断提供了丰富的片上资源，主要包括以下几类：
- 多路CAN/CAN FD节点：TC3xx通常集成多个MCMCAN模块，每个模块支持多路CAN通道，可分别连接动力、底盘、车身等不同总线。诊断报文通常走其中一路，需在配置阶段明确通道分配。
- 以太网MAC：部分型号集成千兆以太网MAC，支持DoIP（Diagnostic over IP，ISO 13400），适用于高带宽诊断场景，如软件刷写。
- DMA与中断：诊断报文收发频繁，使用DMA搬运可降低CPU负载；中断用于及时响应诊断请求。
- Flash与数据存储：DTC、冻结帧、扩展数据需要非易失存储。TC3xx的PFlash/DFlash以及外部EEPROM都可作为候选，需根据擦写寿命和访问速度权衡。
- 安全硬件：HSM（Hardware Security Module）用于诊断安全访问（Security Access）的加解密运算，支持Seed-Key机制。
- 看门狗与复位管理：诊断会话中若发生复位，需能记录复位原因，便于故障追溯。
这些资源并非孤立存在，而是通过系统总线互联。下图给出AURIX TC3xx诊断相关硬件资源与软件模块的整体关系，帮助建立"硬件—驱动—服务—应用"的分层视图。
1.4 诊断相关软件模块总览
在软件层面，AURIX诊断系统通常基于AUTOSAR分层架构组织，也可以使用英飞凌提供的iLLD或MCAL驱动自行搭建。无论采用哪种方式，核心模块的职责是清晰的：
通信驱动层负责CAN帧或以太网报文的收发，处理硬件邮箱、中断和DMA。这一层的关键参数包括波特率、采样点、邮箱数量。以CAN FD为例，仲裁段500 kbit/s、数据段2 Mbit/s是常见配置，采样点通常设在75%～80%。
传输层解决长报文的分段与重组。CAN上使用ISO 15765-2（CAN TP），支持单帧、首帧、连续帧和流控帧；以太网上使用DoIP的传输层。传输层的参数如STmin、BS（Block Size）会直接影响刷写效率，后续章节会详细展开。
诊断服务层即Dcm模块，负责解析UDS请求、维护诊断会话状态机、检查安全访问权限，并调用应用层的回调函数。Dcm的状态机至少包含默认会话、编程会话和扩展会话三种状态，不同状态下允许执行的服务不同。
故障管理模块即Dem模块，负责DTC的状态位管理、去抖计数、冻结帧记录和老化处理。Dem与Dcm通过接口交互，使得0x19服务能够读取故障信息，0x14服务能够清除故障。
应用层是最终使用诊断结果的地方。例如，当某个传感器信号超出范围并持续一定时间后，应用层调用Dem接口上报故障；诊断仪读取到该故障后，维修人员据此判断故障位置。
1.5 一次诊断交互的完整路径
为了把上述分层串起来，我们以一个典型场景为例：诊断仪发送0x22服务（ReadDataByIdentifier）读取VIN码。
- 诊断仪构造请求报文，通过OBD接口发送到网关。
- 网关根据目标地址路由到对应CAN通道，报文到达AURIX的MCMCAN控制器。
- CAN驱动接收报文，经CAN TP重组为完整的UDS请求。
- Dcm模块解析服务ID为0x22，检查当前会话是否允许该服务。
- Dcm调用应用层注册的回调函数，应用层返回VIN数据。
- Dcm构造肯定响应，经CAN TP分段后由CAN驱动发送。
- 诊断仪收到响应并显示VIN。
这个过程中，任何一步出错都会导致诊断失败。例如，若Dcm当前处于默认会话而0x22服务被配置为仅在扩展会话可用，则会返回否定响应0x7F 0x22 0x7F（服务不支持于当前会话）。理解这条路径，是后续排障的基础。