UDS简介

小亮亮虫

已于 2024-01-30 11:41:33 修改

阅读量1.3k

点赞数 9

分类专栏： uds 文章标签： mcu

于 2024-01-29 15:14:31 首次发布

本文链接：https://blog.csdn.net/yeweiliang_93/article/details/135912545

版权

uds 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

资料来源：
ppt内容由Vector公司制作，表示感谢。
https://zhuanlan.zhihu.com/p/135422985
感谢这位汽车行业网友。

学UDS的意义和目标：

毕业之后，就去做t-box,算由此进入了汽车行业，后来有短暂的去做了车机5个月，车载通讯模块1年，现在开始做毫米波雷达，也算一直在汽车行业里面。始终离不开的是can总线（CAN-BUS即CAN总线技术，全称为”控制器局域网总线技术“ControllerAreaNetwork-BUS）。

工作在汽车行业，特别是现在智能化趋势，肯定有大量物理信息采集，处理。这个过程中，涉及到器件的通信，据了解汽车有几百个这样的器件，在这样的使用场景下，总线是最好的物理连接信息交流方式，所以can总线在汽车行业很重要。

汽车使用周期，目前在国内是6到7年，其实10年以上都是有的,使用周期比较长，汽车零部件几百个。时间长就需要保养，器件多就需要人为定义一套协议，方便售后检查汽车的故障或者器件使用寿命。这个人为定义的协议就是UDS 全称为Unified Diagnostic Services，统一诊断服务，由ISO-14229系列标准定义。(看见ISO就知道，这个是国际组织定义的，目前也是使用最广的汽车诊断协议)

ISO-14229系列标准很庞大，涉及6大类，26个服务，我现在从事的不是专门去研究这个协议的工作，我们做到熟练知道14229的结构，熟悉常用的服务，遇到问题去查询相应的章节，就达到了我们的目标。这篇文章，我以Vector ppt为主线，解读ppt涉及的关键知识点，读完之后，对UDS有个了解就行，后面计划用Pyqt GUI 加 C/C++ 加 ZLG USBCANFD 200U 做个上位机客户端和上位机服务端进行诊断，这样才算基本算掌握了UDS.

0.前言

这张ppt截图，主要是保证Vector ppt的完整性，我也有点强迫性，不连贯，总有错过了一个亿的失落感，迫切想完整连贯的叙述，其实这张ppt没有实际用处，但还是截上，后面类似的，没实际用处的ppt就简略带过。
在这里插入图片描述

Diagnostics:诊断。（这个词在汽车行业太常见了。百度百科：从医学角度对人们的精神和体质状态作出的判断。）
诊断是确定、检查和分类一个系统的症状其目的是为了获得总体情况。
诊断的概念来源于医学，医生通过询问、观察病人，或者通过仪器检测，利用数据对病症做出判断。可以这么理解，医生询问病人，病人对医生的问题做出回答的过程。可以抽象为，医生主动向病人发送问题，病人对医生的问题思考之后，把答案返回到医生的过程。
在这里插入图片描述

诊断的一般目标：持续的监督车辆和精确的故障识别，以便以最小的成本和时间进行一站式的维修/维护。
车辆诊断的目：为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。
在这里插入图片描述

本篇文章内容大致分为三个部分，首先介绍诊断的基本概念，再为大家讲解UDS诊断协议，以及协议中常用到的诊断服务，最后对内容做一个总结。（Vector 诊断解决方案就不说了）
在这里插入图片描述

1. 诊断的基本概念

ECU和诊断测试仪之间的通信需要一个“诊断协议”。
诊断协议：ISO14230/ISO15031/ISO15765/ISO14229…
诊断协议定义了诊断请求/响应规则、请求的ECU处理行为，以及请求/响应消息的内容。
车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议，常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有我们熟悉的ISO 14229就是UDS协议，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。
在这里插入图片描述

UDS是Unified Diagnostic Services的缩写，在国际标准ISO 14229-1中定义，UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据，而到OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。
在这里插入图片描述

所以在2013年释放的UDS协议中，除了对通用诊断服务的定义以外，还增加了关于UDS在各个总线中应用的定义。
常用的基于can2.0是ISO 14229-3定义，基于以太网是ISO 14229-5定义等。可以从这里知道，ISO-14229是一套应用层协议，完全独立，和物理层链路层解耦分离的，可以基于铜芯双绕线can实现，也可以基于光纤以太网实现。当然需要中间网络层做数据结构的适配，这个后面再说。
在这里插入图片描述

随着车辆ECU的增多，车辆网络拓扑结构也越来越复杂，比如说一辆车需要有多种总线（CAN, CANFD, DoIP, FlexRay, LIN）
在这里插入图片描述

这张图就描述了UDS在OSI七层模型中的应用，OSI七层模型，第一层第二层分别定义了物理层和数据链路层，第三层第四层定义了网络层和传输层，第七层是应用层。
在这里插入图片描述

比如说我们熟悉的CAN总线，物理层和数据链路层遵循的是ISO 11898，而它的传输层遵循的是ISO 15765-2，在ISO 14229-3中定义了UDS基于CAN总线的应用，而现在比较火的以太网，它的物理层和数据链路层遵循的是ISO 13400-3，它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5
在这里插入图片描述

2 UDS诊断诊断协议

2.1 诊断服务的概念

在这里插入图片描述

首先来看服务请求和响应格式，“请求”由Tester端发送给ECU，请求报文里带有SID（Service Identifier的简写），根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”
NRC : Negative Response Code（否定响应码）。如果ECU不支持一个请求，做出否定响应（Negative Response），它会在第三字节回复一个NRC。不同的NRC对应着不同的含义，完整版参照ISO14229附录A。
在这里插入图片描述

Service Identifier，诊断服务标识符，简称为SID，一字节的无符号整数，用来指代某个诊断服务。诊断协议为每个诊断服务都分配唯一SID，因此更方便协议的软件实现。同时，在开发过程中沟通更加方便。比如，ReadDataByIdentifier服务是去按照ID去读诊断数据，直接说22服务会更加便捷。下图是协议服务的分布，可以大致从宏观上知道，网上常见的6大类，26个服务SID的划分。
在这里插入图片描述

下图是UDS目前全部的26个服务，在实际工作中，可能一半都用不到，如最近我做的boot刷写就只用到了13个服务，学习UDS，我们也是学习26个服务的常见常用的，掌握常用关键的几个，其他的就需要的时候再查询再看。
在这里插入图片描述

看两个名词，一个是Subfunction，另一个是ID。
有的UDS服务支持Subfunction的请求和响应格式，“请求”为“SID+一个字节Subfunction+具体的数据”，肯定响应为“SID+40 + Subfunction+具体的数据”。
有的UDS服务里面是不支持Subfunction，是支持DID的，DID：Data Identifier，那么它的请求格式为“SID+具体的DID+数据内容”，肯定响应“SID+40+DID+具体的数据”。
这里举出两个例子，一个是 “31例程控制服务”，还有一个是“2F IO控制服务”，31就是它的请求报文里面，带一个字节的Subfunction和两个字节的Routine ID，后面的这个数据是跟具体的数据内容，也可以没有具体的数据。2F是它的SID+两个字节的DID+一个字节的输入输出控制参数（这里注意这一个字节的数据类似于Subfunction，但是他不是Subfunction）+后面加具体的数据内容。
在这里插入图片描述

下面为大家介绍一个概念，为肯定响应抑制位。肯定响应抑制位是在Subfunction里的这个字节的最高位，我们把它叫做肯定响应抑制位。只有这个服务支持Subfunction的时候，才有可能支持肯定响应抑制位，当肯定响应抑制位置1的时候，要求所有的肯定响应受到抑制将不再发送。当肯定响应抑制位为0的时候，肯定响应是不被抑制的。这里要注意的是它只是抑制肯定响应，而否定响应是不被抑制的。
在这里插入图片描述

Tester发送的请求报文格式错误，或者请求发送的条件处于错误，ECU将发送否定响应，否定响应的格式是“7F+SID+NRC”，常用到的NRC在这里罗列了。
11表示服务不支持；
12 subfunction不支持；
13 请求的长度不正确，或者格式不正确
31 是请求超出范围；
7E 是在当前会话下subfunction不支持
7F 是在当前会话下服务不支持
在这里插入图片描述

来看两个时间参数，一个是叫做P2Sever，一个是叫做P2Sever*。当Tester给ECU发送请求过后，ECU需要在P2Sever时间内给出相应的响应，如果ECU当前正在处理别的任务，处理别的事情，而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78的Pending报文，告诉Tester “ECU正在忙”，之后会在P2Sever的时间内给出其它的响应报文，如果P2Sever的时间内还是不能给出相应的肯定响应和否定响应，将继续给出Pending报文，直到能够正确处理请求报文之后，会给出正确的响应报文。
在这里插入图片描述

UDS协议服务的6大类
诊断管理功能单元：
DiagnosticSessionControl (0x10)
数据传输功能单元：
ReadDataByIdentifier (0x22)
存储的数据传输功能单元：
ReadDTCInformation (0x19)
输入/输出控制功能单元：
输入输出控制由标识符（0x2F）
常规功能单元：
例程控制（0x31）
上传/下载功能单元：
RequestDownload (0x34)
在这里插入图片描述

今天会着重介绍26个UDS服务里的6个，分别是$10诊断会话控制，$14清除诊断信息，$19读取诊断信息，$22由DID读取数据，$27安全解锁服务，$2E由DID写入数据。
在这里插入图片描述

下面我们来看诊断会话控制就是$10服务
在这里插入图片描述

2.2 诊断会话控制0x10服务

ECU会有不同的会话控制，所以ECU在不同的阶段，比如说开发，生产，售后阶段也会用到不同的会话模式，因为每个服务功能的不同，也会在诊断规范里定义这些服务所支持的诊断会话模式.
在这里插入图片描述

这张表是14229里面，对各个诊断服务，对会话控制的支持情况，比如说通信控制28服务，要求在默认会话下不支持；27安全解锁服务，在默认会话模式下不支持；和刷写相关的34,36,37服务，在默认会话下也是不支持的。
在这里插入图片描述

我们来看会话控制有关的3个NRC，首先来看NRC 7F，NRC 7F是指在当前会话下服务不支持。28通信控制服务，要求在默认会话下是不支持的，在扩展会话下能支持。而当ECU处于默认会话的时候，我们上位机发送了28这个服务，ECU收到之后，会回复NRC 7F的否定响应。
在这里插入图片描述

NRC 7E和NRC 7F 不同的是：NRC 7E是在当前会话下Subfunction不支持。一个用的比较多的用法是，编程会话是不能够由默认会话跳转到编程会话的，只能由扩展会话跳转到编程会话。但ECU处于默认会话的时候，执行了10 02 编程会话的请求，ECU会回复NRC 7E的否定响应。
在这里插入图片描述

再来看NRC 31，NRC 31常用的用法是请求超出范围，比如说22服务，发送的DID，是ECU不支持的，比如说发送的请求22 01 01 ，因为ECU不支持01 01这个DID，会发送NRC 31的否定响应，还有一个用法是：22在3个会话（默认，编程，扩展下都是支持的），22后面所跟的DID来读取数据的DID对各个会话等级是有要求的，比如说读取硬件版本号在编程会话模式下是支持的，读取车速在编程会话下是不支持的，当ECU处于编程会话的时候，来通过 C0 01来读取车速，那么ECU会回复NRC 31的否定响应。
在这里插入图片描述

这个是会话状态的一个状态机，状态机之间可以互相跳转，状态机自身也能跳转，我们把除了默认会话之外的会话状态，都叫做非默认会话状态。当ECU一上电的时候是处于默认会话状态，我们通过$10服务，比如说发送10 03, 10 02来将会话状态由默认会话跳转到非默认会话。由非默认会话执行10 01跳转至默认会话。当ECU处于非默认会话的时候，S3 time这个时间超时，ECU也会从非默认会话跳转到默认会话。为了防止ECU从非默认会话跳转至默认会话，我们要求Tester端周期发送3E服务Tester present，让ECU一直维持在非默认会话。（或者发送其他的请求报文，来激活保持会话状态）那么S3 time这个时间怎么用呢？我们来看下面这张图
在这里插入图片描述

Tester端会利用S3Client周期发送Tester present给ECU，ECU收到Tester present比如说3E 00，3E 80的服务请求，会让ECU维持在非默认会话，如果Tester端S3server这个时间内，比如说5000毫秒时间内，都没有给ECU发送任何诊断请求报文，那么ECU就会从非默认会话跳转到默认会话；如果ECU处于解锁状态，也会从解锁状态跳转到锁定状态。通常S3cleint时间小于S3server的时间，比如说网关延时的一些情况。
在这里插入图片描述

这个是10服务的请求和响应格式。SID+一个字节的Subfunction（常用的有01默认会话，02编程会话，03扩展会话），它的肯定响应格式是50（就是10+40）+一个字节的Subfunction（就是诊断会话类型）+4个字节的会话参数。
在这里插入图片描述

支持的NRC有3个，12：subfunction不支持；13：请求格式或者长度错误；22：条件不支持。
在这里插入图片描述

2.3 安全访问0x27服务

在这里插入图片描述

常用到的服务：2E服务通过DID来写入数据；2F通过DID来控制输入输出端口的数值；还有ECU刷写有关的编程服务。这些服务都会改变和影响一些内存里的数据，或者输入输出端口的一些值，所以这些服务是一个被保护的服务。这些服务只有ECU处于解锁状态下才能够执行，而ECU一上电处于锁定状态，那么ECU如何从锁定状态跳转到解锁状态呢？
在这里插入图片描述

我们刚才也提到了ECU一上电处于锁定状态，只有执行了安全解锁的流程后才能跳转到解锁状态，一个ECU可以同时拥有多个安全等级，多个安全等级之间可以是相互独立的，也可以是有依赖关系的，比如说要求先解锁安全等级1才能解锁安全等级2，那么当ECU处于解锁状态的时候，会有几种情况会使ECU由解锁状态跳转至锁定状态，比如说执行了11复位服务，比如说有了重新上下电，还比如说有了执行10会话切换，也会让ECU由解锁状态跳转到锁定状态。
当ECU处于解锁状态的时候Tester端再去请求种子的时候，回复的种子全为0。
在这里插入图片描述

要求Tester端和ECU端进行27解锁服务之后，ECU才能够处于解锁状态，那么这个解锁的过程是一个固定的：首先由Tester端给ECU发送请求报文来请求种子，ECU收到这个报文后，回复肯定响应，肯定响应里带有种子数；Tester端收到这个种子数，根据自己安全算法算出来一个K1发送给ECU，ECU也有自己对应的安全算法，他由这个Seed算出来一个密钥K2，当ECU收到这个K1后和自身计算的K2进行比较，如果两者是一致的，那么ECU发送肯定响应给Tester端，告诉Tester端ECU已经解锁。
在这里插入图片描述

这个是请求种子的请求报文和肯定响应报文。请求报文为“27+01”；肯定响应“67+01+四个字节的种子”。
在这里插入图片描述

当Tester端计算得到了一个密钥，它会发送“27+02+4个字节的密钥”给ECU。当ECU将两者密钥比较后，它认为比较的结果是一致的，ECU会给Tester端发送“67+02”，认为ECU已经处于解锁状态。
在这里插入图片描述

那么当ECU已经处于解锁状态的时候，Tester端又一次请求了种子，发送了请求种子的请求报文给ECU，那么ECU就会回复“种子数全为0的肯定响应”报文给Tester端。表明ECU现在处于解锁状态。
在这里插入图片描述

这个是27服务支持的所有NRC是在14229-1里定义，比如说我们常用的NRC 12；NRC 13；这里注意NRC 24是一个请求顺序错误，比如说我们要求的安全解锁状态过程必须是先请求Seed再发送key，如果你没有执行请求seed的请求报文，直接发送了key，就会回复NRC 24；比如说35是非法Key，如果Tester发送了非法的密钥给ECU，ECU就会回复NRC 35；NRC 36是尝试次数超限，比如说这是要看具体的诊断规范定义，有的定义请求尝试次数不能超过3次，那么Tester端发送给ECU的Key连续3次错误的时候，ECU就会回复NRC 36；NRC 37指延时还没有到，因为在有的诊断规范里定义请求的尝试次数达到最大值的时候，ECU会锁定一段的时间，在这个时间之内，你的Tester端是不能够再次请求种子的，所以在这个时间之内，比如说有的整车厂用到10秒延时，Tester端再一次发送了请求种子的请求报文给ECU，那么ECU就会回复NRC 37的否定响应报文。
在这里插入图片描述

2.4 读/写DID的0x22/0x2E服务

在这里插入图片描述

首先来看22服务的请求和响应格式，请求格式“22+两个字节的DID”；它的肯定响应“62+DID+所读取的数据”。这里举出了一个例子，比如说现在的DID是F1 86来读取当前的诊断会话状态，它的肯定响应格式“62+ F1 86+02”读取当前处于编程会话状态。
在这里插入图片描述

在14229-1 2013版附录C里面列出一些推荐使用的DID和这些DID的功能，大家也可以去看一下这个附录C
在这里插入图片描述

22服务支持的NRC。NRC 13是请求格式不正确；NRC 14读取的数据已经超过了传输的最大值，就是超限了；NRC 31我们刚才也已经提到过了，比如说请求的DID不支持，请求的DID在当前会话下不支持；NRC 33要求在解锁状态下，而现在没有处于解锁状态执行了响应的请求。
在这里插入图片描述

看一下由DID写入数据：2E服务。他的请求格式“2E+2个字节的DID+需要写入的数值”；肯定响应的格式“6E + DID”。这里举出来一个例子，由F1 90来写入VIN码，写入一个17字节的VIN码，这里简化，就打了省略号。当写入成功后，ECU回复肯定响应“6E +F1 90”
在这里插入图片描述

2E服务支持的NRC。NRC 31；NRC 3E；NRC 33；NRC 72和编程有关的，比如说在Bootloader刷写的过程中，需要对Flash进行操作，而写入数据没有写成功的时候，会回复NRC 72
在这里插入图片描述

2.5 故障存储相关的0x19和0x14服务

在这里插入图片描述

什么是故障呢？当系统检测到了一个错误或者是一个故障发生的时候，会将相对应的数值故障码进行存储，那么这个对应的数值故障码，我们称之为故障码，就是DTC(Diagnostic Trouble Code)。
一个DTC可以反应出一个故障发生的具体位置，和这个故障发生原因和类型，我们通过读取的DTC信息，可以为维修提供一些依据。除此以外还有与法律有关的故障，比如说排放有关的，在未来还会有安全相关的故障
在这里插入图片描述

通过这个故障可以反应出在ECU具体的哪一个位置，和产生的故障类型，在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。那么我们常用的UDS服务里面DTC格式用的是哪一种呢？有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式
在这里插入图片描述

ISO 15031-6定义的DTC格式什么样的呢？
两个字节的根字节来定义DTC，
左边bit7 bit6 两位能反应DTC到底是哪一个系统：
00表示Powertrain;
01表示底盘；
10表示车身；
11是网络相关的。
左边bit5 bit4 反应的是，DTC到底是由ISO，SAE，这些标准组织所定义的故障，还是由整车厂来定义命名的故障；
左边bit3 bit2 bit1 bit0 反应的是车辆系统的区域；
右边8位，这个字节具体的编码，就是DTC的编码。
在这里插入图片描述

在14229-1中定义的19服务读取DTC信息里，定义28个Subfunction，根据不同的Subfunction来获取不同的诊断信息，在这里我们介绍4个不同的Subfunction，这4个Subfunction也是在规范中常用的，他们分别是02；04；06；0A。

19 02由DTC的状态码获取DTC；
19 04读取DTC的快照数据。在14229里定义的数据叫做快照数据；在Autosar里定义的数据叫做冻结帧，其实他们指的是一类数据。快照数据是指当这个错误发生，或者当这个DTC存储的时候，记录的一些环境数据，比如说车速，水温，发动机转数等这些数据，从而我们读取这些数据之后，能够更好的判断DTC产生的原因以及发生故障原因。
19 06是来获取DTC存储的时候一些扩展数据，这个数据常用的比如说有一些计数器，比如说老化计数器，这样的数据。
19 0A是来读取这个ECU所支持的全部的DTC，ECU支持的哪些DTC是在ECU诊断规范的时候已经定义好的，所以我们通过19 0A读取的DTC是这个ECU应该支持的所有的DTC，即使这个DTC没有产生，也能够被读取的

刚才我们提到了DTC状态字节，这个DTC状态由8个位组成的一个字节。这8个位分别代表不同的含义，具体这8个位代表的含义，包括这8个位初始值是什么，它什么时候被置1，什么时候又被清0，它在什么情况下用，怎样用，在14229-1 2013版附录D有详细的定义。大家如果想具体了解这8个位的定义，可以参看附录D。
这里要提醒大家的是除了Bit4和Bit6以外，其它所有位的初始值都应该为0，而Bit4和Bit6的初始值位1。
常用的有比如说Bit0和Bit3.
Bit0当检测到这个故障，发生错误的时候被置1；
Bit3 ConfirmedDTC根据具体DTC的应用逻辑，这个DTC被检测到了多次，这个次数由具体的ECU规范定义，那么这一位也应该被置1。
在这里插入图片描述

我们通过19 02读取DTC的时候，会用到3个不同类型的DTC Status，那么这3个不同的DTC有什么区别呢：

在请求报文里有一个字节的DTC Status Mask，这个是被Test用来读取DTC数据的，这个值可以是00到FF之间的任意值，根据所要读取的DTC内容决定。如果你想读取这个ECU产生的所有DTC，你可以用 0xFF.
在肯定响应中，也有一个字节DTC Status Availability Mask，这个字节的DTC Status，是ECU诊断规范里定义的，ECU支持的。
在肯定响应中，读取的DTC后面还有一个字节，是反应的这个DTC，所产生时，对应的状态信息。

我们来看具体的请求和响应格式，首先看19 02。19 02后面跟一个字节的Status Mask，第0位和第3位被置1，而这一个字节Mask，是在ECU诊断规范定义的，所以 59 02 +一个字节的Mask+具体的DTC+DTC后面的跟的DTC Status。
如果有多个DTC，后面会重复DTC的格式：3个字节的DTC+DTC Status。
通过19 0A读取ECU支持的所有DTC，请求格式是两个字节“19 + 0A”；肯定响应格式“59 + 0A+一个字节的Mask+后面跟ECU支持的所有DTC”
在这里插入图片描述

例如
混合动力汽车电池温度传感器电路电压高于阈值,产生DTC 0x0A9B17 statusofDTC 0x24(0010 0100)
A/C 电路间歇中断产生DTC 0x25221F statusofDTC 0x60(0110 0000)
离合器位置传感器-电路对地短路产生DTC 0x080511 statusofDTC 0x2F(0010 1111)
Tester请求的Status Mask 0x84(1000 0100)
ECU支持的Status Mask 0x7F
那么0x84 & 0x7F—>0x04(0000 0100)

0x04 & 0x24 不等于0
混合动力汽车电池温度传感器电路电压高于阈值 0x0A9B17 0x24 满足过滤条件
0x04 & 0x2F 不等于0
离合器位置传感器-电路对地短路 0x080511 0x2F 满足过滤条件
0x04 & 0x60 等于0
A/C 电路间歇中断不满足过滤条件

请求：$0x19 0x02 0x84
应答：$0x59 0x02 0x7F 0x0A 0x9B 0x17 0x24 0x08 0x05 0x11 0x2F
在这里插入图片描述

$0x19 0x04读取DTC的快照数据.($19服务很重要，需要时间研究再补充)
在这里插入图片描述

$0x19 0x06 获取DTC存储的时候一些扩展数据
在这里插入图片描述

当诊断故障信息被存储了以后，问题我们已经通过维修的方式解决了，我们用什么样的方法将这个DTC清除呢？
用到14服务清除诊断信息，14服务格式很简单，请求格式是“14 + 3个字节数值”，这3个字节的数值可以是针对单个DTC清除，也可以是按组来清除DTC，也可以是清除全部DTC。当3个字节都为FF时，表示将ECU里产生的所有DTC清除。
在这里插入图片描述

那我能不能按照组来清除DTC，比如说清除和车身有关的DTC，就按照车身这个组的数值，将它添加到请求报文格式里；
那我能不能单独清除，只针对某一个DTC，清除这个DTC，也是可以的。只需将这个DTC的具体数值放在请求报文，那么肯定响应格式是一个字节0x54。
DTC组在14229中也有描述，大家可以具体参看。
在这里插入图片描述

2.6 诊断中的通信方式

在这里插入图片描述

UDS定义在应用层
在这里插入图片描述

物理寻址，即1对1通信，用于知道确切的被诊断ECU的地址；
在这里插入图片描述

功能寻址，即1对n通信，或者说广播发送，用于不知道确切的被诊断的ECU的地址，向一组或者全体ECU发送请求；
在这里插入图片描述

通常地址
地址信息（SA、TA、TA_Type）被映射到1个CAN-ID
每个ECU有两个CAN ID用于物理地址：请求/响应
每个ECU有一个CAN ID用于功能地址：请求
所以一个ECU有三个地址，物理地址，响应地址，功能地址
在这里插入图片描述

在基于广播的总线协议上，从Tester到ECU的点对点连接.
Tester 向can 总线上发送ID:0x600 + 数据，ECU_A做出应答向can总线上回复ID:0x602+数据。为什么ECU_A做应答，其他ECU没有做应答？因为Tester向总线发送的ID:0x600, 这个是ECU_A的 Physical Request地址，其他ECU接收之后，判断不是自己的地址，所以不做应答。
ECU_A:
Physical Request :0x600
Response:0x602

ECU_B:
Physical Request :0x604
Response:0x606

ECU_C:
Physical Request :0x608
Response:0x60A

ECU_D:
Physical Request :0x60C
Response:0x60E
在这里插入图片描述

从Tester到广播总线协议上的更多ecu
Tester向总线发送ID:0x6FF,这个ID表示功能地址，所以其他ECU收到之后都要做应答, ECU_A 用0x602+数据向can总线响应Tester的功能请求。
Tester:
functional request 0x6FF

ECU_A:
Response:0x602

ECU_B:
Response:0x606

ECU_C:
Response:0x60A

ECU_D:
Response:0x60E
在这里插入图片描述

无分段消息传输
应用层可以发送大于8字节的数据，如发送VIN 17字节，但是CAN2.0 规定一帧can报文最大数据域是8字节，那么大于8字节怎么用8字节的一个数据帧发送呢？这个就是15031协议做的事情了，当应用层发送大于8字节数据的时候，就需要对大于8字节数据进行分为多个8字节数据帧发送。当接收到8字节数据帧时候，需要考虑是否需要组成大于8字节的整体数据。
在这里插入图片描述

网络层传输数据涉及4种类型的帧数据：
SingleFrame : 单帧
First Frame : 首帧
Flow Control : 流控帧
Consecutive : 连续帧

单帧适用于应用层发送的数据长度小于等于7字节的情况下。can2.0 数据域最大8字节，其中第一个字节需要给网络层使用，这个字节用来标识这个数据帧的类型和后面有效数据长度。第一个字节的bit7~bit4 赋值为0，标识这个数据帧是单帧类型，第一个字节的bit3~bit0 标识这个数据帧有效数据的长度，如下图是3，表示数据帧有三个有效字节 I S O
在这里插入图片描述

应用层数据大于8字节的时候，就需要分段发送了，如下图就是应用层发送24字节的数据，就需要分多帧数据来发送。
在这里插入图片描述

首帧，表示要发送多帧数据的时候，第一帧数据就是首帧，首帧里面前两个字节被网络层使用。第一字节的bit7~bit4 为1的时候表示First Frame首帧，bit3~bit0 + 第二字节表示多帧有效数据的长度。
在这里插入图片描述

流控，当发送方如这里的A要发送多帧数据的时候, 发送了FF(首帧)数据帧到了B后，B需要响应流控帧，以告诉A, 接收方B是否可以接收数据，接收的最小连续帧时间间隔。
流控帧里面前一个字节被网络层使用。第一字节的bit7~bit4 为3的时候表示Flow Control流控，bit3~bit0表示流控的状态，一般情况都是0.
在这里插入图片描述

连续帧，当发送方如这里的A要发送多帧数据的时候, 发送了FF(首帧)数据帧到了B后，B需要响应流控帧，以告诉A, A接收到了B的流控帧之后，A开始连续发送Consecutive Frames连续帧。
流控帧里面第一个字节被网络层使用。第一字节的bit7~bit4 为2的时候表示Consecutive Frames连续帧，bit3_{bit0表示连续帧的序列号，范围是0x00}0xFF，但是第一个连续帧的序列号是从1累计到0xFF，再到0,1,2… … 0xFF
在这里插入图片描述

当A诊断仪发送的连续帧的帧数达到了B 被诊断响应的流控帧里面参数BS时候，这里是BS=2，表示B方允许A方发送2帧连续帧，就需要等待B方流控帧的应答了。
在这里插入图片描述

A诊断仪继续发送连续帧到B被诊断者。
在这里插入图片描述

多帧传输的完整过程。
在这里插入图片描述

2.7 小结

在这里插入图片描述

服务请求和响应格式：
在这里插入图片描述

3个常用的类，6个常用的服务：
在这里插入图片描述

响应超时时间P2 和 P2*
在这里插入图片描述

会话超时时间S3_client S3_server
在这里插入图片描述

在诊断过程中，有两种寻址方式，物理寻址一对一的方式，功能寻址一对多的方式。数据传输有两种形式，单帧传输传输小于等于7字节数据，多帧传输传输大于等于8字节数据。
在这里插入图片描述

保证ppt的完整。
在这里插入图片描述

3 结尾

上述，仅仅算是UDS的简单概述，因为在我看来，软件工程师，需要对ISO 7层模型，简化成3层，都要熟悉，从上到下应用层14229-3 网络层15765-2 物理链路层11898，而上述仅从宏观层面简单介绍了下，有很多知识点经不住细想的，为什么单帧多帧都是8字节传输，而不是7字节或者9字节传输？ UDS使用的场景有EOL下线检测，售后故障诊断，flash OTA等场景，大致使用的服务其实在13个左右，目前仅介绍了6个。还需要不断的对UDS进行学习。