全部学习汇总： https://github.com/GreyZhang/hack_autosar
继续学习AUTOSAR，看一下官方文档。
6 诊断事件处理
6.1 简介
本子章节描述了定义诊断事件处理和功能的元模型元素。
在标准的 AUTOSAR 基础软件架构中，基于本子章节中描述的模型元素的定义由诊断事件管理器 (Dem) 模块实现。
上图概述了与诊断事件功能相关的模型元素。
对于诊断事件功能的定义，从 DiagnosticCommonElement 派生了许多模型元素。 这些元素在以下子章节中进行了描述。
6.2 诊断事件
诊断事件的语义
诊断事件是由 Dem 模块处理的原子单元 - 必须与其属性一起定义，这些属性会影响事件处理行为和软件组件的可能接口。
图 6.2 描述了 DiagnosticEvent 的定义及其属性。
图 6.2：DiagnosticEvent 的建模
DiagnosticExtract 允许定义任意数量的 DiagnosticEvent。
尽管公司之间的 DiagnosticExtract 交换通常涉及与 SWC 功能相关的诊断事件，但也支持事件类型 BSW 以启用 BSW 事件处理的定义（例如，关联的 DiagnosticTroubleCode 的定义）。
清除诊断事件的请求
此外，对诊断事件的清除请求可能需要调用对 SWC 的回调，以便允许或禁止清除操作。
可以使用属性 eventClearAllowed 表达对该回调接口的期望：
• always表示应无条件执行对 DiagnosticEvent 的清除请求。
• never 表示有意不可能清除DiagnosticEvent。
• 在requiresCallbackExecution 的情况下，回调的执行将决定是否允许清除。
换句话说，这个决定的实现取决于相应 AtomicSwComponentType 的开发者。
后者应定义具有适当的 DiagnosticEventNeeds 和 RoleBasedPortAssignment 的 SwcServiceDependency，其中属性 role 的值设置为 CallbackClearEventAllowed。
此元素用于配置诊断事件。
诊断事件可以连接一个或多个指示器
一个 DiagnosticEvent 可以连接到一个或多个特定类型和特定行为的指标（通过在角色 connectedIndicator 中聚合 DiagnosticIndicator 建模）。
附加到诊断事件的文本内容
诊断事件的定义还包括在结构上形式化但在内容上不能形式化的文本表述的内容。
此内容的目的是定义诸如与特定诊断事件相关的成熟条件。
关于诊断事件的文字描述
具有与诊断事件相关的要求特征的文本描述应通过元类 StructuredReq 提供，即通过 Introduction.structuredReq。
有关半正式文本建模的更多详细信息，请参阅图 4.3。
DiagnosticEvent.introduction.structuredReq 的标准化值
DiagnosticEvent.introduction.struturedReq 的上面可能值由 AUTOSAR 标准化，么开一条不再单独去梳理了。主要是条件、类型、速率、去成熟条件、老化、跛行、成熟时间、去成熟时间。
上面 ARXML 片段举例说明了 StructuredReq 的用法以及属性类别的标准化值，以将半正式文本描述附加到 DiagnosticEvent。
清单 6.1：DiagnosticEvent 上下文中半正式文本元素的定义示例。
每个诊断事件定义的指标的描述。
表示是否允许清除事件。
清除事件的可能行为。
诊断事件的适用性。
指标的行为。
6.3 DiagnosticTroubleCode
DiagnosticTroubleCodes（即诊断事件的 ECU 外部视图）与其属性一起定义，并使用 DiagnosticEventToTroubleCodeUdsMapping 映射到 DiagnosticEvents。
小结：这个应该就是DFC与FID关联的一个对等描述？
三种 DTC
有三种 DTC 表示为 DiagnosticTroubleCode 的特化：
• 非 OBD 相关 DTC (DiagnosticTroubleCodeUds)
• OBD 相关 DTC (DiagnosticTroubleCodeObd)
• J1939 [17] 相关 DTC (DiagnosticTroubleCodeJ1939)
此类 DTC 专业化的特性分别建模为 DiagnosticTroubleCodeUds、DiagnosticTroubleCodeObd 和 DiagnosticTroubleCodeJ1939 的属性。
图 6.4：DiagnosticTroubleCodeUds 的建模
DTC 的共同属性
通常对一组 DiagnosticTroubleCodeUds 元素通用的属性被建模为 DiagnosticTroubleCodeProps 的属性。
udsDtcValue 的值应该是唯一的
udsDtcValue 的值对于任何其他 DTC 和 DTC 组值应该是唯一的。
诊断故障代码定义了显示给诊断测试仪的唯一标识符。
DiagnosticTroubleCodeGroup 的语义
DiagnosticTroubleCodeGroup 元素用于定义属于一起的 DTC 组。 每个 DiagnosticTroubleCodeGroup 都分配有自己的 groupNumber 值。
DiagnosticTroubleCodeGroup 元素用于定义属于一起的 DTC 组。 每个 DiagnosticTroubleCodeGroup 都分配有自己的 groupNumber 值。
DiagnosticTroubleCodeGroup.groupNumber 的值应是唯一的
DiagnosticTroubleCodeGroup.groupNumber 的值对于任何其他 DTC 和 DTC 组值应该是唯一的。
DiagnosticTroubleCodeGroup.groupNumber 的值
为了符合 ISO，DiagnosticTroubleCodeGroup.groupNumber 的值应按照 ISO 14229-1 [15] 中的定义进行设置。
ISO 14229-1 保留了 DiagnosticTroubleCodeGroup.groupNumber 的值
[constr_1351] 中提到的值以外的任何值都由 ISO 14229-1 [15] 保留。
maxNumberFreezeFrameRecords 与 freezeFrame 的存在
如果属性 DiagnosticTroubleCodeProps.maxNumberFreezeFrameRecords 存在，则属性 DiagnosticTroubleCodeProps.freezeFrame 不应存在，反之亦然。
[constr_1352] 的适用性
[constr_1352] 应以相同的方式（一个或另一个属性应存在）应用于引用同一 EcuInstance 的类别为 DIAGNOSTIC_ECU_EXTRACT 的所有 DiagnosticContributionSet 上下文中的所有 DiagnosticTroubleCodeProps。
存在属性 DiagnosticTroubleCodeProps.freezeFrameConten
如果存在 DiagnosticTroubleCodeProps.maxNumberFreezeFrameRecords 或 DiagnosticTroubleCodeProps.freezeFrame 属性之一，则属性 DiagnosticTroubleCodeProps.freezeFrameContent 应存在。
附加到 DiagnosticTroubleCode 的文本内容
DiagnosticTroubleCode 的定义还包括在结构上形式化但在内容上不能形式化的文本表述的内容。
此内容的目的是定义例如错误文本或与特定 DiagnosticTroubleCode 相关的可能原因。
提供附加到 DiagnosticTroubleCode 的半正式文本内容的不同方法
有不同的方法来提供附加到 DiagnosticTroubleCode 的半正式文本内容：
• 具有 DiagnosticTroubleCode 描述特征的文本描述应通过元类 TraceableText 提供，即通过 Introduction.trace。
• 应通过属性 longName 提供描述与 ODX 长名称相关的 DiagnosticTroubleCode 特征的文本描述。
有关半正式文本建模的更多详细信息，请参阅图 4.3。
单独使用 TraceableText 和 StructuredReq 不能作为半正式的文本附件。 有必要对类别的值进行标准化，以获得某种程度的半正式文本描述。
这部分主要是诊断时间处理的部分简介，加上诊断事件的描述，带有一部分DTC的相关的内容，但是DTC相关的信息比较多，一次没能看完，后面再进行补充。
