在深入研究AUTOSAR V3.1标准的基础上，分析其各层软件的复用性及其三种接口的区别，详细阐述AUTOSAR架构下的诊断实现——UDS服务、OBD服务和主要的功能模块。研究发现，AUTOSAR CAN诊断最大程度地提高了诊断模块复用性，但目前不支持SAE J1939和Bootloader。

AUTOSAR简介

1. 分层架构

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

2. 接口类型

AUTOSAR各层软件的交互通过三类接口实现，分别是标准接口、AUTOSAR接口和AUTOSAR标准接口。其中，标准接口用于BSW各个模块之间的交互，已用C语言定义，如void Adc_Init (const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件（Software Component, SW-C）之间的交互或者软件构件和ECU韧件（IO硬件抽象、复杂设备驱动）之间的交互，这类接口命名以“Rte_”为前缀。AUTOSAR标准接口用于软件构件访问AUTOSAR服务。

依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者，复用性越强。值得注意的是：

（1） 微控制器抽象层层级最低，随微控制器的更换而更换；

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

（3） 应用层（除传感器、执行器相关的软件构件外）完全独立于硬件，具有绝对的复用性。

汽车诊断简介

当前，OEM和供应商采用在线诊断与离线诊断相结合的诊断方法。在线诊断通过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线的0×05服务在0×06中实现。不支持UDS中的0×28（通信控制）、0×34（程序下载）0×35（程序上传）、0×36（数据传输）和0×37（请求传输退出）服务，且0×10服务不支持编程会话和扩展会话这两种子功能。这些服务主要用于ECU重新编程，因此AUTOSAR不支持Bootloader。

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

2.  软件架构

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

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架构中和诊断相关的核心模块。

（1）DCM  DCM模块遵循ISO 14229-1、ISO 15031-5、ISO 15765-4和SAE J1979标准，能直接处理0×10、0×27和0×3E服务。收到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。

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

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

结论

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

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

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

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