K课堂 | 深入理解RP1210通讯诊断标准(详解)

自1980年代起，Kvaser就开始CAN产品的研发，对CAN和相关总线技术有着非常深入的研究。您可以在Kvaser官网找到多种CAN总线培训资料，点击文末“查看原文”即可直达Kvaser培训中心。

CAN总线多用于工控和汽车领域，是国际上应用最广泛的现场总线之一。CAN标准定义的是硬件（物理层 – 有几种）和通信的基本层面（数据链路层），CAN协议本身仅规定如何通过共享通信介质把小数据包从A点传送到B点。为了管理系统中的通信，我们就必须有一个高层协议（HLP），HLP通常规定了：启动行为、如何在系统内不同的节点中分发报文标识、如何编译数据帧的内容、系统内的状态报告等。

K课堂在这里整理了最常见的几种高层协议以及主要HLP之间的差异，将该内容系统性地梳理给到大家，希望能对CAN总线技术的学习者有所帮助。欢迎关注❤️Kvaser微信公众号❤️！

内容框架如下：

第一部分 高层协议

• J1939: 和
  

第二部分 其他协议和相关标准

• RP1210A，RP1210B（本篇内容）

第三部分 其他相关

• 比较SDS、DeviceNet和CAN Kingdom

• CAN Open和CAN Kingdom的区别

*未标注发布时间的内容将在以后陆续更新。

RP1210标准

标准概要

RP1210是由技术和维护委员会（TMC）编写的一种建议性实践。RP1210用于对重型车辆射频相关的（主要针对）电子控制单元（ECU）进行二次编程和分析。RP1210的目标是为车辆ECU和使用微软Windows操作系统的电脑之间的通信创建标准化的API。该标准使得第三方公司可以开发和销售连接到车载通信总线（即CAN）的PC与ECU之间所需的硬件接口。

图1表示的是连接原理。RP1210 API包含用于通信的标准函数和例程（例如connect、write和read）。硬件设备必须使用标准函数并能够独立于与其连接的数据通信协议与ECU进行通信。RP1210A硬件设备应当包含下列协议：J1708/J1587、CAN、J1939和J1850。最新版本的RP1210B还可以选择支持J1850。

△ 图1: RP1210设置

标准背景

随着汽车电子变得越来越复杂，对分析和重新编程不符合原理的ECU的工具的需求变得越来越重要。因为每家汽车厂商都有其自己的特殊命令用于编程，所以除了OEM厂商之外，几乎没有任何人能够开发这种工具。因为市场上没有竞争，所以这些工具非常昂贵。因为每家汽车厂商都有其自己的工具，所以想要分析和维修几种品牌车辆的汽车维修店必须每个品牌都提供一个开发工具。

RP1210概念使得为所有品牌使用相同的硬件工具变得可能。OEM仍然供应用于对ECU进行编程的电脑应用程序，但是电脑应用程序和硬件工具之间的标准API使得任何厂商都有可能创建硬件工具。

不同版本的区别

RP1210的版本主要是根据主机厂、车载通信软件开发公司以及VDAs制造商的要求对旧版进行了增强与添加。RP1210B相对于先前的版本RP1210A，主要升级的内容有：

◉ 可选协议J1850

◉ 不再强制支持Windows 3.1

◉ 可以改变CAN比特率 – 在RP1210A中，比特率固定为250kbps

◉ RP1210B可向后兼容RP1210A

常规要求

RP1210 API可用于不同版本的Microsoft Windows，也没有特定要求必须支持所有版本的Windows操作系统。RP1210A可能支持Windows 3.1、95、98、ME、XP或更新的版本。RP1210B取消了对Windows 3.1的支持。

遵循RP1210的任何硬件设备应当能够与支持相同的操作系统的任何遵循RP1210的软件应用程序协同工作。这表示硬件和软件都必须遵循RP1210 API。

电脑和硬件工具之间的连接和通信取决于所选的硬件设备厂商，可以通过RS-232、USB或者甚至蓝牙实现通信。需要注意的是，硬件工具的厂商还提供处理底层通信的驱动程序（DLL）。在PC上运行的编程软件应用程序与数据如何通过硬件工具发送到ECU，这两者之间没有关系。

虽然硬件工具和车辆之间的连接取决于不同品牌，但还是有一些标准连接器：

◉ 对于J1939，使用9针Deutsch HD10-9（图A）。

◉ J1708使用6针Deutsch HD10-6（图B）或9针Deutsch HD10-9（图A）。

◉ 对于“普通的”CAN（ISO 11898）和J1850，最常用的汽车接口是图C中所示的J1962（OBDII）。

图A

图B

图C

<<<左右滑动查看图片>>>

通常，硬件开发工具厂商会为其开发工具支持的所有协议提供线缆和连接器。

使用RP1210 DLL的应用程序应该让用户选择使用哪种硬件工具。有时候应用程序会自动搜索连接到电脑的工具。当选择或发现硬件工具后，必须加载用于这个硬件的特定DLL。

来自汽车数据总线的报文被缓存在硬件工具中。这会占用硬件工具中的内存空间。这还需要每个报文都有关联的时间戳，这样软件应用程序才能区分报文的先后顺序。时间戳应当是4字节长，采用Motorola格式（最高有效字节在前）。

软件应用程序必须能够初始化和重置硬件工具参数和引脚。可使用API函数实现此举。

API必须包含用于报文过滤的函数。过滤应当由硬件工具进行。这样，无需一直向电脑发送任何不必要的报文。

另外，必须能够从软件应用程序控制硬件工具的初始化（例如，波特率设置和用于编程的引脚数）。

RP1210 (API)

RP1210 API包含大量标准化的函数用于控制电脑软件应用程序和连接到汽车总线上ECU的硬件之间的通信。要想把电脑连接到汽车总线，需要一些类型的硬件（包括CAN收发器）。J1587/1708需要不同的硬件收发器。

硬件工具提供物理手段来发送和接收不同总线类型上的报文，但是必须为每种协议使用正确的参数对它进行初始化。为了从电脑控制硬件功能，我们需要一个API。必须同时在电脑应用程序和硬件工具的微处理器中实现这个API。换句话说，硬件工具必须理解从电脑应用程序发送过来的命令并返回请求的信息，或者在一些情况中仅仅确认收到命令。RP1210文档中描述了几种标准命令。请参见表1。

△ 表1：API 函数说明

通过发送某些ECU特定的报文来完成ECU重新编程。这些报文使用RP1210_SendMessage命令以和任何其它报文相同的方式发送。

命令RP1210_SendCommand包括几个功能，例如：

◉ 重置硬件设备

◉ 设置和重置过滤器

◉ 初始化广播报文

◉ 回传报文

RP1210中的过滤函数是包含式过滤，这表示应用程序必须明确指定哪些MID、PGN或CAN-ID可以通过。RP1210B的新特性包含一个排除式过滤函数。这种过滤器允许应用程序让所有报文通过（除了MID、PGN或CAN-ID选择成不通过的报文）。硬件中不能过滤J1708 PID，必须在软件应用程序中完成。

报文回传表示应用程序通过硬件工具把报文发送到汽车总线上，然后报文被返回到硬件工具的接收报文缓存中。然后，当应用程序读取接收报文缓存时，传输的报文被返回到应用程序。报文回传默认情况下被关闭。

RP1210 API DLL

每家硬件工具厂商都提供名称唯一的DLL文件。这样，电脑上的软件应用程序可以选择连接到哪个硬件工具。API DLL包含与电脑应用程序中一致的函数。

RP1210文档中没有指定电脑和硬件工具之间的数据通信。这使得硬件工具厂商能够选择通信协议（例如RS-232、USB或者可能是一些无线协议）。每种协议都有其自己与电脑进行通信的API。RP1210 API DLL必须提供RP1210 API函数和协议特定API之间的链接来发送和接收报文。这显然必须由硬件工具的厂商完成。这使得任何电脑应用程序都可以使用标准的API函数，而无需考虑硬件工具和电脑之间使用哪种协议。