聊聊车载诊断那些事之基于CAN总线的UDS诊断—入门篇

目录

1.什么是车载诊断?

2.UDS on CAN

2.1 应用层诊断服务介绍

2.2 网络层时间参数介绍

3.小结


最近M哥忙于项目,距上次更新已经过去了许久,今日有时间一二,来跟大家聊聊车载诊断方面的内容,并对常用的UDS诊断进行介绍。

1.什么是车载诊断?

什么是诊断?首先拿一个最直观的例子解释:医生对病人的病情进行分析,来判断是那种疾病,这便是诊断。只不过诊断的对象为人。同样的道理,在我们的整车控制系统中,存在许多的ECU(电子控制单元),所有ECU正常工作来保证车辆的安全行驶;但是,在某些情况下总会不可避免的出现一些故障,导致部分功能无法工作,那么测试人员对故障进行分析定位的过程就是一个诊断的过程,诊断对象为ECU,即实现车载诊断通过诊断就可以判断是哪里出现的问题,通常是这一过程由ECU中存储的DTC(故障码)来决定。

在进行诊断时候,需要遵循UDS协议。其架构如下图所示:

 对于UDS的测试人员来说,主要运用ISO 14229和ISO 15765两个标准,来实现对应用层和网络层的诊断测试。以上两个标准涵盖了所有的诊断,常用的如:基于CAN总线和LIN总线的诊断。

2.UDS on CAN

基于CAN总线的UDS主要包括应用层诊断服务和网络层的时间参数。

2.1 应用层诊断服务介绍

诊断服务主要用来实现Client(Tester)和Server(ECU)间的数据传输。根据ISO 14229-1,将服务分为以下几类:

  • Diagnostic and Communication Management functional unit

        ①DiagnosticSessionControl (0x10) service

        ②ECUReset (0x11) service

        ③SecurityAccess (0x27) service

        ④CommunicationControl (0x28) service

        ⑤TesterPresent (0x3E) service

        ⑥AccessTimingParameter (0x83) service

        ⑦SecuredDataTransmission (0x84) service

        ⑧ControlDTCSetting (0x85) service

        ⑨ResponseOnEvent (0x86) service

        ⑩LinkControl (0x87) service

  • Data Transmission functional unit

        ReadDataByIdentifier (0x22) service

        ②ReadMemoryByAddress (0x23) service

        ③ReadScalingDataByIdentifier (0x24) service

        ⑤ReadDataByPeriodicIdentifier (0x2A) service

        ⑥DynamicallyDefineDataIdentifier (0x2C) service

        ⑦WriteDataByIdentifier (0x2E) service

        ⑧WriteMemoryByAddress (0x3D) service

  • Stored Data Transmission functional unit

        ClearDiagnosticInformation (0x14) Service

        ②ReadDTCInformation (0x19) Service

  • InputOutput Control functional unit

        InputOutputControlByIdentifier (0x2F) service

  • Routine functional unit

        RoutineControl (0x31) service

  • Upload Download functional unit

        RequestDownload (0x34) service

        ②RequestUpload (0x35) service

        ③TransferData (0x36) service

        ④RequestTransferExit (0x37) service

        ⑤RequestFileTransfer (0x38) service

2.2 网络层时间参数介绍

关于网络层时间参数的定义在ISO 15765-2规范中,主要包含以下参数:

N_As: 表示CAN数据帧从请求数据链路层发送至接收到对应的ACK的最大时间间隔;

N_Bs: 表示发送方数据链路层接受到流控帧的最大时间间隔;

N_Ar: 表示接收方从请求数据链路层发送流控帧至接收到对应的ACK的最大时间间隔;

N_Br: 表示接收方请求数据链路层发送流控帧的内在最大时间间隔 (N_Br + N_Ar)<(0.9倍N_Bstimeout);

N_Cs: 表示发送方请求数据链路层发送流控帧的内在最大时间间隔 (N_Cs + N_As)<(0.9倍N_Cr timeout);

N_Cr: 表示接收方接收到流控帧的最大等待时间间隔;
注:上述参数的下标r表示发送方,s表示接收方。

3.小结

本节内容是对UDS的一个总体入门介绍,不进行详细阐述。后续会陆续更新有关服务和时间参数更详细的内容,以及怎么使用,尽情关注。

如果觉得M哥分享的内容对你有帮助或有错误之处,请留言相告,感谢XDM支持!

  • 3
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
基于CAN盒编写UDS诊断程序是指利用CAN通信协议来实现统一诊断服务(Unified Diagnostic Services, UDS)的诊断程序。UDS是由国际标准组织制定的一种用于车辆诊断和程序编程的通信协议。 CAN盒是一种硬件设备,用于连接车辆的CAN总线诊断设备。它可以接收和发送CAN消息,提供对车辆CAN数据的读取和控制能力。 编写UDS诊断程序需要以下步骤: 1. 确定诊断需求:根据需要对车辆进行故障诊断、参数配置等需求,明确诊断操作和要求。 2. 准备CAN盒:选用合适的CAN盒,确保它具备与车辆CAN总线通信的能力,并配置好硬件连接。 3. 编写CAN通信模块:使用CAN通信接口的API,通过CAN盒与车辆CAN总线进行通信。建立和管理CAN通信连接,发送和接收CAN消息。 4. 实现UDS协议逻辑:根据UDS协议规范,编写相关代码实现诊断服务的逻辑。包括创建和解析UDS报文、处理诊断请求和响应、完成各种诊断功能。 5. 测试和调试:使用合适的车辆模拟器或真实车辆,对编写的UDS诊断程序进行测试与调试。验证程序的功能和性能,进行必要的修改和优化。 6. 部署和应用:将编写好的UDS诊断程序部署到适合的诊断设备上,例如车辆诊断仪、OBD扫描工具等。应用于实际的车辆诊断场景中,完成相应的诊断任务。 基于CAN盒编写UDS诊断程序能够有效地实现车辆的诊断和编程操作。通过CAN通信协议的高效性和灵活性,结合UDS协议的标准化和通用性,可以实现对车辆故障的诊断、参数的配置和调整等功能,提高了车辆维护和故障排查的效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

汽车测试M哥

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

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

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

打赏作者

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

抵扣说明:

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

余额充值