CAN Hacking: Protocols

44 Comments

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

CAN Hacking

44 thoughts on “CAN Hacking: Protocols”

    3. hey Q, u seem like a helpful guy and i need some help. i am trying to fit some seats from a 2014 taurus into pre-computer vehicle. driver’s seat has a module for the power seat operation and the passenger seat has a module for the heating and cooling for both seats. long story short i need to tell these modules to work. i have the official ford manual for all the wiring and can identify the MS CAN communication wires for each modules so it seems like i just need a “signal generator” (?!). any help would be greatly appreciated.

      Report comment
      Reply

      1. You will need access to Ford’s CAN database. Since seat positions are not part of OpenXC (which would be read only anyway) this will probably require some social engineering or other methods of information access. Once you know which messages to send, you’ll need a control module like http://vector.com/vi_canister_en.html. Cheaper models are available from numerous suppliers (but may be harder to configure).

        Report comment
        Reply

    1. Schwarz_Oa,

      What systems do you work with?

      As far as the Medium-Speed CAN bus goes, Ford is only releasing binary firmware which only includes a subset of translations, and they don’t actually release what the message IDs are.

      I will post up a spread sheet of what I have so far as well as my OpenXC implementation of the JSON signals file.

      I am planning on replacing my center console with an Android tablet, the next thing I need to do is sniff the Heat/AC controls so I can write that into my andoid app as well.

      Report comment
      Reply

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

    Report comment
    Reply

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

    Report comment
    Reply

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

    Report comment
    Reply

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

      Report comment
      Reply

  15. Here’s some of my CAN hacks from 2005+ onwards.

    Real time tracing and changing of internal ecu tables while tuning
    http://www.youtube.com/watch?v=EOalTdwfAhI

    watching various internal ECU parameters ( showing a steady idle in this case)
    http://www.youtube.com/watch?v=jQbWorgcDuI

    I’d been developing a new gui back then, never finished it ( uses canned data for the test, but it normally reads it all off the CAN bus)
    http://www.youtube.com/watch?v=06MeRhBtqDw

    I wote the app to tie into multiple ecu types just via a DLL.

    bouncy videos.

    Report comment
    Reply

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

    Report comment
    Reply

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.