824_AUTOSAR_TPS_DiagnosticExtractTemplate2_简介_概述2

系统管理员 2022-09-12 11:51 20阅读 0赞

全部学习汇总： [GitHub - GreyZhang/hack\_autosar: learning autosar documents, aha, very hard!][GitHub - GreyZhang_hack_autosar_ learning autosar documents_ aha_ very hard]

继续学习AUTOSAR的文档，看一下《AUTOSAR\_TPS\_DiagnosticExtractTemplate》。近段时间的状态不佳，类似的学习有一点点进度慢了，重新振作一下仔细阅读学习。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16][]

1.1.4 文件交换

在ECU 开发项目期间，三个主要角色（OEM、应用程序开发人员、ECU 集成商）交换DiagnosticExtract 文件。 交换的时间和频率以及这些交换文件中的每一个的内容在很大程度上取决于各个项目的设置和情况。

因此，DiagnosticExtract 格式的设计允许逐步丰富不同角色在很大程度上任意时间点贡献的定义，以满足“分布式配置”的需求。

对于任何两个角色之间的任何交换路径，都使用基于 DiagnosticExtract 模板的相同文件格式。 然后取决于公司特定的流程和工具来合并收集的 DiagnosticExtract 文件，同时解决冲突（矛盾、冗余等）。

作为最终结果，可获得一致且完整的 DiagnosticExtract 文件，该文件可作为基础软件诊断模块配置派生的输入。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

1.1.5 与 SWC 服务需求的关系

在引入诊断提取之前，服务需求用于描述 SWC 级别的诊断需求。 这些配置要求参考相关的 BSW 模块 DCM 或 DEM，以便在 BSW 级别提供相应的配置。

服务需求的使用只能在原子 SWC 级别上进行，而诊断需求的分配必须在组合级别上是可能的。

SWC 描述中的 SWC 服务需求仍将与诊断提取一起使用，以便注释与诊断提取定义的进一步映射和处理相关的 SWC 端口。

因此，从 SWC 开发人员的角度来看，DiagnosticExtract 部分用作 SWC 服务需求的替代，部分用作 SWC 服务需求的扩展。“替代”的理由是避免冗余的诊断定义。

由于 SWC 开发人员可能定义的某些诊断属性未包含在 SWC 服务需求中，因此也可以将 DiagnosticExtract 视为对 SWC 服务需求原始目的的“扩展”。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

1.1.6 建议和提示

多方可能对每一方应提供哪些部分有不同的理解。 没有明确的规则来指示谁对每个部分负责。 最后，作为集成商的 ECU 供应商必须确保完成所有映射，并确保 ECU 按照 OEM 的预期运行。

如果 OEM 没有自己的诊断要求，ECU 供应商必须提供完整的 DiagnosticExtract。 在这种情况下，OEM 可能只在交付过程中收到 DiagnosticExtract。 本规范中没有定义各方如何使用这种格式的过程本身。

图 1.1 显示了如何处理不同方之间的 DiagnosticExtract 的推荐方式。 在用例 1 中，一些 SWC 由 OEM（或 OEM 的供应商）实施，并且 DiagnosticExtract 数据的第一次合并发生在 OEM。

在用例 2 中，OEM 通过 DiagnosticExtract 提供诊断要求，多个应用程序开发人员提供与其实现相关的信息，合并完全由 ECU 供应商执行。

还允许用例 1 和 2 的组合。 此外，ECU 供应商可能会实现软件的某些部分，包括其相应的诊断提取。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

1.1.7 限制

DiagnosticExtract 模板的第一个版本侧重于定义仅单个 ECU 的诊断要求。 这意味着目前，无法使用 DiagnosticExtract 模板定义由多个 ECU 组成的系统或部分系统的分布式诊断功能。

在未来的版本中，DiagnosticExtract 模板预计将扩展到还包括分布式诊断功能的配置。 类似于系统描述中对通信相关性的描述，应该可以描述系统级别的诊断需求，以从该描述中导出对特定 ECU 的诊断需求。

此外，使用 DiagnosticExtract 的 Fim \[8\] 配置已推迟到未来的 AUTOSAR 版本。 预计 Fim 模块的配置将以与使用 DiagnosticExtract 的 Dem 和 Dcm 配置类似的方式处理。

此外，DiagnosticExtract 不支持 DCM 和 DEM 的 OBD 相关配置部分，包括 WWH-OBD（全局协调 OBD）。

DiagnosticExtract 目前不支持模式规则的配置。

DiagnosticExtract 目前不支持配置多个诊断协议（UDS、OBD、J1939）和相应的协议优先级。这意味着，仅支持符合 ISO14229-1 的 UDS，并且需要手动配置另一个并行实现的协议。

通常，DiagnosticExtract 不支持与流程相关的部分来记录诊断配置数据的成熟度。 这意味着，不能将数据对象标记为“草稿”或“已发布”。 这个问题需要由 AUTOSAR 在未来版本的一般概念中解决。 因此，引入仅用于诊断的解决方案是没有意义的。

这样，整个简介部分的概述内容全都看完了。这里介绍了一些不同的角色之间的合作关系。同时，介绍了当前架构的覆盖内容以及模糊定义的部分。

[GitHub - GreyZhang_hack_autosar_ learning autosar documents_ aha_ very hard]: https://github.com/GreyZhang/hack_autosar
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/1918eb9fa414403d92467a3cc2489042.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/d58a766998fc4e949f6ab937c770bbb3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/30ff274826914f33bf054b9bda220bb2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAZ3JleV9jc2Ru_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/fbe46683ad1f457ea16497ac4b8e51a1.png