您当前位置:首页 > 大数据

AUTOSAR CAN诊断实现研究

发布时间:2019-11-10 09:30:50编辑:迪威国际登录-16563835730阅读次数:
AUTOSAR CAN诊断实现研究

AUTOSAR是由全球汽车OEM和供应商共同推出的一种汽车电子嵌入式软件分层架构。该分层架构由微控制器抽象层、ECU抽象层、服务层、运行时环境(RTE)和应用层组成,前三层被统称为基础软件(BSW)。

AUTOSAR各层软件的交互通过三类接口实现,分别是标准接口、AUTOSAR接口和标准AUTOSAR接口。其中,标准接口用于BSW各个模块之间的交互,已用C语言定义,如void Adc_Init(const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件(SW-C)之间的交互或者软件构件和ECU韧件(IO硬件抽象、复杂设备驱动)之间的交互,这类接口命名以“Rte_”为前缀。标准AUTOSAR接口用于软件构件访问AUTOSAR服务。依赖这种分层架构和接口定义,AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者,复用性越强。值得注意的是:

l 微控制器抽象层层级最低,随微控制器的更换而更换;

l RTE虽然层级仅低于应用层,但由于它承担着应用层和BSW之间的桥梁作用,和硬件的耦合性最高,不具有复用性;

\

l 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件,具有绝对的复用性。


图1 AUTOSAR分层架构

汽车诊断简介

当前,整车厂和供应商采用在线诊断与离线诊断相结合的诊断方法。在线诊断通过ECU内部软硬件实现自诊断。在汽车运行过程中,自诊断系统实时监控电子控制系统各组成部分的工作状态,从而检测电子控制系统中的故障。自诊断系统一方面将检测出的故障通过一定的方式(比如报警指示灯)向驾驶员发出警告,另一方面将故障代码及相关数据存入ECU存储器。离线诊断通过外部诊断设备读取相应的诊断信息,实现诊断操作。实现离线诊断的关键在于如何实现诊断设备和ECU之间的通信机制和诊断服务,即诊断协议。

目前,诊断协议标准主要分为ISO和SAE两种体系。美国使用SAE标准体系,包括中国在内的多数国家使用ISO标准体系。在乘用车领域,OEM正从自定义诊断协议逐渐转向ISO标准。在商用车领域,OEM沿用SAE诊断,欧洲OEM在此基础上增加了ISO诊断。表1列出了部分ISO和SAE标准对照。


表1 ISO与SAE标准对照(不含SAE J1939)

AUTOSAR CAN诊断实现

1) 诊断服务

目前,AUTOSAR V3.1诊断部分支持9个OBD服务(如表2所示),14个UDS服务(如表3所示)。


表2 AUTOSAR支持的OBD服务

\


表3 AUTOSAR支持的UDS服务

依据表2和表3可知,AUTOSAR不支持OBD中的0x05服务(请求氧传感器监测结果),原因在于基于CAN线的0x05服务在0x06中实现。不支持UDS中的0x28(通信控制)、0x34(程序下载)、0x35(程序上传)、0x36(数据传输)和0x37(请求传输退出)服务,且0x10服务不支持编程会话和扩展会话这两种子功能。这些服务主要用于ECU重新编程,因此AUTOSAR不支持Bootloader。

虽然AUTOSAR目前不支持上述服务,但并未限制开发者对其进行扩展。

2) 软件架构

AUTOAR架构中和诊断相关的模块如图2所示。


图2 AUTOSAR CAN诊断相关模块

FIM模块的作用是根据DEM(Diagnostic Event Manager)报告的事件状态使能或禁止软件构件内部的功能实体。PDU Router(协议数据单元路由器)模块仅负责转发DCM(Diagnostic Communication Manager)和CAN TP(CAN Transport Layer)之间的I_PDU(交互层协议数据单元),不会对数据进行任何修改。CAN Interface模块、CAN Driver模块和CAN Transceiver模块负责L_PDU(数据链路层协议数据单元)的传输。

DEM、DCM和CAN TP是AUTOSAR架构中和诊断相关的核心模块。

3) DCM

DCM模块遵循ISO 14229-1、ISO 15031-5、ISO 15765-4和SAE J1979标准,能直接处理0x10、0x27和0x3E服务。收到AUTOSAR支持的OBD服务或其他UDS服务时,靠调用DEM、软件构件或者其他BSW模块提供的接口进行响应。

AUTOSAR建议用三个功能块组成DCM,分别是DSL(Diagnostic Session Layer)、DSD(Diagnostic Service Dispatcher)和DSP(Diagnostic Service Processing)。其中DSL负责处理PDU Router传来的诊断请求,管理会话层和应用层定时参数,处理会话状态的切换等。DSD负责将DSL传来的诊断请求转发给DSP,同时将DSP传来的诊断响应报文传给DSL。DSP负责分析接收到的诊断请求报文,检查其报文格式以及其请求的子功能。只有在诊断请求报文的服务标识符、子功能、报文格式等条件都满足的情况下,DSP才会处理收到的请求报文,并将处理结果整理成诊断响应报文发给PDU Router。

4) DEM

DCM模块遵循的标准与DCM相同,负责直接处理与DTC相关的服务,如UDS中的0x19服务(响应报文由DCM发送出去)。当软件构件中的Monitor Function检测到故障或BSW模块检测到故障时,将通知DEM模块处理和存储“诊断事件”(由Event ID进行标识)。如果故障确诊,调用NVRAM Manager(非易失存储器管理器)提供的接口将其存取到非易失存储器中,同时通知应用层进行故障指示。DEM的状态图如图3所示:

\


图3 DEM状态图

5) CAN TP模块

遵循ISO 15765-2标准。负责诊断报文的寻址、拆包与打包,以及网络层定时参数的管理。所以,该模块向下传输的是N_PDU(网络层协议数据单元)。

结论

第一、由于严格分层,除了CAN Driver和CAN Transceiver模块要依赖于硬件,AUTOSAR与诊断相关的模块几乎完全独立于硬件。按照此架构开发完成的诊断代码能够摆脱硬件的束缚,具有最大程度的复用性。

第二、AUTOSAR目前不支持SAE J1939。

第三、暂时不能直接将AUTOSAR软件架构用于Bootloder程序的开发。

综上所述,AUTOSAR标准仍旧处于发展和完善阶段,但随着目前汽车ECU软件开发矛盾的加剧,开发难度不断增大,开发周期却不断缩短,AUTOSAR将成为必然趋势。

参考文献:

[1] AUTOSAR Consortium, “Technical Overview” v2.2.2, R3.1 Rev0001, August 2008.

[2] Per Johannessen, “AUTOSAR Safety Approach Convergence 2006”, Transportation Electronics Conference, Detroit, 2006.

[3] AUTOSAR Consortium, “Specification of Diagnostic Communication Manager,” v3.1.1, R3.1 Rev0001, August 2008.

[4] International Standards Organization, “Road vehicles-Communication between vehicle and external equipment for emissions-related diagnostics”,Jan 2006.

[5] International Standards Organization, “Road vehicles-Unified diagnostic services(UDS)”,Revision of ISO 14229:1998.

[6] AUTOSAR Consortium, “Specification of Function Inhibition Manager” v1.3.1, R3.1 Rev0001, August 2008.

[7] AUTOSAR Consortium, “Specification of Diagnostic Event Manager” v3.0.1, R3.1 Rev0001, August 2000.

[8] AUTOSAR Consortium, “Specification of CAN Transport Layer” v2.2.2, R3.1 Rev0001, August 2008.

本文链接:AUTOSAR CAN诊断实现研究

友情链接:

大悲咒经文 观音心经 佛经