ECU复位服务,其服务ID是0x11,主要功能是控制ECU执行复位动作,功能和格式都比较简单。
一、响应规则
接收到复位请求后,ECU执行请求的复位功能,如果需要给出响应,可以根据实际需要在复位前或复位之后给出肯定响应。
这个响应在ISO里推荐在执行复位之前进行响应,使用了strongly来形容其推荐的做法,这里结合自己的经验,推测一下原因。
ECU的复位动作是一个有可能耗费时间比较长的动作,而前面10服务提到的P2server_max参数一般设置为50ms,即使在客户端P2client_max也仅有150ms,因此这个时间有可能是不够ECU执行完复位再进行响应的,这就造成了响应超时的结果。超时是什么概念呢,相当你还花呗一样,会有一个约定时间还款,如果逾期了,花呗就当你超时了,会收违约金,而在诊断的概念里,就直接当成ECU没有响应,放弃这次会话了。
所以为了不超时,一般两种做法,第一种就是ISO里推荐的这种在执行复位之前进行响应,另一种呢就是先响应一个NRC78,前面提到过,这个NRC的含义是等一下,等多久呢,P2*server_max时间,通用定义为5000ms也就是5s,这个时间就足够大部分ECU复位了。
那么ISO为什么推荐第一种做法呢,因为ECU越来越复杂,复位的时间也越来越长,那么有一部分是没办法完成5s复位的,最典型的例子,车上的娱乐主机,大部分都安卓系统,哪个安卓能5s完成复位。所以,ISO推荐的方案就是执行复位前给出肯定响应,但这里有个事情需要注意,就是采用这种策略之后,后续步骤要留出足够的时间再执行,不然ECU复位过程中是无法给出响应的。
二、应用数据格式
1.请求报文
下表是请求报文的数据格式,格式比较简单,只包含两个字节,服务ID占一个字节0x11,子功能占一个字节,数据可取范围为0x00-0xFF。
2.响应报文
下表是响应报文的数据格式,与请求报文有两点不同,响应的服务ID变成了0x51,子功能之后有一个可选字节powerDownTime,这个字节的作用与子功能0x04有关,指的是快速关闭需要的时间,该子功能下节会详细说明。
3.子功能
ECU复位服务在ISO标准中定义的子功能有5个,而常用的子功能有1和3两个,具体含义参见下表。
子功能 | 功能描述 |
---|---|
1 | 硬复位,模拟电源断开重新连接的场景,这个子功能是最常用的一个。具体执行的操作这里ISO并没有给出来,而是把解释权交给了ECU供应商,只给了一个可能的做法,就是易失存储器和非易失存储器的数据都会被初始化,跟没说差不多,不具备太大的参考意义。 |
2 | 钥匙上下电复位,模拟车钥匙切换到off再切换会on的场景,遇到使用这个子功能的情况不多。同样ISO里也没有给出具体的措施,ISO给出的典型做法里易失存储器的数据在这种场景下会重新初始化。 |
3 | 软复位,模拟应用程序重新打开的场景,也算是一个常见的子功能,比硬复位用的少。ISO给出的典型做法是易失存储器和非易失存储器的数据都不会被重新初始化。 |
4 | 使能快速下电,适用于带睡眠唤醒功能的ECU,设置使能后会加快ECU在从唤醒状态切换到睡眠状态的时间,前提是ECU支持这个快速下电的功能。这个功能使能之后在睡眠之前会一直保持,直到经过一次睡眠唤醒之后或者收到关闭请求这个功能就被关闭了。ISO里特别提示这个子功能需要ECU支持stand-by-mode功能,具体功能定义不太清楚,是否指网络管理也不清楚,因为至今还没遇到有用过的,可能需要再接触一些先进的外企才能遇到吧。 |
5 | 关闭快速下电,顾名思义,这里不再多说。 |
前面说明格式的时候提到响应里有个下电时间参数,就是给4这个子功能用的,请求之后需要给出一个时间,方便确定执行下一步的准确时间。
NRC和数据示例我就不从ISO中截图了,没啥特殊的,自己看就可以了