【车载开发系列】UDS诊断---例程控制（$0x31）

【车载开发系列】UDS诊断—例程控制（$0x31）

一.概念定义

1）RoutineControl服务

用于对主机厂定义的一些特定程序的控制操作（启动例程、停止例程、请求运行结果）。
例程控制服务主要功能是由客户端请求服务端开始、结束一个例程，以及获取例程执行的状态和结果。

2）例程的概念

例程也可以理解为程序，就是指的一段写好的具有一定功能的代码模块，通过例程控制服务，可以控制这段代码
例程有两种，一种是完全由例程控制服务对例程的开始和结束进行控制，该例程开始之后会持续执行，由客户端对其进行控制，服务端仅负责接受和执行请求；
另一种是由客户端请求例程开始执行，但例程结束由服务端控制，可以是在诊断响应之前就结束，也可以在给出诊断响应之后再结束。

3）例程的应用

最常见的应用场景如车钥匙学习，四轮胎压学习，ESP制动液注入，车窗防夹标定，存储器擦除，数据校验，一些需要测试的功能检测，功能控制等等。

4）例程有效前提

例程执行的条件由ECU系统供应商定义。出于存在任何对于操作者、驾驶员及乘客安全隐患的考虑，一般情况下，系统必须保证在例程执行前满足低车速的情况下可用。

二.子功能

例程控制服务只有三个有效子功能，其他的都是保留值，其定义对应的就是上篇提到的三个功能。

1）启动例程

服务端在接收到开始例程的请求后，应立即开始执行指定的例程（通过一个两个字节的ID来指定，后面格式里会看到），根据例程设计的不同，服务端应该在执行例程之后给出响应，有些例程如擦除寄存器、数据校验等，需要立即执行并且在执行完给出结果的，则需要在执行完给出肯定或者否定响应，而有些如钥匙学习、胎压学习等需要由客户端发送请求来控制，则在正常开始例程之后给出肯定响应，如不正常则给出否定响应。

2）停止例程

服务端在接收到停止例程的请求后，应立即停止指定的例程，如果例程停止成功，服务端应该给出肯定响应，如果例程停止失败，则需要给出否定响应。

3）请求运行结果

一般例程，在前面的两个指令的响应里，就会带有例程执行的结果。但是有一些由于例程的特殊性无法在响应里给出结果，所以需要单独请求例程执行的结果。

三.否定响应流程

例程控制服务只有三个有效的子功能，其他的都是保留值，其定义对应的就是上篇提到的三个功能。如果下面的检查内容都检查通过了，则回复肯定响应。

1）NRC13

Minimum length check：这里最小长度检查包括了SID,SubFunction,RID，最少是4个字节；

2）NRC31

这里检查在当前诊断会话模式，是否支持请求的RID，这里的RID即routineIdentifier

3）NRC34

如果服务支持安全传输，这里检查安全传输的验证结果是否通过；

4）NRC33

如果DID支持安全校验，这里检查安全校验服务是否已经验证通过；

5）NRC12

这里校验请求里的子功能是否支持；

6）NRC13

Total length check：总长度检查，即包括SID,SubFunction,RID,routineControlOptionRecord的总长度，routineControlOptionRecord的长度依据RID而定；

7）NRC31

当检查逻辑执行到这里的时候，主要检查的是routineControlOptionRecord参数是否在RID定义的有效范围内；

8）NRC22

NRC22有两个，第一个检查的是请求的服务和子功能的执行条件是否满足，第二个检查的是请求数据的执行条件是否满足；

9）NRC24

31服务的子功能是有顺序的，即停止例程的请求必须是在开始例程的后面请求才可以，请求例程的执行结果也必须在开始例程之后才被允许，否则回复此NRC。

四.报文格式

1）请求报文

1. 主要包括请求的服务ID，子功能，routineIdentifier和routineControlOptionRecord四个部分。
2. routineControlType就是子功能类型；
3. routineIdentifier和输入输出控制服务的DID参数类似，也是用来标识具体的功能的,具体可以参照下面；
4. routineControlOptionRecord这个参数是可选的，根据实际的routine设计来决定，有些例程需要额外的数据，就需要通过这个参数来放入一些内容；比如在检查编程依赖性的时候（RID：0xFF01）就用这个参数来传递CheckSum。
   

2）肯定响应

1. routineStatusRecord是实际的例程执行结果，根据具体的例程进行定义，可以是简单的成功失败，也可以是具体的执行后的数据。
2. 在ISO14229当中还有一个routineInfo，这个参数的定义比较有意思，这是个固定格式，主要目的是为了能够让诊断工具更加得通用。
   一般说来诊断工具分为两种，OEM自己的和通用诊断工具，OEM自己的很容易理解，因为有OEM的数据支持，所以基本上所有的数据都可以识别，而通用的诊断工具则没有办法识别OEM定义的部分内容；这个参数在一些OBD的标准里要求的例程是强制的，而对于OEM则是可选的。
   

2）否定响应

否定响应码具体可以参照以上的否定响应流程。

五.RID Definition

RID就是RoutineIdentifier的缩写。

字节值	说明	说明详细
0x0000 – 0x00FF	ISOSAEReserved	ISOSAE保留位
0x0100 - 0x01FF	TachographTestIds	自动回转速度计测试标识符
0x0200 - 0xDFFF	vehicleManufacturerSpecific	车辆制造商专用
0xE000 - 0xE1FF	OBDTestIds	OBD测试标识符
0xE200	DeployLoopRoutineID	部署点火线圈例程标识符
0xE201 – 0xE2FF	SafetySystemRoutineIDs	安全系统例程标识符
0xE300 - 0xEFFF	ISOSAEReserved	ISOSAE保留位
0xF000 - 0xFEFF	systemSupplierSpecific	系统供应商专用
0xFF00	eraseMemory	清除内存
0xFF01	checkProgrammingDependencies	检查编程依赖性
0xFF02	eraseMirrorMemoryDTCs	清除镜像内存DTC
0xFF03 - 0xFFFF	ISOSAEReserved	ISOSAE保留位

六.常用的RID Definition

1. EraseFlashMemory（擦除Flash内存）

用于对此次升级要用到的内存空间进行擦除操作。
一般用于请求APP数据下载（34服务）之前。

2. CheckProgrammingDependency（编程兼容性的检查 ）

用于升级完成后对升级信息的兼容性检查，例如对升级文件产品型号的检查，必要的逻辑块是否存在的检查等操作。
一般用于完成所有数据的升级之后。

3. CheckProgrammingPreconditions（编程条件检查）

该程序用于对ECU升级条件（如车速信息等）的判断，在ECU的BootLoader与APP程序中一般都要有该程序功能的定义。一般用于进入编程会话之前。

4. CheckAppSwAppDataValidity（检查数据的有效性，如CRC校验）

一般用于对升级数据中的每个块信息的CRC校验；
ECU会将接收到的数据进行CRC计算，并与诊断仪计算发送过来的CRC进行比对；确保数据的准确性。