![cover](https://img-blog.csdnimg.cn/20200211155815975.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI1OTIwMDkx,size_16,color_FFFFFF,t_70)
AUTOSAR——DCM&DEM (UDS&OBD)
1.术语与缩写术语DCMDiagnostic Communication ManngerDEMDiagnostic Event ManngerUDSUnified diagnostic servicesOBDOn-Board DiagnosisDSDDiagnostic Service DispatcherDSL
1.术语与缩写
DCM | Diagnostic Communication Manager |
DEM | Diagnostic Event Manager |
UDS | Unified diagnostic services |
OBD | On-Board Diagnosis |
DSD | Diagnostic Service Dispatcher |
DSL | Diagnostic Session Layer |
DSP | Diagnostic Service Processing |
SID | Server Identifier |
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的连接,同时将之前的服务和状态保持。不会因为超过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,因为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可以通过0x19服务获取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的具体数据。
![Logo](https://devpress.csdnimg.cn/79de2bf0b7994defa4242ef90d5513fa.jpg)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)