车载网络测试 - UDS诊断篇 - 诊断RID/IOID($2F/$31)

发布网友发布时间：2024-10-23 22:08

共1个回答

热心网友时间：2024-11-01 17:04

UDS诊断介绍中，着重讲解了诊断报文格式、故障码与DID概念后，本次将深入探讨RID和IOID，即Routine Control与IO control。这两个服务分别聚焦于软件逻辑控制与硬件IO接口控制，功能上虽有相似之处，但侧重点各异。接下来，我们将逐一对这两个服务进行解析。

功能详解

31服务，即Routine Control，专为软件逻辑控制而生。它的主要功能涉及CAN/CANFD、DoIP升级时的flash预擦除、拨打xcall电话、播放AVAS声音等。而2F服务，作为IO control，侧重于硬件接口控制，如车窗升降、后视镜调节、内部灯光控制等。功能上，两者紧密相关，均涉及控制概念，但区别在于控制对象的不同，一个针对软件逻辑，一个针对硬件接口。

命令格式解析

31服务的请求格式为31(服务)+01/02/03(子服务)+RoutineID+OptionRecord。其中31服务与子服务固定，RoutineID代表不同的功能，而OptionRecord为可选部分，仅在有需求时添加。同样，31服务的RoutineControl Request SID固定为31，RoutineIdentifier则由DUT规范决定，不同ID对应不同功能。

在31服务中，Subfunction分为01/02/03三类，01代表startroutine（启动例程），02代表stoproutine（停止例程），03代表requestroutineresult（获取例程结果）。其中，startroutine为必须支持的功能，停止例程与获取结果则依据主机厂需求或具体功能需要。

以闪存擦除为例，该操作需时间完成，中途可能想停止，此时可利用停止例程功能。再如打开背光灯，为瞬时动作，无需停止功能，但通过获取例程结果可检查是否启动成功。

2F服务的请求格式为2F(服务)+DataID+01/02/03(子服务)+MaskRecord。所有2F服务包含2F、DataID两部分，MaskRecord为可选部分。DataID根据DUT规范在设计初期确定，代表不同功能。2F服务的Subfunction包括01/02/03，01代表ReturnControltoECU（控制权返回ECU），02代表stopcontrol（停止控制），03代表shortterm adjustment（获取控制权）。

在2F服务中，常用01和03子服务，因控制权需在使用后返回原所有者，如中央控制器。以麦克风（MIC）为例，通常挂在中央控制器上，但在拨打xcall时，控制权需暂时转移至tbox，通话结束后，控制权回到中央控制器，确保中央控制器能再次使用MIC。

肯定与否定应答机制

肯定应答格式为：(sessionParameterRecord为各主机厂定义)。10服务的诊断正响应格式如上图所示，其中sessionParameterRecord的具体含义如图所示。

否定应答机制方面，不同主机厂的规定存在差异，但普遍支持的否定应答码包括NRC 13（命令长度错误）与NRC 12（子服务功能不支持）。其他否定应答码需根据主机厂的具体定义确认。