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

<think>好的,我现在需要帮助用户了解AUTOSAR相关的诊断机制和实现方法。用户提到了Autosar诊断协议、实现方法以及标准,我需要结合提供的引用内容来组织答案。 首先,我应该先回顾用户提供的引用资料。引用[1]提到UDS是基于ISO 14229,位于OSI应用层,可以通过CAN总线实现。引用[2]指出DCM和DEM模块遵循ISO 15765和ISO 14229。引用[3]说明AUTOSAR诊断主要由DEM和DCM实现。引用[4]详细介绍了UDS的服务,如10、27、22、2E等。引用[5]提到AutoSAR标准协议文档涵盖诊断、网络管理等。 接下来,我需要将这些信息结构化。按照AUTOSAR诊断协议的核心模块开始,分点介绍DCM和DEM的功能。然后说明遵循的标准,如ISO 14229和ISO 15765。再描述实现方法,比如分层架构、服务处理流程、DEM的事件管理、NRC解码字典等。最后提到相关的开发资源,如AutoSAR标准协议文档。 需要注意用户提到的系统级指令,比如使用正确的LaTeX格式,生成相关问题。同时,回答中引用的部分要加上引用标识,比如[^1]、[^2]等。确保回答结构清晰,分点明确,语言简洁。 可能还需要检查是否有遗漏的关键点,例如诊断通信流程、具体的服务例子,以及实现时需要注意的标准细节。同时,确保生成的三个相关问题与主题相关,能够帮助用户进一步学习。 最后,确认所有引用都正确对应,没有错误,并且语言符合中文表达,不使用Markdown格式,行内公式用$...$,独立公式用$$...$$,但当前内容可能不需要太多公式,但如果有涉及数学表达式的地方需要正确应用。</think>### AUTOSAR诊断协议实现方法与标准解析 AUTOSAR诊断机制基于模块化设计,主要实现故障诊断通信管理(DCM)和诊断事件管理(DEM),其核心遵循ISO 14229(UDS)和ISO 15765(传输层协议)标准[^1][^3]。以下是关键实现方法与标准解析: --- #### **1. 核心模块与功能** - **DCM模块** 负责诊断通信协议的解析与响应,包括: - 接收并解析UDS请求(如$10$服务开启会话、$22$服务读取DID)。 - 校验请求格式与访问权限(如安全等级、会话状态)。 - 调用下层通信协议(如CAN TP)实现报文传输[^3][^4]。 - **DEM模块** 管理故障诊断事件的生命周期,包括: - 故障码(DTC)的存储、更新与清除。 - 触发事件关联的动作(如点亮故障指示灯、记录冻结帧)[^3][^5]。 --- #### **2. 遵循的核心标准** - **ISO 14229 (UDS)** 定义统一诊断服务,例如: - 会话控制($10$服务)、安全访问($27$服务)、读写数据($22/2E$服务)。 - 服务格式:请求格式为$SID + Subfunction + Parameter$,响应格式为$SID + Response Code + Data$。 - **ISO 15765-2 (CAN传输层)** 解决长报文的分段与重组(如多帧传输),确保诊断报文在CAN总线上的可靠传输。 --- #### **3. 典型实现方法** - **分层架构** $$ \text{应用层(UDS)} \rightarrow \text{传输层(CAN TP)} \rightarrow \text{数据链路层(CAN)} $$ 通过分层实现协议解耦,便于适配不同总线(如FlexRay、Ethernet)[^5]。 - **服务处理流程** 1. DCM接收请求,校验会话状态与安全等级。 2. 若合法,调用DEM或其他BSW模块获取数据。 3. 生成响应(正响应:$SID + 40$,负响应:$7F + SID + NRC$)。 - **NRC解码字典** 定义标准化否定响应码(NRC),例如: - $22$:条件不满足,$31$:请求超出范围。 - **DEM事件管理** 使用事件ID关联DTC,并通过计数器机制抑制偶发故障(如去抖算法)。 --- #### **4. 开发资源与工具** - **AutoSAR标准文档** 提供DCM/DEM模块的配置规范,包括: - 服务映射表、DID定义、事件触发条件。 - 通信时序与资源分配策略。 - **诊断协议栈工具** 如Vector Davinci Configurator,支持自动生成代码与集成测试[^5]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值