参考文献:《AUTOSAR AP 标准》
AP和CP相关资料和工具咨询可关注微信公众号“搞一下汽车电子”
手机/微信:18405011517
诊断管理实现了基于ISO 14229-5 (UDSonIP),ISO 14229-1 (UDS) 和ISO 13400-2 (DoIP)。
诊断管理表示使用ara::com的服务层上的自适应平台的功能集群。因此,它是独立于语言的,并且可以在将来与其他语言绑定(例如Java)一起服务于自适应应用。
配置基于经典平台的autosar诊断提取模板(dext)。德克斯特开始在市场上解决,并已被几个原始设备制造商和供应商使用和支持。
支持的传输层是DoIP。未来的自适应平台将支持进一步的传输层,如CAN。可能还计划支持定制的传输层,因为DoIP通常不作为车辆协议使用。
其作用是从自适应应用程序中抽象出诊断协议。接口与经典平台(如seteventstatus)协调,以方便经典平台开发人员进行更改。
传统上,在AUTOSAR Classic平台中,诊断是针对一个物理ECU,通常由一个微控制器运行DCM和DEM功能。然而,AUTOSAR自适应平台考虑了具有多个处理单元(多个微控制器、微处理器、GPU等)的ECU的进一步使用情况,以及具有进一步应用的动态扩展性。这需要一种新的机制来处理AP机器的不同部分。
原子可更新/可扩展部分由软件集群(SWCL)管理。SoftwareCluster包含与更新已安装或部署特定新功能/应用程序集相关的所有部分。因此,自适应诊断管理器支持每个已安装的软件集群都有自己的诊断地址的诊断服务器实例。请注意,该软件集群还与UCM的软件包耦合,以便软件集群可以更新或新引入机器。
诊断通信子集群就像经典平台的DCM——它实现了诊断服务器。目前,受支持的服务是有限的,但对进一步的UDS服务的支持将在未来的版本中得到扩展。
除了ISO 14229-1的伪并行客户机处理之外,诊断管理器(DM)还被扩展以支持对不同诊断客户机的完全并行处理。这满足了现代车辆体系结构的需求,包括多个诊断客户机(测试仪)用于数据收集、从后端访问、SOTA(空中软件)以及最终的经典车间和生产用例。
诊断感知自适应应用程序(AA)
在这种情况下,DM向AA发送一个传入的诊断请求(通常是例行控制或DID相关服务),AA提供一个明确的诊断相关接口(特定于UDS服务类型的服务接口)。例如,常规控制的服务接口由方法“start”、“requestResults”和“stop”组成,每个方法将特定的UDS错误代码定义为应用程序错误)。
由AA本身到uint8数组分析/序列化的参数
在这种情况下,以请求中的数据参数1开始的整个UDS数据参数和以正响应中的数据参数1开始的整个UDS数据参数作为输入/输出参数作为服务方法的uint8类型的向量给出。对于这样的用例,没有特定的映射到一个UDS请求,但是简单的转发,并且为了有一个非常灵活的请求处理方式,已经引入了GenericUdsService接口。
参数作为输入/输出方法参数
在这种情况下,根据与帝亚吉xt中数据参数n相关的诊断数据元素的类型定义,从请求中的数据参数1开始的整个UDS数据参数和从正响应中的数据参数1开始的整个UDS数据参数被作为数据类型的不同输入/输出参数给出。
事件内存子集群类似于经典平台的DEM——它负责DTC管理。
支持的功能和界面类似于经典平台。诊断监视器表示为(诊断)事件,可与故障诊断码结合使用。该故障诊断码可以分配给PrimaryMemory(可通过19 02/04/06访问)或可配置用户存储器(可通过0x19 17/18/19访问)。故障诊断码可以存储快照和扩展数据记录。
支持计数器和时基去抖动。此外,dm还提供有关内部转换的通知:通知相关方有关DTC状态字节更改、诊断事件需要重新初始化监视器以及快照或扩展数据记录是否更改。
运行周期变化——对老化和准备状态计算很重要——需要转发给DM。
同样适用于存储和启用条件,需要将更改转发给DM。通过启用条件,可以控制故障诊断码的一般更新,例如在欠电压条件下禁用所有与网络相关的监视器。根据存储条件,故障诊断码不能存储在故障诊断码存储器中。