车载诊断协议栈简介

目录

前言

一、什么是诊断？

二、什么是诊断协议栈？

1.诊断协议

1.1 OBD II 

1.2 UDS 

1.3  J1939

2.诊断服务

3.故障码

4.诊断事件

5.DID

6.快照

三、诊断开发工具链

四、Autosar诊断模块

1.DCM(Diagnostoc Communication Manager)

2. DEM(Diagnostic Event Manager)

3. FIM(Function Inhibition Manager)

总结

---

---

前言

主要是结合自身对诊断协议栈开发的经历对车载诊断协议栈做一些简单的介绍。

---

一、什么是诊断？

车载诊断和医生看病类似，医生通过望闻问切，获取相应的信息来确定病人的病因，从而采用正确的方法治疗病人，车载诊断则是通过诊断协议获取相应的信息，来定位故障的原因。

二、什么是诊断协议栈？

在我看来，诊断协议栈就是检测单，它主要包含以下组成

1.诊断协议

诊断协议我理解为是一种语言，用于和诊断设备沟通。同一种语言可以用不同的形式来体现比如声音，图片，文字。同一种诊断协议也可以基于不同的通讯载体，比如CAN,LIN和以太网等。常见的诊断协议有UDS,OBD II，J1939

1.1 OBD II 

OBD II 是美国加州为了加强对汽车排放监管提出的一套诊断协议，主要目的就是检测汽车排放相关的指标，然后点亮相应的错误指示灯，经过不断的发展形成了如今几乎全球同音的排放诊断协议OBD II

1.2 UDS 

UDS不同于OBD，是一套通用的诊断协议，适用于整车上的所有ECU，是目前汽车领域使用最广泛的车载诊断协议，支持CAN,LIN,K-LINE,Flexray以太网等所有车载通讯协议的诊断。

1.3  J1939

J1939是美国工程师协会（SAE）提出，专用于卡车，农用车等重型车辆的通讯和诊断，不适用于乘用车，但是目前国内的电动车快充协议采用的J1939。

2.诊断服务

诊断服务可以理解为看病时医生的一些指令，比如看口腔医生会要求张嘴“啊”，诊断服务就是要求被诊断设备做出相应的动作来定位故障。

车载的诊断服务主要基于ISO14229,采用问答模式实现，下面以0x14服务（ECU复位）为例简单介绍：

诊断设备发出复位请求，ECU执行复位操作，给予正响应，其中01表示硬件复位，正响应的格式为SID + 0x40。

CAN1   735    Tx    【02】 11 01

CAN1   635    Rx    【02】 51 01

诊断服务发出复位请求，ECU无法执行复位操作，给予负响应，负响应应答码为22，在ISO14229中查询到22表示 conditionNotCorrect,查看当前condition条件要求车速<3Km/h，此时不满足。负响应的格式为 7F + SID +NRC(错误码)。

CAN1   735    Tx    【02】 11 01

CAN1   635    Rx    【03】 7F 11 22

3.故障码

故障码（diagnosyic trouble code）可以理解为病症名字，每一个故障码对应一种故障。

在我的诊断协议里,DTC C06488表示CAN 总线BUS_OFF故障，在诊断协议栈开发工具CANdelaStudio里C06488分为两个部分，DTC:U0064;Failure Type: 0x88。

C064 写成U0064是因为按照定义，root DTC的高2位按值表示不同的含义，具体见下表：

Value	Description
00(bit)	PowerTrian(P)
01(bit)	Classis(C)
10(bit)	Boody(B)
11(bit)	Network(U)

故障类型0x88 则表示bus off

每个DTC还对应有1个字节的状态位，具体见下表：

Bit	Description
0	TestFailed
1	TestFailedThisOperationCycle
2	PendingDTC
3	ConfirmedDTC
4	TestNotCompletedSinceLastClear
5	TestFailedSinceLastClear
6	TestNotCompletedThisOperationCycle
7	WarningIndicatorRequested

19服务读取DTC相应信息时都会附带对应DTC的状态位，根据状态位可以获知当前DTC的一些基本的状态信息。同时状态位也是DTC存储的触发源。

4.诊断事件

诊断事件（event）可以理解为医院检测单上的检测项，每一项都有合格和不合格的标准。

每个诊断事件都对应一个monitor,用于周期性判断所诊断的故障是否产生。以DTC C06488为例，在我的诊断协议栈中，这个DTC表示CAN总线BUS_OFF故障，monitor会周期性的检测CAN总线是否进入BUS-OFF状态，如果进入则会将这个故障码连同快照一同存储。

5.DID

DID 可以理解为医院的检测项的检测值，比如血压zhi，转氨酶的数量值。对应诊断里DID里存储的是车速，电压，温度等值。

6.快照

快照我的理解就是快速照相，尽可能真实的保存故障发生时候的环境。所以在故障发生的时候我们会把能帮助诊断那一时刻的最新检测值保存下来，便于后续排查故障原因。这样做的原因是有些故障不会一直发生，只在特定情形下发生，采用快照的方式可以帮助我们迅速定位故障原因。

三、诊断开发工具链

采用vector的解决方案，首先根据系统的输入需求在CANdelaSudio里完成DTC,DID,服务等诊断信息的配置，生成的CDD文件导入DaVinci Configurator,生成对应的接口分配给monitor所属的SWC,在DaVinci Developer中将SetEventStatus给到对应检测周期的runnable中， 然后在DaVinci Configurator配置FIM。生成代码，在对应的接口函数中实现相应功能，然后代码集成采用CANoe.Diva测试。

四、Autosar诊断模块

Autosar诊断模块主要分为DEM,DCM和FIM三个部分。

1.DCM(Diagnostoc Communication Manager)

DCM主要分为三个部分：

1）Diagnostic Session Layer(DSL)：处理诊断请求及相应；诊断状态管理，会话状态和安全访问状态，提供接口获取当前的状态信息。

2）Diagnostic Service Dispatcher(DSD)：检测请求是否有效；汇总响应数据，如果是负响应自动给SID+0x40。

3）Diagnostic Service Processing(DSP):根据请求服务，调用不同的接口实现服务；检测请求格式以及响应子服务是否支持。

2. DEM(Diagnostic Event Manager)

DEM主要负责DTC的故障判断以及数据的存储和老化，由于涉及的内容较多，后续会单独讲。

3. FIM(Function Inhibition Manager)

FIM就是当故障发生后对系统的某些功能采用降级处理或者功能抑制，此模块很简单在工具里只需要设置FID的mask和将FID与DTC对应起来即可。

---

总结

本文主要是对诊断协议栈做一个粗略的介绍，便于不了解车载诊断的人对于诊断有一个笼统的印象。