AUTOSAR架构诊断功能类似于VxWorks653的HM和OMS功能。 AUTOSAR的诊断功能包括两部分： ①在线诊断模式（Onboard Diagnostic System）， 易于被用户感知的仪表故障灯显示，在线诊断系统对ECU的软硬件及各传感器参数进行某些常见故障的实时监控与发现，当系统判断电控系统出现故障时，会以仪表警示灯亮的形式来告知驾驶者(类似于DS的FDAS功能)，并在ECU的EEPROM或Flash内对相关DTC（Diagnostic Trouble Codes）进行存储，以便后续车辆被送至售后处，工程师对其进行故障检测时读取分析处理（类似OMS功能）。 ②离线诊断模式（Offboard Diagnostic System），即将外部设备接在OBD诊断口上与整车网络各ECU进行通讯，以对各模块数据实行监控与检测分析。诊断设备通过发送满足诊断协议定义的诊断服务来实现诸如对已存储DTC的读取与清除，利用其他的整车控制指令来实现对车辆的动静态控制。

 目前OEM在产品前期开发及售后过程中最常见的两种通信工具有美国英特佩斯公司的NeoVI fire(目前已有fire 2)/ RED + Vehicle SPY3及Vector的CANoe CAN。 外部测试工具如何对总线ECU发起合法消息请求并进行正常通讯，并按照规则解析出反馈报文的含义，则需要参考整车网络架构中应用层的诊断通信协议定义。 两个最常见且较有代表性的诊断体系标准： ISO 15765
Road Vehicles-Diagnostics on Controller Area Network，是车辆基于CAN诊断的标准协议。通讯方面开发能力强的公司会进行协议定制，如北美通用（GM）在ISO 15765-2的基础上进行定制化开发出应用于Service Layer及Transport Layer的GMLAN，该协议也被其他某些厂家采用。

ISO 14229
ISO 14229，也就是近年常被行业内提及的UDS protocol（Unified Diagnostic Service）。标准中定义出了诊断服务在数据链路上的独立需求。通过标准化的诊断服务，用户可以使用诊断工具（Client端）直接控制ECU（Server端）的电子燃油喷射、节气门转角、转速、ABS系统、EPS模块等（是否能联想到某前瞻扩展领域的应用）。
  有了争端通讯协议，接下来说说诊断的两大功能： ①DEM:故障诊断事件管理 ②DCM:故障诊断通信管理 需要明白一个名词：DTC（Diagnostic Trouble Codes） （1）DEM则负责直接处理与DTC相关的诊断服务，例如UDS中的0x19（读取故障码）及0x14（清除故障码）的服务，在ECU运行过程中，Monitor Function会进行持续的status检测，一旦出现疑似故障时，会直接调用DEM来进行故障check，确认后即可完成将诊断故障数据写入到EEPROM或者Flash中的过程。对于在线诊断模式（Onboard Diagnostic System），SWC在从DEM中读取到故障信息的同时，会将以故障灯的形式告知驾驶人员。 （2）DCM支持ISO 14229-1标准，主要负责确保诊断通信数据流，及包括安全访问在内的诊断状态控制，因此支持0x10(Session Control)、0x27(Security Access)。当总线给该ECU发送UDS协议中定义的诊断请求指令时，DCM会调用DEM、SWC或者是其他基础软件模块提供的接口进行如诊断请求判断、诊断功能执行以及响应的反馈。

具体实现上，DCM分成三个子模块:

诊断服务处理器（Diagnostic Service Processing, DSP）

DSP位于DCM的最上层，可理解为一个包含了通用性诊断服务的容器，用于处理各应用间共性的服务，如故障相关信息等数据的处理。当DSD完成诊断请求处理并且将请求转发出来后，DSP对该消息进行处理。

诊断服务调度器（Diagnostic Service Dispatcher, DSD）

DSD位于DCM中间层，当接收到诊断请求后，会将请求转发给DSP。同样，在DSP完成诊断请求处理后，也会将响应转发出来。

诊断会话层（Diagnostic Session Layer, DSL）

DSL位于DCM最底层，主要负责接收模块上传的诊断请求并最终发送出诊断响应数据，并管理、确保诊断协议的Timing以及诊断状态。 参考：http://bbs.cirmall.com/thread-50517-1-1.html