引言
故障诊断系统中，诊断通讯管理模块（Diagnostic Coummunication Management，Dcm）主要实现UDS和OBD的诊断服务，即处理诊断数据流和管理诊断状态，包括诊断会话和安全状态，检查诊断服务的请求是否满足条件等功能。
本文主要介绍Dcm模块的UDS服务(Unified Diagnostic Services，统一诊断服务)，UDS服务是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又发什么指令。下文将说明以下几块内容：
- UDS服务的应用介绍；
- UDS服务的基本概念；
- UDS服务的层次关系；
- UDS服务单元的介绍。
1 UDS服务的应用介绍
假如车窗系统出现故障，维修人员会先使用诊断设备去检测，了解清楚具体是什么故障，再决定怎么维修，那么在这个维修过程，就需要使用到UDS服务。
首先，维修人员可能会利用UDS的读写相关服务去获取软、硬件版本号，供电电压等，以获取一些最基本的信息；再利用UDS的查看故障码相关的服务，了解具体出现了什么故障，比如出现电机故障，想亲自感受下电机的故障，这时可以使用UDS的例程控制服务去控制开启电机。当发现这个故障在旧版本的软件都存在，新版本的软件已经修复了这些故障，那么使用UDS的刷写服务更新软件。当然这个过程所使用的这些UDS服务都是通过诊断设备发送的，所使用到的服务如下示意。
2 UDS服务的基本概念
UDS服务分为6类功能，26种服务，分别是：
1）诊断和通信管理功能单元，包括10，11，27，28，3E，83，84，85，86，87共10种服务；
2）数据传输功能单元，包括22，23，24，2A，2C，2E，3D共7种服务；
3）存储数据传输功能单元，包括14，19共2种服务；
4）输入输出控制功能单元，包括2F服务；
5）例行程序功能单元，包括31服务；
6）上传下载控制功能单元，包括34，35，36，37，38共5种服务。
下文将介绍以下：诊断会话相关服务$10和$3E，安全访问服务$27，诊断相关服务$14和$19， 读写数据相关服务$22和$2E，刷写软件相关服务$31，$34，$36和$37。
不过在介绍这些服务前，先了解服务请求/响应行为的定义，就是客户端Tester和服务端ECU怎么使用UDS服务进行通讯。当客户端请求服务SID，服务端需要响应，有两种响应：一类是正响应，另一类是负响应。正响应规定响应格式必须是请求的SID+40，即请求SID为10，则响应SID为50；请求SID为27，则响应SID为67。负响应规定响应格式必须是7F SID NRC，与正响应不同，这里SID仍为请求的SID，即请求SID为10，那么响应SID仍为10。NRC可理解为什么不能提供正响应的原因，比如说请求的SF不支持，请求的长度不对，等等原因。
3 UDS服务的介绍
在具体介绍每块UDS服务之前，先说明下UDS服务的层次关系，即UDS服务需分3个层次：首先是确定在什么诊断会话模式（$10），即是默认会话，还是扩展会话，还是编程会话；在此基础上，再明确是否需要使用安全访问服务（$27）解锁，有些功能服务需要通过该服务解锁才能使用，有些则不需要考虑该服务；最后才能实现具体的服务控制。
3.1诊断会话相关服务
诊断会话相关服务被用来使能服务端中的不同诊断会话模式，诊断会话模式分为两大类：默认会话和非默认会话，其中非默认会话又包括编程会话和扩展会话。不同的会话模式下服务的使用权限不同，且能使用的服务有区别。默认会话是指ECU在刚上电时保持的会话状态，其服务的使用权限小，即可操作的功能单元服务少，比如不能使用27，28，83，84等服务；编程会话主要使用与刷写程序相关的诊断服务，比34，36，37等服务；而扩展会话相较于默认会话，其使用服务的权限大，即可操作的功能单元服务多，默认会话模式下不能使用的服务，在扩展模式下都能使用。
诊断会话控制服务，即$10，采用请求格式是SID+SF(sub-function,子功能)，请求默认会话模式，则客户端发送10 01；请求编程会话模式，则发送10 02；请求扩展会话模式，则发送10 03。关于诊断会话模式的切换处理，如下图所示：
当ECU上电时，ECU总是从默认会话模式开始，当非默认会话被激活，比如请求10 03扩展会话，ECU则进入扩展会话，如果待机握手服务$3E或其他服务被激活，则保持在当前会话模式，如果S3定时器超时或请求10 01默认会话，则会进入默认会话。
3.2 安全访问服务
当了解诊断会话相关服务后，比如当前在扩展会话，那么在使用某个功能服务前，就需要清楚是否需要解锁，即是否使用$27服务。该服务是为了保证访问数据服务和某些诊断服务所需的保密或安全，其实现机制是：先客户端（也叫测试端）请求种子，再服务端（ECU）发送种子，然后客户端根据种子按事先约定的加密算法计算密钥，发送密钥，最后服务端将发送密钥与预期的密钥对比，两者一致则说明验证有效，解锁，大致过程如下示意。
这里，不同会话模式会使用不同的子功能SF，且可能使用不同的加密算法，比如扩展会话使用27 01, 27 02，编程会话使用27 03, 27 04。
3.3 其他服务
3.3.1诊断相关服务$14和$19
故障诊断中，$14和$19服务用于操作存储在ECU中的DTC，其中$14服务是清除故障服务，其请求格式为：SID+ groupOfDTC(3字节)，正响应为：54。一般使用都14 FF FF FF，表示清除ECU中所有的DTC；而$19服务是用于读取存储在ECU中的DTC，其请求格式为：SID+ SF+Parameter，这里SF代表了各种各样读取DTC的方法，比如SF=0x01代表读取符合特定条件的DTC数量，具体可以查阅ISO 14229的定义。
3.3.2 读写数据相关服务$22和$2E
读取数据服务（$22）是根据Data Identifier（即DID）去请求读取数据，其请求格式为SID+DID。
注意DID表示存储数据的地方，一般存储整车厂和零件供应商定义的数据，包括模拟输入和输出信号（比如转速信号），数字输入和输出信号（比如车门信号），内部数据和系统状态信息等，这里请求的DID可以是一个，也可以是多个。
写入数据服务（$2E）是根据DID去请求写入数据，其请求格式为SID+DID+Data。这里一次只写一个DID的数据，不像读取数据服务（$22）可以一次读取多个DID的数据。通过该服务可以：写入一些配置信息到ECU（比如VIN码），清除非易失性数据，重置学习值等。
3.3.3 刷写软件相关服务$31，$34，$36和$37
软件刷写就是要把目标软件烧录到ECU芯片内存规定的区域。在刷写前必须做一些准备工作，比如先擦除目标刷写区域，再ECU需要检查能否下载。具体刷写则按照传输规则进行，当传输完毕，再验证checksum值。这里将会使用到$31，$34，$36和$37服务。
$31服务是例程控制服务，其指客户端请求服务端开始，停止一个例程或请求例程结果，主要用来擦除内存、复位或自学习等功能。它的请求格式为：SID+SF+RID+非必须选项；例程控制的正响应格式为：（SID+40）+SF+RID+非必须选项。这里开始以一个基本的刷写过程为例：假设需擦除内存的从地址0xA0000000开始，大小为0x00010000的信息，执行完例程控制后，目标位置的信息成功擦除，如下所示：
客户端Tester: 31 01 FE 00 00 A0 00 00 00 00 01 00 00
服务端ECU: 71 01 FE 00 01
$34服务是请求下载服务，其在擦除成功后，从客户端发起一个数据传输到服务端，服务端接收到请求后，将会做一系列的动作，检查是否能下载，正常则正响应给客户端，如下所示：
客户端Tester: 34 00 44 A0 00 A0 00 00 00 00 01 00 00
服务端ECU: 74 20 0F 00
当客户端接收到请求下载的正响应，则说可以开始传输数据，那么客户端将按照每次0x0F00的数据量传输数据（$36），这样刷写文件的数据就会按照一一对应的地址逐块地被刷写到内存中，当数据刷写完毕，则请求传输退出（$37）。数据传输过程如下所示：
客户端Tester: 36 01 xx xx xx ....... xx xx xx
服务端ECU: 76 01
客户端Tester: 36 02 xx xx xx ....... xx xx xx
服务端ECU: 76 02
......, 当数据传输完毕，则：
客户端Tester: 37
服务端ECU: 77
最后请求$31服务验证Checksum。
客户端Tester: 31 01 FE 01 44 80 00 80 00 00 00 FF 00 DA E5 12 41
服务端ECU: 71 01 FE 01
以上概述Dcm的UDS服务，关于各服务使用细节，可见参考文章。
Reference:
[1] https://zhuanlan.zhihu.com/p/37310388
[2] A brief introduction to the diagnostic protocol UDS(ISO 14229) Vector.pdf
[3] https://www.zhihu.com/column/c_137983690
