AUTOSAR_EXP_PlatformDesign - 09 Diagnostics

AUTOSAR_EXP_PlatformDesign - 09 Diagnostics 

【translated by sky8336, 2019.06.08, Shanghai】

9 Diagnostics 

9.1 Overview 

诊断管理实现了基于ISO 14229-1 (UDS)和ISO 13400-2 (DoIP)的ISO 14229-5 (UDSonIP)。

 

诊断管理使用ara::com表示服务层自适应平台的功能集群。因此，它是独立于语言的，将来可能能够与其他语言绑定(如Java)一起提供自适应应用程序。

该配置基于经典平台的AUTOSAR诊断提取模板(Diagnostic Extract Template, DEXT)。DEXT开始进入市场，并已被多家oem和供应商使用和支持。

 

支持的传输层是DoIP。未来的自适应平台将支持进一步的传输层，例如CAN。可能还计划支持自定义传输层，因为DoIP通常不用作车载协议。

 

范围是从自适应应用程序中抽象诊断协议。这些接口与经典平台(例如SetEventStatus)相协调，允许对经典平台开发人员来说简单的更改。

 

传统上在AUTOSAR经典平台中，诊断是针对一个物理ECU的，通常使用一个运行DCM和DEM功能的微控制器。但是，AUTOSAR Adaptive Platform考虑了ECUs的更多用例，包括多个处理单元(多个微控制器、微处理器、gpu等等)，以及进一步应用程序的动态扩展。这将需要一种新的机制来处理AP机器的不同部分。

 

原子可更新/可扩展部件由软件集群(SoftwareClusters，SWCL)管理。软件集群包含与更新安装或部署一组特定的新功能/应用程序相关的所有部分。因此，Adaptive Diagnostics Manager为每个已安装的软件集群支持它们自己的诊断服务器实例，每个实例都有自己的诊断地址。请注意，此软件集群还与UCM软件包耦合，以便软件集群可以被更新或新引入到机器上。

 

9.2 Diagnostic communication sub-cluster（诊断通信子集）

诊断通信子集群类似于经典平台的DCM，它实现了诊断服务器。目前，所支持的服务是有限的，但是对更多的UDS服务的支持将在未来的版本中得到扩展。

 

除了ISO 14229-1的伪并行客户机处理之外，还扩展了诊断管理器(DM)，以支持对不同诊断客户机的完全并行处理。这满足了现代车辆体系结构的需求，包括用于数据收集的多个诊断客户端(tester)、从后端的访问、SOTA(Software Over-the-Air)以及最后的经典车间和生产用例。

 

诊断感知自适应应用(AA)

在这种情况下，DM将传入的诊断请求(通常是例程控制或DID相关服务)分派给AA, AA提供显式的诊断相关接口(特定于UDS服务类型的服务接口。例如，例程控制的服务接口由方法“start”、“requestResults”和“stop”组成，每个方法都将特定的UDS错误代码定义为应用程序错误。)

 

Parameters parsed/serialized by AA itself from/to UINT8-Array（AA本身从/到UINT8-Array解析/序列化的参数）

在本例中，以请求中的data-parameter#1开始的整个UDS数据参数和以正响应中的data-parameter#1开始的整个UDS数据参数作为In /OUT参数，它们作为UINT8类型的向量提供给服务方法。对于这样的用例，我们引入了GenericUDSService接口，在这些用例中，没有特定的映射到UDS请求，而只是简单的转发，并且具有非常灵活的请求处理方式。

 

Parameters are given as typed in/out method parameters （参数以输入/输出方法参数的形式给出）

在这种情况下,在请求中的以data-parameter#1开始的整个UDS数据参数和在正响应中的以data-parameter#1开始的整个UDS数据参数被给出作为明确的 IN/OUT 数据类型的参数，这根据DiagExt中与data-parameter#N 相关的 DiagnosticDataElement 类型定义做出。

 

9.2.1 Diagnostic conversations（诊断会话）

正如上面提到的，DM需要伪并行和完全并行的客户机处理，因此它支持诊断对话，以反映诊断客户机和诊断服务器之间的不同对话。诊断服务器由根据UDS请求的目标地址标识，并在自适应平台的运行时动态分配。在经典的平台中，分配必须静态配置。

 

注:关于ara::diag的部分是开放的，因为讨论正在进行中。到目前为止，还没有指定任何内容。

 

9.3 Event memory sub-cluster 

事件内存子集群类似于经典平台的DEM，负责DTC管理。

-----------------

note:

DTC: Diagnostic Trouble Code

------------------

所支持的功能和接口与经典平台类似。诊断监视器表示为(诊断-)事件，可以与DTC结合。DTC可以分配给主内存(通过19 02/04/06访问)或可配置的用户内存(通过0x19 17/18/19访问)。DTC可以存储快照(Snapshot- )和扩展数据记录(ExtendedDataRecords)。

 

支持Counter- and Timebase Debouncing(反时基和时基销毁?)。此外，DM还提供关于内部转换的通知:感兴趣的各方将被告知有关DTC状态字节更改、为DiagnosticEvents 重新初始化监视器的需要以及快照或ExtendedDataRecord是否更改。

 

操作周期的变化——对老化和准备计算很重要（the aging and readiness calculation ）——需要提交给DM。

 

同样的情况也适用于存储器，并且启用条件的更改需要转发给DM。通过启用条件，可以控制DTCs的一般更新，例如在电压不足条件下禁用所有网络相关监视器。根据存储条件，DTC不能存储在DTC内存中。

 

-----------

【end-2019.06.08】