1.术语与缩写
| DCM |
Diagnostic Communication Mannger |
|
DEM |
Diagnostic Event Mannger |
| 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的具体数据。