解析AUTOSAR CAN诊断实现

     AUTOSAR是由全球汽车OEM和供货商共同推出的一种汽车电子嵌入式软件分层架构。该分层架构由微操纵器微操纵器

　　一个微操纵器，（也称作微处理器或MCU）就是一个小型的计算机，它由一系列简洁的电路和一些支持微处理器作用的简洁模块组成，如晶体振荡器，定时器，看门狗，串行和模拟I / O口等等。芯片里包括非闪烁存储器和OTP ROM 用来存储程序，以及一个很小的读写程序。 [全文]

抽象层、ECU抽象层、服务层、执行时环境(Rte)和应用层组成，前三层被统称为基础软件(BSW)。

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

　　* 微操纵器微操纵器

　　一个微操纵器，（也称作微处理器或MCU）就是一个小型的计算机，它由一系列简洁的电路和一些支持微处理器作用的简洁模块组成，如晶体振荡器，定时器，看门狗，串行和模拟I / O口等等。芯片里包括非闪烁存储器和OTP ROM 用来存储程序，以及一个很小的读写程序。

抽象层层级最低，随微操纵器的换掉而换掉；

　　* RTE虽然层级仅低于应用层，但由于它负责着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有可重用性；

　　* 应用层(除传感器传感器

　　凡是利用一定的物性（物理、化学、生物）法则、定理、定律、效应等把物理量或化学量转变成便于利用的电信号的器件。传感器是测试系统中的一种前置部件，它将输入变量转换成可供测试的信号”。按照Gopel等的说法是：“传感器是包括承载体和电路连接的敏感元件”，而“传感器系统则是组合有某种信息处理(模拟或数字)能力的系统”。传感器是传感系统的一个组成部分，它是被测试信号输入的第一道关口。 [全文]

、执行器执行器

　　执行器是自动操纵系统的终端执行部件，由执行机构和调节机构组成，负责从自动化技术工具中接收操纵信息并对受控对象施加操纵作用。 [全文]

相关的软件构件外)完全独立于硬件，具有绝对的可重用性。

图1：AUTOSAR分层架构。

　　汽车诊断简介

　　目前，整车厂和供货商采纳在线诊断与脱机诊断相结合的诊断方法。在线诊断通过ECU内部软硬件实现自诊断。在汽车执行过程中，自诊断系统实时监控电子操纵系统各组成部分的工作状态，因而检测电子操纵系统中的故障。自诊断系统一方面将检测出的故障通过一定的方式(比如警报指示灯)向驾驶员发出警告，另一方面将故障程序代码及相关数据存入ECU内存内存

　　内存的正式叫法是内存储器，以此来与外存储器区分开。物理上它安装在计算机内部，通常安装在主板上，所以称为内存。它的作用是供临时存储处理器需要处理的数据或处理后的结果，可见内存是计算机处理器的工作空间。它是处理器运行的程序和数据必须驻留于其中的一个临时存储区域，是计算机十分重要的部件。 [全文]

。脱机诊断通过外部诊断设备读取相应的诊断信息，实现诊断作业。实现脱机诊断的要害在于如何实现诊断设备和ECU之间的通信机制和诊断服务，即诊断协议。

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

　　AUTOSAR CAN诊断实现

　　1) 诊断服务

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

　　依据表2和表3可知，AUTOSAR不支持OBD中的0x05服务(请求氧传感器氧传感器

　　氧传感器是利用陶瓷敏感元件测试各类加热炉或排气管道中的氧电势，由化学平衡原理计算出对应的氧浓度，达到监测和操纵炉内燃烧空然比，保证产品质量及尾气排放达标的测试元件，广泛应用于各类煤燃烧、油燃烧、气燃烧等炉体的气氛操纵。它是目前最佳的燃烧气氛测试方式，具有结构简洁、响应迅速、维护轻易、使用方便、测试正确等优点。运用该传感器进行燃烧气氛测试和操纵既能稳定和提高产品质量，又可缩短生产周期，节约能源。 [全文]

监测结果)，缘由在于基于CAN线的0x05服务在0x06中实现。不支持UDS中的0x28(通信操纵)、0x34(程序下载)、0x35(程序上传)、0x36(数据传输)和0x37(请求传输退出)服务，且0x10服务不支持编程会话和扩展会话这两种子功能。这些服务主要用于ECU重新编程，因此AUTOSAR不支持BootlOAder。

图2：AUTOSAR CAN诊断相关模块。

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

　　2) 软件架构

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

　　FIM模块的作用是根据DEM(Diagnostic Event Manager)报告的事件状态使能或禁止软件构件内部的功能实体。PDU Router(协议数据单元路由器路由器

　　路由器是用来连接不同网络或网段的装置，它能够根据信道的情况自动选择并设定路由，以最佳路径，按前后顺序发送信号。路由器构成了 Internet的骨架。路由器的处理速度与可靠性直接影响着网络互连的速度与质量。 [全文]

)模块仅负责转发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)和DSPDSP

　　dsp是digital signal processor的简称，即数字信号处理器。它是用来完成实时信号处理的硬件平台，能够接受模拟信号将其转换成二进制的数字信号，并能进行一定形式的编辑，还具有可编程性。由于强大的数据处理能力和快捷的运行速度，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将成为必定趋势。

  来源:zhouxiao

该文章来至网络或用户，仅供学习交流之用，版权归原作者所有。
如有侵权，请及时与我们联系！

基于CAN总线智能建筑监控系统的通信协议设计

摘要：从研究CAN2．OB总线规范入手，介绍了CAN总线规范的硬件基础，分析了CAN总线报文格式，通过对报文标识符的分配，设计了应用于该系统的通信协议，并给出了软件设计流程...

客车网络操纵中的CAN/CAN网桥设计方案

1 引言　　操纵器局部网CAN（ControllerAreaNetwork）是德国RobertBosch公司在20世纪80年代初为汽车业开发的一种车载专用串行数据通信总线，经过多年的进展，现在越来越多...

基于WinCE的CAN适配卡驱动程序的设计与实现

1 引言　　WinCE是一种为多种嵌入式系统和产品设计的紧凑、高效、可升级的操作系统，WinCE 采纳标准模式，其最主要的特征：为有限的硬件资源提供了多线程、多任务和完全优...

CAN 总线车载网络通讯组件的研究和实现

摘要: 本文提出了一种基于CAN 总线的车载网络软件解决方案。该方案可将应用与网络协议分开，以便降低整车厂商对硬件供给商的依靠性，同时提高软件的复用性和可移植性。该方...

过程分析仪器CAN 网络通信设计

摘要：为了解决在工业生产中碰到的现场检测信息的采集、处理和同步等问题，提出了实现过程分析仪器CAN 总线网络通信的方法。根据项目的设计要求，制定了适用的CAN 应用层协...