UDS诊断系列之十三 例程控制（31）服务 上

例程控制服务主要功能是由客户端请求服务端开始、结束一个例程，以及获取例程执行的状态和结果。

一、主要功能和响应规则

1.例程 routine

A routine is the usual series of things that you do at a particular time. A routine is also the practice of regularly doing things in a fixed order.
以上是柯林词典给出的例程的定义，英语水平有限，就不直接翻译了，这里只按我自己的理解来解释它的含义。
例程，就是指的一段写好的具有一定功能的代码模块，通过例程控制服务，可以控制这段代码。ISO14229-1里对例程的接口已经定义好了，即可以控制例程的开始、结束和获取结果，以及相关的执行规则也定义的很清楚。
例程有两种，一种是完全有例程控制服务对例程的开始和结束进行控制，该例程开始之后会持续执行，由客户端对其进行控制，服务端仅负责接受和执行请求；另一种是由客户端请求例程开始执行，但例程结束由服务端控制，可以是在诊断响应之前就结束，也可以在给出诊断响应之后再结束。
那么，例程都用来做什么？最常见的应用场景如车钥匙学习，四轮胎压学习，ESP制动液注入，车窗防夹标定，存储器擦除，数据校验，一些需要测试的功能检测，功能控制等等。

2.例程控制

乍一看，会有这样的疑问，例程控制和输入输出控制服务的功能是不是一样的？
实际上，输入输出控制的功能，都可以通过例程控制来实现，而且，例程控制服务可以实现更复杂的功能。按照标准对服务功能的定义，输入输出控制服务大部分都是对服务端的一些变量做临时控制，基本上都是静态的，也就是说不能形成有序的操作。而例程控制前面说过，是由一段代码来执行的，所以它是可以让服务端的某些接口按照一定的顺序执行一系列的控制，通过连贯操作，实现一些复杂场景的功能实施。
例程控制主要包含以下控制指令：

开始例程

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

停止例程

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

请求例程结果

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

二、应用数据格式

1.请求报文

请求报文的格式比较简单，主要包括请求的服务ID，子功能，routineIdentifier和routineControlOptionRecord四个部分。服务ID和子功能这里就不再多说，固定格式必须包含的。routineIdentifier和输入输出控制服务的DID参数类似，也是用来标识具体的功能的，也是强制的参数。routineControlOptionRecord这个参数是可选的，根据实际的routine设计来决定，有些例程需要额外的数据，就需要通过这个参数来放入一些内容，如数据校验需要把校验标准发送给服务端，这样服务端就可以根据自身计算结果和接收到的校验数据进行校验比对，来判断校验结果。

2.响应报文

响应的格式同样，也比较简单，响应的服务ID和子功能（这里叫routineControlType）同样不再多说，routineIdentifier这里也不再说明。
第5个字节是routineInfo，这个参数的定义比较有意思，这是个固定格式，主要目的是为了能够让诊断仪更加通用。一般诊断仪分两种，OEM自己的和通用诊断仪，OEM自己的很容易理解，因为有OEM的数据支持，所以基本上所有的数据都可以识别，而通用的诊断仪则没有办法识别OEM定义的部分内容，如没办法识别例程的执行结果是成功和失败。所以这个字节提供了一个框架，把执行的结果统一放到这个地方，这样通用的诊断仪虽然不能识别结果的具体细节，但还是能够识别请求执行的成功与否。这个参数在一些OBD的标准里要求的例程是强制的，而对于OEM则是可选的。
最后这个参数routineStatusRecord则是实际的例程执行结果，根据具体的例程进行定义，可以是简单的成功失败，也可以是具体的执行后的数据。

以下是系列链接：
UDS诊断系列之十四 例程控制（31）服务下

UDS诊断系列链接汇总