如何看懂UDS诊断报文

UDS介绍

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(待机握手)。
image.png

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

$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有不同的含义。

image.png

例子:以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。

$3E待机握手

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

例子:

02 3E 80 00 00 00 00 00,发送一个3E服务的报文,保持非默认会话状态。80表示无需回复。

$27安全访问

image.png

27服务,加上一个子服务,再加上一个钥匙,这样的服务请求可以进行解锁。

比如下面的例子,2n-1是某个子服务,通过首轮种子的请求,首轮ECU会返回67+01+AA+BB+CC+DD,AA~DD就是种子了。之后第二轮,诊断端会利用种子进行运算(利用整车厂的算法),生成k1(不一定是1个字节),那么发送请求,27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时,解锁(Unlocked)成功。

  • 例子:

Rx: 02 27 05 00 00 00 00 00 安全访问,05子功能
Tx: 07 67 05 08 27 11 F0 77 肯定响应,回复了对应安全级别的种子
Rx: 06 27 06 FF FF FF FF 00 发送密钥,4个FF。注意06是与05成对使用的。
Tx: 03 7F 27 78 00 00 00 00 否定响应,7F+27+NRC
Tx: 02 67 06 00 00 00 00 00 肯定响应,通过安全校验

$22读数据

$22读数据,
Request(请求):

22+DID(Data Identifier,通常是两个字节)

Response(响应):

62+DID+Data

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符,0xF187就是车厂备件号数据标识符,0xF188就是车厂ECU软件号码数据ID,0xF189就是车厂ECU软件版本号数据标识符。

$2E写数据

$22写数据,
Request(请求):

2E+DID+Data

Response(响应):

6E+DID

注意,比如0xF186这个DID不支持直接写入数据,需要用$10来进行会话转换。也就是说,对于写数据的请求,一般来说需要在一个非默认会话,或解锁的状态下才能进行

$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数据)。

$14清除DTC

清除(复位)DTC格式,它可以改变DTC的状态。3个FF代表清除所有DTC。

Request:14+FF+FF+FF;
Response:54 。

诊断报文解析

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

CAN Message =CAN ID + CAN DATA

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

image.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
image.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限定连续帧相互之间所允许的最小时间间隔。

先面用连个例子进行说明,请参考!

例子 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 --- 多帧的数据接收与传输

[图片上传失败...(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为填充位。

参考资料:

作者:智车科技
链接:https://www.jianshu.com/p/b5805e734ed6
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342

推荐阅读更多精彩内容