1.前言

本文利用CAN总线源码，进行车速数据的逆向破解。

本文亦在通过OBD技术获取汽车实时车速，OBD技术涉及的内容繁多，如何在如此繁多的内容中提炼出一个行之有效的方法去实现我们的目的是本文的创作目的。所以如果你对OBD不是很熟悉，或者在网络上繁杂的信息里很难提炼出关键的解决手段，通过本文或许会给你一些启发和思路。

2. 知识预备

2.1 什么是OBD?

在了解这个领域之前，首先需要解决什么是OBD？它是用来做什么的？

OBD全称也叫On-Board Diagnostic[ɒn bɔːd ˌdaɪəɡˈnɒstɪk] 翻译成中文叫“车载诊断”，是汽车上的一种用于监控车辆状况以及控制排放的一种在线诊断系统。因此如果你的小汽车出现了故障开去4S店进行维修，维修师傅都会进行OBD来了解你的小汽车的基本情况。

同时也要注意诊断分为两种：在线诊断和离线诊断
比如汽车仪表对油温、水温、车速等数据的实时监测，车载仪表盘的相关显示就属于在线诊断；离线诊断是外部诊断设备通过车辆的OBD接口与汽车进行通讯，从而获知汽车的相关数据和故障信息。因此我们获取车速是采用离线诊断。

2.2 OBD可以监测车辆什么数据呢？

用于监控车辆基本参数，例如监控里程、车速、油门踏板位置、冷却液温度等等的一些参数。

2.3 OBD-II的数据接口

硬件上接线：

CAN_H-----接OBD接口第6引脚

CAN_L-----接OBD接口第14引脚

信号地------接OBD接口第5引脚

电源正端---接OBD接口第16引脚

车身公共地------接OBD接口第4引脚

我们通常需要接的主要有5号GND线，6号CAN-H，14号CAN-L，即可完成OBD硬件通信。

2.4 OBD通信诊断协议

什么是诊断协议？

外部设备和车辆通讯的方式和原则我们就称作为诊断协议。诊断协议主要定义了请求和响应的规则，也定义了ECU如何处理响应的机制，还定义了在请求和响应中的报文所承载的物理意义的解析方式。（注：ECU（Electronic Control Unit）电子控制器单元，又称为汽车的“行车电脑”，它们的用途就是控制汽车的行驶状态以及实现其各种功能。主要是利用各种传感器、总线的数据采集与交换，来判断车辆状态以及司机的意图并通过执行器来操控汽车。）

常见的诊断协议：ISO15031、ISO15765、ISO14229等

对于每一层都有一个协议来约束&规定，通过物理的线路和MCU的运算，将电信号转换成表示诊断信息的报文，就是依据这些协议完成的。

现有的国际上比较成熟、实用的应用层可用于诊断的协议有 ISO 14230、SAE J1939 和 ISO 15765 等，它们都是针对特定应用领域所开发的，均有独特的设计思路与组成特点。目前基于 CAN 总线上最常用的汽车诊断协议为 ISO 15765 协议，它更大限度的发挥了 CAN 的优异性能并具有很高的可靠性。我们不需要全部了解，只需要重点关注ISO 15765协议标准即可。

2.5 ISO 15765协议标准

为了解决诊断系统和 CAN 总线融合这一问题，欧洲汽车厂商与 2000 年推出一种以 CAN 作为底层的诊断系统通信诊断标准 ISO15765，在这个诊断系统通信模型中，应用层在参考 ISO14229-1 以及 ISO15031-5 标准的内容后并兼容了大部分汽车厂商规范中所定义的诊断服务定义的诊断服务，这些服务具有测试、检查、监控、诊断管理等功能。

由于 CAN 总线的渐渐成为主流的总线，基于 CAN 总线的诊断系统通信标准 ISO 15765 已被许多汽车厂商采纳，将成为目前汽车行业的通用诊断标准。

ISO 15765 总共分为 4 个部分： ISO 15765-1 物理层及数据链路层说明、 ISO15765-2 网络层的说明、 ISO 15765-3 应用层的说明、 ISO 15765-4 排放相关说明。

2.5.1 物理层

ISO 11898-1 标准是 ISO 15765 协议的物理层和数据链路层所遵循底层的标准。通过使用 CAN_H 和 CAN_L 的差分电压来表示 CAN 总线中的显性和隐性位,可以用数据的 1 和 0 来表示。

2.5.2 数据链路层 ISO 15765-1

根据 ISO 15765-1 中的定义。链路层的功能是把通过网络层传来的诊断报文消息，经过修改打包成能够在 CAN 总线上进行传输的 CAN 帧。ISO 15765 的数据层在 CAN 总线上传输时可以使用标准帧（ 11 位标识符），遵守 CAN2.0 A，11 位标识符定义了 CAN 节点在总线上的唯一的地址。报文的优先级是按照标识符从高位到低位按位进行仲裁 0 的优先级高于 1。即CAN有个特点是竞争机制，帧ID越小越有占用总线资源的权利，越会优先发送。举个例子，灯光信号帧ID 0x555，发动机温度传感器帧ID 0x111，那么当两个信号同时发出时，发动机的信号会优先发送，灯光在后面排队。同样也可以使用扩展帧（ 29 位标识符）遵守 CAN2.0B，其数据帧的格式就是利用 CAN的数据帧进行传输。为什么CAN节点ID不能相同？ - 知乎https://zhuanlan.zhihu.com/p/288795172.5.2.1 11位和29位是什么意思呢？

11位指的是标准帧的帧ID范围是0x000-0x7FF（0x是十六进制的意思），7FF翻译成二进制是111 1111 1111，对吧，十一个“1”。同理，29位指扩展帧的帧ID范围是0x0000 0000-0x1FFF FFFF，1FFF FFFF翻译成二进制是29个1。大致明白了吧。29位的分配ID能力要比11位的强，11位能够表示的信息总量小一点。

2.5.2.2 帧数据

与串口相比，CAN的帧数据只有8个字节，即64个，不会再多了。

2.5.2.3 波特率

，要注意常见的CAN波特率大多都是整数。常见的车辆波特率有500K，250K，125K，100K。波特率和收音机频率一样，如果两个CAN设备的通信波特率不一致的话，是不能进行通讯的。如果你需要设计CAN总线节点，波特率的设置是一个难点，应认真仔细查阅MCU关于CAN控制器部分的datasheet。

2.5.2.4 终端电阻

，CAN和RS485一样，要在终端减少差分信号的反射。我记得最经典的一张图是这么画的，水流在试管（平躺）的尾部受阻，水也就涌了回来。差分信号也是如此，你不在两个终端加电阻，信号会反弹回来影响通讯。终端电阻在CAN总线上要有两个，阻值为120欧姆，并联，最远的两端一边一个。多了不行少了也不行。你不确定的话，用万用表量一下，CANH和CANL之间60欧姆左右最好。如果有多个节点的话，终端电阻应适当加大。

小电阻之大作用——CAN终端电阻 - 知乎CAN总线终端电阻，顾名思义就是加在总线末端的电阻。此电阻虽小，但在CAN总线通信中却有十分重要的作用。终端电阻的作用 CAN总线终端电阻的作用有两个： 1、提高抗干扰能力，确保总线快速进入隐性状态； 2、提高…https://zhuanlan.zhihu.com/p/26096996

2.5.3 网络层 ISO15765-2

根据 ISO 15765-2 中的定义，网络层的功能是接收到应用层发送过来的消息流后，根据定义中的分包、位填充和时间控制等步骤，对消息流进行控制传输。流控制输有单帧传输、多帧传输两种类型，可根据传输数据的长度进行帧传输方式的选择。

2.5.4 应用层 ISO15765-3

在汽车诊断协议中应用层就是有关诊断的应用，完整资料请参见文末下载链接：

ISO15765-4协议的标准帧帧ID有0x7DF、0x7E0、0x7E8、0x7E1、0x7E9等。0x7DF是外部测试设备发送的功能寻址请求消息的can标识符；(can identifier for functionally addressed request messages sent by extermal test equipment)他是一个功能寻址，广播的，也就是说，如果诊断仪Tester发出了7DF，所有的ECU都要进行回复Response。

图：ISO15765-4协议 Page12

0x7E0是物理寻址Request，由诊断仪Tester发出给ECU1号，1对1有针对性的查询；0x7E8是1号ECU发出的回应帧，功能寻址和物理寻址都支持。对一个ECU来说，它包含3个帧ID。一个是功能寻址请求ID，一个是物理寻址请求ID，一个是回复Response ID。

其中：7E0/7E8 for ECM(engine control module)发动机控制模块；7E1/7E0 for TCM(transmission control module)变速器控制模块；

图：部分ISO15765-4协议内容

对于0x7DF和0x7E8它是CAN总线的帧ID，也就是CAN总线的“地址”。这个“xx”是可选字节，根据你不同的需求，在这个位置填入不同的数据。

以车速为例：

图：部分ISO15765-4协议内容

车速的可选字节是“0D”，后面的意思是：Byte3（从左往右数第四个）的数值表示了车速。

也就是说我们接受的8位数据帧的第三位也就是0x7B代表了车速。

3. 协议验证

3.1 准备工作

比较主流的两款USBCAN-II调试设备主要是周立功和广成科技，比较推荐广成科技的调试设备，因为其配套软件ECANTools具有OBD-II调试软件，可以根据指令进行OBD实时分析。

3.1.1 安装周立功USBCAN-II调试软件

具体安装教程如下：

第一步：安装软件驱动；第二部运行软件即可。

这里安装的USBCAN软件是周立功USBCAN。官网软件链接如下：

USB接口CAN卡-广州致远电子有限公司广州致远电子USBCAN系列CAN接口卡是兼容USB2.0全速规范的，带有1~8路CAN接口的高性能CAN接口卡。采用该接口卡，PC机可以通过USB总线连接至CAN网络，进行车辆、煤矿、实验室、工业控制、智能小区等CAN网络领域中的数据采集与数据处理。https://www.zlg.cn/can/down/down/id/22.html如果不知道下载那个，就下载我上传的USB-CAN软件。

周立功USB-CAN-II安装包-嵌入式文档类资源-CSDN下载周立功USB-CAN-II安装包更多下载资源、学习资料请访问CSDN下载频道.https://download.csdn.net/download/Roger_717/83192883第二步：将USBCAN-II设备的USB接口插入电脑，在计算机管理中找到带有黄色感叹号的ZLG USBCAN，右击搜索安装其驱动程序。如果不确定，直接选文件夹加大搜索范围，自动完成驱动安装，然后就可以直接打开软件使用了。

3.1.2 安装广成科技ECANTools软件

这款软件可以让我们更好的对调试协议有一个更为直观的理解。

官网链接如下：

广成科技USBCAN通用光盘下载广成科技usbcan通用光盘下载地址。http://gcgd.net/tecinfo1_1098.html软件安装完毕如下：

该款软件具备一个优点是具备OBD II界面用户可以使用 ECANTools 软件的汽车信号解析功能。使用该设备接入汽车OBD 接口即可将汽车内部部分传感器的实际数值解析出来，信号解析功能仅支
持家用汽油车 ISO15765 协议。车速、转速、水温可通过软件仪表盘显示。目前该功能仅支持 CAN1 通道。用户可通过此界面直观的看到汽车当前实时车速、转速和油量的具体数值，便于用户校对汽车仪表盘数值是否准确。

使用时，请首先点选 11Bit 按钮，勾选“循环获取实时数据”。若此时 USBCAN分析仪连接到汽车动力总线上，则将返回车速、转速、水温等参数。若两种模式皆无反馈，请检查通信波特率及接线。大多数汽车动力总线波特率为 500Kbps。

3.2 广成科技USBCAN-II Pro分析仪

3.2.1 实验方法

首先做的是回环实验，因为目前OBD-II功能仅支持USBCAN-II Pro分析仪的CAN1通道，因此我们要做测试需要进行回环实验，利用CAN2模拟汽车向调试接口CAN1发送数据。因此需要将两个通道短接在一起。之后选择500k波特率，进入ECANTools软件，选择2通道，将0x7E8填入帧ID一栏，将06 41 0D 7B 00 00 00 00依次填入帧数据一栏，之后点击发送。在OBD II界面中我们可以看到仪表盘发生了转动。这说明我们发送了正确的数据。我们看到仪表盘显示的车速是123，怎么来的呢？帧数据的第四个字节0x7B转成16进制就得到了123。

测试完毕后，进行实际测试，将CAN线（1通道）接入到车辆CAN总线上面。如果该车辆满足ISO15765-4协议，那么点击“循环获取实时数据”，软件将自动发送帧ID为0x7DF的请求数据。要注意，第三个字节是在变化的。

从上面的图中我们可以看到，我们发出了对“0D”这个可选字节的请求。相应的车辆将会把“0D”的这个信息回应给我们。理想状态下是发一个数据回应一个数据，但是在真实车辆环境下还是有很多数据回应的。

3.2.2 数据分析

解读一下上面的接收数据帧：

0x7E8表示这数据是1号ECU（也就是发动机控制模块）作出的回应。

03主要是由网络层确定的：可参见标准：UDS网络层/TP层（ISO 15765-2）

3.2.3 ISO 15765-2

网络层最主要的目的就是把数据转换成能适应CAN总线规范的单一数据帧，从而进行传输。如果将要传输的报文长度超过了CAN数据帧的长度，则需要将报文信息进行拆分后传输，每次至多可以传输4095个字节长度的报文。
UDS网络层/TP层（ISO 15765-2）的解读 - 知乎本文是对 ISO 15765-2-2011 协议的一些解读。需要指出该协议的最新版为2016版。 TP层存在意义 UDS网络层，又称为TP层（Transport Protocol Layer）。其存在的目的是为了解决ISO 11898协议中定义的经典CAN数据链路…https://zhuanlan.zhihu.com/p/44857562原版请下载：

下属名词缩写见上图：

3.2.4 网络层协议数据单元（N_PDU，Network_Protocol Data Unit）

网络层协议数据单元 N_PDU 包含N_AI，N_PCI，N_Data。即地址信息，协议控制信息和数据。

网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC），用于建立对等实体间的通信。对于TP层来说，我们可以把报文分为单帧和多帧，单帧只有一种N_PCI，即单帧；多帧有三种N_PCI，即首帧、流控制帧、连续帧。在这里我们只需要分析单帧即可，及SingleFrame(SF)。

3.2.5 协议控制信息（N_PCI，Protocol Control Information）

网络层对于这四种类型的数据单元是通过协议控制信息（N_PCI，Protocol Control Information）进行区分的。每一个N_PDU都只有一个N_PCI。我们完全可以通过识别每条CAN帧数据域的首个字节来确定它属于四种类型中的哪类。

简单来说：网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC）。这四种类型的表示由协议控制信息（N_PCI，Protocol Control Information）来表示。

3.2.5.1 单帧（SF）

一个字节byte由8个bit组成，在CAN帧数据字段（can frame data field），单帧数据类型在byte 1的表示为0x0X(X为数据长度Data Length)，首个字节为0（4bit）+ Data Length(4bit)，控制信息占用1个字节。

例如上面的速度接收帧：DataNum:0x08 03 41 0d 00 aa aa aa aa 中03就表示这个单帧数据只有3个有效字节，后续的字节是自动填充的无效字节。

图：单帧PCI通常仅占用1个字节，其他是数据，所以可以后面可以跟着最多7个字节的数据

其余三种数据类型在这里就不多做赘述了，请参见：UDS网络层/TP层（ISO 15765-2）的解读 - 知乎本文是对 ISO 15765-2-2011 协议的一些解读。需要指出该协议的最新版为2016版。 TP层存在意义 UDS网络层，又称为TP层（Transport Protocol Layer）。其存在的目的是为了解决ISO 11898协议中定义的经典CAN数据链路…https://zhuanlan.zhihu.com/p/44857562

3.2.6 ISO 15031-5

ISO 15031-5主要描述了OBD所用的诊断服务。

OBD总共定义了9个诊断服务，每个服务用一个byte来代表，即所谓的Service。ID(SID)，从0x01到0x09。

3.2.7 Sever $01 Request current powertrain diagnostic data请求当前动力总成诊断数据

从这个定义我们就了解到，通过该模式我们可以去请求车辆上动力系统的一些数据，但是这些数据都是需要预先定义好的，如何进行定义呢，那么ISO标准规定了一些参数标识符即PID（parameter Identifiers），每个PID代表一个变量参数，但是呢在CAN上传输怎么去识别这个参数呢，其实就是顶一个8bit的数据来代表这个参数，比如PID 0x01 表示DTC清除后的监控状态，比如PID 0x05 表示电机冷却液的温度，那么ISO15031-5它定义了很多这样的PID参数，这样定义是很有意义的，因为这可以保证所有厂家的OBD可以尽可能的统一，从而方便通用。命令格式是：

SID + 若干PID（Parameter ID）

每个PID也是一个byte，所以理论上PID取值范围是0x00至0xFF，但是ISO-15031-5只明确定义了部分PID，其余的值都保留。

模式1的作用就是通过预先标准定义好的一些PID参数，去请求动力系统当前的一些数据（如速度、里程、温度等），以此来了解当前车辆的一些状态。

3.2.7.1 模式的使用

ISO其实定义了很多PID参数，但是并不要求所有的主机厂把这些参数都实现，也就是说PID参数是可以选择支持的。那么我们怎么知道这个厂家支持哪一些参数呢？其实模式1中它有一些PID 0x00 0x20 0x40 0x60 0x80等就是用来查询到底支持哪些服务的。通常来说，诊断仪要首先读取00、20、40这些ID，然后就知道ECU支持哪些其他的PID了，而其他的PID就是很直接地表示某种数据，具体如何使用如下：

PID 0x00 用于查询（0x01~0x20）之间支持的PID参数

PID 0x20 用于查询（0x21~0x40）之间支持的PID参数

PID 0x40 用于查询（0x41~0x60）之间支持的PID参数。。。。

还是以我们接收的车速数据信息为例，这里我们要根据ISO 15031-5这个标准来分析请求数据和接收数据。

Request
DataNum:0x08 0x7DF 02 01 0d 00 00 00 00 00 (外部测试设备发送的功能寻址请求消息的CAN标识符；2位有效字节；01请求当前动力总成诊断；PID参数车速)

Response
DataNum:0x08 0x7E8 03 41 0d 00 aa aa aa aa (1号ECU作出回答；3位有效字节；41为动力总成请求响应代码；PID车速代号；00车速)

其中Byte 2中的41是应用层数据（ISO15031-5协议），它是由0x01服务再加上0x40得来的，表示我确认了Tester（诊断仪）发出的01服务。

00代表车速，00代表真实的车速值是0x00，也就是0 km/h。

0x7DF是外部测试设备发送的功能寻址请求消息的can标识符；

回复的数据帧：0x12代表18km/h。

4. 汽车CAN总线介绍

汽车 CAN 总线属于 C 级汽车车用总线网络，C 级网络用于高速、实时性、可靠性要求较高的系统，一般速度在 500kbps 以上。

参考文献：

[1]周涛. ISO 15765协议的研究与实现[D].合肥工业大学,2011.

[2]邹凤. 基于ISO15765协议的汽车诊断系统的设计与实现[D].中国科学院大学(中国科学院工程管理与信息技术学院),2017.

[3]李甫. 面向汽车电子应用的ISO15765网络层协议研究与实现[D].上海交通大学,2016.DOI:10.27307/d.cnki.gsjtu.2016.000441.

[4]心机之花. https://zhuanlan.zhihu.com/p/31233540

[5]关于汽车诊断OBD的理解（ISO15031-5）_AgingMoon的博客-CSDN博客_obd诊断

[6]张丁.

【STM32-CAN】基于STM32的OBD监测车速系统设计相关推荐

STM32毕业设计——基于STM32+JAVA+Android的六足机器人控制系统设计与实现（毕业论文+程序源码）——六足机器人控制系统
基于STM32+JAVA+Android的六足机器人控制系统设计与实现(毕业论文+程序源码) 大家好,今天给大家介绍基于STM32+JAVA+Android的六足机器人控制系统设计与实现,文章末尾附有 ...
STM32毕业设计——基于STM32+MQTT+WiFi技术的智能家居系统设计与实现（毕业论文+程序源码）——智能家居系统
基于STM32+MQTT+WiFi技术的智能家居系统设计与实现(毕业论文+程序源码) 大家好,今天给大家介绍基于STM32+MQTT+WiFi技术的智能家居系统设计与实现,文章末尾附有本毕业设计的论文 ...
STM32项目--基于STM32的办公室安保（智能家居）系统设计
基于嵌入式系统的办公室安保系统设计简介设计一套基于STM32的办公室安防系统,系统内部包括门禁系统.灾害报警系统.人脸识别系统和交互中心四个子系统. 门禁系统:主要实现对门禁卡的存储和读取并识别已 ...
STM32实例——基于STM32开发板实现传感数据采集-DHT11温湿度采集
STM32开发板实现传感数据采集-DHT11温湿度采集一.前言本项目是基于STM32开发板的温湿度采集,传感器采用DHT11温湿度传感器,软件采用keil5等.本项目采用ARM结构中最为代表的Co ...
基于单片机的运动监测控制系统设计
博主福利:100G+电子设计学习资源包! http://mp.weixin.qq.com/mp/homepage?__biz=MzU3OTczMzk5Mg==&hid=7&sn=ad5 ...
stm32 IOT_基于STM32平台的cubeMX和HAL库详解
课程简介: <朱有鹏老师单片机完全学习系列课程>总共5季,其中第1.2季是51单片机学习,第3.4.5季是STM32单片机与RTOS学习.整个课程时长约250小时,是一套零基础.全面系统. ...
【STM32】基于stm32的阿里云智能家居
摘要智能家居是一种通过物联网将家里的各种电器设备连接在一起,并由中心控制器统一管理的信息系统.系统的核心是各类家居信息的采集与处理.阿里云能够提供云端的数据存储和分析功能,可以作为智能家居中心控制 ...
基于STM32的智能手环系统的设计
STM32系列基于STM32的智能手环系统的设计 STM32系列前言一.系统方案的设计 1.1系统功能分析 1.2系统总体结构二.硬件电路的搭建 2.1STM32最小系统组成部分 2.2S硬件 ...
基于 STM32 和 NB-IoT 的可穿戴式老人防摔监测系统
这是我本科毕设搞得一个小任务,现在稍微整理了其中一点内容,下面有相应的程序代码. 程序参考: 采用STM32作为主控,通过串口与ME3616通信,控制ME3616对接OneNET,将采集到的温度数据上 ...

【STM32-CAN】基于STM32的OBD监测车速系统设计