UDS最全内容总结.docx

UDS最全内容总结.docx

《UDS最全内容总结.docx》由会员分享，可在线阅读，更多相关《UDS最全内容总结.docx（38页珍藏版）》请在冰点文库上搜索。

UDS最全内容总结

前言

UDS协议即ISO14229,是UnifiedDiagnosticServices，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又是发什么指令。

OBD是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范，只是应用层的规范。

UDS（Unifieddiagnosticservices），与OBD最大的区别就在于“Unified”上，

UDS是面向整车所有ECU（电控单元）的，而OBD是面向排放系统ECU的。

简单说UDS而言，它只是一个应用层协议（ISO14229-1），所以它既可以在CAN线上实现（见下图.1），甚至也能在Ethernet上实现（DOIP,DiagnosticoverInternetprotocol见下图.2）。

并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常常被称为Enhanceddiagnostic（增强型诊断），UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。

UDS（UnifiedDiagnosticServices，统一的诊断服务）诊断协议是ISO15765和

ISO14229定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN,LIN,Flexray,Internet和K-line）上实现。

UDS协议的应用层定义是ISO14229-1，目前大部分汽车厂商均采用UDSonCAN的诊断协议。

如下图所示，ISO14229-1也就是UDS协议仅对应用层做出了定义，物理层有双绞线和光纤供用户选择，数据链路层采用CAN总线的ISO11898-1协议，针对ClassicalCAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾，ISO15765-2对网络层进行了定义。

CAN的8字节数据场会腾出一帧来表示网络层的信息。

下图右侧是排放相关的协议，ISO15031-5主要针对OBD协议，为法规强制要求车厂满足的协议。

学习时，我们应在了解CAN总线基本知识的前提下，着重学习ISO15765-2和ISO11898-1的协议内容，并通过BootLoader作为例子，对UDS有一个大致的了解。

UDS的7种服务及肯定响应和否定响应的形式

UDS本质上是一系列的服务，共包含6大类26种。

每种服务都有自己独立的ID，即SID。

SID：

（ServiceID（Identifier）以下简称SID）Service，诊断服务ID。

UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。

如果是肯定的响应（PositiveResponse），回复[SID+0x40]，就是请求10，响应50；请求22，响应62，回复的是一组数据。

如果是否定的响应（NegativeResponse），回复[7F+SID+NRC]，回复的是一个声明。

肯定响应和否定响应的形式一定要熟记。

UDS的26种服务中，有7种很重要。

它们分别是：

$10 DiagnosticSessionControl（诊断会话），

$14ClearDiagnosticInformation（清除诊断信息），

$19 ReadDTCInformation，

$22 ReadDataByIdentifier（通过ID读数据），

$27 SecurityAccess（安全访问），

$2EWriteDataByIdentifier（通过ID写数据），

$3E TesterPresent（待机握手）。

下面对这7个服务进行解读。

$10诊断会话

DiagnosticSessionControl（0x10）

DiagnosticSessionControl诊断request的格式

DiagnosticSessionControl这个服务的SID是0x10，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将进入的session。

UDS定义的session包括：

0x00ISOSAEReserved（保留）

0x01defaultSession

0x02ProgrammingSession

0x03extendedDiagnosticSession

0x04safetySystemDiagnosticSession

0x05–0x3FISOSAEReserved（保留）

0x40–0x5FvehicleManufacturerSpecific（由整车厂自定义使用）

0x60–0x7EsystemSupplierSpecific（由ECU供应商自定义使用）

0x7FISOSAEReserved（保留）

DiagnosticSessionControl用于控制ECU在不同的session之间进行转换，session可以看作是ECU所处的一种软件状态，在不同的session中诊断服务执行的权限不同。

ECU上电之后，

默认处在defaultSession中，在这个session中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。

一般的诊断仪启动之后，会给ECU发送1003，即让ECU进入extendedDiagnosticSession中，在这个session中可执行的诊断服务就很多了。

而如果要让ECU保持在non-defaultSession中，则需要诊断仪每隔固定的时间发送0x3E服务，ECU才会知道诊断仪有和自己通信的需求，从而保持在non-defaultSession中。

另一个常用的session是ProgrammingSession，在这个session中可以进行软件刷写的一系列诊断服务。

0x40–0x5F这个范围中的session由整车厂自定义使用，比如，某些诊断服务或诊断数据的操作需要在生产线上执行，即所谓的End-Of-Line，整车厂可以从这个范围中选择一个值来表示EOLsession；又或者在开发阶段需要某种“超级”session，则也可以从这里选一个值用来使ECU进入开发模式的session。

DiagnosticSessionControl这个服务非常简单，但是它却是ECU和诊断通信的第一条诊断命令。

$10包含3个子功能，01Default，02Programming，03Extended，ECU上电时，进入的是默认会话（Default）。

如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。

当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

UDS包含4种类型，

即SID，SID+SF（Sub-function），SID+DID（DataIdentifier）（读写用），SID+SF+DID。

NRC：

NegativeResponseCode（否定响应码）。

如果ECU拒绝了一个请求，它会回应一个NRC。

不同的NRC有不同的含义。

14229-1协议第329页

单词：

Consult（查阅）Session（会话）DTC（diagnostictroublecode）故障码Handling（处理）Conditions（条件）restricted（受限的）Concept（概念）SA（sourceaddress源地址）TA（目标地址）

例子：

以CAN总线网络举例。

八个帧数据字节，第一字节被网络层占用。

请求（Request）:

021002xxxxxxxxxx;02中的0代表网络层单帧SF，2代表数据域有2个字节；SF，数据域有2个字节，10是SID，02是子功能。

肯定响应:

025002xxxxxxxxxx；02同上，10+40表示对SID的肯定回复，02是子功能。

否定响应:

037F1022xxxxxxxx；03同上，7F表示否定响应，10是SID，22是NRC。

$3E待机握手

TesterPresent（0x3E）

这个诊断服务的用处可以通过它的名字很明显地得知，即告知ECU诊断仪还在连接着。

在上一篇文章中我说到了关于session的部分，如果没有诊断命令的发送和接收，ECU将从non-defaultsession中回退到defaultsession，0x3E就是用于使ECU保持在当前session。

这应该是UDS中最简单的一个诊断服务了，它永远只有两个byte，格式如下：

0x3E诊断服务的格式

当sub-function是0x00时，ECU要给出response；

当sub-function是0x80时，ECU不需要要给出response。

一般来说主机厂会为这个服务定义两个时间参数，一个参数用于规定自己的诊断仪发送0x3E服务的间隔，另一个参数用于定义ECU收不到0x3E服务的timeout时间。

$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。

0x3E就是用于使ECU保持在当前session。

这应该是UDS中最简单的一个诊断服务了，它永远只有两个byte，格式如下：

例子：

02 3E 800000000000，发送一个3E服务的报文，保持非默认会话状态。

80表示无需回复。

$27安全访问

SecurityAccess（0x27）

厂家可能会为ECU定义某些安全级别稍微高一些的诊断服务，在执行此类服务之前，就需要执行SecurityAccess这个诊断命令，进行一个简单的身份验证。

完成SecurityAccess有以下步骤：

诊断仪向ECU请求“Seed”（通常是一个与时间相关的伪随机数）,

ECU向诊断仪发送“Seed”诊断仪向ECU发送“Key”（根据请求得到的Seed和一个本地的密码进行计算得来）

ECU判断诊断仪发来的“Key”是否有效

根据UDS的定义，0x03,0x05,0x07–0x41这个范围留给用于requestSeed的sub-function；0x04,0x06,0x08–0x42这个范围留给用于sendKey的sub-function。

具体选择哪对值，由整车厂自己定义。

整车厂也可以选择多对sub-function，用于不同等级的安全访问。

下面我举一个完成SecurityAccess的诊断命令的例子，

假设0x05用于requestSeed，0x06用于sendKey。

诊断仪发送2705

ECU响应6705010101（seed是010101）

诊断仪发送2706020304（key值是020304，seed是010101，假设本地密码为010203，而算法就是将密码与seed相加）

ECU验证成功6706

此时ECU就处于unlocked的状态了，那些被保护起来的诊断服务和诊断数据可以被操作了。

通常来说，如果ECU重启，或者回到了defaultsession，unlocked状态就失效了，如果要执行相关诊断服务，则需要再次执行上面描述的过程。

$27安全访问：

ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。

我们在读取一些特殊数据的时候，要先进行一个安全解锁。

ECU上电之后是一个锁定的状态（Locked），我们通过$27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

比如下面的例子，2n-1是一个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。

之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。

ECU同样也会通过种子算出k2。

当k1和k2匹配时，解锁（Unlocked）成功。

$27安全访问服务的否定响应服务ID也是7F。

还记得刚才否定响应的格式吗？

7F+27+NRC

Rx：

02 2705 0000000000安全访问，05子功能

Tx：

07 6705 082711F077肯定响应，回复了对应安全级别的种子

Rx：

06 2706 FFFFFFFF00发送密钥，4个FF。

注意06是与05成对使用的。

Tx：

03 7F2778 00000000否定响应，7F+27+NRC

Tx：

02 6706 0000000000肯定响应，通过安全校验

$22读数据

$22读数据，Request（请求）：

22+DID（DataIdentifier，通常是两个字节）

Response（响应）：

62+DID+Data

DID有一部分已经被ISO14229-1规定了。

比如

0xF186就是当前诊断会话数据标识符，

0xF187就是车厂备件号数据标识符，

0xF188就是车厂ECU软件号码数据ID，

0xF189就是车厂ECU软件版本号数据标识符。

$2E写数据

$22写数据，Request（请求）：

2E+DID+Data

Response（响应）：

6E+DID

注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。

也就是说，对于写数据的请求，一般来说需要在一个非默认会话，和解锁的状态下才能进行。

$19读DTC

DTC（diagnostictroublecode）：

如果系统检测到了一个错误，它将存储为DTC。

DTC可表现为：

一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。

DTC可以揭示错误的位置和错误类型。

通常DTC占用3个字节，OBDII占用两个字节。

图中FTB为FaultTypeByte。

故障码包括四个大类，分别是PCBU，

P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。

一个DTC信息占用4个字节。

最后一个字节是DTC的状态。

前两个字节是我们熟知的类似P0047的故障码。

LowByte暂不清楚。

$19拥有28个子服务（Sub-Function）。

常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。

刚才提到，一个DTC除了它自己的3个字节，还有一个字节专门用于表达DTC的状态。

这个状态字节每个位的含义可以查询ISO14229-1。

注意，并不是所有的DTC状态都是支持的。

下图是Request/Response。

括号标识循环，可以读出很多DTC。

$14清除DTC

清除（复位）DTC格式，它可以改变DTC的状态。

3个FF代表清除所有DTC。

Request：

14+FF+FF+FF；

Response：

54。

我们刚才学完了7种重要的服务，SID。

除此之外，在CAN总线中，Addressinginformation寻址信息通过CAN帧ID体现出来。

通讯的模式分两种，一种是物理寻址（点对点），根据物理地址的不同进行访问，但只能访问单个ECU节点，Test为SA源地址，ECUX作为TA目标地址；对应的，另一种是功能寻址（广播），根据功能的不同进行访问，它能访问多个ECU节点。

每一个ECU都有2个CAN帧ID，分别对应收和发的物理寻址。

以上只是一些粗浅的理解。

对26种服务更详细的解读请拉到屏幕下方参考张老师的8篇文章。

张老师也开通了微信公众号，可以了解一下。

UDS应用的设备：

在UDS诊断产品中知名度最高，应用最广泛的是德国Vector公司的CANcase配合其CANoe 软件，Vector产品功能齐全，适合系统级汽车总线开发，被大部分汽车厂商采用。

Vector产品因不开放API，不能做二次开发且价格昂贵，不适用于硬件开发团队和生产线的自动化测试。

目前市面上有很多CAN厂商（如Kvaser,ZLG等）能提供低成本、体积小、驱动简单、开放API的设备，很适合进行二次开发。

杂记

变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元，这2个ECU要通过CAN网络进行大量的信息交互。

但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因，2个控制单元之间可能会出现通信丢失的现象。

控制系统需要将故障信息（例如通信丢失故障信息）诊断出来，以处理通信被破坏时出现丢失帧的故障现象，并记录为DTC（diagnostictroublecode）。

ECU的输入信号主要有4种形式：

1模拟信号（水温、油压、蓄电池电压等）；

2数字信号（各种开关信号等）；

3PWM信号（脉冲信号、频率信号等）；

4网络信号（CAN、LIN上传输的信号）。

微控制器可以通过监测这些信号来判别输入电路的工作状况。

输出的信号往往用作控制电磁阀、指示灯、步进电机等，大多数为数字信号。

统一诊断服务（Unifieddiagnosticservices，UDS）

（一）

UDS由ISO-14229系列标准定义，ISO14229-1定义了诊断服务，不涉及网络及实现，只有应用层的内容。

而ISO14229-3则定义了UDS在CAN总线上的实现。

诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求（request），ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。

Diagnosticrequest的格式：

Diagnosticrequest的格式可以分为两类：

一类是拥有sub-function的，

一类是没有sub-function的，如下面两张图所示。

ServiceID（以下简称SID）的长度固定为1个字节，代表了这条诊断命令执行的什么功能。

Sub-function的长度也是1个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。

Parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。

parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。

有一点要补充的是，其实sub-function严格来说是7个bit，而不是1个byte，因为它的最高位bit被用于抑制正响应（suppresspositiveresponse,SPR），

如果这个bit被置1，则ECU不会给出正响应（positiveresponse）；

如果这个bit被置0，则ECU会给出正响应。

这样做的目的是可以告诉ECU不要发不必要的response，从而节约通信资源。

Diagnosticresponse的格式：

Diagnosticresponse分为positive和negative两类。

positiveresponse意味着诊断仪发过来的诊断请求被执行了

negativeresponse则意味着ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于negativeresponse的报文中。

positiveresponse

positiveresponse的格式如上图所示，也基本上是由三部分组成，其中的responseSID这个字节作为诊断请求的echo，它等于SID+0X40。

后面的两个部分则视具体的诊断服务而定。

negativeresponse

negativeresponse的格式固定为3个字节，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。

下面这张图列举了部分原因代码，比如，如果ECU给出7F2213这个negativeresponse，则说明22这个服务因为诊断请求数据长度不对的原因无法执行。

总结：

诊断通信的过程就是诊断仪和ECU交换数据，前者发的是request，后者发的是response，而UDS最重要的作用就是定义了这些request和response的格式和内容。

统一诊断服务（Unifieddiagnosticservices，UDS）

（二）

UDS定义的诊断服务从逻辑来说分为以下几类：

DiagnosticandCommunicationManagement（诊断和通信管理）

DataTransmission（数据传输）

StoredDataTransmission（存储数据传输，用于操作DTC）

InputOutputControl（IO控制）

RoutineControl（不知如何翻译好，作用是调用ECU内部的预置函数）

UploadDownload（上传下载）

UDS规定使用1个byte来表示诊断服务，即所谓的ServiceID,简称SID。

本文介绍一下DiagnosticandCommunicationManagement这一类诊断服务中的一部分。

DiagnosticSessionControl（0x10）

DiagnosticSessionControl诊断request的格式

DiagnosticSessionControl这个服务的SID是0x10，request固定为2个byte，第一个byte是SID，第二个byte的低7bit是sub-function，用于指示ECU将进入的session。

UDS定义的session包括：

0x00ISOSAEReserved（保留）

0x01defaultSession

0x02ProgrammingSession

0x03extendedDiagnosticSession

0x04safetySystemDiagnosticSession

0x05–0x3FISOSAEReserved（保留）

0x40–0x5FvehicleManufacturerSpecific（由整车厂自定义使用）

0x60–0x7EsystemSupplierSpecific（由ECU供应商自定义使用）

0x7FISOSAEReserved（保留）

DiagnosticSessionControl用于控制ECU在不同的session之间进行转换，session可以看作是ECU所处的一种软件状态，在不同的session中诊断服务执行的权限不同。

ECU上电之后，

默认处在defaultSession中，在这个session中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。

一般的诊断仪启动之后，会给ECU发送1003，即让ECU进入extendedDiagnosticSession中，在这个session中可执行的诊断服务就很多了。

而如果要让ECU保持在non-defaultSession中，则需要诊断仪每隔固定的时间