车辆控制单元诊断系统开发 --- UDS 诊断数据流解析
UDS诊断服务在车载ECU中的应用分析
UDS诊断服务在车载ECU中的应用分析黄丽芳【摘要】重点介绍基于IS014229，即OUDS的诊断服务，并结合车载ECU的组成架构分析UDS诊断服务在车载ECU中的应用。
%The ISO 14229, namely UDS diagnostic service is mainly introduced and the application of this service on vehicle ECU is analyzed according to the ECU framework.【期刊名称】《汽车电器》【年(卷),期】2012(000)006【总页数】4页(P60-63)【关键词】汽车诊断技术;诊断服务;UDS【作者】黄丽芳【作者单位】广州1汽车集团汽车研究院,广东广州510640【正文语种】中文【中图分类】U463.6随着汽车电子的发展，电子控制单元越来越复杂，车辆故障诊断也越来越重要。
汽车的电子控制单元大约有30%～40%的内存被用于故障诊断，诊断服务也越来越丰富，各种服务子功能也越来越细化[7]。
随着汽车诊断技术的发展，诊断协议越来越完善。
目前应用比较广泛的协议有ISO14229、ISO15765、ISO14230、SAE J1939。
早在1994年以前，ISO制定了ISO14230。
2008年以前，ISO14230是国内许多汽车厂商采用的诊断通信标准，是基于K线诊断的。
但随着K线的逐步淘汰，CAN（Controller Area Network，控制器局域网）网络的大力兴起，大多数主机厂都过渡到基于ISO15765的诊断协议。
但是随着车载网络的发展，又出现了MOST、FlexRay、无线网络等多种网络并存。
为了统一不同网络的诊断服务，ISO制定了一种新的诊断通信协议，ISO14229-1，也叫UDS（Unified diagnostic services，统一诊断服务）。
UDS诊断服务不仅用于目前盛行的CAN 网络，还可以用于以后的MOST、FlexRay、无线网络等，为汽车网络的发展做铺垫。
UDS最全内容总结
目录前言 (2)UDS 的7种服务及肯定响应和否定响应的形式 (3)$10诊断会话 (5)$3E待机握手 (6)$27安全访问 (7)$22读数据 (8)$2E写数据 (8)$19 读DTC (8)$14清除DTC (10)统一诊断服务(Unified diagnostic services ，UDS) （一） (10)Diagnostic request的格式： (10)统一诊断服务(Unified diagnostic services ，UDS) （二） (12)Diagnostic Session Control (0x10) (12)诊断response的格式：Diagnostic Session Control (13)ECU Reset 诊断request的格式 (13)Security Access (0x27) (13)统一诊断服务(Unified diagnostic services ，UDS) （三） (14)Tester Present (0x3E) (15)Control DTC Setting (0x85) (16)Response On Event (0x86) (16)Link Control (0x87) (16)统一诊断服务(Unified diagnostic services ，UDS) （四） (16)Read Data By Identifier (0x22) (16)0x23服务的请求格式0x23 (17)统一诊断服务(Unified diagnostic services ，UDS) （五） (17)0x14:Clear Diagnostic Information (17)0x19:Read DTC Information (18)统一诊断服务(Unified diagnostic services ，UDS) （六） (19)Input Output Control By Identifier (0x2F) (19)Routine Control (0x31) (20)统一诊断服务(Unified diagnostic services ，UDS) （七） (21)Request Download （0x34）： (21)Transfer Data（0x36）： (22)Request Transfer Exit（0x37）： (22)基于CAN总线实现的UDS诊断（DoCAN） (23)前言UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又是发什么指令。
UDS最全内容总结
UDS最全内容总结UDS（Unified Diagnostic Services）是一种用于在汽车电子控制单元之间进行诊断和通信的标准协议。
它定义了一套结构化的通信服务，使得汽车制造商和汽车维修厂商能够有效地连接和诊断各种电子控制单元。
本文将对UDS的最全内容进行总结。
UDS的核心功能是通过诊断请求和诊断响应在车辆电子系统之间进行通信。
UDS定义了一套诊断服务和功能的集合，包括诊断会话管理、ECU数据读取和写入、故障码管理、例程执行、报文传输和安全管理等。
UDS支持多种通信协议，如CAN、LIN、FlexRay等，可以在不同层次的网络上进行通信。
UDS的会话管理用于建立和维护UDS连接。
UDS定义了三种会话：默认会话、编程会话和标批会话。
默认会话用于诊断基本功能，编程会话用于ECU编程，标批会话用于同时执行多个功能。
会话管理还包括会话切换、安全访问认证等功能。
UDS的ECU数据读取和写入功能用于读取和修改ECU中的数据。
通过UDS协议，可以读取和修改ECU的参数、状态和配置信息。
UDS支持不同的读写操作，如单个字节、多个字节、按页读写、逐字节读写等。
UDS还定义了读写的级别和权限，可以设置为只读、读写等。
UDS的故障码管理功能用于管理和处理ECU的故障码。
UDS支持故障码的读取、解读、清除和存储。
UDS还定义了不同的故障码类型和级别，如当前故障码、历史故障码、预留故障码等。
故障码管理还包括DTC （Diagnostic Trouble Code）的定义、存储和显示。
UDS的报文传输功能用于在ECU之间传输诊断请求和响应。
UDS定义了一套通用的报文格式和传输机制，包括报头、源地址、目标地址、数据长度、CRC校验等。
UDS还支持多种传输模式，如物理报文、功能报文、网络管理报文等。
UDS的安全管理功能用于保护诊断通信的安全性。
UDS定义了一套安全机制和策略，包括安全访问认证、数据加密、消息完整性保护等。
UDS诊断服务在车载ECU中的应用分析
UDS诊断服务在车载ECU中的应用分析UDS（Unified Diagnostic Services）诊断服务是一种汽车电子控制单元（ECU）通信协议，它是一个基于CAN（Controller Area Network）总线的诊断协议，用于车辆在故障检测和修复方面的诊断。
这种诊断服务在车载ECU中的应用范围广泛，可以帮助工程师准确地诊断车辆的问题，并提高车辆的整体性能。
UDS诊断服务在车载ECU中的应用分析可以从以下几个方面进行说明：1. 检测车辆故障UDS诊断服务可以检测车辆的发动机、制动系统、传动系统、空调系统以及其他故障，对于车辆的诊断和维修工作非常有帮助。
利用UDS诊断服务，工程师可以定位并解决车辆存在的问题。
2. 提高诊断效率UDS诊断服务的使用可以大大提高车辆的诊断效率，与传统的诊断工具相比，UDS可以更快速、更准确地完成诊断过程。
使用UDS，工程师能够获取车辆的实时数据，并实时监测车辆的运行状态，在诊断过程中，还能够排除假故障，减少误判，提高诊断效率。
3. 依据UDS标准进行升级UDS的标准化使得在研发和制造过程中，车辆制造商能够将这种诊断技术直接集成到ECU中。
随着UDS技术的不断升级和发展，车辆制造商可以通过进一步集成，使得ECU更加智能化和高效化，这将显著提高车辆的性能和效率。
4. 提供车辆数据记录UDS诊断服务可以提供车辆数据记录功能，包括车辆的行驶数据、发动机数据和其他传感器信息等。
这些数据可以用于优化车辆的性能、提高车辆的安全性和减少车辆维修成本，同时也可以在改善产品的质量，提高制造效率方面得到应用。
总之，UDS诊断服务在车载ECU中的应用提供了高效、准确和可靠的车辆故障检测和维修服务。
随着车辆制造技术的不断发展和UDS技术的普及，UDS是迈向车辆智能化和高效化的关键技术之一。
5. 支持OBD-II诊断OBD（On Board Diagnostic）是汽车故障检测的标准，它在美国、欧洲和许多其他国家都有广泛的应用。
UDS诊断详解
6
光传感器内部故障
0x90B196
2019/10/17
6
四-2:输入/输出线路的开路或短路情
№
诊断失效功能 Subtype Description
$19
InputOutputControlByIdentifier $2F
RoutineControl
$31
RequestDownload
$34
RequestUpload
$35
TransferData
$36
RequestTransferExit
$37
DEFAULT
EXTENDED DEFAULT PROGRAMMING
5
Test failed since last clear 上次清零后测试失效
Test not completed this operation
6 cycle 本运行周期测试未完成
7
Warning indicator requested 警告指示位请求
2019/10/17
Bit State Definition 位状态定义
Bit Description 描述
0
Test failed 测试失效
1
Test failed this operation cycle 本运行周期测试失效
2
Pending DTC 等待DTC
3
Confirmed DTC 确认DTC
4
Test not completed since last clear 上次清零后测试未完成
信。
但是对于此项目 , BCM作为网关, 连接了多个网段的ECU, 外部设备只能通过其中 一个网段 对该 ECU进行诊断操作, 推荐选择路由工作量较低的网段.
基于CAN总线的汽车诊断协议UDS（ECU底层模块移植开发）
基于CAN总线的汽车诊断协议UDS（ECU底层模块移植开发）⼀、意义为了指导开发⼯程师，正确的使⽤诊断模块，快速开发出满⾜车⼚要求的诊断功能。
⼆、诊断模块介绍此诊断模块根据ISO-14229-1⽂档，并结合部分车⼚的⽂档进⾏开发，使⽤⾯向对象的思路进⾏设计，将模块需要处理的所有事情封装在模块内部，留出模块处理过程接⼝和配置接⼝供调⽤接⼝的⼯程师使⽤。
通过调⽤配置接⼝，可以配置我们想要的功能。
通过调⽤处理过程接⼝，诊断模块便能提供诊断服务，⽆需其他操作，便能实现诊断功能，开发起来⽅便快捷。
使⽤过程中的复杂之处在于配置，需要根据具体项⽬的诊断需求进⾏具体配置。
以下详细介绍。
三、接⼝与配置说明1、类型定义1）、安全等级定义typedef enum{LEVEL_ZERO = 7,//安全等级0，当⼀个服务不需要安全解锁时，使⽤此安全等级。
LEVEL_ONE = 1,//安全等级1，当⼀个服务可以在安全等级1时，使⽤此安全等级。
LEVEL_TWO = 2,//安全等级2，当⼀个服务可以在安全等级2时，使⽤此安全等级。
LEVEL_THREE = 4,//安全等级3，当⼀个服务可以在安全等级3时，使⽤此安全等级。
LEVEL_FOUR = 8,//安全等级4，⼯⼚模式会话使⽤此安全等级，⽤户零部件商下线配置。
LEVEL_UNSUPPORT = 0,//不⽀持，当⼀个服务在某个会话模式不⽀持时，使⽤此等级。
}SecurityLevel;2）、复位类型，参考ISO-14229-1中11服务复位类型的定义。
typedef enum{HARD_RESET = 1,//硬件复位KEY_OFF_ON_RESET = 2,//关开钥匙复位SOFT_RESET = 3,//软件复位ENABLE_RAPID_POWER_SHUTDOWN = 4,//预留，⼀般不使⽤DISABLE_RAPID_POWER_SHUTDOWN = 5,//预留，⼀般不使⽤}EcuResetType;3）、DTC类型定义。
UDS最全内容总结资料讲解
前言 (2)UDS 的7种服务及肯定响应和否定响应的形式 (3)$10诊断会话 (5)$3E待机握手 (6)$27安全访问 (7)$22读数据 (8)$2E写数据 (8)$19 读DTC (9)$14清除DTC (10)统一诊断服务(Unified diagnostic services ，UDS) （一） (11)Diagnostic request的格式： (11)统一诊断服务(Unified diagnostic services ，UDS) （二） (12)Diagnostic Session Control (0x10) (13)诊断response的格式：Diagnostic Session Control (13)ECU Reset 诊断request的格式 (14)Security Access (0x27) (14)统一诊断服务(Unified diagnostic services ，UDS) （三） (14)Tester Present (0x3E) (16)Control DTC Setting (0x85) (16)Response On Event (0x86) (16)Link Control (0x87) (16)统一诊断服务(Unified diagnostic services ，UDS) （四） (17)Read Data By Identifier (0x22) (17)0x23服务的请求格式0x23 (17)统一诊断服务(Unified diagnostic services ，UDS) （五） (18)0x14:Clear Diagnostic Information (18)0x19:Read DTC Information (18)统一诊断服务(Unified diagnostic services ，UDS) （六） (19)Input Output Control By Identifier (0x2F) (19)Routine Control (0x31) (21)统一诊断服务(Unified diagnostic services ，UDS) （七） (21)Request Download （0x34）： (22)Transfer Data（0x36）： (22)Request Transfer Exit（0x37）： (23)基于CAN总线实现的UDS诊断（DoCAN） (23)前言UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又是发什么指令。
商用车电控单元UDS诊断协议栈的开发与应用
商用车电控单元UDS诊断协议栈的开发与应用作者：白蒲江孟晨兴来源：《机电信息》2020年第30期摘要：首先介绍了UDS的特点及优势，然后具体对UDS的服务功能进行了说明，最后以缓速器电控单元的诊断设计为例，阐述了UDS的设计要点及其在车辆标定诊断测试中的应用。
关键词：UDS;电控单元;诊断标定1 技术背景CAN（Controller Area Network，控制器局域网）是国际上应用最广泛的汽车通信总线之一。
为实现智能化控制、共享数据信息，商用车将所有的车载电器和ECU控制单元都搭载到CAN网络总线上[1]。
随着汽车ISO（International Standard Organization）诊断标准日趋完善，ISO 15765诊断通信协议规范了基于CAN总线的诊断服务UDS（Unified Diagnostic Services）。
UDS是面向商用车控制单元的应用层协议（ISO 14229-1），提供了诊断服务的基本框架，主机厂和零部件供应商可以根据自身情况自定义诊断服务。
2 缓速器控制器诊断需求说明随着汽车嵌入式技术的发展，商用车控制系统规模日益扩大，复杂程度不断提高，给整车各种控制单元的诊断、升级服务带来了新的挑战。
对缓速器而言，信号连接上，控制器与整车信号的交互已经从全硬线传输过渡到硬线加CAN通信传输上来，未来为了满足整车数据共享的需求，将实现全CAN通信传输;整车均配备了OBD诊断接口，控制器与该接口连接，利用诊断仪等可以实现控制器程序升级及数据监测等。
功能方面，原来识别驾驶员手柄档位控制缓速器输出制动力，现在能响应来自电子制动系统装置（制动踏板）、车身装置（手柄）的扭矩请求，精准控制缓速器辅助整车进行制动。
整车人机接口方面，控制器与智能化仪表通过CAN方式进行交互，不仅线束连接更加简单，还能实现运行数据、故障灯、故障码显示。
综上所述，对于缓速器控制而言，为满足驾驶员对车辆功能持续提升、维修人员对车辆故障快速处理的需求，缓速器控制系统应支持用户利用诊断仪对控制器进行程序刷写、故障诊断、参数标定、数据采集等方面的操作。
uds诊断开发流程
uds诊断开发流程下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。
文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!UDS（Unified Diagnostic Services，统一诊断服务）诊断开发流程一般包括以下步骤：1. 需求分析：确定诊断功能和需求，包括诊断请求、响应、错误处理等。
UDS诊断详解
2021/4/20
3
3.7支持的UDS服务
DIAGNOSTIC SERVICE
session@APPLICATION SOFTWARE
session@BOOTLOADER
SERVICE NAME
SID
DiagnosticSessionControl $10
EcuReset
$11
SecurityAccess
B 类电控单元，可以不支持诊断通信协议。 接入LIN 网络的主节点，应为A 类电控单元；接入LIN 网络的从节点，应为B 类电 控单元。接入多路CAN 总线的电控单元，应选择速率最高的CAN 总线进行诊断通 信。
但是对于此项目 , BCM作为网关, 连接了多个网段的ECU, 外部设备只能通过其中 一个网段 对该 ECU进行诊断操作, 推荐选择路由工作量较低的网段.
0 <30ms
5
2021/4/20
10
Failure Type Byte DTC Failure Subtype
0X900516
0X900517
2021/4/20
8
四-4 网络通信异常情况
№
诊断失效功能 Subtype Description
1
LIN bus off failureLIN总线通信故障
2
Lost communication with ECU与某ECU失 去通信
2021/4/20
2
三. 诊断需求定义说明
3.1 自诊断需求
所有ECU 都应持续地进行故障自诊断，以监控运行状态下的异常事件（错误）。故障自诊断
包括两种：初始化阶段自诊断及持续运行时的自诊断。
3.2 故障自诊断范围
uds诊断实现流程
uds诊断实现流程UDS（Unified Diagnostic Services）诊断是一种用于汽车电子控制单元（ECU）的诊断通信协议。
它通过在汽车ECU和诊断工具之间建立通信连接，实现对车辆电子系统进行故障诊断和参数配置的功能。
本文将介绍UDS诊断的实现流程。
UDS诊断实现流程可以分为以下几个步骤：1. 建立诊断通信连接在诊断工具与车辆ECU之间建立通信连接是UDS诊断的第一步。
通常，诊断工具通过诊断接口（如OBD-II接口）与车辆ECU进行物理连接。
然后，诊断工具发送一个诊断请求给车辆ECU，请求建立通信连接。
车辆ECU接收到请求后进行响应，建立诊断通信连接。
2. 识别车辆ECU在建立通信连接后，诊断工具需要识别车辆ECU的身份。
这是因为现代汽车通常由多个ECU组成，每个ECU负责不同的功能。
诊断工具发送一个识别请求给车辆ECU，请求获取ECU的身份信息。
车辆ECU接收到请求后返回ECU的身份信息，诊断工具通过解析身份信息来识别车辆ECU。
3. 诊断会话管理UDS诊断协议定义了多个诊断会话，每个会话对应着不同的诊断操作。
在识别车辆ECU后，诊断工具需要选择合适的诊断会话进行后续的诊断操作。
通常，诊断会话分为默认会话和扩展会话两种。
默认会话用于常规的诊断操作，而扩展会话则提供了更高级的诊断功能。
诊断工具发送一个会话切换请求给车辆ECU，请求切换到所需的诊断会话。
车辆ECU接收到请求后切换到指定的诊断会话。
4. 诊断服务请求在选择合适的诊断会话后，诊断工具可以向车辆ECU发送诊断服务请求。
诊断服务是UDS诊断协议定义的一系列操作，用于实现不同的诊断功能。
例如，诊断工具可以发送读取数据请求来获取车辆ECU的参数值，也可以发送写入数据请求来配置车辆ECU的参数。
诊断工具发送一个诊断服务请求给车辆ECU，请求执行相应的诊断服务。
车辆ECU接收到请求后执行诊断服务，并返回相应的结果给诊断工具。
5. 诊断服务响应车辆ECU接收到诊断服务请求后，执行相应的诊断服务，并返回诊断服务的执行结果给诊断工具。
车辆控制单元诊断系统开发 --- UDS 诊断数据流解析
车辆控制单元诊断系统开发--- UDS 诊断数据流解析屌丝小蚂蚁4 个月前之前在专栏里面写过一篇关于UDS诊断协议的介绍，对比于专栏文章的热度与一位朋友的咨询，决定在上篇文章的基础上，对UDS诊断协议开发进行进一步的解析。
UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构CAN Message = CAN ID + CAN DATACAN ID 分为标准与扩展，两种类型，具体大家可以百度，百度上老多了。
在UDS的协议里面ID 的类型并没有对其进行具体的定义，可以根据自己的需求进行自己定义，在Autosar里面是个两个配置变量，一个配置ID值，一个配置ID类型，大家自己配置一下就可以，对于UDS数据流来说，需要重点分析一下CAN DATA. CAN DATA的最终形成是在网络层实现的，遵循ISO15765-2的规则，在这个层里面吸收应用层的UDS诊断数据，同时增加了这个CAN 信息的控制信息，最终形成一个帧的CAN消息，放入物理层的数据收发器里面。
根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data. 具体如下图所示：综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。
其中，SF_DL 代表单帧中数据的个数，FF_DL代表连续帧中的数据总数，SN代表此帧为连续帧中的第几帧，FS参数控制发送端是否能继续传输数据，BS规定发送端允许持续传输连续帧数目的最大值，STmin限定连续帧相互之间所允许的最小值。
先面用连个例子进行说明，请参考！例子1--- 单帧的数据传输与接收数据发送：27 09数据反馈：7F 27 7E --- 负反馈数据发送：10 40数据反馈：50 40 00 32 01 F4下图为在Canlyzer里面的数据截图，请参考由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个数据位，02，03，02，06代表的为此帧数据含有几个数据位，多余的数据位都用00或者AA行填充。
UDS最全内容总结
UDS最全内容总结UDS最全内容总结UDS（Unified Diagnostic Services）是一种诊断通信协议，它是OBD（On-board Diagnostics）协议的升级版，旨在提高诊断功能和系统性能，使得诊断更加准确和高效，广泛应用于汽车和工业控制领域。
UDS通信协议包含了多个服务和功能，这些服务和功能支持诊断、编程、配置、测试和故障排除，如读取/写入ECU数据、清除故障码、查看实时数据、执行特定动作等。
UDS与OBD协议相比具有更高级别和更丰富的诊断服务，它采用ISO 15765-2协议实现了标准和扩展的诊断通信，对底层协议进行了优化，实现了更快的诊断速度和更容易的软件设计。
以下是UDS协议中常见的一些服务和功能：1. 诊断控制服务（Diagnostics Control Service）：用于控制诊断会话的开始和结束、安全访问保护和调取ECU功能的能力。
2. ECU重置服务（ECU Reset Service）：用于重置设备或模块以恢复出厂设置，解除错误状态或清除所有已知错误记录。
3. 读取数据服务（Read Data By Identifier Service）：按标识符读取ECU的实时数据流，包括传感器状态、电压、水温等。
4. 诊断会话控制服务（Diagnostic Session ControlService）：用于与ECU之间建立通信会话，识别会话类型并更改会话条件。
5. 清除故障码服务（Clear Diagnostic Information Service）：用于清除诊断卡车或模块中的存储的错误代码并删除相关的事件所记录的信息。
6. 读取故障码服务（Read Diagnostic Trouble Codes Service）：读取诊断系统中是否有存储的故障码，并返回故障的代码和错误部件的标识符。
7. 修改数据服务（Write Data By Identifier Service）：根据标识符修改ECU的数据、参数、设置和配置。
UDS诊断服务解读
4
诊断服务
SID
0x10 0x11 0x14 0x19 0x22 0x27 0x28 0x2E 0x31 0x3E
描述
DiagnosticSessionControl ECUReset ClearDiagnosticInformation ReadDTCInformation ReadDataByIdentifier SecurityAccess CommunicationControl service WriteDataByIdentifier RoutineControl TesterPresent
8
DiagnosticSessionControl
正响应格式
Data Byte No. 1 2 Parameter Name Diagnostic Session Control Response Service Id Diagnostic Session Type Message Usage M M Data Value[hex] 50 00-FF
0x85
ControlDTCSetting
5
否定响应（1）
数值 0x11 0x12 0x13 0x22 0x31 0x33 描述 serviceNotSupported 服务器不支持客户端请求的诊断服务 subfuntionNotSupported 服务器不支持客户端请求服务的子功能 incorrectMessageLengthOrInvalidFormat 服务器认为客户端的请求报 文的数据长度（或者格式）不符合标准 conditionsNotCorrect 服务器执行诊断服务的条件不满足 requestOutOfRange 服务器没有客户端请求的数据，此否定响应适用 于支持数据读、写，或者根据数据调整功能的服务器 securityAccessDenied 服务器阻止客户端的受限诊断服务请求，原因 包括： 服务器的测试条件不满足 服务器的安全状态处于锁定状态
UDS最全内容总结
前言 (3)UDS 的7种服务及肯定响应和否定响应的形式 (4)$10诊断会话 (7)$3E待机握手 (9)$27安全访问 (9)$22读数据 (11)$2E写数据 (12)$19 读DTC (12)$14清除DTC (13)统一诊断服务 (Unified diagnostic services ， UDS) （一） (15)Diagnostic request的格式： (15)统一诊断服务 (Unified diagnostic services ， UDS) （二） (17)Diagnostic Session Control (0x10) (18)诊断response的格式：Diagnostic Session Control (19)ECU Reset 诊断request的格式 (19)Security Access (0x27) (19)统一诊断服务 (Unified diagnostic services ， UDS) （三） (20)Tester Present (0x3E) (22)Control DTC Setting (0x85) (23)Response On Event (0x86) (23)Link Control (0x87) (23)统一诊断服务 (Unified diagnostic services ， UDS) （四） (24)Read Data By Identifier (0x22) (24)0x23服务的请求格式0x23 (25)统一诊断服务 (Unified diagnostic services ， UDS) （五） (25)0x14:Clear Diagnostic Information (26)0x19:Read DTC Information (26)统一诊断服务 (Unified diagnostic services ， UDS) （六） (28)Input Output Control By Identifier (0x2F) (28)Routine Control (0x31) (30)统一诊断服务 (Unified diagnostic services ， UDS) （七） (31)Request Download （0x34）： (32)Transfer Data（0x36）： (33)Request Transfer Exit（0x37）： (33)基于CAN总线实现的UDS诊断（DoCAN） (34)前言UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又是发什么指令。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
车辆控制单元诊断系统开发 --- UDS 诊断数据流解析
屌丝小蚂蚁
4 个月前
之前在专栏里面写过一篇关于UDS诊断协议的介绍，对比于专栏文章的热度与一位朋友的咨询，决定在上篇文章的基础上，对UDS诊断协议开发进行进一步的解析。
UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构
CAN Message = CAN ID + CAN DATA
CAN ID 分为标准与扩展，两种类型，具体大家可以百度，百度上老多了。
在UDS的协议里面 ID 的类型并没有对其进行具体的定义，可以根据自己的需求进行自己定义，在Autosar里面是个两个配置变量，一个配置ID值，一个配置ID类型，大家自己配置一下就可以 ，对于UDS数据流来说，需要重点分析一下CAN DATA. CAN DATA的最终形成是在 网络层实现的，遵循ISO15765-2的规则，在这个层里面吸收应用层的UDS诊断数据，同时增加了这个CAN 信息的控制信息，最终形成一个帧的CAN消息，放入物理层的数据收发器里面。
根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data. 具体如下图所示：
综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。
其中，SF_DL 代表单帧中数据的个数，FF_DL代表 连续帧中的数据总数，SN代表此帧为连续帧
中的第几帧， FS参数控制发送端是否能继续传输数据，BS规定发送端允许持续传输连续帧数目的最大值，STmin限定连续帧相互之间所允许
的最小值。
先面用连个例子进行说明，请参考！
例子 1--- 单帧的数据传输与接收
数据发送：27 09
数据反馈：7F 27 7E --- 负反馈
数据发送： 10 40
数据反馈： 50 40 00 32 01 F4
下图为在Canlyzer里面的数据截图，请参考
由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个数据位，02，03，02，06代表的为此帧数据含有几个数据位，多余的数据位都用 00或者AA行填充。
例子2 --- 多帧的数据接收与传输
数据发送：19 04 00 01 00 00
数据反馈：59 04 00 01 00 27 00 0B FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
下图为在Canlyzer里面的数据截图，请参考
数据发送为单帧，所以06代表发送的数据中含有6个字节，回复为正反馈，为连续帧，10 代表连续帧的首帧，1E代表此连续帧含有30个字节，30代表此连续帧的流控制帧，21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。