您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
AutoSAR 诊断模块的重点概念

 
作者: Archieeeeee
  2560  次浏览      15 次
 2022-11-3
 
编辑推荐:
本文主要介绍DCM 与DEM模块,以及这两个模块在Autosar架构下如何运行。同时介绍了UDS 和OBD中相关概念。
本文来自于微信公众号车端,由火龙果软件Linda编辑、推荐。

1.术语与缩写

2.文章简介

本文主要介绍DCM 与DEM模块,以及这两个模块在Autosar架构下如何运行。同时介绍了UDS 和OBD中相关概念。

3.DCM模块

1.什么是DCM

如上图所示,DCM模块负责接收并响应诊断仪的数据请求。在AUTOSAR_SWS_DCM文档中描述如下:

也就是说,DCM模块负责诊断数据流以及诊断状态的管理。并且检查请求的服务是否在当前的会话和安全等级中支持。

2.DCM模块如何工作

根据上图可以看出,当ECU接收到诊断报文时,经过CANTp模块进行网络层解析(15765-2),在根据报文的归属判断,由PDUR模块转发置DCM模块。当DCM收到诊断报文时,DCM模块就开始运行了。

DCM模块由三个子模块组成:DSL DSD DSP组成。

DSL:Diagnostic Session Layer,DSL模块负责确认诊断数据流的请求与响应。确保诊断计时以及诊断状态的切换。

DSD: Diagnostic Service Dispatcher,DSD负责接收网络上的诊断请求,并转发到对应的数据处理模块。接收响应数据并将数据传递给DSL模块,在由DSL模块发送到网路。

DSP:Diagnostic Service Processing,DSP负责处理诊断服务请求。

三个模块架构如下:

3.诊断服务(UDS&OBD)

DCM是服务的形式响应诊断仪的数据请求的。DCM支持UDS(14229-1)和OBD-II(15765-4)的全部服务。这里只介绍一部分诊断服务,详细请参考14229和15031。

10服务

DiagnosticSessionControl (0x10) service,用于激活和切换会话。在默认状态下ECU处于Default Session。14229-1中定义了如下几个Other Session。14229-2中有关于会话层的详细描述。

一般用到02 Programming Session和03 Extended Diagnostic Session。02服务用于开启编程,APP主动跳转到Boot,并告知Boot处于SIB(Stay In Boot)状态等待升级。这里会涉及到一个问题,也就是Programmning Session的请求是APP响应还是Boot响应,一般是由BOOT响应,但是各家做法可能不同,APP也可以响应。

03 服务用于开启拓展会话,UDS的其他服务可以根据OEM的需求,定义在不同的Session和Level下。14229-1定义了服务在哪些Session状态执行。

Q:10服务的响应帧数据由哪些组成?

A:每个服务都会有Positive Response 和Negative Response。

DiagnosticSessionControl Response SID:响应ID等于服务ID+0x40

Sub-funtion,也就是切换的会话类型

sessionParameterRecord:

P2server_max 与P2*server_max定义如下:

P2、P2*是由OEM定义的APP在会话的最大保持时间,一般P2为50MS,P2*为5000MS。

当超过定义的时间DCM就会自动切换到Default Session。

11服务

ECUReset (0x11) service,诊断仪请求ECU重启服务。11服务支持一下几种复位类型。

不同子服务,对应不同的复位方式。

11服务的Postitive Response 与Negative Response 如下:

27服务

SecurityAccess (0x27) service,提供安全访问数据或者服务的方法。Client首先请求Seed,在Server返回Seed之后,Client根据Seed计算出Key,并将Key发送给Server。Server接收到Key之后校验,校验成功则进入安全状态。

28服务

CommunicationControl (0x28) service,用于控制通信的发送与接收,诊断帧不受影响。服务请求数据格式如下:

Sub-Funtion 定义如下:

Communication Type定义如下:

3E服务

TesterPresent (0x3E) service,用于保持诊断仪与ECU的连接,同时将之前的服务和状态保持。TesterPresent (0x3E) service,用于保持诊断仪与ECU的连接,同时将之前的服务和状态保持,,不会因为超过P2*的时间限制重新切换到Default Session。

服务请求数据如下:

Postitive Responese 和 Negatice Response 数据如下:

NRC

NRC,否定响应码,当Server返回NRC码时,可以根据不同的NRC码,分析出对应的原因,不同的服务支持不同的NRC,NRC码汇总请参考14229-1的附录A。不同的NRC码,对应不同的故障条件,但是每个故障条件的检测都是存在先后顺序。

下图是不带子服务的响应顺序。

当收到服务请求,DCM会检测当前是否处于BUSY状态(比如上次的多帧数据还没发送完成),如果是就会返回0x21(Busy Repeat Request)。

检查完成后,在检查请求的SID是否支持,如果不支持则返回0x11(Service Not Supported)。

查询SID是否在当前会话中支持,如果不支持则返回0x7F(Service Not Support In Active Session)。

查询SID是否在当前安全等级(Level)中支持,如果不支持则返回0x33(Security Access Denied)。

有些服务可能会自定义一些检查条件,比如在执行10 02跳转Boot之前一般都会执行车速检查,如果大于设定值则返回指定的NRC。

下图是带子服务的响应流程。

响应抑制位

suppressPosRspMsgIndicationBit,肯定响应抑制位。是SubFunction的BIT,表示当请求服务的子服务参数的BIT7置1,表示这个请求不必返回积极响应的报文。比如,当请求 10 81 时,ECU会切换到Default Session 但是不会返回积极响应的报文 50 81。

OBD服务

说到OBD总会要问OBD与UDS的关联。OBD是在15031-5中定义的排放相关的服务,UDS是14229-1中定义的通用服务。两者都依赖15765-2中定义的网络层和14229-2中定义的会话层,因此在一个ECU中是可以共存OBD与UDS的,两者各司其职。

OBD一共有9个服务,服务编号01 到09。

01服务,Request Current Powertrain diagnostic data, 诊断仪可以通过01服务请求排放相关的数据,包括模拟输入输出,数字输入输出,系统状态信息。请求的信息以PID的形式给出,PID的定义在15031-5的附录B中描述。

所有支持OBD的ECU必须支持01服务和PID 00中包含了通用的”Initialization / keep alive/Ping ”等系统状态。

01服务最多可以请求6个PID信号,请求数据格式如图20所示。

响应的数据格式如下:

4.DEM模块

DEM(Diagnostic Event Mannger)模块,用于处理诊断事件的信息和相关的数据,DCM模块通过服务请求可以获得这些数据。DEM模块主要是处理的DTC相关的数据,DTC在15765-6中有详细定义。DTC一共分为四类,如下图所示。

1.DTC

DTC由两个字节或者三个字节组成,每个DTC对应一个或者多个Event。比如ECU检测到某个Sensor断线了,就可以通过DEM接口函数:Dem_SetEventStatus 改变DTC的状态。达到某个条件之后这个DTC关联的数据就可以以快照的方式存储起来,同时车身亮故障灯,维修人员就可以根据DTC码判断出是何处发生了故障。UDS可以通过19服务获取DTC是Status。

DTC的Status是一个Byte的数据,每个BIT代表不同的状态。

BIT0 : testFailed。表示发生了TestFailed

置位与恢复逻辑如下:

BIT1:testFailedThisOperationCycle。表示当前Cycle发生了TestFailed

置位与恢复逻辑如下:

BIT2:pendingDTC。表示当前发生了testFailed

置位与恢复逻辑如下:

BIT3: confirmedDTC,表示已经检测到多次testfailed,并且能确认故障发生,需要去存储相关的数据。

置位与恢复逻辑如下:

BIT4:testNotCompletedSinceLastClear, 表示自执行14服务起,还没有完成完成测试,也就是没有testPass或者testFailed。

置位与恢复逻辑如下:

BIT5:testFailedSinceLastClear,表示自执行14服务起,发生了testFailed事件。

置位与恢复逻辑如下:

BIT 6: testNotCompletedThisOperationCycle,表示当前OperationCycle还未完成测试。

置位与恢复逻辑如下:

BIT7: warningIndicationRequested,表示特定的DTC需要置告警,车身故障灯亮起。

置位与恢复逻辑如下:

2.DTC置位的Debounce

DEM提供接口函数Dem_SetEventStatus设置DTC的Status,接口描述如下:

EventStatus表示需要置成的状态,由如下几种选择:

为了防止出现故障误报的现象,14229-1中规定了Debounce功能,只有当TripCounter达到一定数值时,才能确认故障发生,也就是BIT3置位。

上图可以看出,TripCounter在默认状态下是为0,计数范围是-128 ~127。

在连续测试中一直处于testPassed状态,直到TripCounter达到-128,BIT4由1置位0,BIT6由1置位0。如果侦测到testFiled,那么TripCounter就直接从大于0开始计数,并且testFailed的计数比TestPassed快。当TripCounter计数到127时,BIT2与BIT3置位。

3.老化AgingCounter &Agecounter

AgingCounter也就是处于老化中DTC的计数。当一个OpreationCycle没有检测到testFailed,AgingCounter就会自加1,同时DTC Status的BIT就会清0。当AgingCounter计数达到一定的阈值后,此故障已经完成了老化,可以自愈。同时DTC Status的BIT3清0。

AgedCounter,表示完成老化的DTC的数量。

14229-1附录D提供了关于AgingCounter的演示。

4.快照

快照SnapShot是一群DID数据的集合,每个DTC在Confirm时可以生成快照,将当时的一些关键数据存储在NVM中。诊断仪可以通过19服务读取SnapShot的具体数据。

 
   
2560 次浏览       15
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
简述Matplotlib
Python三维绘图--Matplotlib
Python数据清洗实践
PyTorch实战指南
Python爬虫与数据可视化
最新课程
Python应用开发最佳实践
Python+数据分析+tensorflow
Python 编程方法和应用开发
人工智能+Python+大数据
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
某领先数字地图提供商 Python数据分析与机器学习
北京 Python及数据分析
某金融公司 Python编程方法与实践培训
更多...