结合实例来聊聊UDS诊断中的0x2F服务

news2025/1/4 1:40:38

1、什么是UDS中的0x2F服务

0x2F简单来说，就是输入输出控制服务。先看官方的简绍

翻译如下：

InputOutputControlByldentifier服务来替换输入信号、内部服务器函数和/或强制控制为电子系统的输出（执行器）的值。通常，此服务用于相对简单的（例如静态）输入替换/输出控制，而routineControl用于需要更复杂的输入替换/输出控制。

2、0x2F服务中的5个参数

2.1 、请求PUD中元素的名称、位置、值

2.2 、5个参数的详细解释

2.3、inputOutputControlParameter 参数ISO规定的几种类型

3、实例分析

现在存在一个项目，需要使用0x2F服务来控制左前、右前、左后、右后四个车窗的升降。一般来说可以有以下两个设计方案。

从简单到复杂

3.1 为每个车窗单独设定一个DID

为每个车窗单独设定一个DID，inputOutputControlParameter只支持03，和00即可。

**1）左前车窗控制 DID= D001

**2) 右前车窗控制 DID= D002

**3) 左前车窗控制 DID= D003

**4) 左后车窗控制 DID= D004

cdd文件中可以这样定义：

诊断请求这样发送：

假设，物理请求地址为0x 701，XX(代表填充数据) ,诊断帧DLC固定为8

0x 701 05 2F D0 01 03 FF(该参数指示的是左前车窗打开到0.1*255=25.5%位置处) XX XX

这里FF换算关系，0.1*raw不一定合理，建议修改为0.4*raw，这样可以做到100%开启。

FF对应的参数就是controlState参数，按照2.1章节中的描述，可以认为FF=controlState_1。

对controlState补充说明：

规范中对，这个参数并没有作出具体的长度和位数限制，还是以车窗控制为例，controlState参数

可以设置为7bit。当参数= bin 110 0100= dec 100时、就代表车窗全开位置100%。

如果DID控制的是一些，继电器开关，车灯的开关、则controlState选用一个bit即可

3.2 为4个车窗设定一个DID

具体4个车窗设定一个DID 还可以分为两种情况：

**1）4个车窗设定一个DID，不带controlEnableMaskRecord参数

**2) 4个车窗设定一个DID，存在controlEnableMaskRecord参数

3.2.1、4个车窗设定一个DID，不带controlEnableMaskRecord参数

此时，4个车窗设定一个DID D001 ，可以认为这4个车窗是"控制组"此时就需要给每一个车窗设置一个controlState，可以编号为：

controlState_FL

controlState_FR

controlState_RL

controlState_RR

诊断请求报文如下：

假设，物理请求地址为0x 701，XX(代表填充数据) ,诊断帧DLC固定为8

0x 701 10 08 2F D0 01 03 FF 0A

0x701 21 14 28 XX XX XX XX XX

提取红色部分数据“FF 0A 14 28”

FF=左前车窗开启25%

0A=右前车窗开启 1%

14=左后车窗开启 2%

28=左后车窗开启 3%

3.2.2、4个车窗设定一个DID，存在controlEnableMaskRecord参数

3.2.1中的设置，存在一个问题，即只能同时控制4个车窗，如果仅仅想只控制一个车窗怎么办？为了解决这个问题，我们就引入了controlEnableMaskRecord参数。

**1）controlEnableMaskRecord参数是什么？

具体到本例子中，我们存在4个车窗需要控制，可以为每一个车窗在controlEnableMaskRecord参数中映射（绑定）一段数据。

说人话，就是，首先我们设置controlEnableMaskRecord=1Byte。然后

对应位置=1，代表开启哪一位的控制。

补充说明；controlEnableMaskRecord14229协议中，也是没有强制规定能占用的长度，需要主机厂在具体项目文件中定义。有同学会说前后左右4个车窗，4个bit就足够了，确实但是一般为了方便以后拓展，都会预留。比如后面D001这个DID还需要去控制4个车门锁的开关，就可以使用了。

报文发送如下：

假设，物理请求地址为0x 701，XX(代表填充数据) ,诊断帧DLC固定为8

0x 701 10 09 2F D0 01 03 01 FF

0x701 21 0A 14 28 XX XX XX XX

提取背景标黄的字节“01”，代表左前车窗需要，其他车窗不能被控制

FF=左前车窗开启25%

0A=右前车窗不被控制，因为controlEnableMaskRecord参数中已经说明

14=左后车窗不被控制，因为controlEnableMaskRecord参数中已经说明

28=左后车窗不被控制，因为controlEnableMaskRecord参数中已经说明

3.3 0x2F 诊断请求、诊断回复报文格式

诊断回复报文，是依据inputOutputControlParameter这个参数的不同，来确定回复和请求的格式

3.3.1 inputOutputControlParameter=0时的请求和回复报文

即 ReturnControlToECU，截取的是14229规范中的表格。

先来解释下，inputOutputControlParameter=0时的含义，是指放弃诊断控制输入输出，转到正常状态下控制，所谓的正常状态是指通过CAN报文指令，通过传感器采集信息，来决定控制器的输入和输出！！

关注的点：

**1） inputOutputControlParameter=00时，不存在CountState参数

**2）正响应回复 0x(2F+40),+DID+00(inputOutputControlParameter),但是反馈了一个CountStateRecord参数。这个参数反馈的是该DID对应所控制的输入输出“实时的参数”，比如这个DID控制的是发动机节气门的闭合度，此时3A就代表的是发送此帧响应报文时刻，节气门的闭合度。

3.3.2 inputOutputControlParameter=01 时的请求和回复报文

规范中，并没有直接给出 “ inputOutputControlParameter=01 时的请求和回复报文”的实例，不过也在其他表格出作出了说明：如下图

大家可以参考 inputOutputControlParameter=00，时请求报文和响应报文的格式相同，只需要将请求报文中，和响应报文中的inputOutputControlParameter参数修改=01，即可

3.3.2 inputOutputControlParameter=02 时的请求和回复报文

3.3.3 inputOutputControlParameter=03 时的请求和回复报文

此时请求报文已经在3.1章节和3.2章节说明过了，分为带controlEnableMask参数和不带ControlEnableMask参数两种状态，不在赘述！！！

回复报文，需要注意一点，就算ControlEnableMask没有置位的控制选项，回复时依然要发送实时状态。

4、一些容易被忽视的知识点

1、ControlState设计的顺序和ControlEnableMask的设计顺序要保持一致

如和3.2章节的例子，

ControlState按字节顺序，依次是“左前、右前、左后、右后”

ControlEnableMask从的bit7（严格来说是最高bit位）位依次也要是“左前、右前、左后、右后”