From https://zhuanlan.zhihu.com/p/25198437
随着计算机及嵌入式技术被愈加广泛融入到汽车工程中，整车内的CAN总线网络结构由于ECU的增加愈加复杂，与之正相关提高的是汽车电子开发验证复杂度。
电子控制系统强大的可操控性虽使车辆运行性能较之传统机械猛兽更为迅猛稳定，但同样也对产品前期设计开发，整车的制造生产，及售后工程部门的维修处理方面提出了挑战。因此各OEM迫切需要一套满足高准确性，实时性及高效性的汽车诊断系统，来应对现阶段分离式的软件设计、测试流程。
目前最主要措施之一就是前面介绍过三次的AUTOSAR（Automotive Open System Architecture,汽车开放系统架构），主流整车制造商及零部件供应商希望对ECU 嵌入式软件架构进行规划统一来实现车辆故障诊断的标准化。
「车辆诊断」定义
对于整车厂而言，诊断分为两类，易于被用户感知的仪表故障灯显示隶属主机厂采用的在线诊断模式（Onboard Diagnostic System），通过车内模块自带的在线诊断系统对ECU的软硬件及各传感器参数进行某些常见故障的实时监控与发现，当系统判断电控系统出现故障时，会以仪表警示灯亮的形式来告知驾驶者，并在ECU的EEPROM或Flash内对相关DTC（Diagnostic Trouble Codes）进行存储，以便后续车辆被送至售后处，工程师对其进行故障检测时读取分析处理。值得记住的是，在线诊断技术首先由通用汽车引入。
诊断第二种类型为离线诊断模式（Offboard Diagnostic System），即将外部设备接在OBD诊断口上与整车网络各ECU进行通讯，以对各模块数据实行监控与检测分析。诊断设备通过发送满足诊断协议定义的诊断服务来实现诸如对已存储DTC的读取与清除，利用其他的整车控制指令来实现对车辆的动静态控制。
目前OEM在产品前期开发及售后过程中最常见的两种通信工具有美国英特佩斯公司的NeoVI fire(目前已有fire 2)/ RED + Vehicle SPY3及Vector的CANoe CAN。
工厂制造环节中因可能需要进行整车ECU的批量在线刷新而选择其他支持并行刷新及测试的设备，具体何种这里不作介绍。
至于外部测试工具如何对总线ECU发起合法消息请求并进行正常通讯，并按照规则解析出反馈报文的含义，则需要参考整车网络架构中应用层的诊断通信协议定义。
诊断协议标准
参照互联OSI 7层模型，把目前整车网络中最常用的ISO（International Standards Organization）与SAE（Society of Automotive Engineers）两套标准协议做出如下归类：
简单介绍两个最常见且较有代表性的诊断体系标准，若需要可自行检索下载阅读：- 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模块等（是否能联想到某前瞻扩展领域的应用）。
AUTOSAR诊断重要组成
介绍过AUTOSAR的软件架构，AUTOSAR诊断功能模块主要实现部分为ECU软件中的故障诊断事件管理(DEM)以及故障诊断通信管理(DCM)，通讯接口如图所示：
故障诊断事件管理DEM
DEM则负责直接处理与DTC相关的诊断服务，例如UDS中的0x19（读取故障码）及0x14（清除故障码）的服务，在ECU运行过程中，Monitor Function会进行持续的status检测，一旦出现疑似故障时，会直接调用DEM来进行故障check，确认后即可完成将诊断故障数据写入到EEPROM或者Flash中的过程。对于在线诊断模式（Onboard Diagnostic System），SWC在从DEM中读取到故障信息的同时，会将以故障灯的形式告知驾驶人员。
故障诊断通信管理DCM
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以及诊断状态。
数据交互及接口如下：
无论是传统汽车电子架构亦或是将来新能源车型的逐步推广，车辆诊断技术在整个汽车产品的设计研发、工厂制造及售后环节中都会起到极其重要的作用。从对K线到CAN，再到不久后的CAN FD以及Ethernet的支持，作为其核心的诊断通信协议也将会随着整车功能的完善及车载总线系统的更新迭代而日益丰富。AUTOSAR的出现，促成了汽车电子软件的高效管理，其中所使用的如UDS的协议同样也将进一步推动汽车诊断领域的标准统一与发展。