UDS诊断

一、UDS介绍

        UDS即统一诊断服务,是汽车电子系统的诊断协议。UDS诊断就像汽车的“医生”,用一套标准的“问诊语言”和车辆对话,帮技师快速找到故障原因。

参考:《UDS协议从入门到精通(UDS速查手册)》(完结撒花版)_obdonuds-CSDN博客

1、为什么需要UDS?

        汽车有几十个ECU,比如发动机、变速箱、ABS等。如果某个部件出现问题,传统方法像“盲人摸象”,而UDS相当于给汽车装了一个“体检系统”,直接问汽车哪里不舒服。

2、它怎么工作?

        “问诊”方式:用诊断仪(类似医生的听诊器)通过车载通讯(比如CAN)给车机发指令。

        “症状”反馈:车机回复标准化的“故障码”,如“P0172(混合气过浓)”,而不是工程师才懂的乱码。

        高级功能:不仅能读懂故障,还能远程升级软件、重置系统、甚至测试某个零件是否正常。

3、实例

        车机仪表盘故障灯亮起,技师用诊断仪连上车,UDS告诉他“变速箱传感器异常,最近10次出现的记录时间是XXX,建议检查线路或更换传感器。”

4、关键特点

        统一标准:不同品牌的车用同一套“语言”。

        深度访问:能访问到刹车系统、气囊等核心模块(普通OBD权限低)。

        双向通信:不仅能读数据,还能对车下指令(比如打开空调)。 

二、常用术语

1、Service ID

        标蓝部分为常用服务。

2、诊断请求 

        诊断过程的请求响应模式:由诊断仪发送诊断请求,ECU在收到诊断请求后进行处理,然后发回诊断响应给回诊断仪(凡是能发送诊断请求的软件工具都可以称为诊断仪)。

        诊断请求和诊断响应的本质是一段符合UDS协议规范的16进制的报文。

        UDS规定每个诊断请求报文的组成:1Byte的SID+1Byte的sub-function+不定长的实际数据数据 

         UDS规定每个诊断的响应可以分为两种情况:肯定响应否定响应

        肯定响应:一次成功的请求响应,首字节必须为这次请求的SID+40。

        否定响应:一次失败的请求响应,首字节是7F,第二个字节是这次失败请求的SID,第三个字节是表示本次失败原因的否定响应码

3、否定响应码         

        否定响应码:negative response code(NRC)

        当一次UDS诊断请求响应失败的时候,ECU会返回一个否定响应码,它用于指示服务执行失败的原因。NRC用一个字节表示,每个取值对应不同的错误类型。

4 、UDS诊断的请求和响应的寻址

        以CAN总线为例。CAN总线挂载着数十个甚至上百个ECU,基于CAN协议,对于UDS的诊断请求报文,诊断仪是如何发送给ECU的呢?精准地找到想要诊断的ECU呢?ECU又是如何将诊断响应的报文返回给诊断仪的呢?

        在UDS协议中,除了规定26个服务的那些服务细节,还规定了诊断请求和响应报文发送时必须要指明寻址信息(包括源地址、目标地址)。

        假设一个汽车仪表的ECU,给它事先设定好了总线上发出CAN报文ID为701的报文,那就代表诊断仪是发送给这个仪表ECU自己的诊断请求报文 。

        基于CAN总线,UDS诊断通信的报文(就是CAN报文)通过CAN协议传输,请求和响应的地址信息就是CAN报文的ID;请求和响应的服务信息就是CAN报文中的数据域的字节。在车企中,会为总线上的每个ECU都设定一个唯一UDS诊断请求CAN报文ID,以及一个唯一的UDS诊断响应CAN报文ID。

        如上图:假设总线上有A、B、C三个ECU,A的车企设定的诊断请求的CAN报文ID就是701,诊断响应的CAN报文ID是709。

       诊断仪发送一帧ID为701的诊断CAN报文就只有ECU A进行处理并响应,这就是物理寻址; 诊断仪发送一帧ID为7DF的诊断CAN报文,所有ECU都会处理并响应,这就是功能寻址。企业里一般把功能寻址的ID设定为7DF。

三、UDS服务详述

1、诊断会话

        诊断会话就是车辆诊断时,诊断工具和ECU之间建立的“对话模式”,不同模式有不同的权限和能执行的操作。目的是保障安全、防止误操作,同时节省ECU资源。

        常见的诊断会话类型:

        (1)默认会话(基础模式)

        ECU启动后的默认模式,只能做基本操作(如读取故障码、重置ECU等)。

        (2)扩展会话(高级模式)

        执行高级操作(如清除故障码、读取传感器实时数据、解锁ECU、控制输入输出等)。诊断工具发送指令“进入扩展会话”,可能需要安全验证(类似输入密码)。

        (3)编程会话(“手术模式”)

        刷写ECU程序或更新软件(比如升级车载系统),必须通过严格的身份验证(如密钥匹配)。

        注意:

        ECU一上电就处于默认会话

        会话最大超时时间

        进入编程会话的前提是必须先进入扩展会话

2、10服务

        每种会话都有一个编号:默认会话是01;扩展会话是03;编程会话是02。 

        普通超时时间:P2

        扩展超时时间:P2Ex 

MICROSOFT 基础类库 : ZLG_UDS_DEMO 项目概述 应用程序向导已为您创建了此 ZLG_UDS_DEMO 应用程序。此应用程序不仅演示 Microsoft 基础类的基本使用方法,还可作为您编写应用程序的起点。 本文件概要介绍组成 ZLG_UDS_DEMO 应用程序的每个文件的内容。 ZLG_UDS_DEMO.vcxproj 这是使用应用程序向导生成的 VC++ 项目的主项目文件,其中包含生成该文件的 Visual C++ 的版本信息,以及有关使用应用程序向导选择的平台、配置和项目功能的信息。 ZLG_UDS_DEMO.vcxproj.filters 这是使用“应用程序向导”生成的 VC++ 项目筛选器文件。它包含有关项目文件与筛选器之间的关联信息。在 IDE 中,通过这种关联,在特定节点下以分组形式显示具有相似扩展名的文件。例如,“.cpp”文件与“源文件”筛选器关联。 ZLG_UDS_DEMO.h 这是应用程序的主头文件。 其中包括其他项目特定的标头(包括 Resource.h),并声明 CZLG_UDS_DEMOApp 应用程序类。 ZLG_UDS_DEMO.cpp 这是包含应用程序类 CZLG_UDS_DEMOApp 的主应用程序源文件。 ZLG_UDS_DEMO.rc 这是程序使用的所有 Microsoft Windows 资源的列表。它包括 RES 子目录中存储的图标、位图和光标。此文件可以直接在 Microsoft Visual C++ 中进行编辑。项目资源包含在 2052 中。 res\ZLG_UDS_DEMO.ico 这是用作应用程序图标的图标文件。此图标包括在主资源文件 ZLG_UDS_DEMO.rc 中。 res\ZLG_UDS_DEMO.rc2 此文件包含不在 Microsoft Visual C++ 中进行编辑的资源。您应该将不可由资源编辑器编辑的所有资源放在此文件中。 应用程序向导创建一个对话框类: ZLG_UDS_DEMODlg.h、ZLG_UDS_DEMODlg.cpp - 对话框 这些文件包含 CZLG_UDS_DEMODlg 类。此类定义应用程序的主对话框的行为。对话框模板包含在 ZLG_UDS_DEMO.rc 中,该文件可以在 Microsoft Visual C++ 中编辑。 其他功能: ActiveX 控件 该应用程序包含对使用 ActiveX 控件的支持。 其他标准文件: StdAfx.h, StdAfx.cpp 这些文件用于生成名为 ZLG_UDS_DEMO.pch 的预编译头 (PCH) 文件和名为 StdAfx.obj 的预编译类型文件。 Resource.h 这是标准头文件,可用于定义新的资源 ID。Microsoft Visual C++ 将读取并更新此文件。 ZLG_UDS_DEMO.manifest Windows XP 使用应用程序清单文件来描述特定版本的并行程序集的应用程序依赖项。加载程序使用这些信息来从程序集缓存中加载相应的程序集,并保护其不被应用程序访问。应用程序清单可能会包含在内,以作为与应用程序可执行文件安装在同一文件夹中的外部 .manifest 文件进行重新分发,它还可能以资源的形式包含在可执行文件中。 其他注释: 应用程序向导使用“TODO:”来指示应添加或自定义的源代码部分。 如果应用程序使用共享 DLL 中的 MFC,您将需要重新分发 MFC DLL。如果应用程序所使用的语言与操作系统的区域设置不同,则还需要重新分发相应的本地化资源 mfc110XXX.DLL。 有关上述话题的更多信息,请参见 MSDN 文档中有关重新分发 Visual C++ 应用程序的部分。
UDS(Unified Diagnostic Services,统一诊断服务)是一种基于ISO 14229标准的汽车诊断通信协议,主要用于车辆电子控制单元(ECU)的故障诊断和数据读写。UDS协议定义了诊断仪(Tester)与ECU之间的通信格式和流程,位于OSI模型的应用层,确保不同厂商的设备可以实现互操作性[^1]。 ### 故障码读取方法 在UDS协议中,故障码(DTC,Diagnostic Trouble Code)是用于标识车辆系统中异常状态的重要信息。故障码的读取主要通过两个诊断服务实现:**14服务**(清除故障码)和**19服务**(读取故障码信息)[^2]。 #### 19服务:读取故障码 19服务用于从ECU中读取当前存储的故障码信息。该服务支持多种子功能(Subfunction),用于获取不同状态的故障码。常见的子功能包括: - **0x01:读取所有当前故障码** - **0x02:读取故障码的快照信息** - **0x03:读取故障码的扩展数据** - **0x04:清除故障码并重置相关状态** 例如,使用19服务子功能0x01时,诊断仪发送请求报文,ECU返回当前存储的所有故障码。每个故障码通常由三个字节表示,其中第一个字节代表DTC的类型(如动力系统、底盘、车身等),后两个字节表示具体的故障代码。 #### 14服务:清除故障码 14服务用于清除ECU中存储的故障码。执行该服务后,ECU会将NVM(非易失性存储器)中的故障码清除,并重置相关的诊断状态(如冻结帧数据、故障计数器等)。需要注意的是,某些OEM可能会对故障码的清除操作进行限制,例如要求特定的安全访问权限或在特定条件下执行[^4]。 ### 实现方式 在实际应用中,UDS协议的实现通常依赖于底层通信总线,如CAN(Controller Area Network)。诊断仪通过CAN总线发送UDS请求报文,ECU接收到请求后解析并执行相应的诊断操作,最后将响应报文返回给诊断仪。 #### 诊断请求格式 一个典型的UDS诊断请求报文由多个字段组成,包括: - **SID(Service Identifier)**:服务标识符,用于标识请求的服务类型。 - **Subfunction(子功能)**:用于进一步细化服务的操作。 - **Data(数据)**:根据服务类型和子功能的不同,携带相应的参数或数据。 例如,读取故障码的请求报文可能如下所示(以CAN总线为例): ```c // 19服务,子功能0x01(读取所有当前故障码) uint8_t request[] = {0x19, 0x01}; ``` #### 诊断响应格式 ECU返回的响应报文通常包括: - **Positive Response(正响应)**:表示请求成功执行,携带所需的数据。 - **Negative Response(负响应)**:表示请求执行失败,包含错误代码。 例如,读取故障码的正响应可能如下所示: ```c // 正响应,包含故障码数量和具体的故障码 uint8_t response[] = {0x7F, 0x19, 0x01, 0x03, 0x01, 0x11, 0x22, 0x33}; ``` 在实际开发中,需要根据ISO 14229标准和具体的ECU实现,编写相应的诊断通信逻辑,包括报文的构造、发送、接收和解析。 ### 测试与验证 在车载网络测试中,故障码的测试是UDS诊断的重要环节。测试内容通常包括: - **故障码的生成与存储**:模拟故障条件,验证ECU是否能够正确生成并存储故障码。 - **故障码的读取与清除**:测试19服务和14服务的功能,确保诊断仪能够正确读取和清除故障码。 - **故障码的持久性**:验证故障码在断电后是否能够保留在NVM中。 - **故障码的容量管理**:测试ECU在故障码数量超过限制时是否采用FIFO策略进行管理[^4]。 通过上述测试,可以确保UDS诊断功能的可靠性和一致性,满足车辆诊断的需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值