feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0d470d1f1750b515b51be218bb3897436579ec0e
autosar_standard_spec_v4.4/MethodologyAndTemplates/AUTOSAR_RS_DiagnosticExtractTemplate.md
T

1326 lines
71 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AUTOSAR 诊断提取模板需求
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Requirements on Diagnostic Extract Template*（文档 ID 681）
>
> 翻译状态：**已完成 v1**（封面+前言+用例+需求+变更历史完整翻译）
>
> 对应原文 PDF：`MethodologyAndTemplates/AUTOSAR_RS_DiagnosticExtractTemplate.pdf`
>
> 翻译日期：Step 3 - P0 批量翻译
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题（Document Title） | 诊断提取模板需求（Requirements on Diagnostic Extract Template） |
| 文档所有者（Document Owner） | AUTOSAR |
| 文档责任人（Document Responsibility） | AUTOSAR |
| 文档标识号（Document Identification No） | 681 |
| 文档状态（Document Status） | 正式版（Final） |
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
| 所属标准版本 | 4.4.0 |
> 原文版权：© AUTOSAR — 机密文件
> 本中文译文仅供学习参考。
---
## 免责声明（Disclaimer）
本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，**仅供信息参考**。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。
本作品可在不作任何修改的情况下、以任何形式或任何手段用于**纯信息性目的**。任何其他目的，未经出版者书面许可，作品的任何部分不得被利用或复制。
本作品**仅**为汽车应用而开发。它既未为非汽车应用而开发，也未为非汽车应用而进行测试。
"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
---
## 文档变更历史（Document Change History）
| 日期 | 版本 | 变更人 | 变更说明 |
|------|------|--------|----------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性修订 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修订；增加 OBD 需求；增加 Fim 支持需求 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 增加 J1939 支持需求；细微修正/澄清/编辑性变更 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正/澄清/编辑性变更 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 初始发布（Initial Release） |
---
## 目录
1. [引言（Introduction）](#1-引言introduction)
- 1.1 [本文档范围（Scope of this document）](#11-本文档范围scope-of-this-document)
- 1.2 [文档约定（Document Conventions）](#12-文档约定document-conventions)
- 1.3 [指南（Guidelines）](#13-指南guidelines)
- 1.4 [需求追溯（Requirements Tracing）](#14-需求追溯requirements-tracing)
2. [需求（Requirements）](#2-需求requirements)
- 2.1 [与 AUTOSAR 特性关系（Relation to AUTOSAR Features）](#21-与-autosar-特性关系relation-to-autosar-features)
- 2.2 [一般需求（General Requirements）](#22-一般需求general-requirements)
- 2.3 [UDS 诊断服务支持需求（Requirements against the Support for UDS Diagnostic Services）](#23-uds-诊断服务支持需求requirements-against-the-support-for-uds-diagnostic-services)
- 2.4 [事件处理需求（Requirements against Event Handling）](#24-事件处理需求requirements-against-event-handling)
- 2.5 [会话和安全需求（Requirements against Sessions and Security）](#25-会话和安全需求requirements-against-sessions-and-security)
- 2.6 [功能抑制支持需求（Requirements against the Support for Function Inhibition）](#26-功能抑制支持需求requirements-against-the-support-for-function-inhibition)
- 2.7 [J1939 诊断支持需求（Requirements against the Support for diagnostics on J1939）](#27-j1939-诊断支持需求requirements-against-the-support-for-diagnostics-on-j1939)
- 2.8 [OBD 诊断服务支持需求（Requirements against the Support for OBD Diagnostic Services）](#28-obd-诊断服务支持需求requirements-against-the-support-for-obd-diagnostic-services)
- [附录 A 约束和规范项历史（History of Constraints and Specification Items）](#附录-a-约束和规范项历史history-of-constraints-and-specification-items)
---
## 参考文献（References）
- [1] Standardization Template，AUTOSAR_TPS_StandardizationTemplate
- [2] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Release 2006-12)，http://www.iso.org
- [3] Specification of Diagnostic Communication Manager，AUTOSAR_SWS_DiagnosticCommunicationManager
- [4] Specification of Diagnostic Event Manager，AUTOSAR_SWS_DiagnosticEventManager
- [5] Motor Vehicle Pollution Control Devices，http://www.iso.org
- [6] Specification of Function Inhibition Manager，AUTOSAR_SWS_FunctionInhibitionManager
- [7] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 5: Emission-related diagnostic services，http://www.iso.org
---
## 1 引言（Introduction）
### 1.1 本文档范围（Scope of this document）
本文档收集了关于诊断提取（Diagnostic Extract）的需求。
诊断提取的主要目标是在诊断开发过程的不同参与方之间交换诊断数据，以支持诊断模块 DCM 和 DEM 的自动代码生成过程。
此外，诊断提取用于支持诊断功能的分布式开发过程。
下面再次提及诊断提取使用的关键方面：
- DCM 和 DEM 的诊断数据交换
- 支持诊断功能的分布式开发
### 1.2 文档约定（Document Conventions）
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中规定的表格，详见《标准化模板》的"可追溯性支持"一章 ([1])。
用于表达义务的动词形式应遵循 [TPS_STDT_00053] 的规定，用以表示需求，详见《标准化模板》的"可追溯性支持"一章 ([1])。
### 1.3 指南（Guidelines）
应引用现有规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性：
- **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。
- **清晰性（Clearness）**：所有需求应仅允许一种解释可能性。使用的未在词汇表中的技术术语必须定义。
- **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能拆分为更多的需求，则该需求是原子的。
- **可测试性（Testability）**：需求应可通过分析、评审或测试进行测试。
- **可追溯性（Traceability）**：需求的来源和状态应始终可见。
### 1.4 需求追溯（Requirements Tracing）
本文档目前不提供需求追溯。需求追溯将在后续修订中包含。
---
## 2 需求（Requirements）
### 2.1 与 AUTOSAR 特性关系（Relation to AUTOSAR Features）
本节描述应由需求处理的特性列表：
- [RS_Main_00300] AUTOSAR 应提供数据交换格式以支持大型跨公司和公司内部开发组的工作分担
- [RS_BRF_01112] AUTOSAR 应提供引导加载程序接口
- [RS_BRF_01440] AUTOSAR 服务应支持系统诊断功能
这是需要由诊断提取需求满足的特性和主要需求的简短选择。
### 2.2 一般需求（General Requirements）
本章包含适用于诊断提取所有方面的一般需求集合。
#### [RS_DEXT_00001] 诊断数据交换
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断相关信息的交换。 |
| **原理（Rationale）** | AUTOSAR 诊断栈的配置在绝大多数情况下是 OEM 和相应 ECU 供应商共同努力的结果。为此，OEM 和供应商需要能够以尽可能少的摩擦交换配置信息。通常，特定 OEM 和特定供应商的任意组合都是可能的。为了实现这一点，有必要在必要的范围内对受影响方之间交换的数据进行标准化。 |
| **用例（Use Case）** | • OEM 向供应商交付部分配置，供应商随后填写缺失的部分和/或审查并在适用的情况下覆盖 OEM 已完成的配置。<br>• 供应商将审查后的诊断配置反馈给 OEM。<br>• 供应商将诊断栈的最终配置交付给 OEM，以便后者能够从这些数据中得出测试仪配置。<br>• 供应商或 OEM 使用诊断提取在公司内部相关的负责组织部分之间交换信息。通过这种方式支持公司内部的分布式软件开发。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00044] 相关 ECU-C 参数的派生
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持为 Dcm、Fim 和 Dem 派生相关的 ECU-C 参数。 |
| **原理（Rationale）** | 按定义，AUTOSAR 诊断栈在 ECUC 级别上的具体配置不可移植。它非常侧重于反映特定诊断栈特定实现的特定细节。这种方法是合理的，因为它允许比通用和更抽象的方法更深入地优化软件栈。然而，更抽象的方法在跨组织甚至在某种程度上跨项目的可交换性方面具有其他优点。因此，定义一种通用和更抽象的方式来配置诊断栈是合理的，其最终目标是在很大程度上派生出具体的和不可移植的特定配置。 |
| **用例（Use Case）** | 用户希望以可以与项目合作伙伴以与系统描述相同的方式交换的通用方式指定诊断栈的配置。用户希望在与系统提取相同的概念级别上指定诊断信息，并希望将诊断配置与系统提取的元素相关联（如果适用）。最后，有人希望采用在更高概念级别上描述的此信息，并将其用于在 ECUC 这一更具体（因此可移植性较低）级别上派生配置信息。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00046] 变体
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持变体。 |
| **原理（Rationale）** | AUTOSAR 模型通常可能由同一方面的不同变体组成。一方面上不同变体的建模可能对另一方面产生影响，即另一方面也需要变体以正确实现模型一致性。换句话说，如果 ECU 的配置（例如以系统描述的形式）具有变体，则 ECU 上诊断栈的配置或多或少可能需要考虑这些变体并做出相应反应。除此之外，诊断提取可能需要从与相应系统描述中变体的存在完全不同的动机出发来定义变体。 |
| **用例（Use Case）** | 用户需要考虑相应系统描述中现有的变体，因此引入与系统描述中适用的变更点绑定相同表达式的变体点。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00048] 特定于一个 ECU 的诊断属性
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持针对给定 ECU 特定的诊断属性的定义。 |
| **原理（Rationale）** | 某些属性因 ECU 而异。如果诊断提取同时涵盖多个 ECU，则有必要单独表达其诊断属性。 |
| **用例（Use Case）** | 用户希望指定由多个 ECU 组成的诊断提取，并希望为每个包含的 ECU 单独定义某些属性。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00058] 表明 ECU 支持 OBD
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应允许定义给定 ECU 是否（以及如何）支持 OBD。 |
| **原理（Rationale）** | 下游配置中存在某些需要根据给定 ECU 的 OBD 能力信息设置的开关。 |
| **用例（Use Case）** | 用户希望指定给定 ECU 的 OBD 适用性。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00059] 支持不同的协议
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持不同诊断协议（例如 UDS、OBD 等）的定义及其彼此之间的优先级关系。 |
| **原理（Rationale）** | 应以不同的优先级处理不同的协议。这要求对诊断协议进行正式定义，并定义其与已属于诊断提取的其他模型元素的关系。 |
| **用例（Use Case）** | 用户希望定义支持不同诊断协议的诊断提取。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
### 2.3 UDS 诊断服务支持需求（Requirements against the Support for UDS Diagnostic Services）
本章包含根据 [2] 的 UDS 诊断服务上下文的需求集合。
#### [RS_DEXT_00003] SessionControl
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x10（SessionControl）的配置。 |
| **原理（Rationale）** | 不同诊断会话的使用非常常见，因此需要诊断提取模板的支持。 |
| **用例（Use Case）** | 支持从一个诊断会话切换到另一个。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00004] ECUReset
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x11（ECUReset）的配置。 |
| **原理（Rationale）** | 重置服务器的能力对于进行诊断会话至关重要。 |
| **用例（Use Case）** | 用户希望重置连接的服务器。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00005] ClearDiagnosticInformation
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x14（ClearDiagnosticInformation）的配置。 |
| **原理（Rationale）** | 该服务允许清除服务器的诊断内存。这是一个经常使用的功能。 |
| **用例（Use Case）** | 用户希望清除连接服务器上的诊断内存。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00006] ReadDTCInformation
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x19（ReadDTCInformation）的配置。 |
| **原理（Rationale）** | 该服务允许访问服务器上诊断故障代码的状态。这是一个经常使用的功能。 |
| **用例（Use Case）** | 用户希望通过测试仪访问服务器上的 DTC 信息。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00007] ReadDataByIdentifier
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x22（ReadDataByIdentifier）的配置。 |
| **原理（Rationale）** | 该服务允许根据给定数据标识符的定义读取服务器上的值。这是一个经常使用的功能。 |
| **用例（Use Case）** | 用户希望从服务器读取与给定数据标识符关联的值。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00008] ReadMemoryByAddress
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x23（ReadMemoryByAddress）的配置。 |
| **原理（Rationale）** | 该服务允许访问服务器上某段内存的内容。这是一个经常使用的功能。 |
| **用例（Use Case）** | 用户希望从诊断服务器读取内存内容。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00009] SecurityAccess
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x27（SecurityAccess）的配置。 |
| **原理（Rationale）** | 此服务允许数据和应用特定安全限制的诊断服务。 |
| **用例（Use Case）** | 安全限制的应用程序将数据和诊断服务的访问限制为授权人员。可能出于安全和/或安全原因而应用此限制。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00010] CommunicationControl
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x28（CommunicationControl）的配置。 |
| **原理（Rationale）** | 此服务允许打开和关闭某些消息的通信（例如与应用相关的通信）。 |
| **用例（Use Case）** | 用户希望关闭正常通信消息。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00011] ReadDataByPeriodicIdentifier
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x2A（ReadDataByPeriodicIdentifier）的配置。 |
| **原理（Rationale）** | 该服务允许根据定期数据标识符的定义请求服务器对诊断数据的定期传输。 |
| **用例（Use Case）** | 用户希望获得对定期传输的诊断数据的访问权限，而无需单独请求每次传输。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00012] DynamicallyDefineDataIdentifier
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x2C（DynamicallyDefineDataIdentifier）的配置。 |
| **原理（Rationale）** | 该服务允许即时定义数据标识符，然后可以通过相应的诊断服务访问该数据标识符。 |
| **用例（Use Case）** | 与预先定义数据标识符（在诊断会话之前）的情况相反，此服务允许在诊断会话进行时定义数据标识符。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00013] WriteDataByIdentifier
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x2E（WriteDataByIdentifier）的配置。 |
| **原理（Rationale）** | 该服务允许通过与诊断数据标识符的关联将诊断数据传输到诊断服务器。这是一个经常使用的功能。 |
| **用例（Use Case）** | 用户希望将与给定数据标识符关联的数据传输到诊断服务器。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00014] IOControl
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x2F（IOControl）的配置。 |
| **原理（Rationale）** | 该服务允许使用诊断测试仪提供的值替换 I/O 层的值。 |
| **用例（Use Case）** | 用户希望绕过传感器并提供替代值。用户希望替换提供给给定执行器的值。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00015] RoutineControl
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x31（RoutineControl）的配置。 |
| **原理（Rationale）** | 该服务可用于在服务器上执行特定代码。 |
| **用例（Use Case）** | 用户希望在远程服务器上执行代码，以实现超出任何"简单"数据交换服务提供的功能的功能。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00016] RequestDownload
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x34（RequestDownload）的配置。 |
| **原理（Rationale）** | 此服务具有请求服务器接受从客户端（例如测试仪）到服务器的数据传输的能力。对该服务的支持是对 [RS_DEXT_00018] 中描述的服务支持的前提条件。 |
| **用例（Use Case）** | 用户希望将（通常复杂的）数据从客户端传输到服务器。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00017] RequestUpload
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x35（RequestUpload）的配置。 |
| **原理（Rationale）** | 此服务具有请求服务器接受从服务器到客户端（例如测试仪）的数据传输的能力。对该服务的支持是对 [RS_DEXT_00018] 中描述的服务支持的前提条件。 |
| **用例（Use Case）** | 用户希望将（通常复杂的）数据从服务器传输到客户端。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00018] TransferData
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x36（TransferData）的配置。 |
| **原理（Rationale）** | 此服务用于实际执行客户端和服务器之间的数据传输。 |
| **用例（Use Case）** | 用户希望在客户端和服务器之间传输（通常复杂的）数据。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00019] RequestTransferExit
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x37（RequestTransferExit）的配置。 |
| **原理（Rationale）** | 此服务可用于请求终止服务器和客户端之间的数据传输（与数据传输的方向无关）。 |
| **用例（Use Case）** | 用户希望主动结束客户端和服务器之间的数据传输。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00020] WriteMemoryByAddress
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x3D（WriteMemoryByAddress）的配置。 |
| **原理（Rationale）** | 此服务可用于将数据写入服务器的内存。 |
| **用例（Use Case）** | 用户希望覆盖给定服务器内存段中的值。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00021] ControlDTCSetting
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x85（ControlDTCSetting）的配置。 |
| **原理（Rationale）** | 此服务可用于控制服务器中诊断故障代码状态位的更新。 |
| **用例（Use Case）** | 用户希望停止或恢复服务器中诊断故障代码状态位的更新。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00022] ResponseOnEvent
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x86（ResponseOnEvent）的配置。 |
| **原理（Rationale）** | 此服务可用于控制服务器在响应给定事件时传输数据的行为。 |
| **用例（Use Case）** | 用户希望控制服务器在给定事件存在的情况下发送响应消息的方式。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00057] RequestFileTransfer
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 UDS 服务 0x38（RequestFileTransfer）的配置。 |
| **原理（Rationale）** | RequestFileTransfer 服务属于诊断提取支持的 UDS 服务子集。 |
| **用例（Use Case）** | 用户希望指定到/从服务器的文件传输。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00047] 自定义诊断服务
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持自定义诊断服务的定义。 |
| **原理（Rationale）** | 在某些情况下，需要超出 ISO 14229 中标准化的服务集的诊断服务。 |
| **用例（Use Case）** | 用户希望执行不属于 ISO 14229 [2] 规范的诊断功能。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00049] 各个诊断服务的属性
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持针对给定诊断服务的特定属性的定义。 |
| **原理（Rationale）** | 诊断服务的某些属性需要针对给定类别的诊断服务（例如 ReadDataByIdentifier）的每个实例进行单独的微调。 |
| **用例（Use Case）** | 用户希望为给定诊断服务的所有实例定义不同的特定属性。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00050] 给定类别的所有诊断服务的属性
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持针对某一类诊断服务所有实例的公共属性的定义。 |
| **原理（Rationale）** | 诊断服务的某些属性对于特定诊断服务的所有实例都是通用的。如果这些可以单独指定，则在不同诊断服务实例的规范中可能存在不一致。 |
| **用例（Use Case）** | 用户希望在给定诊断服务的所有实例之间共享特定属性。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00051] 诊断服务的子功能
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务子功能的定义。 |
| **原理（Rationale）** | 子功能的定义是诊断服务定义的重要组成部分。此外，某些诊断服务的子功能的存在由适用的 ISO 14229-1 [2] 规定。 |
| **用例（Use Case）** | 用户希望为给定诊断服务指定子功能。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00052] 诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射规范。 |
| **原理（Rationale）** | 诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射将诊断服务的定义与这些服务所涉及的实际应用软件连接起来。因此，此映射是工作流中的重要步骤，并且还为在给定 ECU 上集成软件提供了重要信息。 |
| **用例（Use Case）** | 用户希望将诊断服务映射到应用软件，以表达 ECU 配置的这两个方面之间的概念联系。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00043] 数据元素的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务的数据元素的描述。 |
| **原理（Rationale）** | 数据元素表示在客户端和服务器之间交换的诊断消息内容的正式规范。消息元素的形式化定义允许更清楚地了解实际交换的内容。此外，可以检查在诊断提取中定义的数据元素与最终连接到的应用软件中的数据元素的一致性。 |
| **用例（Use Case）** | 用户希望为在客户端和服务器之间交换的诊断消息的内容创建细粒度模型。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00038] 数组数据类型的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持在 Dcm 和应用软件之间的 DID 发送者/接收者交互中使用数组数据类型。 |
| **原理（Rationale）** | 数组数据类型是 AUTOSAR 应用软件中常用的案例。因此，AUTOSAR 诊断栈以及扩展的诊断提取需要支持 Dcm 和应用软件之间交互的这种情况。 |
| **用例（Use Case）** | 用户希望访问应用程序 PortPrototype 中的数组数据类型，以用于诊断内容的描述（例如诊断数据标识符的定义）。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00039] 诊断服务表
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持指定诊断服务表的能力。 |
| **原理（Rationale）** | 诊断服务表表示适用于相关诊断协议所需的服务量。服务表是诊断栈配置的中心方面，因此应由诊断提取支持。 |
| **用例（Use Case）** | 用户希望在项目上下文中定义特定的诊断协议。就诊断提取而言，这需要定义诊断服务表。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
### 2.4 事件处理需求（Requirements against Event Handling）
本章包含针对诊断事件和诊断故障代码的一般上下文的需求集合。
#### [RS_DEXT_00023] 事件的配置
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断事件的配置。 |
| **原理（Rationale）** | 诊断事件的定义对于 AUTOSAR Dem 的配置至关重要。诊断事件具有丰富的附加信息，需要作为诊断事件定义的一部分提供。此外，诊断事件与其他实体也具有关系，这些关系也需要作为诊断提取的一部分表达。 |
| **用例（Use Case）** | 用户希望正式定义诊断监视器的结果。这是（但不限于）供应商工作流的典型任务。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00024] DTC 的配置
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 DTC 的配置。 |
| **原理（Rationale）** | 诊断栈预见了称为诊断故障代码（DTC）的实体的存在，从简化的角度来看，这些实体代表向诊断测试仪报告的事件。实际上，DTC 具有更复杂的功能，这些功能也需要由诊断提取支持。 |
| **用例（Use Case）** | 用户希望定义一个唯一标识符，表示给定的故障情况，然后可以将其报告给诊断测试仪。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00025] 组合事件
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持映射到单个 DTC 的事件配置。 |
| **原理（Rationale）** | 在某些情况下，多个诊断监视器的结果有助于单个诊断故障代码。为此，诊断提取需要允许诊断事件和诊断故障代码的模型元素之间存在 n:1 关系。 |
| **用例（Use Case）** | 用户希望将多个诊断监视器的结果连接到单个诊断故障代码。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00026] 启用条件
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持启用条件的配置。 |
| **原理（Rationale）** | AUTOSAR 预见了控制诊断事件处理的条件的存在。应可以定义控制特定诊断事件如何启用（即将被处理）或禁用（即处理将被阻止）的条件。 |
| **用例（Use Case）** | 用户希望定义影响诊断事件处理的诊断启用条件。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00027] 存储条件
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持存储条件的配置。 |
| **原理（Rationale）** | AUTOSAR 预见了控制诊断事件是否存储在事件内存中的条件的存在。这些条件是诊断栈配置的一部分。因此，还必须能够在诊断提取中定义存储条件。 |
| **用例（Use Case）** | 用户希望为给定事件定义存储条件。这些存储条件稍后应被用于派生 AUTOSAR 诊断栈的配置。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00028] 启用条件组
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持通过启用条件组来收集启用条件。 |
| **原理（Rationale）** | 启用条件组的定义通常便于处理启用条件。这尤其适用于依赖于共享启用条件集合的诊断事件。因此，诊断提取需要支持稍后用于促进 AUTOSAR 诊断栈配置的启用条件组的定义。 |
| **用例（Use Case）** | 用户希望将多个诊断启用条件分组为单个启用条件组，然后该组可用于在一个步骤中表达给定诊断事件与启用条件定义的关系。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00029] 存储条件组
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持通过存储条件组来收集存储条件。 |
| **原理（Rationale）** | 存储条件组的定义通常便于处理存储条件。这尤其适用于依赖于共享存储条件集合的诊断事件。因此，诊断提取需要支持稍后用于促进 AUTOSAR 诊断栈配置的存储条件组的定义。 |
| **用例（Use Case）** | 用户希望将多个诊断存储条件分组为单个存储条件组，然后该组可用于在一个步骤中表达给定诊断事件与存储条件定义的关系。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00030] 启用条件组的分配
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持将启用条件组分配给事件。 |
| **原理（Rationale）** | 诊断启用条件和启用条件组的存在的结果是应可以建立其中一个与另一个的关系。 |
| **用例（Use Case）** | 用户希望在一个启用条件组的上下文中收集多个诊断启用条件。这样，可以显著简化诊断事件与启用条件之间关系的配置。 |
| **依赖（Dependencies）** | [RS_DEXT_00028] |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00031] 存储条件组的分配
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持将存储条件组分配给事件。 |
| **原理（Rationale）** | 诊断存储条件和存储条件组的存在的结果是应可以建立其中一个与另一个的关系。 |
| **用例（Use Case）** | 用户希望在一个存储条件组的上下文中收集多个诊断存储条件。这样，可以显著简化诊断事件与存储条件之间关系的配置。 |
| **依赖（Dependencies）** | [RS_DEXT_00029] |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00032] 扩展数据记录的配置
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持扩展数据记录的配置。 |
| **原理（Rationale）** | 扩展数据记录（如冻结帧）用于存储与诊断事件相关的附加信息，因此也应由诊断提取支持。 |
| **用例（Use Case）** | 用户希望定义随给定诊断事件一起存储在事件内存中的附加信息。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00033] 快照记录的配置
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持快照记录（冻结帧）的配置。 |
| **原理（Rationale）** | 冻结帧（如扩展数据记录）用于存储与诊断事件相关的附加信息，因此也应由诊断提取支持。 |
| **用例（Use Case）** | 用户希望定义随给定诊断事件一起存储在事件内存中的冻结帧内容。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00034] 数据标识符的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务的数据标识符的描述。 |
| **原理（Rationale）** | 数据标识符的定义是 AUTOSAR 诊断栈配置的中心部分。 |
| **用例（Use Case）** | 用户希望定义具有给定内容的诊断数据标识符。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00035] 动态数据标识符的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务的动态数据标识符的描述。 |
| **原理（Rationale）** | 动态数据标识符的定义是 AUTOSAR 诊断栈配置的中心部分。 |
| **用例（Use Case）** | 用户希望指定诊断数据标识符可用作诊断动态数据标识符。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00036] 常规标识符的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务的常规标识符的描述。 |
| **原理（Rationale）** | 常规标识符的定义是 AUTOSAR 诊断栈配置的中心部分。 |
| **用例（Use Case）** | 用户希望定义与给定诊断常规相关联的常规标识符。这通常扩展到诊断常规本身的建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00037] I/O 标识符的描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断服务的 I/O 标识符的描述。 |
| **原理（Rationale）** | I/O 标识符的定义是 AUTOSAR 诊断栈配置的中心部分。 |
| **用例（Use Case）** | 用户希望定义 I/O 标识符。这通常扩展到诊断数据标识符的建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00053] 诊断事件的去抖
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断事件应如何去抖的规范。 |
| **原理（Rationale）** | 通常，将去抖算法（如 SWS Dem 中所定义）应用于诊断事件的出现，以避免误报的存在。诊断提取也应支持此方面。 |
| **用例（Use Case）** | 用户希望定义如何对给定诊断事件应用去抖。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00054] 操作循环
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持操作循环的规范。 |
| **原理（Rationale）** | AUTOSAR 诊断栈支持操作循环的配置。因此，诊断提取应支持此方面。 |
| **用例（Use Case）** | 用户希望根据项目需要将特定操作循环分配给诊断事件。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00055] 老化
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持老化的规范。 |
| **原理（Rationale）** | 常见的做法是，在对事件连续进行一定次数的"通过"报告后，将其从故障内存中删除。诊断提取应支持此方面。 |
| **用例（Use Case）** | 用户希望指定特定诊断事件应如何进行老化。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00056] 指示器
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持指示器的规范。 |
| **原理（Rationale）** | 诊断栈应支持将某些诊断事件通知给车辆驾驶员。信号应建模为诊断指示器。 |
| **用例（Use Case）** | 用户希望指定如何向驾驶员指示诊断事件。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断事件管理器 [4] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00045] 文本描述
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持为诊断事件和 DTC 属性指定文本描述的能力。 |
| **原理（Rationale）** | 能够将文本描述附加到诊断模型元素的定义上，可以更好地传递有关相应模型元素的用途和语义的知识。 |
| **用例（Use Case）** | 用户希望提供与诊断提取描述相关的特定模型元素的正确文本文档。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00078] 支持在用监测器性能比率
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持在用监测器性能比率（IUMPR）的定义。 |
| **原理（Rationale）** | IUMPR 的定义是 OBD 应用程序的一个组成部分。 |
| **用例（Use Case）** | 用户希望根据给定的诊断事件指定 IUMPR。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此方面的更多信息可在相应的法律出版物 [5] 中找到。 |
| **追溯（Tracing）** | c() |
### 2.5 会话和安全需求（Requirements against Sessions and Security）
本章包含针对诊断会话和安全上下文的需求集合。
#### [RS_DEXT_00040] 诊断会话
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持指定诊断会话的能力。 |
| **原理（Rationale）** | 诊断会话的配置代表 AUTOSAR 诊断栈配置的重要角度。因此，诊断提取需要支持此方面的建模。 |
| **用例（Use Case）** | 用户希望将诊断会话定义为项目的一部分。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00041] 访问权限
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持指定访问权限的能力。 |
| **原理（Rationale）** | 访问权限的配置代表 AUTOSAR 诊断栈配置的重要角度。因此，诊断提取需要支持此方面的建模。 |
| **用例（Use Case）** | 用户希望定义需要访问权限的特定诊断功能（例如 DID 或 RID）作为项目的一部分。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00042] 安全级别
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持指定安全级别的能力。 |
| **原理（Rationale）** | 安全级别的配置代表 AUTOSAR 诊断栈配置的重要角度。因此，诊断提取需要支持此方面的建模。 |
| **用例（Use Case）** | 用户希望将安全级别定义为项目的一部分。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00079] 支持环境条件
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持启用诊断功能处理的环境条件的制定。 |
| **原理（Rationale）** | 某些诊断功能只有在车辆处于特定状态时才是安全的。因此，应可以在诊断提取的级别上指定执行诊断功能的条件。 |
| **用例（Use Case）** | 用户希望执行需要车辆停止的诊断功能（即条件是车速 == 0）。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 诊断通信管理器 [3] 的规范中找到。 |
| **追溯（Tracing）** | c() |
### 2.6 功能抑制支持需求（Requirements against the Support for Function Inhibition）
本章包含针对诊断提取中功能抑制支持的需求集合。
#### [RS_DEXT_00060] 功能
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持为了功能抑制目的而定义功能。该功能应具有标识符，可以进一步在配置下游进行识别。 |
| **原理（Rationale）** | 为了能够定义功能抑制，必须具有表示功能的模型元素。 |
| **用例（Use Case）** | 用户希望指定一个功能，然后可以在功能抑制范围内使用。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 功能抑制管理器 [6] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00061] 功能与诊断事件之间的关系
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持功能与如果抑制相应功能则不再报告的诊断事件之间的关系。应可以以不同的粒度级别表达功能与相应事件之间的关系。这意味着应可以引用单个诊断事件以及整个诊断事件集合。 |
| **原理（Rationale）** | 禁止报告诊断事件是 Fim 的核心功能。应可以在诊断提取中描述此方面。 |
| **用例（Use Case）** | 用户希望指定特定功能如何抑制给定诊断事件集合的报告。而不是必须引用每个预期的诊断事件，用户希望通过引用由诊断提取形式化的事件组来简化此操作。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 功能抑制管理器 [6] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00062] 当 Dem 配置尚不可用时 Fim 的预配置
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 在诊断提取中创建 Fim 配置的时间点，可能会出现诊断提取中 Dem 的配置尚不存在的情况。因此，没有可用于 Fim 预配置创建的诊断事件的形式化表示。因此，诊断提取应提供定义诊断事件占位符的能力，这些占位符可用于 Fim 的预配置中，并在诊断提取中的 Dem 配置可用时替换为真正的诊断事件。 |
| **原理（Rationale）** | 分散配置的概念支持这样的想法：诊断提取的某些部分应彼此独立地定义，然后稍后合并以形成整个诊断栈的配置。 |
| **用例（Use Case）** | 用户希望在定义实际诊断事件之前对功能与诊断事件之间的关系进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 功能抑制管理器 [6] 的规范中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00063] Fim 级别的功能与软件组件之间的关系
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应提供定义功能到软件组件的映射的方法。 |
| **原理（Rationale）** | Fim 中功能的概念相当抽象，需要进一步澄清 AUTOSAR ECU 上应用软件的哪一部分实际对应于它。 |
| **用例（Use Case）** | 用户希望指定 Fim 方面的哪个功能由应用软件的哪一部分表示。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 更多信息可在 AUTOSAR 功能抑制管理器 [6] 的规范中找到。 |
| **追溯（Tracing）** | c() |
### 2.7 J1939 诊断支持需求（Requirements against the Support for diagnostics on J1939）
本章包含针对诊断提取中 J1939 诊断支持的需求集合。
#### [RS_DEXT_00064] SPN 的定义
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 SPN 的定义以及系统描述中通信项及其物理属性的表示。 |
| **原理（Rationale）** | 所谓的可疑参数编号（SPN）是 J1939 诊断中的一个重要概念。SPN 也可以引用物理属性。 |
| **用例（Use Case）** | 用户希望通过诊断提取指定 J1939 SPN。用户希望指定如何在系统描述中表示 SPN。用户希望确保预期的物理属性在系统描述中可用。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00065] J1939 上冻结帧的定义
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 J1939 上冻结帧（常规和扩展）的定义。 |
| **原理（Rationale）** | J1939 上冻结帧的定义是 J1939 诊断栈配置的重要组成部分。 |
| **用例（Use Case）** | 用户希望定义 J1939 冻结帧的内容。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00066] J1939 控制器应用与软件组件之间的映射
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 J1939 控制器应用的概念与由单个软件组件表示的 AUTOSAR 应用软件的一部分之间的映射规范。 |
| **原理（Rationale）** | 控制器应用和软件组件之间的映射是 AUTOSAR 和 J1939 技术领域之间"架桥"的重要组成部分。功能单元的不同定义方法应相互映射。 |
| **用例（Use Case）** | 用户希望指定控制器应用与 AUTOSAR 应用软件的一部分之间的映射。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00067] J1939 DTC 的定义
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持在 J1939 域中定义具有其所有特定属性的 DTC。 |
| **原理（Rationale）** | DTC 的定义是诊断栈的重要组成部分。J1939 域中的 DTC 具有明显不同于 UDS DTC 等属性的特定属性。 |
| **用例（Use Case）** | 用户希望在诊断提取的 J1939 诊断栈配置中指定 DTC。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
### 2.8 OBD 诊断服务支持需求（Requirements against the Support for OBD Diagnostic Services）
本章包含根据 [7] 的 OBD 诊断服务上下文的需求集合。
#### [RS_DEXT_00068] 诊断参数标识符的定义
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断参数标识符（PID）的正式定义。PID 的正式表示应具有数字标识符，该标识符应用于下游配置。 |
| **原理（Rationale）** | PID 在 OBD 服务建模中起着核心作用。PID 的定义是支持 OBD 服务的关键。 |
| **用例（Use Case）** | 用户希望定义 PID 以便对 OBD 服务进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00069] 支持 OBD 模式 0x01（RequestCurrentPowertrainDiagnosticData）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x01（也称为 RequestCurrentPowertrainDiagnosticData）的建模。 |
| **原理（Rationale）** | OBD 模式 0x01 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x01 进行建模。 |
| **依赖（Dependencies）** | [RS_DEXT_00068] |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00070] 支持 OBD 模式 0x02（RequestPowertrainFreezeFrameData）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x02（也称为 RequestPowertrainFreezeFrameData）的建模。 |
| **原理（Rationale）** | OBD 模式 0x02 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x02 进行建模。 |
| **依赖（Dependencies）** | [RS_DEXT_00068] |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00071] 支持 OBD 模式 0x03 / 0x07 / 0x0A（RequestEmissionRelatedDiagnosticTroubleCodes）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x03 / 0x07 / 0x0A（也称为 RequestEmissionRelatedDiagnosticTroubleCodes）的建模。 |
| **原理（Rationale）** | OBD 模式 0x03 / 0x07 / 0x0A 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x03 / 0x07 / 0x0A 进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00072] 支持 OBD 模式 0x04（ClearResetEmissionRelatedDiagnosticInformation）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x04（也称为 ClearResetEmissionRelatedDiagnosticInformation）的建模。 |
| **原理（Rationale）** | OBD 模式 0x04 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x04 进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00073] 支持 OBD 模式 0x06（RequestOnBoardMonitoringTestResults）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x06（也称为 RequestOnBoardMonitoringTestResults）的建模。 |
| **原理（Rationale）** | OBD 模式 0x06 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x06 进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00074] 支持 OBD 模式 0x08（RequestControlOfOnBoardDevice）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x08（也称为 RequestControlOfOnBoardDevice）的建模。 |
| **原理（Rationale）** | OBD 模式 0x08 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x08 进行建模。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00075] 支持 OBD 模式 0x09（RequestVehicleInformation）
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持 OBD 模式 0x09（也称为 RequestVehicleInformation）的建模。 |
| **原理（Rationale）** | OBD 模式 0x09 是 OBD 功能的强制性部分，因此需要在诊断提取中表示此模式。 |
| **用例（Use Case）** | 用户希望在诊断提取中对 OBD 服务 0x09 进行建模。 |
| **依赖（Dependencies）** | [RS_DEXT_00076] |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00076] 诊断测试标识符的定义
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应支持诊断测试标识符（TID）的定义。 |
| **原理（Rationale）** | OBD 模型 0x09 的定义需要 TID 的定义。 |
| **用例（Use Case）** | 用户希望定义稍后用于 OBD 服务 0x09 定义中的 TID。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | 有关此诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| **追溯（Tracing）** | c() |
#### [RS_DEXT_00077] 描述 UDS 用于支持 WWH-OBD
| 字段 | 内容 |
|------|------|
| **类型（Type）** | valid |
| **描述（Description）** | 诊断提取应指定应如何使用 UDS 诊断服务来实现 WWH-OBD。 |
| **原理（Rationale）** | WWH-OBD 的实现基本上意味着使用 UDS 服务来模拟 OBD 服务的行为。为了协调为此目的使用 UDS 服务，诊断提取应提供尽可能消除模糊配置变体的规范。 |
| **用例（Use Case）** | 用户希望利用 WWH-OBD 在通常支持 UDS 诊断服务的 ECU 上。用户希望利用阐明如何在诊断提取中为此目的配置 UDS 服务的规范。 |
| **依赖（Dependencies）** | – |
| **支持材料（Supporting Material）** | – |
| **追溯（Tracing）** | c() |
---
## 附录 A 约束和规范项历史（History of Constraints and Specification Items）
### A.1 根据 AUTOSAR R4.2.1 的本文档约束历史
#### A.1.1 在 R4.2.1 中新增的可追溯项
| ID | 标题 |
|----|------|
| [RS_DEXT_00001] | 诊断数据交换 |
| [RS_DEXT_00002] | 分布式软件开发过程 |
| [RS_DEXT_00003] | SessionControl |
| [RS_DEXT_00004] | ECUReset |
| [RS_DEXT_00005] | ClearDiagnosticInformation |
| [RS_DEXT_00006] | ReadDTCInformation |
| [RS_DEXT_00007] | ReadDataByIdentifier |
| [RS_DEXT_00008] | ReadMemoryByAddress |
| [RS_DEXT_00009] | SecurityAccess |
| [RS_DEXT_00010] | CommunicationControl |
| [RS_DEXT_00011] | ReadDataByPeriodicIdentifier |
| [RS_DEXT_00012] | DynamicallyDefineDataIdentifier |
| [RS_DEXT_00013] | WriteDataByIdentifier |
| [RS_DEXT_00014] | IOControl |
| [RS_DEXT_00015] | RoutineControl |
| [RS_DEXT_00016] | RequestDownload |
| [RS_DEXT_00017] | RequestUpload |
| [RS_DEXT_00018] | TransferData |
| [RS_DEXT_00019] | RequestTransferExit |
| [RS_DEXT_00020] | WriteMemoryByAddress |
| [RS_DEXT_00021] | ControlDTCSetting |
| [RS_DEXT_00022] | ResponseOnEvent |
| [RS_DEXT_00023] | 事件的配置 |
| [RS_DEXT_00024] | DTC 的配置 |
| [RS_DEXT_00025] | 组合事件 |
| [RS_DEXT_00026] | 启用条件 |
| [RS_DEXT_00027] | 存储条件 |
| [RS_DEXT_00028] | 启用条件组 |
| [RS_DEXT_00029] | 存储条件组 |
| [RS_DEXT_00030] | 启用条件组的分配 |
| [RS_DEXT_00031] | 存储条件组的分配 |
| [RS_DEXT_00032] | 扩展数据记录的配置 |
| [RS_DEXT_00033] | 快照记录的配置 |
| [RS_DEXT_00034] | 数据标识符的描述 |
| [RS_DEXT_00035] | 动态数据标识符的描述 |
| [RS_DEXT_00036] | 常规标识符的描述 |
| [RS_DEXT_00037] | I/O 标识符的描述 |
| [RS_DEXT_00038] | 数组数据类型的描述 |
| [RS_DEXT_00039] | 诊断服务表 |
| [RS_DEXT_00040] | 诊断会话 |
| [RS_DEXT_00041] | 访问权限 |
| [RS_DEXT_00042] | 安全级别 |
| [RS_DEXT_00043] | 数据元素的描述 |
| [RS_DEXT_00044] | 相关 ECU-C 参数的派生 |
| [RS_DEXT_00045] | 文本描述 |
| [RS_DEXT_00046] | 变体 |
| [RS_DEXT_00047] | 自定义诊断服务 |
| [RS_DEXT_00048] | 特定于一个 ECU 的诊断属性 |
| [RS_DEXT_00049] | 各个诊断服务的属性 |
| [RS_DEXT_00050] | 给定类别的所有诊断服务的属性 |
| [RS_DEXT_00051] | 诊断服务的子功能 |
| [RS_DEXT_00052] | 诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射 |
| [RS_DEXT_00053] | 诊断事件的去抖 |
| [RS_DEXT_00054] | 操作循环 |
| [RS_DEXT_00055] | 老化 |
| [RS_DEXT_00056] | 指示器 |
| [RS_DEXT_00057] | RequestFileTransfer |
#### A.1.2 在 R4.2.1 中新增的可追溯项（重复节标题）
无（none）
#### A.1.3 在 R4.2.1 中删除的可追溯项
无（none）
### A.2 根据 AUTOSAR R4.2.2 的本文档约束历史
#### A.2.1 在 R4.2.2 中新增的可追溯项
无（none）
#### A.2.2 在 R4.2.2 中更改的可追溯项
| ID | 标题 |
|----|------|
| [RS_DEXT_00003] | SessionControl |
| [RS_DEXT_00004] | ECUReset |
| [RS_DEXT_00005] | ClearDiagnosticInformation |
| [RS_DEXT_00006] | ReadDTCInformation |
| [RS_DEXT_00007] | ReadDataByIdentifier |
| [RS_DEXT_00008] | ReadMemoryByAddress |
| [RS_DEXT_00009] | SecurityAccess |
| [RS_DEXT_00010] | CommunicationControl |
| [RS_DEXT_00011] | ReadDataByPeriodicIdentifier |
| [RS_DEXT_00012] | DynamicallyDefineDataIdentifier |
| [RS_DEXT_00013] | WriteDataByIdentifier |
| [RS_DEXT_00014] | IOControl |
| [RS_DEXT_00015] | RoutineControl |
| [RS_DEXT_00016] | RequestDownload |
| [RS_DEXT_00017] | RequestUpload |
| [RS_DEXT_00018] | TransferData |
| [RS_DEXT_00019] | RequestTransferExit |
| [RS_DEXT_00020] | WriteMemoryByAddress |
| [RS_DEXT_00021] | ControlDTCSetting |
| [RS_DEXT_00022] | ResponseOnEvent |
#### A.2.3 在 R4.2.2 中删除的可追溯项
无（none）
#### A.2.4 在 R4.2.2 中新增的约束
无（none）
#### A.2.5 在 R4.2.2 中更改的约束
无（none）
#### A.2.6 在 R4.2.2 中删除的约束
无（none）
### A.3 根据 AUTOSAR R4.3.0 的本文档约束历史
#### A.3.1 在 R4.3.0 中新增的可追溯项
| ID | 标题 |
|----|------|
| [RS_DEXT_00058] | 表明 ECU 支持 OBD |
| [RS_DEXT_00059] | 支持不同的协议 |
| [RS_DEXT_00060] | 功能 |
| [RS_DEXT_00061] | 功能与诊断事件之间的关系 |
| [RS_DEXT_00062] | 当 Dem 配置尚不可用时 Fim 的预配置 |
| [RS_DEXT_00063] | Fim 级别的功能与软件组件之间的关系 |
| [RS_DEXT_00064] | SPN 的定义 |
| [RS_DEXT_00065] | J1939 上冻结帧的定义 |
| [RS_DEXT_00066] | J1939 控制器应用与软件组件之间的映射 |
| [RS_DEXT_00067] | J1939 DTC 的定义 |
| [RS_DEXT_00068] | 诊断参数标识符的定义 |
| [RS_DEXT_00069] | 支持 OBD 模式 0x01（RequestCurrentPowertrainDiagnosticData） |
| [RS_DEXT_00070] | 支持 OBD 模式 0x02（RequestPowertrainFreezeFrameData） |
| [RS_DEXT_00071] | 支持 OBD 模式 0x03 / 0x07 / 0x0A（RequestEmissionRelatedDiagnosticTroubleCodes） |
| [RS_DEXT_00072] | 支持 OBD 模式 0x04（ClearResetEmissionRelatedDiagnosticInformation） |
| [RS_DEXT_00073] | 支持 OBD 模式 0x06（RequestOnBoardMonitoringTestResults） |
| [RS_DEXT_00074] | 支持 OBD 模式 0x08（RequestControlOfOnBoardDevice） |
| [RS_DEXT_00075] | 支持 OBD 模式 0x09（RequestVehicleInformation） |
| [RS_DEXT_00076] | 诊断测试标识符的定义 |
| [RS_DEXT_00077] | 描述 UDS 用于支持 WWH-OBD |
| [RS_DEXT_00078] | 支持在用监测器性能比率 |
| [RS_DEXT_00079] | 支持环境条件 |
#### A.3.2 在 R4.3.0 中更改的可追溯项
| ID | 标题 |
|----|------|
| [RS_DEXT_00001] | 诊断数据交换 |
| [RS_DEXT_00023] | 事件的配置 |
| [RS_DEXT_00024] | DTC 的配置 |
| [RS_DEXT_00025] | 组合事件 |
| [RS_DEXT_00026] | 启用条件 |
| [RS_DEXT_00027] | 存储条件 |
| [RS_DEXT_00028] | 启用条件组 |
| [RS_DEXT_00029] | 存储条件组 |
| [RS_DEXT_00030] | 启用条件组的分配 |
| [RS_DEXT_00031] | 存储条件组的分配 |
| [RS_DEXT_00032] | 扩展数据记录的配置 |
| [RS_DEXT_00033] | 快照记录的配置 |
| [RS_DEXT_00034] | 数据标识符的描述 |
| [RS_DEXT_00035] | 动态数据标识符的描述 |
| [RS_DEXT_00036] | 常规标识符的描述 |
| [RS_DEXT_00037] | I/O 标识符的描述 |
| [RS_DEXT_00038] | 数组数据类型的描述 |
| [RS_DEXT_00039] | 诊断服务表 |
| [RS_DEXT_00040] | 诊断会话 |
| [RS_DEXT_00041] | 访问权限 |
| [RS_DEXT_00042] | 安全级别 |
| [RS_DEXT_00043] | 数据元素的描述 |
| [RS_DEXT_00044] | 相关 ECU-C 参数的派生 |
| [RS_DEXT_00045] | 文本描述 |
| [RS_DEXT_00046] | 变体 |
| [RS_DEXT_00047] | 自定义诊断服务 |
| [RS_DEXT_00048] | 特定于一个 ECU 的诊断属性 |
| [RS_DEXT_00049] | 各个诊断服务的属性 |
| [RS_DEXT_00050] | 给定类别的所有诊断服务的属性 |
| [RS_DEXT_00051] | 诊断服务的子功能 |
| [RS_DEXT_00052] | 诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射 |
| [RS_DEXT_00053] | 诊断事件的去抖 |
| [RS_DEXT_00054] | 操作循环 |
| [RS_DEXT_00055] | 老化 |
| [RS_DEXT_00056] | 指示器 |
| [RS_DEXT_00057] | RequestFileTransfer |
#### A.3.3 在 R4.3.0 中删除的可追溯项
| ID | 标题 |
|----|------|
| [RS_DEXT_00002] | 分布式软件开发过程 |
#### A.3.4 在 R4.3.0 中新增的约束
无（none）
#### A.3.5 在 R4.3.0 中更改的约束
无（none）
#### A.3.6 在 R4.3.0 中删除的约束
无（none）
---
## 翻译说明
1. **文档结构**：本文档为 AUTOSAR RS（需求规范）类文档，主要描述诊断提取模板（DEXT）的需求。
2. **需求 ID**：所有 RS_DEXT_xxxxx 格式的需求 ID 保持原样未翻译。
3. **追溯 ID**：所有 RS_Main_xxxxx、RS_BRF_xxxxx 保持原样。
4. **缩写**：DCM、DEM、Dcm、Fim、Dem、BSW、ECU、OBD、UDS、J1939、SPN、PID、TID、WWH-OBD、IUMPR 等保持英文。
5. **类名与属性名**：ApplicationSwComponentType、PortPrototype、DiagnosticEvent 等 UML 类名保持英文。
6. **ARXML 标签**：保持原样。
7. **服务名与协议标识**：0x10 SessionControl、0x11 ECUReset、0x14 ClearDiagnosticInformation、0x19 ReadDTCInformation 等服务名遵循 ISO 14229 标准约定，保持英文。
8. **附录 A**：完整翻译所有可追溯项的历史变更表格。
Reference in New Issue View Git Blame Copy Permalink