9、诊断和通信管理功能单元(6-10)

系列文章目录

9、诊断和通信管理功能单元(1-5)
9、诊断和通信管理功能单元(6-10)


9、诊断和通信管理功能单元6-10

9.6 testpresent (0x3E)服务

9.6.1服务描述


  此服务用于向一个(或多个)服务器指示客户端仍连接到车辆,并且先前已激活的某些诊断服务和/或通信将保持活动状态。
  此服务用于将一个或多个服务器保持在除defaultSession之外的诊断会话中。这可以通过定期传输testpresent请求消息来完成,也可以在没有其他诊断服务的情况下完成,以防止服务器自动返回到defaultSession。当在诊断会话中保留单个服务器或多个服务器(而不是defaultSession)时,适用于使用 此服务的详细会话要求可以在ISO 14229的实现规范中找到。
  重要提示——服务器和客户端应满足7.5中规定的请求和响应消息行为。

9.6.2请求消息

9.6.2.1请求消息定义


  表65定义了请求消息。

表65 -请求消息定义
A_Data byteParameter NameCvtByte ValueMnemonic
#1TesterPresent Request SIDM0x3ETP
#2sub-function = [ zeroSubFunction ]M0x00 / 0x80LEV_ZSUBF

9.6.2.2请求消息子函数参数$Level (LEV_)的定义


  表66指定了为该服务定义的子函数参数值(suppressPosRspMsgIndicationBit (bit 7)未显示)。

表66 -请求消息子函数参数定义
Bits 6 – 0DescriptionCvtMnemonic
0x00zeroSubFunction
该参数值表示该服务不支持除suppressPosRspMsgIndicationBit之外的子功能值。
MZSUBF
0x01 – 0x7FISOSAEReserved
此值范围由本文档保留。
MISOSAERESRVD

9.6.2.3请求消息数据参数定义

- 
  此服务不支持请求消息中的数据参数。

9.6.3肯定响应消息

9.6.3.1肯定响应消息定义


  表67定义了肯定响应消息。

表67 -肯定响应消息定义
A_Data byteParameter NameCvtByte ValueMnemonic
#1TesterPresent Response SIDM0x7ETPPR
#2sub-function = [ zeroSubFunction ]M0x00LEV_ZSUBF

9.6.3.2正响应消息数据参数定义


  表68定义了肯定响应消息的数据参数。

表68 -响应消息数据-参数定义
定义
zeroSubFunction
该参数是请求消息中子函数参数6 - 0位的回显。

9.6.4支持的否定响应码(NRC_)


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

表69 -支持的否定响应代码
NRCDescriptionMnemonic
0x12sub-functionNotSupported
如果子功能参数不被支持,则发送此NRC。
SFNS
0x13incorrectMessageLengthOrInvalidFormat
如果消息长度错误,则应发送此NRC。
IMLOIF

9.6.5消息流示例testpresent

9.6.5.1示例#1 - testpresent (suppressPosRspMsgIndicationBit = FALSE)


  表70定义了testpresent请求消息流示例#1。

表70 - testpresent请求消息流示例#1
Message directionclient → server(客户端 →服务器)
Message TypeRequest(请求)
A_Data byte描述(所有值都是十六进制)Byte ValueMnemonic
#1TesterPresent Request SID0x3ETP
#2zeroSubFunction, suppressPosRspMsgIndicationBit = FALSE0x00ZSUBF


  表71定义了testpresent肯定响应消息流示例#1。

表71 - testpresent肯定响应消息流示例#1
Message directionserver→ client(服务器 → 客户端)
Message TypeResponse(响应)
A_Data byte描述(所有值都是十六进制)Byte ValueMnemonic
#1TesterPresent Response SID0x7ETPPR
#2zeroSubFunction, suppressPosRspMsgIndicationBit = FALSE0x00ZSUBF

9.6.5.2示例#2 - testpresent (suppressPosRspMsgIndicationBit = TRUE)


  表72定义了testpresent请求消息流示例#2。

表72 - testpresent请求消息流示例#2
Message directionclient → server(客户端 →服务器)
Message TypeRequest(请求)
A_Data byte描述(所有值都是十六进制)Byte ValueMnemonic
#1TesterPresent Request SID0x3ETP
#2zeroSubFunction, suppressPosRspMsgIndicationBit = TRUE0x80ZSUBF


  服务器没有发送任何响应。

9.7 AccessTimingParameter (0x83)服务

9.7.1服务描述


  AccessTimingParameter服务用于读取和更改通信链路活动期间的默认定时参数。
  该服务的使用很复杂,取决于服务器的能力和数据链路拓扑。每个诊断会话只支持一个扩展的定时参数集。建议仅将此服务与物理寻址一起使用,因为服务器支持不同的扩展定时参数集。
  建议使用如下业务顺序:
  ——diagnostic - sessioncontrol (diagnosticSessionType)服务;
  ——AccessTimingParameter (readExtendedTimingParameterSet)服务;
  ——AccessTimingParameter (setTimingParametersToGivenValues)服务;
  对于需要服务器发送响应的情况,客户端和服务器应在服务器发送AccessTimingParameter肯定响应消息后激活新的定时参数设置。如果不允许响应消息,则客户端和服务器在发送/接收请求消息后激活新的定时参数。
  在成功切换到另一个或相同的诊断会话后,服务器和客户端应将其定时参数重置为默认值(例如,通过    DiagnosticSessionControl, ECUReset服务或会话定时超时)。
  AccessTimingParameter服务为访问服务器定时参数提供了四种不同的模式:
  ——readExtendedTimingParameterSet;
  ——setTimingParametersToDefaultValues;
  ——readCurrentlyActiveTimingParameters;
  ——setTimingParametersToGivenValues;
  重要提示——务器和客户端应满足7.5中规定的请求和响应消息行为。

9.7.2请求消息

9.7.2.1请求消息定义


  表73定义了请求消息。

表73 -请求消息定义
A_Data byteParameter NameCvtByte ValueMnemonic
#1AccessTimingParameter Request SIDM0x83ATP
#2sub-function = [ timingParameterAccessType ]M0x00 – 0xFFLEV_TPAT_
#3
:
#n
TimingParameterRequestRecord [
byte#1
:
byte#m ]
C
:
C
0x00 – 0xFF
:
0x00 – 0xFF
TPREQR_
B1
:
Bm
C: TimingParameterRequestRecord只有在timingParameterAccessType = setTimingParametersToGivenValues时才存在。TimingParameterRequestRecord的结构和内容依赖于数据链路层,因此在ISO 14229的实现规范中定义。

9.7.2.2请求消息子函数参数$Level (LEV_)的定义


  AccessTimingParameter服务使用子函数参数timingParameterAccessType来选择服务器的特定行为。表74详细说明了可能的timingparameteridentifier的解释和用法。指定以下子函数值(suppressPosRspMsgIndicationBit (bit 7)未显示):

表74 -请求消息子函数参数定义
Bits 6 – 0DescriptionCvtMnemonic
0x00ISOSAEReserved
此值由本文档保留。
MISOSAERESRVD
0x01readExtendedTimingParameterSet

当接收到带有timingParameterAccessType = readExtendedTimingParameterSet的AccessTimingParameter指示原语时,服务器将读取扩展的定时参数集,即服务器能够支持的值。

如果对定时参数集的读访问成功,服务器将发送一个带有肯定响应参数的AccessTimingParameter响应原语。

如果对设置的定时参数的读访问不成功,服务器将发送带有相应的否定响应码的否定响应消息。

此子函数用于为当前活动的诊断会话提供一组额外的定时参数。

通过timingParameterAccessType = setTimingParametersToGivenValues,只能设置这组定时参数(由timingParameterAccessType = readExtendedTimingParameterSet读取)。
URETPS
0x02setTimingParametersToDefaultValues

当服务器接收到带有timingParameterAccessType = setTimingParametersToDefaultValues的AccessTimingParameter指示原语时,在默认的定时参数生效之前(如果suppressPosRspMsgIndicationBit被设置为FALSE),服务器将把所有的定时参数修改为默认值,并发送一个带有肯定响应参数的AccessTimingParameter响应原语。否则,在成功评估请求消息后,定时参数将变为活动状态)。

如果由于任何原因无法将定时参数更改为默认值,则服务器应保持当前活动的定时参数,并发送带有适当的负面响应代码的负面响应消息。

默认定时值的定义取决于所使用的数据链路,并在ISO 14229的实现规范中指定。
USTPTDV
0x03readCurrentlyActiveTimingParameters

当接收到带有timingParameterAccessType = readCurrentlyActiveTimingParameters的AccessTimingParameter指示原语时,服务器将读取当前使用的定时参数。

如果对定时参数的读访问成功,服务器将发送一个带有肯定响应参数的AccessTimingParameter响应原语。

如果由于任何原因无法对当前使用的定时参数进行读访问,则服务器应发送带有适当的负响应代码的负响应消息。
URCATP
0x04setTimingParametersToGivenValues

当接收到带有timingParameterAccessType = setTimingParametersToGivenValues的AccessTimingParameter指示原语时,服务器将检查在当前条件下是否可以更改定时参数。

如果条件有效,服务器将执行所有必要的操作来更改定时参数,并在新的定时参数值生效之前发送带有肯定响应参数的AccessTimingParameter响应原语(suppressPosRspMsgIndicationBit设置为FALSE,否则在成功评估请求消息后,定时参数将生效)。

如果由于任何原因无法改变定时参数,服务器应保持当前激活的定时参数,并发送带有相应的负面响应码的负面响应消息。

不可能将服务器的定时参数设置为通过timingParameterAccessType = readExtendedTimingParameterSet读取的最小值和最大值之间的任何一组值。服务器的定时参数只能设置为通过timingParameterAccessType = readExtendedTimingParameterSet读取的定时参数。这样做的请求将被服务器拒绝。
USTPTGV
0x05 – 0xFFISOSAEReserved
本文档保留此值以供将来定义。
MISOSAERESRVD

9.7.2.3请求消息数据参数定义


  表75定义了请求消息的数据参数。

表75 -请求消息数据-参数定义
定义
TimingParameterRequestRecord
该参数记录包含要通过timingParameterAccessType = setTimingParametersToGivenValues在服务器中设置的定时参数值。该参数记录的内容和结构是特定于数据链路层的,可以在ISO 14229的实施规范中找到,例如ISO 14229-3。

9.7.3肯定响应消息

9.7.3.1肯定响应消息定义


  表76定义了肯定响应消息。

表76 -肯定响应消息定义
A_Data byteParameter NameCvtByte ValueMnemonic
#1AccessTimingParameter Response SIDM0xC3ATPPR
#2timingParameterAccessTypeM0x00 – 0x7FTPAT_
#3
:
#n
TimingParameterRequestRecord [
byte#1
:
byte#m ]
C
:
C
0x00 – 0xFF
:
0x00 – 0xFF
TPREQR_
B1
:
Bm
C: TimingParameterResponseRecord只有在timingParameterAccessType = readExtendedTimingParameterSet或readCurrentlyActiveTimingParameters时才存在。TimingParameterResponseRecord的结构和内容依赖于数据链路层,因此在ISO 14229的实现规范中定义。

9.7.3.2 Positive response message data-parameter definition

- 
  Table 77 defines the data-parameters of the positive response message.

Table 77 — Response message data-parameter definition
定义
timingParameterAccessType
该参数是请求消息中子函数参数6 - 0位的回显。
TimingParameterResponseRecord
该参数记录包含通过timingParameterAccessType readExtendedTimingParameterSet或readCurrentlyActiveTimingParameters从服务器读取的定时参数值。该参数记录的内容和结构是特定于数据链路层的,可以在ISO 14229的实现规范中找到。

9.7.4支持的否定响应码(NRC_)


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

表78 -支持的否定响应代码

在这里插入图片描述

9.7.5消息流示例AccessTimingParameter

9.7.5.1示例#1 -将定时参数设置为默认值


  此消息流显示了如何在服务器中设置默认定时参数。客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  表79定义了AccessTimingParameter请求消息流示例#1。

表79 - AccessTimingParameter请求消息流示例#1

在这里插入图片描述
 - 
  表80定义了AccessTimingParameter肯定响应消息流示例#1。

表80 - AccessTimingParameter肯定响应消息流示例#1

在这里插入图片描述

9.8 secureddatatranssion (0x84)服务

9.8.1服务描述

9.8.1.1目的


  此服务的目的是传输免受第三方攻击的数据-这可能危及数据安全。
  如果客户机打算以安全模式使用本文中定义的诊断服务,则secureddatatranssion服务是适用的。它还可以用于在客户机和服务器之间以安全模式传输符合某些其他应用程序协议的外部数据。在这种情况下,安全模式意味着传输的数据受到加密方法的保护。

9.8.1.2安全子层

-
  图8说明了安全子层。为了在安全模式下执行诊断服务,必须在服务器和客户端应用程序中添加安全子层。
在这里插入图片描述

图8 -安全子层实现


  在客户端和服务器之间执行诊断服务数据传输有两种方法:
  ——不安全的数据传输方式
  应用程序使用本文档中定义的诊断服务和应用层服务原语在客户机和服务器之间交换数据。安全子层在客户端和服务器端的“应用程序”和“应用层”之间执行数据的“Pass-Thru”。
  ——安全数据传输方式
  应用程序使用诊断服务或外部服务和安全子层服务原语在客户机和服务器之间交换数据。安全子层使用secureddatattransmit服务来传输/接收安全数据。安全链接必须是点对点通信。因此,只允许物理寻址,这意味着只涉及一个服务器。
  安全子层到应用程序的接口是根据ISO/OSI模型约定的,因此提供了以下四个安全子层(SS_)服务原语
  ——SS_SecuredMode。req:安全子层请求
  ——SS_SecuredMode。ind:安全子层
  ——SS_SecuredMode。resp:安全子层响应
  ——SS_SecuredMode.conf:安全子层确认
  ISO 14229的这一部分定义了已确认和未确认的服务。在安全模式下,只允许已确认的服务(suppressPosRspMsgIndicationBit = FALSE)。基于此要求,以下服务不允许以安全模式执行:
  ——response - onevent (0x86);
  —— ReadDataByPeriodicIdentifier (0x2A);
  ——testpresent (0x3E);
  确认的服务(suppressPosRspMsgIndicationBit = FALSE)使用四个应用层服务原语请求、指示、响应和确认。当以安全模式执行已确认的诊断服务时,它们被映射到四个安全子层服务原语,反之亦然。
  在安全模式下执行诊断服务时,安全子层的任务是对“应用程序”提供的数据进行加密,对“应用层”提供的数据进行解密,并添加、检查和删除与安全相关的数据元素。安全子层使用应用层的SecuredDataTransmission (0x84)服务,根据外部协议(请求和响应)发送和接收整个诊断消息或消息,并以安全方式进行交换。
  安全子层为应用程序提供“SecuredServiceExecution”服务,以确保诊断服务的安全执行。
  “SecuredServiceExecution”服务的安全子层请求和指示原语按照以下通用格式指定:
在这里插入图片描述
  -
  SecuredServiceExecution服务的安全子层响应和确认原语按照以下通用格式指定:
在这里插入图片描述
  -
  安全子层服务原语中显示的寻址信息直接映射到应用层的寻址信息,反之亦然。

9.8.1.3安全子层访问

-
  访问安全子层以执行安全服务的概念类似于本文中描述的应用层接口。安全子层使用应用层服务原语。
  下面以安全方式执行已确认的诊断服务为例。
  ——客户端应用程序使用安全子层SecuredServiceExecution服务请求,以安全的方式执行诊断服务。安全子层执行所需的操作,与服务器建立链接,添加特定的安全相关参数,如果需要,将诊断服务的服务数据以安全方式加密执行,并使用应用层SecuredDataTransmission服务请求将安全数据传输给服务器。
  ——服务器接收应用层secureddatatranssion服务指示,该指示由服务器的安全子层处理。服务器的安全子层检查特定于安全的参数,解密加密的数据,并通过安全子层SecuredServiceExecution服务指示将服务的数据以安全模式呈现给应用程序。应用程序执行服务,并使用安全子层SecuredServiceExecution服务响应以安全模式响应服务。服务器的安全子层添加特定的安全相关参数,根据需要对响应消息数据进行加密,并使用应用层SecuredDataTransmission服务响应将响应数据传输给客户端。
  ——客户端接收一个应用层secureddatatransade服务确认原语,由客户端的安全子层处理。客户端的安全子层检查安全特定参数,解密加密的响应数据,并通过安全子层SecuredServiceExecution确认将数据呈现给应用程序。
  图9以图形方式显示了在安全模式下执行已确认的诊断服务时,安全子层、应用层和应用程序之间的交互。
在这里插入图片描述

图9 -安全子层、应用层和应用程序交互


  重要提示——服务器和客户端应满足7.5中规定的请求和响应消息行为。

9.8.2请求消息

9.8.2.1请求消息定义


  安全子层生成应用层secureddatatranssion请求消息参数。
  表81定义了请求消息。

表81 -请求消息定义

在这里插入图片描述

9.8.2.2请求消息子函数参数$Level (LEV_)的定义

此服务不使用子函数参数。

9.8.2.3请求消息数据参数定义

表82定义了请求消息的数据参数。

表82 -请求消息数据-参数定义
定义
securityDataRequestRecord
该参数包含安全子层处理的数据。

9.8.3肯定响应消息

9.8.3.1肯定响应消息定义

表83定义了肯定响应消息。

表83 -肯定响应消息定义

在这里插入图片描述

9.8.3.2 肯定响应消息数据-参数定义

表84定义了肯定响应消息的数据参数:

表84 -响应消息数据-参数定义
定义
securityDataResponseRecord
该参数包含安全子层处理的数据。

9.8.4支持的负响应码(NRC_)

本服务应执行以下否定响应代码。表85记录了每个响应代码发生的情况。响应代码总是不加加密地发送,即使根据请求A_PDU中的配置文件,响应A_PDU必须加密。如果错误场景适用于服务器,则应使用列出的否定响应。

表85 -支持的否定响应代码

在这里插入图片描述
  说明上述响应码适用于SecuredDataTransmission (0x84)服务。如果在安全模式下执行的诊断服务需要否定响应,则该否定响应将通过secureddatatranssion肯定响应消息以安全模式发送给客户端。

9.9 ControlDTCSetting (0x85)服务

9.9.1服务描述


  客户端应使用ControlDTCSetting服务来停止或恢复服务器中DTC状态位的更新。DTC状态位在ReadDTCInformation的某些子函数的正响应的statusOfDTC参数中报告(位的定义见D.2)。
  ControlDTCSetting请求消息可用于停止更新单个服务器或一组服务器中的DTC状态位。如果被寻址的服务器不能停止DTC状态位的更新,它应该响应一个ControlDTCSetting负响应消息,表明拒绝的原因。
  当服务器接受带有DTCSettingType = off的子函数值的ControlDTCSetting请求时,服务器将暂停对DTC状态位的任何更新(即冻结电流值),直到该功能再次启用。一旦ControlDTCSetting请求被执行,子功能设置为“on”或过渡到不支持ControlDTCSetting的会话(例如,会话层超时到defaultSession, ECU复位等),DTC状态位信息将继续更新。即使请求的DTC设置状态已经激活,如果在活动会话中支持该服务,并且所请求的子功能设置为“开”或“关”,服务器仍应发送肯定响应。
  如果客户端发送ClearDiagnosticInformation (0x14)服务,ControlDTCSetting不应禁止重置服务器的DTC状态位。各个DTC状态位的行为应根据D.2、图D.1 -图D.8中的定义来实现。
  DTC状态位记录了与数字标识符(DTC)相关的某些信息,DTC表示特定的故障状态。ControlDTCSetting只打开/关闭DTC状态位更新。ControlDTCSetting服务不打算关闭故障监控,也不打算禁用故障软策略。不建议将故障软或故障安全策略与DTC状态位直接链接或耦合(例如,接受的ClearDiagnosticInformation请求不会直接移除任何活动的故障软)。
  重要提示——服务器和客户端应满足7.5中规定的请求和响应消息行为。

9.9.2请求消息

9.9.2.1请求消息定义


  表86定义了请求消息。

表86 -请求消息定义

在这里插入图片描述

9.9.2.2请求消息子函数参数$Level (LEV_)的定义

- 
  ControlDTCSetting请求消息使用子函数参数DTCSettingType向服务器指示诊断故障码状态位更新是否应该停止或重新开始(suppressPosRspMsgIndicationBit(位7)未在表87中显示)。

表87 -请求消息子函数参数定义
Bits 6 – 0DescriptionCvtMnemonic
0x00ISOSAEReserved
此值由本文档保留。
MISOSAERESRVD
0x01on
服务器应根据正常运行情况恢复诊断故障码状态位的更新
MON
0x02off
服务器应停止更新诊断故障码状态位。
MOFF
0x03 – 0x3FISOSAEReserved
此值范围由本文档保留,以供将来定义。
MISOSAERESRVD
0x40 – 0x5FvehicleManufacturerSpecific
This range of values is reserved for vehicle manufacturer specific use.
UVMS
0x60 – 0x7EsystemSupplierSpecific
此值范围保留给系统供应商特定使用。
USSS
0x7FISOSAEReserved
本文档保留此值以供将来定义。
MISOSAERESRVD

9.9.2.3请求消息数据参数定义


  表88定义了请求消息的数据参数。

表88 -请求消息数据-参数定义
定义
DTCSettingControlOptionRecord
当控制DTC状态位的更新时,该参数记录是用户可选的,用于向服务器传输数据(例如,它可以包含要打开或关闭的DTC列表)。

9.9.3肯定响应消息

9.9.3.1肯定响应消息定义

表89定义了肯定响应消息。

表89 -肯定响应消息定义

在这里插入图片描述

9.9.3.2肯定响应消息数据参数定义

表90定义了肯定响应消息的数据参数。

表90 -响应消息数据-参数定义

在这里插入图片描述

9.9.4支持的否定响应码(NRC_)

本服务应执行以下否定响应代码。表91记录了每个响应代码发生的情况。如果错误场景适用于服务器,则应使用列出的否定响应。
表91 -支持的否定响应代码

在这里插入图片描述在这里插入图片描述

9.9.5消息流示例ControlDTCSetting

9.9.5.1示例#1—ControlDTCSetting (DTCSettingType = off)

请注意,本示例没有使用服务的功能将附加数据传输到服务器。客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  表92定义了ControlDTCSetting请求消息流示例#1。

表92 - ControlDTCSetting请求消息流示例#1

在这里插入图片描述
表93定义了ControlDTCSetting肯定响应消息流示例#1。

表93 - ControlDTCSetting肯定响应消息流示例#1

在这里插入图片描述

9.9.5.2示例#2—ControlDTCSetting (DTCSettingType = on)

此示例不使用服务的功能将附加数据传输到服务器。客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  表94定义了ControlDTCSetting请求消息流示例#2。

在这里插入图片描述
表95定义了ControlDTCSetting肯定响应消息流示例#2。

表95 - ControlDTCSetting肯定响应消息流示例#2

在这里插入图片描述

9.10 ResponseOnEvent (0x86)服务(未完)

9.10.1服务描述

- 
  ResponseOnEvent服务请求服务器启动或停止对指定事件的响应传输。
  此服务提供了在服务器中发生指定事件时自动执行诊断服务的可能性。客户端指定事件(包括可选事件参数)和事件发生时要执行的服务(包括服务参数)。有关客户机和服务器行为的简要概述,请参见图10。

在这里插入图片描述

图10 - ResponseOnEvent服务-客户端和服务器行为


  上面的图假设,事件窗口计时器被配置为在服务器下电之前超时,因此最终的ResponseOnEvent肯定响应消息显示在事件定时窗口的末尾。
  服务器应在接收时评估ResponseOnEvent请求消息的子函数和数据内容。这包括以下子函数和参数:
  ——eventType。
  ——eventWindowTime,
  —— eventtypeecord (eventTypeParameter #1-#m)。
  如果ResponseOnEvent请求消息中的数据无效,则发送负响应码0x31的负响应。serviceToRespondToRecord不是这个评估的一部分。当指定的事件发生时,将评估serviceToRespondToRecord参数,这将触发serviceToRespondToRecord中包含的服务的执行。在事件发生时,应执行serviceToRespondToRecord(诊断服务请求消息)。如果条件不正确,则应发送带有适当的否定响应代码的否定响应消息。多个事件应按其发生的顺序发出信号。
  适用下列实施细则:
  a) ResponseOnEvent服务可以在任何会话中设置和激活,包括defaultSession。保持ResponseOnEvent服务活动并不一定需要testpresent服务。
  b)如果在诊断服务正在进行时发生指定的事件,这意味着要么正在接收请求消息,要么正在执行请求,要么正在发送响应消息(包括响应代码为0x78的否定响应消息处理)(如果suppressPosRspMsgIndicationBit = FALSE),则serviceToRespondToRecord中包含的请求消息的执行将被推迟,直到正在进行的诊断服务完成。
  说明:在某些情况下,由于ServiceToRespondTo的延迟,可能导致ServiceToRespondTo记录中的数据与引起事件的数据值不一致。
  c)如果多个事件发生,而另一个事件正在进行中,则多个事件的处理(例如,忽略除第一个/最后一个事件或事件的储存之外的所有事件)应由车辆制造商指定。
  d)当满足事件逻辑并在事件时间窗口内生成事件时,服务器执行serviceToRespondToRecord中包含的服务。
  e)一旦ResponseOnEvent服务被ResponseOnEvent请求“start”发起,服务器响应已设置事件逻辑并启动ROE事件的客户端,直到事件窗口时间到期。
  f)一个移动到任何非默认会话的DiagnosticSessionControl请求将停止ResponseOnEvent服务,无论是否激活了与当前会话不同的非默认会话或相同的非默认会话。在返回到DefaultSession时,之前在DefaultSession中激活的所有ResponseOnEvent服务将被重新激活。
  g)多个ResponseOnEvent服务可以并发运行,不同的需求(不同的EventTypes, serviceToRespondToRecords,…)来启动和停止诊断服务。启动和停止子函数应该始终控制所有初始化的ResponseOnEvent服务。
  h)如果已经设置了ResponseOnEvent服务,则应适用以下规定:
    1)如果eventType子函数参数的第6位设置为0(不存储事件),则在服务器下电时事件终止。服务器复位或上电后(即ResponseOnEvent服务终止),服务器将不再继续进行ResponseOnEvent诊断服务。
    2)如果eventType子函数参数第6位设置为1(存储事件),则在服务器上电一个周期后,根据ResponseOnEvent-set恢复发送serviceToRespondTo-responses。因此,StoreEvent只允许与无限的eventWindowTime结合使用。
  i)“suppressposresponsemessageindictionbit”=“yes”应该仅由客户端用于eventType = stopResponseOnEvent, startResponseOnEvent或clearResponseOnEvent。当检测到指定的事件时,服务器应始终返回对事件触发的响应的响应。
  j)服务器应返回ResponseOnEvent“最终”响应(见图15),以指示ResponseOnEvent (0x86)服务,只有当有限的窗口时间被设置和有限的窗口时间已经过去。如果在有限窗口时间过去之前,通过任何方式(例如“stopResponseOnEvent”子函数或更改会话)停止了ROE,则不会发送最终响应。
  k)为了避免干扰正常的诊断操作,建议实现ResponseOnEvent服务,只应用于瞬态事件和条件。服务器应该在每次事件发生时返回一个响应。对于持续一段时间的情况,响应服务应在初始发生时只执行一次。如果eventType被定义为serviceToRespondTo-responses可以以高频率发生,那么必须采取适当的措施来防止背对背的serviceToRespondTo-responses。serviceToRespondTo-responses之间的最小间隔时间可以是eventTypeRecord(特定于汽车制造商)的一部分。
  建议仅使用表96中列出的服务,以便在发生指定事件时执行服务。(serviceToRespondToRecord请求服务标识)。

表96 -与ResponseOnEvent服务一起使用的推荐服务

在这里插入图片描述


  ——出于性能原因(例如,避免错过serviceToRespondToRecord请求服务标识符的执行),建议遵循以下建议:
DID可能包含可测量的数据(例如,避免定义事件逻辑读取常数“校准”标签)
  ——serviceToRespondToRecord阳性响应可能仅限于汽车制造商的特定值
  重要提示——服务器和客户端应满足7.5中规定的请求和响应消息行为。

9.10.2请求消息

9.10.2.1请求消息定义

表97定义了请求消息。
表97 -请求消息定义
在这里插入图片描述
C1:如果eventType需要为要响应的事件指定额外的参数,则出现。
C2:当子函数参数不等于reportActivatedEvents、stopResponseOnEvent、startResponseOnEvent、ClearResponseOnEvent时,必须出现
C3:如果要响应的服务的服务请求需要额外的服务参数,则出现

9.10.2.2请求消息子函数参数$Level (LEV_)定义

9.10.2.2.1 ResponseOnEvent请求消息子函数参数定义


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

表98 - eventType子函数第6位定义- storageState
Bit 6 valueDescriptionCvtMnemonic
0x00doNotStoreEvent
该值表示当服务器掉电时事件将终止,并且服务器在复位或上电后(即ResponseOnEvent服务终止)将不再继续ResponseOnEvent诊断服务。
MDNSE
0x01storeEvent
此值表示
1)对于默认会话中的ROE启动或停止请求,该事件应在复位或上电(即ResponseOnEvent服务恢复)后根据ResponseOnEvent-set恢复或停止发送serviceToRespondTo-responses。
2)对于任何ROE设置事件逻辑请求,所请求的事件逻辑应被持久存储,直到事件逻辑被显式清除(通过clearResponseOnEvent)或事件逻辑被相同类别的新ROE设置事件逻辑请求覆盖。
USE

表99定义了请求消息子函数参数。

表99 -请求消息子函数参数定义
Bits 5 - 0ValueDescriptionCvtType ofROE sub-functionMnemonic
0x00stopResponseOnEvent
此值用于在事件发生时停止服务器发送响应。已设置的事件逻辑不会被清除,但可以使用startResponseOnEvent子函数参数重新启动。
eventTypeRecord长度:0字节
UcontrolSTPROE
0x01onDTCStatusChange
该值将该事件标识为检测到的与为此事件指定的DTCStatusMask匹配的新DTC。
eventTypeRecord长度:1字节
实现提示:服务器驻留DTC计数算法应以一定的周期速率(例如大约1秒)计算满足客户端定义的DTCStatusMask的DTC数。如果计数与之前执行时计算的计数不同,则客户端应生成导致serviceToRespondTo执行的事件。
然后将最新的计数存储为下一次计算的参考。
此事件类型需要在请求消息(eventTypeParameter#1)中指定DTCStatusMask。
UsetupONDTCS
0x02onTimerInterrupt
该值将事件标识为计时器中断,但计时器及其值不是ResponseOnEvent服务的一部分。
此事件类型需要在请求消息(eventTypeRecord)中指定更多细节。
eventTypeRecord长度:1字节
UsetupOTI
0x03onChangeOfDataIdentifier
该值将事件标识为由dataIdentifier标识的新的内部数据记录。数据值是特定于汽车制造商的。
此事件类型需要在请求消息(eventTypeRecord)中指定更多细节。
eventTypeRecord长度:2字节
UsetupOCODID
0x04reportActivatedEvents
此值用于指示在正向响应中报告所有已在服务器中使用ResponseOnEvent服务激活的事件(并且当前处于活动状态)。
eventTypeRecord长度:0字节
UcontrolRAE
0x05startResponseOnEvent
该值用于指示服务器激活已设置的事件逻辑(包括事件窗口计时器),并开始在事件上发送响应.
eventTypeRecord长度:0字节。
McontrolSTRTROE
0x06clearResponseOnEvent
此值用于清除服务器中已设置的事件逻辑(这也会阻止服务器发送事件响应)。
eventTypeRecord长度:0字节。
UcontrolCLRROE
0x07onComparisonOfValues
由数据标识符标识的特定记录中数据值的定义更改,该数据标识符标识数据值事件。有了这一子功能,用户应能够在从已定义的测量值比较中收集的特定结果发生时定义一个事件。分配给定义的数据标识符的数据记录中包含的特定测量值与给定的比较值进行比较。指定的运算符定义比较的类型。如果比较结果为正,则发生该事件。
eventTypeRecord长度:10字节
UsetupOCOV
0x08 – 0x1FISOSAEReserved
此值范围由本文档保留,以供将来定义。
M-ISOSAERESRVD
0x20 – 0x2FVehicleManufacturerSpecific
此值范围保留给特定的汽车制造商使用。
UsetupVMS
0x30 – 0x3ESystemSupplierSpecific
此值范围保留给系统供应商特定使用
UsetupSSS
0x3FISOSAEReserved
本文档保留此值以供将来定义。
M-ISOSAERESRVD
9.10.2.2.2请求消息子函数onTimerInterrupt详细参数规范

-
  通过子函数onTimerInterrupt,允许服务器在一个定时器可配置的时间段内触发事件。
eventTypeRecord用以下定时器时间表定义定时器值:
  ——慢速,
  ——中等速率,
  ——速度快。
  定义与每个计时器计划选项相关联的时间率是制造商的特定任务。参见表100。

表100 -比较逻辑参数定义
eventTypeRecord事件将被生成计时器类型
0x01每次慢速计时器值失效时。慢速定时器。例如,计时器在1秒后结束
0x02每次中速率计时器结束。中速率定时器。例如,计时器在300毫秒后结束
0x03每次快速率计时器结束。快速率定时器。例如,计时器在25毫秒后结束
9.10.2.2.3详细请求消息子函数onChangeOfDataIdentifier参数规范

使用onChangeOfDataIdentifier子函数,服务器可以在固定的时间段内轮询度量并比较内容,因此服务器可能丢失一些更改并触发比预期更少的事件是可以接受的。
  eventTypeRecord设置两个字节的DID值,必须对其进行监视以防止任何更改。

9.10.2.2.4详细请求消息子函数onComparisonOfValues参数规范

表101 -表103指定了在serviceToRespondToRecord指定读did之间比较的情况下,使用子函数onComparisonOfValues参数的请求消息的参数。

表101 -子函数onComparisonOfValues参数定义
Data ByteParameterNameByte ValueCommentDetailed requirement
1ServiceID0x86Request SID
2eventType0x07sub-function
onComparisonOfValues
3eventWindowTime0x02InfiniteTimeWindow
specification
4eventTypeRecord
byte1
0x01DataIdentifier (DID)
high byte
可以是不同于serviceToRespondToRecord中使用的DID。可以是动态定义的DID。
5eventTypeRecord
byte 2
0x04DataIdentifier (DID) low
byte
6eventTypeRecord
byte 3
0x01
7eventTypeRecord
byte4
0x00
8eventTypeRecord
byte 5
0x00
9eventTypeRecord
byte 6
0x01
10eventTypeRecord
byte 7
0x00
11eventTypeRecord
byte 8
0x0A
12eventTypeRecord
byte 9
0xBC
13eventTypeRecord
byte 10
0x58
14eventTypeRecordTo
byte 1
0x22
15eventTypeRecordTo
byte 2
0xA1
16eventTypeRecordTo
byte 3
0x00
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
USD(Unified Diagnostic Services)和AUTOSAR(Automotive Open System Architecture)都是汽车电子系统中的关键组件,但它们关注的领域不同。 USD是通用诊断接口标准,它定义了车辆电子系统如何进行统一的诊断和故障信息交换。USD提供了一种标准化的方式来访问车辆的不同电子模块,这样维修人员可以通过统一的协议获取到车辆的实时诊断数据和历史故障记录。USD有助于简化维修流程,提高效率,并增强车辆的安全性和可靠性。 AUTOSAR则是汽车行业的开放架构规范,主要用于设计和开发车载电子控制单元(ECU)。它定义了软件、硬件和网络接口的结构,使得不同供应商之间的ECUs能够互相通信和协作。AUTOSAR包含多个子层,其中就包括诊断功能,这部分关注的是系统内各个模块的健康监控和故障管理,确保系统的可靠运行。 两者的区别在于: 1. USD是一个具体的诊断接口标准,专注于通信和数据共享,而AUTOSAR更广泛,是整个系统架构的一部分。 2. USD适用于所有类型的车辆电子系统,而AUTOSAR专注于汽车电子控制系统的开发。 3. USD主要关注的是故障信息的呈现和交互,而AUTOSAR的诊断功能是在更大的系统集成背景下运作的。 相关问题: 1. USD在汽车诊断中的作用是什么? 2. AUTOSAR诊断子系统如何支持车辆的故障管理和维护? 3. 在一个AUTOSAR架构中,如何通过USD实现ECU间的诊断信息共享?

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值