AUTOSAR_DCM&DEM(UDS&OBD)

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的连接，同时将之前的服务和状态保持。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可以通过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的具体数据。