Diagnostic Extract Requirements
参考文献
[1] Standardization Template
AUTOSAR_FO_TPS_StandardizationTemplate
[2] Unified diagnostic services (UDS) - Part 1: Specification and requirements (Release 2006-12)
https://www.iso.org
[3] Specification of Diagnostic Communication Manager
AUTOSAR_CP_SWS_DiagnosticCommunicationManager
[4] Specification of Diagnostic Event Manager
AUTOSAR_CP_SWS_DiagnosticEventManager
[5] Motor Vehicle Pollution Control Devices
https://www.iso.org
[6] Specification of Function Inhibition Manager
AUTOSAR_CP_SWS_FunctionInhibitionManager
[7] Road vehicles - Communication between vehicle and external equipment for emission-related diagnostic - Part 5: Emission-related diagnostic services
https://www.iso.org
1. 简介
1.1. 本文档的范围
本文档收集对诊断提取（Diagnostic Extract）的需求。
诊断提取的主要目标是在参与诊断开发过程的各方之间交换诊断数据，以支持诊断模块 DCM 和 DEM 的自动代码生成过程。
此外，诊断提取还用于支持诊断功能的分布式开发过程。
下面再次列出诊断提取使用中的关键方面：
- 为 DCM 和 DEM 交换诊断数据
- 支持诊断功能的分布式开发
1.2. 文档约定
AUTOSAR 文档中需求的表示遵循 TPS_STDT_00078 所规定的表格，参见标准模板（Standardization Template）的「追溯支持」（Support for Traceability）一章（[1]）。
应使用 TPS_STDT_00053 中规定的用于表达义务的助动词形式来表示需求，参见标准模板（Standardization Template）的「追溯支持」（Support for Traceability）一章（[1]）。
1.3. 指南
应引用既有的规范（以单个需求的形式）。与这些规范的差异作为附加需求加以规定。所有需求应具有以下特性：
在单个需求之内或其他需求之中，需求不应重复。
所有需求应只允许一种解释。所使用的不在术语表中的技术术语必须加以定义。
每个需求应只包含一个需求。如果一个需求不能再被拆分为更多的需求，则它是原子的。
需求应能通过分析、评审或测试加以验证。
需求的来源和状态应始终可见。
1.4. 需求追溯
本文档目前不提供需求追溯。需求追溯将在后续修订版中加入。
2. 需求
2.1. 与 AUTOSAR 特性的关系
本节描述需求应当覆盖的特性列表：
- AUTOSAR 应提供数据交换格式，以支持大型跨公司和公司内部开发团队之间的协同工作（work-share）
- AUTOSAR 应为引导加载程序（boot loader）提供接口
- AUTOSAR 服务应支持系统诊断功能
这是诊断提取需求需要满足的特性和主要需求的一个简短节选。
2.2. 通用需求
本章包含一组适用于诊断提取所有方面的通用需求。
2.2.1. 诊断数据交换（Diagnostic data exchange）
| 描述 |
诊断提取应支持诊断相关信息的交换。 |
| 理由 |
在绝大多数情况下，AUTOSAR 诊断栈的配置是 OEM 与相应 ECU 供应商共同完成的工作。为此，OEM 和供应商需要能够以尽可能小的摩擦交换配置信息。一般而言，特定 OEM 与特定供应商的任意组合都是可能的。要使之可行，就必须在必要的程度上标准化相关各方之间交换的数据。 |
| 用例 |
1. OEM 向供应商交付部分配置，期望供应商填入缺失的部分和/或评审并（在适用时）覆盖 OEM 已完成的配置。
2. 供应商将评审后的诊断配置反馈给 OEM。
3. 供应商将诊断栈的最终配置交付给 OEM，使后者能够从该数据推导出测试仪（tester）配置。
4. 供应商或 OEM 使用诊断提取在公司内部的相关责任组织部门之间交换信息。以此方式支持公司内部的分布式软件开发。 |
| 依赖项 |
- |
| 支撑材料 |
- |
| 描述 |
诊断提取应支持为 Dcm、Fim 和 Dem 推导相关的 ECU-C 参数。 |
| 理由 |
就定义而言，ECUC 层级上 AUTOSAR 诊断栈的具体配置是不可移植的。它非常聚焦于反映特定诊断栈具体实现的细节。这种做法是合理的，因为它允许比通用且更抽象的方法更深入地优化软件栈。然而，更抽象的方法在跨不同组织乃至一定程度上跨项目的可交换性方面有其他优势。因此，合理的做法是为诊断栈的配置定义一种通用的、更抽象的方式，其最终目标是在很大程度上推导出具体的、不可移植的特定配置。 |
| 用例 |
用户希望以一种可以与项目伙伴交换的通用方式规定诊断栈的配置，交换方式类似于例如系统描述的交换。用户希望在与系统提取相同的概念层级上规定诊断信息，并且希望在适用时从诊断配置关联到系统提取的元素。最后，用户希望获取这一在较高概念层级上描述的信息，并将其用于推导 ECUC 这一具体得多（因而不太可移植）层级上的配置信息。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.2.3. 特定于单个 ECU 的诊断属性（Diagnostic Properties that are specific for one ECU）
| 描述 |
诊断提取应支持定义特定于给定 ECU 的诊断属性。 |
| 理由 |
某些属性因 ECU 而异。当诊断提取同时覆盖多个 ECU 时，必须能够逐个表达它们的诊断属性。 |
| 用例 |
用户希望规定一个由多个 ECU 组成的诊断提取，并为其中包含的每个 ECU 单独定义某些属性。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.2.4. 指示 ECU 支持 OBD（Indicate that an ECU supports ODB）
| 描述 |
诊断提取应允许定义给定 ECU 是否（以及如何）支持 OBD。 |
| 理由 |
下游配置中存在某些开关，它们的设置依赖于给定 ECU 的 OBD 能力信息。 |
| 用例 |
用户希望规定 OBD 对给定 ECU 的适用性。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.2.5. 支持不同的协议（Support for different protocols）
| 描述 |
诊断提取应支持定义不同的诊断协议（例如 UDS、OBD 等）及其相互之间的优先级。 |
| 理由 |
不同协议应以不同的优先级处理。这要求对诊断协议及其与诊断提取中已有的其他模型元素的关系进行形式化定义。 |
| 用例 |
用户希望定义一个支持不同诊断协议的诊断提取。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3. 对支持 UDS 诊断服务的需求
本章包含一组针对 [2] 所述 UDS 诊断服务上下文的需求。
2.3.1. SessionControl（SessionControl）
| 描述 |
诊断提取应支持配置 UDS 服务 0x10（SessionControl）。 |
| 理由 |
不同诊断会话的使用非常普遍，因此诊断提取模板需要予以支持。 |
| 用例 |
支持从一个诊断会话切换到另一个诊断会话。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.2. ECUReset（ECUReset）
| 描述 |
诊断提取应支持配置 UDS 服务 0x11（ECUReset）。 |
| 理由 |
复位服务器（server）的能力对于进行诊断会话至关重要。 |
| 用例 |
用户希望复位已连接的服务器。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| 描述 |
诊断提取应支持配置 UDS 服务 0x14（ClearDiagnosticInformation）。 |
| 理由 |
该服务允许清除服务器的诊断存储器。这是一项经常使用的功能。 |
| 用例 |
用户希望清除已连接服务器上的诊断存储器。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
| 描述 |
诊断提取应支持配置 UDS 服务 0x19（ReadDTCInformation）。 |
| 理由 |
该服务允许访问服务器上诊断故障码（DTC）的状态。这是一项经常使用的功能。 |
| 用例 |
用户希望通过测试仪访问服务器上的 DTC 信息。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.5. ReadDataByIdentifier（ReadDataByIdentifier）
| 描述 |
诊断提取应支持配置 UDS 服务 0x22（ReadDataByIdentifier）。 |
| 理由 |
该服务允许按照给定数据标识符的定义读取服务器上的取值。这是一项经常使用的功能。 |
| 用例 |
用户希望从服务器读取与给定数据标识符相关联的取值。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.6. ReadMemoryByAddress（ReadMemoryByAddress）
| 描述 |
诊断提取应支持配置 UDS 服务 0x23（ReadMemoryByAddress）。 |
| 理由 |
该服务允许访问服务器上一段存储器的内容。这是一项经常使用的功能。 |
| 用例 |
用户希望从诊断服务器读取存储器内容。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.7. SecurityAccess（SecurityAccess）
| 描述 |
诊断提取应支持配置 UDS 服务 0x27（SecurityAccess）。 |
| 理由 |
该服务允许对应用了特定安全限制的数据和诊断服务进行访问。 |
| 用例 |
应用安全限制将数据和诊断服务的访问限定给被授权的人员。该限制可以出于功能安全和/或信息安全的原因而施加。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.8. CommunicationControl（CommunicationControl）
| 描述 |
诊断提取应支持配置 UDS 服务 0x28（CommunicationControl）。 |
| 理由 |
该服务允许开启和关闭某些消息（例如应用相关通信）的通信。 |
| 用例 |
用户希望关闭正常的通信消息。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.9. ReadDataByPeriodicIdentifier（ReadDataByPeriodicIdentifier）
| 描述 |
诊断提取应支持配置 UDS 服务 0x2A（ReadDataByPeriodicIdentifier）。 |
| 理由 |
该服务允许按照周期性数据标识符的定义请求服务器周期性地传输诊断数据。 |
| 用例 |
用户希望访问周期性传输的诊断数据，而无需逐次请求每次传输。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.10. DynamicallyDefineDataIdentifier（DynamicallyDefineDataIdentifier）
| 描述 |
诊断提取应支持配置 UDS 服务 0x2C（DynamicallyDefineDataIdentifier）。 |
| 理由 |
该服务允许以即席方式定义一个数据标识符，随后可由相应的诊断服务访问。 |
| 用例 |
与在诊断会话之前预先定义数据标识符的情形不同，该服务允许在诊断会话进行期间定义数据标识符。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.11. WriteDataByIdentifier（WriteDataByIdentifier）
| 描述 |
诊断提取应支持配置 UDS 服务 0x2E（WriteDataByIdentifier）。 |
| 理由 |
该服务允许通过与诊断数据标识符的关联来识别诊断数据，并将其传输给诊断服务器。这是一项经常使用的功能。 |
| 用例 |
用户希望将与给定数据标识符相关联的数据传输给诊断服务器。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.12. IOControl（IOControl）
| 描述 |
诊断提取应支持配置 UDS 服务 0x2F（IOControl）。 |
| 理由 |
该服务允许用诊断测试仪提供的取值替代 IO 层的取值。 |
| 用例 |
用户希望旁路一个传感器并代之以替代取值。用户希望替代提供给给定执行器的取值。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.13. RoutineControl（RoutineControl）
| 描述 |
诊断提取应支持配置 UDS 服务 0x31（RoutineControl）。 |
| 理由 |
该服务可用于在服务器上执行特定的代码。 |
| 用例 |
用户希望在远程服务器上执行代码，以实现超出任何「简单」数据交换服务所能提供的给定功能。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.14. RequestDownload（RequestDownload）
| 描述 |
诊断提取应支持配置 UDS 服务 0x34（RequestDownload）。 |
| 理由 |
该服务能够请求服务器接受从客户端（例如测试仪）到服务器的一段数据的传输。对该服务的支持是对§2.3.16所述服务支持的前提。 |
| 用例 |
用户希望将一段（大多较为复杂的）数据从客户端传输到服务器。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.15. RequestUpload（RequestUpload）
| 描述 |
诊断提取应支持配置 UDS 服务 0x35（RequestUpload）。 |
| 理由 |
该服务能够请求服务器接受从服务器到客户端（例如测试仪）的一段数据的传输。对该服务的支持是对§2.3.16所述服务支持的前提。 |
| 用例 |
用户希望将一段（大多较为复杂的）数据从服务器传输到客户端。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.16. TransferData（TransferData）
| 描述 |
诊断提取应支持配置 UDS 服务 0x36（TransferData）。 |
| 理由 |
该服务用于实际执行客户端与服务器之间的数据传输。 |
| 用例 |
用户希望在客户端与服务器之间传输一段（大多较为复杂的）数据。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.17. RequestTransferExit（RequestTransferExit）
| 描述 |
诊断提取应支持配置 UDS 服务 0x37（RequestTransferExit）。 |
| 理由 |
该服务可用于请求终止服务器与客户端之间的数据传输（与数据传输的方向无关）。 |
| 用例 |
用户希望主动结束客户端与服务器之间的数据传输。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.18. WriteMemoryByAddress（WriteMemoryByAddress）
| 描述 |
诊断提取应支持配置 UDS 服务 0x3D（WriteMemoryByAddress）。 |
| 理由 |
该服务可用于将一段数据写入服务器的存储器。 |
| 用例 |
用户希望覆盖服务器给定存储器段中的取值。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.19. ControlDTCSetting（ControlDTCSetting）
| 描述 |
诊断提取应支持配置 UDS 服务 0x85（ControlDTCSetting）。 |
| 理由 |
该服务可用于控制服务器中诊断故障码状态位的更新。 |
| 用例 |
用户希望停止或恢复服务器中诊断故障码状态位的更新。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.20. ResponseOnEvent（ResponseOnEvent）
| 描述 |
诊断提取应支持配置 UDS 服务 0x86（ResponseOnEvent）。 |
| 理由 |
该服务可用于控制服务器针对给定事件的发生而传输数据的行为。 |
| 用例 |
用户希望控制服务器在给定事件存在时如何发送响应消息的行为。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.21. RequestFileTransfer（RequestFileTransfer）
| 描述 |
诊断提取应支持配置 UDS 服务 0x38（RequestFileTransfer）。 |
| 理由 |
RequestFileTransfer 服务是诊断提取所支持的 UDS 服务子集的组成部分。 |
| 用例 |
用户希望规定与服务器之间的文件传输。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.3.22. 自定义诊断服务（Custom Diagnostic Service）
| 描述 |
诊断提取应支持定义自定义的诊断服务。 |
| 理由 |
在某些情况下，需要 ISO 14229 标准化服务集之外的诊断服务。 |
| 用例 |
用户希望执行一项不属于 ISO 14229 [2] 规范的诊断功能。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3.23. 单个诊断服务的属性（Properties of individual diagnostic services）
| 描述 |
诊断提取应支持定义特定于给定诊断服务的属性。 |
| 理由 |
诊断服务的某些属性需要针对给定类别诊断服务的每个实例逐一微调，例如 ReadDataByIdentifier。 |
| 用例 |
用户希望为给定诊断服务的所有实例以不同的方式定义特定属性。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3.24. 同类所有诊断服务的属性（Properties of all diagnostic services of a given kind）
| 描述 |
诊断提取应支持定义对某一类别诊断服务的所有实例通用的属性。 |
| 理由 |
诊断服务的某些属性对该类别诊断服务的所有实例是通用的。如果这些属性可以逐实例规定，则不同实例的规范之间存在不一致的潜在风险。 |
| 用例 |
用户希望定义在给定诊断服务的所有实例之间共享的特定属性。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3.25. 诊断服务的子功能（Subfunctions of Diagnostic Services）
| 描述 |
诊断提取应支持定义诊断服务的子功能（subfunction）。 |
| 理由 |
子功能的定义是诊断服务定义的重要组成部分。此外，某些诊断服务是否存在子功能由适用的 ISO 14229-1 [2] 规定。 |
| 用例 |
用户希望为给定的诊断服务规定子功能。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3.26. 数据元素的描述（Description of data elements）
| 描述 |
诊断提取应支持为诊断服务描述数据元素。 |
| 理由 |
数据元素是客户端与服务器之间交换的诊断消息内容的形式化规范。对消息元素的形式化定义可以更清楚地了解实际交换的内容。此外，还可以检查诊断提取中定义的数据元素与诊断服务最终所连接的应用软件中数据元素的一致性。 |
| 用例 |
用户希望建立客户端与服务器之间交换的诊断消息内容的细粒度模型。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.3.27. DID 与 RID 嵌套元素的描述（Description of nested elements of DIDs and RIDs）
| 描述 |
诊断提取应支持为 Dcm 与应用软件之间的 DID 发送者/接收者和 RID 例程交互使用嵌套数据元素。 |
| 理由 |
嵌套数据类型是 AUTOSAR 应用软件中常见的情形。因此，AUTOSAR 诊断栈乃至诊断提取需要为 Dcm 与应用软件之间的这种交互提供支持。 |
| 用例 |
用户希望访问应用软件 PortPrototype 中的嵌套数据类型，将其用于诊断内容（例如诊断数据标识符的定义）的描述。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器（Diagnostic Communication Manager）的规范 [3] 中找到。 |
2.3.28. 诊断服务表（Diagnostic Service Table）
| 描述 |
诊断提取应支持规定诊断服务表（Diagnostic Service Table）的能力。 |
| 理由 |
诊断服务表表示适用的诊断协议所需的服务量。服务表是诊断栈配置的核心方面，因此诊断提取应予支持。 |
| 用例 |
用户希望在项目的上下文中定义一个特定的诊断协议。就诊断提取而言，这要求定义一个诊断服务表。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器（Diagnostic Communication Manager）的规范 [3] 中找到。 |
2.4. 对事件处理的需求
本章包含一组针对诊断事件和诊断故障码一般上下文的需求。
2.4.1. 事件的配置（Configuration of events）
| 描述 |
诊断提取应支持诊断事件的配置。 |
| 理由 |
诊断事件的定义是 AUTOSAR Dem 配置的关键。诊断事件带有丰富的附加信息，需要作为诊断事件定义的一部分提供。此外，诊断事件与其他实体存在关系，这些关系也需要作为诊断提取的一部分表达。 |
| 用例 |
用户希望形式化地定义某个诊断监视器（monitor）的结果。这是（但不限于）供应商工作流中的典型任务。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器（Diagnostic Event Manager）的规范 [4] 中找到。 |
2.4.2. DTC 的配置（Configuration of DTCs）
| 描述 |
诊断提取应支持 DTC 的配置。 |
| 理由 |
诊断栈预见了被称为诊断故障码（DTC）的实体的存在，从简化的角度看，它表示可向诊断测试仪报告的事件。实际上，DTC 具有更复杂的特性，诊断提取也需要予以支持。 |
| 用例 |
用户希望定义一个唯一的标识符来表示给定的故障情况，该情况进而可以报告给诊断测试仪。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.3. 使能条件（Enable Conditions）
| 描述 |
诊断提取应支持使能条件（Enable Condition）的配置。 |
| 理由 |
AUTOSAR 预见了控制诊断事件处理的条件的存在。应可以定义条件，控制特定诊断事件如何被使能（即被处理）或禁用（即处理被阻止）。 |
| 用例 |
用户希望定义影响诊断事件处理的诊断使能条件。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.4. 存储条件（Storage Conditions）
| 描述 |
诊断提取应支持存储条件（Storage Condition）的配置。 |
| 理由 |
AUTOSAR 预见了控制诊断事件是否存储到事件存储器中的条件的存在。这些条件是诊断栈配置的组成部分。因此，还需要能够在诊断提取中定义存储条件。 |
| 用例 |
用户希望为给定的事件定义存储条件。这些存储条件随后应用于推导 AUTOSAR 诊断栈的配置。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.5. 使能条件组（Enable Condition Groups）
| 描述 |
诊断提取应支持通过使能条件组（Enable Condition Group）收集使能条件。 |
| 理由 |
使能条件组的定义总体上便于使能条件的处理。对于依赖共享使能条件集合的诊断事件尤其如此。因此要求诊断提取支持使能条件组的定义，这些条件组随后可用于对 AUTOSAR 诊断栈的配置做出贡献。 |
| 用例 |
用户希望将若干诊断使能条件归组为单个使能条件组，之后可以用它一步式地表达给定诊断事件与使能条件定义的关系。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.6. 存储条件组（Storage Condition Groups）
| 描述 |
诊断提取应支持通过存储条件组（Storage Condition Group）收集存储条件。 |
| 理由 |
存储条件组的定义总体上便于存储条件的处理。对于依赖共享存储条件集合的诊断事件尤其如此。因此要求诊断提取支持存储条件组的定义，这些条件组随后可用于对 AUTOSAR 诊断栈的配置做出贡献。 |
| 用例 |
用户希望将若干诊断存储条件归组为单个存储条件组，之后可以用它一步式地表达给定诊断事件与存储条件定义的关系。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.7. 使能条件组的分配（Assignment of Enable Condition Groups）
| 描述 |
诊断提取应支持将使能条件组分配给一个事件。 |
| 理由 |
诊断使能条件与使能条件组并存的一个后果是，应当能够建立二者之间的关系。 |
| 用例 |
用户希望在一个使能条件组的上下文中收集若干诊断使能条件。这样，诊断事件与使能条件关系的配置就可以显著简化。 |
| 依赖项 |
§2.4.5 |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.8. 存储条件组的分配（Assignment of Storage Condition Group）
| 描述 |
诊断提取应支持将存储条件组分配给一个事件。 |
| 理由 |
诊断存储条件与存储条件组并存的一个后果是，应当能够建立二者之间的关系。 |
| 用例 |
用户希望在一个存储条件组的上下文中收集若干诊断存储条件。这样，诊断事件与存储条件关系的配置就可以显著简化。 |
| 依赖项 |
§2.4.6 |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.9. 扩展数据记录的配置（Configuration of Extended Data Records）
| 描述 |
诊断提取应支持扩展数据记录（Extended Data Record）的配置。 |
| 理由 |
扩展数据记录与冻结帧（Freeze Frame）一样，用于存储与诊断事件相关的附加信息，因此诊断提取也应予以支持。 |
| 用例 |
用户希望定义与某个诊断事件一同存储在事件存储器中的附加信息。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.10. 快照记录的配置（Configuration of Snapshot Records）
| 描述 |
诊断提取应支持快照记录（Snapshot Record，冻结帧）的配置。 |
| 理由 |
冻结帧与扩展数据记录一样，用于存储与诊断事件相关的附加信息，因此诊断提取也应予以支持。 |
| 用例 |
用户希望定义与给定诊断事件一同存储在事件存储器中的冻结帧内容。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.11. 数据标识符的描述（Description of Data Identifiers）
| 描述 |
诊断提取应支持为诊断服务描述数据标识符（Data Identifier）。 |
| 理由 |
数据标识符的定义是 AUTOSAR 诊断栈配置的核心组成部分。 |
| 用例 |
用户希望定义一个具有给定内容的诊断数据标识符。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器的规范 [3] 中找到。 |
2.4.12. 动态数据标识符的描述（Description of Dynamic Data Identifiers）
| 描述 |
诊断提取应支持为诊断服务描述动态数据标识符（Dynamic Data Identifier）。 |
| 理由 |
动态数据标识符的定义是 AUTOSAR 诊断栈配置的核心组成部分。 |
| 用例 |
用户希望规定某个诊断数据标识符可以用作诊断动态数据标识符。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器的规范 [3] 中找到。 |
2.4.13. 例程标识符的描述（Description of Routine Identifiers）
| 描述 |
诊断提取应支持为诊断服务描述例程标识符（Routine Identifier）。 |
| 理由 |
例程标识符的定义是 AUTOSAR 诊断栈配置的核心组成部分。 |
| 用例 |
用户希望定义与给定诊断例程（Diagnostic Routine）相关联的例程标识符。这通常延伸到对诊断例程本身的建模。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器的规范 [3] 中找到。 |
2.4.14. I/O 标识符的描述（Description of I/O Identifiers）
| 描述 |
诊断提取应支持为诊断服务描述 I/O 标识符（I/O Identifier）。 |
| 理由 |
I/O 标识符的定义是 AUTOSAR 诊断栈配置的核心组成部分。 |
| 用例 |
用户希望定义一个 I/O 标识符。这通常延伸到对诊断数据标识符的建模。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器的规范 [3] 中找到。 |
2.4.15. 诊断事件的防抖（Debouncing of diagnostic events）
| 描述 |
诊断提取应支持规定诊断事件应如何防抖（debounce）。 |
| 理由 |
通常，会对诊断事件的发生应用防抖算法（由 SWS Dem 定义），以避免误报的存在。诊断提取也应支持这一方面。 |
| 用例 |
用户希望定义如何对给定的诊断事件应用防抖。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.16. 操作周期（Operation cycles）
| 描述 |
诊断提取应支持操作周期（operation cycle）的规定。 |
| 理由 |
AUTOSAR 诊断栈支持操作周期的配置。因此诊断提取也应支持这一方面。 |
| 用例 |
用户希望根据项目需要为诊断事件分配特定的操作周期。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.17. 老化（Aging）
| 描述 |
诊断提取应支持老化（aging）的规定。 |
| 理由 |
通常的做法是，事件在连续多次「通过（passed）」报告之后从故障存储器中移除。诊断提取应支持这一方面。 |
| 用例 |
用户希望规定特定诊断事件以何种方式接受老化处理。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.18. 指示器（Indicator）
| 描述 |
诊断提取应支持指示器（indicator）的规定。 |
| 理由 |
诊断栈应支持向车辆驾驶员发出某些诊断事件的信号。该信号发送应建模为诊断指示器。 |
| 用例 |
用户希望规定诊断事件如何向驾驶员指示。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.4.19. 文本描述（Textual descriptions）
| 描述 |
诊断提取应支持为诊断事件和 DTC 属性规定文本描述的能力。 |
| 理由 |
将文本描述附加到诊断模型元素的定义上，可以更好地传达相应模型元素的目的和语义。 |
| 用例 |
用户希望对与诊断提取描述相关的特定模型元素提供恰当的文本文档。 |
| 依赖项 |
- |
| 支撑材料 |
- |
| 描述 |
诊断提取应支持使用中监视性能比（In Use Monitor Performance Ratio，IUMPR）的定义。 |
| 理由 |
IUMPR 的定义是 OBD 应用的组成部分。 |
| 用例 |
用户希望针对给定的诊断事件规定 IUMPR。 |
| 依赖项 |
- |
| 支撑材料 |
关于这一方面的更多信息可在相应的法规出版物 [5] 中找到。 |
2.4.21. 支持安全事件的持久化（Support for persisting Security Events）
| 描述 |
在某些情况下，安全事件需要被持久化，以便之后可以由诊断测试仪查询。 |
| 理由 |
安全事件的发生可以是对入侵进行取证分析的重要组成部分。 |
| 用例 |
用户希望规定哪些安全事件应持久化到 Dem 的安全事件存储器（Security Event Memory）中。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.5. 对会话与安全的需求
本章包含一组针对诊断会话和安全上下文的需求。
2.5.1. 诊断会话（Diagnostic Sessions）
| 描述 |
诊断提取应支持规定诊断会话（Diagnostic Session）的能力。 |
| 理由 |
诊断会话的配置是 AUTOSAR 诊断栈配置的重要方面。因此，诊断提取需要支持这一方面的建模。 |
| 用例 |
用户希望将诊断会话的定义作为项目的一部分。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.5.2. 访问权限（Access Permissions）
| 描述 |
诊断提取应支持规定访问权限（Access Permission）的能力。 |
| 理由 |
访问权限的配置是 AUTOSAR 诊断栈配置的重要方面。因此，诊断提取需要支持这一方面的建模。 |
| 用例 |
用户希望将需要访问权限的特定诊断功能（例如 DID 或 RID）定义为项目的一部分。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.5.3. 安全级别（Security Levels）
| 描述 |
诊断提取应支持规定安全级别（Security Level）的能力。 |
| 理由 |
安全级别的配置是 AUTOSAR 诊断栈配置的重要方面。因此，诊断提取需要支持这一方面的建模。 |
| 用例 |
用户希望将安全级别的定义作为项目的一部分。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [2] 中找到。 |
2.5.4. 支持环境条件（Support for environment conditions）
| 描述 |
诊断提取应支持对启用诊断功能处理的环境条件（environment condition）进行表述。 |
| 理由 |
某些诊断功能只有在车辆处于特定状态时才是安全的。因此，应当可以在诊断提取的层级上规定执行诊断功能的条件。 |
| 用例 |
用户希望执行一项要求车辆停止的诊断功能（即条件为车速 == 0）。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断通信管理器的规范 [3] 中找到。 |
2.6. 对支持功能抑制的需求
本章包含一组针对诊断提取中功能抑制（function inhibition）支持的需求。
2.6.1. 功能（Function）
| 描述 |
诊断提取应支持出于功能抑制的目的而定义功能。该功能应具有一个标识，通过它可以向下游配置进一步识别。 |
| 理由 |
为了能够定义功能抑制，必须拥有表示功能的模型元素。 |
| 用例 |
用户希望规定一个功能，之后在功能抑制的范围内使用。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 功能抑制管理器（Function Inhibition Manager）的规范 [6] 中找到。 |
2.6.2. 功能与诊断事件之间的关系（Relationship between functions and diagnostic events）
| 描述 |
诊断提取应支持功能与「在相应功能被抑制后不再报告的诊断事件」之间的关系。应可以在不同的粒度层级上表达功能与相应事件之间的关系。这意味着既可以引用单个诊断事件，也可以引用诊断事件的整个集合。 |
| 理由 |
禁止诊断事件的报告是 Fim 的核心功能。应当可以在诊断提取中描述这一方面。 |
| 用例 |
用户希望规定某个特定功能如何抑制给定的诊断事件集合的报告。为了避免必须逐个引用每个目标诊断事件，用户希望能够通过引用由诊断提取形式化的事件组来省却这一工作量。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 功能抑制管理器的规范 [6] 中找到。 |
2.6.3. Dem 配置尚不可用时 Fim 的预配置（Pre-configuration of the Fim when the Dem configuration is not yet available）
| 描述 |
在诊断提取中创建 Fim 配置时，诊断提取中的 Dem 配置可能尚不存在。因此，没有可供用于创建 Fim 预配置的形式化诊断事件表示。为此，诊断提取应提供为诊断事件定义占位符（placeholder）的能力，这些占位符可用于 Fim 的预配置，并在诊断提取中的 Dem 配置变得可用之后由真实的诊断事件替换。 |
| 理由 |
去中心化配置的概念支持这样的想法：诊断提取的某些部分应彼此独立地定义，随后再合并以形成整个诊断栈的配置。 |
| 用例 |
用户希望在实际诊断事件的定义可用之前，对功能与诊断事件之间的关系建模。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 功能抑制管理器的规范 [6] 中找到。 |
2.7. 对支持 J1939 诊断的需求
本章包含一组针对诊断提取中 J1939 诊断支持的需求。
2.7.1. SPN 的定义（Definition of an SPN）
| 描述 |
诊断提取应支持 SPN 的定义，以及系统描述中通信项及其物理属性的表示。 |
| 理由 |
所谓可疑参数编号（Suspect Parameter Number，SPN）是 J1939 诊断中的一个重要概念。SPN 也可以指物理属性。 |
| 用例 |
用户希望规定 SPN 在系统描述中的表示方式。用户希望确保预期的物理属性得到一致使用。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.7.2. J1939 上冻结帧的定义（Definition of freeze frames on J1939）
| 描述 |
诊断提取应支持 J1939 上冻结帧（常规与扩展）的定义。 |
| 理由 |
J1939 上冻结帧的定义是 J1939 诊断栈配置的重要组成部分。 |
| 用例 |
用户希望定义 J1939 冻结帧的内容。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.7.3. J1939 DTC 的定义（Definition of J1939 DTC）
| 描述 |
诊断提取应支持在 J1939 域中定义具有其所有特定属性的 DTC。 |
| 理由 |
DTC 的定义是诊断栈的重要组成部分。J1939 域中的 DTC 具有与例如 UDS DTC 的属性明确分离的特定属性。 |
| 用例 |
用户希望在诊断提取中 J1939 诊断栈的配置内规定一个 DTC。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.8. 对支持 OBD 诊断服务的需求
本章包含一组针对 [7] 所述 OBD 诊断服务上下文的需求。
2.8.1. 诊断参数标识符的定义（Definition of a Diagnostic Parameter Identifier）
| 描述 |
诊断提取应支持诊断参数标识符（PID）的形式化定义。PID 的形式化表示应具有一个数值标识符，用于下游配置。 |
| 理由 |
PID 在 OBD 服务的建模中扮演核心角色。PID 的定义是支持 OBD 服务的关键。 |
| 用例 |
用户希望定义一个 PID 以对 OBD 服务建模。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.2. 支持 OBD 模式 0x01（RequestCurrentPowertrainDiagnosticData）（Support for OBD Mode 0x01 (RequestCurrentPowertrainDiagnosticData)）
| 描述 |
诊断提取应支持对 OBD 模式 0x01（又称 RequestCurrentPowertrainDiagnosticData）的建模。 |
| 理由 |
OBD 模式 0x01 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x01 建模。 |
| 依赖项 |
§2.8.1 |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.3. 支持 OBD 模式 0x02（RequestPowertrainFreezeFrameData）（Support for OBD Mode 0x02 (RequestPowertrainFreezeFrameData)）
| 描述 |
诊断提取应支持对 OBD 模式 0x02（又称 RequestPowertrainFreezeFrameData）的建模。 |
| 理由 |
OBD 模式 0x02 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x02 建模。 |
| 依赖项 |
§2.8.1 |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| 描述 |
诊断提取应支持对 OBD 模式 0x03 / 0x07 / 0x0A（又称 RequestEmissionRelatedDiagnosticTroubleCodes）的建模。 |
| 理由 |
OBD 模式 0x03 / 0x07 / 0x0A 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x03 / 0x07 / 0x0A 建模。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| 描述 |
诊断提取应支持对 OBD 模式 0x04（又称 ClearResetEmissionRelatedDiagnosticInformation）的建模。 |
| 理由 |
OBD 模式 0x04 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x04 建模。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.6. 支持 OBD 模式 0x06（RequestOnBoardMonitoringTestResults）（Support for OBD Mode 0x06 (RequestOnBoardMonitoringTestResults)）
| 描述 |
诊断提取应支持对 OBD 模式 0x06（又称 RequestOnBoardMonitoringTestResults）的建模。 |
| 理由 |
OBD 模式 0x06 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x06 建模。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.7. 支持 OBD 模式 0x08（RequestControlOfOnBoardDevice）（Support for OBD Mode 0x08 (RequestControlOfOnBoardDevice)）
| 描述 |
诊断提取应支持对 OBD 模式 0x08（又称 RequestControlOfOnBoardDevice）的建模。 |
| 理由 |
OBD 模式 0x08 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x08 建模。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
| 描述 |
诊断提取应支持对 OBD 模式 0x09（又称 RequestVehicleInformation）的建模。 |
| 理由 |
OBD 模式 0x09 是 OBD 功能的强制组成部分，因此诊断提取中需要该模式的表示。 |
| 用例 |
用户希望在诊断提取中对 OBD 服务 0x09 建模。 |
| 依赖项 |
§2.8.9 |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.9. 诊断测试标识符的定义（Definition of Diagnostic Test Identifier）
| 描述 |
诊断提取应支持诊断测试标识符（Diagnostic Test Identifier，TID）的定义。 |
| 理由 |
TID 的定义是 OBD 模式 0x09 定义所必需的。 |
| 用例 |
用户希望定义一个 TID，之后用于 OBD 服务 0x09 的定义。 |
| 依赖项 |
- |
| 支撑材料 |
关于该诊断服务的更多信息可在相应的 ISO 规范 [7] 中找到。 |
2.8.10. 使用 UDS 支持 WWH-OBD 的描述（Description of the utilization of UDS for supporting WWH-OBD）
| 描述 |
诊断提取应规定如何利用 UDS 诊断服务来实现 WWH-OBD。 |
| 理由 |
WWH-OBD 的实现基本上意味着使用 UDS 服务来模拟 OBD 服务的行为。为了协调为此目的对 UDS 服务的使用，诊断提取应提供一种规范，尽可能消除有歧义的配置变体。 |
| 用例 |
用户希望在通常支持 UDS 诊断服务的 ECU 上使用 WWH-OBD。用户希望利用阐明为此目的应如何在诊断提取中配置 UDS 服务的规范。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.9. 对诊断资源映射的需求
本章包含一组针对将诊断资源映射到其他模型元素的需求。
2.9.1. 诊断服务到 ApplicationSwComponentTypes 的 PortPrototypes 的映射（Mapping of diagnostic services to the PortPrototypes of ApplicationSwComponentTypes）
| 描述 |
诊断提取应支持规定诊断服务如何映射到 ApplicationSwComponentType 的 PortPrototype。 |
| 理由 |
诊断服务到 ApplicationSwComponentType 的 PortPrototype 的映射，将诊断服务的定义与这些服务所针对的实际应用软件连接起来。因此，该映射是工作流中的重要一步，也为软件在给定 ECU 上的集成提供重要信息。 |
| 用例 |
用户希望将诊断服务映射到应用软件，以表达 ECU 配置中这两个方面之间的概念性连接。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.9.2. 组合事件（Combined Events）
| 描述 |
诊断提取应支持将映射到单个 DTC 的事件的配置。 |
| 理由 |
存在若干诊断监视器的结果共同促成单个诊断故障码的情况。为此，诊断提取需要能够允许诊断事件与诊断故障码的模型元素之间存在 n:1 关系。 |
| 用例 |
用户希望将若干诊断监视器的结果连接到单个诊断故障码。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 诊断事件管理器的规范 [4] 中找到。 |
2.9.3. Fim 层级的功能与软件组件之间的关系（Relation between functions on Fim level and software-components）
| 描述 |
诊断提取应提供定义功能到软件组件映射的方法。 |
| 理由 |
Fim 中功能的概念相当抽象，需要进一步澄清它对应 AUTOSAR ECU 上应用软件的哪个部分。 |
| 用例 |
用户希望规定 Fim 术语中的哪个功能由应用软件的哪个部分表示。 |
| 依赖项 |
- |
| 支撑材料 |
更多信息可在 AUTOSAR 功能抑制管理器的规范 [6] 中找到。 |
2.9.4. J1939 控制器应用与软件组件之间的映射（Mapping between a J1939 controller application and a software-component）
| 描述 |
诊断提取应支持规定 J1939 控制器应用（controller application）概念与由单个软件组件表示的 AUTOSAR 应用软件部分之间的映射。 |
| 理由 |
控制器应用与软件组件之间的映射是「弥合 AUTOSAR 与 J1939 技术领域之间鸿沟」的重要组成部分。应当将功能单元定义的不同方法相互映射。 |
| 用例 |
用户希望规定控制器应用与 AUTOSAR 应用软件部分之间的映射。 |
| 依赖项 |
- |
| 支撑材料 |
- |
2.10. 其他需求
本章包含一组其他需求。
2.10.1. 支持更新安全事件的报告模式（Support for updating the Reporting Mode of Security Events）
| 描述 |
在某些情况下，需要通过诊断服务更新某些安全事件的报告模式（Reporting Mode）。 |
| 理由 |
安全事件的报告模式可以是对入侵进行取证分析的重要组成部分。 |
| 用例 |
用户希望更新给定安全事件的报告模式。 |
| 依赖项 |
- |
| 支撑材料 |
- |
A. AUTOSAR 可追溯项变更历史
请注意，本章中的列表还包括在后续版本中已从规范中移除的需求项。这些需求项在文档中不作为超链接出现。
A.1. 本文档按 AUTOSAR 发布版 R4.2.1 的可追溯项历史
A.1.1. R4.2.1 中新增的需求
表A.1：R4.2.1 中新增的可追溯项
| 标题 |
| 诊断数据交换 |
| 分布式软件开发过程 |
| SessionControl |
| ECUReset |
| ClearDiagnosticInformation |
| ReadDTCInformation |
| ReadDataByIdentifier |
| ReadMemoryByAddress |
| SecurityAccess |
| CommunicationControl |
| ReadDataByPeriodicIdentifier |
| DynamicallyDefineDataIdentifier |
| WriteDataByIdentifier |
| IOControl |
| RoutineControl |
| RequestDownload |
| RequestUpload |
| TransferData |
| RequestTransferExit |
| WriteMemoryByAddress |
| ControlDTCSetting |
| ResponseOnEvent |
| 事件的配置 |
| DTC 的配置 |
| 组合事件 |
| 使能条件 |
| 存储条件 |
| 使能条件组 |
| 存储条件组 |
| 使能条件组的分配 |
| 存储条件组的分配 |
| 扩展数据记录的配置 |
| 快照记录的配置 |
| 数据标识符的描述 |
| 动态数据标识符的描述 |
| 例程标识符的描述 |
| I/O 标识符的描述 |
| 数组数据类型的描述 |
| 诊断服务表 |
| 诊断会话 |
| 访问权限 |
| 数据元素的描述 |
| 相关 ECU-C 参数的推导 |
| 文本描述 |
| 变体 |
| 自定义诊断服务 |
| 特定于单个 ECU 的诊断属性 |
| 单个诊断服务的属性 |
| 同类所有诊断服务的属性 |
| 诊断服务的子功能 |
| 诊断服务到 ApplicationSwComponentTypes 的 PortPrototypes 的映射 |
| 诊断事件的防抖 |
| 操作周期 |
| 老化 |
| 指示器 |
| RequestFileTransfer |
A.1.2. R4.2.1 中变更的需求
无
A.1.3. R4.2.1 中删除的需求
无
A.2. 本文档按 AUTOSAR 发布版 R4.2.2 的可追溯项历史
A.2.1. R4.2.2 中新增的需求
无
A.2.2. R4.2.2 中变更的需求
表A.2：R4.2.2 中变更的可追溯项
| 标题 |
| SessionControl |
| ECUReset |
| ClearDiagnosticInformation |
| ReadDTCInformation |
| ReadDataByIdentifier |
| ReadMemoryByAddress |
| SecurityAccess |
| CommunicationControl |
| ReadDataByPeriodicIdentifier |
| DynamicallyDefineDataIdentifier |
| WriteDataByIdentifier |
| IOControl |
| RoutineControl |
| RequestDownload |
| RequestUpload |
| TransferData |
| RequestTransferExit |
| WriteMemoryByAddress |
| ControlDTCSetting |
| ResponseOnEvent |
A.2.3. R4.2.2 中删除的需求
无
A.2.4. R4.2.2 中新增的约束
无
A.2.5. R4.2.2 中变更的约束
无
A.2.6. R4.2.2 中删除的约束
无
A.3. 本文档按 AUTOSAR 发布版 R4.3.0 的可追溯项历史
A.3.1. R4.3.0 中新增的需求
表A.3：R4.3.0 中新增的可追溯项
| 标题 |
| 指示 ECU 支持 OBD |
| 支持不同的协议 |
| 功能 |
| 功能与诊断事件之间的关系 |
| Dem 配置尚不可用时 Fim 的预配置 |
| Fim 层级的功能与软件组件之间的关系 |
| SPN 的定义 |
| J1939 上冻结帧的定义 |
| J1939 控制器应用与软件组件之间的映射 |
| J1939 DTC 的定义 |
| 诊断参数标识符的定义 |
| 支持 OBD 模式 0x01（RequestCurrentPowertrainDiagnosticData） |
| 支持 OBD 模式 0x02（RequestPowertrainFreezeFrameData） |
| 支持 OBD 模式 0x03 / 0x07 / 0x0A（RequestEmissionRelatedDiagnosticTroubleCodes） |
| 支持 OBD 模式 0x04（ClearResetEmissionRelatedDiagnosticInformation） |
| 支持 OBD 模式 0x06（RequestOnBoardMonitoringTestResults） |
| 支持 OBD 模式 0x08（RequestControlOfOnBoardDevice） |
| 支持 OBD 模式 0x09（RequestVehicleInformation） |
| 诊断测试标识符的定义 |
| 使用 UDS 支持 WWH-OBD 的描述 |
| 支持使用中监视性能比 |
| 支持环境条件 |
A.3.2. R4.3.0 中变更的需求
表A.4：R4.3.0 中变更的可追溯项
| 标题 |
| 诊断数据交换 |
| 事件的配置 |
| DTC 的配置 |
| 组合事件 |
| 使能条件 |
| 存储条件 |
| 使能条件组 |
| 存储条件组 |
| 使能条件组的分配 |
| 存储条件组的分配 |
| 扩展数据记录的配置 |
| 快照记录的配置 |
| 数据标识符的描述 |
| 动态数据标识符的描述 |
| 例程标识符的描述 |
| I/O 标识符的描述 |
| 数组数据类型的描述 |
| 诊断服务表 |
| 诊断会话 |
| 访问权限 |
| 安全级别 |
| 数据元素的描述 |
| 相关 ECU-C 参数的推导 |
| 文本描述 |
| 变体 |
| 自定义诊断服务 |
| 特定于单个 ECU 的诊断属性 |
| 单个诊断服务的属性 |
| 同类所有诊断服务的属性 |
| 诊断服务的子功能 |
| 诊断服务到 ApplicationSwComponentTypes 的 PortPrototypes 的映射 |
| 诊断事件的防抖 |
| 操作周期 |
| 老化 |
| 指示器 |
| RequestFileTransfer |
A.3.3. R4.3.0 中删除的需求
表A.5：R4.3.0 中删除的可追溯项
A.3.4. R4.3.0 中新增的约束
无
A.3.5. R4.3.0 中变更的约束
无
A.3.6. R4.3.0 中删除的约束
无
A.4. 本文档按 AUTOSAR 发布版 R4.3.1 的可追溯项历史
A.4.1. R4.3.1 中新增的需求
无
A.4.2. R4.3.1 中变更的需求
无
A.4.3. R4.3.1 中删除的需求
无
A.5. 本文档按 AUTOSAR 发布版 R4.4.0 的可追溯项历史
A.5.1. R4.4.0 中新增的需求
无
A.5.2. R4.4.0 中变更的需求
无
A.5.3. R4.4.0 中删除的需求
无
A.6. 本文档按 AUTOSAR 发布版 R19-11 的可追溯项历史
A.6.1. R19-11 中新增的需求
无
A.6.2. R19-11 中变更的需求
无
A.6.3. R19-11 中删除的需求
无
A.7. 本文档按 AUTOSAR 发布版 R20-11 的可追溯项历史
A.7.1. R20-11 中新增的需求
表A.6：R20-11 中新增的需求
| 标题 |
| 支持安全事件的持久化 |
| 支持更新安全事件的报告模式 |
A.7.2. R20-11 中变更的需求
无
A.7.3. R20-11 中删除的需求
无
A.8. 本文档按 AUTOSAR 发布版 R21-11 的可追溯项历史
A.8.1. R21-11 中新增的需求
无
A.8.2. R21-11 中变更的需求
无
A.8.3. R21-11 中删除的需求
无
A.9. 本文档按 AUTOSAR 发布版 R22-11 的可追溯项历史
A.9.1. R22-11 中新增的需求
无
A.9.2. R22-11 中变更的需求
表A.7：R22-11 中变更的需求
A.9.3. R22-11 中删除的需求
表A.8：R22-11 中删除的需求
A.10. 本文档按 AUTOSAR 发布版 R23-11 的可追溯项历史
A.10.1. R23-11 中新增的需求
无
A.10.2. R23-11 中变更的需求
无
A.10.3. R23-11 中删除的需求
无