一、诊断管理概述
在AUTOSAR架构中，通常情况下诊断管理模块（通常称为DCM，即Diagnostics Communication Manager）位于服务层，它与其他基础模块和服务（如通信管理、内存管理等）协同工作，为上层应用提供统一的诊断服务接口。DCM模块是整个诊断系统的核心，它负责处理诊断请求和响应，管理诊断会话，执行安全访问控制，并且与控制单元的其他部分（如应用软件、BSW其他模块以及硬件资源）进行交互。
其中，在相互协同上，DCM通过标准化的接口与应用层交互，同时又依赖于BSW的服务，如通过NVM进行故障码存储和读取，并通过网络管理服务进行数据传输。过程中DCM负责管理诊断会话的状态，根据不同的会话类型（如默认会话、编程会话）激活或停用某些服务。同时，又与安全访问管理模块协同，根据错误计数器的状态决定是否允许执行特定操作。
如在进行诊断测试时，其交互方式大致过程是，外部测试工具发送UDS请求，DCM接收到请求后，解析服务ID和服务参数，并根据服务类型调用相应的处理函数。对于‘Read Data By Identifier’服务，DCM会查询RTE提供的接口，获取指定DID的数据，对于‘Write Data
By Identifier’则需要更新应用软件或BSW的状态，并确认写入成功。在执行敏感操作前，DCM可能需要与DEM和FIM协同，进行安全访问验证，确保请求来自授权源。待处理完请求后，DCM构建响应报文，并通过通信栈发送回测试工具，从而完成诊断交互。
二、诊断管理系统开发关键步骤
在基于CAN总线的诊断管理模块的开发过程中，具体标准、要求请以主机厂相关标准、ISO 11898、ISO 15765、ISO14229、ISO 15031等进行。
在产品开发过程中，关键的一些步骤有：
2.1.需求分析与定义
根据相关主机厂的诊断需求、相关标准文献及规范，明确诊断功能需求、数据标识符（DID）、服务支持范围、安全访问策略、响应机制、诊断会话管理、数据管理、故障管理、网络管理、通信类型等内容。如根据ISO 15031-6，将DTC划分为车身、底盘、动力和网络四个类别，其对应的故障码等内容如下：
2.2.架构设计与模块划分
2.2.1.诊断管理系统总架构概述
将诊断管理系统按层级划分为应用层（Application Layer）、服务管理层（Service Layer）、数据管理层（Data Layer）、网络通信层（Network Communication Layer）、以及硬件抽象层（Hardware
Abstraction Layer）。
其中，应用层负责提供具体诊断服务的逻辑实现，如读取故障码、清除故障信息、数据标示符读写等，并执行相应的故障管理策略。服务管理层实现统一诊断服务（UDS）的调度与控制，包括会话管理、安全访问控制、消息解析与生成等。数据管理层管理所有与诊断相关的数据存储、读写操作，包括DTC（故障诊断码）存储、默认与非默认会话状态信息等。网络通信层负责不同网络（如Body CAN、Dynamic CAN、Propulsion CAN）上的消息传输，确保诊断消息的准确无误传输。硬件抽象层隔离上层软件与底层硬件的具体实现细节，提供统一的接口用于访问ECU硬件资源。
2.2.2.模块设计通用要求
1）通用要求
2）实现与配置方式
在AUTOSAR开发环境中，创建DCM软件组件，定义其接口和行为模式；
集成符合ISO 15765的通信栈，以支持UDS协议在CAN总线上的传输；
利用AUTOSAR工具配置DCM参数，如诊断地址、服务支持列表、安全访问策略等。
3）测试与验证
开发诊断测试用例，确保DCM模块的功能正确性，包括诊断服务的正向和反向测试、安全性验证、通信时序验证等。
2.2.3.应用模块
诊断系统的应用模块是实现车载故障检测、判断与执行的直接部分，其通常包含数据接收、数据处理与分析、系统运行逻辑等几部分，此部分功能的实现通常以主机厂需求或企业自定义为主，并结合相关标准与法规对故障过程实施合理的管理。
2.2.4.诊断管理模块架构
诊断管理模块基于AUTOSAR架构，确保其作为独立的服务层组件，能够与应用层、通信管理层及底层硬件等有效交互。模块按其实现功能，再划分为诊断服务管理模块、网络与协议处理模块、辅助功能模块等子模块。
在诊断服务管理模块中，其还包含有：
故障管理子模块：负责DTC的记录、分类、存储与清除，并支持故障码的读取服务；
数据访问子模块：实现读写等服务，提供对控制单元内部数据的访问能力，如默认配置设定、VIN码等，并确保数据即时保存至非易失性内存；
安全访问子模块：按照ISO
14229标准，实施安全级别验证，如安全检查0x27服务，保护敏感操作不被非法访问，以确保诊断操作的安全性。
网络与协议处理模块包含如下内容：
消息结构处理子模块：负责构造和解析诊断请求与响应消息，依据ISO 15765-2定义的消息格式，处理请求服务标识符、子功能参数等。支持单帧与多帧数据传输协议，确保数据完整且高效传输，适应不同大小的数据包需求；
多网络支持子模块：确保控制单元在连接到多个网络时，基于网络拓扑和带宽考虑，自动选择最优网络进行诊断通信；
唤醒与通信控制子模块：管理控制单元的唤醒机制，确保在唤醒或首次网络活动后的规定时间内响应诊断请求。
辅助功能模块包含内容如下示意：
模拟与控制子模块：提供标准化接口，模拟输入信号并控制输出，以支持离线诊断和功能测试，使外部测试工具无需下载额外代码即可进行全面诊断操作；
配置管理子模块：管理控制单元的配置参数，包括默认值设定、配置参数的读写等，可记录并报告DTC，支持故障码清除与状态监测；
故障诊断例程子模块：提供特定诊断例程的执行，如动力系统性能测试、网络通信测试等。
基于CAN总线的诊断管理模块开发时，确保其遵守ISO 15765-2规定的网络层定时参数，以保证通信的可靠性。同时根据诊断服务的不同，设定合理的响应时间，以提升系统的性能。如：
2.2.6.测试与验证
测试过程分为单元测试以及集成测试。单元测试即以单点控制单元为测试对象，针对每个服务进行测试，以验证数据读写、会话控制、安全访问等功能的正确性。集成测试是通过整车网络，对DCM模块进行测试，以验证其在实际网络环境下的表现。测试过程中，子模块间的交互示意如下：
诊断服务管理模块向数据管理层请求或更新数据，通过网络通信层发送或接收诊断消息，网络与协议处理模块在接收到诊断请求时，通知诊断服务管理模块进行相应的服务处理，并通过硬件抽象层与控制单元的硬件交互。辅助功能模块在需要时被调用，支持特殊诊断场景或功能测试，其结果将反馈至数据管理层或直接用于诊断响应。
三、总结
在新能源汽车用电器数量增加、电子电气结构趋于高集成的背景下，故障管理系统不仅是确保车辆正常运行和安全性的重要手段，也是提升整体服务质量和用户体验的关键环节。本文以某项目开发为背景，对故障管理系统开发过程中的一些关键点进行梳理，以便诸君参考。其他相关细节、功能，请根据实际项目具体而定。
