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架构诊断功能简介

### AUTOSAR诊断协议的实现与应用 AUTOSAR(Automotive Open System Architecture)是一种开放式的汽车软件架构标准,其诊断协议栈是实现车辆ECU(电子控制单元)诊断功能的重要组成部分。以下将从AUTOSAR诊断协议栈的核心模块、UDS协议的作用以及其实现与应用展开详细说明。 #### 核心模块:DCM与DEM 在AUTOSAR中,诊断协议栈主要由两个核心模块组成:DCM(Diagnostic Communication Manager)和DEM(Diagnostic Event Manager)。 - **DCM模块**负责实现UDS(Unified Diagnostic Services)和OBD(On-Board Diagnostics)相关的诊断服务[^1]。这些服务基于ISO 14229标准定义,并位于OSI模型的应用层[^2]。DCM的主要职责包括接收和解析诊断请求、调用相应的诊断服务以及生成诊断响应。 - **DEM模块**则专注于DTC(Diagnostic Trouble Code)相关参数的管理与实现。它通过监测事件状态并触发相应的诊断动作来支持故障检测与报告。 #### UDS协议及其作用 UDS协议作为AUTOSAR诊断的核心部分,提供了统一的诊断服务接口,适用于整车所有ECU的诊断通信[^2]。其主要特点包括: - 基于ISO 14229标准,确保了诊断服务的规范化与标准化。 - 支持多种传输层协议(如CAN总线结合ISO 15765协议实现传输层功能)[^2]。 - 提供了丰富的诊断服务,例如读取数据标识符(Read Data by Identifier)、启动诊断会话(Start Diagnostic Session)以及清除诊断信息(Clear Diagnostic Information)等。 #### 实现与应用 在实际项目中,AUTOSAR诊断协议栈的实现通常遵循以下原则: 1. **基础环境准备**:首先需要构建一个能够调度运行的任务demo工程,在此基础上逐步扩展通讯协议栈功能[^4]。这样可以避免在系统服务(如操作系统、看门狗等)或模式管理上投入过多时间。 2. **模块开发**:根据项目需求分别实现DCM和DEM的功能。例如,DCM需要支持特定的诊断服务集,而DEM则需定义DTC的生成与存储逻辑。 3. **集成测试**:将诊断协议栈集成到目标硬件平台(如TC397)中,并使用配置工具(如Davinci Configurator)进行参数配置与验证[^4]。 以下是一个简单的代码示例,展示如何通过DCM模块处理诊断请求: ```c void Dcm_ProcessRequest(uint8_t serviceId, uint8_t *data, uint8_t length) { switch (serviceId) { case 0x10: // Start Diagnostic Session Dcm_StartSession(data, length); break; case 0x22: // Read Data by Identifier Dcm_ReadDataByIdentifier(data, length); break; default: Dcm_SendNegativeResponse(0x11); // Service Not Supported break; } } ``` ####
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值