Hacking Cars: 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.

can-hacking-part-2

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
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.

UDS Message Structure
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.

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.

Credit: Eric Evenchick, HACKADAY

Advertisements

One thought on “Hacking Cars: Protocols

  1. Pingback: Publications, études, rapports 2015 S07 | La Mare du Gof

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s