14229协议学习

1.什么是ISO-14229和ISO-15765

        简单的说，ISO-14229就是一个用于汽车行业诊断通信的需求规范，ISO-14229只规定了与诊断相关的服务需求,并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO-15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO-14229也称为UDS（Unified Diagnostic Services）

2.诊断通信分层结构

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

OSI Layer	Enhanced Diagnostic Services
Application （layer 7）	ISO 14229
Presentation （layer 6）	-
Session （layer 5）	ISO 15765-3
Application （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.诊断通信的机制

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

• Request 基本格式 ：SID + 一个字节Subfunction + 具体的数据

  
  归纳起来，诊断的request格式无非以下2种：
  < SID> + < Sub-function> + < Parameter>
  < SID > + < Parameter>
  即有无sub-function的区别。其中，我把DID也归为Parameter

• Response 基本格式 ：SID + 40 + Subfunction + 具体的数据

  
  归纳起来，诊断的格式无非以下3种：
  肯定响应
  < SID> + < 40> + < Sub-function> + < Parameter>
  < SID > + < 40> + < Parameter>
  即有无sub-function的区别。其中，我把DID也归为Parameter
  否定响应
  < 7F> + < 请求报文里的SID> + < 一个字节的NRC>
  Tester发送的请求报文格式错误，或者请求发送的条件处于错误，ECU将发送否定响应，否定响应的格式是“7F+SID+NRC”，常用到的NRC在这里罗列了。
  11表示服务不支持；
  12 subfunction不支持；
  13 请求的长度不正确，或者格式不正确.
  31 是请求超出范围；
  7E 是在当前会话下subfunction不支持.
  7F 是在当前会话下服务不支持
  78 如果ECU当前正在处理别的任务，处理别的事情，而不能在P2Sever的时间内给出相应的响应，那么它先在P2Sever时间内给出一个NRC为78的Pending报文，告诉Tester“ECU正在忙”

服务实例

故障存储相关的0x19和0x14服务

• 什么是故障呢？当系统检测到了一个错误或者是一个故障发生的时候，会将相对应的数值故障码进行存储，那么这个对应的数值故障码，我们称之为故障码，就是DTC。一个DTC可以反应出一个故障发生的具体位置，和这个故障发生原因和类型，我们通过读取的DTC信息，可以为维修提供一些依据。除此以外还有与法律有关的故障，比如说排放有关的，在未来还会有安全相关的故障。通过这个故障可以反应出在ECU具体的哪一个位置，和产生的故障类型，在很多国际标准里面都定义了DTC的格式。比如说UDS里定义DTC由3个字节组成，而ISO 15031-6里定义了DTC格式由“两个字节根基+一个字节的故障类型”组成。那么我们常用的UDS服务里面DTC格式用的是哪一种呢？有95%用到的DTC格式都是ISO 15031-6里定义的DTC的故障类型和格式
  ISO 15031-6定义的DTC格式什么样的呢？两个字节的根字节来定义DTC，左边前两位能反应DTC到底是哪一个系统：00表示Powertrain;01表示底盘；
  10表示车身；11是网络相关的。左边第3~4位反应的是，DTC到底是由ISO，SAE，这些标准组织所定义的故障，还是由整车厂来定义命名的故障；
  左边第5~8反应的是车辆系统的区域；
  右边8位，这个字节具体的编码，就是DTC的编码。

我们来看具体的请求和响应格式，首先看19 02。19 02后面跟一个字节的Status Mask，第0位和第3位被置1，而这一个字节Mask，是在ECU诊断规范定义的，所以 59 02 +一个字节的Mask+具体的DTC+DTC后面的跟的DTC Status。
如果有多个DTC，后面会重复DTC的格式：3个字节的DTC+DTC Status。
通过19 0A读取ECU支持的所有DTC，请求格式是两个字节“19 + 0A”；肯定响应格式“59 + 0A+一个字节的Mask+后面跟ECU支持的所有DTC”