统一诊断服务 (Unified diagnostic services ， UDS) （二）

会里很

UDS定义的诊断服务从逻辑来说分为以下几类：

• 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的重启
当我们通过诊断命令改写了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状态就失效了，如果要执行相关诊断服务，则需要再次执行上面描述的过程。

时间有限，这篇文章里就介绍这三个诊断服务，即0x10, 0x11, 0x27，后续有时间我再补充其他的服务，欢迎大家多提宝贵意见。码字不易，看到这里的话就点个赞吧。

原文地址：https://zhuanlan.zhihu.com/p/33742492