【ISO14229_UDS_0x2F服务详解】

最新推荐文章于 2023-12-01 23:26:52 发布
最新推荐文章于 2023-12-01 23:26:52 发布
阅读量847 收藏 4
点赞数 1
分类专栏： ISO14229-UDS诊断服务介绍 文章标签： mcu
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43722921/article/details/132012695
版权

目录

1、0x2F服务（InputOutputControlByIdentifier，根据标识符控制输入输出服务）

  Service description：
  0x2F服务（InputOutputControlByIdentifier，根据标识符控制输入输出服务）被客户端用于替换输入信号/内部服务函数的值，或者是强制控制电子系统执行器(输出)的值。通常，此服务用于相对简单的(例如，静态)输入替换/输出控制，而0x31(routineControl，例程控制服务)则用于需要更复杂的输入替换/输出控制。
  客户端请求消息包含一个dataIdentifier(DID)，用于引用服务端的输入信号、内部函数或输出信号(执行器)(在设备控制访问的情况下，它可能引用一组信号)。controlloptionrecord参数应包括服务端输入信号、内部函数和输出信号所需的所有信息。如果要控制的数据标识符(dataIdentifier(DID))引用多个参数(即数据标识符被打包或位映射)，汽车制造商可能要求请求报文包含controlEnableMask。如果汽车制造商选择支持EnableMask概念，那么对于该服务的所有类型的InputOutputControlByIdentifier请求，controlEnableMask参数都是必需的。如果inputOutputControlByIdentifier请求的dataIdentifier(DID)，其引用的是观测的输出或反馈值，则服务端应替换给控制策略中正确的目标值，以便服务端的控制策略能够正常到达目标状态。
  如果请求的控制成功启动或达到了所需状态，服务端将发送一个肯定应答报文。即使数据标识符(dataIdentifier)目前不在测试者的控制下，服务端也应该向带有returnControlToECU的inputOutputControlParameter的请求报文发送一个肯定应答报文。此外，当接收到returnControlToECU请求时，服务端应该始终为客户端提供将controlMask(如果支持的话)的位全部设置为’1’的功能，以便将数据标识符的位映射的控制权完全返回给ECU。请求报文controlOptionRecord参数中的inputOutputControlParameter后面的controlState字节的格式和长度必须与被请求的dataIdentifier的dataRecord的长度和格式完全匹配。这样就可以确保使用0x22服务(ReadDatabyIdentifier)读取相同DID时，可以获取实际的输出或输入状态。
  当使用inputOutputControlByIdentifier服务执行输入替换或输出控制时，在ECU接受请求时有两个基本。第一种是将dataIdentifier中参数引用的数据对象与所有上层控制策略断开连接，否则这些策略将更新数据对象值。第二种是将一个值替换到数据对象中，这些数据对象将用于控制策略的所有下游活动。例如，测试人员要求直接强制打开前照灯，需要防止前照灯的开关位置影响到了前照灯的输出，并将期望的“打开”状态替换到数据对象中，而这些数据对象会被函数调用，进而会最终决定前照灯的目标输出。
  该服务允许在单个请求报文中控制单个数据标识符(dataIdentifier)及相应的参数。这样，服务端将使用单个应答报文进行响应，包括了请求报文的dataIdentifier和controlStatus信息。

2、请求报文格式

2.1 请求报文定义

  下表定义了请求报文的格式：

字节序号参数值约定字节值
#1InputOutputControlByIdentifier Request SIDM0x2F

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

#4
.
.
#4+(m-1)		controlOptionRecord [] = [
           inputOutputControlParameter
           controlState#1
           .
           .
           controlState#m ]
M1
C1
.
.
C1
0x00 - 0xFF
0x00 - 0xFF
.
.
0x00 - 0xFF

#4+m
.
.
#4+m+(r-1)		controlOptionRecord [] = [
           controlMask#1
           .
           .
           controlState#r ]
C2
.
.
C2
0x00 - 0xFF
.
.
0x00 - 0xFF

  M1：inputOutputControlParameter参数的详细定义见下表；
  C1：该参数的存在取决于dataIdentifier和inputOutputControlParameter；
  C2：如果车辆制造商支持controlEnableMask概念，则如果dataIdentifier包含多个参数(参见controlEnableMaskRecord定义)，则应包括此参数。
  inputOutputControlParameter参数的详细定义见下表

Byte Value描述约定
0x00returnControlToECU
该值应向服务端表明，客户端不再控制由dataIdentifier引用的输入信号、内部参数和输出信号
请求中controlState字节的详细信息:0字节
肯定应答中controlState字节的详细信息:等于dataIdentifier的dataRecord的大小和格式		U
0x01resetToDefault
该值将向服务端表明，它被请求将dataIdentifier引用的输入信号、内部参数和输出信号重置为其默认状态
请求中controlState字节的详细信息:0字节
肯定应答中controlState字节的详细信息:等于dataIdentifier的dataRecord的大小和格式		U
0x02freezeCurrentState
该值将向服务端表明，请求冻结由dataIdentifier引用的输入信号、内部参数和/或输出信号的当前状态
请求中controlState字节的详细信息:0字节
肯定应答中controlState字节的详细信息:等于dataIdentifier的dataRecord的大小和格式		U
0x03shortTermAdjustment
此值应向服务端表明，请求将RAM中的数据标识符引用的输入信号、内部参数和受控输出信号调整为控制参数中包含的值(例如，将怠速空气控制阀设置为特定步长，将阀的脉宽设置为特定值/占空比)
请求中controlState字节的详细信息:等于dataIdentifier的dataRecord的大小和格式
肯定应答中controlState字节的详细信息:等于dataIdentifier的dataRecord的大小和格式		U
0x04 - 0xFFISOSAEReserved
ISO保留		M
        

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

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

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

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

定义
dataIdentifier
该参数表示了服务端的局部输入信号、内部参数和输出信号。
controlOptionRecord
controlloptionrecord由一个或多个字节组成(inputOutputControlParameter和controlState#1到controlState#m)。controlloptionrecord参数细节应按照inputOutputControlParameter参数的详细规范来实现。
controlEnableMaskRecord
controlEnableMaskRecord由一个或多个字节(controlMask#1到controlMask#r)组成。只有当控制的数据标识符包含多个参数(即，数据标识符是位映射的或按定义打包)时，才支持controlEnableMaskRecord。在controlEnableMaskRecord中应该有一个位对应于dataIdentifier中定义的每个单独的参数。当要控制的数据标识符(DID)仅由单个参数组成时，不支持controlEnableMaskRecord。
注意 数据标识符中的每个参数可以是任意位数
controlEnableMaskRecord中的每个位的值，将会决定dataIdentifier中相应的参数是否会受到请求的影响。controlEnableMaskRecord中的“0”表示对应的参数不受此请求的影响，“1”表示对应的参数受此请求的影响。ControlMask#1的最高有效位应对应ControlState中的第一个参数，从ControlState#1的最高有效位开始，ControlMask#1的第二个最高有效位应对应于ControlState中的第二个参数，并以这种方式继续利用尽可能多的ControlMask字节去屏蔽所有的参数。例如，ControlMask#2的最低有效位对应于controlState中的第16个参数。对于位映射的数据标识符(DID)，不支持的位也应该在controlEnableMaskRecord中有相应的位，以便controlEnableMaskRecord中每个参数的掩码位的位置应该与相应参数在controlState中的位置完全匹配。

3、肯定应答报文

3.1 肯定应答报文格式定义

字节序号参数值约定字节值
#1InputOutputControlByIdentifier Response SIDM0x6F

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

#2
#3
.
.
#5+(m-1)		controlStatusRecord [] = [
        inputOutputControlParameter
        controlState#1
        .
        .
        controlState#m ]
M
C1
.
.
C1
0x00 - 0xFF
0x00 - 0xFF
.
.
0x00 - 0xFF

  C1：该参数的存在取决于dataIdentifier和inputOutputControlParameter。

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

  该服务肯定应答报文中使用到的数据参数的定义见下表：

定义
dataIdentifier
该参数为请求报文中的数据标识符(dataIdentifier)。
controlStatusRecord
controlState参数由多个字节组成（InputOutputControlParameter，从controlState#1到controlState#m），其包括了反馈数据。

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

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

NRC描述
0x13incorrectMessageLengthOrInvalidFormat
请求报文长度不正确时，会发送该NRC
0x22conditionsNotCorrect
当根据标识符控制输入输出服务请求的标准不满足时，会发送该NRC
0x31requestOutOfRange
以上情况会会发送该NRC：
— 设备不支持请求的数据标识符的值；
— inputOuptputControlParameter包含的值是无效的；
— controlOptionRecord记录的一个或者多个controlState的值是无效的；
— 在ControlEnableMaskRecord中使能控制位的结合不被设备所支持；
0x33securityAccessDenied
客户端发送了一个请求，其带有有效安全的数据标识符，并且服务端的安全特征是激活的。

  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)否定应答码(NRC)具体处理过程。
在这里插入图片描述

5、0x2F服务（InputOutputControlByIdentifier，根据标识符控制输入输出服务）案例说明

  假设：以下案例展示了根据标识符控制输入输出服务被HVAC控制模块所使用，并且假设与单个服务端进行物理通讯。
  Example #1 - ”Air Inlet Door Position” shortTermAdjustment
  数据标识符(0x9B00)，表示"进气门位置"。
  转换：进气门位置 [%] = decimal(Hex) * 1 [%]；
  Step #1: ReadDataByIdentifier
  该案例使用0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)来获取进气门位置的当前状态。
  0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1ReadDataByIdentifier Request SID0x22
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00

  0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1ReadDataByIdentifier Response SID0x62
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4dataRecord [ data#1 ] = 10%0x0A

  Step #2: shortTermAdjustment
  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Request SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4
#5		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = 60%		0x03
0x3C

  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4
#5		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = 12%		0x03
0x0C

  注意：客户端已经发送了如上所述的inputOutputControlByIdentifier服务的请求报文。服务端已经发送了一个即时的肯定应答报文，其中包括controlState参数“进气门位置”，其值为12%。进气门需要一定的时间才能移动到所要求的60%的值。
  Step #3: ReadDataByIdentifier
  该案例使用0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)来获取进气门位置的当前状态。
  0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1ReadDataByIdentifier Request SID0x22
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00

  0x22服务(ReadDataByIdentifier，根据标识符读取数据服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1ReadDataByIdentifier Response SID0x62
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4dataRecord [ data#1 ] = 60%0x3C

  注意：当inputOutputControlByIdentifier服务处于活动状态时，客户端已经发送了上面指定的readDataByIdentifier请求报文。服务端控制策略需要有限的时间才能最终达到期望的值。上面的示例反映了服务端最终达到期望的目标值的时间。
  Step #4: returnControlToECU
  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Request SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4controlOptionRecord [ inputOutputControlParameter ] = returnControlToECU0x00

  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4controlOptionRecord [ inputOutputControlParameter ] = returnControlToECU0x00
#5controlStatusRecord [ controlState#1 ] = 58%0x3A

  Step #5: freezeCurrentState
  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Request SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4controlOptionRecord [ inputOutputControlParameter ] = freezeCurrentState0x02

  0x2F服务(InputOutputControlByIdentifier，根据标识符控制输入输出服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x9B
dataIdentifier [ byte#2 ] = 0x00 (“Air Inlet Door Position”)		0x9B
0x00
#4controlOptionRecord [ inputOutputControlParameter ] = freezeCurrentState0x02
#5controlStatusRecord [ controlState#1 ] = 50%0x32

  Example #2 – EGR and IAC shortTermAdjustment
  Assumptions
  该案例使用了打包的数据标识符0x0155，来展示单个参数或者多个参数在单条请求报文中的控制。
  本小节指定了shortTermAdjustment函数的测试条件和示例dataIdentifier 0x0155的相关消息流。该数据标识符支持以下表中5种单个的数据。

Data ByteNumberSizeData Record Contents
#1 (all bits)#18 bitsdataRecord [ data#1 ] = IAC Pintle Position (n = counts)
#2 - #3 (all bits)#216 bitsdataRecord [ data#2-#3 ] = RPM (0 = 0 U/min, 65 535 = 65 535 U/min)
#4 (bits 7-4)#34 bitsdataRecord [ data#4 (bits 7-4) ] = Pedal Position A: Linear Scaling, 0 = 0%, 15 = 120 %
#4 (bits 3-0)#44 bitsdataRecord [ data#4 (bits 3-0) ] = Pedal Position B: Linear Scaling, 0 = 0%, 15 = 120 %
#5 (all bits)#58 bitsdataRecord [ data#5 ] = EGR Duty Cycle: Linear Scaling, 0 counts = 0%, 255 counts = 100 %

  DataIdentifier 0x0155 按照定义封装，由五个基本参数组成。出于单独控制的目的，它们中的每一个元素参数可以通过ControlEnableMaskRecord中的单个位进行选择。如果给定的dataIdentifier不具有打包或位映射的定义，则请求报文中不存在ControlEnableMaskRecord。ControlMask#1的最高有效位总是需要对应于从ControlState#1的最高有效位开始的dataIdentifier中的第一个参数。下表展示了这一点。

Bit PositionControlEnableMask#1 – Bit Meaning (1 = affected, 0 = not affected)
7 (Most Significant Bit)#1
6决定参数#2(RPM)是否会受到请求的影响；
5决定参数#3(Pedal Position A)是否会受到请求的影响；
4决定参数#4(Pedal Position B)是否会受到请求的影响；
3决定参数#5(EGR Duty Cycle)是否会受到请求的影响；
2无参数因此无影响
1无参数因此无影响
0 (Least Significant Bit)无参数因此无影响

  Case #1: Control IAC Pintle Position only
  下表定义了InputOutputControlByIdentifier请求报文，example #2 – Case #1，由客户端发往服务端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(7 counts)
controlOptionRecord [ controlState#2 ] = RPM (XX)
controlOptionRecord [ controlState#3 ] = RPM (XX)
controlOptionRecord [ controlState#4 ] = Pedal Position A (Y) and B (Z)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (XX)		0x03
0x07
0xXX
0xXX
0xYZ
0xXX
#10controlEnableMask [ controlMask#1 ] = Control IAC Pintle Position ONLY0x80

  注意：在controlState#2 - #5中传输的RPM、踏板位置A、踏板位置B和EGR占空比的值是不相关的，因为controlMask#1参数指定只有dataIdentifier中的第一个参数将受到请求的影响。

  下表定义了InputOutputControlByIdentifier肯定应答报文，example #2 – Case #1，由服务端发往客户端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(7 counts)
controlOptionRecord [ controlState#2 ] = RPM (750 U/min)
controlOptionRecord [ controlState#3 ] = RPM
controlOptionRecord [ controlState#4 ] = Pedal Position A (8%) and B (16%)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (35%)		0x03
0x07
0x02
0xEE
0x12
0x59

  注意：在controlState#1 - controlState#5中传输的所有参数的值应反映系统的当前状态。

  Case #2: Control RPM Only
  下表定义了InputOutputControlByIdentifier请求报文，example #2 – Case #2，由客户端发往服务端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(XX counts)
controlOptionRecord [ controlState#2 ] = RPM (0x03E8 = 1000 U/min)
controlOptionRecord [ controlState#3 ] = RPM
controlOptionRecord [ controlState#4 ] = Pedal Position A (Y) and B (Z)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (XX)		0x03
0xXX
0x03
0xE8
0xYZ
0xXX
#10controlEnableMask [ controlMask#1 ] = Control RPM ONLY0x40

  注意：在controlstate# 1和controlstate# 4 - #5中，为IAC销位、踏板位置A、踏板位置B和EGR占空比传输的值是不相关的，因为controlMask#1参数指定只有dataIdentifier中的第二个参数将受到请求的影响。

  下表定义了InputOutputControlByIdentifier肯定应答报文，example #2 – Case #2，由服务端发往客户端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(9 counts)
controlOptionRecord [ controlState#2 ] = RPM (950 U/min)
controlOptionRecord [ controlState#3 ] = RPM
controlOptionRecord [ controlState#4 ] = Pedal Position A (8%) and B (16%)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (35%)		0x03
0x09
0x03
0xB6
0x12
0x59

  注意：在controlState#1 - controlState#5中传输的所有参数的值应反映系统的当前状态。

  Case #3: Control both Pedal Position A and EGR Duty Cycle
  下表定义了InputOutputControlByIdentifier请求报文，example #2 – Case #3，由客户端发往服务端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(XX)
controlOptionRecord [ controlState#2 ] = RPM (XX)
controlOptionRecord [ controlState#3 ] = RPM(XX)
controlOptionRecord [ controlState#4 ] = Pedal Position A (0x3 = 24 %) and B (Z)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (45 %)		0x03
0xXX
0xXX
0xXX
0x3Z
0x72
#10controlEnableMask [ controlMask#1 ] = Control Pedal Position A and EGR0x28

  注意：在controlState#1 - #3和controlState#4(位3-0)中传输的IAC销的位置、RPM和踏板位置B的值是不相关的，因为controlMask#1参数指定只有dataIdentifier中的第三和第五个参数会受到请求的影响。

  下表定义了InputOutputControlByIdentifier肯定应答报文，example #2 – Case #3，由服务端发往客户端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = shortTermAdjustment
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(7 counts)
controlOptionRecord [ controlState#2 ] = RPM (850 U/min)
controlOptionRecord [ controlState#3 ] = RPM
controlOptionRecord [ controlState#4 ] = Pedal Position A (24%) and Pedal Position B (16%)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (41%)		0x03
0x07
0x03
0x52
0x32
0x69

  注意：在controlState#1 - controlState#5中传输的所有参数的值应反映系统的当前状态。

  Case #4: Return control of all parameters to the ECU
  下表定义了InputOutputControlByIdentifier请求报文，example #2 – Case #4，由客户端发往服务端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x2F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4controlOptionRecord [ inputOutputControlParameter ] = returnControlToECU0x00
#10controlEnableMask [ controlMask#1 ] = All elemental parameters0xFF

  下表定义了InputOutputControlByIdentifier肯定应答报文，example #2 – Case #4，由服务端发往客户端。

字节顺序Description字节值
#1InputOutputControlByIdentifier Response SID0x6F
#2
#3		dataIdentifier [ byte#1 ] = 0x01
dataIdentifier [ byte#2 ] = 0x55 (IAC / RPM / PPA / PPB / EGR)		0x01
0x55
#4
#5
#6
#7
#8
#9		controlOptionRecord [ inputOutputControlParameter ] = returnControlToECU
controlOptionRecord [ controlState#1 ] = IAC Pintle Position(9 counts)
controlOptionRecord [ controlState#2 ] = RPM (850 U/min)
controlOptionRecord [ controlState#3 ] = RPM
controlOptionRecord [ controlState#4 ] = Pedal Position A (8%) and Pedal Position B (16%)
controlOptionRecord [ controlState#5 ] = EGR Duty Cycle (35%)		0x00
0x09
0x03
0x52
0x12
0x59

  注意：在controlState#1 - controlState#5中传输的所有参数的值应反映系统的当前状态。

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

三星小卤蛋
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
UDS详解（九）——2F和31服务
manjixingkong1234的专栏
09-13 914
介绍UDS服务的2F和31服务
ISO 14229-3.zip_ISO 14229-3_ISO-14229_UDS ISO_uds_诊断uds
07-14
诊断参考文档 汽车控制器 UDS 14229-3
【UDS】ISO14229之0x31服务
weixin_48498880的博客
11-05 6237
RoutineControl”，例程控制该服务执行指定的步骤操作并获取相关结果，相比0x2F服务，具有较大的灵活性，可用于较为复杂类型的控制。一般应用包括清除内存（多数用在更新ECU软件），重置或学习自适应数据，运行自检，方向盘角度零点标定等。0x31服务在实际运用中要比0x2F复杂些，但那又怎样，通过本章讲解是否对该服务熟悉那么一勾勾呢？下一章 DTC控制 0x85服务见！->返回总目录
UDS诊断系列介绍14-2F服务
initiallizer的博客
01-22 4559
2F服务，即IO控制服务，其全称为 InputOutputControlByIdentifier service，可以通过诊断仪/上位机通过相关诊断命令来替代输入信号的值、或ECU的输出命令来实现控制输出的目的。
UDS诊断服务简单介绍
最新发布
weixin_57038822的博客
12-01 4112
UDS诊断服务简单介绍
ISO14229(2006).zip_Bootloader_UDS ISO14229_UDS14229协议_uds_汽车UDS
07-14
UDS 协议文件，可以供在CAN、Bootloader以及汽车电子的设计时参考
ISO14229_iso14229中文_iso14229_UDS协议中文
06-01
汽车CAN总线的UDS协议中文版可以深入学习
UDS服务基础篇之2F
wto9109的博客
06-16 2万+
前言 在汽车ECU诊断服务开发的过程中，有很多常见的诊断服务，比如10, 11, 22, 2E等，但是对于2F服务则会显得有些陌生，因为这类诊断服务主要在车身域比较常见，比如车窗控制，传感器开关、执行器控制等。除此以外，在其他车身域也有不同程度的使用，只不过相对较少。 接下来，让我们带着下列思考一起来了解一下这个较为神秘的2F服务吧！ 2F服务是做什么的呢？ 它的诊断服务请求及回复是怎样一种方式？ 与31服务Routine Control相比，又有什么区别呢？ 这篇，我们来一起探索并回答这些
【UDS】ISO14229之0x2F服务
weixin_48498880的博客
10-29 4431
InputOutputControlByIdentifier”，根据标识符控制输入输出根据标识符控制输入输出服务用于替换输入信号的值、电控单元内部参数或控制电子系统的输出值。0x2F服务还是比较容易理解的，下一章0x31 例行控制服务见！->返回总目录
UDS诊断系列之十一 输入输出控制（2F）服务 上
Chenglim的博客
08-24 4221
应粉丝要求，先来更新输入输出控制（2F）服务的内容。输入输出控制（2F）服务顾名思义就是对输入和输出内容进行控制，这里的输入和输出一般指的是控制器的输入和输出引脚或者设备，例如仪表的各种灯就是仪表控制器的输出，而车内的各种灯光开关则是车身控制器的输入。............
汽车诊断之UDS入门-0x2F服务
weixin_44842720的博客
11-30 1560
0x2F InputOutControlByIdentifier 服务
ISO 14229-4.zip_14229-4_ISO 14229_uds_uds 14229_uds诊断
07-15
诊断参考文档 汽车控制器 UDS 14229-4
SS-ISO_14229-3_2012.zip_14229_14229-3_2012_ISO 14229_uds
09-24
道路车辆uds诊断，14229-3-2012标准
统一诊断服务 (Unified diagnostic services ， UDS) （一）~（七）
usstmiracle的博客
10-22 7164
UDS由ISO-14229系列标准定义，ISO 14229-1 定义了诊断服务，不涉及网络及实现，只有应用层的内容。而ISO 14229-3则定义了UDS在CAN总线上的实现。 诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。 最近关于UDS的一系列专栏文章只关注应用层的诊断服务，忽略下层的通信机制。 Diagnostic request的格式：
【AutoSar_UDS服务】0x2F服务_IO控制
Gagaaaaaa的博客
08-28 1046
uds 0x2F服务详解
【UDS统一诊断服务】四、诊断典型服务（6）— 输入输出控制单元（0x2F）
星Yeah 的博客
03-28 1347
四、诊断典型服务（6）— 输入输出控制单元（0x2F） 我自己汇总了一张表格，免积分下载，对应学习，效果更好！ 链接：https://download.csdn.net/download/sinat_40003796/85031818 各功能单元诊断服务： 诊断和通信管理功能单元 数据传输功能单元 读故障信息功能单元（存储数据传输功能单元） 在线编程功能单元（上传下载功能单元） 功能/元件测试功能单元（例行程序功能单元） 输入输出控制单元（0x2F） 本文主要讲解“输入输出控制单元（0x2F）”，其余的
【车载开发系列】UDS诊断---输入输出控制（$0x2F）
千月星跡
12-10 1494
【车载开发系列】UDS诊断---输入输出控制（$0x2F）
UDS（统一诊断服务）的理解——0x19服务
热门推荐
qq_38301199的博客
03-24 4万+
简述UDS、0x19服务 UDS可以简单理解为一套完整的通讯协议框架，其目的在于规范各种行车电脑和ECU之间的通讯。ISO 15762-2规定了UDS的网络层，ISO14229规定UDS的应用层。 UDS可以在不同的汽车总线上实现，但本文重点讨论UDS on CAN的诊断协议。 UDS包含一系列服务，每种服务都有自己独立的ID，即SID（Service Identifier），0x19服务其实是读取DTC信息的服务，其SID为0x19。 网络层 经典的CAN数据链路层最大能够支持单帧8个字节的数据传输
STM32H7高性能MCU系列 STM32H7A3NGH6 32-bit RISC内核
Mandy_mjd的博客
11-05 2375
STM32H7A3NGH6是基于高性能Arm Cortex-M7的32位MCU，工作频率高达400MHz。
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、付费专栏及课程。

余额充值