UDS服务简易教程

2023-05-16

本文主要以简单易懂的描述向大家介绍CAN诊断基础知识,本文主要介绍CAN诊断中UDS服务的基本内容,主要参考文件ISO15765-2、ISO15765-3、ISO14229-1,读完本篇文章后希望进一步了解的朋友请查阅上述参考文件。

本人关于CAN诊断轻松入门系列的文章有第一讲至第三讲,其中

第一讲:CAN诊断网络层与应用层基本知识讲解

第二讲:CAN诊断UDS服务讲解

第三讲:CAN诊断DTC知识讲解

本文章适合汽车行业刚刚入门的嵌入式软件工程师、系统工程师、测试工程师及其余对CAN诊断感兴趣的朋友们。由于作者水平有限,本文章中难免会出现疏漏和不当之处,敬请批评与指正, 问题反馈邮箱:benyueting@163.com

欢迎关注本团队关于汽车车身电子系统嵌入式软件开发入门系列文章

《汽车车身电子系统嵌入式软件开发入门》

Yueting Ben:汽车车身电子系统嵌入式软件开发入门11 赞同 · 0 评论文章


目录:

  1. 基本说明

  2. 诊断服务格式

  3. 寻址方式

  4. 诊断服务

  5. 负响应码


1. 基本说明

UDS(Unified Diagnostic Services)可以说是外界与汽车内部建立诊断的语言,若外部诊断仪与汽车内部ECU共同遵循UDS协议,诊断仪即可通过UDS相应的指令向汽车内部ECU获取相应的反馈信息,如诊断仪需要读取ECU里面的软件版本等信息,可以通过22服务指令,想写入ECU配置信息,可以通过2E服务写指令,想读取故障信息可通过19服务指令。详细服务指令本文将逐个讲解说明。汽车里的诊断由请求与响应组成,这好比医院看病,医生请求诊断,病人回答医生的问题,汽车中诊断是由外部设备发起,如诊断仪,响应是汽车内部ECU执行,如BCM、GW、PEPS等车身电子器件。

ISO 14229-1对UDS共分了如下几大类,诊断和通信管理功能组,数据传输功能组,存储数据传输功能组,输入输出控制功能组,例行程序功能组,上传下载功能组,如下图所示


2. 诊断服务格式

所有的UDS服务都有相同的请求与响应格式,掌握好该格式,对理解UDS将会容易很多。诊断是通过诊断仪和 ECU 之间的请求和响应完成的,诊断的请求通常是从诊断仪到 ECU,响应则从ECU到诊断仪。

请求报文区分带子服务的请求与不带子服务的请求,响应分正响应与负响应,其中正响应区分对应带子服务的响应与不带子服务的响应,负响应都一样。

下述表格中缩写字母解释

M:强制的

S:强制的,需从参数列表中选择一个

U:用户自定义,可选择的

注:以下所有例子中的数据都为16进制格式,为表达简明,省去“0x”前缀

  • 含有子功能的请求报文

含有子功能的请求报文由请求ID,子服务ID,数据参数[可选]组成,如下图所示

例:10 01(请求切换默认会话模式)

例:19 02 FF(请求读取以0xFF为Mask的故障信息)

  • 不含子功能的请求报文

不含有子功能的请求报文由请求ID,数据参数[可选]组成,如下图所示

例:22 F1 90(请求读取DID为0xF190的数据)

例:37(请求数据传输退出)

  • 含有子功能正响应报文

含有子功能的响应报文由响应ID,子服务ID,数据参数[可选]组成,其中响应ID值为对应请求ID加0x40,如下图所示

例:

请求:10 01(切换默认会话模式)

响应:50 01 xx xx xx xx(成功切换默认会话模式)

  • 不含有子功能正响应报文

不含有子功能的响应报文由响应ID,数据参数[可选]组成,其中响应ID值为对应请求ID加0x40,如下图所示

例:

请求:22 F1 90(读取DID为0xF190的数据)

响应:62 F1 90 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10(返回DID为0xF190的数值为00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10)

  • 负响应报文

例:

请求:10 02(切换编程会话模式)

响应:7F 10 7E (错误切换至编程会话模式,NRC为7E )


3. 寻址方式

CAN是一种广播式的通信方式,即一条CAN报文发送出去后,在同一条CAN网络中的所有节点都能够收到该条CAN报文,那诊断仪在发出诊断请求报文后,具体是想诊断哪个节点,是通过什么方式判断呢?这里引出寻址方式的概念。

寻址方式有两种,一个叫物理寻址,另一个为功能寻址,物理寻址是诊断仪与单个ECU之间的诊断,而功能寻址是诊断仪与多个ECU之间的诊断,即诊断仪通过物理寻址方式发送请求报文时,只有指向的ECU可以回复响应报文;诊断仪通过功能寻址方式发送请求报文时,同一网络中支持功能寻址的所有ECU都需要回复响应报文。ECU收到诊断请求后,则通过消息的ID区分是物理寻址还是功能寻址,一般功能寻址的信号ID为0x7DF,物理寻址的消息ID为客户自定义,每个ECU都不一样。

例:整车同一网络中有ECU A, B, C, D多个节点,假设他们的物理请求消息ID为0x701, 0x702, 0x703, 0x704,响应消息地址分别为0x70A, 0x70B, 0x70C, 0x70D,所有ECU的功能寻址ID为0x7DF。

物理寻址时:

0x701 0x10 0x01 (对ECU A进行诊断请求)

0x70A 0x50 0x01 xx xx xx xx (仅ECU A响应)

功能寻址时:

0x7DF 0x10 0x01 (对所有ECU进行诊断请求)

0x70A 0x50 0x01 xx xx xx xx (ECU A响应)

0x70B 0x50 0x01 xx xx xx xx (ECU B响应)

0x70C 0x50 0x01 xx xx xx xx (ECU C响应)

0x70D 0x50 0x01 xx xx xx xx (ECU D响应)


4. 诊断服务

本文仅介绍常用的服务及格式,如下:

  • 诊断会话控制DiagnosticSessionControl(0x10)

  • ECU复位ECUReset(0x11)

  • 安全访问SecurityAccess(0x27)

  • 通讯控制CommunicationControl(0x28)

  • 待机在线TesterPresent(0x3E)

  • 诊断故障码设置控制ControlDTCSetting(0x85)

  • 读DID数据ReadDataByIdentifier(0x22)

  • 写DID数据WriteDataByIdentifier(0x2E)

  • 清除故障码ClearDiagnosticInformation(0x14)

  • 读故障码信息ReadDTCInformation(0x19)

  • 通过DID控制输入输出InputOutputControlByIdentifier(0x2F)

  • 例程控制RoutineControl(0x31)

  • 请求下载RequestDownload(0x34)

  • 传输数据TransferData(0x36)

  • 请求数据传输退出RequestTransferExit(0x37)

其余详细了解请参考ISO 14229-1文档。

  • 诊断会话控制DiagnosticSessionControl(0x10)

会话模式有默认会话模式(default session)和非默认会话模式(non-default session),非默认会话模式包含编程会话模式(ProgrammingSession)、拓展诊断会话模式(extendedDiagnosticSession)及其余会话模式。会话模式可以理解为诊断的功能模式,即在不同的会话模式下,能够支持不能的诊断功能,如在默认会话模式下,一般情况下不允许支持写服务(WriteDataByIdentifier0x2E),也不允许支持请求下载服务(RequestDownload0x34),而在拓展诊断会话模式下,就允许支持写服务(WriteDataByIdentifier0x2E),在编程会话模式下,就可以支持(RequestDownload0x34)。

DiagnosticSessionControl(0x10)为控制切换各个会话模式的服务。

如下图,为三种常用会话模式的转换图

  • 默认会话模式(default session 0x01)

  • 编程会话模式(ProgrammingSession 0x02)

  • 拓展诊断会话模式(extendedDiagnosticSession 0x03)

图4-1 常用会话模式切换

ECU在刚上电或者复位之后处于默认会话模式(0x01),默认会话模式下发送10 03可以切换至拓展会话模式(0x03),拓展会话模式发送10 02可以切换至编程会话模式(0x02),而在默认会话模式不可以直接跳转至编程会话模式,若在模式会话模式直接发送10 02,此时ECU需要响应NRC为0x7E(subFunctionNotSupportedInActiveSession)的负响应,响应内容为7F 10 7E。

如果ECU处于非默认会话模式下,客户端发送10 01进入默认会话模式,ECU收到该请求后,ECU的安全访问状态切换到锁定状态,由ReadDataByPeriodicIdentifer(0x2A)服务配置的周期调度被禁止,通过CommunicationControl(0x28)和ControlDTCSetting(0x85)进行的设置均被复位,即ECU初始化所有在非默认模式下激活的事件,设置和控制等操作,但不包括已经写入到非易失性存储位置的操作。

请求格式

正响应格式

负响应格式

  • ECU复位ECUReset(0x11)

ECU复位ECUReset(0x11)是控制ECU端执行复位的服务。诊断仪发送11 01复位请求后,ECU复位动作执行前,正响应需先发送给诊断仪,然后ECU执行复位操作,成功复位后,ECU需进入默认会话模式。

请求格式

正响应格式

负响应格式

  • 安全访问SecurityAccess(0x27)

安全访问SecurityAccess(0x27),此服务是提供访问ECU内部数据或者出于安全因素需被限制的诊断服务的请求权限。常见的如读服务(0x22)读取非安全信息时能够直接读取,不需要利用27服务进行安全访问,而通过写服务(0x2E)写入数据时,则通常需要通过27服务进行安全访问才可以写,刷新程序也需要利用27服务通过相关的安全等级才能够对ECU进行程序下载,显然这些都是需要利用27服务进行权限管控,从而保障ECU的安全可靠。

安全访问序列如下图所示,一共4步组成,

  • 诊断仪先发送请求seed的报文(27 01)

  • ECU响应seed(67 01 xx xx xx xx)

  • 诊断仪根据返回的seed按照约定算法计算key值,并发送给ECU请求验证(27 02 xx xx xx xx)

  • ECU收到请求之后,也按照约定的算法对该key进行校验,并给出响应,若计算一致,则为正响应(67 02),否则为负响应(7F 27 NRC)

图4-8 安全访问序列图

ECU若校验key一致,则ECU则切换安全状态至对应的解锁状态,此时在该解锁状态下能够支持的服务都应该可以工作。如果ECU已经处于解锁状态,此时诊断仪再次发送请求seed的报文,ECU应该响应seed为0的正响应。

seed请求的子服务值为奇数,对应的key请求验证的子服务值为该奇数加1,如27 01与27 02为一组安全等级,27 03与27 04为一组安全等级,27 11与27 12为一组安全等级。不同的安全等级由客户定义功能区分。

seed请求格式

seed正响应格式

key请求验证格式

key验证正响应格式格式

负响应格式

  • 通讯控制CommunicationControl(0x28)

通讯控制服务用于开启或关闭ECU对某些报文的发送或接收,如应用报文和网络管理报文等。

请求格式

正响应格式

负响应格式

  • 待机在线TesterPresent(0x3E)

该服务用于诊断仪端告知ECU诊断仪依然在线。该服务通常用于保持ECU处于非默认模式,由于ECU在S3server时间收不到诊断请求的话,ECU将会退回默认会话模式(default session),所以诊断仪为了保持ECU处于非默认模式,需要周期性发送TesterPresent服务指令,周期时间需要小于S3server。

请求格式

正响应格式

负响应格式

  • 诊断故障码设置控制ControlDTCSetting(0x85)

诊断故障代码设置控制服务用于停止或重启ECU诊断故障代码的记录。

当通过该服务对故障码记录进行抑制操作后,若会话层时序参数超时从而ECU进入默认会话,或ECU执行复位操作后,诊断故障代码应该恢复记录。

当接收到诊断仪发送的清除诊断信息(0x14)服务后,ECU应重新开启诊断故障代码记录。

请求格式

正响应格式

负响应格式

  • 读DID数据ReadDataByIdentifier(0x22)

根据DID(标识符)读取数据服务用于从ECU存储器中读取由DID所确定的数据记录值,其中DID为两个字节长度的数值。

ISO14229中定义该服务的请求报文允许支持1个或者多个数据标识符,一般主机厂仅支持1个DID读取。下图报文格式也以1个DID作为讲解。

请求格式

正响应格式

负响应格式

  • 写DID数据WriteDataByIdentifier(0x2E)

根据DID写入数据服务允许诊断仪将数据写入由DID指定的内部存储单元。ECU应在数据写入成功后发送该服务的肯定响应。

请求格式

正响应格式

负响应格式

  • 清除故障码ClearDiagnosticInformation(0x14)

正响应需在诊断信息清除请求后,ECU处理完成后发出,即使 ECU 没有存储的 DTC,也需发出正响应报文。清除 DTC 的同时,所有 DTC 相关存储信息都应被清除。

请求格式

正响应格式

负响应格式

  • 读故障码信息ReadDTCInformation(0x19)

请求格式

正响应格式

 

负响应格式

  • 通过DID控制输入输出InputOutputControlByIdentifier(0x2F)

该服务是用于通过DID来直接控制ECU对应的输入输出信号。

请求格式

正响应格式

负响应格式

  • 例程控制RoutineControl(0x31)

请求格式

正响应格式

负响应格式

  • 请求下载RequestDownload(0x34)

请求格式

正响应格式

负响应格式

  • 传输数据TransferData(0x36)

请求格式

正响应格式

负响应格式

  • 请求数据传输退出RequestTransferExit(0x37)

请求格式

正响应格式

负响应格式


5. 负响应码

https://mp.weixin.qq.com/s/-uQ5rnXooLnCeTlKF6Ii8A

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

UDS服务简易教程 的相关文章

  • 如何制作S32V234的Linux5.x版本BSP

    脚本是编译S32v Linux5 x版本bsp文件的流程 官方也有这个指导说明文档 xff0c 主要是第2 3章内容 xff0c 可以参考着执行 1 下面描述的所有步骤都已在Ubuntu 20 04LTS上 xff08 本机或通过虚拟机 x
  • C++经典面试题100例及答案

    1 面向对象的程序设计思想是什么 答 xff1a 把数据结构和对数据结构进行操作的方法封装形成一个个的对象 2 什么是类 答 xff1a 把一些具有共性的对象归类后形成一个集合 xff0c 也就是所谓的类 3 对象都具有的两方面特征是什么
  • C++面试100题,1——40

    C与c 43 43 有什么不同 xff1f 在c 43 43 中能使用引用就不要使用指针 xff0c 要改变一个一级指针就要用一个二级指针 要改变一个二级指针就要用一个三级指针 xff0c 会变得越来越复杂 A类中的func1是虚函数 xf
  • (TDA4 BSP )Texas Instruments Jacinto 7 J721E (DRA829/TDA4xM) BSP 如何制作?

    1 1 1 Download and Install the SDK Processor SDK Linux for J721e Documentation https software dl ti com jacinto7 esd pro
  • 解决Linux 环境 GLIBCXX_3.4.15‘ not found问题

    升级Centos系统之后 xff0c 运行filezilla时 xff0c 出现如下错误的提示信息 xff1a filezilla usr lib libstdc 43 43 so 6 version 96 GLIBCXX 3 4 15 3
  • 两台Linux服务器之间传输文件的四种方法(转载)

    在日常服务器租用中 xff0c 有时需要将文件从一台服务器传到另一台服务器 xff0c 下面给大家介绍四种linux服务器之间传输文件方式 scp 优点 简单方便 xff0c 安全可靠 xff1b 支持限速参数 缺点 不支持排除目录 用法
  • 任务间通信 | 邮箱、消息队列

    本文分享自中移OneOS公众号 任务间通信 上篇讲解了任务间同步 xff0c 在本篇中主要讲解任务间通信机制 xff0c 并对邮箱及消息队列进行详细介绍 通过对其概念 详细设计 接口设计等的讲解帮助开发者更好的理解其在操作系统中的应用 任务
  • c++ 条件变量的使用,实战

    include lt iostream gt include lt thread gt include lt mutex gt include lt condition variable gt using namespace std 线程通

随机推荐

  • SOA架构和微服务架构的区别

    1 SOA架构和微服务架构的区别 首先SOA和微服务架构一个层面的东西 xff0c 而对于ESB和微服务网关是一个层面的东西 xff0c 一个谈到是架构风格和方法 xff0c 一个谈的是实现工具或组件 1 SOA xff08 Service
  • 浅谈AP autosar 之 runtime 基础

    AP Autosar Architecture overview AP autosar在SOC 中的位置 xff0c 起到的作用 下面图可以看出 xff0c AP autosar封装了操作系统的接口 xff0c 封装了功能安全 xff0c
  • 「冰羚」— 撑起自动驾驶未来的“中间件”

    每当谈到自动驾驶的软件开发 xff0c 人们首先想到的 xff0c 是深不可测的人工智能算法 xff0c 是各种感知融合 xff0c 是各类路径规划 但是 xff0c 就算是再智能再高深的算法 xff0c 如果没有底层操作系统的支持 xff
  • 多核处理器的关键技术

    英特尔的cpu是从前代gt atom一路供货到第7代 xff0c 想必日常使用不会有太大区别 xff0c 而在系统之外可能存在一些散热方面的问题 而上市越早的处理器 xff0c 硬件供货越好 xff0c 可能在某些特殊时间段会出现不足 xf
  • LD_PRELOAD作用

    一 LD PRELOAD是什么 LD PRELOAD 是Linux系统的一个环境变量 xff0c 它可以影响程序的运行时的链接 xff08 Runtime linker xff09 xff0c 它允许你定义在程序运行前优先加载的动态链接库
  • C++ 之父的多线程编程建议——现代 C++ 对多线程/并发的支持(下)

    本文承接前文 现代 C 43 43 对多线程 并发的支持 xff08 上 xff09 xff0c 翻译自 C 43 43 之父 Bjarne Stroustrup 的 C 43 43 之旅 xff08 A Tour of C 43 43 x
  • C++关键字之Future promise and async()

    主线程将x传递给子线程 xff0c 子线程将结果x再传递给主线程 include lt iostream gt include lt future gt include lt thread gt using namespace std vo
  • C++ thread::hardware_concurrency 获取硬件支持并发数

    一 功能 获取硬件支持的并发线程数 二 返回值 正常返回支持的并发线程数 xff0c 若值非良定义或不可计算 xff0c 则返回 0 四 示例 include lt iostream gt include lt thread gt int
  • C++并发编程 unique_lock and condition_variable

    在t1线程中插入值 xff0c 在t2线程中取出值 include lt iostream gt include lt thread gt include lt vector gt include lt string gt include
  • ubuntu18.04+安装ros-melodic+安装realsense-ros包

    自己在安装的时候参考了很多博客 xff0c 但许多的方法很杂乱最后还失败了 xff0c 这里综合下自己尝试成功且比较方便的方法 xff0c 参考链接会在下文列出 安装ros melodic 参考 xff1a https www guyueh
  • [C++11 并发编程] 动态选择并发线程的数量

    C 43 43 标准模板库提供了一个辅助函数 std thread hardware concurrency xff0c 通过这个函数 xff0c 我们可以获取应用程序可以真正并发执行的线程数量 下面这个例子 xff0c 实现了一个并发版本
  • [C++11 并发编程] 17 超时等待 - clock和duration

    之前我们看到的所有等待机制都是不会超时的 xff0c 也就是说 xff0c 等待某个同步事件的线程会一直挂起 有些情况下 xff0c 我们希望设置一个最长等待时间 xff0c 使得程序可以继续与用户进行交互 xff0c 使得用户可以取消这个
  • 激光雷达和相机感知融合简介

    本文介绍激光雷达和相机融合的两种方法 xff1a 前融合 xff1a 融合原始数据 xff08 点云和像素 目标框 xff09 后融合 xff1a 融合目标框 前融合 前融合一般指融合原始数据 xff0c 最容易 最普遍的方式是将点云投影到
  • 聚焦芯片:GPU,CPU,SOC,DSP,FPGA,ASIC,MCU,MPU,GPP,ECU等都是什么?

    先上部分概念 xff1a CPU xff1a 中央处理器 xff08 Central Processing Unit xff09 是一块超大规模的集成电路 xff0c 是一台计算机的运算核心 xff08 Core xff09 和控制核心 x
  • 怎么样实现车辆信息安全

    1 车载IDS 正成为持续网络安全保护的核心要素 持续的网络信息安全风险管理正成为VTA的要求 通过IDS车载入侵检测可以为整个车队提供信息安全保护 但是 xff0c 分布式IDS的指导原则是什么 xff1f 为了满足UNECE WP29法
  • SOA通信架构和SOME/IP-SD的主要功能

    1 SOA面向服务的通信交互 如上图所示 xff0c 女神去热水澡堂洗澡 xff0c 想搓背 xff08 find服务 xff09 xff0c 于是她付要付搓背钱给澡堂老板 xff0c 这时澡堂老板知道通过小王和小明的毛遂自荐 xff08
  • OTA升级的实现原理

    一 简介 1 1 概念 OTA xff1a Over the Air Technology xff0c 即空中下载技术 OTA升级 xff1a 通过OTA方式实现固件或软件的升级 只要是通过无线通信方式实现升级的 xff0c 都可以叫OTA
  • 为什么特斯拉自动驾驶汽车不需要激光雷达

    光 糖果Autosar 2022 02 14 08 08 特斯拉仪表板 打造全自动驾驶汽车所需的技术堆栈是什么 xff1f 公司和研究人员对该问题的答案存在分歧 自动驾驶的方法范围从相机和计算机视觉到计算机视觉和高级传感器的组合 特斯拉一直
  • 架构与中台

    做架构工作最重要的是练好内功 什么是内功 xff1f 大局观 认知层次 xff0c 思维方式 xff0c 方法论 概念抽象能力等等都属于内功 零件设计主外 xff0c 架构设计主内 零件设计五花八门 xff0c 紧随新技术新热点 架构设计苦
  • UDS服务简易教程

    本文主要以简单易懂的描述向大家介绍CAN诊断基础知识 xff0c 本文主要介绍CAN诊断中UDS服务的基本内容 xff0c 主要参考文件ISO15765 2 ISO15765 3 ISO14229 1 xff0c 读完本篇文章后希望进一步了