UDS 报文解读

2021-03-03 11:33:47 阅读：850 来源： 互联网

转载：https://www.cnblogs.com/still-smile/p/12022080.html

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。

UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。
如果是肯定的响应（Positive Response），回复[SID+0x40]，如请求10，响应50；请求22，响应62。
如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。

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

UDS的26种服务中，有7种很重要。它们分别是：

$10 Diagnostic Session Control（诊断会话），
$14 Clear Diagnostic Information（清除诊断信息），
$19 Read DTC Information，
$22 Read Data By Identifier（通过ID读数据），
$27 Security Access（安全访问），
$2E Write Data By Identifier（通过ID写数据），
$3E Tester Present（待机握手）。

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

1 $10诊断会话

$10包含3个子功能，

01 Default，

02 Programming，

03 Extended，

ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

报文包含4种类型，即

SID，

SID+SF（Sub-function），

SID+DID（Data Identifier）（读写用），

SID+SF+DID。

NRC：Negative Response Code（否定响应码)。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。

举例子前首先看下网络层帧：

第一个字节的高位是0的为单帧信息；
第一个字节的高位是1的为多帧中的首帧；
第一个字节的高位是2的为多帧中的后续帧；
第一个字节的高位是3的为流控帧；

举例1：以can总线为例子

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

请求（Request）:

02 10 02 xx xx xx xx xx

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

肯定响应:

02 50 02 xx xx xx xx xx

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

否定响应:

03 7F 10 22 xx xx xx xx；

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

3.$19 读DTC

DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将其存储为DTC。DTC可表现为：一个显而易见的故障:通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。

DTCHighByte	DTCMiddleByte	DTCLowByte	DTCStatus
Byte 1	Byte 2	Byte 3	Byte 4

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

3.$14清除DTC

清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。

Request：14+FF+FF+FF；
Response：54 。

2诊断报文解析

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

CAN Message =CAN ID + CAN DATA

根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.

N_PDU format.png

网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：

帧类型	bit7-4	bit3-0	Byte 2	Byte 3
单帧	PCItype=0	SF_DL	N/A	N/A
首帧	PCItype=1	FF_DL	FF_DL	N/A
连续帧	PCItype=2	SN	N/A	N/A
流控帧	PCItype=3	FS	BS	ST_min

PCI_format.png

综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。其中，

SF_DL 代表单帧中数据字节数（取值0-7），
FF_DL代表连续帧中的数据字节数(12bit可表四8~4095)，
SN代表此帧为连续帧中的第几帧，（0、1、2...E、F、0、1...）
FS流控制帧，有三种状态：继续发送0、保持等待1、数据溢出2
BS规定发送端允许持续传输连续帧数目的最大值（0~255），
STmin限定连续帧相互之间所允许的最小时间间隔。

先面用连个例子进行说明，请参考！

2|1例子 1--- 单帧的数据传输与接收

[图片上传失败...(image-b66bab-1538824826939)]

数据发送： 02 27 09
数据反馈： 03 7F 27 7E ---==否定的响应==（Negative Response），回复==7F+SID+NRC==，回复的是一个声明

数据发送： 02 10 40
数据反馈： 06 50 40 00 32 01 F4 ---==肯定的响应==（Positive Response），回复[==SID+0x40==]，就是请求10，响应40；回复的是一组数据

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。

2|2例子2 --- 多帧的数据接收与传输

[图片上传失败...(image-b5e84b-1538824826939)]

数据发送：

06 19 04 00 01 00 00 00

数据反馈：

10 1E 59 04 00 01 00 27

30 00 00 00 00 00 00 00

21 00 0B FF FF FF FF FF

22 FF FF FF FF FF FF FF

23 FF FF FF FF FF FF FF

24 FF FF FF AA AA AA AA

数据发送为单帧，所以06代表发送的数据中含有6个字节，

回复为Positive Response，为连续帧。

10中的1代表连续帧的首帧，==01E代表此连续帧含有30个字节==，
30代表此连续帧的流控制帧，
21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。

标签：02,UDS,00,字节,DTC,报文,解读,FF,SID
来源： https://www.cnblogs.com/ananmy/p/14473444.html