元器件交易网-中发网全新升级平台
关注我们:
首页 > IC技术 > 生产/测试/封装 > 正文

汽车AUTO SARCAN诊断实现

    中心议题:

    汽车诊断简介

    AUTOSARCAN诊断实现


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

    AUTOSAR各层软体的通讯透过叁类介面实现,分别是标準介面、AUTOSAR介面和标準AUTOSAR介面。其中,标準介面用于BSW各个模组之间的通讯,已用C语言定义,如voidAdc_Init(constAdc_ConfigType*ConfigPtr)。AUTOSAR介面用于软体构件(SW-C)之间的通讯或者软体构件和ECU韧体(IO硬体抽象、复杂设备驱动)之间的通讯,这类介面命名以‘Rte_’为前缀。标準AUTOSAR介面用于软体构件存取AUTOSAR服务。依赖这种分层架构和介面定义,AUTOSR显着提高了汽车电子嵌入式软体的再使用性──层级越高者,再使用性越强。值得注意的是:

    *微控制器抽象层层级最低,随微控制器的更换而更换;
    *RTE虽然层级仅低于应用层,但由于它负责着应用层和BSW之间的桥樑作用,和硬体的耦合性最高,不具有再使用性;
    *应用层(除感测器、执行器相关的软体构件外)完全独立于硬体,具有绝对的再使用性。

    汽车诊断简介

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

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

    AUTOSARCAN诊断实现

    1)诊断服务
 
    目前,AUTOSARV3.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。

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

    2)软体架构

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

    FIM模组的作用是根据DEM(DiagnosticEventManager)报告的事件状态使能或禁止软体构件内部的功能实体。PDURouter(协议数据单元路由器)模组仅负责转发DCM(DiagnosticCommunicationManager)和CANTP(CANTransportLayer)之间的I_PDU(交互层协议数据单元),不会对数据进行任何修改。CANInterface模组、CANDriver模组和CANTransceiver模组负责L_PDU(数据链路层协议数据单元)的传输。

    DEM、DCM和CANTP是AUTOSAR架构中和诊断相关的核心模组。

    3)DCM

    DCM模组遵循ISO14229-1、ISO15031-5、ISO15765-4和SAEJ1979标準,能直接处理0x10、0x27和0x3E服务。收到AUTOSAR支援的OBD服务或其他UDS服务时,靠叫DEM、软体构件或者其他BSW模组提供的介面进行响应。

 


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

    4)DEM
 
    DCM模组遵循的标準与DCM相同,负责直接处理与DTC相关的服务,如UDS中的0x19服务(响应报文由DCM发送出去)。当软体构件中的MonitorFunction检测到故障或BSW模组检测到故障时,将通知DEM模组处理和储存‘诊断事件’(由EventID进行标识)。如果故障确诊,唿叫NVRAMManager(非挥发性记忆体管理器)提供的介面将其存取到非挥发性记忆体中,同时通知应用层进行故障指示。DEM的状态图如图3所示:

    5)CANTP模组

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

    第一、由于严格分层,除了CANDriver和CANTransceiver模组要依赖于硬体,AUTOSAR与诊断相关的模组几乎完全独立于硬体。按照此架构开发完成的诊断程式码能够摆脱硬体的束缚,具有最大程度的再使用性。

    第二、AUTOSAR目前不支援SAEJ1939。

    第叁、暂时不能直接将AUTOSAR软体架构用于Bootloder程式的开发。

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

扫描左侧的二维码

科技圈最新动态一手掌握
每日砸蛋,中奖率100%