Summary

The RP1210 is a recommended practice written by the Technology and Maintenance Council (TMC). RP1210 is used for reprogramming and analyzing of emission related (mainly) Electronic Control Units (ECUs) in heavy duty vehicles. The purpose of RP1210 was to create a standardized API for communication between vehicle ECUs and a PC using a flavor of Microsoft Windows as operating system. This standard makes it possible for third party companies to develop and sell the hardware interface needed between the PC and the ECU which is connected to a onboard communication bus (i.e. CAN).

Figure 1 shows the connection principles. RP1210 API includes standard functions and routines for communication (i.e. connect, write and read). The hardware device must conform to the standard functions and be able to communicate with the ECU independent of the data communication protocol that it is connected to. A RP1210A hardware device should include the following protocols; J1708/J1587, CAN, J1939 and J1850. The latest version RP1210B makes support for J1850 optional.

Figure 1. RP1210 setup.

Background

As vehicle electronics become more and more complex, the need for a tool for analyzing and re-programming ECUs which doesn’t work as supposed becomes more important. This tool was almost impossible for anyone except the OEM to build, since every vehicle manufacturer had their own special commands for programming. Because there was no competition on this market these tools became expensive. Since every vehicle manufacturer had their own tool, the repair workshop that wanted to analyze and repair several brands had to have one tool for each brand. The RP1210 concept made it possible to use the same hardware tool for all brands. The PC application for programming vehicle ECUs are still supplied by the OEM but the standard API between the PC application and hardware tool makes it possible for any manufacturer to build a hardware tool.

RP1210 Versions

The latest version of this recommended practice is the RP1210B which was released in September 2006. The main upgrades in RP1210B from the earlier version RP1210A are:

Except for these changes RP1210B should be backward compatible with RP1210A.

General Requirements

The RP1210 API is created for various flavors of Microsoft Windows. There is no specific demand that all versions of Windows operating systems have to be supported. RP1210A might support all or some of Windows 3.1, 95, 98, ME, XP, or later. RP1210B does not have to support the 16-bit Windows 3.1.

Any hardware device that is RP1210 compliant should be able to work together with any RP1210 compliant software application that supports the same operating system. This means that both hardware and software has to conform to the RP1210 API.

The connection and communication between the PC and the hardware tool is up to the manufacturer of the hardware device to chose. The communication could be accomplished by i.e. RS-232, USB or even Bluetooth. The important thing is that the manufacturer of the hardware tool also provides a driver (DLL) which handles the low level communication. The programming software application which runs on a PC doesn’t care about how data is physically sent (thru a hardware tool) to the ECU.

The connection between hardware tool and vehicle depends on the brand. However there are some standard connectors.

• For J1939 a 9-pin Deutsch HD10-9 (figure A) is used.
• J1708 uses either a 6-pin Deutsch HD10-6 (figure B) or a 9-pin Deutsch HD10-9 (figure A).
• For “ordinary” CAN (ISO 11898) and J1850 the most common vehicle interface is the J1962 (OBDII) shown in figure C.

Usually the manufacturer of a hardware tool provides cables and connectors for all protocols supported by their tool.

Figure A

Figure B

Figure C

The application that uses the RP1210 DLL should give the user the possibility to choose which hardware tool to use. Sometimes the application automatically searches for a tool connected to the PC. When a hardware tool has been chosen (or found) the specific DLL for this hardware has to be loaded.

Messages from the vehicle data bus are buffered in the hardware tool. This requires memory space in the hardware tool. This also requires time stamps associated with every single message so that the software application can distinguish which message that was sent first. The timestamp should be 4 bytes long and be in Motorola format (most significant byte first).

The software application must be able to initialize and reset the hardware tool parameters and pins. There are API functions for this purpose.

The API must include functions for message filtering. The filtering should be done by the hardware tool. This way no unnecessary messages have to be sent all the way thru to the PC.

Initialization of the hardware tool, i.e. setting of baud rate and pins for programming must be controllable from the software application.

RP1210 (API)

The RP1210 API consists of a number of standardized functions for controlling the communication between the PC software application and the hardware connected to ECUs on the vehicle bus. To be able to connect the PC to the vehicle bus some kind of hardware is required which includes a CAN transceiver. J1587/1708 requires a different hardware transceiver.

The hardware tool provides the physical means to transmit and receive messages on different bus types, but it has to be initialized with the right parameters for each protocol. To control the hardware functions from the PC an API is required. The API must be implemented in both PC application and in the microprocessor on the hardware tool; in other words, the hardware tool must understand the commands sent from the PC application and return the requested information, or in some cases just a receipt of the command. There are several standard commands described in the RP1210 document; see table 1.

Function Name	Brief Description
RP1210_ClientConnect	Establishes a logical client connection with the API DLL.
RP1210_ClientDisconnect	Disconnects the logical client application from the API DLL.
RP1210_SendCommand	Sends a command to the API DLL for things like filtering, etc.
RP1210_SendMessage	Sends a message to the API DLL.
RP1210_ReadMessage	Reads a message from the API DLL.
RP1210_ReadVersion	Reads version information from the API, about the API.
RP1210_ReadDetailedVersion	Newer more comprehensive version information command. This command is now preferred over the RP1210_ReadVersion call.
RP1210_GetErrorMsg	Translates an RP1210 error code into a textual description of the error.
RP1210_GetHardwareStatus	Returns information state of the connection and data link.

Table 1: Description of API functions

The reprogramming of an ECU is done by sending certain ECU specific messages. These messages are sent like any other message with the RP1210_SendMessage command.

The command RP1210_SendCommand includes several functions, e.g.

• Resetting of the hardware device.
• Setting and resetting of filters.
• Initialization of broadcast messages.
• Echoing of messages.

The filter function in RP1210 is inclusive, which means that the application must designate exactly which MID, PGN or CAN-ID that should pass. A new feature in RP1210B is an exclusive filter function. This filter allows the application to let all messages pass except the messages including MID, PGN or CAN-ID selected not to pass. J1708 PIDs can not be filtered in the hardware; this must be done in the software application.

Echoing of messages means that messages sent by the application through the hardware tool and onto the vehicle bus, are returned to the receive message buffer in the hardware tool. The transmitted messages are then returned to the application when it reads the received message buffer. Initially the echoing of messages is turned off.

RP1210 API DLL

Each manufacturer of a hardware tool has a DLL file with a unique name. In this way it is possible for the software application on the PC to select which hardware tool to connect to.

The API DLL includes functions that are compliant to the functions in the PC application.

The data communication between PC and hardware tool is not specified in the RP1210 document. This gives the manufacturer of the hardware tool the possibility of choosing the communication protocol i.e. RS-232, USB, or maybe some wireless protocol. Each protocol has it own API for communicating with the PC. The RP1210 API DLL has to provide a link between the RP1210 API functions and protocol specific API for sending and receiving messages. This obviously has to be done by the manufacturer of hardware tool. This makes it possible for any PC application to use the standard API functions without considering which protocol that is being used between the hardware tool and the PC.