SAE J2534 (Part I): An Introduction

This Developer Blog is the first of a 3-part series taking a look at SAE J2534. This series introduces SAE J2534 (including it’s multiple editions), describes how to use the 2004 API, and then provides instruction on getting started with Kvaser and J2534.

First the earth cooled, and then the dinosaurs came.
Then in 2002 people at the Society of Automotive Engineers, SAE, decided it would be a good idea to standardize the way service technicians reprogram vehicles. Rather than every technician buying different devices they want to plug into their cars and the car manufacturer having to support them all, the service technician should buy a standardized device – still from whichever supplier they wanted – with a single standardized API. This would help the vehicle manufacturers and the service technicians protect their technological investments in an ever changing field.

That year, 2002, SAE released a standard called SAE J2534-1 for this purpose, standardizing what they called “Pass-Thru Device” along with an API for controlling it. This Pass-Thru Device can then communicate to cars using any of a number of protocols that service technicians may need, while being controlled by a single interface of functions that are all called PassThruXxx() — just in case you forget you’re using a “Pass-Thru Device”.

The original 2002 version of the standard seems to have been lost to time, relegated to “superseding” clauses and compliance lists. Two years later an updated version was released, and as updated versions will be a common theme I will refer to this standard as J2534-1 2004.

The J2534-1:2004, and J2534-1:2002, standards set down the basics of the J2534 (or Pass-Thru) API; the sequence of operation as well as support for CAN 2.0, ISO-TP, ISO 9141 & 14230, and a handful more. In 2006 this was extended by J2534-2:2006 which added optional features such as several more protocols, and the ability to connect to more than one device with more than one channel. Later on J2534-2:2010 arrived with additional minor optional features, replacing J2534-2:2006 without much fuss.

Note that all features from the J2534-2 standards are explicitly optional; they do not need to be supported for a device to be J2534 compliant.

Then in 2015 came a big change. J2534-1:2015 was released, which despite having the same numbers as J2534-1:2004 has an entirely new API: a new sequence of operations, brand new functions, new interfaces for old functions, etc. It still supports the same protocols that J2534-1:2004 supports but there were two new goals: no optional features and no (okay, fewer) ambiguities.

And scrapping optional features was just as well because the optional features, from the J2534-2 standards, relied on the 2004 API which J2534-1:2015 wasn’t compatible with anyway.

The final event in our J2534 saga is the release of J2534-2:2019, with updated optional features. As the point of J2534-1 2015:was to remove optional features, this is still based on J2534-1:2004. So despite J2534-2:2019 being released after the J2534-1:2015, it is still based on the earlier J2534-1 from 2004.

And J2534-2:2019 is notable because it is the standard that introduces support for CAN FD, including ISO-TP FD. It also introduced a “discovery mechanism” which allows user applications to ask the DLL things like which protocols it supports and how many channels the device has.

So there is now an old version of J2534/Pass-Thru based on J2534-1:2004 with optional features which has been updated more recently than the newer version of Pass-Thru/J2534 defined in J2534-1:2015 but which doesn’t support CAN FD.

Confused yet? Well here’s a list of all the different J2534 standards, and what each one brought to the metaphorical table:

1. J2534-1 2002
2. J2534-1 2004 (×2)
   • CAN 2.0 & K-line based protocols
3. J2534-2 2006 (based on J2534-1 2004)
   • Multiple devices and channels
   • Mixing CAN 2.0 and ISO-TP messages on the same channel
4. (J2534-2 2010 (based on J2534-1 2004))
   • Nothing interesting
5. J2534-1 2015
   • New API.
   • CAN 2.0 & K-line based protocols
   • More explicitly stated behaviour, more verbose interface
   • No optional features
6. J2534-2 2019 (still based on J2534-1 2004)
   • CAN FD
   • Discovery mechanism

So what is the idea behind J2534 and its Pass-Thru device and API? Well, J2534-1:2004 has this to say about what it calls the “Pass-Thru Concept”:

[J2534-1] defines the following two interfaces for the SAE J2534 pass-thru device:

1. Application program interface (API) between the programming application running on a PC and a software device driver for the pass-thru device
2. Hardware interface between the pass-thru device and the vehicle

The standard assumes a certain setup. You have a vehicle with a J1962 connector, into which you plug a Pass-Thru Device. That device is then plugged into a computer with a 32-bit Windows OS, where the user application uses a DLL with a standardized interface to control the Pass-Thru Device.

Car in snow: CC-0 via pxhere.com; Pass-Thru Device: © Elsa Carlsson & Kvaser AB; IBM 300PL: CC-0 by Automaton399 @ wikimedia commons.

However, Kvaser does not sell a Pass-Thru device, but still provides a J2534 DLL. This lets customers use the same standardized API they use for Pass-Thru devices with any of Kvaser’s interfaces. This is done by wrapping Kvaser’s CANlib library, adding and extending functionality to implement the applicable parts of the J2534 standards.

However, for this to work some parts of the standard have to be reinterpreted, or don’t apply at all. The most obvious such thing is the PassThruSetProgrammingVoltage() function,  which is just something current Kvaser devices aren’t made to support. Therefore any attempt to use this function in Kvaser’s J2534 DLL will simply return “not supported”. 

Another mismatch is that J2534 specifically mandates a 32-bit dll while Kvaser compiles both a 32-bit and a 64-bit version of the DLL. Most mismatches however are more subtle and may evolve over time, so the best place to learn about them is the official readme file for the version of the DLL you are using.

So technically, Kvaser’s J2534 DLL provides a J2534 API for the CANlib library which is based on and compatible with the API from J2534-1:2004 and has as many optional features from J2534-2:2019 as are applicable. In terms of protocols, this means support for CAN 2.0, CAN FD, ISO-TP, and ISO-TP FD.

In the next part we will look at what these four protocols are, and how to use the Pass-Thru API to communicate using any of them.

Here are all functions in both the 2004 and 2015 version of the J2534 API, with a short description as provided by the relevant standard.

Definitions

• ISO-TP
  The Transport Protocol defined in 15765-2:2011, without the support for CAN FD which was introduced in 15765-2:2016. Sometimes ambiguously called simply ISO 15765-2 or ISO 15765.
• ISO-TP FD
  The Transport Protocol defined in 15765-2:2016 (including the support for CAN FD).
• CAN
  The Controller Area Network as described in ISO 11898, a blanket term for both CAN 2.0 and CAN FD.
• CAN 2.0
  The “classic” CAN with up to eight bytes of data and no support for bit rate switching.
• CAN FD
  CAN Flexible Data rate protocol that supports longer data than CAN 2.0 as well as bit rate switching.
• J2534
  A family of standards that specify the Pass-Thru device and the Pass-Thru API used to communicate to the device via a J2534 DLL.
• J2534 DLL
  The DLL provided by an interface manufacturer, which conforms to the Pass-Thru API.
• Pass-Thru API
  The API of all J2534 DLLs, which the vehicle manufacturer can use regardless of which company’s J2534 DLL is actually in use.
• Pass-Thru devic
  A specific type of device standardized by J2534, which has an accompanying J2534 DLL.

• Kvaser’s Overview of SAE J2534