在汽车ECU诊断服务开发的过程中，有很多常见的诊断服务，比如10, 11, 22, 2E等，但是对于2F服务则会显得有些陌生，因为这类诊断服务主要在车身域比较常见，比如车窗控制，传感器开关、执行器控制等。除此以外，在其他车身域也有不同程度的使用，只不过相对较少。

接下来，让我们带着下列思考一起来了解一下这个较为神秘的2F服务吧！

  • 2F服务是做什么的呢？
  • 它的诊断服务请求及回复是怎样一种方式？
  • 与31服务Routine Control相比，又有什么区别呢？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文

UDS诊断服务协议都以ISO标准ISO14229-1来集中体现，如需了解其他更多诊断服务的精彩使用，可以参考此文档，本文以ISO14229-1（2020）协议作为参考来解读2F服务。

服务功能

功能描述

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

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

有小伙伴们在此会发问了，虽然可以对信号进行控制，但是怎么知道软件内部有没有真正的起作用呢。

别着急，此时要引入一个新的服务22(ReadDataByIdentifier)，该服务可以通过信号所在的DID去获取对应的数值，然后与2F请求设置的数值比较是否相同，进而便可以知道2F控制是否生效。

本文不会对22服务展开，只会提到其基本使用，具体细节可参考上文提到的协议标准。也就意味着支持2F的DID必然支持22服务，反之则不然。

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

如下图1所示，较为清晰的描述了2F服务的主体功能:

​图1 2F服务功能逻辑

应用场景

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

  • 车窗的升降控制；（OutputControl）
  • 直连执行器的启动与停止；（OutputControl）
  • 车灯的开启与关闭；（OutputControl）
  • ADAS相关功能的配置开启与关闭；（InputControl）
  • LED报警灯的驱动与关闭；（OutputControl）

服务请求

所谓服务请求就是客户端（以下统称为Tester）按照UDS协议规范来发送一系列诊断指令，等待ECU（以下统称为Server）响应的过程。

请求格式

如下图2所示，Tester需要按照以下的格式要求来发送至Server：

​图2 2F服务诊断请求格式

诊断请求格式中包含四大部分：

  • SID: 诊断服务2F的标识符；
  • DataIdenfier: 服务请求受控cs所分配的DID；
  • ControlOptionRecord: 表示控制模式及控制的相关参数组成的数据集；
  • IOCP: 控制模式；
  • CS：需要被控制的参数；
  • controlEnableMaskRecord: 若CS参数个数超过1个时，此时可以使用CM来实现对不同参数的控制，但只有1个CS参数时，则不应该使用CM参数，否则会回复NRC13表示请求的长度不满足要求。

控制参数(IOCP)

控制参数IOCP是一种控制输入输出的控制模式，如下图3所示，有以下4种控制模式：

​图3 IOCP定义与说明

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

  • IOCP参数并不是2F服务的子服务，2F服务没有子服务，这点要明确；
  • 在使用00 ，01，02时，诊断请求不需要加入受控参数controlState参数以及enable Mask，只需执行诊断请求 2F + DID +Byte Number,但其诊断回复还是要带有该DID所控制的参数的值;
  • IOCP中的4个参数并不是都需要支持，取决于客户需要，一般而言，00，03都会支持，其余两项可选；