2F服务,即 InputOutputControlByIdentifier
(按标识符的输入输出控制)服务,该服务用于相对简单的(如静态)输入替换/输出控制,但若必须使用较为复杂的输入替换/输出控制时,则使用 routineControl(例程控制)。
该服务是用于client主动请求server去对相关输入输出信号进行控制。所谓的输入输出控制简而言之就是屏蔽实际的输入输出信号值,取而代之的是client主动以某种特定的控制方式去设置这些信号值。
2F服务会对所需要受控的信号进行编组,同时分配一个特定的DataIdentifier(即DID)来实现1个或多个信号参数的控制。但有时发送2F诊断服务时我们不需要对所有信号进行控制,那么此时我们可以引入controlEnableMask来实现只对特定信号的控制。
此时要引入一个新的服务22(ReadDataByIdentifier),该服务可以通过信号所在的DID去获取对应的数值,然后与2F请求设置的数值比较是否相同,进而便可以知道2F控制是否生效。
也就意味着支持2F的DID必然支持22服务,反之则不然。
2F服务功能逻辑:
常见场景:
基本格式
归纳起来,诊断的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,第三个字节是错误响应码,指示具体错误响应的原因
NRC 判断优先级顺序:
控制参数IOCP是一种控制输入输出的控制模式,有以下4种控制模式:
在使用4个参数时,需注意以下两点内容:
IOCP参数并不是2F服务的子服务,2F服务没有子服务,这点要明确;
在使用00 ,01,02时,诊断请求不需要加入受控参数controlState参数以及enable Mask,只需执行诊断请求 2F + DID +Byte Number,但其诊断回复还是要带有该DID所控制的参数的值;
IOCP中的4个参数并不是都需要支持,取决于客户需要,一般而言,00,03都会支持,其余两项可选;
示例 1 - 示例 1:“进气门位置”shortTermAdjustment(短期调整)
正受控制的参数是与 dataIdentifier(数据标识符)(0x9B00) 相关的“进气门位置”。
换算: Air Inlet Door Position(进气门位置) [%] = 十进制(十六进制) * 1 [%]
示例 2 – EGR 和 IAC shortTermAdjustment(短期调整)(单个请求内的各个参数或多个参数)
本示例使用了打包的 dataIdentifier(数据标识符) 0x0155 说明单个请求内的各个参数或多个参数。 dataIdentifier 支持下表内的五个参数
案例 1:仅控制 IAC 枢轴位置
案例 2: 仅控制 RPM
案例 3:控制踏板位置 A和 EGR 工作周期
案例 4:将所有参数的控制权返还给 ECU