UDS协议—14229—19、14服务解析"

admin 2026-10-15 17:01:15 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

UDS协议—14229—19、14服务解析

谈思实验室

2026年10月13日 17:49
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

01

什么是UDS?

UDS(统一诊断服务) 是汽车电子系统中广泛使用的诊断协议,基于ISO 14229标准的汽车电子诊断协议,用于ECU(电子控制单元)的诊断、调试、编程和维护。\"UDS诊断\"指通过访问车辆电子控制单元(ECU)提供的服务,获取车辆实时状态信息。技术人员可主动请求这些数据服务,从而分析车辆运行状况、定位故障原因,并据此进行维修维护或系统配置 。

形象点说,就是用一套仪器对当前汽车出现的问题进行分析,而这套仪器与汽车交谈所使用的语言就是UDS。

02

诊断服务

车辆诊断用于整车厂开发、产线测试、售后维修、OTA升级。主要目标是检测和查询电子控制单元(ECU)的故障,更新ECU软件,与ECU硬件进行交互(如控制IO引脚的开关使能),以及执行自检操作。

1、UDS服务

UDS服务包括但不局限于以下内容:

  • 诊断会话控制服务(0x10):用于控制诊断的启动和停止
  • 安全访问服务(0x27):用于解锁ECU访问,访问受保护的功能
  • 通讯控制服务(0x28):用于打开和关闭ECU报文的传输及接受
  • 诊断设备在线服务(0x3E):用于保持诊断工具与ECU之间的诊断连接
  • 通过标识符读取数据服务(0x22):使诊断工具从ECU中通过数据标识符进行数据读取
  • 通过标识符写入数据服务(0x2E):使用此服务通过数据标识符将数据写入到ECU中
  • 清除故障信息服务(0x14):用于清除ECU存储的故障码信息
  • 读取故障码信息服务(0x19):从ECU中读取存储在ECU内部的DTC信息
  • 例程控制服务(0x31):用于零部件标定的启动、结束以及请求零部件标定结果

2、DTC状态位定义

DTC状态位包含1个字节的数据长度,每个Bit位都有各自的含义,对应以下表格满足条件时,所对应的Bit位置1,通过读取各个Bit位的信息可以知道当前DTC的状态情况。开发时,需要双方协商一致,并不是每一个Bit都需要使用。

3、0x19 读取故障码信息服务

0x19服务:允许诊断仪通过该服务读取存储在ECU芯片内的故障码(DTC)状态信息。其中,该服务中又包含很多子服务,重点讲解常用的01、02、04、06、0A这5个子服务。

3.1 0x19 01服务(reportNumberOfDTCByStatusMask)

通过该服务,诊断仪能够请求ECU中DTC状态与DTC状态掩码相匹配的故障码个数。

3.1.1 0x19 01服务报文讲解

发送:19+01+DTCStatusMask(DTC状态掩码)

正响应:59+01+DTCStatusAvailabilityMask(ECU支持的状态掩码)+DTC格式(如下图进行选择)+DTCCount(2个字节)

例:

发 送:19 01 09

正响应:59 01 FF 01 00 04

DTCStatusMask=:09

DTCStatusAvailabilityMask:FF 这里只ECU支持的状态为1111 1111

DTC格式:01 (14229-1DTCF)

DTCCount:00 04  DTCCount的计算:

ECU中存储的DTC状态如果有:

DTC1 0000 1111

DTC2 0000 1101

DTC3 0000 1001

DTC4 0000 1100

DTC5 0000 0010

ECU中存储的DTC状态(DTC1、DTC2、DTC3、DTC4、DTC5)和

ECU支持的状态位(DTCStatusMask:09)相与

DTC1:0000 1111 &0000 1001->09

DTC2:0000 1101 &0000 1001->09

DTC3:0000 1001 &0000 1001->09

DTC4:0000 1100&0000 1001->08

DTC5: 0000 0010&0000 1001->00

从相与的结果可以看出,有4个非0的结果,所以回复00 04,表明有4个DTC满足

3.2 0x19 02服务(reportDTCByStatusMask)

按照定义的状态掩码形式去查找匹配的故障信息列表,将DTC标识符(3个字节)、DTC状态(1个字节)的所有信息返回。

3.1.1 0x19 02服务报文讲解

发送:19+02+DTCStatusMask(DTC状态掩码)

正响应:59+02+DTCStatusAvailabilityMask(ECU支持的状态掩码)+(DTC故障码(3个字节)……+DTC状态……)

例:

发 送:19 02 09

正响应:59 02 FF 60 00 01 2C 60 00 02 4F

DTCStatusMask:09

DTCStatusAvailabilityMask:FF

DTC1故障码:60 00 01

DTC1状态:2C

DTC2故障码:60 00 02

DTC2状态:4F

从回复中看出有两个故障:

2C:0010 1100  Bit0(Test Failed)为0,Bit3(Confirmed DTC)为1,故DTC1是一个历史故障

13:0100 1111  Bit0(Test Failed)为1,Bit3(Confirmed DTC)为1,故DTC1是一个当前故障

3.3 0x19 04服务(reportDTCSnapshotRecordByDTCNumber)

该服务用于请求指定故障码(DTC)的快照信息,通过查找故障发生时刻的这些数据,来分析故障原因,快照信息包括故障的发生时间、电压、行驶里程数、车速等。

3.3.1 0x19 04服务报文讲解

发送:19+04+DTC故障码(3个字节)+DTC快照记录编号

正响应:59+04+DTC故障码(3个字节)+DTC状态+DTC快照记录编号(如图)+快照信息中记录的信息成员数(几个DID)+第1个DID(2字节)+第1个DID对应的数值信息+第2个DID(2字节)+第2个DID对应的数值信息……

例:

发 送:19 04 60 00 01 02

正响应:59 04  60 00 01 2C 02 15 F1 02 01 C8 F1 03 21 C8 23……

DTC故障码: 60 00 01

DTC快照记录编号:02(DTC 快照可以分为不同的组,包含不同种类的快照信息,通常要记录某个DTC第一次发生(用01表示)和最近一次发生的快照数据时(用02表示)以及读取所有快照记数据(用FF表示)。

DTC状态:2C

快照信息中记录的信息成员数:15(这指的是所定义的快照数据为15个)

第1个DID:F1 02

第1个DID对应的数值信息:01 C8

第2个DID:F1 03

第2个DID对应的数值信息:21 C8 23

……还有13个DID和数值信息省略

3.4 0x19 06服务(reportDTCRecordByDTCNumber)

该服务获取指定DTC的扩展信息,用于记录故障的一些其他信息,比如故障发生的次数、老化次数、已老化次数等。

3.4.1 0x19 06服务报文讲解

发送:19+06+DTC故障码(3个字节)+扩展信息记录码

正响应:59+04+DTC故障码(3个字节)+DTC状态+扩展信息记录码+扩展信息

例:

发 送:19 06 60 00 01 01

正响应:59 06  60 00 01 2C 01 02

DTC故障码:60 00 01

扩展信息记录码:01(故障发生计数器)

DTC状态:2C

扩展信息:02(故障发生了2次)

3.5 0x19 0A服务(reportSupportedDTC)

该服务用于请求所有支持的DTC信息(3个字节DTC与1个字节的DTC状态),响应的报文返回的是所有DTC的信息,而02服务返回的是请求时状态掩码与之不为0的DTC信息。

3.5.1 0x19 0A服务报文讲解

发送:19+0A

正响应:59+0A+DTCStatusAvailabilityMask(ECU支持的状态掩码)+(DTC故障码(3个字节)……+DTC状态……)

例:

发 送:19 0A

正响应:59 0A FF 60 00 01 2C 60 00 02 4F……

DTCStatusAvailabilityMask:FF

DTC1故障码:60 00 01

DTC1状态:2C

DTC2故障码:60 00 02

DTC2状态:4F

……

4、0x14 清除诊断信息服务(ClearDiagnosticInformation)

该服务用于清除ECU内存 储的故障码信息。

4.1 0x14 服务报文讲解

发送:14+DTC编码/DTC编码组

正响应:54

例1:(清除某个固定的DTC)

发 送:14 B0 76 54

正响应:54

例2:(清除车身系统组DTC)

发 送:14 80 00 00

正响应:54

按组清除分为:

000000:排放相关系统

100000:动力系统组

400000:底盘系统组

800000:车身系统组

C00000:网络系统组

FFFFFF: 所有组故障信息

来源:CSDN博主「清轩轩」

https://blog.csdn.net/qq\_54112829/article/details/146909794

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自:

新势力车企:

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯......

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚......

内资传统主流车企:

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用......

全球领先一级供应商:

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、......

二级供应商(500+以上):

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学......

人员占比

公司类型占比

文章

不要错过哦,这可能是汽车网络安全产业最大的专属社区!

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全:TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些?

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言:关于构建完善汽车数据安全管理体系的建议

车载安全之锚:一文读懂HSM硬件安全模块" 网络安全文章

车载安全之锚:一文读懂HSM硬件安全模块"

本文系统介绍车载HSM硬件安全模块,阐述其作为安全之锚在密钥生成存储与隔离攻击中的核心作用,对比纯软件与硬件外设加密方案,详解SHE安全硬件拓展标准及EVITA划分的full、medium、light三个HSM等级及其特性差异,为汽车网络安全防护提供技术参考。
Agent时代,还有必要知道怎么写Prompt吗?(五刀一个完美Prompt)" 网络安全文章

Agent时代,还有必要知道怎么写Prompt吗?(五刀一个完美Prompt)"

文章提出Agent时代仍需掌握Prompt编写技巧,核心是解决意图传递失效问题。作者给出五刀方法论:补角色、补受众和目标、补约束、补示例、补验收,通过具体案例展示如何将模糊需求转化为可执行指令。强调在Agent能力增强的背景下,明确表达需求能避免方向性错误,提升AI交付成果的准确性。
评论:0   参与:  0