解析AUTOSAR CAN诊断实现

liyf

                    ???? 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显著提高了汽车电子嵌入式软件的可重用性——层级越高者，可重用性越强。值得注意的是：
　　* 微控制器抽象层层级最低，随微控制器的更换而更换；
　　* RTE虽然层级仅低于应用层，但由于它负责着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有可重用性；
　　* 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的可重用性。




　　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。




图3：DEM状态图。
　　5) CAN TP模块
　　遵循ISO 15765-2标准。负责诊断报文的寻址、拆包与打包，以及网络层定时参数的管理。所以，该模块向下传输的是N_PDU(网络层协议数据单元)。
　　本文小结
　　第一、由于严格分层，除了CAN Driver和CAN Transceiver模块要依赖于硬件，AUTOSAR与诊断相关的模块几乎完全独立于硬件。按照此架构开发完成的诊断程序码能够摆脱硬件的束缚，具有最大程度的可重用性。
　　第二、AUTOSAR目前不支持SAE J1939。
　　第三、暂时不能直接将AUTOSAR软件架构用于Bootloder程序的开发。
　　综上所述，AUTOSAR标准仍旧处于发展和完善阶段，但随着目前汽车ECU软件开发矛盾的加剧，开发难度不断增大，开发周期却不断缩短，AUTOSAR将成为必然趋势。