ISO 14229系列（一）简介

前言

首先感谢autogeek的分享，原文链接：http://www.cnblogs.com/autogeek/p/4458591.html

由于工作中经常用到ISO-14229，因此决定对该协议做个总体介绍和总结，既是对自己学习的总结，也能够给初次涉及该协议的朋友一个参考。

首先简要介绍什么是ISO-14229，至于可以在网上找到的大篇理论介绍我就略过不讲了，有兴趣可以自行搜索。简单的说，它就是一个用于汽车行业诊断通信的需求规范，它只规定了与诊断相关的服务需求，并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO-15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO-14229也称为UDS（Unified Diagnostic Services）统一诊断服务。

 

1. 用途

ISO-14229的用途就是规定了诊断需求，因此想要了解ISO-14229的用途首先要知道诊断的用途。诊断最先用于汽车尾气排放的监测，后来发展为包括对汽车行驶故障的监测，想知道诊断的发展史，可以维基百科。至少现代的诊断可以粗略的分为排放相关和非排放相关，ISO-14229只定义非排放相关的诊断需求。非排放相关诊断可以做什么呢？其实用途很大，基本贯穿整个汽车ECU生命周期。首先，ECU开发时要用到它来构建bootloader，上传和下载数据；测试时要用它来读写RAM、ROM，控制外设；在产线上，要用它来校准机械件，刷新软件；在行驶过程中，要用它来监测各种故障，并记下故障码；在4S店，技师需要用它来读出故障码，判断故障发生点，还可以用来升级ECU程序。现在很火热的车联网概念，其中一些就是通过OBD口联网，读取车内故障码，车辆信息，或者油量、速度等等车相关的参数。

 

2. 诊断通信分层结构

虽然借鉴OSI的七层结构，但是诊断通信分层还是做了一些改变。可以参考如下列表：

OSI Layer	Enhanced Diagnostic Services
Application （layer 7）	ISO 14229
Presentation （layer 6）	-
Session （layer 5）	ISO 15765-3
Transport （layer 4）	ISO 15765-2
Network （layer 3）	ISO 15765-2
Data link （layer 2）	ISO 11898
Physical （layer 1）	ISO 11898

 

显然，从上表可以看出诊断通信分层模型和OSI的区别，同时也可以看到ISO-14229在该模型中的位置。其实，可以将该模型简化为：
- 统一诊断服务层 （layer 7）

- 网络服务层 （layers 1 to 6）

因此，在使用ISO-14229时，下面的通信机制可以改变，比如基于CAN，基于蓝牙，基于LAN，基于FlexRay等等。

 

3. 相关术语

3.1 协议相关术语

要了解协议，首先要知晓协议内定义的术语。我挑了一些使用频率比较高的在此解释。

1. Diagnostic Service （诊断服务）

诊断服务是介于诊断设备和被诊断ECU之间的一种信息交互方式。通常是由诊断设备发出请求，被诊断ECU做出回应。

2. Diagnostic Trouble Code （故障码）

故障码是用来标记ECU故障的代码，它遵循一定的规则（以后会介绍），驻留在ECU的非易失性存储器中。

3. Diagnostic Data （诊断数据）

诊断数据是可以被诊断设备请求的ECU内部数据，它包括：

-当前数据，即ECU正在使用的某个数据，比如车速、节气门角度等

-存储数据，即被ECU存储在存储器中某一时刻的数据，比如DTC

-静态数据，即恒定不变的ECU内部数据，比如VIN码。

4. Diagnostic Session （诊断会话）

可以理解为某种诊断模式或权限，即在不同的模式下，对不同的诊断服务的使用做了限制。

5． Diagnostic Routine （诊断例程）

驻留在被诊断ECU中的子程序，它可以被诊断设备启动和停止。比如格式化EEPROM的子程序。

6. Tester， 就理解为诊断设备或诊断仪吧。

3.2 诊断服务相关术语

再来说一些跟诊断服务相关的术语。

1 Addressing Type （寻址方式）

寻址方式指的是诊断消息的传递方式，有两种寻址方式：

-Physical ，物理寻址，即1对1通信，用于知道确切的被诊断ECU的地址

-Functional，功能寻址，即1对n通信，或者说广播发送，用于不知道确切的被诊断的ECU的地址，向一组或者全体ECU发送请求

2 Result

Result指的是tester请求诊断服务执行后，从ECU的返回结果。可以有两种结果：

-Positive Response，正响应，即诊断请求执行成功

-Negative Response，负响应，即诊断请求执行失败

3 Service Identifier

Service Identifier可以简称为SID，它是一个一字节的无符号整数，用以指代某个诊断服务。诊断协议为每一个诊断服务都分配了唯一一个SID，因此更方便协议的软件实现。同时，在日常工作中工程师们用SID来指代某个诊断服务比说出某个服务的名字更方便简洁。比如ReadDataByIdentifier这个服务是去按照ID去读某个诊断数据，直接说22服务会更加方便。

4 Data Identifier

简称DID，是2个字节无符号整数的ID，用来标识ECU中贮存的某个诊断数据单元。它的好处是当要读取某个单元的诊断数据时，只要读对应的DID就可以，不必知道数据的具体地址。即使当ECU中的数据地址发生变化时，只要DID和某个地址单元的映射地址改变即可，对于使用者来说DID屏蔽了具体实现细节，而将重点放在了数据本身。

5 Negative Response Code

可以简称为NRC，或者叫错误响应码，是一个字节的无符号整数。它是诊断协议为每一种执行失败的诊断服务分配的失败原因代号。

6 Sub-function

有些诊断服务可以支持不同的诊断子服务，sub-function就是用来定义这种子服务的，它将某一个服务细分为更为具体的服务，它是一个字节的无符号整数。比如ECUReset这个服务就有0x01，0x02，0x03等几种sub-function指代具体的reset方式。

---

1. 简单的通信机制

感谢autogeek的分享，原文链接：http://www.cnblogs.com/autogeek/p/4458658.html

其实诊断通信的机制很简单，可以类比client-server通信方式，即客户端发送request，服务器收到request之后进行处理，然后向客户端发送response。但是，诊断协议有自己的特色，它规定了在request和response的格式，在收到request的时候要做格式的检查。同时由于寻址方式的不同，有无sub-function的支持等，也会影响request和response的处理方式和结果。下面将我就具体情况分析，尽量做到简介明了。

 

2. Request

2.1 基本格式

归纳起来，诊断的request格式无非以下2种：

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

即有无sub-function的区别。其中，我把DID也归为Parameter

2.2 有sub-function

在介绍有sub-function情况的request之前，首先要了解一下sub-function的定义方法。下图是从ISO14229中截来的，它是对sub-function的定义。

值得注意的是Bit 7，从字面上来看它用来指示是否要抑制Positive Response。的确，它的目的就是这个意思，当Bit 7为1（1 = ‘true’）时，对该request的Positive Response要被抑制，即不发送Positive Response；当Bit7为0（0 = ‘false’）时，对该request的Positive Response不被抑制，正常发送。除了Bit 7，Sub-function有不同的值，具体的值和含义在协议中对每个服务的解释时都会有介绍。

2.3 不带sub-function

根据2.2的说明，不带sub-function的服务，就带parameter。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数目也是视具体要求而定。一般在协议内都会有表格，当遇到具体问题时，可查表确定。

 

3. Response

一般来讲，response会在一个服务被request且执行之后发送，成功的话就发positive response，失败的话要发negative response，但是也有例外的时候，比如ECUreset，他要求先发送response，然后再去执行具体的reset，因为如果先reset，那么ECU的通信模块shut down，是无法发送出去response的。一般像这种特殊情况，协议会在描述具体服务时标注出来。

3.1 Positive Response

基本格式：

<SID+0x40> + <Sub-function> + <Parameter>

<SID+0x40> + <Parameter>

其中要注意第一个字节是由SID和0x40的和构成，至于为什么要这样做，只能说协议就是这么规定的，只要是Positive的response，其第一个字节就是要由相应SID的值再加上0x40构成。这里的Parameter项是optional的，具体要看协议规定。

比如session control的service：

Send：10 01（byte1的10是SID，byte2的01是sub-function，且可知Bit 7是false）

Receive：50 01 （byte1是SID+0x40，byte2是sub-funtion）

再举个不带sub-function的例子，比如ReadDataById这个service：

Send：22 F1 86（byte1是SID，byte2和byte3是DID，可视为parameter的一种）

Receive：62 F1 86 01（byte1的62是SID+0x40，byte2和byte3是DID，byte4是读到的数据）

不论是物理寻址还是功能寻址，对于Positive Response来说都没有影响，只需要关注sub-function中的Bit 7 suppressPosRspMsgIndicationBit是0还是1，如果为0即false，那么正常发送即可，如果是1即true，那么就不发送response。如果根本没有subfunction呢，那么什么都不要考虑，肯定是要发送positive response的。

3.2 Negative Response

基本格式:

<0x7F> + <SID> + <NRC>

看起来比较简单，格式比较固定，只要是Negative Response，第一字节就一定是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因，这个NRC可以在协议中查到，并且不同的服务所支持的NRC也有规定。

还是拿session control 这个service来举例：

Send：10 05（现在sun-function变为05了，假定系统不支持这个sub-function）

Receive：7F 10 12（7F即指代错误响应，10为SID，12是NRC，查协议可知其指代sub-function not supported 这个错误）

格式讲完了，来看看在物理寻址和功能寻址情况下，Negative Response分别有什么区别。

首先在物理寻址情况下，只要是Negative Response就应该按照规定格式发送。而在功能寻址情况下，有一点特殊，对于NRC为0x11（service not supported）、0x12（subfunction not supported）、0x31（request out of range）这三种情况，功能寻址是不会发送response的。

 

4. Request的检查策略

下面用一张流程图来展示收到request之后ECU如何检查他的合法性，并确定是正响应还是负响应，发送还是不发送。这里只是展示最基本的步骤，还有具体的和每个服务相关的条件判断，需要结合具体需求来讨论。