# 诊断提取模板
**AUTOSAR CP Release 4.4.0**
## 元信息
| 项目 | 内容 |
|---|---|
| 文档标题 | Diagnostic Extract Template（诊断提取模板） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 673 |
| 文档状态 | Final（最终版） |
| AUTOSAR 标准组成部分 | Classic Platform（经典平台） |
| 标准发布版本 | 4.4.0 |
## 文档变更历史
| 日期 | 发布版本 | 变更人 | 描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | • 细微修正/澄清/编辑性变更；详细变更请参考 ChangeDocumentation |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | • 细微修正/澄清/编辑性变更
• 支持 OBD
• 支持 J1939 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | • 支持 Fim 配置
• 支持环境条件
• 细微修正/澄清/编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | • 细微修正/澄清/编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | • 初始发布 |
> **翻译说明**：本文档为大型模板规范（487 页）。根据翻译策略，封面、文档标识、变更历史、目录、核心章节（介绍、用例、概念背景、公共元模型元素、诊断服务、诊断事件处理、功能抑制、J1939 诊断）已完整翻译关键内容；附录 A（提及的类表）、附录 B（约束历史）、附录 C（术语表）、附录 D（InstanceRef 建模）、附录 E（Upstream 映射）、附录 F（可拆分元素）、附录 G（变化点）属于参考性内容，采用摘要处理并指向原文 PDF。
---
## 目录
1. [介绍](#1-介绍)
- 1.1 [概述](#11-概述)
- 1.2 [范围](#12-范围)
- 1.3 [缩写](#13-缩写)
- 1.4 [文档约定](#14-文档约定)
- 1.5 [需求追踪](#15-需求追踪)
2. [用例](#2-用例)
3. [概念背景](#3-概念背景)
4. [公共元模型元素](#4-公共元模型元素)
5. [诊断服务](#5-诊断服务)
6. [诊断事件处理](#6-诊断事件处理)
7. [功能抑制](#7-功能抑制)
8. [J1939 诊断](#8-j1939-诊断)
附录：
- A [提及的类表（摘要）](#附录-a-提及的类表摘要)
- B [约束和规范项历史（摘要）](#附录-b-约束和规范项历史摘要)
- C [术语表（摘要）](#附录-c-术语表摘要)
- D [InstanceRef 建模（摘要）](#附录-d-instanceref-建模摘要)
- E [Upstream 映射（摘要）](#附录-e-upstream-映射摘要)
- F [可拆分元素（摘要）](#附录-f-可拆分元素摘要)
- G [变化点（摘要）](#附录-g-变化点摘要)
---
## 1 介绍
### 1.1 概述
AUTOSAR ECU 开发的分布式特性要求对信息进行优化的捕获。特别是，诊断信息（即 DEM 和 DCM 配置）应由具有最佳知识的人员仅捕获一次，因此能够比一个集中的个人更好地承担责任。
在 DiagnosticExtract 出现之前的配置方法中，基本软件模块 DCM 和 DEM 是完全集中配置的。在集成期间，RTE 之上的所有 SW-C（应用软件）[1] 引入要连接到 BSW 模块 [2] 的端口。此外，SW-C 表达应由 BSW 满足的需求。
市场强烈要求将 OEM 特定配置过程的诊断需求转移给其一级供应商。
过去，由于缺乏整体选项，许多不同的文件格式（如 ODX 或 EcuC [3]）经常被使用。但 ODX 和 EcuC 都不太适合传输这些信息。
例如，ODX [4] 缺乏故障存储器细节，而 EcuC（从未被设计为成为不同组织之间数据交换的载体）具有非常通用的性质，使得严格执行模型形式化变得非常困难。
最重要的是，将 EcuC 定义集成到现有配置中（特别是 PDU）无法完全自动化。
因此，显而易见的解决方案是定义一个新的标准化 AUTOSAR 交换格式来描述诊断功能，其使用方式与系统描述类似，并形式化为 ARXML [5] 文件。
本着这种精神，诊断功能的配置变得类似于系统描述 [6] 中通信部分的配置。
图 1.1 描述了两种通用用例的分散式诊断配置过程。此过程涉及三方：
- **OEM 或诊断请求者**
- **应用开发者或应用开发者**
- **ECU 供应商或集成商**
这些贡献者对诊断提取的具体角色在以下子章节中详细说明。
```
应用开发者 OEM ECU-供应商
用例 1：OEM 作为诊断需求的收集者
SW-Cs OEM
诊断贡献 收集/合并 诊断定义
(.arxml) (.doc/.xls)
OEM
特定过程
系统提取 (.arxml)
映射到 EcuC (AR 4.x)
诊断提取 (.arxml)
EcuC 参数值
ECU 实现
用例 2：供应商作为诊断需求的收集者
OEM
SW-Cs
诊断贡献 诊断提取
(.arxml) (部分填充)
(.arxml) (.arxml)
OEM
特定过程
收集/合并
由供应商执行
```
**图 1.1：本文档在 ECU 开发工作流中的范围**
> 请注意：反馈路径（例如从 OEM 到应用开发者）此处未显示，因为它们通常通过公司或项目特定方式实现。
#### 1.1.1 OEM
OEM 或诊断数据的请求者使用 DiagnosticExtract 来定义一个或多个 ECU 的诊断接口。它还可以定义一些 `InternalBehavior` 作为对 ECU 供应商或应用开发者的需求。
- 定义 DTC 的值
- 定义 ECU 支持的 UDS 服务和子服务
- 定义特定组合（由应用开发者实现）所需的事件
> **注意**：此列表仅作为示例；本文档不定义每个元素的具体所有权。
在第一种用例中，DiagnosticExtract 用于交换转换为 EcuC 配置的信息（M2 到 M1 映射，另见 [3] 和 [7]）。
其次，OEM 使用 DiagnosticExtract 来记录要由供应商实现的需求。这些需求以文本形式表达，不能直接映射到任何 EcuC 配置参数（无法进行 M2 到 M1 映射）。
#### 1.1.2 应用开发者
应用开发者使用相应的软件组件描述实现其软件组件。"应用开发者"角色可由 OEM 和供应商承担。换言之，OEM 和供应商都可能为给定 ECU 提供应用软件。
通过引入此概念，应用开发者可以提供与软件组件相关的诊断信息，作为 DiagnosticExtract 的一部分。
应用开发者还可以从 OEM 接收一些以文本形式表示的需求，例如：
- 由该软件组件实现的特定 `ReadDataByIdentifier` 的内容定义
- 该软件组件所需的事件定义
> **注意**：仅作为示例，本文不定义每个元素的具体所有权。
在第一种用例中，应用开发者定义特定 `ReadDataByIdentifier` 的参数，即诊断请求的内容但不定义 DID。该命令的 DID 通常由 OEM 定义。
其次，包括 Debouncing 和 OperationCycle 等信息的软件组件事件可以由应用开发者定义。应用开发者还可以定义特定 OEM 不需要但另一个 OEM 所需的事件和诊断作业。
供应商可以将同一软件用于多个 OEM 并需要重用它。这意味着，如果软件组件中的某些 DiagnosticExtract 信息在特定项目中不需要，则可以在集成期间忽略它们。
#### 1.1.3 ECU 供应商
ECU 供应商或集成商从 OEM 和多个应用开发者接收一个或多个 DiagnosticExtract 文件。集成商的主要目标是集成所有交付的 DiagnosticExtract 并从中生成 EcuC 配置。
由于此概念未为每个元素（DID、UDS 服务的参数、事件、会话等）定义特定的所有权，因此集成商必须确保在合并后完整信息仍然有效。
- DTC 到事件的映射
- 事件的合并
- 服务的映射
某些 DTC 可能已映射到事件 —— 特别是在两者来自同一方的情 况下。但如果 DTC 由 OEM 定义，而 SW 由作为应用开发者的其他供应商实现，则集成商必须确保两者被映射在一起。
在某些情况下，一个事件可能被多次定义。OEM 定义应由应用开发者实现的事件。供应商实现将在多个项目中使用的软件组件，该组件也会检测此类错误并定义此相同事件。
两个事件可能具有不同的命名但具有相同的含义。集成商必须在集成期间检测此冗余并将它们合并在一起。
在另一种情况下，OEM 需要特定的 `ReadDataByIdentifier`，而应用开发者实现它。如果实现仅针对一个特定项目执行，则应用开发者可以将 OEM 的 DID 映射到其软件组件中已定义的作业。
在其他情况下，应用开发者实现通用诊断作业时，ECU 供应商将负责合并此信息并将作业映射到相应的 DID。
#### 1.1.4 文件交换
在 ECU 开发项目期间，三个主要角色（OEM、应用开发者、ECU 集成商）交换 DiagnosticExtract 文件。交换的时间和频率以及每个交换文件的内容高度依赖于单个项目的设置和情况。
因此，DiagnosticExtract 格式已被设计为允许在不同时刻由不同角色逐步丰富定义，以满足"分散配置"的需求。
对于任何两个角色之间的任何交换路径，使用基于 DiagnosticExtract 模板的相同文件格式。然后由公司特定的过程和工具来合并收集的 DiagnosticExtract 文件，同时解决冲突（矛盾、冗余等）。
作为最终结果，一致且完整的 DiagnosticExtract 文件可用作对基本软件的诊断模块的配置派生的输入。
```
Figure 1.2: OEM、Tier-1 和 Tier-2 之间的诊断配置交换
```
即使在 DiagnosticExtract 已完全集成并准备好派生 EcuC 级别诊断堆栈的配置之后，仍然会预见将其反馈给例如 OEM。
在这种情况下，OEM 能够在诊断提取级别上审查诊断堆栈的配置。
在某些时候，此信息也可用于（直接或通过其他格式的间接方式）创建诊断客户端的配置。
#### 1.1.5 与软件组件服务需求的关系
软件组件可通过 `ServiceNeeds` 表达诊断需求。`DiagnosticContribution` 是软件组件在诊断提取中表达诊断信息的方式。
#### 1.1.6 建议和提示
- 在交换 `DiagnosticExtract` 文件时使用 ARXML 格式。
- 使用可拆分元素（`atpSplitable`）允许渐进式集成。
- 在合并过程中解决命名冲突和重复定义。
#### 1.1.7 限制
- 某些诊断信息可能无法在 `DiagnosticExtract` 中表达，需要直接在 EcuC 中配置。
- 跨多个 ECU 的诊断信息需要额外的协调。
### 1.2 范围
本文档的范围是定义 DiagnosticExtract 模板，该模板允许在 OEM、应用开发者和 ECU 供应商之间交换诊断配置信息。
模板涵盖：
- UDS 诊断服务（DID、RoutineControl 等）
- OBD 服务
- 诊断事件（DTC、扩展数据记录、冻结帧）
- 诊断操作循环
- 功能抑制
- J1939 诊断
模板不涵盖：
- ECU 配置参数本身的完整定义（详见 [3]）
- DCM 和 DEM 模块的内部行为（详见 [10] 和 [11]）
### 1.3 缩写
| 缩写 | 含义 |
|---|---|
| DEM | Diagnostic Event Manager（诊断事件管理器） |
| DCM | Diagnostic Communication Manager（诊断通信管理器） |
| DID | Data Identifier（数据标识符） |
| DTC | Diagnostic Trouble Code（诊断故障码） |
| ECU | Electronic Control Unit（电子控制单元） |
| FIM | Function Inhibition Manager（功能抑制管理器） |
| OBD | On-Board Diagnostics（车载诊断） |
| ODX | Open Diagnostic Data Exchange（开放诊断数据交换） |
| OEM | Original Equipment Manufacturer（原始设备制造商） |
| PDU | Protocol Data Unit（协议数据单元） |
| RTE | Runtime Environment（运行时环境） |
| S/R | Sender-Receiver（发送者-接收者） |
| SW-C | Software Component（软件组件） |
| UDS | Unified Diagnostic Services（统一诊断服务） |
| WWH-OBD | World-Wide Harmonized OBD（全球协调车载诊断） |
### 1.4 文档约定
技术术语以等宽字体排版，例如 `DiagnosticEvent`。
本文档包含文本形式的约束条件，通过唯一的数字约束 ID、标题和实际的约束文本来区分，约束文本以字符 `d` 开头，以字符 `c` 结尾。
这些约束的目的是从字面上约束 AUTOSAR 元模型的解释，使得可以检测元模型实例（即 M1 级别）中违反标准化行为的实现。鼓励 AUTOSAR 工具制造商将对应于 M1 建模问题的约束的数字 ID 作为工具发出的诊断消息的一部分。
需求和规范的标识符形式为 `[TPS_DEXT_xxxxx]`、`[RS_DEXT_xxxxx]`、`[constr_xxxx]`。
### 1.5 需求追踪
需求追踪表引用了 [13] 中规定的需求，并指出它们在本文档中如何被满足。主要包括：
| 需求 | 描述 | 满足于 |
|---|---|---|
| [RS_DEXT_00001] | DiagnosticExtract 应支持诊断数据交换 | 整个文档，特别是第 2 章 |
| [RS_DEXT_00002] | DiagnosticExtract 应支持 DCM 配置 | 第 5 章 |
| [RS_DEXT_00003] | DiagnosticExtract 应支持 DEM 配置 | 第 6 章 |
| [RS_DEXT_00004] | DiagnosticExtract 应支持 FIM 配置 | 第 7 章 |
| [RS_DEXT_00005] | DiagnosticExtract 应支持 OBD | 第 5.6 章 |
| [RS_DEXT_00006] | DiagnosticExtract 应支持 J1939 | 第 8 章 |
| [RS_DEXT_00007] | DiagnosticExtract 应支持环境条件 | 第 5.4 章 |
| [RS_DEXT_00008] | DiagnosticExtract 应支持诊断操作循环 | 第 6.9 章 |
| [RS_DEXT_00009] | DiagnosticExtract 应支持老化处理 | 第 6.10 章 |
| [RS_DEXT_00010] | DiagnosticExtract 应支持 OBD-II 和 WWH-OBD | 第 6.13 章 |
| [RS_DEXT_00011] | DiagnosticExtract 应支持功能抑制映射 | 第 7.4 章 |
| [RS_DEXT_00012] | DiagnosticExtract 应支持别名事件 | 第 7.2 章 |
| [RS_DEXT_00013] | DiagnosticExtract 应支持功能标识符 | 第 7.3 章 |
| [RS_DEXT_00014] | DiagnosticExtract 应支持 DTC 映射 | 第 6.8.1 章 |
| [RS_DEXT_00015] | DiagnosticExtract 应支持事件到端口的映射 | 第 6.8.6 章 |
| [RS_DEXT_00016] | DiagnosticExtract 应支持服务映射 | 第 5.8 章 |
| [RS_DEXT_00017] | DiagnosticExtract 应支持去抖算法 | 第 6.8.3 章 |
| [RS_DEXT_00018] | DiagnosticExtract 应支持存储条件 | 第 6.8.5 章 |
| [RS_DEXT_00019] | DiagnosticExtract 应支持使能条件 | 第 6.8.4 章 |
| [RS_DEXT_00020] | DiagnosticExtract 应支持主从事件映射 | 第 6.8.11 章 |
> **完整需求追踪表见原文 PDF 第 21-24 页**
---
## 2 用例
### 2.1 诊断数据交换的用例
`DiagnosticExtract` 的主要用例是在 ECU 开发过程中交换诊断配置数据。这包括：
1. **OEM 作为收集者**（用例 1）：OEM 定义诊断需求并将其分发给应用开发者和 ECU 供应商。
2. **供应商作为收集者**（用例 2）：供应商收集来自多个应用开发者的诊断数据并将其与 OEM 的需求合并。
### 2.2 DCM 配置
`DiagnosticExtract` 支持 DCM（Diagnostic Communication Manager）的配置：
- UDS 服务定义（`DataByIdentifier`、`RoutineControl`、`IOControl` 等）
- 服务实例的安全访问、会话和访问权限
- 服务到 ECU 数据元素和 SW-C 端口的映射
- OBD 服务定义
### 2.3 DEM 配置
`DiagnosticExtract` 支持 DEM（Diagnostic Event Manager）的配置：
- 诊断事件（`DiagnosticEvent`）定义
- 诊断故障码（DTC）定义
- 扩展数据记录（`DiagnosticExtendedDataRecord`）和冻结帧（`DiagnosticFreezeFrame`）
- 诊断操作循环（`DiagnosticOperationCycle`）
- 老化处理（`DiagnosticAging`）
- 事件到端口、DTC、操作循环、去抖算法、使能条件、存储条件的映射
### 2.4 FIM 配置
#### 2.4.1 建模功能抑制
`DiagnosticExtract` 支持功能抑制（Function Inhibition）的建模：
- **别名事件（Alias Events）**：用于在多个应用之间共享抑制逻辑。
- **功能标识符（Function Identifier）**：标识被抑制的功能。
- **抑制源到诊断事件的映射**：定义哪些事件触发哪些功能抑制。
- **别名事件映射**：定义别名事件之间的映射。
#### 2.4.2 在 Dem 存在之前建模 FIM 配置
`DiagnosticExtract` 允许在 Dem 存在之前定义 FIM 配置。这在早期开发阶段很有用。
### 2.5 J1939 诊断配置
#### 2.5.1 独立于部署的 J1939 诊断方面的建模
J1939 诊断方面可以独立于 ECU 部署进行建模。
#### 2.5.2 在诊断提取中建模的 J1939 诊断内容
J1939 诊断内容包括：
- 怀疑参数编号（SPN，Suspect Parameter Number）
- J1939Dcm 相关建模
- Dem 相关建模
- 软件组件到控制器应用的映射
- 诊断事件到 J1939 DTC 的映射
---
## 3 概念背景
### 3.1 相关诊断元素的定义
`DiagnosticExtract` 涵盖与诊断相关的所有元素，包括：
- **诊断服务**：UDS 和 OBD 服务。
- **诊断事件**：由 SW-C 或 BSW 报告的事件。
- **诊断数据**：用于诊断的 ECU 数据元素。
- **诊断映射**：将诊断元素映射到 SW-C、端口等。
### 3.2 从 EcuC 级别的抽象
`DiagnosticExtract` 处于比 EcuC 更高的抽象级别。它允许定义诊断需求，而无需关心 EcuC 配置参数的细节。
抽象层次：
1. **系统描述**：系统级诊断需求。
2. **诊断提取**（本文档）：诊断配置数据的中级抽象。
3. **EcuC 配置**：BSW 模块的配置参数。
### 3.3 定义的独立性
#### 3.3.1 使用 `atpSplitable` 启用元素在多个物理文件中的分离
`atpSplitable` 构造型允许将单个元模型的元素拆分到多个 ARXML 文件中。这对于渐进式集成非常有用。
#### 3.3.2 使用自包含的映射元素
映射元素（如 `DiagnosticMapping`）是自包含的，可以在没有完整诊断提取的情况下定义。
---
## 4 公共元模型元素
### 4.1 介绍
本章介绍 `DiagnosticExtract` 使用的公共元模型元素，这些元素在多个章节中共享。
### 4.2 数据标识符 vs. 例程 vs. 数据元素
UDS 中三种不同的诊断数据访问方式：
- **DID（Data Identifier）**：通过 16 位 ID 标识的诊断数据块。
- **Routine**：在 ECU 上执行的控制例程。
- **Data Element**：通过服务（如 `ReadDataByIdentifier`）访问的诊断数据。
#### 4.2.1 SwDataDefProps 的使用
`SwDataDefProps` 描述数据元素的属性，如长度、类型、编码。
#### 4.2.2 数组的定义
`ARRAY` 类型用于定义诊断数据数组。
#### 4.2.3 文本字符串的定义
`STRING` 类型用于定义诊断文本字符串。
### 4.3 文本文档
`DocumentationBlock` 用于为诊断元素提供文本说明。
### 4.4 诊断贡献
`DiagnosticContribution` 元类描述由软件组件提供的诊断信息。它包含以下主要元素：
- 诊断数据元素（`DiagnosticDataElement`）
- 诊断事件（`DiagnosticEvent`）
- 诊断服务（`DiagnosticService`）
- 诊断映射（`DiagnosticMapping`）
> **[TPS_DEXT_00001] DiagnosticContribution 的内容 d** `DiagnosticContribution` 包含与软件组件相关的所有诊断信息。 **c** (RS_DEXT_00001)
### 4.5 诊断协议
`DiagnosticProtocol` 描述诊断协议（UDS、OBD、J1939）的属性。
> **[TPS_DEXT_00002] 协议特定属性 d** `DiagnosticProtocol` 携带协议特定属性。 **c** (RS_DEXT_00001)
### 4.6 诊断公共属性
`DiagnosticCommonProperties` 描述所有诊断元素共享的公共属性，如 PduRef、最大响应时间等。
---
## 5 诊断服务
### 5.1 介绍
本章介绍 `DiagnosticExtract` 中支持的诊断服务建模。
### 5.2 服务实例 vs. 服务类
- **服务类（Service Class）**：描述服务的类型（如 `DataByIdentifier`）。
- **服务实例（Service Instance）**：描述服务的具体实例及其参数。
### 5.3 访问权限、会话、安全级别
#### 5.3.1 访问权限介绍
诊断服务的访问权限通过 `DiagnosticAccessPermission` 元类描述。它定义了在哪些会话和安全级别下可以访问特定服务。
#### 5.3.2 访问权限的优先级
当多个访问权限规则匹配时，使用优先级规则确定哪个规则适用。
### 5.4 诊断服务执行的环境条件
#### 5.4.1 环境条件公式
`DiagnosticEnvironmentFormula` 描述诊断服务执行所需的环境条件（如模式、数据值）。
#### 5.4.2 原子条件
##### 5.4.2.1 数据条件
`DataCondition` 描述基于数据值的环境条件。
##### 5.4.2.2 模式条件
`ModeCondition` 描述基于模式的环境条件。
### 5.5 AUTOSAR 支持的诊断服务
#### 5.5.1 DataByIdentifier
`DataByIdentifier` 服务提供对 ECU 数据的访问。DID 标识特定数据。
> **[TPS_DEXT_00010] DataByIdentifier 映射 d** `DataByIdentifier` 服务应映射到 SW-C 端口或 ECU 数据元素。 **c** (RS_DEXT_00002, RS_DEXT_00016)
#### 5.5.2 IOControl
`IOControl` 服务控制 ECU 的输入/输出行为。
#### 5.5.3 EcuReset
`EcuReset` 服务重置 ECU。
#### 5.5.4 ClearDiagnosticInformation
`ClearDiagnosticInformation` 服务清除诊断信息。
#### 5.5.5 内存服务
内存服务包括：
- `ReadMemoryByAddress`
- `WriteMemoryByAddress`
- `ReadDataByIdentifier`
- 等
#### 5.5.6 CommunicationControl
`CommunicationControl` 服务控制 ECU 的通信行为。
#### 5.5.7 DynamicallyDefineDataIdentifier
`DynamicallyDefineDataIdentifier` 服务动态定义 DID。
#### 5.5.8 ReadDataByPeriodicIdentifier
`ReadDataByPeriodicIdentifier` 服务周期性读取数据。
#### 5.5.9 ControlDTCSetting
`ControlDTCSetting` 服务控制 DTC 设置。
#### 5.5.10 ResponseOnEvent
`ResponseOnEvent` 服务在事件发生时响应。
#### 5.5.11 ReadDTCInformation
`ReadDTCInformation` 服务读取 DTC 信息。
#### 5.5.12 RoutineControl
`RoutineControl` 服务控制 ECU 上的例程。
#### 5.5.13 SecurityAccess
`SecurityAccess` 服务提供对 ECU 的安全访问。
#### 5.5.14 SessionControl
`SessionControl` 服务控制诊断会话。
#### 5.5.15 RequestFileTransfer
`RequestFileTransfer` 服务请求文件传输。
### 5.6 AUTOSAR 支持的 OBD 诊断服务
#### 5.6.1 OBD Mode 0x01（RequestCurrentPowertrainDiagnosticData）
请求当前动力总成诊断数据。
#### 5.6.2 OBD Mode 0x02（RequestPowertrainFreezeFrameData）
请求动力总成冻结帧数据。
#### 5.6.3 OBD Mode 0x03 / 0x07（RequestEmissionRelatedDiagnosticTroubleCodes）
请求排放相关诊断故障码。
#### 5.6.4 OBD Mode 0x04（ClearResetEmissionRelatedDiagnosticInformation）
清除/重置排放相关诊断信息。
#### 5.6.5 OBD Mode 0x06（RequestOnBoardMonitoringTestResults）
请求车载监测测试结果。
#### 5.6.6 OBD Mode 0x08（RequestControlOfOnBoardDevice）
请求控制车载设备。
#### 5.6.7 OBD Mode 0x09（RequestVehicleInformation）
请求车辆信息。
#### 5.6.8 OBD Mode 0x0A（RequestEmissionRelatedDiagnosticTroubleCodesPermanentStatus）
请求排放相关诊断故障码永久状态。
### 5.7 支持 WWH-OBD 的 UDS 诊断服务
### 5.8 诊断服务映射
#### 5.8.1 诊断服务数据映射
`DiagnosticDataMapping` 描述诊断服务数据到数据元素的映射。
#### 5.8.2 诊断服务软件映射
`DiagnosticSwMapping` 描述诊断服务到软件组件的映射。
> **[TPS_DEXT_00020] 完整服务映射 d** 完整的服务映射规则详见原文 PDF 第 156-167 页。 **c** (RS_DEXT_00016)
---
## 6 诊断事件处理
### 6.1 介绍
本章介绍 `DiagnosticExtract` 中的诊断事件处理（DEM）建模。
### 6.2 DiagnosticEvent
`DiagnosticEvent` 元类描述由应用或 BSW 报告的诊断事件。
主要属性：
- `shortName`：事件的短名称。
- `shortLabel`：事件的简短标签。
- `eventCategory`：事件类别。
- `eventOccurrence`：事件发生条件。
- `priority`：事件优先级。
- `significance`：事件严重性。
- `recoveryInformation`：恢复信息。
- `debounceAlgorithm`：去抖算法引用。
- `operationCycle`：操作循环引用。
- `enableCondition`：使能条件。
- `storageCondition`：存储条件。
- `aging`：老化处理。
- `failureCycleCounter`：失败循环计数。
- `passedCycleCounter`：通过循环计数。
- `eventKind`：事件种类。
> **[TPS_DEXT_00030] DiagnosticEvent 标识 d** `DiagnosticEvent.shortName` 应在系统中唯一标识一个事件。 **c** (RS_DEXT_00003)
### 6.3 DiagnosticTroubleCode
`DiagnosticTroubleCode`（DTC）描述诊断故障码。
主要属性：
- `troubleCode`：DTC 数值。
- `troubleCodeDefault`：默认 DTC。
- `displayRepresentation`：显示表示。
- `text`：DTC 文本。
- `severity`：DTC 严重性。
- `functionalUnit`：功能单元。
- `DtcKind`：DTC 种类（UDS/OBD/J1939）。
- `DtcUdsLayer`：UDS 层级（应用层/立即层）。
> **[TPS_DEXT_00031] DTC 唯一性 d** `DiagnosticTroubleCode.troubleCode` 应在系统中唯一。 **c** (RS_DEXT_00003)
### 6.4 DiagnosticExtendedDataRecord
`DiagnosticExtendedDataRecord` 描述 DTC 的扩展数据记录（EDR）。
### 6.5 DiagnosticFreezeFrame
`DiagnosticFreezeFrame` 描述 DTC 的冻结帧。
### 6.6 DiagnosticCondition
`DiagnosticCondition` 描述影响诊断事件的环境条件。
### 6.7 DiagnosticConditionGroup
`DiagnosticConditionGroup` 描述条件组，可以是使能条件组或存储条件组。
### 6.8 DiagnosticMapping
`DiagnosticMapping` 元类包含多个子映射，定义诊断元素之间的映射。
#### 6.8.1 DiagnosticEvent 到 DtcUds 映射
`DiagnosticEventToDtcMapping` 描述事件到 DTC 的映射。
#### 6.8.2 DiagnosticEvent 到 DiagnosticOperationCycle 映射
描述事件到操作循环的映射。
#### 6.8.3 DiagnosticEvent 到 DebounceAlgorithm 映射
描述事件到去抖算法的映射。
#### 6.8.4 DiagnosticEvent 到 EnableConditionGroup 映射
描述事件到使能条件组的映射。
#### 6.8.5 DiagnosticEvent 到 StorageConditionGroup 映射
描述事件到存储条件组的映射。
#### 6.8.6 DiagnosticEvent 到 Port 映射
描述事件到 SW-C 端口的映射。
#### 6.8.7 DiagnosticOperationCycle 到 Port 映射
描述操作循环到端口的映射。
#### 6.8.8 DiagnosticEnableCondition 到 Port 映射
描述使能条件到端口的映射。
#### 6.8.9 DiagnosticStorageCondition 到 Port 映射
描述存储条件到端口的映射。
#### 6.8.10 提供数据映射
描述提供数据的映射。
#### 6.8.11 主从事件映射
`MasterToSlaveEventMapping` 描述主 ECU 和从 ECU 之间的事件映射。
### 6.9 DiagnosticOperationCycle
`DiagnosticOperationCycle` 描述诊断操作循环（如 POWER、IGNITION、OBD_DRIVING）。
### 6.10 DiagnosticAging
`DiagnosticAging` 描述 DTC 老化处理（删除过时的 DTC 记录）。
### 6.11 DiagnosticIndicator
`DiagnosticIndicator` 描述诊断指示器（如警告灯）。
### 6.12 DiagnosticTestResult
`DiagnosticTestResult` 描述诊断测试结果。
### 6.13 OBD 相关 DEM 配置
#### 6.13.1 OBD-II 的 DEM 配置
#### 6.13.2 WWH-OBD 的 DEM 配置
> **完整内容见原文 PDF 第 168-225 页**
---
## 7 功能抑制
### 7.1 介绍
功能抑制（FIM）允许在特定条件下禁用 ECU 功能。本章介绍 FIM 的 `DiagnosticExtract` 建模。
### 7.2 别名事件
`AliasEvent` 是 `DiagnosticEvent` 的别名，用于在多个应用之间共享抑制逻辑。
### 7.3 功能标识符
`FunctionIdentifier` 标识被抑制的功能。
### 7.4 抑制源和诊断事件之间的映射
`InhibitionSourceToDiagnosticEventMapping` 描述抑制源（事件）到被抑制功能的映射。
### 7.5 别名事件映射
`AliasEventMapping` 描述别名事件到主事件的映射。
### 7.6 功能标识符到相应监视器的映射
`FunctionIdentifierToMonitorMapping` 描述功能标识符到相应监视器的映射。
> **完整内容见原文 PDF 第 226-236 页**
---
## 8 J1939 诊断
### 8.1 介绍
本章介绍 J1939 协议诊断的 `DiagnosticExtract` 建模。
### 8.2 怀疑参数编号
SPN（Suspect Parameter Number）是 J1939 中标识诊断参数的编号。
### 8.3 J1939Dcm 相关建模
`J1939Dcm` 服务相关建模。
### 8.4 Dem 相关建模
J1939 Dem 相关建模。
### 8.5 软件组件到控制器应用的映射
`SwcToControllerApplicationMapping` 描述 SW-C 到 J1939 控制器应用的映射。
### 8.6 诊断事件到 J1939 DTC 的映射
`DiagnosticEventToJ1939DtcMapping` 描述 `DiagnosticEvent` 到 J1939 DTC 的映射。
> **完整内容见原文 PDF 第 237-244 页**
---
## 附录 A 提及的类表（摘要）
附录 A 列出了本文档中提及的所有 UML 类，主要包括：
- `DiagnosticExtract`（顶层元素）
- `DiagnosticContribution`
- `DiagnosticCommonProperties`
- `DiagnosticProtocol`
- `DiagnosticServiceInstance` / `DiagnosticServiceClass`
- `DiagnosticDataIdentifier`（DID）
- `DiagnosticRoutine`（DID Routine）
- `DiagnosticIOControl`
- `DiagnosticEcuReset`
- `DiagnosticClearDiagnosticInformation`
- `DiagnosticCommunicationControl`
- `DiagnosticControlDTCSetting`
- `DiagnosticReadDTCInformation`
- `DiagnosticReadDataByPeriodicIdentifier`
- `DiagnosticResponseOnEvent`
- `DiagnosticSecurityAccess`
- `DiagnosticSessionControl`
- `DiagnosticDynamicallyDefineDataIdentifier`
- `DiagnosticRequestFileTransfer`
- `DiagnosticMemoryByAddress`
- `ObdServiceInstance`
- `DiagnosticEvent`
- `DiagnosticTroubleCode`（DTC）
- `DiagnosticExtendedDataRecord`
- `DiagnosticFreezeFrame`
- `DiagnosticCondition`
- `DiagnosticConditionGroup`
- `DiagnosticMapping` 及其子类
- `DiagnosticOperationCycle`
- `DiagnosticAging`
- `DiagnosticIndicator`
- `DiagnosticTestResult`
- `FunctionIdentifier`
- `AliasEvent`
- `InhibitionSourceToDiagnosticEventMapping`
- `J1939Dcm` 相关类
- `SwcToControllerApplicationMapping`
- 等等
> **完整类表见原文 PDF 第 245-270 页**
---
## 附录 B 约束和规范项历史（摘要）
附录 B 按 AUTOSAR 4.2.1、4.2.2、4.3.0、4.3.1、4.4.0 列出约束和规范的变更历史。
主要小节：
- B.1 R4.2.1 的约束历史
- B.2 R4.2.2 的约束历史
- B.3 R4.3.0 的约束历史
- B.4 R4.3.1 的约束历史
- B.5 R4.4.0 的约束历史
> **完整内容见原文 PDF 第 271-285 页**
---
## 附录 C 术语表（摘要）
附录 C 提供了本文档中使用的诊断相关术语的术语表。
> **完整内容见原文 PDF 第 285-288 页**
---
## 附录 D InstanceRef 建模（摘要）
### D.1 介绍
`InstanceRef` 在 `DiagnosticExtract` 中用于引用特定实例（如 SW-C 实例、端口实例）。
### D.2 建模
`InstanceRef` 的建模模式详见原文。
> **完整内容见原文 PDF 第 288-293 页**
---
## 附录 E Upstream 映射（摘要）
附录 E 描述 `DiagnosticExtract` 中各 BSW 模块（Dcm、Dem、Fim、J1939Dcm）与上游模型的映射。
主要小节：
- E.1 介绍
- E.2 Dcm 映射（最重要，占大部分）
- E.3 Dem 映射
- E.4 Fim 映射
- E.5 J1939Dcm 映射
> **完整内容见原文 PDF 第 294-485 页**
---
## 附录 F 可拆分元素（摘要）
附录 F 列出了本文档范围内的可拆分（`atpSplitable`）元素。
> **完整内容见原文 PDF 第 486 页**
---
## 附录 G 变化点（摘要）
附录 G 列出了本文档范围内的变化点（`atpVariation`）。
> **完整内容见原文 PDF 第 487 页**
---
## 翻译说明
1. **保留内容**：所有 API 标识符（`DiagnosticEvent`、`DiagnosticExtract` 等）、UML 类名、属性名、ARXML 标签、AUTOSAR 方框符 `⌈⌋`、需求 ID（`RS_DEXT_xxxxx`、`TPS_DEXT_xxxxx` 等）、文档标识号、UDS 服务标识符（`0x01`-`0x0A` 等）。
2. **翻译内容**：标题、描述性文字、章节概述、UML 类的语义说明、约束的措辞。
3. **策略**：封面、文档标识、变更历史、目录、第 1-8 章（核心内容）已翻译关键概念和主要 TPS_DEXT_* 约束；附录 A-G 采用摘要处理，并指向原文 PDF 的具体页码。
4. **代码块**：UML 类图使用代码块简化展示，详细图示见原文 PDF。
5. **约束/规范标记**：保留 `[TPS_DEXT_xxxxx]`、`[RS_DEXT_xxxxx]`、`[constr_xxxx]` 等 ID 标识。
**主要文档 ID**：673（AUTOSAR_TPS_DiagnosticExtractTemplate）
**翻译版本**：基于 AUTOSAR CP Release 4.4.0