《AUTOSAR_TPS_DiagnosticExtractTemplate》。

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_开发人员

       1 介绍

       1.1 概述

       AUTOSAR ECU 开发的分布式特性需要优化的信息捕获。 特别是，诊断信息（即 DEM 和 DCM 配置）应仅由具有最佳知识的人员捕获一次，因此能够比一个集中的个人更好地承担责任。

       在 DiagnosticExtract 出现之前的配置方法中，基础软件模块 DCM 和 DEM 完全集中配置。 在集成过程中，RTE [1]（应用软件）之上的所有 SW-C 都会引入要连接到 BSW 模块 [2] 的端口。 此外，SW-C 表达了应由 BSW 满足的需求。

       市场对将 OEM 特定配置过程的诊断需求转移到其一级供应商的需求很高。

       过去，由于缺乏集成选项，经常使用许多不同的文件格式，如 ODX 或 ECU-C [3]。 但是 ODX 和 ECU-C 都不太适合传输这些信息。

       例如，ODX [4] 缺乏故障记忆细节，并且 ECU-C（从未设计为成为不同组织之间数据交换的工具）具有非常通用的性质，这使得严格模型形式化的实施非常困难。

       最重要的是，将 ECU-C 定义集成到现有配置（尤其是 PDU）中无法完全自动化。

       因此，显而易见的解决方案是在诊断功能上定义一种新的标准化 AUTOSAR 交换格式，该格式可以类似于系统描述，形式化为 ARXML [5] 文件。

       本着这种精神，诊断功能的配置变得类似于系统描述 [6] 中通信部分的配置。

       小结：这部分内容的引入，跟之前看相关的辅助文档的时候有一部分类似的信息。关于诊断部分对于有经验人员的这一条就是一模一样的。

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_应用程序_02

       图 1.1 显示了未来两个通用用例的诊断配置过程。 此过程涉及三方：

       • OEM 或诊断请求者

       • 应用开发商或应用开发商

       • ECU 供应商或集成商

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_开发人员_03

       1.1.1 OEM

       OEM 或诊断数据的请求者使用DiagnosticExtract 来定义一个或多个ECU 的诊断接口。 它还可以定义一些内部行为作为 ECU 供应商或应用程序开发人员的要求：

       • 定义 DTC 的值

       • 定义由 ECU 支持的 UDS 服务和子服务

       • 定义由应用程序实现的特定组合所需的所需事件

       开发人员要注意：仅作为示例，本文档并未定义每个元素的特定所有权。

       在第一个用例中，DiagnosticExtract 用于交换信息，这些信息被转换为 ECU-C 配置（M2 到 M1 的映射，另见 [3] 和 [7]）。

       其次，OEM 使用 DiagnosticExtract 记录供应商要实施的要求。 这些要求以文本语言表达，不能直接映射到任何 ECU-C 配置参数（没有 M2 到 M1 的映射可能）。

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_autosar_04

       1.1.2 应用开发者

       应用开发者用相应的 SWC 描述来实现他们的 SWC。 随着这个概念的引入，应用程序开发人员有可能提供与 SWC 相关的诊断信息作为 DiagnosticExtract 的一部分。

       应用程序开发人员还可以在 DiagnosticExtract 中以文本形式从 OEM 接收一些输入作为要求，例如：

       • 定义此 SWC 实现的特定 ReadDataByIdentifier 的内容

       • 定义此 SWC 所需的事件

       注意：仅作为示例 ，本文档没有定义每个元素的特定所有权。

       在第一个用例中，应用程序开发人员定义了特定 ReadDataByIdentifier 的参数，即诊断请求的内容而不是 DID 本身。 此命令的 DID 通常由 OEM 定义。

       其次，应用程序开发人员可以定义包括去抖动和操作周期等信息的 SWC 事件。 应用程序开发人员还可以定义特定 OEM 不需要但另一个 OEM 需要的事件和诊断作业。

       供应商可能会为多个 OEM 使用相同的软件，并且需要重复使用它。 这意味着如果特定项目不需要，则在集成期间可能会忽略来自 SWC 的某些 DiagnosticExtract 信息。

       小结：从AUTOSAR的实现角度看，DID的设计还是可能放到应用软件来做的。

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_应用软件_05

823_AUTOSAR_TPS_DiagnosticExtractTemplate1_简介_概述1_用例_06

       1.1.3 ECU 供应商

       ECU 供应商或集成商从 OEM 和多个应用程序开发商接收一个或多个 DiagnosticExtract 文件。  Integrator 的主要目标是集成所有提供的 DiagnosticExtract 并从中生成 ECU-C 配置。

       由于此概念并未为每个元素（如 DID、UDS 服务的参数、事件、会话等）定义特定的所有权，因此集成商必须确保合并后的完整信息仍然有效。

       • DTC 到事件的映射

       • 事件的合并

       • 服务的映射

       一些 DTC 可能已经映射到事件 - 特别是在两者来自同一方的情况下。 但是，如果 DTC 由 OEM 定义，而 SW 由其他供应商作为应用程序开发人员实施，则集成商必须确保将两者映射在一起。

       在某些情况下，一个事件可能被定义多次。  OEM 定义应由应用程序开发人员实现的事件。 供应商实现了一个 SWC，该 SWC 将在多个项目中使用，并且还检测此类错误并定义相同的事件。

       两个事件的命名可能不同，但含义相同。 集成方必须在积分过程中检测这种冗余并将它们合并在一起。

       在另一种情况下，OEM 需要特定的 ReadDataByIdentifier 并且应用程序开发人员实现它。 如果仅针对一个特定项目执行实施，则应用程序开发人员可以将来自 OEM 的 DID 映射到其 SWC 中已定义的作业。

       在应用程序开发人员实现通用诊断作业的其他情况下，ECU 供应商的任务是合并此信息并将作业映射到相应的 DID。

       这部分主要做了一个文档的概述，针对OEM、应用软件开发者、ECU的供应商等各个层面的处理方式做了一些介绍。通过这部分，也确认了一部分开发形式的支持性。