Introduction to SAE J1587
Background
The protocol is an SAE standard put forward by a subcommittee to Truck and Bus Electrical and Electronics Committee. The purpose of the protocol is to promote consistency between software in different electronic control units. The J1587 protocol should be used together with the SAE J1708 protocol that describes the hardware and the basics of communication. Together with J1708 it is supposed to lower the cost and complexity for developing and maintenance of microcontroller devices in heavy duty vehicles (trucks and busses).
Areas of use
The J1587 protocol is exclusively used within heavy duty vehicles, where it is used for data exchange between nodes in a network, driver information or diagnosis. Areas of use are:
- Vehicle and component information (performance, maintenance, diagnosis).
- Navigation and time schedule (route description and time estimation).
- Driver information (trip recorder data, driver log).
- Freight information (information about pick up place and delivery destination).
Quick facts
The J1587 protocol defines the format of J1708 messages sent between microprocessors devices in heavy duty vehicles. It also supports communication with external devices connected to the bus.
- J1587 is an application layer and is used together with J1708, which is the physical layer.
- J1587 describes a message format and defines parameters.
- A J1587 message consists of MID, PID, data bytes and a checksum.
- The length of a J1587 message is limited to 21 bytes according to J1708.
- J1587 allows for sending messages longer than 21 bytes using a connection oriented transport service (COTS).
The Protocol In Detail
The Anatomy of a J1587 Message
The construction of a J1587 message follows the J1708 specification which means that the length of a message is limited to 21 bytes.
- The first byte of a message contains a message identification (MID) which is node specific. J1587 defines MIDs in the interval 128-255.
- The first byte after the MID is a parameter identification (PID). A PID is (usually) one byte long and can contain values 0-255.
- Every PID is followed by a number of parameter data bytes. Their number and interpretation depend on the value of the PID. Note that a message can contain several PIDs.
- The message is completed with a one byte long checksum, which consists of the two’s complement to the sum of all data bytes in the message. The sum modulo 256 of all bytes in a message, including the checksum, is zero if the message is valid.
Here’s an example of a message.
| MID | PID | Data | PID | Data1 | Data2 | Checksum |
|---|---|---|---|---|---|---|
| 128 | 21 | 50 | 12 | 05 | 48 | 248 |
A J1587 message containing two PIDs, 21 and 12.
PIDs 0-127 (and 256-383) describe data parameters that are one byte long. PIDs 128-191 (and 384-447) describe data parameters that consist of two bytes. Data parameters that demand more than two bytes are assigned PIDs 192-253 (or 448-509). The first byte following these PIDs will contain the number of data parameter bytes.
PIDs 194-196 are used for diagnosis. For this purpose many electrical components in the vehicle have been assigned subsystem identification (SID). For every MID there can be up to 255 different SIDs defined. Through these SIDs parts which can not be related to a certain PID can be identified. SIDs should only be assigned to field-replaceable parts or parts than can be related to a MID. Most SIDs are predefined by SAE or the Data Format Subcommittee. SIDs 151-155 are “system diagnostic codes” and can be used to read out diagnostic information which is not component specific. The diagnostic information consists of a failure mode identifier (FMI).
PIDs 225-227 are used for dash board text display which can be accessed by several ECUs. There are three commands for this purpose: text message display type (PID 227), text message to display (PID 226), text message acknowledged (PID 225).
PID 254 is used for transmission of special commands, data and information intended for a certain node on the bus. Data parameters sent after this PID can be determined by the manufacturer of a device.
PID 255 is used for extension of a PID to two bytes, that is to say that the following byte also is a PID. With this extra PID values up to 511 can be used. If the first PID is 255 the following PID is interpreted as modulo 256 (0=256, 1=257).
Definition of Parameters
Normally data is sent with the least significant byte first. Alphanumerical data are sent with most significant byte first and is interpreted according to the ISO Latin 1 (8859-1) standard. Signed integers are sent as two’s complement. All temperatures are in degree Fahrenheit. Floating point numbers adhere to the IEEE floating-point standards.
Priority
Priority and transmission rate for a message is determined by the manufacturer of a device. J1587 has recommendations for how to set priority and transmission rate to avoid bus overload. If several parameters are sent in a single message the priority will be based on the parameter with highest priority. Messages with diagnostic requests should be given low priority to avoid disturbing the ordinary bus traffic.
How Do I Interpret a J1587 Message?
You look in the J1587 standard, which is readily available from SAE’s web shop. Table 1 defines the MIDs. For example, 128 is the engine (Engine #1, to be precise) and 130 is the transmission. Table 2 is a list of all PIDs – for example, 21 is the engine ECU temperature. The definition of the data for each PID is found in appendix 1 of the standard. Here is an example:
A.21 Engine ECU Temperature — Internal air temperature of the engine ECU.
| Parameter Data Length: | 1 Character |
|---|---|
| Data Type: |
Signed Short Integer |
| Bit Resolution: |
2.5 °F |
| Maximum Range: |
–320.0 to 317.5 °F |
| Transmission Update Period: |
1.0 s |
| Message Priority: |
8 |
|
Format: |
|
| PID |
Data |
| 21 |
a |
| a— |
Engine ECU temperature |
In this case, we can see that the temperature is coded as one byte (that follows immediately after the PID byte, 21). It’s a signed value and scaled so each bit corresponds to 2.5 °F.
Construction of Segmented Messages
The need for an external communication link to read out information from a “closed system” has increased. Therefore J1587 provides this service. The method used is called Connection Oriented Transport Service (COTS) and provides an way to send more than 21 bytes long messages that is used for internal communication.
This transport protocol can handle messages up to 3825 bytes. The message is segmented into blocks consisting of 15 bytes each. The length of the last segment may be less than 15. Every segment is given a header with a segment number and then sent in a J1708 message with a MID and a special PID. The receiver of the segmented message removes the header and checksum and reconstructs the original message from the remaining 15 data bytes. When the whole message is transferred it can be sent to an external device through a gateway or internally to a display for example.
The service for transmitting segmented messages uses two special PIDs. Connection management PID (197) controls the start and end of a connection, flow control and receipt of a message. Connection mode data transfer PID (198) is used exclusively for data transfer.
CMP (Connection Management PID)
This PID (197 ) administrates the segmented data transfer. The first byte following this PID contains the number (n) of bytes to come. The second byte contains the MID of the receiver. The third byte contains the connection management control command (CMCC) and thereafter follows data bytes depending on the command.
| PID | n | MID | CMCC | Data(1) | Data(2) | Data(3) | Data(…) |
The Connection Management PID
The CMCC byte can contain the following commands:
- Request to send (RTS), is sent from a node who wishes to transfer data.
- Clear to send (CTS), is sent as a response from the receiver of a RTS.
- End of message acknowledgement (ACK), is sent from the receiver when all segments of the message have been received.
- Request for standardized data, is used when data of a standard format is requested. For example, drivers log or trip recorder.
- Abort, can be sent from transmitter or receiver to abort communication.
CDP (Connection Mode Data Transfer PID)
This PID (198) is used for transmission of segmented message. The first byte after this PID contains the number (n) of bytes to come. The second byte contains the MID of the receiver. The third byte contains the segment id (1-255) and thereafter follows 15 data bytes. The last segment may contain less than 15 data bytes.
| PID | n | MID | SEG | Id | Data(1) | Data(2) | Data(…) | Data(15) |
The Connection Mode Data Transfer PID
Transmission of Segmented Messages
To transfer segmented messages between two nodes a request of a virtual connection has to be sent from transmitter to receiver. This is done with the RTS command which contains the number of segments and the total number of bytes to be transmitted. The receiver has to accept the request by sending a CTS command which contains the number of segments it can receive and which segment to send first. When this handshaking has been successfully performed data can be transmitted with the connection mode data transfer PID. When all data have been transmitted the virtual connection is closed with an EOM command. See the following figure.
Segmented data communication. (Picture borrowed from the J1587 specification.)