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之间的桥梁作用，和硬件的耦合性最高，不具有可重用性；
* 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的可重用性。
图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(协议数据单元路由器)模块仅负责转发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
DEM模块遵循的标准与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将成为必然趋势。
AUTOSAR在CAN上的处理与我们传统的使用还是有比较大的差异，过去我们写CAN的代码，也就是写了CAN基本的Tx和Rx驱动，收到原始8个bytes的数据后，进行什么处理或者在哪一层处理都由自己随意来定，有的甚至8bytes数直接在APP层用建模进行解析处理，这种情况也不少见，也没有不对。而AUTOSAR出于解耦，隔离及统一接口的因素考虑，将CAN做了多个层次的处理，不再只是一个底层驱动+应用层（或增加一个中间层）。
下面是AUTOSAR常见的介绍：
红框部分是和通讯相关的内容，包含LIN，CAN，Eth等，我们重点介绍CAN。和汽车领域中大家熟知的和CAN相关最重要的三部分就是诊断，标定及COM。
我们结合两张图中来看AUTOSAR中的分层和数据走向：
第一张图中可以看出根据不同的层次，CAN在不同的层次的数据包分为了
* 数据链路层：L-PDU
* 网络层（通常用的是TP层）：N-PDU
* 交互层：I-PDU
可以看到CAN Driver和CAN Interface部分COM，XCP，UDS仍然是共用的，再往上就有不同的分支：
* UDS需要通过TP层，再进入PDUR进行分配进入DCM
* XCP相对独立直接由CAN interface进入后独立处理，不经过PDUR
* COM则从CAN Interface进入PDUR然后分配至COM
是否已经被各种PDU弄蒙圈了，下面是PDU和PDUR的官方解释，一起来理解一下：
PDU是“协议数据单元”的缩写。PDU包含SDU和PCI。在传输端，PDU从上层传递到下层，下层将PDU解释为SDU。
1.提供不同抽象通信控制器与上层之间的pdu路由
2.路由器的规模是特定于ECU的(如果只有一个通信控制器存在，则没有大小)
3.实时提供TP路由。在缓冲完整的TP数据之前，会启动TP数据的传输
简单的说，PDU中包含地址信息（当前层和目标层的地址信息）和数据信息，PDUR通过地址信息分配到不同的目标地。下图是PDU的组成，可以加深理解
PDU包含PCI和SDU，PCI包含源地址和目标地址信息，SDU是数据信息。
在我们关注的CAN传输中最关键的信息I-PDU，I-PDU并不是某一层单独所有的信息，也不是CAN单独所有的内容，可以在前一个图中看出I-PDU是进出PDUR的信息。而I-PDU是包含地址信息和数据信息的。
最后拿大家最关注的COM来说明各层的数据走向，以收取报文来举例：由CAN Driver收取报文生成L-PDU,而后进入CAN Interface进行抽象隔离处理，生成I-PDU，进入PDUR进行分配，根据地址信息（PCI）将进入COM模块的I-PDU传入COM，COM对I-PDU的数据信息SDU进行解析，生成signals，signals通过RTE传输给APP层，发送则正好相反