weixin_42967006的博客

1.什么是诊断车辆在运行过程中，不可避免地会发生一些故障，为了确保行车安全，我们要求车上的ECU能够实时监测部件的运行状态，一旦发现异常情况，能通过点亮报警灯等方式提示驾驶员。但是，点亮报警灯只能告诉驾驶员车辆发生了故障，最多只能定位到故障ECU，比如ABS报警灯亮说明ABS系统出现故障，但具体是什么部件发生故障并不能通过报警灯显示出来。这时就需要ECU在本地存储一个与故障相对应的故障代码，在进行维修的时候，可以通过车上的OBD接口连接诊断仪，把这个存储的故障代码读取出来，从而进一步定位到更加具体的故障部

本文我们先从整体的维度来介绍一下应用层协议，每个UDS服务都遵循本文中的协议。一、SI（Service ID）SI是UDS指令的第一个字节，我们第一篇文章中提到的10等服务就是指这个服务的SI=0x10，它是服务的标识，每个服务的SI都是唯一的。...

这篇文章给大家介绍一下14229-1中给出的服务原语（Service primitive）的概念，在开发的时候可以参考使用。一、应用层服务与协议的概念我们首先来看一张图：图中左侧是诊断请求的发送方，常指诊断仪，也称客户端；右侧是诊断请求的接收方，常指ECU，也称服务器。图中展示了诊断仪发送一条诊断请求，和ECU返回一条响应的过程，我们后面会逐步分析这个过程。我们首先来看图中分成了上下两部分，UDS属于应用层，但标准中进一步将其划分为两层——应用层服务（Application Layer Servi

第一篇文章中我们简要提到过服务器接收到客户端的诊断请求后的响应规则，上一篇文章我们详细介绍了诊断请求和响应的流程，现在我们来完整归纳一下服务器的诊断响应规则，即ECU接收到诊断仪的诊断请求后，应该按照哪些规则来决定给出肯定响应还是否定响应，如果给出否定响应，应该使用哪些否定响应码（后文统称NRC）。这部分内容在14229-1-2013版本的7.5章节。一、通用服务响应规则上图是标准给出的通用诊断响应规则。图中被划分为三部分：mandatory 强制的：这部分的规则是标准强制要求遵守的optio

从本章开始，会为大家详细讲解UDS中常用的诊断服务。标准中把UDS所有诊断服务分为了以下几个部分：诊断和通信管理功能单元数据传输功能单元传输储存的数据功能单元输入输出控制功能单元远程激活例程功能单元上传下载功能单元每个功能单元会包含多个诊断服务，每个诊断服务用我们前文提到过的SI——服务ID来作为标识，比如：读取故障码服务的SI是0x19，我们也常用19服务来指代读取故障码服务。我们本章先来介绍诊断和通信管理功能单元，共包含以下几个服务：我们可以看出，本章的服务都是用来控制UDS状

诊断会话控制服务（DiagnosticSessionControl）的SI是0x10，它是最为基础的一个诊断服务。1. 诊断会话的概念1.1 何为诊断会话。诊断会话其实也可以称为诊断模式，ECU在同一时刻必然会处于某一种诊断会话下，且只能处于唯一一种诊断会话下。 它类似于一个基础平台，不同的诊断会话所支持的诊断服务不同，同时也具有不同的诊断定时参数，如诊断响应的最大允许时间等。诊断会话总体上分为默认会话和非默认会话两种，非默认会话还可以进一步分为多个具体的诊断会话。1.2 诊断会话间的转换ECU

我们前一篇文章详细讲了诊断会话控制服务10服务，这篇文章来讲一下如何在CDD文件中配置这个服务和相关的诊断会话状态等内容。先来介绍下什么是CDD。CDD全称是诊断数据库，里面包含了一个ECU所有与诊断相关的内容，比如CAN诊断ID、支持的服务、故障码表等。CDD用Vector CANDelaStudio软件进行修改，可以加载到CANoe或CANalyzer中，就可以在CANoe或CANalyzer中直接发送诊断指令了，并且可以直接解析诊断报文中的指令和数据。CDD还可以加载到Diva软件中，Diva就可以

ECU复位（ECUReset）服务的SI是0x11，它相对来说比较简单。1. 概述ECU复位服务，顾名思义，就是可以用这个诊断指令来命令ECU执行自复位，复位形式有多种，依据子功能参数来进行区分。通常来说，ECU在收到一条诊断指令后，要先进行相应的处理，执行某些诊断操作，完毕后再发送肯定响应。但11服务是个特例，因为它的诊断操作是复位，复位后没办法再发送诊断响应，所以要先发送肯定响应，再执行复位。从发送完肯定响应到执行复位的这段时间内，ECU是否还可以响应其它诊断请求，标准中没有规定。2. 诊断请

1. 概念关于安全访问，我们前文已经提到过，这里再归纳总结一下：部分UDS操作具有一定的危险性，或会对ECU的功能产生永久性的改变，比如：输入输出控制会操作ECU外部的一些执行器，如果操作不当会造成部件损坏或人身危险写参数服务会通过改变ECU内部的一些标定参数来永久性的改变ECU功能，如改写发动机扭矩限值来提高车辆动力。BootLoader程序刷写功能所用到的服务会永久性地改写ECU中的程序。这一类的服务不允许随便执行，需要经过一个安全访问（27服务），在27服务被正确执行之后，ECU会进入

我们前文讲过，非默认会话下，如果ECU长时间没有收到诊断仪发送的诊断请求，会自动返回默认会话。UDS中为了使ECU保持在非默认会话，专门设置了一个诊断服务——诊断仪在线服务0x3E，我们通常也称为3E报文或心跳报文。它不会使ECU执行任何诊断操作，就是单纯的告诉ECU诊断仪仍处于连接状态。每当ECU收到这个服务指令，就会把返回默认会话的定时器清零。这是最简单的一个诊断服务。1. 请求报文格式3E服务的请求报文格式很简单，就是SI+子功能参数，这里列出的0x00和0x80两个参数的作用是一样的，不同的是

我们接下来两篇分别来讲通信控制服务0x28和控制DTC设置0x85，这两个服务有点类似，可以结合起来看。1. 概述通信控制0x28服务是用来打开或关闭ECU通信报文的接收或发送，它对ECU的所有通信通道有效，例如网关有多路CAN，这那么这个诊断服务就要对多路CAN上的通信报文都有控制作用。28服务起作用的是应用报文和网络管理报文，对诊断报文不起作用。28服务的应用场景通常有：给车上某个ECU进行程序刷写的时候，为了降低总线负载，要把其它ECU的通信报文的发送给停止掉。在测试时想模拟某个信号，替

1. 概述上文讲了28服务通信控制，可以停止通信报文的收发，本文讲85服务——控制DTC（故障码）设置。在ECU中，每个DTC都有一个状态，为一字节，每一位有不同的含义，例如bit0代表故障当前正存在。我们后文19服务中还会再详细讲，这里只需要知道通过DTC的状态可以得到这个故障当前是否发生、是否被确认等信息。正常情况下，ECU的故障检测功能模块会根据故障检测结果实时更新每个DTC的状态。而85服务就可以用来停止ECU更新DTC状态，简单来说就是停止故障检测功能，不记录新的DTC，原来记录的DTC状态

1. 概述时间参数控制服务（0x83）可以用来控制ECU内部诊断相关的时间参数，可以进行读取、修改等，但对这些参数的修改是暂时的，当诊断会话切换时（包含重新进入当前会话）以及重启ECU时，被控制的时间参数应该恢复默认状态。具体能够对哪些参数进行操作取决于ECU的支持情况。该服务不常用，可做了解。对时间参数的操作有以下四种：读取时间参数将时间参数恢复默认值读取当前激活的时间参数值设置时间参数值为制定数值标准推荐控制时间参数的流程是：① 诊断会话控制-进入非默认会话② 用读取时间参数子功

1. 概述链接控制服务（0x87）可以用来改变网络传输速率，最为常用的应用场景是在BootLoader刷写程序时临时提高传输速率，刷写完毕后再恢复正常，以提高刷写速度。链接控制服务只适用于集中特定的底层传输协议，例如CAN、Flexray等速率可变的通信方式。在改变传输速率前，要先校验ECU是否支持某种控制方式（用子功能0x01/0x02），校验通过后，再发命令改变传输速率。且如果改变传输速率的命令是用功能寻址发送的，那么应该将禁止肯定响应位置为有效，以防止某些ECU的通信速率已经改变后，另外的ECU

1. 概述在以往的诊断数据传输过程中，诊断数据都是透明的，第三方可以轻易获取。对于一些需要保密的诊断数据，标准定义了一种加密传输方式，即0x84-加密数据传输服务。简单来说，就是在发送诊断数据的时候，发送方先把数据加密，再用84服务发送，接收方收到后进行解密后再把诊断数据上报给应用层。按照标准的说法，是在应用程序和应用层（ISO 14229-1）之间添加一个加密子层，如下图所示：发送方和接收方之间要提前商定好加解密算法，且加密算法必须是对称加密（如AES），才能保证诊断数据发送到接收方之后能够被解

1. 概述基于事件响应（ResponseOnEvent）服务（0x86）顾名思义就是当ECU发生了某个事件或满足了某个条件的时候发送响应，这和以往我们介绍的一条请求一条响应的诊断通信方式有所不同。86服务的大体流程如下图所示：首先诊断仪要先向ECU发送请求，设置一个事件逻辑，之后再向ECU发送指令控制该事件逻辑的启动，指令中附带eventWindowTime参数，即事件有效持续时间。当事件逻辑启动时，如果发生了指定的事件，ECU就会返回一条响应。2. 执行规则（1） 86服务可以在任何诊断会话下

本章节我们来介绍数据传输功能单元，包含以下服务：这个功能单元的服务都是用来在客户端和服务器之间传输数据的，如从ECU中读取车速值，或向ECU写入一些配置参数，如最大扭矩限制等。我们最常用的就是22服务读取数据和2E服务写入数据，这两个服务都是不带子功能的，所以都不能禁止肯定响应。当然22服务本身就是要读取数据的，禁止肯定响应也没有意义。22服务和2E服务都会用到一个参数，叫做数据标识符（Data Identifier），记为DID。DID是2字节的无符号数，它是一条数据的代号，我们可以通过这个代号来

数据读取和写入这两个服务我们放在一起看，它们是相对应的一组服务，都很常用。1. 22服务读取数据请求报文格式下面是22服务读取数据请求报文的格式，就是SI+DID，允许在一条请求中同时包含多个DID，即同时请求多条数据，用户可自定义每次包含DID的最大个数。但实际使用的时候通常都是每次只请求一个DID。2. 22服务读取数据肯定响应报文格式22服务读取数据的响应报文格式就是SI+DID+数据，每条DID后面跟着它的数据。数据的长度和格式标准中没有定义，都是用户自定义的，我们后文会详细介绍几种常用的

1. 概述读取内存服务可以用来读取ECU内部RAM或ROM的数据。诊断指令中包含想要读取的数据地址和长度。通常内存中的数据都不允许被随意读取，尤其是Flash中的程序数据，随意读取会导致程序泄露，所以该服务一般要经过安全访问后才能执行。当ECU中数据存储地址有重叠的时候，比如有一个内部存储器一个外部存储器，二者地址重叠，那么此时可以用指令中内存地址(memoryAddress)参数中的一个字节当做存储器ID（memoryID）。是否采用这种方式用户可自定义。ECU要对该服务的诊断请求中的内存地址和数

1. 概述写内存服务允许诊断仪向指定地址处写入指定长度的数据。该服务通常被用于修改或清除Flash中的数据，或修改标定数据等。该服务通常也要经过安全访问才能执行，因为修改内存数据是比较危险的行为。当ECU中存在地址重叠的情况时，同样允许用指令中内存地址参数的一个字节来表示内存ID。ECU要对指令中想要写入的地址和长度做校验，主要有以下三方面：① 地址要对齐，要以最小写入单位为基准进行对齐，例向PFlash中写入数据，最小写入单位是32字节，地址就要32字节对齐。② 写入地址应在有效范围内，起始地

1. 概述该服务可以用来读取DID的换算信息，当我们不知道某个DID的数据应该如何换算的时候，可以先用这个服务读换算信息，再用22服务读取DID，来获取有效数据。2. 请求报文格式<<<回到总目录>>>...

1. 概述周期读取数据服务可以命令ECU周期性返回某个数据。该服务的DID都位于0xF200-0xF2FF范围内，所以该服务的请求报文中不包含DID完整的两字节，而是只包含低字节，省略了高字节0xF2.ECU发送数据的周期长短有三种模式：SlowRate，MediumRate，FastRate，每种模式发送数据具体的周期时间由用户自定义，ECU用哪种周期模式发送由指令中的transmissionMode参数控制。在同一时段内，一个DID只能处于某一种周期模式；不同DID是否支持不同的周期模式由用户自定

1. 概述动态定义DID服务允许诊断仪在ECU内部动态定义一个临时的DID，可以通过该DID读取一段内存的数据，也可以通过改DID一次性读取多个原有DID的数据。动态定义DID既可以是支持22服务的DID，也可以是支持2A服务的周期性读取 DID。该服务可以更加灵活地读取一些临时数据，也可以降低因频繁发送诊断请求和响应而导致的总线负载过高。动态定义DID有三种方式：通过原有的DID来定义；通过指定内存地址来定义；以上两种方式结合使用。该服务可以用一条诊断请求定义一个动态DID，也可以用多条

1. 概述存储数据传输功能单元其实就是读取故障码信息和清除故障码两个服务。我们本文就来看一下我们一直说的故障码是什么样子的。诊断故障码DTC顾名思义就是一个故障代码，每个代码对应一个故障。在OBD（排放相关诊断）中，DTC都是两个字节，UDS属于增强型诊断（OBD诊断是法规强制要求的，UDS不强制，故称增强型诊断），UDS中的DTC都是三个字节。与DTC相关的标准主要有：SAE J2012、SAE J1939、ISO 15031、ISO 27145，这些标准中定义了一些常用的DTC代码和解码方式。我

在ECU中，每个故障码会有一个字节长度的状态字节（statusOfDTC），DTC状态指示了该DTC所对应的故障是否发生、是否被确认等状态。DTC状态每一位的定义如下：我们结合下面的例子，来看一下这些状态在ECU实际运行的时候怎么使用：先来说一下图中的两个概念：Operation Cycle-操作循环：一个操作循环指故障监测功能从开始到结束的这一个周期，对于非排放相关ECU，整车厂或供应商可以自定义操作循环的具体概念，如定义为KL15从上电到下电。但对于排放相关ECU，法规有具体的要求，动力系统

1. 19服务概述从本文开始我们来介绍UDS最重要的一个功能——读取故障信息的功能，用到的是19服务，19服务有很多个子功能，如下图所示：19服务的每个子功能之间功能、请求响应格式都不大一样，所以我们后面几篇文章会分别介绍几个常用的子功能（图中标绿的子功能）。2. 19 01子功能本文我们先来介绍它的第一个子功能：0x01——通过状态掩码读DTC数量（reportNumberOfDTCByStatusMask）。它的作用就是获取ECU中符合要求的DTC的数量。2.1 请求报文格式19 01

19服务的02子功能是通过状态掩码来读取DTC（reportDTCByStatusMask），用来获取符合条件的DTC及其状态。1. 请求报文格式02子功能的请求报文格式和01子功能相同，子功能参数置为0x02即可。请求报文中的DTC状态掩码的用法也和01子功能相同。2. 肯定响应报文格式02子功能的肯定响应报文格式如下，子功能参数置为0x02，后面加一个字节的DTCStatusAvailabilityMask，然后跟着ECU中存储的符合DTC状态掩码要求的DTC信息，每个DTC后面跟着1字节DT

1. 何为DTC快照有的ECU在检测到一个故障的时候，不仅会记录DTC，还会记录故障发生时刻的一些车辆运行信息，如当时的车速、发动机转速、发生时间、水温等，这些信息可以帮助维修人员更快的查找故障原因。2. 请求报文格式04子功能的请求报文格式如下：这里面有两个参数：DTCMaskRecord：指想要读取哪个DTC的快照信息。DTCSnapshotRecordNumber：DTC快照记录编号，标准中定义DTC快照可以分成不同的组，包含不同的快照信息，用这个编号来表示请求哪个组的快照。这个参数

<<<回到总目录>>>

1. 概述19服务最后一个常用的子功能是0A-读取所有支持的DTC，这个子功能是让ECU返回所有支持的DTC，不论DTC状态如何、故障是否发生，都要返回。它通常被整车厂用来测试ECU中实际支持的DTC和预定义的DTC列表是否相符。这个子功能的报文格式比较简单。2. 请求报文格式0A子功能的请求报文就是0x19 0A：3. 响应报文格式肯定响应报文格式如下，是59 0A + ECU支持的DTC状态掩码 + ECU支持的所有DTC及其状态，每个DTC后面跟着1字节它的状态，如果故障没有发生，那么状态

1. 概述我们前面讲了如何读取DTC及相关信息，也讲到了DTC老化自动清除的概念。但是有些时候我们需要人工清除DTC，比如故障维修完毕后，如果等待相关DTC自动清除，会需要很长一段时间，这时我们就可以用14服务-清除DTC信息服务手动把故障码清除掉。14服务在下线检测时也经常使用，因为在装配的时候各个部件装配顺序有先有后，可能会导致ECU内部记录故障码，但在装配完成后相应故障就不再存在，所以在下线的时候要执行清故障码，保证车辆下线的时候所有ECU中都没有故障存在。14服务可以对ECU中DTC信息进行单

1. 概述输入输出控制（0x2F）服务是用来控制ECU的某个外部执行器的状态，或者是替换ECU某个输入信号的值。我们前面也提到过，下线检测的时候经常会用到这个服务，例如用诊断仪命令雨刷动两下，来判断雨刷功能及安装是否正常。在进行输出状态控制，即控制某个外部执行器的时候，要把ECU内部原本控制该执行器的上游逻辑切断，改由诊断控制；当进行输入状态控制，即控制某个输入信号的时候，要把实际输入信号（如传感器检测信号）切断，用诊断仪发送的输入信号值替换实际信号值。举个例子来说，当我们想控制雨刷的时候，ECU内

1. 概述例程控制服务（0x31）允许诊断仪向ECU发送诊断命令来开始或停止一段程序的执行，还可以请求例程执行的结果。例如ECU中一段函数的作用依次让外部的几个电磁阀动作，同时自检是否存在阀故障，ECU正常运行时这段代码不会执行，只有当收到诊断仪发送的31服务...

本章来介绍上传下载功能单元，这个单元里的服务都是用来在诊断仪和ECU之间传输大批量数据时用到的，一般用在BootLoader刷新应用程序中。包含以下服务：<<<回到总目录>>>

1. 概述36服务就是用来在诊断仪和ECU之间传输数据的，有两个方向：在下载流程中，是诊断仪发送的请求报文中包含数据，在上传流程中，是ECU返回的肯定响应中包含数据。36服务必须在34或35服务后开始执行。在传输数据的时候，因为网络层传输能力大小的限值，大多数情况下要传输的数据都不能用一次请求和响应传输完成，要分成多个36服务来传输，我们通常把每个36服务请求或响应中传输的数据叫做一个数据块。2. 请求报文格式36服务的请求报文格式如下：transferRequestParameterRec

1. 37服务报文格式请求退出传输（0x37）就是在所有数据都传输完毕后，诊断仪给ECU发指令使其结束整个数据传输的过程，恢复默认状态。它的请求报文格式如下：transferRequestParameterRecord参数是自定义参数，如果诊断仪和ECU之间需要在退出传输的时候传输一些数据，就可以用过这个参数传递。很少用到。37服务的肯定响应报文格式：通常37服务的请求就是2字节0x37，响应是1字节0x77。2. 37服务支持的否定响应码0x24-请求顺序错误：返回NRC 24有两种情

1. 概述请求上传服务是与0x34请求下载服务(点击这里回顾)的服务，二者的诊断报文格式类似，只是数据发送方向不同，请求下载是向ECU中写入一段数据，请求上传是从ECU中读取一段数据。上传数据的过程也会用到0x36传输数据和0x37退出传输，只不过0x36服务的诊断仪请求报文中不再带有数据，而是ECU发送的响应中带有数据。ECU在收到请求上传的诊断指令后，要进入准备上传数据的状态，一切准备做好后，再发送肯定响应。2. 请求报文格式请求上传的请求报文格式和请求下载的报文格式是一样的，参数含义也相同，

1. 概述请求文件传输服务是用在有文件系统的ECU上的，通常都是带操作系统的。该服务可以用来读取、新增、替换、删除某个路径下的文件，是0x34-请求下载和0x35请求上传两个服务在有文件系统的ECU上的替代服务。当读取、新增或替换文件时，会发生数据传输，这时也是使用0x36-传输数据服务和0x37-请求退出传输来完成数据的传输。2. 请求报文格式请求文件传输服务的请求报文格式如下表所示：下面我们来分别看一下其中的参数。① 操作类型-modeOfOperation操作类型参数（modeOfOpe

1. 简介我们前面讲的UDS是应用层的服务，UDS与底层传输介质无关，不仅可以用于CAN网络，还可以用于以太网、Lin等多种底层网络。15765-3是UDSonCAN的标准，定义了以CAN网络作为UDS的底层传输介质时的一些规则，主要是定时参数、交互规则和错误处理。2. 协议体系UDS on CAN的协议体系如下：15765-3和14229-1同属于应用层；网络层是15765-2，定义了单帧传输、多帧传输等传输规则；数据链路层和物理层是11898.在研究UDSonCAN的时候，需要区分是功能寻

1. 数据帧格式为了更好的理解网络层传输协议，我们这里先简要介绍一下CAN 和CAN FD。一帧CAN报文分为仲裁场和数据场，仲裁场包含我们常说的CAN ID，用来决定CAN帧的优先级，还有其他一些帧属性信息，数据场就是所要传输的数据。CAN 和 CAN FD帧格式对比如下：标准帧：扩展帧：这里对于每一位的具体含义不做详细的介绍，需要了解的可以查询ISO 11898标准，网上的资料也很多。大家着重关注以下**仲裁场（ArbitrationPhrase）和数据场（DataPhase）**的