转载来自：https://zhuanlan.zhihu.com/p/33742492 来自知乎张丁
UUDS定义的诊断服务从逻辑来说分为以下几类：
- Diagnostic and Communication Management （诊断和通信管理）
- Data Transmission （数据传输）
- Stored Data Transmission （存储数据传输，用于操作DTC）
- InputOutput Control （IO控制）
- Routine Control （不知如何翻译好，作用是调用ECU内部的预置函数）
- Upload Download （上传下载）
UDS规定使用1个byte来表示诊断服务，即所谓的Service ID,简称SID。本文介绍一下Diagnostic and Communication Management 这一类诊断服务中的一部分。
DiagnosticSessionControl (0x10)
DiagnosticSessionControl诊断request的格式
DiagnosticSessionControl这个服务的SID是0x10，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将进入的session。
UDS定义的session包括：
0x00 ISOSAEReserved（保留）
0x01 defaultSession 默认会话
0x02 ProgrammingSession 编程会话
0x03 extendedDiagnosticSession 扩展会话
0x04 safetySystemDiagnosticSession 安全系统会话
0x05 – 0x3F ISOSAEReserved（保留）
0x40 – 0x5F vehicleManufacturerSpecific（由整车厂自定义使用）
0x60 – 0x7E systemSupplierSpecific（由ECU供应商自定义使用）
0x7F ISOSAEReserved（保留）
DiagnosticSessionControl用于控制ECU在不同的session之间进行转换，session可以看作是ECU所处的一种软件状态，在不同的session中诊断服务执行的权限不同。
ECU上电之后，默认处在defaultSession中，在这个session中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。
一般的诊断仪启动之后，会给ECU发送10 03，即让ECU进入 extendedDiagnosticSession中，在这个session中可执行的诊断服务就很多了。
而如果要让ECU保持在non-defaultSession中，则需要诊断仪每隔固定的时间发送0x3E服务，ECU才会知道诊断仪有和自己通信的需求，从而保持在non-defaultSession中。
另一个常用的session是ProgrammingSession，在这个session中可以进行软件刷写的一系列诊断服务。
0x40 – 0x5F 这个范围中的session由整车厂自定义使用，
比如，某些诊断服务或诊断数据的操作需要在生产线上执行，即所谓的End-Of-Line，整车厂可以从这个范围中选择一个值来表示EOL session；
又或者在开发阶段需要某种“超级”session，则也可以从这里选一个值用来使ECU进入开发模式的session。
DiagnosticSessionControl这个服务非常简单，但是它却是ECU和诊断通信的第一条诊断命令。
DiagnosticSessionControl诊断response的格式
这个诊断服务的response分为三部分，第一部分是0x50，作为SID的echo；第二部分是进入的session，作为sub-function的echo；
第三部分是4个字节，前两个字节代表P2Server_max，即ECU在应用层上对诊断命令的响应时间，后两个字节代表P2*Server_max
，即ECU在暂时无法处理当前诊断命令（具体表现为发送了NRC 0X78），在应用层上对诊断命令响应的最长时间。
ECUReset (0x11)
ECUReset 这条指令的用途是通过诊断请求使ECU重启。
ECUReset 诊断request的格式
ECUReset 这个服务的SID是0x11，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将模拟哪种方式进行重启。
常用的sub-function包括（只举2个例子，UDS还定义了很多其他的值）
0x01 hardReset 模拟KL30的重启
0x02 keyOffOnReset 模拟KL15的重启
01硬件重启 02 keyOffOnReset 03 软件重启
当我们通过诊断命令改写了ECU的某些数据，或者对ECU进行了某些设置，只有将ECU重启才能将这些配置生效，所以就有了这个诊断命令。在ECUReset 执行之后，ECU会从Non-defaultsession回退到defaultsession中。
SecurityAccess (0x27)
厂家可能会为ECU定义某些安全级别稍微高一些的诊断服务，在执行此类服务之前，就需要执行SecurityAccess 这个诊断命令，进行一个简单的身份验证。
完成SecurityAccess 有以下步骤：
- 诊断仪向ECU请求“Seed”（通常是一个与时间相关的伪随机数）,
- ECU向诊断仪发送“Seed”(并且这边自己要根据安全算法得出来)
- 诊断仪向ECU发送“Key” (根据请求得到的Seed和一个本地的密码进行计算得来)
- ECU判断诊断仪发来的“Key”是否有效
根据UDS的定义，0x03, 0x05, 0x07 – 0x41 这个范围留给用于requestSeed的sub-function；
0x04, 0x06, 0x08 – 0x42这个范围留给用于sendKey的sub-function。
具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对sub-function，用于不同等级的安全访问。
下面我举一个完成SecurityAccess的诊断命令的例子，假设0x05用于requestSeed，0x06用于sendKey。
诊断仪发送 27 05
ECU响应 67 05 01 01 01（seed是 01 01 01）
诊断仪发送 27 06 02 03 04（key值是02 03 04，seed是 01 01 01，假设本地密码为01 02 03，而算法就是将密码与seed相加）
ECU验证成功 67 06
此时ECU就处于unlocked的状态了，那些被保护起来的诊断服务和诊断数据可以被操作了。通常来说，如果ECU重启，或者回到了default session，unlocked状态就失效了，如果要执行相关诊断服务，则需要再次执行上面描述的过程。