【车载开发系列】UDS诊断—输入输出控制($0x2F)
UDS诊断---输入输出控制($0x2F)
- 【车载开发系列】UDS诊断---输入输出控制($0x2F)
- 一.概念定义
- 1)与0x31例程控制服务的关系
- 2)与0x22读取数据标识符的关系
- 二.应用场景
- 三.限制条件
- 四.报文格式
- 1)请求报文
- 2)肯定响应
- 3)否定响应
一.概念定义
- 诊断工具使用此服务来替代ECU实现的标识符对应的输入信号的值、ECU内部功能和/或控制电子系统的输出。
- 2F服务作为输入输出控制服务,其全称为InputOutControlByIdentifier。简而言之就是屏蔽实际的输入输出信号值,取而代之的是client主动以某种特定的控制方式去设置这些信号值。
- 该服务是用于client主动请求server去对相关输入输出信号进行控制。
- ECU简单来说就是一个对输入(sensor)进行计算再产生输出(actuator)的系统。类似于软件架构风格当中的管道过滤器风格,而2F这个服务就是对ECU的输入和输出进行控制。
1)与0x31例程控制服务的关系
- InputOutputControlByIdentifier (0x2F) 和RoutineControl (0x31) 这两个诊断服务的用途和用法有点类似,都是调用ECU内部一些预定义的操作序列,相当于是我们从外部利用诊断手段控制ECU的接口。
- 2F服务主要用于较为简单的输入输出控制,而更为复杂的输入输出控制使用31(Routine Control)服务则更为合适。
2)与0x22读取数据标识符的关系
- 0x22服务可以通过信号所在的DID去获取对应的数值,然后与2F请求设置的数值比较是否相同,进而便可以知道2F控制是否生效。
- 支持2F的DID必然支持22服务,反之支持22的DID不一定支持2F服务。
- UDS定义可以用22服务读取2F服务中使用的dataIdentifier,返回值是状态信息,具体的状态信息是什么,可以由使用者自定义。
二.应用场景
- 输入输出控制比较常用的场景就是用来进行一些下线检测,前面提到仪表的各种警告灯,在下线时如果想检查是否能够点亮,不太可能去制造相关的故障或状态来让仪表的灯点亮,所以输入输出控制这个服务就可以用在这里。
- 通过控制仪表控制器的输出变量,来直接控制点亮相关的警告灯,来达到检测目的。
- 请求打开远光灯,那么请求之后无论车内的开关什么状态,远光灯都是打开状态,但是要注意这个控制的值应该在符合其正常或安全的范围内才可以被执行
- 2F服务主要针对输入输出控制,列举常见的使用场景如下:
- 车窗的升降控制;(OutputControl)
- 雨刮器的启动关闭控制;(OutputControl)
- 直连执行器的启动与停止;(OutputControl)
- 车灯的开启与关闭;(OutputControl)
- ADAS相关功能的配置开启与关闭;(InputControl)
- LED报警灯的驱动与关闭;(OutputControl)
三.限制条件
- 一般输入输出控制仅在扩展会话下支持,且需要先通过安全访问才可以执行
- 一旦按照诊断会话服务所介绍的跳转到了默认会话,那么所有被改变的内容都会恢复到被控制之前的状态。
- 输入输出控制服务会通过一个数据ID以及ID所代表的数据参数来表示其所控制的一个或一类输入或输出内容,只有经授权的诊断工具才可以使用输入输出控制功能,而且只有在特定的车辆运行条件下该功能才能被激活。基本条件一般定义如下(不同的车企有不同的定义):
- 车速小于3km/h;
- 车速有效;
- 激活的输入输出并不存在严重的故障条件(根据特定的ECU/系统来定义);
- 系统不存在任何与操作者、驾驶员及乘客安全相关的隐患(根据特定的 ECU/系统来定义)
- 若上述任何一个条件不满足,ECU应该拒绝通信控制请求报文并发送否定响应码22h。
- 每个激活的输入输出将保持激活状态直到:
- 执行了ECU的硬件或软件复位;
- 由于任何原因,ECU由非默认会话模式切换到默认会话模式。
- 某些特殊的ECU可能会对该服务做特别的约束。这些需求需在该ECU的诊断文档中描述说明清楚。
- 用户的可选参数“控制选项”(ControlOption)应包含ECU输入信号、内部功能和/或输出信号的所需信息。
四.报文格式
0x2F这个服务是没有子功能的。这个需要特别注意。
1)请求报文
- 2F服务的request由4部分组成,第一部分就是SID;
- dataIdentifier,用于标识被控制的IO对象
- controlOptionRecord,用于标识控制方式,比如是启动、停止控制,还可以有一些自定义的参数来进行更精准的控制,比如让某个执行器的动作持续多长时间。
controlOptionRecord又分为两部分,分别是1个byte的inputOutputControlParameter,以及若干byte由厂家自定义使用的controlState,controlState就是要控制的状态参数 - controlEnableMaskRecord,这是一个可选参数,用于标识controlOptionRecord中的哪些parameter被使用。
- inputOutputControlParameter具体的值定义如下
Hex | Description | 描述 | controlState | 详细 |
---|---|---|---|---|
0x00 | returnControlToECU | 将控制权还给ECU,即结束控制 | 请求里不需要包含,响应里必须包含 | 诊断工具不再能通过 “ 输入输出本地标识符 ”控制输入信号,内部参数或输出参数 |
0x01 | resetToDefault | 将dataIdentifier所引用的输入信号、内部参数、输出信号等设为默认值 | 请求里不需要包含,响应里必须包含 | 请求通过“输入输出本地标识符”复位输入信号,内部参数或输出参数至缺省值 |
0x02 | freezeCurrentState | 将dataIdentifier所引用的输入信号、内部参数、输出信号等冻结住 | 请求里不需要包含,响应里必须包含 | :请求通过“输入输出本地标识符”冻结输入信号,内部参数或输出参数的当前状态 |
0x03 | shortTermAdjustment | 将dataIdentifier所引用的输入信号、内部参数、输出信号进行设置,其实就相当于开始了对ECU的控制 | 请求和响应里必须包含 | 请求通过RAM中的“输入输出本地标识符”调整输入信号,内部参数或输出参数的值至参数controlOption 中的值 |
2)肯定响应
- 肯定响应报文和请求报文格式少了一个参数,第一个字节是肯定响应的服务ID,后面紧跟着DID和inputOutputControlParameter,然后是控制状态,注意没有controlMask参数。
- ControlOptionRecord:表示控制模式及控制的相关参数组成的数据集;
- 在肯定响应当中,有单参数控制响应和多参数控制响应两种情况,具体体现在ControlOptionRecord中数据集的个数。
3)否定响应
于2F服务负响应的格式如下:
诊断服务负响应格式: 0x7F + Request SID + NRC。
以此类推,2F服务诊断服务负响应: 0x7F + 0x2F + NRC。