UDS诊断基础服务————11服务（基础篇）

UDS11服务也就是重启服务（ECURest）,用来控制MCU的重启用的。这里重启主要分为硬件重启和软件重启。同时也对应着11不同的子功能。

对于11服务的机制是在client端通过上位机发送一个11服务+CF的请求，然后通过诊断报文进行对MCU内部的重启接口调用，这里一般会调用到底层的重启复位接口。

根据协议的定义如下：

该服务请求服务器根据ECUReset请求消息中嵌入的resetType参数值的内容有效地执行服务器重置。 ECUReset

肯定响应消息（如果需要）应在服务器中执行复位之前发送。 服务器重置成功后，服务器应激活

defaultSession。

ISO 14229的这部分内容没有定义ECU从正面响应消息到ECU复位请求的时间，直到复位成功完成。 建议在此期

间ECU不接受任何请求消息并发送任何响应消息。

下面是相应格式：

ECUReset请求消息使用子函数参数resetType来描述服务器如何执行重置（suppressPosRspMsgIndicationBit （bit 7）未显示）。

下面我会给出子功能参数表（常用就是123，但是2对于目前的零部件供应商或者主机厂用的也很少，基本不用，除非添加该功能项）

位6-0	描述	Cvt	助节符
0x00	ISOreserved(预存)	M	ISORESERVED
0x01	硬重置。 该值标识了模拟通常在服务器先前已从其电源（即电池）断开连接之后执行的 开机/启动序列的“硬重置”条件。 执行的操作是特定于实现的，并未由标准 定义。 这可能导致易失性存储器和非易失性存储器位置重新初始化为预定 值。	U	HR
0x02	KEYoffonreset 此值标识 “ 软重置 ” 条件，如果适用，这会导致服务器立即重新启动应用程序。 执行的操作是特定于实现的，并未由标准定义。 典型的操作是重新启动应用 程序，而不重新初始化以前学习的配置数据，自适应因素和其他长期调整。	U	KOFFONR
0x03	softreset 软件重启。 此值标识 “ 软重置 ” 条件，如果适用，这会导致服务器立即重新启动应用程序。 执行的操作是特定于实现的，并未由标准定义。 典型的操作是重新启动应用 程序，而不重新初始化以前学习的配置数据，自适应因素和其他长期调整。	U	SR
0x04	enableRapidPowerShutDown 该子功能适用于不由点火提供动力但仅由电池供电的ECU。 因此，关机强制进 入睡眠模式，而不是关闭电源。 睡眠意味着断电，但仍然可以唤醒（电池供 电）。 子功能的目的是在点火转到关闭位置后减少ECU的待机时间。 该值请求服务器启用并执行 “ 快速关闭电源 ” 功能。 一旦“钥匙/点火”关闭， 服务器应立即执行该功能，当服务器执行断电功能时，应直接或在定义的准备 时间之后转换到睡眠模式，如果客户需要响应消息，并且服务器已经准备好执 行“快速关机”功能，则服务器应在“快速关机”功能开始之前发送肯定响应 消息，下一次出现“开机键”或“点火开启”信号终止“快速关闭电源”功 能。 注意此子功能仅适用于支持待机模式的服务器！	U	ERPSD
0x05	disableRapidPowerShutDown 该值请求服务器禁用先前启用的 “ 快速关闭电源 ” 功能。	U	DRPSD
0x06-0x3F	ISOSAEReserved 这个范围的值由本文件保留以备未来定义。	M	ISORESERVED
0x40-0x5F	vehicleManufacturerSpecific 这个值的范围保留给车辆制造商特定用途。	U	VMS
0x60-0x7E	systemSupplierSpecific 这个值的范围保留给系统供应商特定用途。	U	SSS
0x7F	ISOSAEReserved 该值由本文档保留以备将来定义。	M	ISO

然后就是肯定响应格式

肯定响应的格式还是以SID+40 +子功能

然后就是针对11服务的常用的NRC如下

消息流示例ECUReset

本小节指定了满足在服务器中成功执行ECUReset服务的例子的条件。

服务器状况：点火=开，系统不应处于运行模式（例如，如果系统是发动机管理，发动机应关闭）。

通过将suppressPosRspMsgIndicationBit（子函数参数的第7位）设置为'FALSE'，客户端请求获得响应消息。

在服务器执行resetType之前，服务器应发送ECUReset肯定响应消息。

关于如何去实现11服务

这里是根据规范去进行定义

首先无论走哪个接口，我们都会去调到硬件上的RESET的接口，这里是由macal层进行编写的接口，直接调用的芯片的硬件部分。然后对于11服务，我们需要明确一个就是它的复位时间和先后顺序，对于整个MCU来说无论是先复位还是后重启，还是先重启再复位都是可行的。一般来说是先重启了再复位。对于重启或者复位都应有一个标志位，目前对于主机厂来说，如果是自己的架构，这个标志位是可以自己定义的。对于autosar的工具链来说，这个是已经定义好了，在重启和KL15下电都会涉及到。

然后通过标志位的写入调用相应的判断从而进行重启。

同时需要注意的就是。

对于10 02也就是跳转到boot里面的时候，也会用到标志位，同时需要注意的是关于标志位写入EE里面的话，是否是同一个标志位，这里类autosar写了不同的信息，定义在同一DID里的。

11服务在进行复位重启的时候也是需要跳到boot里面进行重启复位，所有是需要注意11 01或者11 03的返回值是多少。