31服务,即 RoutineControl
(例程控制)服务,该服务允许客户端使用 RoutineControl(例程控制)服务执行指定的步骤顺序并获取任何相关结果。
该服务具有较大的灵活性,但一般应用可以包括清除内存、重置或学习自适应数据、运行自检、覆盖正常的服务器控制策略和控制服务器值随时间而变化,以及预定义序列(如关闭敞篷车顶)等。
在某些情况下2F服务的基本功能也是能够通过31服务来实现,可以理解2F实现的功能31服务均可以实现,不过如果能够用2F实现的功能来用31服务,未免有些大材小用,因此31服务则是用于更为复杂的输入输出控制场景,而2F服务则可用于较为简单常见的输入输出控制场景。
常见场景:
如下图所示,针对31服务的通信控制过程会经过如下几个AUTOSAR BSW模块进行处理,然后完成最终的Routine控制,具体步骤如下:
基本格式
归纳起来,诊断的request格式无非以下两种:
<SID> + <Sub-function> + <Parameter>
<SID> + <Parameter>
即有无sub-function的区别。Parameter可以是DID,可以是输入参数,可以是自定义的值,字节数视具体要求而定。
子功能参数定义(1字节数据):
无。
基本格式:
<SID + 0x40> + <Sub-function> + <Parameter>
<SID + 0x40> + <Parameter>
要注意,第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的,具体要看协议规定。
基本格式:
<0x7F> + <SID> + <NRC>
看起来比较简单,格式比较固定,只要是Negative Response,第一字节就是0x7F,第二字节照抄原来的SID,第三个字节是错误响应码,指示具体错误响应的原因
示例 1:子功能 = startRoutine
本小节说明了在服务器中启动例程的测试条件,在技术员“扭动”所有受试系统线束接头时,间歇性的不断测试(尽可能快的)所有输入和输出信号。通过 routineIdentifier 0x0201 引用该程序。
测试条件: ignition = on, engine = off, vehicle speed = 0 [kph](点火开关打开,发动机熄火,车辆速度为 0 [kph])
客户端通过将 suppressPosRspMsgIndicationBit(抑制肯定响应消息指示位)(子功能参数的第 7位)设置为“FALSE(假) ”(“0”)来请求响应消息。
示例 2:子功能 = stopRoutine
本小节说明了在服务器中停止例程的测试条件,在技术员“扭动”所有受试系统线束接头时,间歇性的不断测试(尽可能快的)所有输入和输出信号。通过 routineIdentifier 0x0201 引用该程序。
测试条件: ignition = on, engine = off, vehicle speed = 0 [kph](点火开关打开,发动机熄火,车辆速度为 0 [kph])
客户端通过将 suppressPosRspMsgIndicationBit(抑制肯定响应消息指示位)(子功能参数的第 7位)设置为“FALSE(假) ”(“0”)来请求响应消息。
示例 3:子功能 = requestRoutineResults
本示例说明了如何在结束例程后获取结果值。在技术员“扭动”所有受试系统线束接头时,间歇性的不断测试(尽可能快的)所有输入和输出信号。 routineIdentifier 0x0201 引用该例程。
测试条件:ignition = on, engine = off, vehicle speed = 0 [kph](点火开关打开,发动机熄火,车辆速度为 0[kph])。
客户端通过将 suppressPosRspMsgIndicationBit(抑制肯定响应消息指示位)(子功能参数第 7位)设置为“假”(‘0’)请求响应消息。