AUTOSAR诊断简介

AUTOSAR诊断简介


AUTOSAR架构的目标主要有三个:

  • 建立独立于硬件的分层软件架构
  • 为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU
  • 制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同汽车平台复用

这里写图片描述

AUTOSAR整体框架为分层式设计,以中间件RTE(Runtime Environment)为界,隔离上层的应用层(Application Layer)与下层的基础软件BSW(Basic Software)

车辆诊断定义

对于整车厂而言,诊断分为两类,易于被用户感知的仪表故障灯显示隶属主机厂采用的在线诊断模式(Onboard Diagnostic System),通过车内模块自带的在线诊断系统对ECU的软硬件及各传感器参数进行某些常见故障的实时监控与发现,当系统判断电控系统出现故障时,会以仪表警示灯亮的形式来告知驾驶者,并在ECU的EEPROM或Flash内对相关DTC(Diagnostic Trouble Codes)进行存储,以便后续车辆被送至售后处,工程师对其进行故障检测时读取分析处理。值得记住的是,在线诊断技术首先由通用汽车引入。

诊断第二种类型为离线诊断模式(Offboard Diagnostic System),即将外部设备接在OBD诊断口上与整车网络各ECU进行通讯,以对各模块数据实行监控与检测分析。诊断设备通过发送满足诊断协议定义的诊断服务来实现诸如对已存储DTC的读取与清除,利用其他的整车控制指令来实现对车辆的动静态控制。

目前OEM在产品前期开发及售后过程中最常见的两种通信工具有美国英特佩斯公司的NeoVI fire(目前已有fire 2)/ RED + Vehicle SPY3及Vector的CANoe CAN。

诊断协议标准

参照互联OSI 7层模型,把目前整车网络中最常用的ISO(International Standards Organization)与SAE(Society of Automotive Engineers)两套标准协议做出如下归类:

简单介绍两个最常见且较有代表性的诊断体系标准,若需要可自行检索下载阅读:
这里写图片描述

  • ISO 15765

Road Vehicles-Diagnostics on Controller Area Network,是车辆基于CAN诊断的标准协议。通讯方面开发能力强的公司会进行协议定制,如北美通用(GM)在ISO 15765-2的基础上进行定制化开发出应用于Service Layer及Transport Layer的GMLAN,该协议也被其他某些厂家采用。

  • ISO 14229

ISO 14229,也就是近年常被行业内提及的UDS protocol(Unified Diagnostic Service)。标准中定义出了诊断服务在数据链路上的独立需求。通过标准化的诊断服务,用户可以使用诊断工具(Client端)直接控制ECU(Server端)的电子燃油喷射、节气门转角、转速、ABS系统、EPS模块等(是否能联想到某前瞻扩展领域的应用)。

AUTOSAR诊断重要组成

AUTOSAR诊断功能模块主要实现部分为ECU软件中的故障诊断事件管理(DEM)以及故障诊断通信管理(DCM),通讯接口如图所示:
这里写图片描述
这里写图片描述

故障诊断事件管理DEM

DEM则负责直接处理与DTC相关的诊断服务,例如UDS中的0x19(读取故障码)及0x14(清除故障码)的服务,在ECU运行过程中,Monitor Function会进行持续的status检测,一旦出现疑似故障时,会直接调用DEM来进行故障check,确认后即可完成将诊断故障数据写入到EEPROM或者Flash中的过程。对于在线诊断模式(Onboard Diagnostic System),SWC在从DEM中读取到故障信息的同时,会将以故障灯的形式告知驾驶人员。

故障诊断通信管理DCM

DCM支持ISO 14229-1标准,主要负责确保诊断通信数据流,及包括安全访问在内的诊断状态控制,因此支持0x10(Session Control)、0x27(Security Access)。当总线给该ECU发送UDS协议中定义的诊断请求指令时,DCM会调用DEM、SWC或者是其他基础软件模块提供的接口进行如诊断请求判断、诊断功能执行以及响应的反馈。

具体实现上,DCM分成三个子模块:

  • 诊断服务处理器(Diagnostic Service Processing, DSP)

DSP位于DCM的最上层,可理解为一个包含了通用性诊断服务的容器,用于处理各应用间共性的服务,如故障相关信息等数据的处理。当DSD完成诊断请求处理并且将请求转发出来后,DSP对该消息进行处理。

  • 诊断服务调度器(Diagnostic Service Dispatcher, DSD)

DSD位于DCM中间层,当接收到诊断请求后,会将请求转发给DSP。同样,在DSP完成诊断请求处理后,也会将响应转发出来。

  • 诊断会话层(Diagnostic Session Layer, DSL)

DSL位于DCM最底层,主要负责接收模块上传的诊断请求并最终发送出诊断响应数据,并管理、确保诊断协议的Timing以及诊断状态。

数据交互及接口如下:
这里写图片描述
无论是传统汽车电子架构亦或是将来新能源车型的逐步推广,车辆诊断技术在整个汽车产品的设计研发、工厂制造及售后环节中都会起到极其重要的作用。从对K线到CAN,再到不久后的CAN FD以及Ethernet的支持,作为其核心的诊断通信协议也将会随着整车功能的完善及车载总线系统的更新迭代而日益丰富。AUTOSAR的出现,促成了汽车电子软件的高效管理,其中所使用的如UDS的协议同样也将进一步推动汽车诊断领域的标准统一与发展。

文章主要参考AUTOSAR架构诊断功能简介

猜你喜欢

转载自blog.csdn.net/helaisun/article/details/80551561