AUTOSAR DEM （三）:故障事件及故障错误码定义

故障事件定义

在 Autosar 中，诊断事件是指在车辆电子系统中发生的特定事件，可以用于诊断和故障排除。

DEM模块通过EventId和相关的EventName来表示每个诊断事件。诊断事件的状态代表了监控器的结果，DEM模块通过RTE或其他BSW模块从SW-C接收监控器的结果。DEM模块使用EventId来管理系统中每个诊断事件的状态，并对各个测试结果执行所需的操作，例如存储冻结帧/拓展帧。

所有监控器和BSW模块使用EventId作为符号化的EventName来管理诊断事件。
每个DEM模块的EventId和相关的EventName在ECU配置中必须是唯一的。DEM模块无法处理多个监控器共享一个EventId的情况。
DEM模块使用内部的监控器状态来存储报告事件的状态并向Dcm模块报告UDS状态。

Event priority

事件优先级定义为根据重要性级别对事件进行排名。
它用于确定在存储的事件数超过最大内存条目数（事件内存已满）的情况下，可以从事件内存中删除哪些故障条目，也可以说将哪些低优先级的故障条目替换出来。

Event occurrence

DEM模块为每一个event提供了一个occurrence counter。
如果配置参数DemOccurrenceCounterProcessing设置为DEM_PROCESS_OCCCTR_TF(发生计数只会由TestFailed位触发)，如果上报事件对应的UDS状态位0（TestFailed）从0转换为1，则occurrence counter加1。如果相关事件已经存储在事件存储器中，并且UDS状态位3等于1，则Dem模块应将发生计数器增加一。
如果occurrence counter 已达到最大值255， Dem模块不应增加特定事件的发生计数器。

Event kind

dem模块有两种不同类型的事件：
  BSW相关事件（通过API报告-Dem_SetEventStatus）
  SW-C相关事件（通过RTE操作-SetEventStatus报告）
事件类型可配置

Event destination

Permanent Event Memory（PEM）是DEM的一个重要组成部分。PEM用于存储和管理持久性的诊断事件，这些事件在车辆的整个生命周期中都是可用的。PEM中存储的事件可以是故障码、警告码或其他类型的诊断事件。

“PEM(Permanent Event Memory)”赋值是隐式地从相关的DTC 类派生出来的。与排放相关的事件被自动分配到 PEM，因为作为“永久DTC”的事件存储是动态地从其当前状态派生出来的。在此上下文中，术语“永久”与排放相关事件 的属性相关，而不仅仅与通过NvM进行的持久存储相关，NvM是针对每个事件 内存类型进行的
配置参数定义了事件及其相关数据的专用存储位置。

“永久性事件存储器”的分配是从相关DTC类型中隐含得出的。排放相关事件自动分配到永久性事件记忆中，因为将事件存储为“永久性DTC”是从其当前状态中动态得出的。

对于Dcm-Dem接口，DTCOrigin参数用于区分不同的内存区域。其目的是允许对不同的 内存区域(主内存、用户定义内存、永久内存和镜像内存)进行特定操作。

Diagnostic monitor

Diagnostic monitor（诊断监控器）是一种模块或组件，用于监测车辆系统的状态和性能，并生成相应的诊断事件。它负责实时监测各种传感器、执行器和系统组件的运行状况，以便及时检测和报告任何故障或问题。它可以通过与车辆系统中的其他模块和组件进行通信，获取各种状态和参数信息。
该监测功能识别监测路径的特定故障类型（例如，对地短路、开路负载等）。监控路径表示被监控的物理系统或电路（例如传感器输入）。每个监测路径只与一个诊断事件相关联。

如果监视器自己启动，则只有在获得合格的 结果(通过或失败)后才调用report API。如果结果发生变化，报告是必要的。
通常情况下，监视器调用 Dem在计算上更有效率，应该首选。因此， Dem处理未改变结果的报告是特定于实现的。
如果监视器使用了dem内部的debounce机制，那么每当执行带有功能检查的代码时，就会调用report API。

Event dependencies

Event dependencies（事件依赖关系）是指诊断事件之间的关联和依赖关系。在车辆系统中，不同的诊断事件之间可能存在一定的依赖关系，即一个事件的发生可能会触发或影响其他事件的发生。

Event dependencies可以帮助DEM在处理诊断事件时，更准确地确定事件的原因和影响。它可以帮助DEM识别和追踪事件之间的关联性，从而更好地理解车辆系统的整体状态和性能。

Event dependencies可以通过定义适当的规则和条件来实现。这些规则和条件可以基于车辆系统的特定要求和逻辑关系进行配置和定义。例如，如果某个传感器故障，可能会导致多个相关的诊断事件被触发。通过定义事件之间的依赖关系，DEM可以更好地处理和报告这些相关的诊断事件。

指定的DemComponent中的事件优先级以及DemComponent之间的依赖关系 用于过滤错误存储报告到故障内存。

• 当一个事件报告为FAILED时，如果同一DemComponent上具有更高优先级的其他事件 已经为FAILED，则该事件应被视为 连续故障。
• 当一个事件报告FAILED时，如果任何父组件为FAILED，则该事件应被视为连续故障。
• Dem应允许忽略Dem事件的优先级( ComponentIgnoresPriority)。在这种情况下，如果任何父组件为FAILED，则该事件应被视为连续故障(同一组件上的其他事件FAILED状态将被忽略)。
• 如果报告的故障不被视为连续故障，则应被视为因果故障。因果故障应正常处理。
• 如果报告的故障不被认为是连续故障 ，并且已经配置了DemCausalityDelayTime，则将其视为初步因果故障。从事件报告发生的时间点开始，直到DemCausalityDelayTime过去，该事件可以重新考虑为连续故障。如果在此期间在同一DemComponent或任何父DemComponent上报告了另一个具有更高优先级的故障 ，则该事件应被重新视为连续故障。时间过去后，将不会重新考虑失败。
• 被认为是连续故障的故障不应 存储到故障存储器中。
• 报告DEM_EVENT_STATUS_FDC_THRESHOLD_REACHED (例如:无论是通过接口调用还是达到debounce( 算法中配置的阈值)，这被认为是失败事件的连续报告，不应存储到失败存储器中。处理应类似于未 满足的存储条件。
• Dem应提供 Dem_GetComponentFailed接口，用于查询DemComponents FAILED 状态。
• 如果启用了DemTriggerFiMReports， 在每次DemComponent失败状态发生变化时，Dem应通过调用DemTriggerOnComponentStatus函数通知FiM模块。
• 如果组件状态发生变化，且配置了DemComponent- FailedCallbackFnc或DemComponentFailedCallbackUsePort 为TRUE，则Dem触发回调DemTriggerOnComponentStatus。
• DemComponentFailedCallbackUsePort 只有在没有配置DemComponentFailedCallbackFnc的情况下才允许设置为TRUE。

Component availability

Component availability（组件可用性）是指车辆系统中各个组件的可用性和状态。每个组件都有其特定的功能和任务，它们负责监测和控制车辆的不同系统和子系统。
它可以帮助DEM判断各个组件是否正常工作，并根据其可用性和状态来生成相应的诊断事件。如果某个组件不可用或处于异常状态，DEM可以生成相应的故障码或警告信息，并将其发送到适当的Event destination进行处理和报告。

组件可用性可以通过与各个组件进行通信和监测来实现。DEM可以定期检查各个组件的状态和可用性，并根据预定义的规则和条件判断其是否正常工作。这种监测和检查可以通过AUTOSAR中的服务接口或其他通信机制进行。通过实时监测和报告组件的可用性，DEM可以帮助车辆制造商和维修人员及时发现和解决问题，提高车辆的可靠性和性能。

Dem应支持DemComponent的可用性。不可用的组件被视为不包括在系统。

• Dem_SetComponentAvailable接口应该可用 来设置组件的可用状态。
• 通过将DemComponent设置为not available，所有分配的事件也应该设置为not available。
• 启动后，所有DemComponents都可用。
• 如果通过 Dem_SetComponentAvailable将DemComponent设置为“不可用”，则Dem应将所有依赖组件 (子组件)视为设置为“不可用”。
• 如果通过 Dem_SetComponentAvailable将DemComponent设置为’ not available ‘，则Dem应将所有分配的事件设置为’ not available '，包括所有子节点的事件。事件的行为将类似于将每个事件单独设置为“不可用”(例如设置事件状态)。
• 如果通过 Dem_SetComponentAvailable将DemComponent设置为’ not available ‘，并且分配给它的任何单个事件已经失败，则单个事件将保持为’ available '。Dem_SetComponentAvailable仍然会返回E_OK。
• 如果通过 Dem_SetComponentAvailable将DemComponent设置为available，则所有分配的事件也将设置为’ available ‘， 包括所有子节点的事件(如果这些节点尚未设置为’ not available ')。单个事件的行为类似于将它们单独设置为 'available '(例如触发InitMonitorForEvent)。
• 如果为一个事件调用Dem_SetEventAvailable函数将该事件设置为’ available ‘，如果其相关的节点当前为’ not available '，则该函数将返回E_NOT_OK。
• 如果使用Dem_SetEventAvailable 将一个事件设置为可用，并且它的组件是’不可用’，Dem_SetEventAvailable将返回 E_NOT_OK.

故障诊断码定义

“诊断故障代码”定义了一个唯一标识符(显示给诊断测试人员) 映射到Dem模块的“诊断事件”。Dem向Dcm模块提供 “诊断故障代码”的状态。

DTC format

DTC有两种类型：

• 与OBD无关的DTC（Unified Diagnostic Services Diagnostic Trouble Codes）
• OBD-相关DTCs (On-Board Diagnostics Diagnostic Trouble Code)
  这种类型是从demDTCattributes配置隐式派生的。如果存在 DemObdDTC参数，则表示该DTC及相关事件均与obd相关。

Dem模块应支持的DTC格式：

• ISO-14229-1：Road vehicles – Unified diagnostic services (UDS) – Part 1: Specification and requirements
• SAE J2012 OBD DTC (aka 2-byte DTC)：Diagnostic Trouble Code Definitions for OBD-II Vehicles
• SAE J1939-73：Application Layer - Diagnostics
• ISO 11992-4：Road vehicles – Interchange of digital information on electrical connections between towing and towed vehicles – Part 4: Diagnostic communication
• SAE J2012 WWH-OBD DTC (aka 3-byte DTC)：World-Wide Harmonized On-Board Diagnostic (WWH-OBD) Fault Codes for OBD-II Vehicles
  上述为ECU的中定义的支持的DTC格式。这些 要为ISO-14229-1服务报告的DTC格式值 。
  DTC可以是三种格式(UDS、OBD和J1939)的任意组合，即 一种、两种或三种格式同时使用。因此，Dem将在内部处理三个DTC值列表。report的格式取决于Dem_DTCFormatType或 由相关API的上下文定义。

DTCFormatType

• DEM_DTC_FORMAT_OBD 0
• DEM_DTC_FORMAT_UDS 1
• DEM_DTC_FORMAT_J1939 2

• Dem应报告DTC值为字节0 = LowByte，字节1 = MiddleByte，字节2 = HighByte，字节3未使用的uint32。对于OBD DTC 格式，只使用两个字节(HighByte, LowByte)。Dem service 应将这些dtc报告为一个uint32，其中字节1 = LowByte，字节2 = HighByte，字节3 未使用，字节0 = 0x00。
  
• Dem应将DTC值报告为字节0 = Low- byte，字节1 = MiddleByte，字节2 = HighByte，字节3未使用的uint32。对于whh - obd DTC格式，只使用三个字节(HighByte, MiddleByte和LowByte)。 Dem服务将这些dtc报告为一个uint32，其中字节1 = LowByte，字节2 = HighByte，字节0用作FTB(Failure Type Byte)。
• 当DemOBDSupport(此配置开关定义OBD支持和OBD ECU类型)设置为 DEM_OBD_MASTER_ECU(Kind of OBD ECU)或DEM_OBD_PRIMARY_ECU时，OBD DTC DemDtcValue才会出现。
• Dem_GetDTCOfEvent函数将获得DTC，该DTC通过Dem配置 映射到EventId。

DTC Groups

除了单个DTC值外，还可以配置DTC组，详细定义见ISO 14229-1[2] -附件D.1所定义。
每个DTC组都分配了自己的 DTC组值(该值必须与任何其他DTC和DTC 组值唯一)。
当请求对DTC组(如ClearDTC和Disable/ Enable DTC)进行操作时，DTCGroup由DTC值选择。

• DemGroupOfDTC代表DTC 组边界值。
• 在所请求的 group DTC code和下一个dtcgroup之间的所有dtc应被视为属于该组。
• DTC组与ClearDiagnosticInformation (0x14)以及ControlDTCSetting (0x85)相关。
• DEM提供以下DTC group

•   ' all DTC ' DTC组(必选，固定值= 0xFFFFFF)
  

•   WWH-OBD的Emission相关dtc (0xFFFF33)
  

• DTC组’ all DTC '将不会在DemGroupOfDTC中配置，它是由Dem模块提供的。

DTC Severity

DTC severity是根据诊断事件对车辆功能和安全性的影响程度来确定的。它可以帮助车辆制造商和维修人员对诊断事件进行分类和优先级排序，以便更好地处理和解决问题。
根据ISO-14229-1[2]，附件D.3“DTC严重程度和等级定义”，DTC严重程度用于提供有关特定事件重要性的信息。DemDTCSeverity仅对UDS dtc有效。

• 如果调用API Dem_GetSeverityOfDTC或 Dem_GetNextFilteredDTCAndSeverity，并且为所选的DTC 配置了DemDTCSeverity中的严重性值，则Dem应将DemDTCSeverity中配置的值 设置为DTCSeverity。
• 如果调用API Dem_GetSeverityOfDTC或 Dem_GetNextFilteredDTCAndSeverity，并且对于所选的 DTC没有配置DemDTCSeverity中的严重性值，则Dem应将 DEM_SEVERITY_NO_SEVERITY设置为DTCSeverity。
• DEM servity取决于汽车制造商，如果没有配置，则以“no severity”计数。如果没有DTC配置参数，则Dem不提供DTC严重程度信息。

AutoSar DEM Severity：

• DEM_SEVERITY_CHECK_AT_NEXT_HALT
• DEM_SEVERITY_CHECK_IMMEDIATELY
• DEM_SEVERITY_MAINTENANCE_ONLY
• DEM_SEVERITY_NO_SEVERITY

Functional unit

Functional Unit（功能单元）是指车辆电子系统中的一个独立模块或组件，它具有特定的功能和任务。

Functional Unit可以是车辆中的任何电子控制单元（ECU），例如发动机控制单元、制动控制单元、底盘控制单元等。每个Functional Unit都有其特定的功能和任务，它们负责监测和控制车辆的不同系统和子系统。

每个Functional Unit都与一个或多个DTC（Diagnostic Trouble Code）相关联。当Functional Unit检测到故障或问题时，它会生成相应的诊断事件，并将其报告给DEM。DEM会根据诊断事件的严重程度（DTC severity）和优先级进行处理和管理。

Functional Unit可以通过AUTOSAR中的服务接口与DEM进行通信，以发送诊断事件和接收DEM的指令和请求。这种通信可以是基于AUTOSAR标准的CAN（Controller Area Network）总线或其他通信协议。

DTC significance

DTC significance指的是故障代码的重要性或严重程度。它用于确定故障代码在诊断系统中的处理和显示方式。不同的DTC significance级别表示了不同的故障严重程度，可以用于区分和优先处理故障。

根据AutoSar，DTC significance级别通常分为以下几种：

• fault:：对故障进行分类，这与组件/ECU本身有关(并且需要 例如修复操作)。。
• occurrence:：对一个问题进行分类，该问题指出了有关系统行为不足的附加信息(并且与例如 ECU控制之外的条件相关)。

一般来讲DTC significance级别通常分为以下几种：

• 无意义（Not significant）：表示该故障代码不会引起车辆性能下降或安全风险，可以被忽略。
• 一般（General）：表示该故障代码可能会引起车辆性能下降或轻微的安全风险，需要进行诊断和修复。
• 严重（Serious）：表示该故障代码可能会引起严重的车辆性能下降或安全风险，需要立即进行诊断和修复。

Suppress DTC output

Suppress DTC output是一种配置选项(配置参数：DemSuppressionSupport)，用于控制是否屏蔽（Suppress）特定的DTC输出。
当配置了Suppress DTC output时，诊断系统将不会将特定的DTC输出到诊断接口或诊断工具中。这种配置选项通常用于屏蔽一些不重要或不需要显示的DTC，以减少诊断信息的冗余和干扰。

通过配置Suppress DTC output，可以实现以下几个目的：

• 减少诊断信息的冗余：对于一些不重要的DTC，可以选择屏蔽输出，以减少诊断信息的冗余，提高诊断系统的效率。
• 降低诊断工具的负担：对于一些不需要显示的DTC，屏蔽输出可以减少诊断工具的负担，提高诊断工具的性能和响应速度。
• 提高诊断信息的可读性：屏蔽一些不需要显示的DTC可以使诊断信息更加清晰和易读，减少用户的困惑和误解。

被抑制的DTC的行为方式对测试人员是不可见的，但可以由诊断监视器连续处理。

• 如果该DTC的所有相关事件 不可用，则DTC应被禁用。
• 关于输出和查询功能，被抑制的dtc被视为 未在系统中配置。
• 被抑制DTC查询函数的行为在 的情况下，以下任何api Dem_GetStatusOfDTC, Dem_GetSeverityOfDTC, Dem_GetFunctionalUnitOfDTC, Dem_ClearDTC 在被抑制的DTC上，Dem将返回 DEM_WRONG_DTC。
• 对于以下Dcm 查询函数，抑制的DTC将不可见; 因此，以下函数应将DTC视为过滤器不匹配:
  
  
• DTC抑制不得停止相应DTC的事件处理, 事件鉴定，环境数据更新和功能抑制仍然在Dem中处理(如果DTC/冻结帧不应存储在故障存储器中，则应另外使用 存储条件)
• 如果调用 Dem_GetDTCSuppression，则Dem应在输出参数SuppressionStatus中返回DTC抑制状态。SuppressionStatus = TRUE表示 DTC被抑制, FALSE值表示DTC当前没有抑制。

Availability of events (visibility and computation)

Availability of events (visibility and computation)指的是事件的可见性和计算可用性。事件的可见性是指事件是否能够被正确地检测和识别，以及是否能够被相关的系统和组件观察到。事件的计算可用性是指事件是否能够被正确地处理和计算，以产生相应的结果或响应。

在诊断系统中，事件的可见性和计算可用性非常重要。如果事件的可见性和计算可用性存在问题，可能会导致系统无法准确地监测和诊断故障，或者无法及时采取适当的措施进行修复。

事件的可见性和计算可用性受到事件依赖关系的影响。事件依赖关系是指事件之间的相互关系和依赖，包括事件的产生、传递、处理和响应等过程。事件依赖关系可以影响事件的可见性和计算可用性，因为它们决定了事件的传递路径、处理顺序和结果反馈等。

为了确保事件的可见性和计算可用性，诊断系统需要正确地建立和管理事件之间的依赖关系。这包括定义和配置事件之间的依赖关系，确保事件的传递和处理按照预期进行，并及时处理和反馈事件的结果。通过正确地管理事件的依赖关系，诊断系统可以提高事件的可见性和计算可用性，从而提高系统的监测和诊断能力，确保车辆的安全性和可靠性.