车辆控制单元诊断系统
随着汽车普及程度越来越高，汽车服务市场不断扩大，汽车维修公司对汽车故障快速定位的需求也越来越大。对于车主而言，迅速地了解爱车的车况及故障信息有助于及时对车进行检修和维护。目前诊断系统的通讯协议多种多样，包括主要的标准的诊断通信协议KWP2000、UDS、OBD，及CAN物理层标准SAE J1939等等。其中，欧洲汽车领域广泛使用的一种车载诊断协议标准是KWP2000，有基于K线的诊断协议，也有基于CAN的，统一诊断服务UDS在设计之初就是基于CAN线，目前UDS是各个厂家应用的趋势。SAE J1939,OBD的一些协议由美国人主导，J1939既可以通讯，也有关于诊断的相关协议,车辆车载诊断系统OBD主要面向汽车排放而制定。
KWP2000
KWP 2000（Keyword Protocol 2000关键字协议2000）协议实现了一套完整的车载诊断服务，并且满足E-OBD（European On Board Diagnose）标准（简称OBD）。KWP2000最初是基于K线的诊断协议，由于K线物理层和数据链路层在网络管理和通讯速率上的局限性，使得K线无法满足日趋复杂的车载诊断网络的需求。而CAN网络（Controller Area Network）由于其非破坏性的网络仲裁机制、较高的通讯速率（可达1Mbps）和灵活可靠的通讯方式，越来越多的汽车制造商把CAN总线应用于汽车控制、诊断和通讯。近年来欧洲汽车领域广泛采用了基于CAN总线的KWP2000，即ISO 15765协议，而基于K线的KWP2000物理层和数据链路层协议将逐步被淘汰。
这里首先浅谈一下基于K线的KWP2000协议，其主要包括ISO/WD 14230-1~14230-4。ISO 14230由三部分组成，定义的物理层在ISO 9141-2的基础上把数据交换系统扩展到了24V电压系统。这意味着凡是满足ISO 9141-2的车辆、模块或测试设备，只需对软件进行修改，即能满足KWP 2000接口需求；其数据链路层主要关注如何定义报文，建立通信等，包括信息格式和时序，兼容ISO 9141-2，同时提供额外选项，包括报文结构、初始化过程、通讯连接管理、定时参数和错误处理等内容。K线的报文结构见表1；其应用层主要关心具体通信，兼容了ISO 14229中描述的诊断维修实施方法。同时对数据的排放在ISO 15031中进行了定义。总的来讲，KWP2000可理解为ISO 14230协议的简版。
表1 基于K线的KWP2000报文结构
| 报文头 |
数据域 |
校验和 |
||||
| 格式字节 |
目标地址字节（可选） |
源地址字节（可选） |
长度字节（可选） |
服务标识符 |
...数据... |
校验和 |
| 最长4 字节 |
最长255 字节 |
1字节 |
||||
基于CAN总线的KWP2000协议，实际指的就是ISO/WD 15765-1～15765-4。ISO 15765（道路车辆——控制局域网络诊断）协议把KWP2000应用层的诊断服务移植到CAN总线上。ISO 15765规定了在ISO 11898指定的链路上实现车辆诊断系统的通用要求。ISO 15765协议也是按照ISO/OSI 7层参考模型建立的，数据链路层采用ISO 11898-1协议，该协议进一步标准化和规范化CAN2.0B协议；应用层采用ISO 15765-3协议，该协议完全兼容基于K线的应用层协议14230-3，并加入CAN总线诊断功能组；网络层采用ISO 15765-2协议，规定了网络层协议数据单元（N_PDU，见表2）与底层CAN数据帧、上层KWP2000服务之间的映射关系，并且为长报文的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。目前ISO 15765协议已广泛用于轿车、汽车控制工业等方面。
表2 网络层协议数据单元（N_PDU）格式
| 地址信息 |
协议控制信息 |
数据域 |
| N_AI |
N_PCI |
N_Data |
- 地址信息：标识对等网络实体间的通信。包括源地址（N_SA）、目标地址（N_TA）、网络目标地址格式（N_TAType）和可选择地址扩展（N_AE）。
- 协议控制信息：用于交互在网络层对等实体通信的其他控制参数。包含四种帧格式（见表3）。
- 数据域：KWP2000服务标识符（Service ID），服务参数。
四个网络层服务项：N_USData.Request、N_USData_FF.indication、N_USData.Indication和N_USData.Confirm，分别用于发送数据的请求服务项、通知上层被拆分数据首帧接收的指示服务项、提供接收数据至上层的指示服务项及为上层提供.Request服务完成情况的确认服务项。这些数据结构包含了诊断类型，地址信息、服务请求ID和服务请求参数等内容。
表3 15765协议网络层四种PDU对应的PCI格式
|
N_PDU 名称 |
N_PCI |
|||
| 字节1 |
字节2 |
字节3 |
||
| 7-4位 |
3-0位 |
|||
| 单帧（SF） |
N_PCItype=0 |
SF_DL |
N/A |
N/A |
| 首帧（FF） |
N_PCItype=1 |
FF_DL |
N/A |
|
| 连续帧（CF） |
N_PCItype=2 |
SN |
N/A |
N/A |
| 流控制帧（FC） |
N_PCItype=3 |
FS |
BS |
STmin |
- 单帧：对于未拆分的信息，将信息长度值仅放置在PCI字节里。单帧应当能支持在单个CAN帧中的信息传输。
- 首帧：只支持一条信息无法在单个CAN帧中发送时使用，如拆分的信息。拆分信息的第一帧编码为FF，当接收到FF时，接收网络层实体应重组这些信息。
- 连续帧：当发送拆分数据时，所有的连续帧跟着FF编码为连续帧。在接收到一个连续帧，接收网络层实体应重组接收到的数据字节直到信息被接收完整。接收实体在收到最后一帧信息并无接收错误后，应传递这些信息至相邻上层。
- 流控制帧：用于调整CF N_PDUs发送速率。流控协议数据单元的三种类型用于支持这些功能，这些类型由协议控制信息的流状态（FS）域指示（见表4）。
表4 流状态参数（FS）定义
| 16进制值 |
说明 |
| 0 |
继续发送（CTS），即接收者准备好接收最大BS个连续帧。 |
| 1 |
等待（WT），促使发送方继续等待流控帧（N_PDU）的到来，并重新设置N_BS定时器。 |
| 2 |
溢出（OVFLW），促使发送方中止拆分信息的发送并且做传递参数 |
| 3-F |
协议保留 |
BS,STmin等这里只简单提及，未做详细解释，欲了解详情参考ISO 15765-2网络层标准。表5为各部分协议与OSI模型的对应关系。
表5 KWP2000协议与OSI模型的对应关系
| OSI模型 |
基于K线的KWP2000 |
基于CAN总线的KWP2000 |
| 应用层 |
ISO 14230-3 |
ISO 15765-3 |
| 表示层 |
N/A |
N/A |
| 会话层 |
N/A |
N/A |
| 传输层 |
N/A |
N/A |
| 网络层 |
N/A |
ISO 15765-2 |
| 数据链路层 |
ISO 14230-2 |
ISO 11898-1 |
| 物理层 |
ISO 14230-1，ISO 9141-2 |
用户设定 |
OBD
OBD（On Board Diagnostics车载自动诊断系统）是汽车排放和驱动性相关故障的标准化诊断规范，对所有车辆统一适用，有严格的排放针对性，其实质即通过监测汽车的动力和排放控制系统来监控汽车的排放。OBD系统将从发动机的运行状况随时监控汽车是否尾气超标，一旦超标，会马上发出警示。当系统出现故障时，故障(MIL)灯或检查发动机(Check Engine)警告灯亮，同时动力总成控制模块(PCM)将故障信息存入存储器，通过一定的程序可以将故障码从PCM中读出。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。
在OBDⅡ计划实施之后，任一技师可以使用同一个诊断仪器诊断任何根据标准生产的汽车。所有执行OBDII标准的汽车都需要具备标准化的车辆数据诊断接口(SAE J1962，也就是现在常说的OBD接口)、标准化的诊断解码工具(SAE J1978)、标准化的诊断协议(ISO 9141-2\ISO 14230-4\ISO 15765-4)、标准化的故障码定义(SAE J2012\ISO 15031-6)、标准化的维修服务指南(SAE J2000)。OBDⅡ程序使得汽车故障诊断简单而统一，使用标准的16针诊断接口，维修人员无需专门学习每一个厂家的新系统，当故障车辆来到4S店后，技师可用专用的诊断工具读取汽车存在的故障码，故障发生时的时间、里程、故障发生次数等重要参数，从而提高维修效率。而OBD系统更重要的另一方面，也是其设计初衷，就是为了控制排放。
图1 诊断座针脚定义（图片取自百度百科）
通过OBD接口与汽车电控系统ECU通讯获取汽车各项数据，OBDⅡ支持多种汽车协议。这里简单介绍ISO 15031-5及ISO 15031-6标准。
ISO 15031-5（道路车辆—车辆和外部测试设备之间与排放相关诊断通讯要求）基于SAE J1979，ISO 15031-5中描述的关于OBD输出信息的9种模式/服务：Mode1请求动力系当前数据，Mode2请求冻结帧数据，Mode3请求排放相关的动力系诊断故障码，Mode4清除/复位排放相关的诊断信息，Mode5请求氧传感器检测测试结果，Mode6请求非连续检测系统OBD测试结果，Mode7请求连续检测系统OBD测试结果，Mode8请求车载系统、测试或者部件，Mode9读取车辆和标定识别号。每个模式后面紧跟着一个参数标识（PID）表示后面是什么参数及请求。ISO 15031-5是应用层协议（见表7），编程时只要关心数据消息包的7字节数据部分。
表6 ISO 15765-4 诊断信息格式
| CAN标识符（11或29位） |
PCI |
7字节数据 |
表7 ISO 15031-5定义
| 字节 |
说明 |
| 1 |
MODE，表示请求数据的类型 |
| 2 |
PID，参数标识 |
| 3-7 |
根据不同MODE及PID，ISO 15031-5有详细定义 |
接下来举几个实例以方便大家更好地掌握。
实例1：获取车辆冷却液温度。
请求数据01 05，即MODE 01，PID 05指令。
接收应答41 05 6A
第一个字节41，代表MODE 01应答（01+40，标准定义）；
第二个字节代表PID 05，与请求PID对应；
第三个字节6A，根据ISO 15031-5中MODE 01，PID 05定义，-40℃的偏移值解析出冷却液温度值为0x6A-40=106-40=66℃。
实例2：获取与排放相关的诊断故障码。
步骤1，请求数据01 01，即MODE 01，PID 01指令。首先获取与排放相关的故障码数量。
步骤2，若存在故障，请求数据03，即MODE 03指令。（注：若出现报文的故障码数量与基于服务$01，PID $01的应答故障码个数不同，则外部测试设备重复步骤1,2）
步骤1接收应答 41 01 81 07 65 04
第一个字节41，代表MODE 01应答（01+40，标准定义）；
第二个字节代表PID 01，与请求PID对应；
其他字节81 07 65 04，根据ISO 15031-5中MODE 01，PID 01中定义，第三个字节的最高位代表是否点亮故障指示灯，低7位代表故障码数量。解析出故障灯状态0x81>>7=1，故障灯点亮；故障码个数0x81&0x7F=0x01，即1个故障码。
步骤2接收应答 43 01 02 3F 00 00 00 00（若故障码数量多于3个，会返回多行消息包）
第一个字节43，代表MODE 03应答（03+40，标准定义）；
第二个字节01，DTC个数。
第三，四个字节02 3F，OBD的故障码，使用标准ISO 15031-6，由5个字符组成（解析见表8）；其他未使用字节用00填充。
表8 ISO 15031-6故障码解析
| $0 |
$2 |
$3 |
$F |
||||||||||||
| 0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
1 |
1 |
| P |
0 |
2 |
3 |
F |
|||||||||||
| 00：动力总成系统P 01：底盘悬挂系统C 10：车身系统B 11：网络通讯系统U
|
P开头的故障码： 0-通用故障码 1-制造商自定义故障码 2-通用故障码 3-P3000-P3399：制造商自定义 P3400-P3FFFF：通用故障码 |
P0/P1开头的故障码： 0-燃油，空气及排放控制 1-燃油，空气计量 2-燃油与空气计量（喷油器电路） 3-点火系统 4-排放控制 5-车速及怠速控制 6-计算机或辅助输出电路 7,8,9-变速箱 A,B,C-混合动力系统 |
具体故障。 此处表示燃油泵二级电路/开路 |
||||||||||||
UDS
UDS（Unified Diagnostic Services统一诊断服务）是诊断服务的规范化标准，比如读取故障码应该向ECU发什么指令，读数据流又是发什么指令。UDS与OBD最大的区别就在于“Unified”上，OBD是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范，只是应用层的规范。UDS面向整车所有ECU(电控单元)，而OBD面向排放系统ECU。单就UDS而言，它只是一个应用层协议(ISO 14229-1)，所以它既可以在CAN线上实现，也能在Ethernet上实现(DoIP, Diagnostic over Internet protocol)。并且UDS提供的是一个诊断服务的基本框架，这些诊断服务允许诊断仪在车载电子控制单元里控制诊断功能，以便维修人员准确解决故障。主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于UDS协议的诊断又常被称为Enhanced diagnosic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。
ISO 14229标准是为了给诊断系统定义通用的需求而发布的，而这与串行数据链路的种类无关。为了完成这一工作，该标准基于OSI基准模式，这与 ISO7498-1、ISO/IEC 10731保持一致，在这两个标准中，它把通讯系统的结构分为七层。当映射到这种模式时，可通过诊断仪和ECU将服务分解为单独的诊断服务（第七层）和通信服务（第一到第六层）两种。
表9 CAN UDS和OBD协议与OSI模型的对应关系
| 适用性 |
OSI模型 |
统一诊断服务UDS |
通用车载诊断OBD |
|
基于ISO/IEC 7498和ISO/IEC 10731 |
应用层 |
ISO 14229-1/ISO 15765-3/ISO 11992-4 |
ISO 15031-5/SAE J1979 |
| 表示层 |
用户设定 |
ISO 15031-5/SAE J1979 |
|
| 会话层 |
ISO 15765-3/ISO 11992-4 |
ISO 15765-4 |
|
| 传输层 |
ISO 15765-2/ISO 11992-4 |
N/A |
|
| 网络层 |
ISO 15765-2/ISO 11992-4 |
ISO 15765-4/ISO 15031-4 |
|
| 数据链路层 |
ISO 11898-1/ISO 11992-1/SAE J1939-15 |
ISO 15765-4/ISO 15031-4 |
|
| 物理层 |
ISO 11898-2/ISO 11992-1/SAE J1939-15 |
ISO 15765-4/ISO 15031-4 |
SAE J1939
SAE J1939协议是美国汽车工程师协会为了实现总线协议的标准化，在CAN2.0B的基础上制定的应用于大型货车和客车的车辆网络串行通信和控制协议。该协议按照OSI 7层参考模型建立，在物理层和数据链路层基本上沿用了CAN规范，并增加了网络层、应用层和网络管理规范，网络通信速率可达250Kbps。
表10 SAE J1939协议与OSI模型的对应关系
| OSI模型 |
SAE J1939协议 |
| 应用层 |
J1939-71/诊断协议J1939-73 |
| 表示层 |
N/A |
| 会话层 |
N/A |
| 传输层 |
N/A |
| 网络层 |
J1939-31/网络管理J1939-81 |
| 数据链路层 |
J1939-21 |
| 物理层 |
J1939-11/J1939-15/非车载诊断连接器J1939-13 |
SAE J1939是一种支持闭环控制的在多个ECU之间高速通信的网络协议，以CAN2.0为网络核心。J1939必须使用扩展格式。表11介绍了CAN2.0的标准和扩展格式及J1939协议的定义格式。表12给出了J1939 的一个协议报文单元的具体格式。
表11 CAN2.0的标准和扩展格式及J1939协议定义格式
| CAN扩展帧格式 |
SOF |
11位标识符 |
SRR |
IDE |
18位扩展标识符 |
|||||
| J1939 |
帧起始位 |
优先权3位 |
R保留位 |
数据页DP |
PF格式6位 |
SRR位 |
扩展标识 |
RF |
PS格式8位 |
源地址8位 |
| CAN |
1 |
2-4 |
5 |
6 |
7-12 |
13 |
14 |
15 16 |
17-24 |
25-32 |
| 帧位置 |
|
28-26 |
25 |
24 |
38-18 |
|
|
17 16 |
15-8 |
7-0 |
表12 J1939协议报文单元的具体格式
| 优先权 |
R保留位 |
数据页DP |
PDU格式PF |
PDU特定PS |
源地址SA |
数据场 |
| 3 |
1 |
1 |
8 |
8 |
8 |
0-64 |
例如：0x18FECA00=11000,11111110,11001010,00000000
P PF PS SA
消息优先级0-7。所有控制消息的缺省优先级是3。其他所有信息、专用、请求和ACK消息的缺省优先级是6。PF决定PS是目的单元地址还是组扩展。
表13 PF与PS
| PDU格式（PF） |
PDU特定（PS） |
| 0-239（00-EF） |
目的单元地址DA |
| 240-255（F0-FF） |
参数组扩展GE |
J1939通信的核心是负责数据传输的传输协议。其功能分为两部分:
- 连接管理：用于建立和关闭连接，以及控制数据流。传输协议提供了以下5种传输协议连接管理消息：连接模式下的请求，准备发送，消息结束应答，放弃连接，以及广播公告消息（报文见表17）。
- 数据的拆分打包和重组：一个J1939的报文单元只有8个字节的数据场。因此若发送的数据>8字节，须拆分成若干个小的数据包后逐一发送。由于组成长信息的单个数据包必须能被识别以便正确重组，因此把数据域的首字节定义为数据包的序列编号。每个数据包都会被分配一个从1-255的序列编号。由此，最大的数据长度是1785（255包×7字节/包）个字节。传送的每个数据包都装载着原始数据中的7个字节（除了传送队列中的最后一个数据包，其包含数据包的序列编号和参数组至少一个字节的数据，余下未使用的字节全部设置为FF16）。接收方必须能接收到这些单个数据帧后解析各个数据包重组成原始信息。
传输速度：单包1s为周期更新速度。当不止一个激活的 DTC 存在，这个参数组将使用“多包传输”，响应者必须知道这些数据包都具有相同的标识符。多包广播信息的数据包发送间隔时间为50-200ms。
J1939故障代码种类(此处仅列举三个)：激活状态的诊断故障代码DM1；先前激活状态的诊断故障代码DM2；先前已激活状态的DTC的诊断数据清除/复位DM3。接下来重点介绍DM1。
DTC（Diagnostic Trouble Code诊断故障代码），一种用以识别故障类型、相关故障模式以及发生次数的4字节数值。DM1指令包含的诊断信息仅限于当前正处于激活状态的可改变指示灯状态的故障码。该数据包括了所有相关发送的DTC。若电子传输部件中没有激活的DTC，则来自该部件的指示灯状态为关闭态。01灯亮，00灯灭。
表14 DTC构成
| 可疑参数编号SPN |
19位 |
| 故障模式标志FMI |
5位 |
| 发生次数OC |
7位（当发生次数未知时，应将其所有位的数值设为1） |
| 可疑参数编号的转化方式CM |
1位 |
实例1：诊断故障代码以诊断信息的方式传送（例 DM1）
已知：油压预滤器参数SPN=1208，FMI=3，OC=10。所有的诊断故障代码域以英特尔格式传送（最小有效字节优先）
PDU 格式：254=0xFE
PDU 指定：202=0xCA
默认优先值：6
参数组数编号： 65226（ 0x00FECA）
字节1：8-7、6-5、4-3、2-1位分别表示故障指示灯、红色停止灯、琥珀色警告灯及保护灯状态。
字节2：8-7、6-5、4-3、2-1位分别预留以用来表示SAE任务灯状态。
表15 以 CAN 的数据结构作为 DM1 的 DTC 表示法
| DTC |
|||||||||||||||||||||||||||||||||||
| 字节3 SPN的低8位有效位（最高有效位为第8位） |
字节4 SPN的第2个字节（最高有效位为第8位） |
字节5 SPN高3位有效位与FMI有效位（第8位为SPN的最高有效位及第5位为FMI的最高有效位） |
字节6
|
||||||||||||||||||||||||||||||||
| SPN |
FMI |
CM |
OC |
||||||||||||||||||||||||||||||||
| 8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
| 1 |
0 |
1 |
1 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
||||
实例2：以下信息格式适用于制订一个DM1请求且不存在激活状态故障。
字节1=00
字节2=255
字节6～3 SPN=FMI=OC=CM=0
字节7，8=255
接下来具体介绍协议数据解析。
表16 单包/多包格式
| PGN（ID） |
说明 |
| 65226（FECA） |
故障码单包传输PGN，用于传输单包故障码，如果只有一个故障码则用这个ID进行传输。 |
| 60416（ECFF） |
连接管理消息，可用于多包广播公告（多包声明）。 |
| 60160（EBFF） |
专用于多包传输PGN，有数据需要由多包传输都用这个PGN进行，故障码多于一个的话，也用这个PGN。 |
表17 广播公告报文（TP.CM_BAM）——全局目标地址
| 字节 |
说明 |
| 1 |
控制字节=32，广播公告报文（BAM） |
| 2,3 |
整个报文大小的字节数 |
| 4 |
全部数据包的数 |
| 5 |
保留给CATARC设定使用，该字节应设为0xFF |
| 6-8 |
打包报文的参数组编号（=65226，则可知接下来要传输的多包消息为故障码，第8字节为最高有效字节） |
实例3：以下所列举的信息格式适用于多个诊断故障代码的情况。
已知：a为灯状态字节(两个字节)，b为故障代码(四个字节)
将每一帧的有效数据重组后的数据格式如下：a b b b b b......
参考资料
百度百科词条“obdⅡ”“OBD系统”“UDS协议” [引用日期2018-04-27]
《ISO 14230》《ISO 15765》《SAE J1979》《SAE J1939》标准 [引用日期2018-04-22]