CAN Hacking: Protocols

We’ve gone over the basics of CAN and looked into how CAN databases work. Now we will look at a few protocols that are commonly used over CAN.

In the last article we looked at CAN databases, where each bit of a message is mapped to a specific meaning. For example, bit 1 of a CAN message with ID 0x400 might represent whether the engine is currently running or not.

However, for more complex communications we need to use protocols. These can map many meanings to a single CAN ID by agreeing on a structure for sending and receiving data.

OBD-II

The standard OBD-II connector

Next time you’re in the drivers seat, look around your left knee. You’ll find a connector like the one above. This is the OBD-II connector.

The OBD-II protocol is not CAN specific, and can be implemented over UART and PWM channels as well as CAN. OBD-II became present in cars when the California Air Resources Board demanded a diagnostic protocol for all vehicles sold in California in 1991. Since it’s always done over CAN in newer vehicles, this connector gives you access to at least one vehicle CAN bus.

OBD-II is used for reading vehicle parameters and reading fault codes. By using the various OBD-II modes, you can read parameter IDs (PIDs) containing information about the state of the vehicle. Wikipedia has a great article on the OBD-II modes and PIDs.

There’s a wealth of information out there about OBD-II, and you can buy a tool for under 20 bucks to read fault codes and clear the pesky check engine light in your car. Instead of going into detail about OBD-II, lets talk about its big brother.

Unified Diagnostic Services

While many car enthusiasts are familiar with OBD-II, many haven’t heard of Unified Diagnostic Services (UDS). This is unfortunate, since OBD-II is just a subset of UDS. While OBD-II only allows a limited set of services, UDS is the diagnostic protocol that manufacturers and technicians use. It provides all the services needed for diagnostics, calibration, and flashing firmware.

UDS has various services, such as ReadDataByIdentifier and TransferData, which are identified with a one byte Service ID (SID). The first 0x0F SIDs are reserved for OBD-II. The rest are defined either by standards, or by the manufacturer. Here’s a list of the standard UDS services, and their hex identifiers.

DiagnosticSessionControl – 10 hex

ECUReset – 11 hex

SecurityAccess – 27 hex

CommunicationControl – 28 hex

TesterPresent – 3E hex

AccessTimingParameter – 83 hex

SecuredDataTransmission – 84 hex

ControlDTCSetting – 85 hex

ResponseOnEvent – 86 hex

LinkControl – 87 hex

ReadDataByIdentifier – 22 hex

ReadMemoryByAddress – 23 hex

ReadScalingDataByIdentifier – 24 hex

ReadDataByPeriodicIdentifier – 2A hex

DynamicallyDefineDataIdentifier – 2C hex

WriteDataByIdentifier – 2E hex

WriteMemoryByAddress – 3D hex

ClearDiagnosticInformation – 14 hex

ReadDTCInformation – 19 hex

InputOutputControlByIdentifier – 2F hex

RoutineControl – 31 hex

RequestDownload – 34 hex

RequestUpload – 35 hex

TransferData – 36 hex

RequestTransferExit – 37 hex

UDS uses a frame structure to send data to controllers. Single Frames (SF) are for short messages, where all the data can fit into six bytes. If the data is longer, a FirstFrame (FF) is sent to start the transaction, then Consecutive Frames (CF) are sent with data. Here’s a layout of how the frames are structured.

The structure of SF, FF, and CF messages

OBD-II only uses the first frame structure, but the others are useful for longer data such as a firmware download.

To get into how all the services work, you’ll need a copy of ISO 14229. Unfortunately, it’ll cost you about $250 USD just for the PDF. Tools that can talk UDS are very expensive. However, with this basic knowledge you can get a grasp of what’s happening on the bus.

OpenXC

While UDS is a closed protocol, researchers at Ford have been working on creating an open platform for interfacing with vehicles. The result is the OpenXC Platform. OpenXC provides a protocol to read data from Ford vehicles over CAN.

To use it, you’ll need a vehicle interface. A chipKIT can be used with Ford’s open source firmware. Alternatively, you can buy a prebuilt solution from CrossChasm. Once the vehicle interface is up and running, you can access data from the Android and Python APIs. We’ve featured a few OpenXC hacks on Hackaday in the past.

It’s great to see an automotive manufacturer embracing open source, and hopefully Ford continues to work on the platform. That being said, the OpenXC protocol is read only, and limited to a fairly small set of messages.

Now that we’ve heard all about protocols, it’s time to get into building CAN hardware. Next week we’ll look at what hardware you need to start using CAN in your own projects.

It should be noted that while OBD-II was not mandatory until 1996. Some 1995 and earlier model year vehicles have it, but not many. Prior to OBD-II, OBD (the original specification) did not require a generic connector, forcing shops to get expensive vehicle-specific diagnostic tools. Much like the requirements for manufactures to not void vehicle warranties when after-market parts were used, OBD-II was partially ratified to allow independent shops to more easily diagnose emission-related problems, without paying exorbitant amounts for tools

Ford just earned some serious respect from me. The expense of some of these OBD-II tools completely blew my mind, largely contributing to my hatred of computers in cars (despite my love of computers in general!) I’m very glad somebody is working to change this a bit, and hope other car makers follow suit.

Oddly enough, take a look at the specifications behind MIL-STD-1553. It’s in much the same shape as the OBD families of methods of access to vehicles (ground). Typically that one is found in military aircraft, although the Space Shuttle used it……..

I’m not an expert on what subset of the standards ODB-II supports, but if it used the first frame (FF), it would also the consecutive frame (CF) (because if the data could fit in a single frame, it would use the single frame format).

What the article doesn’t show is the 4th kind of frame, the flow control frame (FC). After the FF is sent, the receiver sends the FC frame to let the sender know if and how it should send the remaining consecutive frames.

You can find more info on this on Wikipedia under ISO-15765 if you don’t have access to the actual standards.

if making snowfall leaps Hermes purses And totes operating 3ounce throwaway duplicate Hermes cups of coffee or even a conforms icle, pour the juices a mixture on the road to these kind of people until it is they have been perfect possessions wall plug ecommerce better than nearly full. ecckabbkefkc