全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续学习AUTOSAR的文档，看一下《AUTOSAR_TPS_DiagnosticExtractTemplate》。这一次看看这个文件的用例部分，整个章节一个4页，一次性看完应该比较容易。
2 用例
2.1 诊断数据交换用例
DiagnosticExtract 的基本用途是在诊断开发过程中涉及的不同方之间交换诊断数据，以允许配置 DCM 和 DEM 并提供相应应用程序的描述接口来实现诊断服务和故障处理。
2.2 DCM 的配置
DCM 的配置包括诊断服务的设置和由一个或多个软件组件（例如组合 1、组合 2）提供的数据对象的分配。
图 2.2：DEM 相关数据对象的分配
2.3 DEM的配置
DEM 的配置包括故障存储器数据（DTC 和环境数据）以及一个或多个 SwComponentType（例如组合 1、组合 2）对相应数据的分配。
如前所述，诊断开发过程分布在不同的各方之间。 一方面，OEM 需要描述必须由 ECU 实施的诊断系统的一般要求：
1. 根据诊断系统，OEM 可以提供完全或部分填充的 DiagnosticExtract，包括端口接口的描述：
• 集成商/SWC 开发人员（OEM 或Tier 1）负责完成（预定义诊断内容的详细说明）。
• 集成商/SWC 开发人员（OEM 或Tier 1）负责自己定义的诊断内容的具体配置。
• 集成商对更新诊断描述的新集成。
2. 将完全或部分填充的 DiagnosticExtract 返还给 OEM 用于：
• 文档
• ECU 测试
• 集成审查
• 故障纠正
用例示例：
• UDS 服务 0x22 (ReadDataByIdentifier) 的配置
• UDS 服务 0x2E (WriteDataByIdentifier) 的配置
• UDS 服务 0x31 (RoutineControl) 的配置
• UDS 服务 0x2F (I/O) 的配置 -控制）
• DEM DTC 的配置
• 组合事件的配置
• 事件到 DTC 的映射
• DTC 相关环境数据的配置
• DEM 事件与其相应的启用条件和存储条件的映射
• 配置通用 DCM 参数
• 诊断需求的描述
• 与代码生成无关但必须在 OEM 和 Tier1 之间交换的诊断需求的描述（例如 DTC 的设置和重置条件）
用例的改进：OEM 已经为 ECU 提供了一个系统模板，该模板将 ECU 供应商软件部件描述为 CompositionSwComponentType，其中只有输入和输出是已知的。
1. OEM 创建一个描述 ECU 诊断接口的 DiagnosticExtract。描述了支持的服务（例如 RDBI/WDBI/Routine Control）及其相应的输入/输出参数和返回值（这些在 UDS 标准中是可选的）。
2. OEM 的 SWC 开发人员或 OEM SW 供应商开发 SWC 并使用 ServiceNeeds 作为诊断贡献描述诊断信息。
3. 负责项目的 OEM 诊断创建 DiagnosticExtract 和 OEM 端可用的 SWC 之间的映射（从 2.）。
4. 负责项目的 OEM 诊断在 DiagnosticExtract 和 CompositionSwComponentTypes 之间创建映射，将由 ECU 供应商或软件开发人员实施。
5. ECU 供应商从 OEM 接收包含 DiagnosticExtract 的 ECU Extract 并将其导入到项目中。
6. 与第 2 点相同，供应商或 Tier 2 侧的 SWC 开发人员使用 ServiceNeeds 作为诊断贡献描述诊断信息。
图 2.3：诊断数据交换的工作流场景
与第 3 点中的方式相同：ECU 供应商诊断负责人在 DiagnosticExtract（来自 5.）的 PortInterfaces 和 6 中提供的 SwComponentTypes 之间创建映射。
对于指示器的使用，可能会发生在 DEM 中在 BSW 级别定义的指示器可能不会自动映射到 SWC 级别的实现。 这将需要集成人员的手动映射步骤来解决不匹配。
以上是关于诊断提取模板用例相关的一些介绍，内容不是很多。明确了一些可能的合作的团队之间的工作内容信息。给出了一个简单的诊断数据交换的工作流程场景。
