【ISO14229_UDS_0x86服务详解】

已于 2023-06-23 11:47:30 修改
阅读量2.3k 收藏 14
点赞数 4
分类专栏： ISO14229-UDS诊断服务介绍 文章标签： mcu
于 2023-05-20 15:04:37 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43722921/article/details/130713175
版权

目录

1、0x86服务（事件响应服务）

  Service description：
  0x86服务（ResponseOnEvent，事件响应服务）请求服务端开始或停止传输具体事件的响应。
  如果服务端中指定事件发生了，该服务ResponseOnEvent会自动执行一个诊断服务。客户端来指定事件(包括可选择的事件参数)以及要执行的服务(包括服务参数)。有关客户端和服务端之间行为的简要概述，请参见下图：
在这里插入图片描述
  注意：上图假设在服务端下电之前事件窗口计时器(event window timer)配置成超时，因此最后ResponseOnEvent的肯定应答报文在事件超时窗口的最后才会显示。
  服务端应该在接收请求报文时，就去评估事件响应服务(ResponseOnEvent)的子函数和数据内容，子函数和参数包含如下：
—— eventType，事件类型;
—— eventWindowTime，事件窗口时间；
—— eventTypeRecord (eventTypeParameter #1-#m)，事件类型记录(事件类型参数 #1-#m).
  如果事件响应服务(ResponseOnEvent)请求报文中的数据无效，则发送否定应答码0x31。serviceToRespondToRecord不属于该评估的一部分。当指定事件发生时，将评估serviceToRespondToRecord参数，这将触发serviceToRespondToRecord中所包含服务的执行。在事件发生时，应执行serviceToRespondToRecord(诊断服务请求报文)。如果条件不正确，则应发送带有合理的否定应答码的否定应答报文。多个事件应按其发生的顺序发出信号。
  应用以下实施规则：
  a) ResponseOnEvent服务可以在任何会话中设置和激活，包括defaultSession。保持ResponseOnEvent服务激活并不一定需要TestPresent(测试工具保持连接)服务。
  b) 如果在诊断服务运行过程中发生了指定的事件，这意味着正在接收请求报文或正在执行请求，或者正在传输应答报文(包括响应码为0x78的否定应答报文)(如果suppressposrspmsglnindicationbit = FALSE)，则serviceToRespondToRecord中包含的请求报文的执行应该延迟。直到正在进行的诊断服务完成。
  注意：在某些情况下，由于ServiceToRespondTo的延迟，ServiceToRespondTo记录中包含的数据，可能与导致事件的数据值不对应。
  c) 如果一个事件发生时多个事件也发生了，这种多事件处理(如忽略所有除了第一个或者最后一个或事件存储之外的所有事件)应该由车辆制造厂商去指定。
  d) 当事件逻辑满足并且事件在事件时间窗口内产生，服务端应该执行serviceToRespondToRecord所包含的服务。
  e) 一旦ResponseOnEvent服务被“start”初始化，服务端将会响应已设置事件逻辑的客户端，并启动ROE事件，直到事件窗口时间超时。
  f) 切换到任何非默认会话的诊断会话控制的请求将会停止掉ResponseOnEvent服务，无论是否激活了与当前会话不同的非默认会话或相同的非默认会话。在返回到DefaultSession时，之前在默认会话中激活的所有ResponseOnEvent服务都将被重新激活。
  g) 带有不同需求(不同的EventTypes, serviceToRespondToRecords，…)的多个ResponseOnEvent服务可能会并发地运行，以启动和停止诊断服务。启动和停止子函数应该始终控制所有初始化的ResponseOnEvent服务。
  h) 如果设置了事件响应服务，如下应该应用：
    1)如果eventType子函数参数的第6位设置为0(不存储事件)，则事件将在服务端下电时终止。服务端在复位或上电后，将不再继续进行ResponseOnEvent诊断服务(即ResponseOnEvent服务终止)。
    2)如果eventType子函数参数的第6位设置为1(存储事件)，则在服务单上电一个周期后，将根据ResponseOnEvent-set恢复发送serviceToRespondTo-responses。因此，StoreEvent只允许与infinite eventWindowTime去结合使用。
  i) “suppressPosResponseMessageIndicattionBit” = “yes”，被客户端用于eventType = stopResponseOnEvent, startResponseOnEvent or clearResponseOnEvent时去使用，当指定的事件被探测时，服务端总能够对事件触发型的响应给出应答。
  j) 只有当有限的窗口时间被设置和有限的窗口时间已经过去时，服务端应该返回一个ResponseOnEvent “final”应答，来表明ResponseOnEvent (0x86)服务。在有限的窗口时间过去之前，如果ROE(ResponseOnEvent)以任何方式停止(例如:"stopResponseOnEvent"子函数或会话切换)，那么“final”应答将不被发送。
  k) 为了避免干扰正常的诊断操作，建议将ResponseOnEvent服务实现为只应用于瞬态的事件和条件。服务器应该在每次事件发生时返回一个响应。对于持续一段时间事件发生的情况，响应服务应在事件初始发生时只执行一次。如果eventType被定义为serviceToRespondTo，应答可以以高频率发生，同时也必须采取适当的措施来防止back to back这种的serviceToRespondTo 应答。serviceToRespondTo-responses之间的最小间隔时间可以是eventTypeRecord(车辆制造商定义)的一部分。
  建议仅使用下表中列出的服务，以便在发生指定事件时能够执行服务。(serviceToRespondToRecord SID)。

推荐服务(ServiceToRespondTo)Request SIDReponse SID
ReadDataByIdentifier0x220x62
ReadDTCInformation0x190x59
RoutineControl0x310x71
InputOutputControlByIdentifier0x2F0x6F

  出于运行原因(如，避免错过serviceToRespondToRecord请求服务标识符(SID)的执行)，建议遵循以下建议:
——可能会包含测量数据的DID（如避免读取常量“标定”标签事件逻辑(event logic)的定义）；
——serviceToRespondToRecord 肯定应答的大小可能会受限，其尺寸大小取决于车辆制造商定义的值；

2、请求报文格式

2.1 请求报文定义

字节序号参数值约定字节值
#1ResponseOnEvent Request SIDM0x86
#2sub-function = [ eventType ]M0x00 - 0xFF
#3eventWindowTimeM0x00 - 0xFF
#4
.
.
#(m-1)+4		eventTypeRecord[] = [
               eventTypeParameter 1
               .
               .
               eventTypeParameter m ]		C1
0x00 – 0xFF
.
.
0x00 – 0xFF

#n-(r-1)-1
#n-(r-1)
.
.
#n		serviceToRespondToRecord[] = [
               serviceId
               serviceParameter 1
               .
               .
               serviceParameter r ] ]
C2
C3
.
.
C3
0x00 – 0xFF
0x00 – 0xFF
.
.
0x00 – 0xFF

  C1: 如果eventType需要额外的参数，来应答指定的事件，则出现该参数；
  C2: 如果子函数参数(eventType)不等于reportActivatedEvents，stopResponseOnEvent, startResponseOnEvent, ClearResponseOnEvent，则该参数强制出现；
  C3: 如果服务请求需要附加服务参数去应答服务时，则出现该参数；

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

  ResponseOnEvent请求报文中使用子函数参数(eventType)来指定要在服务端中需要配置的事件，并去控制ResponseOnEvent的设置。每个子函数参数值在下表中给出，同时也指定了适用eventTypeRecord的长度(suppressPosRspMsgIndicationBit (bit 7)在下表中未显示)。eventType子函数参数的第6位用于表明事件是否应存储在服务端的非易失性存储器中，并在服务器下次上电时重新激活，或者是否应在服务器下电时终止(storageState参数)。

Bit6 值描述约定
0x00doNotStoreEvent
该值表示当服务器掉电时事件将终止，并且服务器在复位或上电后(即ResponseOnEvent服务终止)将不再继续ResponseOnEvent诊断服务		M
0x01storeEvent
该值表示：
  1) 在默认会话中，一旦ROE启动或停止请求，事件应该根据ROE Service是否被重启，来决定是否重启或停止发送serviceToRespondTo-responses
  2) 对于任何ROE设置事件逻辑的请求，所请求的事件逻辑应被持久存储，直到事件逻辑被显式清除(通过clearResponseOnEvent)，或者事件逻辑被相同类别的新ROE设置事件逻辑请求所覆盖。		U
          

  请求报文中子函数参数(eventType)具体含义的定义：

Bit5-0值描述约定类型
0x00stopResponseOnEvent
该值用来停止发送事件的响应消息，被设置的事件逻辑不能被清除，但可以用startResponseOnEvent子函数参数去重启；
Length of eventTypeRecord: 0 字节		Ucontrol
0x01onDTCStatusChange
该值表示将该事件标记为检测一个新DTC，其与指定事件的DTCStatusMask相匹配；
Length of eventTypeRecord: 1 字节
实现提示：服务端中resident DTC的计数算法在一定周期(如1秒)内，计算出满足客户端DTCStatusMask定义的故障码数量。如果计数与上一个执行过程中的计数不同，客户端应该产生引起serviceToRespondTo执行的事件；
eventType需要在请求报文中(eventTypeParameter#1)指定DTCStatusMask；		Usetup
0x02onTimerInterrupt
该值将事件标记为计时器的中断，但计时器及其值并非是事件响应服务的一部分；
该eventType在请求报文(eventTypeRecord)中需要更多细节的具体定义；
Length of eventTypeRecord: 1 byte；		Usetup
0x03onChangeOfDataIdentifier
该值将事件标记为由数据标识符定义的内部数据记录。该数据值由汽车制造厂商定义。
该eventType在请求报文(eventTypeRecord)中需要指定更多的细节；
Length of eventTypeRecord: 2 byte；		Usetup
0x04reportActivatedEvents
该值被用来表示在肯定响应中采用事件响应服务(并且当前激活的)，来汇报所有在服务端激活的事件，
Length of eventTypeRecord: 0 bytes		Ucontrol
0x05startResponseOnEvent
该值用于表示服务器要去激活已设置的事件逻辑(包括事件窗口计时器)，并开始发送对事件的响应。
Length of eventTypeRecord: 0 byte.		Mcontrol
0x06clearResponseOnEvent
该值用于清除在服务端设置的事件逻辑(这让服务端停止发送对事件的响应)
Length of eventTypeRecord: 0 byte		Ucontrol
0x07onComparisonOfValues
修改由数据标识符(DID)标识的数据值，该DID标记了一个数据值事件。有了这一子功能，当在一个已定义的测量值比较中收集到指定结果发生时，用户有能力去定义一个事件。在数据记录中所包含的指定测量值，这条数据记录会分配给定义好的数据标识符(DID)，拿指定测量值与给定值进行比较。指定的运算符会定义了二者比较的类型。如果比较结果为正，则发生该事件;
Length of eventTypeRecord: 10 bytes		Usetup
0x08 - 0x1FISOSAEReserved
ISO保留		M-
0x20 - 0x2FVehicleManufacturerSpecific
汽车制造厂商预留		Usetup
0x30 - 0x3ESystemSupplierSpecific
供应商预留值		Usetup
0x3FISOSAEReserved
ISO保留		M-
              

请求报文中对子函数参数onTimerInterrup的具体细节说明：
  使用子函数onTimerInterrup，在定时器可配置的时间中，服务端允许触发型的事件。
  eventTypeRecord使用了以下定时器计划来定义计时器的值：
  ——Slow rate,慢速；
  ——Medium rate，中速；
  ——Fast rate，快速；
  定义每个计时器计划选项相关的时间速率，是整车制造厂商的任务。具体见下表：

eventTypeRecordEvent will be generatedTimer type
0x01每次慢速计时器值失效时慢速计时器，如计时器每过去1秒
0x02每次中速计时器值失效时中速计时器，如计时器每过去300ms
0x03每次快速计时器值失效时快速计时器，如计时器每过去25ms

请求报文中对子函数参数onChangeOfDataIdentifier的具体细节说明：
  使用子函数onChangeOfDataIdentifier，服务端允许在定长的时间内去调查测量结果并且比较内容，因此服务端可能会丢失一些变化并且触发比预期更少的时间，这是可以接受的。
  eventTypeRecord设置了两个字节大小的DID，来监测任何的变化。
请求报文中对子函数参数onComparisonOfValues的具体细节说明：
  下表定义了子函数参数为onComparisonOfValues的详细定义，如果serviceToRespondToRecord指定了在读取DID之间作比较。

字节序号参数名称字节值Comment具体细节
#1ServiceID0x86Request SID—
#2eventType0x07sub-function onComparisonOfValues—
#3eventWindowTime0x02InfiniteTimeWindow specification—
#4eventTypeRecord byte10x01DataIdentifier (DID) high byte—
#5eventTypeRecord byte20x04DataIdentifier (DID) low byte—
#6eventTypeRecord byte30x01比较逻辑，见下表eventTypeRecord Byte# 3设置了比较方法的逻辑
#7eventTypeRecord byte40x00原始比较值MSBeventTypeRecord Byte# 4, Byte# 5, Byte# 6, Byte# 7设置了比较的参考值
#8eventTypeRecord byte50x00原始比较值—
#9eventTypeRecord byte60x01原始比较值—
#10eventTypeRecord byte70x00原始比较值LSB—
#11eventTypeRecord byte80x0Ahysteresis valueeventTypeRecord Byte# 8定义了从0%到100%的histeresys value
#12eventTypeRecord byte90xBCLocalization byte 1 MSB, 见下表eventTypeRecord Byte# 9, Byte# 10定了值在数据标识符中的位置，见下表
#13eventTypeRecord byte100x58Localization byte 2 LSB, 见下表—
#14serviceToRespondTo byte 10x22SIDserviceToRespondToRecord设置了服务，需要读取及比较的DID。在第一个肯定应答报文中numberOfIdentifiedEvents的区域总是设置为0x00
#15serviceToRespondTo byte 20xA1DID1—
#16serviceToRespondTo byte 30x00DID2—
                 

比较逻辑参数(comparison logic)的定义：

Comparison logic IDEvent will be generated when
0x01比较值 < 测量值
0x02比较值 > 测量值
0x03比较值 = 测量值
0x04比较值 <> 测量值

值位置(localization of value)16位 位域的定义：

Bitfield bit position描述
15(MSB), bit = 0 表示无符号比较, bit = 1 有符号比较
14 - 10第10位(LSB) -第14位(MSB)包含了将要比较的数据标识符的值的长度。值0x00用于比较所有的4个字节，其他值都以位为单位去设置大小。14-10有5个位，因此最大长度为31。
9 - 0肯定应答报文的偏移量，从中提取DID的值；Bit#0(LSB) - Bit#9 (MSB)包含了数字偏移量的起始位，10个位，表示的最大偏移为1023。
            

2.3 请求报文数据参数定义

定义
eventWindowTime
eventWindowTime参数用于指定在服务端被激活事件逻辑的窗口。如果eventWindowTime的参数值被设置为0x02，那么响应时间是无限的。如果事件窗口无限，storageState = doNotStoreEvent，建议通过一个具体的信号关闭事件窗口（如下电）；
有限事件窗口与storageState = storeEvent的组合，不能使用；
注意：如果eventType = ROE control subfunction，该参数不适用于服务端来评估。
eventTypeRecord
该参数记录包含了指定事件类型的附加参数；
serviceToRespondToRecord
该参数记录包含了每次发生eventTypeRecord中定义的指定事件时，需要被执行的服务参数(如ID，service parameters) ；

3、肯定应答报文

3.1 肯定应答报文定义

所有子函数参数的肯定应答报文格式(除了subFunction = reportActivatedEvents)定义如下：

字节序号参数名称约定字节值
#1ResponseOnEvent Response SIDM0xC6
#2eventTypeM0x00 - 0x7F
#3numberOfIdentifiedEventsM0x00 - 0x7F
#4eventWindowTimeM0x00 - 0x7F

#5
.
.
#(m-1)+5		eventTypeRecord[] = [
               eventTypeParameter 1
               .
               .
               eventTypeParameter m ]		C1
0x00 – 0xFF
.
.
0x00 – 0xFF

#n-(r-1)-1
#n-(r-1)
.
.
#n		serviceToRespondToRecord[] = [
               serviceId
               serviceParameter 1
               .
               .
               serviceParameter r ]
M
C2
.
.
C2
0x00 – 0xFF
0x00 – 0xFF
.
.
0x00 – 0xFF

  C1: 如果eventType需要指定附加参数去响应事件，则出现该参数；
  C2: 如果服务的请求将要去应答需要附加服务参数，则出现该参数；

子函数参数subFunction = reportActivatedEvents的肯定应答报文格式定义如下：

字节序号参数名称约定字节值
#1ResponseOnEvent Response SIDM0xC6
#2eventType = reportActivatedEventsM0x04
#3numberOfActivatedEventsM0x00 - 0xFF
#4eventTypeOfActiveEvent#1C10x00 - 0xFF
#5eventWindowTime#1C10x00 - 0xFF

#6
.
.
#(m-1)+6		eventTypeRecord#1[] = [
               eventTypeParameter 1
               .
               .
               eventTypeParameter m ]		C2
0x00 – 0xFF
.
.
0x00 – 0xFF

#p-(o-1)-1
#p-(o-1)
.
.
#p		serviceToRespondToRecord#1[] = [
               serviceId
               serviceParameter 1
               .
               .
               serviceParameter o ] ]
C3
C4
.
.
C4
0x00 – 0xFF
0x00 – 0xFF
.
.
0x00 – 0xFF

#5
.
.
#(m-1)+5		eventTypeRecord[] = [
               eventTypeParameter 1
               .
               .
               eventTypeParameter m ]		C1
0x00 – 0xFF
.
.
0x00 – 0xFF
.
.		.
.		.
.		.
.
#n-(r-1)-4-(q-1)eventTypeOfActiveEvent#kC10x00 – 0xFF
#n-(r-1)-3-(q-1)eventWindowTime#kC10x00 – 0xFF

#n-(r-1)-2-(q-1)
.
.
#n-(r-1)-2		eventTypeRecord#k[] = [
               eventTypeParameter 1
               .
               .
               eventTypeParameter q ]		C2
0x00 – 0xFF
.
.
0x00 – 0xFF

#n-(r-1)-1
#n-(r-1)
.
.
#n		serviceToRespondToRecord#k[] =[
               serviceId
               serviceParameter 1
               .
               .
               serviceParameter r ] ]
C3
C4
.
.
C4
0x00 – 0xFF
0x00 – 0xFF
.
.
0x00 – 0xFF

  C1: 如果激活的事件被汇报时，则出现该参数；
  C2: 如果激活事件的汇报事件类型(eventTypeOfActiveEvent)为响应指定事件需要附加参数时，则出现该参数；
  C3: 当汇报激活事件时，则强制出现该参数；
  C4: 如果服务的请求将要去应答需要附加服务参数，则出现该参数；

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

Definition
eventType
请求报文中子函数参数值中的bit 6 - 0。
eventTypeOfActiveEvent
请求报文中子函数中为了设置激活事件的参数，应用值为子函数参数eventType指定的一类值。
numberOfActivatedEvents
当客户端请求汇报激活事件的数量时，该参数包含了所激活事件的数量，事件的数量会在应答报文中汇报。
numberOfIdentifiedEvents
此参数包含在激活的事件窗口中已识别的事件数量，并且仅适用于在事件窗口结束时发送的响应消息(如果是有限事件窗口)。对请求报文的初始化响应，在此参数中应该包含一个零(0)。
eventTypeRecord
来自于请求报文中eventTypeRecord参数，当汇报激活事件时，此参数是为设置激活事件请求中eventTypeRecord的回显；
serviceToRespondToRecord
来自于请求报文serviceToRespondToRecord中的参数，当汇报一个激活的事件时，此参数是为设置激活事件请求消息serviceToRespondToRecord的回显。

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

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

NRC描述
0x12sub-functionNotSupported
子函数参数不支持时，会发送该NRC
0x13incorrectMessageLengthOrInvalidFormat
请求报文长度不正确时，会发送该NRC
0x22conditionsNotCorrect
当服务器处于关键的正常模式活动时，并且因此无法运行请求功能时，会发送该NRC
0x31requestOutOfRange
如果eventTypeRecord parameter参数中有错误，指定的eventWindowTime时间无效，请求的DID不支持，以及有限窗口与storageState = storeEvent的组合，都会发送该NRC

5、0x86服务（事件响应服务）案例说明

5.1 假设

  案例中假设了eventWindowTime = 0x08，定义了事件窗口为80s(eventWindowTime * 10 seconds)。通过设置suppressPosRspMsgIndicationBit (bit 7 of the sub-function parameter) 为 FALSE，客户端请求应答报文。
  注意：eventWindowTime的定义由车辆制造厂商指定，除了在下表中被指定的eventWindowTime的参数值。

Byte ValueDescriptionCvt
0x00 - 0x01ISOSAEReserved
ISO保留		M
0x02infiniteTimeToResponse
该参数值指定了事件窗口应该保持激活无限时间(例如，打开窗口一直到熄火)		U
0x03 - 0x7FvehicleManufacturerSpecific
该范围的参数值为车辆制造厂商保留使用，eventWindowTime参数的精度由车辆制造厂商自行定义		U
0x80 - 0xFFISOSAEReserved
ISO保留		M

  以下条件适用于0x86服务的使用案例：
——Trigger signal:
  定义具体的触发信号，可以触发客户端(如外部测试设备，OBD单元，诊断主机)来开始0x86服务ResponseOnEvent请求报文。这个触发信号可以通过一个事件或者就像一个heartbeat-time的固定时间(应该比eventWindowTime要大)。而且在数据链路层应该有一个同步消息(如同步信号)作为触发信号。
——Open event window:
  一旦接收0x86服务ResponseOnEvent请求报文，服务端应该去评估。如果评估有效，服务端应该设置事件逻辑，必须发送初始的肯定应答报文。为了激活事件逻辑，客户端应该请求子函数参数为startResponseOnEvent。在肯定应答之后，事件逻辑被激活，并且事件窗口计时器正在运行。详细地去定义事件窗口的一些参数，由车辆制造厂商去指定使用eventWindowTime参数(如计时窗口，点火开/关窗口)。如果检测到指定的eventType (EART_)，服务端必须立即响应与ResponseOnEvent请求中的serviceToRespondToRecord相对应的响应消息。
——Close event window：
  推荐根据参数eventWindowTime来关闭服务端的事件窗口。关闭事件窗口之后，服务端应该停止发送可以驱动诊断应答报文的事件。同样可以通过发送ResponseOnEvent (ROE_)请求消息(包括参数stopResponseOnEvent)或关闭电源来实现。

5.2 ResponseOnEvent使用案例

例1：ResponseOnEvent (finite event window)
  下表定义了ResponseOnEvent请求报文的设置：
  事件响应服务的请求报文使用案例1如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ResponseOnEvent Request SID0x86
#2eventTypeRecord [ eventType ] = onDTCStatusChange,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x01
#3eventWindowTime = 80 seconds0x08
#4eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#5serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#6serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#7serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  事件响应服务案例1初始的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Request SID0xC6
#2eventTypeRecord [ eventType ] = onDTCStatusChange0x01
#3numberOfIdentifiedEvents = 00x00
#4eventWindowTime = 80 seconds0x08
#5eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#6serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#7serviceToRespondToRecord [ sub-function ] = reportNumberOfDTCByStatusMask0x01
#8serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  事件逻辑被设置；现在事件必须要被激活。
  下表定义了ROE请求报文的启动。事件响应服务的请求报文使用案例如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ResponseOnEvent Request SID0x86
#2eventTypeRecord [ eventType ] = startResponseOnEvent,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x05
#3eventWindowTime (will not be evaluated)0x08

  事件响应服务的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Request SID0xC6
#2eventType = onDTCStatusChange0x01
#3numberOfIdentifiedEvents = 00x00
#4eventWindowTime0x08

  如果发生指定的事件，服务端应该能够根据指定serviceToRespondToRecord去发送应答报文。
  0x19服务ReadDTCInformation的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ReadDTCInformation Response SID0x59
#2DTCStatusAvailibilityMask0xFF
#3DTCCount [ DTCCountHighByte ] = 00x00
#4DTCCount [ DTCCountLowByte ] = 40x04

  客户端在激活事件窗口期间请求报告服务端中当前活动事件情况的消息流如下所示。
  ResponseOnEvent请求激活事件的数量

字节顺序Description字节值
#1ReadDTCInformation Response SID0x86
#2eventTypeRecord [ eventType ] = reportActivatedEvents,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x04
#3eventWindowTime (will not be evaluated)0x08

  ResponseOnEvent reportActivatedEvents的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Response SID0xC6
#2eventType = reportActivatedEvents0x04
#3numberOfActivatedEvents = 10x01
#4eventTypeOfActiveEvent = onDTCStatusChange0x01
#5eventWindowTime = 80 seconds0x08
#6eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#7serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#8serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#9serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  如果指定的事件窗口时间超时了，服务端应该发送最终的肯定应答报文。
  ResponseOnEvent最终的肯定应答报文定义如下：

字节顺序Description字节值
#1ResponseOnEvent Response SID0xC6
#2eventType = onDTCStatusChange0x01
#3numberOfIdentifiedEvents = 10x01
#4eventWindowTime = 80 seconds0x08
#5eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#6serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#7serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#8serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  Example #1 - flowcharts
  如下所示的流程图展示了两种不同的服务端行为：
—— 在有限事件窗口内不发生任何事件。在这种情况下，服务器必须在事件窗口的末尾发送ResponseOnEvent的响应。
—— 有限事件窗口内的多个事件(#1到#n)。serviceToRespondTo的每个肯定应答都与一个已识别的事件(#1…#n)相关，并且应该具有相同的服务标识符(SId)，但可能具有不同的内容。在event_Window结束时，服务器将发送responseOnEvent服务的肯定应答报文，该报文表示numberOfIdentifiedEvents。
  下图展示了有限事件窗口— 在激活事件窗口中无事件。
在这里插入图片描述

  下图展示了有限事件窗口— 在激活事件窗口中有多个事件。

在这里插入图片描述
例2：ResponseOnEvent (infinite event window)
  事件响应服务的请求报文使用案例2如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ResponseOnEvent Request SID0x86
#2eventTypeRecord [ eventType ] = onDTCStatusChange,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x01
#3eventWindowTime = infinite0x02
#4eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#5serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#6serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#7serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  事件响应服务案例2初始的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Request SID0xC6
#2eventTypeRecord [ eventType ] = onDTCStatusChange0x01
#3numberOfIdentifiedEvents = 00x00
#4eventWindowTime = infinite0x02
#5eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#6serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#7serviceToRespondToRecord [ sub-function ] = reportNumberOfDTCByStatusMask0x01
#8serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  事件逻辑被设置；现在事件必须要被激活。
  下表定义了案例2 ROE请求报文的启动。案例2 事件响应服务的请求报文使用案例如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ResponseOnEvent Request SID0x86
#2eventTypeRecord [ eventType ] = startResponseOnEvent,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x05
#3eventWindowTime (will not be evaluated)0x02

  案例2 事件响应服务的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Request SID0xC6
#2eventType = onDTCStatusChange0x05
#3numberOfIdentifiedEvents = 00x00
#4eventWindowTime0x02

  如果发生指定的事件，服务端应该能够根据指定serviceToRespondToRecord去发送应答报文。
  案例2中0x19服务ReadDTCInformation的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ReadDTCInformation Response SID0x59
#2DTCStatusAvailibilityMask0xXX
#3DTCCount [ DTCCountHighByte ] = 00x00
#4DTCCount [ DTCCountLowByte ] = 40x04

  客户端在激活事件窗口期间请求报告服务端中当前活动事件情况的消息流如下所示。
  ResponseOnEvent请求激活事件的数量

字节顺序Description字节值
#1ReadDTCInformation Response SID0x86
#2eventTypeRecord [ eventType ] = reportActivatedEvents,
               storageState = doNotStoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x04
#3eventWindowTime (will not be evaluated)0x08

  ResponseOnEvent reportActivatedEvents的肯定应答报文见下表，由服务端(ECU)发往客户端：

字节顺序Description字节值
#1ResponseOnEvent Response SID0xC6
#2eventType = reportActivatedEvents0x04
#3numberOfActivatedEvents = 10x01
#4eventTypeOfActiveEvent = onDTCStatusChange0x01
#5eventWindowTime = 80 seconds0x08
#6eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#7serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#8serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#9serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  如果指定的事件窗口时间超时了，服务端应该发送最终的肯定应答报文。
  ResponseOnEvent最终的肯定应答报文定义如下：

字节顺序Description字节值
#1ResponseOnEvent Response SID0xC6
#2eventType = onDTCStatusChange0x01
#3numberOfIdentifiedEvents = 10x01
#4eventWindowTime = 80 seconds0x08
#5eventTypeRecord [ eventTypeParameter ] = testFailed status0x01
#6serviceToRespondToRecord [ serviceId ] = ReadDTCInformation0x19
#7serviceToRespondToRecord [ sub-function ] =
                    reportNumberOfDTCByStatusMask		0x01
#8serviceToRespondToRecord [ DTCStatusMask ] = testFailed status0x01

  Example #2 - flowcharts
  如下所示的流程图展示了两种不同的服务端行为：
—— 在无限事件窗口内不发生任何事件。
—— 无限事件窗口内的多个事件(#1到#n)。serviceToRespondTo的每个肯定应答都与一个已识别的事件(#1…#n)相关，并且应该具有相同的服务标识符(SId)，但可能具有不同的内容。
  下图展示了无限事件窗口— 在激活事件窗口中无事件的情况。

在这里插入图片描述

  下图展示了无限事件窗口— 在激活事件窗口中有多个事件的情况。

在这里插入图片描述

例3：ResponseOnEvent (infinite event window) – sub-function parameter “onComparisonOfValues”

  这个例子只解释了子函数参数“onComparisonOfValues”的用法，假设案例1和案例2中描述的ROE服务的通信行为没有改变。因此，此示例没有描述完整的消息流。相反，事件窗口设置请求消息和对发生事件的肯定应答报文将被展示和解释。开始和停止请求报文以及不同的响应消息已经在上面的例子中描述了，以下条件适用：
—— 0x22服务-根据标识符读取数据服务(ReadDataByIdentifier)，被挑选为serviceToRespondTo；
—— 0x0104数据标识符包含了测量值，这个测量值需要在数据字节#11和#12中被比较；
—— 如果测量值(MV)大于所谓的比较参数(comparison parameter - CP)，那么操作符值(operator)则变为0x01 - “MV > CP”；
—— hysteresis value 0x0A - 设置为10%；
—— eventWindowTime值设置为0x02，表示“infinite”；
—— storageState (eventType sub-function bit 6)设置为1，表示“storeEvent”；
—— 在任何情况下，应答都是需要的；
  案例的定义：
—— Byte#4&5: dataIdentifier 0x0104
—— Byte#6&7: 读取的位置和读取类型的定义
例1  如果读取数据记录的第11个字节，适用于以下情况：
    —— 11 * 8 = 88(dec) = 00 0101 1000(binary) Bit#10 - Bit#14: length in bits - 1.
    —— 使用5 bits，最多可表示32bits = “long”
例2  对于"word"，长度为15(dec) = = 0 1111(binary)，Bit#15: Sign entry: 1=signed, 0=unsigned；
例3  Total assignment would be：
    —— 1011 1100 0101 1000b= 0xBC58，因此 byte#6 contains 0xBC, byte#7 contains 0x58
    —— Byte#8，比较运算符(operator)；
例4  操作符MV > CP = 0x01：
    —— Byte#9-12：比较参数由于占四个字节，所有数据类型都可以从’Bit’ 到’Long’类型转换；
例5  如果比较值是5242(dec) = 0x0000 147A：
    —— byte#9 = 0x00, byte#10 = 0x00, byte#11 = 0x14 and byte#12 = 0x7A
    —— Byte#13: Hysteresis value (指定比较参数的百分比). It only applies to 只有在操作符(operators)为 “<” 和 ">"时，才能应用。 为了防止0作为比较参数值，hysteresis value应该被定义为绝对值。
例6  Hysteresis value 10% = 0x0A。

  案例3中，事件响应服务的请求报文使用如下，由客户端发向服务端(ECU)：

字节顺序Description字节值
#1ResponseOnEvent Request SID0x86
#2eventTypeRecord [ eventType ] = onComparisonOfValues,
               storageState = StoreEvent
               suppressPosRspMsgIndicationBit = FALSE		0x47
#3eventWindowTime = infinite0x02
#4eventTypeRecord [ eventTypeParameter#1 ] = recordDataIdentifier (High Byte)0x01
#5eventTypeRecord [ eventTypeParameter#2 ] = recordDataIdentifier (Low Byte)0x04
#6eventTypeRecord [ eventTypeParameter#3 ] = Valueinfo#10xBC
#7eventTypeRecord [ eventTypeParameter#4 ] = Valueinfo#20x58
#8eventTypeRecord [ eventTypeParameter#5 ] = Operator0x01
#9eventTypeRecord [ eventTypeParameter#6 ] = Comparison Parameter (Byte#4)0x00
#10eventTypeRecord [ eventTypeParameter#7 ] = Comparison Parameter (Byte#3)0x00
#11eventTypeRecord [ eventTypeParameter#7 ] = Comparison Parameter (Byte#2)0x14
#12eventTypeRecord [ eventTypeParameter#7 ] = Comparison Parameter (Byte#1)0x7A
#13eventTypeRecord [ eventTypeParameter#10 ] = Hysteresis [%]0x0A
#14serviceToRespondToRecord [ serviceID ] = ReadDataByIdentifier0x22
#15serviceToRespondToRecord [ serviceParameter#1 ] = dataIdentifier (MSB)0x01
#16serviceToRespondToRecord [ serviceParameter#2 ] = dataIdentifier (LSB)0x04

注意：  响应消息和后续的初始化序列没有显示。
  事件窗口成功设置以及ROE机制被激活后，如果测量值大于5242(dec)，服务端中指定的事件会发生，如下报文也会被发送：
  案例3中0x22服务(根据标识符读取数据服务)的肯定应答报文定义如下：

字节顺序Description字节值
#1ReadDataByIdentifier Response SID0x62
#2dataIdentifier [ byte#1 ] (MSB)0x01
#3dataIdentifier [ byte#2 ] (LSB)0x04
#4dataRecord [ data#1 ]0xXX
#5dataRecord [ data#2 ]0xXX
#6dataRecord [ data#3 ]0xXX
#7dataRecord [ data#4 ]0xXX
#8dataRecord [ data#5 ]0xXX
#9dataRecord [ data#6 ]0xXX
#10dataRecord [ data#7 ]0xXX
#11dataRecord [ data#8 ]0xXX
#12dataRecord [ data#9 ]0xXX
#13dataRecord [ data#10 ]0xXX
#14dataRecord [ data#11 data content of byte#11: 0x14 ]0x14
#15dataRecord [ data#12 data content of byte#12: 0x7B ]0x7B

  另一个事件发生在测量值至少一次低于比较参数值的90%之前。这种行为由hysteresis value指定。如果满足此条件，并且测量值再次高于比较值，则会发生新的事件，服务端将会发送新的ReadDataByIdentifier应答报文。

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

三星小卤蛋
关注
  • 4
    点赞
  • 踩
  • 14
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
汽车UDS诊断详解及Vector相关工具链使用说明——2.1.12 基于事件响应（0x86）
weixin_42967006的博客
10-26 1599
1. 概述 基于事件响应（ResponseOnEvent）服务（0x86）顾名思义就是当ECU发生了某个事件或满足了某个条件的时候发送响应，这和以往我们介绍的一条请求一条响应的诊断通信方式有所不同。 86服务的大体流程如下图所示： 首先诊断仪要先向ECU发送请求，设置一个事件逻辑，之后再向ECU发送指令控制该事件逻辑的启动，指令中附带eventWindowTime参数，即事件有效持续时间。当事件逻辑启动时，如果发生了指定的事件，ECU就会返回一条响应。 2. 执行规则 （1） 86服务可以在任何诊断会话下
UDS入门至精通系列Service 86
Soly_kun的博客
11-27 932
本文详细分享了UDS Service86的应用场景和功能，并基于协议描述了该服务的请求和响应格式。
跟我学UDS(ISO14229) ———— 0x86(ResponseOnEvent)
永远的菜鸡小詹的博客
05-25 3826
客户端请求启动服务器中的事件机制。该服务是请求服务器启动或停止对指定事件的响应的传输。如果服务器中发生指定的事件，此服务提供了自动执行诊断服务的可能性。 客户端指定事件（包括可选的事件参数）和事件发生时要执行的服务（包括服务参数）。 有关客户端和服务器行为的简要概述，请参见下图： 注意：上图的流程中是假定事件窗口计时器配置为在服务器掉电之前超时，因此最终的ResponseOnEvent肯定响应消息显示在事件计时窗口的末尾。服务器应在接收时评估ResponseOnEvent请求消息的子功能和数据内容。 这包
【车载开发系列】UDS诊断---基于事件响应（$0x86）
千月星跡
12-22 970
【车载开发系列】UDS诊断—基于事件响应（$0x86） 诊断---基于事件响应（$0x86）【车载开发系列】UDS诊断---基于事件响应（$0x86）一.概念定义二.注意事项三.报文格式1）请求报文2）肯定响应3）否定响应 一.概念定义 基于事件响应（ResponseOnEvent）服务（0x86）顾名思义就是当ECU发生了某个事件或满足了某个条件的时候发送响应，这和以往我们介绍的一条请求一条响应的诊断通信方式有所不同。 该服务是请求服务器启动或停止传输对特定事件的响应。 由客户端规定事件发生时将要执行的
UDS 14229 - 中英文 - 86 service - section1
rengubai的博客
06-06 2503
9.10 ResponseOnEvent (0x86) service- 基于事件响应 服务 9.10.1 Service description服务描述 The ResponseOnEvent service requests a server to start or stop transmission of responses on a specified event. 此服务请求服务器开始或停止对一特定事件发送响应报文。 This service provides the pos...
《UDS协议从入门到精通》系列——图解0x86：事件响应
最新发布
车载系统攻城狮
07-04 811
到底如何理解UDS协议中的事件响应机制？详解UDS最复杂的服务之一！！
UDS统一诊断服务
05-07
ISO 14229-1道路车辆—统一诊断服务 应用层协议
(57条消息) 汽车UDS诊断详解及Vector相关工具链使用说明——2.1.12 基于事件响应（0x86）_老孟_的博客-CSDN博客.mhtml
12-05
(57条消息) 汽车UDS诊断详解及Vector相关工具链使用说明——2.1.12 基于事件响应（0x86）_老孟_的博客-CSDN博客.mhtml
ISO 14229-4.zip_14229-4_ISO 14229_uds_uds 14229_uds诊断
07-15
《ISO 14229-4：UDS 诊断通信协议详解》 在现代汽车电子系统中，诊断服务和通信协议扮演着至关重要的角色。ISO 14229，也被称为统一诊断服务（UDS），是全球汽车行业中广泛采用的诊断标准，尤其在控制器局域网络...
ISO14229_iso14229中文_iso14229_UDS协议中文
06-01
ISO14229，全称为“Road Vehicles - Diagnostics on Controller Area Network (CAN) - Unified Diagnostic Services”（道路车辆-CAN总线统一诊断服务），是国际标准化组织（ISO）制定的一项汽车行业标准，用于规范...
UDS诊断服务详解.docx
08-23
UDS由ISO-14229系列标准定义，ISO 14229-1 定义了诊断服务，不涉及网络及实现，只有应用层的内容。而ISO 14229-3则定义了UDS在CAN总线上的实现。 诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。
ISO14229(2006).zip_Bootloader_UDS ISO14229_UDS14229协议_uds_汽车UDS
07-14
UDS 协议文件，可以供在CAN、Bootloader以及汽车电子的设计时参考
SS-ISO_14229-3_2012.zip_14229_14229-3_2012_ISO 14229_uds
09-24
ISO 14229，也被称为统一诊断服务（UDS），是汽车行业中广泛应用的一套通信协议，用于车载电子系统的故障检测、诊断和维修。这个标准由国际标准化组织（ISO）制定，其2012年的第三部分（ISO 14229-3）是UDS的重要...
ISO 14229-3.zip_ISO 14229-3_ISO-14229_UDS ISO_uds_诊断uds
07-14
诊断参考文档 汽车控制器 UDS 14229-3
统一诊断服务 (Unified diagnostic services ， UDS) （三）
u012252959的博客
10-15 8527
大年初二更新一篇，祝大家春节快乐，好好休整，节后更好地工作生活。 在上一篇文章中我写了Diagnostic and Communication Management （诊断和通信管理）这一类诊断服务中的0x10 , 0x11 , 0x27，在这篇文章中继续这一大类诊断服务中的其他内容。 CommunicationControl (0x28) 该服务用于打开/关闭某些类别的报文的发送/接收。它...
诊断通讯模块Dcm的UDS服务概述
m0_37777700的博客
02-18 2392
0引言 故障诊断系统中，诊断通讯管理模块（Diagnostic Coummunication Management，Dcm）主要实现UDS和OBD的诊断服务，即处理诊断数据流和管理诊断状态，包括诊断会话和安全状态，检查诊断服务的请求是否满足条件等功能。 本文主要介绍Dcm模块的UDS服务(Unified Diagnostic Services，统一诊断服务)，UDS服务是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又发什么指令。下文将说明以下几块内容： -...
0x86事件响应服务
qiu421的博客
09-28 153
请求服务端开始或停止传输具体事件的响应。
x86中内存管理寄存器
yyt7529的专栏
07-06 4468
一、内存管理寄存器处理器提供了4个内存管理寄存器（GDTR、LDTR、IDTR和TR），用于指定内存分段管理所用系统表的基地址，如图4-2所示。处理器为这些寄存器的加载和保存提供了特定的指令。有关系统表的作用请参见4.2节"保护模式内存管理"中的详细说明。 （点击查看大图）图4-2  内存管理寄存器GDTR、LDTR、IDTR和TR都是段基址
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协议栈实现了车载控制电子单元的标准化通讯，可简化车辆诊断和维护过程，提高效率和可靠性。同时，相应的规范、文档和源代码也为相关人员提供了方便和支持。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值