uds学习总结

uds诊断中Server是指的ECU，Client是指的上位机

根据ISO14229协议定义了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种服务。

正响应规定响应的SID必须是请求的SID+40，即请求SID为10，则响应SID为50；请求SID为27，则响应SID为67。

负响应规定响应格式必须是7F SID NRC,与正响应不同，这里SID仍为请求的SID，即请求SID为10，那么响应SID仍为10

默认会话是指ECU在刚上电时保持的会话状态，其服务的使用权限小，即可操作的功能单元服务少，不能使用27，28，83，84等服务；编程会话是仅使用与刷写程序相关的诊断服务，比如27，31，34，36，37等服务；而扩展会话相较于默认会话，其使用服务的权限大，即可操作的功能单元服务多，默认会话模式下不能使用的服务，在扩展模式下都能使用

会话模式可以理解为诊断的功能模式，即在不同的会话模式下，能够支持不能的诊断功能，如在默认会话模式下，一般情况下不允许支持写服务(WriteDataByIdentifier0x2E)，也不允许支持请求下载服务(RequestDownload0x34)，而在拓展诊断会话模式下，就允许支持写服务(WriteDataByIdentifier0x2E)，在编程会话模式下，就可以支持(RequestDownload0x34)

ECU在刚上电或者复位之后处于默认会话模式(0x01)，默认会话模式下发送10 03可以切换至拓展会话模式(0x03)，拓展会话模式发送10 02可以切换至编程会话模式(0x02)，而在默认会话模式不可以直接跳转至编程会话模式，若在模式会话模式直接发送10 02，此时ECU需要响应NRC为0x7E(subFunctionNotSupportedInActiveSession)的负响应，响应内容为7F 10 7E

当进入非默认会话后，如果服务端的S3定时器超时或请求了默认会话，将进入默认会话；

当进入非默认会话后，如果控制服务端的S3定时器不超时，比如使用待机握手服务（$3E），则即可进行编程会话与扩展会话切换，也可相应的会话模式进行所允许的服务。

S3server：服务器的定时参数，通常取5000ms，仅用于非默认会话模式。该定时器是在系统通过功能寻址检测器将原先的默认会话模式切换为非默认会话模式时使用。在S3Server 时间内，如果服务端没有收到任何诊断请求服务，则退出非默认会话，返回默认会话。
S3client：客户端的定时参数，通常取4000ms，客户端为保持非默认会话自动化连接，两个连续的待机握手服务请求的间隔时间。
即ECU处于非默认会话模式，如果不使用3E服务，如果5000ms都没有诊断服务请求，则会跳转到默认会话；如果使用3E服务，且每4000ms请求一次，则不管是否有其他诊断服务请求，都可以使ECU保持在非默认会话模式。

11复位服务

HardReset：硬复位；

keyOffOnReset：点火开关复位；

SoftReset: 软复位；

enableRapidPowerShutDown：使能快速休眠流程；

disableRapidPowerShutDown：抑制快速休眠流程；

vehicleManufacturerSpecific：供整车制造商使用的自定义复位类型；

systemSupplierSpecific：供系统供应商使用的自定义复位类型；

27安全解锁服务

 A：Service 27是成对出现，奇数位是请求Seed，偶数位是发送Key;

B：一个ECU中可以有不同安全等级，可通过Subfunction来区分不同安全等级

安全访问SecurityAccess(0x27)，此服务是提供访问ECU内部数据或者出于安全因素需被限制的诊断服务的请求权限。常见的如读服务(0x22)读取非安全信息时能够直接读取，不需要利用27服务进行安全访问，而通过写服务(0x2E)写入数据时，则通常需要通过27服务进行安全访问才可以写，刷新程序也需要利用27服务通过相关的安全等级才能够对ECU进行程序下载，显然这些都是需要利用27服务进行权限管控，从而保障ECU的安全可靠。

读取数据服务（$22）是根据DataIdentifier（即DID）去请求读取数据，其请求格式为SID+DID。
注意DID表示存储数据的地方，一般存储整车厂和零件供应商定义的数据，包括模拟输入和输出信号（比如转速信号），数字输入和输出信号（比如车门信号），内部数据和系统状态信息等，这里请求的DID可以是一个，也可以是多个。

写入数据服务（$2E）是根据DataIdentifier（即DID）去请求写入数据，其请求格式为SID+DID+Data.
注意这里一次只写一个DID的数据，不像读取数据服务（$22）可以一次读取多个DID的数据。通过该服务可以：写入一些配置信息到ECU（比如VIN码），清除非易失性数据，重置学习值，设置一些可选内容。

首帧，单帧，连续帧

0开头为单帧， 1开头为首帧，2开头为续帧，3开头为流控帧

 先通过首帧会告诉客户端数据有多长，比如这里的 0x0 14，即数据长度有20个字节；

然后客户端根据要接收的数据长度，决定是否允许续帧发送（0x0，表示允许发送），每回一帧流控帧后所允许的续帧数量（0x00,表示只发一帧流控帧，服务端将一直发续帧直到全部数据发送完毕），续帧发送的最小时间间隔多长（0x0A，10ms），发送给服务端；

最后服务端根据客户端响应的流控帧信息，按规定的要求顺序发送数据给客户端（粉色字体1，2表示续帧的顺序）。

服务端（作为发送方）响应时，发送方发送首帧后，接收方（客户端）接收到了将回复流控帧，即对发送方如何发送续帧做出一些要求，然后发送方再根据接收方的要求发送续帧。

DTC相关诊断功能

一个DTC对应一个具体故障，而鉴于整车运行是一个复杂的运行环境，其中必不可少会出现电压、电流异常（电涌）、信号不稳定（受电磁干扰）等情况。而对于车内节点判定DTC时，必然会根据一定的判定机制，避免因偶发而导致故障界定不准确：

DTC5位代码

 

 3.第三位是数字，表示故障所属的子系统；以对动力系统为例（P开头的故障码），有以下的情况：

0：表示燃油和空气计量辅助排放控制整个系统；

1：表示燃油和空气计量系统；

2：表示燃油和空气计量系统（喷油器）；

3：表示点火系统；

4：表示废气控制系统；

5：表示巡航、怠速控制系统；

6：车载电脑和输出信号；

7：传动系统控制；

4.最后两位也是数字，表示具体故障对象和类型。

 bit 0 : testFailed

通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1，表征出错。此时DTC的testFailed位被置1，但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0。

operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed = 0， 说明当前这个DTC没有出错，如果testFailedThisOperationCycle = 1的话，就说明这个DTC在当前这个operation cycle中出过错，但是当前错误又消失了。

bit 2 : pendingDTC

根据规范的解释，pendingDTC = 1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC = 1的时候，DTC就要被存储下来了，如果接下来的两个operation cycle中这个DTC都还存在，那么confirmedDTC就要置1了。如果当前operation cycle中，故障发生，pendingDTC = 1，但是在下一个operation cycle中，故障没有了，pendingDTC 仍然为 1，再下一个operation cycle中，故障仍然不存在，那么pendingDTC 就可以置0了

confirmedDTC = 1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC = 1，但testFailed = 0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC 重新置0的方法只有删除DTC，UDS用0x14服务，OBD用0x04服务

故障的确认是指上述检测到“故障”出现多少次或多长时间才算是真正的故障。因为有时可能只是某个信号极其偶尔波动一下，而这种波动对汽车没有影响，这时如果识别为故障，那么就过敏感了，反而会给驾驶员带来困扰。因此，为了规避这样的情况也被识别为故障，那么就提出了debouncing的概念，即通过一次次数或时间的累加，才能确认是否出现了真正的故障。只有当“故障”出现次数或时间累加到一定的值，才确认故障。当前常用Debouncing算法有基于计数器和基于时间两类，如下所示：

 

 

 

 发 送：19 +04+DTC故障码+快照记录码

正响应：59+04+DTC故障码+DTC状态位+快照记录码+快照信息个数+快照DID+对应的快照DID数据…

 0x19服务的sub-function代表了各式各样读取DTC的方法，UDS给19服务的sub-function从0x00到0x19进行了明确定义，我只使用过其中4种，下面对我用过的这些进行介绍，如果大家对其他的感兴趣，可以查阅ISO 14229的定义。

sub-function =0x01 （reportNumberOfDTCByStatusMask）

sub-function =0x01用于读取符合特定条件的DTC数量，此时parameter为一个byte的Mask，用于与DTC的Status进行“与”运算，而ECU返回的则是"与"运算之后结果不为0的DTC的数量。DTC的Status用一个byte表示，其中的8个bit分别代表DTC的不同状态，比如，bit 0 表示这个DTC是active的还是passive的，bit 4表示这个DTC是否已经被confirm了，如果DTC的状态是confirm，则说明该DTC已经被ECU存储下来了。

比如：19 01 08这个命令的用途，就是读取所有状态为confirm的DTC的数量。

sub-function =0x02 （reportDTCByStatusMask）

sub-function =0x02用于读取符合特定条件的DTC列表，此时parameter仍然为一个byte的Mask，用于与DTC的Status进行“与”运算，而ECU返回的则是"与"运算之后结果不为0的DTC列表。

比如19 02 01这个命令的用途，就是读取所有状态为active的DTC的数量。此时ECU返回的格式应该是59 02 01 XX XX XX 01 YY YY YY 09......。返回的DTC列表中的每个条目为4个字节，前三个字节用于标识DTC，比如 XX XX XX，最后一个字节用于标识DTC状态，比如01，表示DTC是active的，09表示DTC是active且confirm的。

sub-function =0x06 （reportDTCExtDataRecordByDTCNumber）

sub-function =0x06用于读取某个DTC及其相关的环境数据，此时parameter为4个byte，前三个byte用于标识我们要读取的DTC，第四个byte用于标识要读取的环境数据的范围，UDS规定使用FF来表示读取所有的环境数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的环境数据的范围。环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。

比如 19 06 XX XX XX FF就表示读取 XX XXXX这个DTC的所有环境数据，ECU的返回值应该是59 06 XX XX XX AA BB CC DD.....，其中AA BB CC DD...代表的就是XX XX XX这个DTC产生时所一起存储的环境数据。

sub-function =0x0E（reportMostRecentConfirmedDTC）

sub-function =0x0E时，不需要parameter。0x0E表示，要求ECU上报最近的一条被置为confirm的DTC

ECU软件刷写相关功能

软件刷写是指将软件程序烧录到ECU芯片内存的特定地址段，然后ECU就会运行该软件程序，去实现其特有的功能。常用的ECU刷写文件格式有：Hex, s19, bin等其他格式。

不管是哪种格式，这些文件都必须包含：存储地址，数据，校验和（checksum），记录类型和记录长度信息。

需要将软件刷写到芯片内存规定的区域

刷写时就必须知道要刷到哪里（即起始地址和结束地址），刷写空间够不够大，刷写是否正确（即通过校验和校验）

寻址方式有两种，一个叫物理寻址，另一个为功能寻址，物理寻址是诊断仪与单个ECU之间的诊断，而功能寻址是诊断仪与多个ECU之间的诊断，即诊断仪通过物理寻址方式发送请求报文时，只有指向的ECU可以回复响应报文；诊断仪通过功能寻址方式发送请求报文时，同一网络中支持功能寻址的所有ECU都需要回复响应报文。ECU收到诊断请求后，则通过消息的ID区分是物理寻址还是功能寻址，一般功能寻址的信号ID为0x7DF，物理寻址的消息ID为客户自定义，每个ECU都不一样。

0x34服务的请求格式

0x34服务的请求格式包括5个部分
第一部分：1个byte的SID
第二部分：1个byte的dataFormatIdentifier，这里面标识了数据格式相关的信息，比如数据是否有压缩，是否有加密，用的什么算法加密等，应该由主机厂与供应商约定好，用哪个bit来表示压缩、加密等信息。
第三部分：1个字节的addressAndLengthFormatIdentifier，用于指示后面两个部分所占用的字节，高4bit表示memorySize所占的字节长度，低4bit表示memoryAddress
所占的字节长度。在这个例子中我将这两个值分别设置为n和m。
第四部分：m个字节的memoryAddress，由addressAndLengthFormatIdentifier中的低4bit指示。含义是要写入数据在ECU中的逻辑地址。
第五部分：n个字节的memorySize，由addressAndLengthFormatIdentifier中的高4bit指示。含义是要写入数据的字节数。
ECU收到请求之后，如果允许传输的话，会给出如下response
第一部分：1个byte的 ResponseSID
第二部分：1个byte的dataFormatIdentifier作为echo
第三部分：maxNumberOfBlockLength，长度不定，表示可以通过0x36服务一次传输的最大数据量。

0x36服务的请求格式
第一部分：1个byte的 SID
第二部分：1个byte的blockSequenceCounter，标识当前传输的是第几个数据块，或者简单地说就是第几次调用36服务。
第三部分：transferRequestParameterRecord，传输的数据。第次传输数据量的上限就是34服务响应中的maxNumberOfBlockLength。

举例：如果ECU告知tester,maxNumberOfBlockLength= 20，也就是说tester每次通过36服务只能发送最多20个字节，其中还包括了SID和blockSequenceCounter，所以实际上每次可传的数据信息只有18个字节。如果tester要传的数据为50个字节，则需要传输三次，每次分别传输18，18，14个字节，即调用3次36服务。
36的响应很简单，就是一个字节的Response SID再加一个字节的blockSequenceCounter作为echo。

RequestTransferExit（0x37）：

37服务用于退出上传下载，如果之前的34和36服务都顺利执行完成，那么37服务就可以得到ECU的positive response。

格式很简单，请求就是37，正确响应就是77，都是一个字节。

如果前面的36服务没有执行完成，以我前面举的例子来说，比如这个数据块有50个字节，但是tester只发了两次36服务传了36个字节，那么这次传输对于ECU来说是失败的，所以ECU应该给出NRC 0x7F 37 24，表示诊断序列执行有错误。

Bootloader

BootLoader(下文简称Boot)也称为引导程序，其主要用于软件更新

刷新时序分为三个编程步骤：
预刷新步骤：刷新前的CAN网络准备；
主刷新步骤：下载应用软件或应用数据；
后刷新步骤：重同步CAN网络。
如果在预刷新、主刷新和后刷新步骤过程中，出现刷写中断，则全部时序需被再次执行。

由于ECU软件中难免会有BUG存在，以及要满足整车OTA需求，必须可以在不开盖的情况下更新软件。而ECU控制器对外的接口通常只有总线、电源和控制IO等。出于最大化复用接口(减少线束的重量和成本）考虑，通常采用基于UDS的Boot，而最常用的总线为CAN。为什么不用JTAG口呢？主要是ECU装车后，直接通过烧录器或者仿真器更新软件的很不方便，难以实现远程更新，另外由于JTAG口的权限很高，可以任意修改内部程序，安全风险很大。

Boot和APP应该放在不同的内存区域，防止相互干扰。Boot中不应集成Flash Driver，避免程序在正常运行时非法修改FLash，导致软件异常，通常在刷写App或者标定数据时，先将Flash Driver下载至芯片的RAM中。

为确保刷写的安全，ECU需设计安全机制，避免以下几种情况：a. 来自非法源的下载动作；b. 当前刷新条件不满足；c.下载错误的应用软件或应用数据到ECU；d.软件之间不兼容
在每次上电/复位后，ECU首先执行Bootloader代码。Bootloader首先执行一些基本的初始化，然后检查刷新请求标志位是否为有效，如果刷新请求标志位有效，即使应用程序是有效的，Bootloader也会继续运行。如果当前没有刷新请求，即刷新请求标志位为无效，则检查应用软件的状态，如果应用软件是有效的，则应用软件代码将被执行，如果应用软件是无效的，则继续执行Bootloader代码

另外，在Boot执行App或者标定数据更新时，应该具有多重安全检查机制，确保刷入正确的软件。

首先在执行刷写流程之前，上位机对需要更新的软件包进行检查，通常包括两项，其一是在生成软件包时，开发人员会在特定位置增加一个与上位机约定的特定的ID，当上位机加载软件包时，会去检查软件包中存储的ID是否与上位机中相同，如果不同，则终止刷写，这样可以防止刷入其他ECU的软件包。

其二是在生成软件包时，会对特定地址区域进CRC计算，通常采用CRC32，并将该CRC值存储在特定的地址，通常是程序的末尾，在上位机加载软件包时，按照相同的CRC算法进行计算，并与软件包中存入的进行比较，如果相同则进行下面的流程。这也是俗称的完整性检查。

在以上确认软件包本身没有问题后，开始准备将软件刷入到车内的ECU中，在此之前需要对当前车辆的刷写条件进行检查，其中主要包括当前是否有车速，档位是否在P档，蓄电池电压是否过低，对于新能源车而言，还需检查高压继电器是否闭合等。如果有一个条件不满足，处于安全考虑，都会终止软件更新。

此后，在执行数据下载前，还需通过主机厂指定的0x27服务的安全算法，对数据下载命令进行解锁。

ECU上电后，程序从链接文件中定义的RESET入口进入Boot，Boot在做完基本的初始化之后，会检查软件刷新标志位和App有效标志位，如果有效，则停留在Boot中等待执行软件刷写任务，如果无效，则跳转至App的入口地址，启动App

软件刷新标志位被置位通常有两种方式，其一为当App正常运行的时候，如果此时收到10 02切换至编程会话的命令，在App会将软件刷新标志位进行置位，通常写入至NVM，写入成功后，软件进行复位。这里涉及到NvM模块中的block在App和Boot中的同步管理。

其二是在Boot启动期间，收到10 02编程会话命令，Boot将软件刷新标志位进行置位，进入刷写流程

1、预编程步骤

从名字可以看出，该步骤主要是下载程序前的一些操作，包括唤醒ECU、读写特定的DID、通信管理等

 

其中：

1、唤醒ECU，唤醒的方法和策略由主机厂制定，有些要求在KeyOn下刷写，有些要求在KeyOff下刷写。

2、为了运行85服务关闭DTC存储和28服务关闭相关的通信，首先需通过10服务切换至扩展会话，因为85和28服务都需要在扩展模式下才能工作。

3、进入扩展会话后，主机厂可以进一步进行特定数据链路的初始化，通常来说，国内主机厂不会有这种需求，不知道欧洲会不会有。

4、运行31服务对刷写条件进行检查，例如低压电是否在正常范围内，档位是否为P档，车速是否为零等；

5、检查通过后，为了防止刷写过程中其他ECU节点误触发DTC，通常为通信故障，则通过功能寻址请求85服务关闭局域网内所有ECU节点的DTC存储；

6、该步骤提供给主机厂一个接口，可以通过0x31服务启动或关闭ECU的故障安全响应(failsafe reaction)，目前主机厂用得很少。

7、为了提高刷写速度，降低刷写程序时总线负载率，通过28服务关闭无关报文，比如应用报文和网络管理报文；

8、在关闭部分通信之后，通过22服务读取被刷ECU的状态(应用软件和数据)、软件指纹信息等；

9、为了减少刷写的时间，可以通过87服务提高CAN总线的波特率。

a) 诊断会话控制10h 03h：为了禁止ECU间的正常通信和禁止DTC设置，预刷新需要切换到扩展会话，通过功能寻址发送给所有的ECU。

b) 例程控制“检查刷新预条件”31h 01h xxh xxh：通过此例程来检查ECU刷新条件，从而确保系统安全，如果有任何不安全的因素，ECU将拒绝刷新。

注意：如果ECU在未收到“检查刷新预条件”例程（31 01 xx）的情况下，收到“10h 02h”请求，ECU将拒绝进入Bootloader，并且发送否定响应。

c) 控制DTC设置85h 02h：诊断仪通过DTC设置类型设为“关闭”的控制DTC设置服务请求。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

d) 通信控制28h 03h 03h：诊断仪通过通信控制（28h）服务请求，禁止非诊断报文的发送和接收。请求中的控制类型参数置为“disable the transmissionand the reception”，通信类型置为“application and network management messages”。此请求使用一个单帧请求报文，通过功能寻址发送给所有的ECU。

e) 读取数据22h xxh yyh：在禁止正常通信后，读取被刷新的ECU的状态（如：刷新的应用软件和数据）。从被刷新的ECU读取服务器标识数据，如应用软件标识、应用数据标识、Bootloader软件标识。

2、主编程阶段

该步骤用于将软件或者数据下载到被刷ECU中，主要包括进入特定的安全等级、写入指纹信息、下载软件和数据等

 a) 诊断会话控制10h 02h：通过物理寻址发送10h 02h，然后写入刷写标志位，最后ECU重启进入Bootloader，在BootLoader中需先发送肯定响应再执行跳转到刷新模式动作。

b) 安全访问27h 03h/04h：刷写必须通过安全访问。安全访问（27h）服务在排放相关和安全系统中是强制的。其它系统不要求使用该服务。下载前，通过安全访问过程是强制的，确保只有合法的诊断仪或上位机能对ECU进行下载操作。

为了缩短重刷新时间，上电可直接执行安全访问服务。

c) 驱动下载34h，36h，37h，31h：通常ECU的flash中不会存储flash读写驱动时，因此首先将执行flashdriver的下载。下载应该按照如下时序来进行：请求下载、传输数据、请求传输退出。下载完所有字节后，用“检查刷新完整性”例程（31h 01h F0h 01h）来检查所有的字节都正确传输。

d) 写入数据2Eh F1h 5Ah：在擦除内存例程之前，将“指纹”写到ECU内存中是强制的。“指纹”标识了是哪个诊断仪对ECU内存做了修改。使用F1h5Ah数据标识符而不是引导软件指纹、应用软件指纹、应用数据指纹这些数据标识符。每个逻辑块（除了驱动）下载前，诊断仪将首先写“指纹”，在下载完逻辑块后，ECU将识别之前下载的程序是哪个逻辑块（即逻辑块序号），并根据逻辑块的序号将它存储。在追踪指纹信息时，诊断仪将发报文“22hF1h 5Bh”，ECU将通过“62h F1h 5Bh…”，返回每一个逻辑块的指纹信息。

e) 例程控制——“擦除内存”31h 01h FFh 00h：为了允许应用软件和数据下载，ECU的内存将被擦除。此步骤通过例程控制服务（31h）来执行擦除内存。如果擦除内存例程被调用执行，那么应用软件的标志位将被置为无效。

f) 下载过程34h，36h，37h：应用软件或者数据的每一个连续的数据块下载到ECU非易失性内存中，都是遵循下面的服务顺序完成数传输：

Ø 请求下载（34h）；

Ø 传输数据（36h）；

Ø 请求退出传输（37h）。

单个应用软件或数据块可能需要多个数据传输（36h）请求报文来完成传输（当数据块长度超出网络层缓存大小时，就会出现这种情况）。

g) 例程控制——“检查刷新完整性”31h 01h F0h 01h：此例程用来检查逻辑块的完整性。

h) 例程控制——“检查刷新一致性”31h 01h FFh 01h：一旦完成所有的应用软件或数据块/模块的下载，诊断仪将开始一个例程来触发ECU检查重刷新的一致性。

i) 电控单元复位11h 01h：诊断仪使用物理寻址，发送一个复位类型为硬复位的ECU复位（11h）服务请求报文到CAN网络上。

通过ECU复位服务请求将使ECU结束重刷新过程，返回到正常的操作模式。内存驱动代码必须从RAM缓存中完全清除，避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

3、后编程阶段

该步骤主要通过11服务对ECU进行复位或者通过10服务将会话切换至默认会话，如果在预编程阶段中调整了波特率，须通过特定的操作将波特率调整至正常值。通常操作是运行11服务使ECU复位，重启ECU。

通讯控制CommunicationControl(0x28)

通讯控制服务用于开启或关闭ECU对某些报文的发送或接收，如应用报文和网络管理报文等。

 待机在线TesterPresent(0x3E)

该服务用于诊断仪端告知ECU诊断仪依然在线。该服务通常用于保持ECU处于非默认模式，由于ECU在S3server时间收不到诊断请求的话，ECU将会退回默认会话模式(default session)，所以诊断仪为了保持ECU处于非默认模式，需要周期性发送TesterPresent服务指令，周期时间需要小于S3server。

诊断故障码设置控制ControlDTCSetting(0x85)

诊断故障代码设置控制服务用于停止或重启ECU诊断故障代码的记录。

当通过该服务对故障码记录进行抑制操作后，若会话层时序参数超时从而ECU进入默认会话，或ECU执行复位操作后，诊断故障代码应该恢复记录。

当接收到诊断仪发送的清除诊断信息(0x14)服务后，ECU应重新开启诊断故障代码记录。