Autosar知识：方法论-诊断摘要

此用例使用诊断摘要模板提供诊断配置的大致轮廓。所涉及的活动和交付物将在下次AUTOSAR版本中根据该领域的经验进行细化。

 

AUTOSAR ECU开发的分布式特性要求对信息进行优化捕获。特别是，诊断信息(即DEM和DCM配置)应由最了解情况的人只掌握一次，因此比一个集中的人更有能力承担责任。ECU配置不适合在ECU开发项目的合作伙伴之间进行交换。

因此，AUTOSAR定义了诊断提取模板，该模板表示诊断功能上的标准化交换格式。Diagnostic Extract模板允许分散配置诊断方面。诊断提取模板的基本用法是在诊断开发过程中涉及的不同参与方之间交换诊断数据，以允许配置DCM和DEM，并提供相应应用程序接口的描述，以实现诊断服务和故障处理。在AUTOSAR方法中，诊断摘录由可交付的诊断摘录及其子可交付内容表示。

诊断摘要的内容

可交付的诊断摘要包含所有相关的诊断方面。

• 诊断服务(如IOControl、MemoryByAddress)

• 诊断事件处理(例如事件、故障代码、条件)

• 映射(服务映射、诊断映射等)

 

诊断提取类别

根据过程中的不同阶段，诊断提取可以有几个类别，这些类别可以表示为专门的可交付成果:

诊断抽象系统描述:此可交付成果表示

• 一个高级定义，可以作为创建具体的诊断系统摘要或诊断ECU摘要的模板。

• 诊断系统摘录:这个可交付成果代表了几个ecu的诊断方面。

• 诊断ECU提取:此可交付成果代表单个ECU的诊断方面。

 

分散配置

交换的时间和频率以及每个交换文件中的内容在很大程度上取决于各个项目的设置和情况。诊断提取模板的设计目的是支持分散的和独立的诊断需求定义，这些定义可以在开发过程的后期链接在一起。

诊断提取模板主要以两种方式满足分散配置的方法:

• 元素在多个物理文件上的分离:Diagnostic Extract模板的大多数元素可以在多个物理文件上进行分离。因此，这些元素的部分(例如某些属性)可以由原始设备制造商(OEM)定义，而这些元素的其他部分可以由ECU供应商(例如)定义。

• 自包含映射的使用:许多诊断需求是通过诊断元素之间的映射建立的(例如，DTC到DemEvent映射)。然而，“分散配置”方法要求这些映射可以在ECU开发过程中的几乎任何时间由任何相关公司的角色灵活定义。因此，Diagnostic Extract模板定义自包含的映射元素，这些元素引用两个(或更多)诊断元素来定义映射。

在下一个AUTOSAR4.5版本中，“角色和权限”概念的适当应用将限制诊断提取模板的使用。

诊断提取用例的相关活动在逻辑上划分为以下角色:诊断请求者、软件开发人员和诊断整合者。显然，OEM充当诊断请求者，ECU供应商充当诊断整合器。然而，在某些情况下(例如，内部开发应用软件组件)，OEM可能充当诊断整合器，执行收集和合并任务。

开发诊断抽象系统描述活动

诊断方面配置的基本工作流可以从可选活动开发诊断抽象系统描述开始。此活动在抽象级别定义诊断需求。所得到的诊断抽象系统描述可用于以下活动，作为诊断系统提取或诊断ECU提取的基础。

诊断要求的开发

在开发诊断需求活动中，诊断数据的请求者定义一个或多个ecu的诊断接口。可执行下列任务:

• 定义DTC的值

• 定义ECUs支持的UDS服务和子服务

• 定义应用程序开发人员在此活动期间实现的特定组合所需的事件，可能会收集和合并来自不同方面的多个开发诊断需求。

SW-C开发环境中的诊断信息

在软件组件的开发过程中，诊断提取的目的基本上是双重的:一方面，诊断系统提取可以作为软件开发人员的需求。诊断请求者可以指定下列问题:

•定义一个特定的ReadDataByIdentifier的内容，它必须由一个特定的SW-C实现

•定义某个SW-C所需的事件

另一方面，应用程序开发人员可以提供与SW-Cs相关的诊断信息，作为诊断系统提取和/或使用服务需求的一部分。SW-C描述中的服务需求仍然与诊断系统提取一起使用，以便注释与诊断系统提取定义的进一步映射和处理相关的SW-C端口。

诊断信息集成

在活动集成诊断信息中，集成程序从诊断请求程序和多个应用程序软件或基本软件开发人员那里接收一个或多个诊断系统摘要(或诊断ECU摘要)。集成活动的主要目标是对所有交付的诊断摘录进行集成和合并，从而生成相应的基本软件模块(DCM、DEM)的配置(ECU的活动集成软件)。

由于AUTOSAR方法不限制诸如DIDs、UDS服务的参数、事件、会话等元素在活动集成诊断信息中的定义，因此集成器必须确保在合并之后完整的信息仍然有效。通常可以执行以下任务:

• 将DTCs(故障诊断代码)映射到事件

• 合并事件

• 服务映射

在整合活动中，可以考虑以下问题和冲突:

• 一些DTC可能已经映射到事件，特别是来自同一方的事件。但是，如果原始设备制造商定义了DTC，而软件组件由充当应用程序开发人员的其他供应商实现，则集成商必须确保两者一起映射。

• 在某些情况下，一个诊断事件可能被定义多次。诊断请求程序定义应用程序开发人员应实现的事件。供应商实现了一个软件组件，该组件将在多个项目中使用，它还会检测这种类型的错误，并定义相同的事件。这两个事件可能有不同的命名，但有相同的含义。整合器必须在集成过程中检测这种冗余并将它们合并在一起。

• 诊断请求者需要一个特定的ReadDataByIdentifier，应用程序开发人员实现它。如果仅对一个特定项目执行实现，则应用程序开发人员可以从诊断中映射DID。

向其软件组件中已定义的作业的请求者。在应用程序开发人员实现通用诊断作业的其他情况下，将由诊断集成器负责合并此信息并将作业映射到相应的DID。

在解决所有问题和冲突并合并输入之后，将生成最终的完整诊断ECU提取。在此交付物的基础上，生成了相关的基本软件模块的初始配置(ECU的活动集成软件)。

 

工作流程：

诊断摘要能力模式总览

 

 

诊断摘要提取工作流程