UDS_InputOutputControlByIdentifier(0x2F)服务

一、服务功能：

该服务是用于client主动请求server去对相关输入输出信号进行控制。所谓的输入输出控制简而言之就是屏蔽实际的输入输出信号值，取而代之的是client主动以某种特定的控制方式去设置这些信号值。

2F服务会对需要受控的信号进行编组，同时分配一个特定的DataIdentifier（即DID）来实现1个或多个信号参数的控制。但有时发送2F诊断服务时，我们不需要对所有信号进行控制，那么此时我们可以引入controlEnableMask来实现只对特定信号的控制。

针对2F服务设置后的输入输出信号值如何检验问题？

答：通过22服务；该服务可以通过信号所在的DID去获取对应的数值，然后与2F请求设置的数值比较是否相同，进而便可以知道2F控制是否生效。也就意味着支持2F的DID必须支持22服务，反之则不然。

一般而言，2F服务主要用于较为简单的输入输出控制，而更为复杂的输入输出控制使用31（Routine Control）服务则更为合适。

二、应用场景：

2F服务主要针对输入输出控制，列举常见的使用场景如下：

①：车窗的升降控制；（OutputControl）

②：直连执行器的启动与停止；（OutputControl）

③：车灯的开启与关闭；（OutputControl）

④：ADAS相关功能的配置开启与关闭；（InputControl）

⑤：LED报警灯的驱动与关闭；（OutputControl）

三、服务请求：

请求格式：

SID：诊断服务2F的标识符；

DataIdentifier：服务请求受控CS所分配的DID；

ControlOptionRecord：表示控制模式（IPCP）及控制的相关参数组成的数据集（CS）；

IOCP：控制模式

CS：需要被控制的参数

controlEnableMaskRecord：若CS参数个数超过1个，此时可以使用CM来实现对不同参数的控制，但只有1个CS参数时，则不应该使用CM参数，否则会回复NRC13表示请求的长度不满足要求。

控制参数（IPCP）

4种控制模式：

在使用4个参数时，需注意以下两点内容：

IOCP参数并不是2F服务的子服务，2F服务没有子服务，这点要明确；

在使用00，01，02时，诊断请求不需要加入受控参数controlState参数以及enable Mask，只需执行诊断请求 2F + DID +Byte Number（这三种种控制模式之一）,但其诊断回复还是要带有该DID所控制的参数的值;

还有一点：03控制模式对ECU是暂时的控制权；

IOCP中的4个参数并不是都需要支持，取决于客户需要，一般而言，00，03都会支持，其余两项可选。

关于多参数控制还是要说一下：（了解，平时很少用到CM）

当受控参数CS的个数超过1个时，我们引入controlEnableMask参数来实现对不同受控参数的控制。

其基本原理就是将对应参数与controlEnableMask的bit位进行一对一Mapping，若bit位为1，则表明对应的参数将受控，若为0，则表明对应的参数不受控。

并且受控的第一个参数必须对应controlEnableMask的最高位，其余参数按照排列顺序逐位类推。

四、服务响应：

正响应格式：

Response SID ：固定为0x6F

Data Identifier：与诊断请求一致的DID

ControlOptionRecord：表示控制模式及控制的相关参数组成的数据集；

IOCP：与诊断请求相同；

CS：与诊断请求的控制参数相同，其顺序也应当一致；

相比诊断请求，无论诊断请求是否包含Mask，我们会发现2F服务的诊断请求响应中不会包含controlEnableMask。

五、支持的NRC：

上述列出的NRC并不是需要全部支持，取决于具体的使用场景及客户需求。