「uds协议对接java」UDS诊断协议
本篇文章给大家谈谈uds协议对接java，以及UDS诊断协议对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
uds协议是什么
UDS协议即ISO14229,统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ecu发什么指令，读数据流又是发什么指令。
OBD是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范。UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来。
基于UDS协议的诊断又常常被称为增强型诊断，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。
扩展资料
UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。
1、SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。
2、如果是肯定的响应（Positive Response），回复[SID+0x40]，如请求10，响应50；请求22，响应62。
3、如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。
参考资料来源：百度百科-UDS协议
uds是什麽意思？
UDS协议是一种统一的诊断服务是诊断服务的一个标准参考协议。比如读取故障码应该向ecu发什么指令读数据流又是发什么指令。是一套诊断协议对当前汽车出现的问题进行分析这套协议在汽车电子上目前使用非常多。相关介绍如下：1、诊断服务：OBD是关注车辆售后实时排放的理念形成的行业规范而UDS是诊断服务的统一化规范。UDS提供的是一个诊断服务的基本框架主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来。2、增强型诊断：基于UDS协议的诊断又常常被称为增强型诊断UDS非法规要求没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现。
UDS-CAN网络层传输协议
CAN传输数据长度最大8个字节;
SF（Single Frame） 例1:02 27 29 00 00 00 00 00;
SF第一字节的高4位为0，低4位为数据长度，其余字节为服务数据内容，没用到的数据可以按00或AA填充。
02:
0:第一字节高4位默认为0,表示单帧数据.
2:数据长度,表示在02后面有两个数据长度;为27 29;
多帧发送方式:
FF（First Frame）多帧传输的第一帧;
FC（Flow Control）多帧传输的流控制帧;
CF（Consecutive Frame）多帧传输的连续帧;
例2: FF 10 1E 59 04 00 01 00 27;
FC 30 00 00 00 00 00 00 00;
CF 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;
FF（First Frame）多帧传输的第一帧，其第一字节的高4位为1，低四位+第二字节为数据长度，其余字节为服务数据内容;
10 1E:
1:第一字节高四位默认为1;
01E:数据长度位30; 最大为FFF=4095可知传输数据最大长度为4095;
FC（Flow Control）多帧传输的流控制帧，其第一字节高四位为3，低四位为FS流控制状态;第二字节为BS数据块大小,第三字节为STmin间隔最短时长;
30:
3:第一字节高四位为3;
0;为FS流控制状态;
FS:
FS=0:表示允许发送方继续发送连续帧;
FS=1: 表示发送方需等待下一条流控制帧[1]，该流控制帧称为等待流控制帧;
FS=2: 表示报文长度超出接收方的网络层缓存大小，此流控制帧将迫使发送方中断多帧报文的发送，并且发送方网络层使用N_USData.con向应用层报告N_Result = N_Buffer_Overflow。FS = Overflow的流控制帧接收方只能在接收到第一帧后发送。
第二字节BS=00;
BS=00: 表示允许发送方连续发送连续帧，而不需要等待接收方发出的流控制帧;
BS=01||BS=FF: 表示允许发送方连续发送连续帧的数目，发送完成相应数目的连续帧后，发送方必须等待接收方发出的流控制帧;
BS为当前接收数据的数据长度,通过控制数据长度来防止通道堵塞;
第三字节STmin=00;
STmin=00||STmin=7F: 两个连续帧之间的最小间隔时间，0~127ms;
STmin=80||STmin=F0:Reserved保留;
STmin=F1||STmin=F9: 两个连续帧之间的最小间隔时间，100~900us;
STmin=FA||STmin=FF: Reserved保留;
如果发送方收到一个FC，其STmin的值是Reserved，则发送方应默认STmin为7F（127ms）;
STmin为两个CF之间的时间间隔,通过时间间隔控制接收数据的速率;
多帧发送三种情况:
1. 不停止接收:开始→FF→(接收方)FC→CF→结束;
2. 指定数据长度接收:开始→FF→(接收方)FC→CF(部分数据) →(接收方)FC→CF(部分数据) →(接收方)FC→CF(部分数据) →….. (接收方)FC→CF(部分数据)→结束;
3. 数据异常,不接收:开始→FF→(接收方)FC→结束;
UDS协议是什么
UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向ecu发什么指令，读数据流又是发什么指令.
UDS(Unified diagnostic services)，它是面向整车所有ECU(电控单元)的，它只是一个应用层协议(ISO 14229-1)，所以它既可以在CAN线上实现(见下图.1)，甚至也能在Ethernet上实现(DoIP, Diagnostic over Internet protocol 见下图.2)。并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。
在1939协议下和UDS协议下的单帧和多帧
在1939协议下在CANID中就以及规定了是多帧还是单帧 18EBxxxx和18ECxxxx是多帧（针对缓速器）
在UDS协议下CANID中没有规定是多帧还是单帧发送，只有通过底层返回的数据的第一个字节的高四位是否为0或者为1的时候来判断是否多帧还是单帧
FF（First Frame）多帧传输的第一帧，其第一字节的高4位为1，低四位+第二字节为数据长度，其余字节为服务数据内容，没用到的数据可以按FF填充。
FC（Flow Control）多帧传输的流控制帧，上位机发送流控帧给下位机，让下位机继续发送多帧数据
如何看懂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。
肯定响应和否定响应的形式一定要熟记。
UDS的26种服务中，有7种很重要。它们分别是：
下面对这7个服务进行解读。
$10包含3个子功能，
ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01 。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。
报文包含4种类型 ，即
NRC：Negative Response Code（否定响应码) 。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。
八个数据字节，第一字节被网络层占用 。
02中的0代表网络层单帧SF，2代表 数据域有2个字节； 10是SID，02是子功能 。
02同上，10+40表示对SID的肯定回复，02是子功能。
03同上，7F表示否定响应，10是SID，22是NRC。
$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。
例子：
27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。
比如下面的例子，2n-1是某个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。
$22读数据，
Request（请求）：
Response（响应）：
DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。
$22写数据，
Request（请求）：
Response（响应）：
注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。也就是说， 对于写数据的请求，一般来说需要在一个非默认会话，或解锁的状态下才能进行 。
DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将其存储为DTC。DTC可表现为：一个显而易见的故障:通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。
故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态 。前两个字节是我们熟知的类似P0047的故障码。
$19 拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。
清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。
UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构
根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.
网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：
综上所述， N_PDU =N_PCI+N_DATA , N_PCI 的值主要集中的 前三个字节 ， N_DATA 值主要集中在 后面7位字节 。其中，
先面用连个例子进行说明，请参考！
[图片上传失败...(image-b66bab-1538824826939)]
由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。
[图片上传失败...(image-b5e84b-1538824826939)]
数据发送为单帧，所以06代表发送的数据中含有6个字节，
回复为Positive Response，为连续帧。
参考资料：
uds协议对接java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于UDS诊断协议、uds协议对接java的信息别忘了在本站进行查找喔。