【ISO14229_UDS_0x24服务详解】

已于 2023-06-23 11:54:01 修改
阅读量917 收藏 3
点赞数 1
分类专栏： ISO14229-UDS诊断服务介绍 文章标签： mcu
于 2023-05-28 13:56:40 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43722921/article/details/130909403
版权

目录

1、0x24服务（根据标识符读取缩写信息服务）

  Service description：
  0x24服务（ReadScalingDataByIdentifier，根据标识符读取缩写信息服务）允许客户端从服务端请求DID的缩写信息。
  客户端请求报文中包含了一个dataIdentifier(DID)值，用于标识服务端中维护的数据记录。数据记录(dataRecord)的格式和定义应该由汽车制造厂商来指定，可包括一些模拟输入和输出信号、数字输入和输出信号、内部的数据和系统状态信息(如果服务端支持)。
  在接收到0x24服务(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的请求后，服务端应该访问与指定dataIdentifier(DID)参数有关的缩写信息，并在肯定应答报文中去传输这些缩写信息值。

2、请求报文格式

2.1 请求报文定义

  请求报文的定义：

字节序号参数值约定字节值
#1ReadScalingDataByIdentifier Request SIDM0x24

#2
#3		dataIdentifier[] = [
        byte#1 (MSB)
        byte#2 ]
M
M
0x00 – 0xFF
0x00 – 0xFF

2.2 请求报文中子函数参数定义

  该服务未使用子函数参数。

2.3 请求报文中数据参数定义

  该服务在请求报文中的数据参数定义如下表所示：

定义
DataIdentifier
该参数标识了客户端正在请求服务端的数据记录，即DID。

3、肯定应答报文

3.1 肯定应答报文格式定义

字节序号参数值约定字节值
#1ReadScalingDataByIdentifier Response SIDM0x64

#2
#3		dataIdentifier[] =[
        byte#1 (MSB)
        byte#2 (LSB) ]
M
M
0x00 – 0xFF
0x00 – 0xFF
#4scalingByte#1M0x00 – 0xFF

#5
.
.
#(p-1)+5		scalingByteExtension[]#1 = [
        scalingByteExtensionParameter#1
        .
        .
        scalingByteExtensionParameter#p ] ]
C1
.
.
C1
0x00 – 0xFF
.
.
0x00 – 0xFF
.
.		        .
        .		.
.		.
.
#n-rscalingByte#kC20x00 – 0xFF

#n-(r-1)
.
.
#n		scalingByteExtension[]#k = [
        scalingByteExtensionParameter#1
        .
        .
        scalingByteExtensionParameter#r ]
C1
.
.
C1
0x00 – 0xFF
.
.
0x00 – 0xFF

  C1：该参数的存在取决于scalingByte的high nibble。如果scalingByte high nibble被编码为公式、单位/格式或bitmappedreporttedwithoutmask，则必须存在。
  C2：此参数的存在取决于缩写信息的编码是否需要超过一个字节。

3.2 肯定应答报文数据参数定义

Definition
dataIdentifier
请求报文中的DID。
scalingByte (#1 to #k)
0x24服务（ReadScalingDataByIdentifier，根据标识符读取缩写信息服务）肯定应答报文中提供给客户端的换算数据记录值。
scalingByteExtension (#1 to #p / #1 to #r)
high nibble被编码为公式、单位/格式或bitmappedreporttedwithoutmask，为scalingByte提供额外信息

  其中，参数scalingByte (SBYT)由一个字节(high和low nibble)组成。scalingByte high nibble定义了用于表示数据标识符(DID)的数据类型。scalingByte low nibble定义了在数据流中用于表示参数的字节数。
  scalingByte (High Nibble)的定义如下表：

High Nibble编码数据类型描述约定
0x0unSignedNumeric (1 to 4 bytes)
这种编码使用一种通用的二进制加权方案，通过离散增量步来表示一个值。一个字节表示256步;两个字节产生65536个步骤，等等。		U
0x1signedNumeric (1 to 4 bytes)
这种编码使用二补二进制加权方案，通过离散增量步来表示一个值。一个字节表示256步;两个字节产生65536个步骤，等等。		U
0x2bitMappedReportedWithOutMask
位映射编码使用单个位或小组位来表示状态。有效掩码用于指示特定应用中每个位的有效性。bitmappedreporttedwithoutmask编码表示有效掩码不是参数定义本身的一部分。		U
0x3bitMappedReportedWithMask
位映射编码使用单个位或小组位来表示状态。bitmappedreporttedwithmask编码表示有效掩码包含在参数定义本身中。对于每个表示状态的位，需要一个相应的掩码位作为参数定义的一部分。掩码表示特定应用中每个比特的有效性。这种类型的位映射参数为表示数据的每个状态字节包含一个有效掩码字节。由于有效性掩码是参数定义的一部分，因此不需要单独的scalingByteExtension。		U
0x4BinaryCodedDecimal
传统的二进制编码十进制编码用于表示每个字节的两个数字。upper nibble用来表示最高有效数字(0 -9)，lower nibble用来表示最低有效数字(0 -9)。		U
0x5stateEncodedVariable (1 byte)
这种编码使用二进制加权方案来表示多达256种不同的状态。一个例子是参数，它表示点火开关的状态。代码“00”、“01”、“02”和“03”分别表示点火关闭、锁定、运行和启动。这种表示总是被限制为一个字节。		U
0x6ASCII (1 to 15 bytes for each scalingByte)
传统的ASCII编码用于表示多达128个标准字符，MSB =逻辑’0’。另外128个自定义字符可以用MSB =逻辑’1’表示。		U
0x7signedFloatingPoint
浮点编码用于需要用浮点或科学记数法表示的数据。标准IEEE格式应根据ANSI/IEEE标准754-1985使用。		U
0x8packet
数据包包含多个数据值，通常是相关的，每个值都有惟一的缩放。不包括各个值的缩放信息。		U
0x9formula
使用公式从原始数据计算一个值。公式标识符在定义公式标识符编码的表中指定。		U
0xAunit/format
这些单位和格式用于以更加用户友好的格式表示数据。单位标识符和格式标识符在定义formulaIdentifier编码的表中指定。
如果使用组合单位和/或格式，例如mV，则每个单位/格式的scalingByte(和scalingData)应包含在readScalingDataByIdentifier的正响应中。		U
0xBstateAndConnectionType (1 byte)
这种编码特别用于输入和输出信号。编码在数据字节中的信息指定了高级物理布局、电平和功能状态。建议对数字输入和输出参数使用此选项。		U
0xC - 0xFISOSAEReserved
ISO保留		M
          

  scalingByte (Low Nibble)的定义如下表：

Low Nibble编码数据类型描述约定
0x0 – 0xFnumberOfBytesOfParameter
此值范围由数据流中引用的参数标识符的数据字节数指定。参数的长度由缩放字节 scaling byte(s) 定义，其前面总是有一个参数标识符(一个或多个字节)。如果参数标识符后面有多个缩放字节，则参数标识符引用的数据长度是缩放字节中low nibbles内容的总和。
如VIN是由一个单字节参数标识符和后跟两个缩放字节来标识的。长度最多计算为17个数据字节。两个low nibbles的内容可以是任何值的组合，加起来最多17个数据字节。
对于以公式或单位/格式编码的high nibble的scalingByte，该值为0x0。		U

4、支持的否定应答码(NRC_)

  本服务应实施如下否定响应代码，下表记录了每个应答代码发生的情况，如果服务端在错误场景使用了该服务，则应使用如下列出的否定响应代码。

NRC描述
0x13incorrectMessageLengthOrInvalidFormat
请求报文长度不正确时，会发送该NRC
0x22conditionsNotCorrect
服务端的运行条件不满足去执行请求的动作时，会发送该NRC
0x31requestOutOfRange
如下情况发送该NRC：
— 请求的DID值不被设备所支持；
— 请求的DID值被设备所支持，但是没有指定标识符(dataIdentifier，DID)换算信息；
0x33SecurityAccessDenied
DID是保密的，并且服务端处于上锁状态，会发送该NRC

  0x24服务（ReadScalingDataByIdentifier，根据标识符读取缩写信息服务）的否定应答码(NRC)具体处理过程如下图所示：
在这里插入图片描述

5、0x24（ReadScalingDataByIdentifier，根据标识符读取缩写信息服务）案例说明

  Assumptions:
  如下案例中，假定运行0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的条件都满足，客户端可以在任何时候请求与服务端状态无关的数据标识符(DID)的换算数据。
  案例1读取了两个字节的0xF190 DID的换算信息，其包含了17个字符的VIN数字。
  案例2展示了在服务器中指定的数据变量，如何使用公式和单元标识符。
  案例3展示了第三个示例演示了如何使用readScalingDataByIdentifier返回位映射的数据标识符支持的位(有效掩码)，该数据标识符通过使用readDataByIdenditfier报告时没有掩码。
  例1：readScalingDataByIdentifier wth dataIdentifier 0xF190 (VIN number)
  案例1 0x24(ReadScalingDataByIdentifier，根据标识符读取换算信息服务)的请求报文使用如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ReadScalingDataByIdentifier Request SID0x24
#2dataIdentifier [ byte#1 ] (MSB)0xF1
#3dataIdentifier [ byte#2 ] (LSB)0x90

  案例1 0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ReadMemoryByAddress Response SID0x64
#2dataIdentifier [ byte#1 ] (MSB)0xF1
#3dataIdentifier [ byte#2 ] (LSB)0x90
#4scalingByte#1 {ASCII, 15 data bytes}0x6F
#5scalingByte#2 {ASCII, 2 data bytes}0x62

例2：readScalingDataByIdentifier wth dataIdentifier 0x0105 (Vehicle Speed)
  案例2 0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的请求报文使用如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ReadScalingDataByIdentifier Request SID0x24
#2dataIdentifier [ byte#1 ] (MSB)0x01
#3dataIdentifier [ byte#2 ] (LSB)0x05

  案例2 0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ReadScalingDataByIdentifier Response SID0x64
#2dataIdentifier [ byte#1 ] (MSB)0x01
#3dataIdentifier [ byte#2 ] (LSB)0x05
#4scalingByte#1 {unsigned numeric, 1 data byte}0x01
#5scalingByte#2 {formula, 5 data bytes}0x95
#6scalingByteExtension#2 [ byte#1 ] {formulaIdentifier = C0 * x + C1}0x00
#7scalingByteExtension#2 [ byte#2 ] {C0 high byte}0xE0
#8scalingByteExtension#2 [ byte#3 ] {C0 low byte} [ C0 = 75 * 10P-2P ]0x4B
#9scalingByteExtension#2 [ byte#4 ] {C1 high byte}0x00
#10scalingByteExtension#2 [ byte#5 ] {C1 low byte} [ C1 = 30 * 10P0P ]0x1E
#11scalingByte#3 {unit / format, 1 data byte}0xA1
#12scalingByteExtension#3 [ byte#1 ] {unit ID, km/h}0x30

  单位，车速数据变量采用下式计算:
    Vehicle Speed = (0.75 * x + 30) km/h.

例3：readScalingDataByIdentifier wth dataIdentifier 0x0967
  这个案例展示了客户端如何确定服务端中的数据标识符支持哪些位，该数据标识符被格式化为无有效掩码的位映射记录。案例中，dataIdentifier (0x0967)定义如下：

字节Bit(s)描述
#17-4
3
2
1
0		Unusued
命令打开中速风扇
检测到中速风扇输出故障
Purge monitor soak time status flag
Purge monitor idle test is prevented due to refuel event
#17
6
5
4
3
2
1
0		检查燃油盖指示灯是否已亮起
检查油盖灯输出是否有故障
A模式风扇控制输出故障
B模式风扇控制输出故障
高速风扇输出故障检测
命令高速风扇输出
Purge monitor idle test (small leak) ready to run
Purge monitor small leak has been monitored

  案例3 0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的请求报文使用如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ReadScalingDataByIdentifier Request SID0x24
#2dataIdentifier [ byte#1 ] (MSB)0x09
#3dataIdentifier [ byte#2 ] (LSB)0x67

  案例3 0x24(ReadScalingDataByIdentifier，根据标识符读取缩写信息服务)的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ReadScalingDataByIdentifier Response SID0x64
#2dataIdentifier [ byte#1 ] (MSB)0x09
#3dataIdentifier [ byte#2 ] (LSB)0x67
#4scalingByte#1 {bitMappedReportedWithOutMask, 2 data bytes}0x22
#5scalingByteExtension#1 [ byte#1 ] {dataRecord#1 Validity Mask}0x03
#6scalingByteExtension#1 [ byte#2 ] {dataRecord#2 Validity Mask}0x43

  上面的示例假设服务器中该dataIdentifier支持的唯一位(即包含信息的位)是字节#1、位1和位0，以及字节#2、位6、位1和位0。

返回UDS诊断服务功能单元介绍目录

三星小卤蛋
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
UDS协议一致性测试之Service 27环境NRC 13、NRC 24优先级判断
Soly_kun的博客
01-14 3828
预祝各位看官周末愉快，牙齿晒太阳哈。 今天闲聊下在进行UDS协议一致性测试时，Service 27测试背景下NRC 13/24优先级判断问题。 在实际一个车载控制器项目，首先OEM会提出该控制器的诊断需求规范（本文暂以诊断视角分析问题），对于测试端，会根据需求规范，提炼出测试规范。 测试的目的是验证控制器功能实现是否是按照需求规范定义的内容来实现的，当然这期间会有很多正向、逆向、各种非工况的测试。 当然对于测试而言，又区分很多内容：单元测试、集成测试、敏捷测试等等，不是本文重点，不过多讨论。 首先
跟我学UDS(ISO14229) ———— 0x24(ReadScalingDataByIdentifier)
永远的菜鸡小詹的博客
06-07 3890
该服务允许客户端请求读取DID记录的缩放信息。客户端请求消息包含一个DID值，该值标识服务器维护的数据记录（有关允许的dataIdentifier值，请参阅下方表格）。 dataRecord的格式和定义应特定于车辆制造商，并且如果服务器支持，则可以包括模拟输入和输出信号，数字输入和输出信号，内部数据和系统状态信息。在收到ReadScalingDataByIdentifier请求后，服务器应访问与指定的dataIdentifier参数关联的缩放信息，并在一个ReadScalingDataByIdentifie
汽车UDS：统一诊断服务
n320533510的博客
05-08 925
（03同上，7F表示否定响应，10是SID，22是NRC）不论是物理寻址还是功能寻址，对于Positive Response来说都没有影响，只需要关注sub-function中的Bit 7 suppressPosRspMsgIndicationBit是0还是1，如果为0即false，那么正常发送即可，如果是1即true，那么就不发送response。有些诊断服务可以支持不同的诊断子服务，sub-function就是用来定义这种子服务的，它将某一个服务细分为更为具体的服务，是一个字节的无符号整数。
0x24服务 uds_UDS（ISO14229)诊断协议（二）
weixin_35649143的博客
01-16 1380
在上一篇文章中主要阐述了一下应用层服务，这一篇小编打算就从应用层协议开始。应用层协议首先应用层协议应该发送的都是确定的消息，意思就是说来自于客户端的每一个服务请求都应该有一个或者是多个来自服务器的响应。协议数据单元A_PDU(application protocol data unit)是由A_SDU(application service data unit)和A_PCI(application...
计算机网络学习 - UDS协议
热门推荐
hezhanran的博客
06-11 1万+
文章目录一、背景二、概述三、诊断原理四、UDS诊断服务五、DTC 一、背景         汽车故障诊断是利用ECU监测控制系统各组成部分的工作情况，发现故障后自动启动故障记录和处理逻辑。汽车故障诊断模块不仅能够存储记忆汽车故障，还能够实时提供汽车各种运行参数。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。 二、概述     
【UDS】ISO14229之0x27服务
weixin_48498880的博客
08-21 6984
SecurityAccess”，安全访问由于（保密、排放或安全的原因），安全访问服务提供一种方法以方便访问受限制的数据或诊断服务。0x27服务还是比较有意思的，之前博主一直是手写代码的，现在的项目考虑到了功能安全，整车厂要求是Autosar架构的，因此现在开发都是使用DaVinCi软件开发生成代码，很强大的软件（德国佬的确很6）。下一章0x28控制通信服务见！
UDS诊断否定响应码（全网最全）
最新发布
PlutoZuo的博客
08-30 3644
UDS诊断否定响应码（全网最全）
UDS诊断NRC
sinat_29152229的博客
04-26 1145
一般程序性错误，在非易失性存储器中擦除或编程。错误的报文长度或无效的格式。ECU繁忙，不执行请求操作。暂时无法响应，需等待处理。超过允许的安全访问次数。当前会话不支持该子功能。当前会话不支持该服务。节气门/加速踏板过高。节气门/加速踏板过低。变速器不满足挂挡要求。
车载诊断NRC - UDS Negative Response Code
CDamogu
09-19 3897
>下表中列出了ISO14229-12013(E)中定义的否定响应码及其使用条件否定响应码的取值范围为0x00-0xFF，被分为三组NRC常用列表001112132224313335363770717273787E7F。
UDS诊断系列之三 ISO14229协议介绍（下）
Chenglim的博客
07-08 6923
上篇主要分享了一些基本概念和响应规则，此篇主要介绍否定响应码的判断逻辑。
NRC编码大全
01-28
NRC编码大全,总共65536个字符,其它的没了，凑下字数！
ISO 14229-4.zip_14229-4_ISO 14229_uds_uds 14229_uds诊断
07-15
诊断参考文档 汽车控制器 UDS 14229-4
ISO14229(2006).zip_Bootloader_UDS ISO14229_UDS14229协议_uds_汽车UDS
07-14
UDS 协议文件，可以供在CAN、Bootloader以及汽车电子的设计时参考
ISO14229_iso14229中文_iso14229_UDS协议中文
06-01
汽车CAN总线的UDS协议中文版可以深入学习
SS-ISO_14229-3_2012.zip_14229_14229-3_2012_ISO 14229_uds
09-24
道路车辆uds诊断，14229-3-2012标准
ISO 14229-3.zip_ISO 14229-3_ISO-14229_UDS ISO_uds_诊断uds
07-14
诊断参考文档 汽车控制器 UDS 14229-3
UDS服务-10、11、27、28、3E、85服务
yunhuhude的博客
10-06 1868
dddd
UDS服务-22、2E、23、2A服务
yunhuhude的博客
10-08 3661
它的好处是当要读取某个单元的诊断数据时，只要读对应的DID就可以，不必知道数据的具体地址。功能： 用户通过请求该服务，写指定dataIdentifler（数据标识符DID）所记录的数据值到NVM(非易失性存储，上下电不会被清除的空间，如：EEPROM，ROM,一般常用DataFlash仿EE，性价比高)中。10 09 中1代表第一帧，009为这个多帧中的数据长度，62=22+40，后面跟对应的DID及数据。安全访问拒绝，请求的DID是受保护的，且没有处于解锁状态。CNC 请求诊断会话控制的条件不满足。
二网络专题OSI七层模型、TCP/IP协议栈
weixin_63204687的博客
11-13 1246
计算机网络概述
iso-14229_14229_uds协议栈_uds-iso-14229_iso14229文档_iso+14229_源码.zip
06-25
### 回答1： iso-14229是一项用于汽车电子系统通信的协议，其全称为ISO14229 Unified Diagnostic Services（UDS）on Controller Area Network（CAN）。该协议旨在为车辆的诊断、维护和修复提供标准化的方法。ISO 14229定义了诊断服务和通信的标准化消息格式，包括诊断数据、错误码、故障清除等，以使不同车辆的系统实现得到统一和互操作性。 ISO14229 UDS协议栈是用于实现ISO 14229诊断协议的软件组件。该协议栈的实现可分为物理层和软件层两个部分，其中物理层是指使用CAN总线对车辆的执行单元进行通信，而软件层则是指实现ISO 14229标准的协议堆栈。该协议栈具有标准化、可重用和可配置的特点，可在不同的客户平台上使用。 ISO 14229的文档是对该协议的规范和说明，包括协议的基本架构、消息格式、错误码表、会话层和传输层的细节等。该文档是实现ISO 14229协议的必要依据，可用于开发UDS协议栈的开发人员和车辆诊断工程师。 源码.zip则是UDS协议栈的实现源代码，包括物理层和软件层代码。开发人员可根据该源码了解UDS协议栈的实现细节和技术实现，并根据需求进行二次开发。 综上所述，ISO-14229_14229_UDS协议栈_UDS-ISO-14229_ISO14229文档_ISO 14229_源码.zip等组件，是用于实现汽车电子系统诊断的标准化协议，可为车辆的维护和修复提供规范的方法。开发人员和车辆诊断工程师可根据这些组件进行UDS协议栈的开发和实现。 ### 回答2： ISO-14229是用于诊断汽车电子控制单元（ECU）的标准协议。该协议旨在提供一种标准化的方法，让技术人员可以使用相同的工具和流程诊断不同制造商的汽车。 14229 UDS是该标准的通信协议栈。UDS指协议栈中定义的通用诊断服务，该服务可用于访问ECU的内部数据和状态。ISO14229文档提供了UDS协议栈的详细规范，以及相关的数据格式和命令集合。 此外，文档和源代码可以帮助工程师实现符合ISO-14229标准的诊断工具或ECU，提高汽车诊断系统的质量和效率。源码.zip则是UDS协议栈的代码包。 总之，ISO-14229标准和UDS协议栈提供了一种标准化的、可靠的汽车诊断协议。它们有助于提高汽车技术人员的工作效率，同时减少汽车诊断工具和软件的开发成本。 ### 回答3： ISO-14229是一种用于汽车电子系统的通讯协议。它定义了诊断通信的规范和协议，允许车辆厂商和供应商使用这些规范和协议来开发和测试车载电子控制单元。其中，UDS协议栈是实现ISO-14229的关键技术之一，能够为客户端提供远程访问ECEs的可能性。 ISO-14229规定了接口：UDS（Unified Diagnostic Service），用于与电子控制单元（ECU）之间进行通讯。 UDS协议栈则实现了UDS协议的接口，可以自动进行诊断和测试，发生故障时还能产生错误报告。 相应地， ISO14229文档描述了在ISO14229-1文档中定义的UDS协议的特定应用，与ISO15765-2的特定要求相结合。 它还包括了EVITA Light文档中的安全方面。 源码.zip文件则包含了UDS协议栈的源代码，可以在开发与应用中使用，实现对汽车电子控制单元的简便对话操作。 总之，ISO-14229及其UDS协议栈实现了车载控制电子单元的标准化通讯，可简化车辆诊断和维护过程，提高效率和可靠性。同时，相应的规范、文档和源代码也为相关人员提供了方便和支持。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值