汽车CAN网络及UDS诊断应该如何学习？

good

本人在一家汽车零部件公司工作两年，目前工作主要在试验方面，基本了解uds及相关规范，基于uds的软件刷写也有接触，平时接触到的软件有CANOE，CANALYSER和VS3，职业规划想从事CAN网络软件开发，但由于试验出身，网上资料纷杂，实体书本少之又少，请各位前辈指明方向，或者有哪些好的书本资料可以学习？不胜感激！

原文地址：https://www.zhihu.com/question/284708378

清风寡欲

​回顾接触UDS的过程

        自毕业后，我一直干了2年的Autosar CAN通讯开发。
        开发的主要内容简单概括就是：应用报文开发、网管报文开发、休眠唤醒开发，及CAN网络相关故障开发，并没有涉及UDS开发，但虽然没有涉及开发，但多多少少都听过一点（特别是后来跑路的时候，恶补了学习了一手，嘿嘿）。
        我刚开始接触诊断相关内容的时候，对诊断没有任何概念。所以听到同事们讨论什么SID啦、DID啦，DTC啦，什么27啦。
        不能说听得不太懂，只能说一脸懵逼。
        小小的脑瓜大大的问号，SID？SID是什么？怎么还有DID，DTC？它们是什么关系，他们是一个类别的东西吧？长得这么像！
        所以就百度，好了，假设你是一个对UDS诊断没有任何概念的小白。你看看百度出来的东西。


        你看看上面这图，我就问你，你说这是小白能看懂的东西吗？？什么每种服务都有自己独立的ID，我连服务是什么鬼都不知道，我看得懂才怪了。
        所以，我连SID的概念都花了好久才搞明白。
        于是，我问同事，有没有什么资料能够学习UDS，然后，他们都告诉我，让我看14229-1和15765-2这两个标准文档。
        然而，一个文档三四百页，内容这么多，怎么看啊，主要是，对小白来说，如此多内容的文档，是很难捉住重点的，这样就很费劲了。
        有一次，领导把我派去了测试部支援3天，让我跟着一个测试部的同事测UDS的内容，想起来也挺不好意思，这3天我也没帮到什么忙，主要是不懂这些数据，举个小栗子，看下面这张图。


        这一串串数据，让一个对诊断没有任何概念的小白来看哪里能看懂啊。
        后来，我明白了什么是SID、DID，什么又是DTC，诊断报文的这些数据要怎么看。
        但是，由于没有具体开发过UDS，因此并不知道这些东西具体是怎么去开发的。比如19服务有个DTC状态码，这个状态码是要怎么开发？是Autosar配置工具配置的吗？还是不需配置静态代码已经全部实现？
        两年过去，在换了一个企业后，有机会开始正式开发UDS和对UDS进行完整的测试，让我对UDS从概念上的认识进入到了UDS各个具体内容开发的认识。
        下面就开始讲一下我理解的UDS基本概念。
<hr/>UDS的作用



        当一辆汽车出现故障的时候，维修人员会拿着诊断仪接上汽车，然后读取出车上的故障信息，这样就知道车上什么地方出故障了。（这只是其中一个功能，另外还有软件升级、标定等等。）
        能实现山上面这个过程，就是因为有UDS的存在。
我们所说的诊断UDS开发，就是代码实现上面图中“ECU-A”的诊断功能。最终使得ECU-A能够根据诊断仪的请求，返回对应的数据信息。
UDS的宏观认识

        就像地球总共由7块大陆组成一样。且先不管UDS的具体细节内容，UDS世界总共由以下这些“大陆板块”组成：




        大家把这些大陆板块称之为：SID，即：诊断服务ID，简称“服务” 。每一个服务都有它的独特的职能。(车企常用到的每个服务后续我会每个都写一篇去展开描述。)
        整个UDS都是围绕上面这些服务展开的，服务下面又会有子服务。这就好比“国家”的概念。“国家”是不会做事情的，做事情的是“国家”下面的各个“部门”，你可以把各个诊断服务理解为各个“国家”，子服务理解国家下面的“部门”。
        举个栗子：28服务（CommunicationControl）有下面的这些子服务。


       28服务它的作用是通讯控制，但是真正具体干活的是它的各个子服务，比如0x00：使能报文的发送和接收。
UDS的CAN通讯链路

       UDS的最终目的，是如一开始那张图。告诉诊断仪自己的故障信息、通过诊断仪升级软件、标定等等。
        而通讯总线，就是实现这些功能的媒介。​
        所谓的UDSOnCan，其实就是字面意思：基于CAN总线的UDS。
        大家都知道，汽车上不止有CAN总线，可能还有LIN总线、以太网等等。所以，UDS还可以“On”在其它总线上。我们这里讲的是UDSOnCan，如下图。


         从上面这张官方标准的图就可以看出UDS在整个CAN通讯中的链路了，但会比较抽象。
        所以我按照Autosar的架构画了下面的图，UDS的整个链路如下图红色线所示：


        UDSOnCan相关协议如下图示。


11898：这个是关于CAN总线的相关标准。比如它会描述CANH、CAHL的电平要求是多少、一帧CAN报文的结构定义、关于CAN Tranceive的一些要求等等。从上面的图中也可以看到，不只是诊断报文的这部分要满足11898，网管报文、应用报文也是同样要满足这个。实际上，所有的CAN报文，都得满足11898。
15765-2：这个就是诊断报文的传输协议标准，比如发送多帧时要如何发送，每帧的时间间隔等等。
14229-1：到这一层，才是真正打开UDS的世界，具体的UDS功能都在这个标准文档中定义。
        诊断开发。一般来说实际上是指CANTP模块（15765-2）、DCM模块和DEM模块（14229-1）。

UDS的报文种类

        UDS总共有3种报文。物理请求报文、功能请求报文、响应报文
        我们先来讲一下为什么会有这3种诊断报文。
        由于一辆汽车上有十几个ECU。因此，诊断仪对车上ECU的操作共有两种情况。
        ①对某一个ECU单独进行操作。比如读取某一个ECU的故障信息、升级某一个ECU的软件
        ②同时对所有ECU进行操作。比如整车处于唤醒过程中，大家都在往外发送报文，总线负载率相对较高。但诊断人员现在需要对某一个ECU升级软件，总线负载率高可能会影响，因此，需要先让所有的ECU都停止发送应用报文。这时候就需要通知所有ECU停发应用报文。
        根据上面第①种情况。就出现了第一种诊断报文类型：物理请求报文。每个ECU都有自己唯一的诊断物理地址。当ECU接收到物理地址是指向自己的诊断报文时就要根据这帧报文的请求内容做出对应的操作。简单来说，就是一对一。
        根据上面第②种情况。就出现了第二种诊断报文类型：功能请求报文。在同一个CAN网络上所有ECU的功能地址是一样的。在同一个CAN网络，当ECU接收到功能地址的诊断报文时都要根据这帧报文的请求内容做出对应的操作。简单来说，就是一对多。
        好了，物理请求报文和功能请求报文都是ECU要接收的诊断报文，ECU接收到诊断报文后需要回应。因此就出现了第三种诊断报文类型：响应报文。
        上面的描述可以用下面两张图表示：




        另外需要注意的是：物理请求报文是支持回应多帧的。而功能请求报文只支持回应单帧。这在15765-2中8.3.2.4就有说明。


<hr/>结束

到这里为止。关于UDS的一些基本概念应该就差不多了。接下来我会先讲一下15765-2，即UDSOnCan的“OnCan”，也即CANTP层。



朋友们，关注下我呀，我以我过来人，再用小白的角度认真写的知识总结一定让你的脑子饿肚子进来，扶墙出去...
返回目录
Autosar BSW 开发笔记（目录）

检验医师

[6 诊断]
同系列文章点击以下链接：
汽车系统安全 功能安全 与网络安全
开发者视角的汽车电控功能安全和诊断设计
特斯拉 AP （autopilot）和FSD（Full Self-Drive）
从最近炒得火热的“幽灵刹车”AEB想到说...
漂移、甩尾——不可不说的摩擦圆
汽车电源模式
当你发现你的同事们连ASPICE是什么都不知道就开始讲敏捷...
[全网唯一中文] 通用Volt混动架构解读笔记丰田THS混动架构解读笔记（Toyota THS/GM Volt/Honda Pruis系列之二）

2 什么是UDS

UDS，unified diagnostic services。汽车行业诊断通信的需求规范，规定诊断相关的服务要求，不涉及通信机制。
电子系统故障的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议。
常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有就是ISO 14229（UDS协议），在UDS协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。



UDS诊断协议是ISO15765 和ISO14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层。
可在不同的汽车总线（例如CAN, LIN, Flexray, Internet 和K-line）上实现。
UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。
UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据。
OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。
2.1 OSI七层模型

在2013年释放的UDS协议中，除了对通用诊断服务的定义以外，还增加了关于UDS在各个总线中应用的定义。
下图描述了UDS在OSI七层模型中的应用，
比如说我们熟悉CAN总线，物理层和数据链路层遵循的是ISO 11898，而它的传输层遵循的是ISO 15765-2，在ISO 14229-3中定义了UDS基于CAN总线的应用；
而现在比较火的以太网，它的物理层和数据链路层遵循的是ISO 13400-3，它的传输层也就是DoIP遵循的是ISO 13400-2, 它的UDS基于以太网的应用是ISO 14229-5；


OSI（Open System Interconnect），即开放式系统互联，一般叫OSI参考模型，是ISO（国际标准化组织）组织在1985年研究的网络互连模型。
OSI模型把网络通信的工作分为7层。
1至4层被认为是低层，这些层与数据移动密切相关。
5至7层是高层，包含应用程序级的数据。每一层负责一项具体的工作，然后把数据传送到下一层。
由低到高具体分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。





2.2 诊断服务

所有的UDS服务都有相同的请求与响应格式。
诊断是通过诊断仪和 ECU 之间的请求和响应完成的，诊断的请求通常是从诊断仪到 ECU，响应则从ECU到诊断仪。
CAN是一种广播式的通信方式，即一条CAN报文发送出去后，在同一条CAN网络中的所有节点都能够收到该条CAN报文。
诊断仪在发出诊断请求报文后，具体是想诊断哪个节点，有两种寻址方式，一个叫物理寻址，另一个为功能寻址。ECU收到诊断请求后，则通过消息的ID区分是物理寻址还是功能寻址，一般功能寻址的信号ID为0x7DF，物理寻址的消息ID为客户自定义，每个ECU都不一样。
物理寻址
诊断仪与单个ECU之间的诊断，即诊断仪通过物理寻址方式发送请求报文时，只有指向的ECU可以回复响应报文；
功能寻址
诊断仪与多个ECU之间的诊断，诊断仪通过功能寻址方式发送请求报文时，同一网络中支持功能寻址的所有ECU都需要回复响应报文。
2.3 $19服务

$19拥有28个子服务(Sub-Function)。（见后图）
常用的子服务有：
0x01
reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC（Diagnostic Trouble Code）数量）
(读取符合掩码条件的DTC数量)(必须支持),后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读。在肯定回复时，组合应该是59(19+40) - 01 (子功能) - 09 (本ECU所支持的掩码条件)-01 DTC的格式(ISO14229-1为01) - 00 01 (目前满足条件的DTC有一个)
0x02
reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC）
(读取符合掩码条件的DTC列表及其状态)(必须支持)，后面的参数是DTC状态掩码，解读同上。在肯定回复是，59 - 02(子功能)- 09(本ECU所支持的掩码条件) - XX XX XX ( DTC,车厂定义 ) - 01 (这个故障码怎么了，01表示当前故障)
报文格式及内容
发 送： 19 +02+DTCStatusMask（状态掩码）
正响应： 59+02+DTCStatusAvailabilityMask（ECU支持的状态掩码）+DTC-状态位
0x04
reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的记录数据(快照)如发生某一故障记录DTC时的车速，电源电压状态等）
(读取快照信息)，也叫冻结帧。
为了方便找到故障的原因，在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因。

0x06
reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的环境数据，环境数据包括DTC状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此DTC产生时的测量数据。）
0x0A
reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态）
(读取ECU支持的所有DTC列表及其状态)(必须支持)。这个就不必发DTC状态掩码了。所有支持的DTC列表及其状态都会打印出来。




















2.3 $14服务 清除DTC

客户端通过该诊断服务清除ECU中存储的诊断信息。
请求格式分为两个部分，
第一部分：请求SID：0x14，占用一个字节
第二部分：groupOfDTC，由厂家自定义，占用三个字节
groupOfDTC为3个FF代表清除所有DTC，$14+FF+FF+FF，标识清除所有DTC

3.2 CRC检错码的工作原理

一般情况，一个由二进制数位串组成的发送序列，可以用一个只含有0和1系数的多项表达式的系数
表示出来，例如：代码1001011对应的多项式为X6+X3+X+1，再如：代码为1010111，则对应的
多项式X6+X4+X2+X+1.
CRC检错码是采用多项式相除的运算方法实现的，如被处理报文的比特序列对应的多项式为P
(X)，收发双方约定的多项式为G(X),用P(X)除以G (X)后，求得余数多项式R(X)，并将多项式R(X)附
加到多项式P(X)的后边，生成M(X)，这样能保证M(X)除以G(X)的余数为0.此时，可以将M(X)作为
发送序列发给接收方.接收方用收到的报文N(X)去除同样的G(X)，如果余数等于0，则说明接收到的
序列与发送的序列一致，接收到的数据没有错误；否则，说明传输过程中出错，由发送端重发，重
新开始CRC校验，直到接收到的数据没有错误为止.
M 2022-11-06

卡卡

在车载诊断中常用的诊断协议有ISO 14229等，在协议中主要定义了诊断请求、诊断响应的报文格式及ECU该如何处理诊断请求的应用。其中ISO 14229系列标准协议定义了用于行业内诊断通信的需求规范，也就是UDS。UDS主要应用于OSI七层模型的第七层——应用层，它支持的汽车总线包括：CAN、LIN、FlexRay、Ethernet及K-LINE。UDS中的服务根据其功能分为6大类，共26种。其中包含的0x19服务（ReadDTCInformation）则是UDS中的重中之重。
服务介绍

19服务（ReadDTCInformation）用于读取ECU的DTC故障信息，此服务允许客户端从服务器读取诊断故障代码（DTC）的相关信息。此服务包含28个子服务(Subfunction)，常用的5种子服务如下：

0x01 reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC数量）
0x02 reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC）
0x04 reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的快照数据）
0x06 reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的扩展数据，扩展数据包括DTC状态，优先级，发生次数，时间戳，里程等。）
0x0A reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态）

今天主要解析19服务中的04子服务，也就是检索客户端定义DTC的快照号对应的快照记录数据，在AUTOSAR中也叫冻结帧。
04子服务介绍

1、快照数据概念介绍

前面讲19服务常用子服务的时候，提到了Subfunction为04的子服务，使用04子服务对服务端进行请求，可以获取DTC发生时记录的快照数据。那04子服务是如何获取快照数据的呢？首先我们需要理解什么是快照数据。从ISO 14229-1协议可知，快照数据为发生某一故障时记录的DTC的电压、发动机转速、时间戳等，从而使工程师在ECU出现故障时能及时了解车辆的历史和实时故障信息。
2、报文格式介绍

接下来通过介绍19 04子服务请求和响应的报文格式，分析报文中各个字节的相关定义。
请求格式




图1

从图1中可知，19 04的请求报文包括四个部分，其中服务ID和Subfunction就不用过多解释了。DTCMaskRecord表示某个故障的DTC，当系统检测到一个故障发生时，则会存储其对应的故障数值，这个故障数值就是DTC。通过读取DTC可知一个故障发生时的具体位置以及原因和类型。通常UDS中DTC占3个字节，OBD Ⅱ占2个字节，在ISO 15031-6中定义的DTC由两个字节根基和一个字节的故障类型组成。我们通常用到的DTC格式都是由ISO 15031-6中定义的。图2是ISO 15031-6中定义的DTC的两个字节根基，图中很详细地解释了每一个Bit的含义。



图2

SnapshotRecordNumber需要提前定义，可以有多个。如SnapshotRecordNumber设置为FF，则表示读取所有的快照数据组。
响应格式




图3

图3为响应报文格式，当使用19 04对ECU进行请求时，ECU给出的肯定响应的报文格式由七部分组成。此时的DTCAndStatusRecord由三个字节的DTC和一个字节的StatusOfDTC组成，StatusOfDTC表示DTC的状态。假设现在的DTC状态为0x09，则Bit0和Bit3置1。如某个DTC一直存在并且确认，则在ECU响应的报文中的StatusOfDTC为0x09。如图4



图4

SnapshotRecordNumber这个字节表示DTC快照记录的组号；DTCSnapshotRecordNumberOfldentifiers表示快照DID的个数，占一个字节；Dataldentifier这部分由两个字节组成，表示快照数据对应的DID，DTCSnapshotRecord表示快照DID对应的具体数据。
3、实例分析

前面介绍了19 04子服务请求和响应的报文格式。掌握了理论知识，那么现在我们就到实例中去具体分析，从而加深对19 04子服务如何读取快照数据的过程的理解。
客户端对服务端发起一个读取DTC快照的请求。当前DTC为0x123456，可以假设这是一个转向灯的故障码，0x02为快照记录组号。请求报文如图5所示。



图5

服务端端对客户端回复了一个肯定响应。从图6中可知，当前的DTC状态掩码为0x24，0x01表示只有一个快照DID，当然也可以包含多个快照DID，可以分别表示车速、电压等。如果有两个快照DID，此时DTCSnapshotRecordNumberOfldentifiers这个字节为0x02。快照DID为0x4711，如果此时记录的是转向灯故障时当前车速的数据，那么这个0x4711则表示此时快照数据的名称——车速。DTCSnapshotRecord为具体的快照数据0xA666075020，以16进制数值表示，通过数据类型解析后就可以得到具体的车速等信息。



图6

<hr/>北汇信息会持续发布CAN总线网络相关的教学视频和技术文章，诊断相关的技术干货，欢迎关注北汇信息获取更多咨询！
CAN总线的起源

CAN总线概述 - 知乎 (zhihu.com)

教你学会使用CANoe——License介绍 (zhihu.com)

卡卡

一、UDS概述

       汽车故障诊断  UDS（Unified Diagnostic Service）是利用ECU监测控制系统各组成部分的工作情况，发现故障后自动启动故障记录和处理逻辑。汽车故障诊断模块不仅能够存储记忆汽车故障，还能够实时提供汽车各种运行参数。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。其主要遵循：ISO-15765、ISO-14229诊断协议。经常应用在整车的各种整车上的电控单元(ECU)上面。
二、UDS基本原理

1、UDS协议栈

       UDS协议栈主要分为网络层和应用层两大部分


网络层：是为了解决ISO 11898 协议中的经典can数据链路层与UDS 应用层 ISO 14229 协议中定义的应用层，彼此的数据长度不一样问题。经典can数据链路层最大支持8字节，但 ISO 14229 不仅仅支持can总线设计的，其最大容量是达到4095字节。如UDS应用需要发送20字节数据信息，而can不能一帧报文处理完，需要3帧才能发送完毕。那么如何将多字节数据通过can进行有效，有序的传输呢？ISO 15765-2 由此而生。网络层分为单帧和多帧，单帧(SF)就是一帧can报文8字节内就可以把uds数据处理完毕。多帧就是一帧can报文8字节内处理不完,需分为首帧(FF)，流控帧(FC)，连续帧(CF)来处理。网络层还有时间参数，如N_Ar、N_As、N_Br、N_Bs、N_Cr、N_Cs。后续网络层会详细讲解。
应用层：应用层协议通常作为确认消息的传输，意味着从客户端发送的每一个请求都将有由服务器端产生的与之相对的响应。
2、功能寻址与物理寻址

       由客户端诊断设备（诊断仪Tester），发出诊断请求，服务端server响应客户端请求。客户端可以使用功能寻址（一条报文对应本网络中所有Server（ECU），一般为报文ID为7DF），也就是说本网络中所有ECU都要对这条指令做出响应，即一对多模式。
     客户端也可以使用物理寻址（是一种点对点的寻址模式，一条报文对应于单独一个Server（ECU））单独跟网络中某个ECU服务端进行通讯，即一对一模式。
     功能寻址和物理寻址是每一个具备UDS诊断功能的ECU，所具有的两个CAN_ID，整车上规定每个ECU功能寻址的CAN_ID相同，一般设置为0x7DF。整车上也规定每个ECU的物理寻址CAN_ID 都是唯一的。

清风寡欲

​
本文笔记来自于ISO15765-3-2004中文版和1422-1-2013中文版，2020英文版，恒润的can诊断基础，汽车控制器（ECU）中DTC的状态位.PDF 感谢以上资源！笔记仅用于自己学习及大家参考~~

<hr/>9 诊断服务实施 （15765-3and14229-1）

9.1 统一诊断服务总览

该部分定义了 ISO 14229-1 定义的诊断服务是如何适用于 CAN 的。对于每一个应用服务，都定义了可用的子功能及数据参数。
注意：子功能参数的定义考虑了 suppressPosRspMsgIndicatonBit 参数的最高有效位。该参数在 ISO 14229-1 中定义。
表 26 用于提供所有统一诊断服务的总览，它们适用于 CAN 诊断实施，表包含了可用服务总数。使用该部分ISO 15765 协议实施 CAN 诊断的某些应用上可能限制了可使用服务的数量， 并可将它们按应用范围/诊断会话（默认会话，编程会话等）进行归类。




​
Cvt所代表的含义：



9.2 诊断与通信控制功能单元



9.2.1 诊断会话控制（DiagnosticSessionControl）（10hex）服务

表 27 定义了适用于 CAN 诊断服务的子功能参数


01：默认会话
02：编程会话
03：扩展会话
表 28 和 29 定义了应答信息数据参数结构，sessionParameterRecord 适用于 CAN 诊断实施。


​
上表中的两个参数是在服务器发送诊断会话控制（如10 01）后服务器回复给诊断仪的，响应格式是类似 50 01 xx xx yy yy 这种， xx xx 就表示 P2Server_max，yy yy 就表示 P2*Server_max。诊断仪收到这两个参数之后，就对 ECU 的响应速度有了认知，可以据此来判断 ECU 的响应是否及时
会话状态转移图：只能从扩展模式进入编程模式，为什么要这么设置呢？在刷写流程里有提到。




​

诊断会话模式的状态转移图说明
DS-默认会话 PRGS-编程会话 EXTDS-扩展会话
a：服务器上电或者复位（初始化）；
b：服务器接收到DS_＝DS的DSC请求报文；
c：服务器接收到DS_＝PRGS或EXTDS的DSC请求报文，依据DS_进入扩展模式或编程模式；
d：服务器接收到DS_＝DS的DSC请求报文，或者S3Server超时，服务器的安全状态变为锁定状态；
e：服务器接收到DS_＝PRGS的DSC请求报文；
f：服务器接收到DS_＝EXTDS的DSC请求报文。
此外，只有成功发送肯定响应报文之后（网络层使用N_USData.con向应用层确认N_Result＝N_Success），服务器才进入所请求的诊断模式，否则诊断模式维持不变。


​
具体的服务允许条件，不同的主机厂可能有区别

肯定响应50，否定响应7F



不满足会话切换条件时，ECU要求返回0x22

9.2.2 ECU 复位（ECUReset）（11hex）服务

表 30 定义了该项 CAN 服务的子功能参数



01:硬件复位
02:钥匙复位
03:软件复位
04:启用快速断电，意思是快速进入休眠模式（正常从keyoff到控制器休眠一般还会有一段时间，用来做数据存储等）
05:关闭快速断电
肯定响应：




​
否定响应：



​

9.2.3 安全访问（SecurityAccess）(27hex)服务

有些服务需要安全访问解锁通过后才可以访问，如写入数据等


​


​
子功能：01，03，05，07....7D，表示请求种子，实际只能到5F，
02,04,06,08.....7E，表示发送密钥，实际只能到60，后面的61-7E供应商保留，7F被ISO保留


​




​
肯定响应：


​


​
根据实际情况，请求的种子可能是2字节，也可能是4字节，或者更多。加密算法一般由主机厂自定义。
否定响应码：


​



如果客户端不希望服务器回复，则可以设置子功能最高为TRUE，那么服务器将不会回复。只有最高位为FALSE时，ECU才可以响应消息。
ISO14229-1给出的示例：


​





9.2.4 通信控制服务（CommunicationControl）(28hex)

用于打开/关闭服务器对非诊断消息的发送和/或接收


​


​







​

01，所有应用报文 02，所有网络管理报文 03，都包括


​
举例：禁止与诊断无关的通讯 用功能寻址 28 83 01 controltype-83表示发送和接收都禁止，且不需要回复 communicationType-01表示所有应用报文
肯定响应：



否定响应码：


​

9.2.5 诊断仪在线服务（TesterPresent）(3E hex)

诊断仪在线服务主要是让服务器保持在非默认会话模式


​

举例：诊断仪发送诊断仪在线 3E 80 80表示不需要ECU回复



否定响应码：


9.2.6 安全数据传输服务（SecuredDataTransmission）(84 hex)

这个15765-3里没有用，一般整车厂也不用
该服务用于保护数据传输免遭第3方攻击，具体见14229-1-9.8
9.2.7 控制故障码信息设置服务（ControlDTCSetting）(85 hex)







​
肯定响应：


​

否定响应码：




​

示例：关闭设置DTC 功能寻址 85 82 82表示关闭设置DTC，且不需要ECU回复
9.2.8 基于事件应答服务（ResponseOnEvent）(86 hex)

用于启动或停止服务器中某个特定事件触发的响应
基本用不到，暂时不看。详见14229-1-9.10
9.2.9 链路控制（LinkControl）(87 hex)服务



​




​


​
01或者02，先验证是否可以转换，如果ECU回复可以，那么进行转换（发送03）。




​
肯定响应：



否定响应码：


​
14229-1给出的示例：


​


​


​
第二步，转换波特率



9.3 数据传输功能单元



​
9.3.1 通过标识符读数据服务（ReadDataByIdentifier）（22hex）

ReadDataByIdentifier服务通过客户端向服务器发起读取数据请求，由一个或多个DataIdentifier（DID）决定具体的数据。
DID所表示参数的格式由制造商自己约定
附件C



​














​


​
肯定响应：



多个读取请求时，顺序响应



否定响应码：



9.3.2 通过地址读内存（ReadMemoryByAddress）(23 hex)

用的比较少





肯定响应：



否定响应码：


​


​
示例：


​
9.3.3 通过标识符读取换算数据（ReadScalingDataByIdentifier）(24hex)

相当于是经过一次加密，读取的数据是经过换算后的。具体的换算参数定义见14229-1-附录C2,C3
用的比较少，暂时不看了.具体见14229-1-10.4
9.3.4 通过周期的标识读数据（ReadDataByPeriodicIdentifier）(2Ahex)

周期性读取数据，启动和停止由客户端发送，启动时发送的还有传输速率，读取的DID（周期性标识符是F200-F2FF，所以发送时只发送后一个字节，F2不用发送）
用的比较少，暂时不看了.具体见14229-1-10.5
9.3.5 动态定义数据标识（DynamicallyDefineDataIdentifier）（0x2C）服务

子功能有3个。01：由原DID们创建新DID。02：由内存地址来创建新DID。03：删除动态创建的DID。
用的比较少，暂时不看了.具体见14229-1-10.6
9.3.6 通过标识写数据服务（WriteDataByIdentifier）(0x2E)





​


​

示例：写入VIN码





9.3.7 通过地址写内存服务（WriteMemoryByAddress）(0x3D)

用的比较少，暂时不看了。具体见14229-1-10.8
9.4 存储数据传输功能单元

ReadDTCInformation (0x19)服务
ClearDiagnosticInformation (0x14) 服务
9.4.1 读故障码信息服务（ReadDTCInformation）（19 hex）


故障状态掩码MASK 位定义：
该mask由主机厂提供。


主要第0位和第三位用的比较多，所以一般故障掩码的值为0x09
bit 0 : testFailed 通常来说，ECU 内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应 DTC 的这一个状态位就要被置 1，表征出错。此时 DTC 的 testFailed 位被置 1，但是它不一定被 ECU 存储到 non-volatile memory 中，只有当 pendingDTC 或 confirmedDTC 被置 1 时 DTC 才会被存储。 而 pendingDTC 或 confirmedDTC 被置 1 的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除 DTC 指令时，testFailed 会再次被置为0
bit 1 :testFailedThisOperationCycle 这个 bit 用于标识某个 DTC 在当前的 operation cycle 中是否出现过 testFailed 置 1 的情况， 即是否出现过错误。operation cycle 的起始点是 ECU 通过网络管理唤醒到 ECU 通过网络 管理进入睡眠，对于没有网络管理的 ECU，这个起始点就是 KL15 通断。通过 bit 0 我们 无法判断某个 DTC 是否出现过，比如，当前 testFailed = 0， 说明当前这个 DTC 没有出 错，如果 testFailedThisOperationCycle = 1 的话，就说明这个 DTC 在当前这个 operation cycle 中出过错，但是当前错误又消失了。也就是说上电时间内出现的故障，该位都会置1，不管是否存储。
bit 2 : pendingDTC 根据规范的解释，pendingDTC = 1 表示某个 DTC 在当前或者上一个 operation cycle 中是 否出现过。pendingDTC 位其实是位于 testFailed 和 confirmedDTC 之间的一个状态，有 的 DTC 被确认的判定条件比较严苛，需要在多个 operation cycle 中出现才可以被判定为 confirmed 的状态，此时就需要借助于 pendingDTC 位了。pendingDTC = 1 的时候， DTC就要被存储下来了，如果接下来的两个 operation cycle 中这个 DTC 都还存在，那么 confirmedDTC 就要置 1 了。如果当前 operation cycle 中，故障发生，pendingDTC = 1， 但是在下一个 operation cycle 中，故障没有了，pendingDTC 仍然为 1，再下一个 operation cycle 中，故障仍然不存在，那么 pendingDTC 就可以置 0 了。 相当于历史故障，需要被存储的，但是还没到那么严重的地步，还是可以由ECU清除的。
bit 3 : confirmedDTC 当 confirmedDTC = 1 时，则说明某个 DTC 已经被存储到 ECU 的 non-volatile memory 中， 说明这个 DTC 曾经满足了被 confirmed 的条件。但是请注意，confirmedDTC = 1 时，并 不意味着当前这个 DTC 仍然出错，如果 confirmedDTC = 1，但 testFailed = 0，则说明这 个 DTC 表示的故障目前已经消失了，属于历史故障了。将 confirmedDTC 重新置 0 的方法只有清除DTC， UDS 用 0x14 服务，OBD 用 0x04 服务。
bit 4 : testNotCompletedSinceLastClear 这个 bit 用于标识，自从上次调用了清理 DTC 的服务（UDS 用 0x14 服务，OBD 用 0x04 服务）之后，是否成功地执行了对某个DTC 的检测（不管测试结果是什么，只关心是否测了）。因为很多 DTC 的检测也是需要满足某些边界条件的，并不是 ECU 上电就一定会 对 DTC 进行检测。 testNotCompletedSinceLastClear = 1 : 自从清理 DTC 之后还没有完成过针对该 DTC的检测。 testNotCompletedSinceLastClear = 0 : 自从清理 DTC 之后已经完成过针对该 DTC的检测
bit 5 : testFailedSinceLastClear 这个位与 bit 1 :testFailedThisOperationCycle 有些类似，后者标识某个 DTC 在当前的 operation cycle 中是否出现过 testFailed 置 1 的情况，而 testFailedSinceLastClear 标识 的是在上次执行过清理 DTC 之后某个 DTC 是否出过错。
testFailedSinceLastClear = 0 ， 自从清理 DTC 之后该 DTC 没有出过错。
testFailedSinceLastClear = 1， 自从清理 DTC 之后该 DTC 出过至少一次错。
bit 6 : testNotCompletedThisOperationCycle
这个位与 bit 4 : testNotCompletedSinceLastClear 类似，后者标识自从上次调用了清理DTC 的服务之后，是否成功地执行了对某个 DTC 的检测 。而testNotCompletedThisOperationCycle 则标识在当前 operation cycle 中是否成功地执行了对某个 DTC 的检测 。
testNotCompletedThisOperationCycle = 1 ： 在当前 operation cycle 中还没在完成过针对该 DTC 的检测 。
testNotCompletedThisOperationCycle = 0 ： 在当前 operation cycle 中已经完成过针对该DTC 的检测
bit 7 : warningIndicatorRequested 某些比较严重的 DTC 会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文 字，或者是声音。这个 warningIndicatorRequested 就用于此类 DTC。 warningIndicatorRequested = 1 ： ECU 请求激活警告指示。
warningIndicatorRequested = 0： ECU 不请求激活警告指示。
注意，如果这个 DTC 不支持警告指示，则这个位永远置 0

子功能：



sub-function = 0x01reportNumberOfDTCByStatusMask 用于读取符合特定条件的 DTC 数量，此时 parameter 为一个 byte 的 Mask，用于与DTC 的 Status 进行“与”运算，而 ECU 返回的则是"与"运算之后结果不为 0 的 DTC 的数量。DTC 的Status 用一个 byte 表示，其中的 8 个 bit 分别代表 DTC 的不同状态，比如，bit 0 表示这个 DTC 是active 的还是 passive 的，bit 4 表示这个 DTC 是否已经被 confirm 了，如果 DTC 的状态是 confirm，则说明该 DTC 已经被 ECU 存储下来了。
比如：19 01 08 这个命令的用途，就是读取所有状态为 confirm 的 DTC 的数量
sub-function = 0x02 （reportDTCByStatusMask） 用于读取符合特定条件的 DTC 列表，此时 parameter 仍然为一个 byte 的 Mask，用 于与 DTC 的 Status 进行“与”运算，而 ECU 返回的则是"与"运算之后结果不为 0 的 DTC 列表。
比如 19 02 01 这个命令的用途，就是读取所有状态为 active 的 DTC。此时 ECU 返回的格式应该 是 59 02 01 XX XX XX 01 YY YY YY 09......。返回的 DTC 列表中的每个条目为 4 个字节，前三个字节用 于标识 DTC，比如 XX XX XX，最后一个字节用于标识 DTC 状态，比如 01，表示 DTC 是 active 的，09 表示 DTC 是 active 且 confirm 的。
sub-function = 0x04 （reportDTCSnapshotRecordByDTCNumber通过故障码报告故障快照记录）
sub-function = 0x04 用于读取某个 DTC 发生时的故障快照信息，此时 parameter 为 3个 byte 用于标识我们要读取的DTC，第四位为故障快照编号
sub-function = 0x06 （reportDTCExtDataRecordByDTCNumber通过故障码报告故障扩展数据记录） sub-function = 0x06 用于读取某个 DTC 及其相关的扩展数据，此时 parameter 为 4 个 byte，前三个 byte 用于标识我们要读取的 DTC，第四个 byte 用于标识要读取的扩展数据记录号，UDS 规定使用 FF 来 表示读取所有的扩展数据，各厂家可以要根据自己的需求定义其他的值来代表要读取的扩展数据。 扩展数据包括 DTC 状态，优先级，发生次数，老化计数器，时间戳，里程等，厂家还可以根据自己的需求定义一些此 DTC 产生时的测量数据。 比如 19 06 XX XX XX FF 就表示读取 XX XX XX 这个 DTC 的所有扩展数据，ECU 的返回值应该是 59 06 XX XX XX XX（DTC状态码） AA BB CC DD.....，其中 AA BB CC DD...代表的就是 XX XX XX 这个 DTC 产生时所一起存储的扩展数据。
sub-function = 0x0A （report Supported DTC报告支持的故障）
sub-function = 0x0A 用于读取ECU所有支持的故障码，且是发生过的故障，ECU应答时会应答所支持的故障掩码，及具体的故障码及故障状态。

扩展数据记录号及具体定义由主机厂定义，故障快照编号，故障快照ID及具体信息由主机厂定义。





其他子功能没怎么用到，暂时不看了
9.4.2 清故障码信息服务（ClearDiagnosticInformation）(0x14)








如果发送的故障码为FFFFFF，则表示清除所有故障信息。



9.5 输入输出控制功能单元

9.5.1 输入输出控制标识服务（InputOutputControlByIdentifier）(0x2F)

该服务用来控制ECU的输入和输出，相当于是标定控制，若是输入，则ECU接收次服务的输入，若是输出，则ECU按此服务给定的输出。具体的输入输出信号由ID决定，此ID由整车厂指定（且需要按表C1(见9.3.1)中的范围）。






​
ID和ControlParameter比较好理解，后面的controlState表示控制的具体值，需要在ID里面定义具体信息。
controlEnableMaskRecord只能在多个控制参数时才可以使用，表示哪些控制参数可以被控制（控制有效，目的是为了一组参数中可以进行单个参数的控制）。
控制参数与掩码需要对应，一个参数对应一个掩码位。
肯定响应：


​


​
否定响应码：


示例：






​


​
EGR周期反馈的是41%，不表示没响应请求，是实际还没达到目标而已。


​


9.6 例程控制功能单元

9.6.1 例程控制服务（RoutineControl）(0x31)

例程控制主要是控制一些比较复杂的功能，如擦除内存，换挡自学习（TCU）等。RoutineID由整车厂给定


​


​



该Record表示一些请求的信息，如擦除内存时的字节规则，起始地址，字节数等，由整车厂给定
表F.1



​





该Record表示反馈状态，由整车厂给定，一般就是成功或者不成功。
否定响应码：



9.7 上传/下载功能单元

主要用于bootLoader刷写程序，后面再具体整到一个文章中
9.7.1 请求下载服务（RequestDownload）(0x34)

9.7.2 请求上传服务（RequestUpload）(0x35)

9.7.3 传输数据服务（TransferData）（0x36）

9.7.4 请求传输退出服务（RequestTransferExit）（0x37）

简介：一般bootloader中，诊断仪0x34服务请求下载，ECU肯定响应后，诊断仪0x36服务开始传输数据，传输完成后诊断仪发送0x37退出传输服务。


​

​