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

UDS诊断在之前的文章中已经介绍了诊断报文在各个服务中的格式,以及故障码和DID的一些介绍,为了完整性,今天这篇继续进行补充,来介绍下RID和IOID(即Routine Control和IO control),看到他们的名字全称,从字面意思大家应该也能理解到,这2个是服务是控制类的,这也是我把他们呢放在一起进行介绍的原因。它们的不同点在于,一个是控制软件逻辑类,一个是硬件IO接口的控制。下面我们就对着2个服务进行一一介绍。

功能

31服务又叫Routine Control,该服务主要是对产品内部软件逻辑进行一些控制,比如在CAN/CANFD、亦或者DoIP升级的时候,对flash进行预擦除;或者拨打xcall电话;播放驱动AVAS声音等功能。

2F服务又叫IO control,也很简单,IO就是硬件接口,该服务就是对硬件接口进行控制,比如控制车窗的升降;后视镜的调节;以及内部灯光的控制等功能。从功能上来说,这2个非常相似,都是控制,区别在于一个是软件内部逻辑的控制,一个是IO硬件接口的控制。

命令格式

31服务的请求格式:31(服务)+01/02/03(子服务)+RoutineID+OptionRecord

所有的31服务必须包含的要有31(服务)+01/02/03(子服务)+RoutineID,而OptionRecord是可选3,只有在有需要的时候才会添加该数据,如果没有需要整个命令可不带有该部分。

关于RoutineControl Request SID和RoutineIdentifier我们不做过多的介绍,在31服务中RoutineControl Request SID就是固定的31会改变,而RoutineIdentifier会根据不同的DUT规范在器件设计之初就会定下来。不同的ID代表不同的功能。我们主要说的是Subfunction,在31服务中主要包含01/02/03 3种子功能,其中01代表startroutine(启动例程),02代表stoproutine(停止例程),03代表requestroutineresult(获取例程结果)。

其中启动例程是必须支持的,很明显如果例程没有被启动的话,就不存在停止和请求结果了,因此01必须支持;而停止例程和请求例程结果就是看各主机厂的需求或者具体的功能需要,可有可无。例如打开背光灯,这个动作是一瞬间执行完成的,那么很明显我们要无法对其进行停止操作,因此停止例程的功能有没有就没有什么必要了,但是我们如果是黑盒测试的话,我们可以通过获取例程请求结果来检查是否启动成功。

再比如擦除flash,由于这个过程是需要一段时间才能完成,这其中就会涉及到在擦除一半的时候我们想停止擦除,这就可以使用停止例程来终止该操作。

a95d571d7ad172ce986f4d75400273b6.png

2F服务的请求格式:2F(服务)+DataID+01/02/03(子服务)+MaskRecord

所有的2F服务必须包含的要有2F(服务)+DataID+子服务,而MaskRecord是可选,只有在有需要的时候才会添加该数据,如果没有需要整个命令可不带有该部分。

关于IO Request SID和DataID我们不做过多的介绍,在2F服务中IO Request SID就是固定的2F会改变,而DataID会根据不同的DUT规范在器件设计之初就会定下来。不同的ID代表不同的功能。我们主要说的是Subfunction,在2F服务中主要包含01/02/03 3种子功能,其中01代表ReturnControltoECU(控制权返回ECU),02代表stopcontrol(停止控制),03代表shortterm adjustment(获取控制权)。

相对于31服务来说,2F服务中常用的是01和03两个子服务,原因很好理解,你从其他地方拿到某个硬件的控制权,在使用后肯定需要返回给人家,不然别的ECU如何使用。

我们拿现在车上常用的MIC来举例,通常MIC是挂在中央控制器上,但是在拨打xcall的时候,我们需要从中央控制器手中将mic的控制权给到tbox,在xcall结束后,控制权回到中央控制器,这是个正常的流程,如果我们补还给中央控制器,那中央控制器将无法使用MIC。

0ba6cabfd9955a75fd5ef196b6ea16ae.png

肯定应答

肯定应答在看过我之前的文章,上面都有具体的命令描述,大家可以进行参考,之前手误对于2F服务的命令格式写错成跟31服务一样,已进行说明,大家看的时候可以注意下:https://mp.weixin.qq.com/s?__biz=MzkxMjI4ODMwMQ==&mid=2247483756&idx=1&sn=11846fee19a1f5a6c0a5ee3cc7103cff&chksm=c10e7e2ef679f738fa8ff7bcee74f9d23cea1e24de79a7cbe352b7f68d7dc406fe0e96d839cc&token=1465782712&lang=zh_CN#rd

否定应答

由于各个主机厂对于否定应答的规定都有一定的出入,这里不再进行全部的介绍,我们只说下一定支持的否定应答码一般有NRC 13(命令长度错误);NRC 12(子服务功能不支持)。其他的否定应答码我们根据主机厂的具体定义进行确认。

 

  • 2
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
UDS(Unified Diagnostic Services)是一种用于车辆诊断的标准协议,它定义了一套诊断服务和通讯机制,可用于汽车电子控制单元(ECU)之间进行通信和诊断31. 将要求来自所选控制单元的信息发回给UDS诊断工具或依据请求来在所选控制单元中执行一个操作的服务称为?答案是:Read Data By Identifier(按标识符读取数据)。 Read Data By Identifier是UDS诊断服务中的一种基础服务。它通过在请求中指定一个标识符来读取所选控制单元中的数据,然后将这些数据返回给UDS诊断工具。 在使用Read Data By Identifier服务时,UDS诊断工具会向所选的控制单元发送一个请求,请求中包含要读取的数据的标识符。控制单元根据这个标识符,从自己的存储器中读取相应的数据,并将其返回给UDS诊断工具。这样,UDS诊断工具就可以获得所需的数据,用于诊断和故障排除。 Read Data By Identifier服务的应用场景很广泛。例如,当车辆发生故障时,UDS诊断工具可以使用该服务来获取与故障相关的数据,以帮助诊断工程师分析和解决问题。此外,厂商和技术支持人员还可以通过Read Data By Identifier服务来获取车辆的状态信息、性能参数等。 总之,Read Data By Identifier是UDS诊断服务中的一项重要基础服务,它允许UDS诊断工具从所选控制单元中读取数据,并帮助诊断工程师进行故障诊断和解决问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

车载网络测试

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值