# Automotive protocols in automotive (for devs)

In the automotive world, several protocols are used for different purposes.

Here we will give only a high-level overview of each, from a developer's point of view, if you want to read more about each protocol, there's plenty of in-depth documentation on google.

This is pretty much a "What you need to know as a dev", assuming you uses libraries to do all the low level work, with some context to understand why it was created, and what they are used for.

## LIN (Local Interconnect Network)

LIN, for Local Interconnect Network, is a low-cost, low bandwith, master-slave protocol with a bandwith up to 19.2kbps on a single wire.

It is mostly used for the simplest ECUs that doesn't need full CAN capabilities, as it is simple enough to be fully implemented in software, for example simple notifications light, or the wipers.

The network (up to 40meters) is master-slave based, with 16 nodes in total (so one master and up to 15 slaves), with broadcast messages only. The master initiate the messages, with an identified, to which the slaves with that identified reply to. The master can also act as it's own slave, replying to it's own messages.

From a high level point of view, a LIN message is:
* An ID, from 0x00 to 0xFF
* A size for the data, which is either 2, 4 or 8 bytes
* The data which is $size bytes long

## VAN (Vehicle Area Network)

VAN, for Vehicle Area Network was (it is not phased out for CAN) a multi-master, "high" bandwith, up to 250kbps, with up to 16 nodes per bus on two wires.

This is basically "same as CAN, but from peugeot/renault instead of bosch" (frenchies love their NIH syndrome), it is so similar that you can use CAN transceivers (not controllers!) for VAN, only the encoding changes, without the termination resistors.

From a high level point of view, a VAN message is:
* An identifier, 12 bits wide (0x000 to 0xFFF)
* A size for the data, which is up to 28 bytes
* The data, which is $size bytes long

## CAN (Controller Area Network)

CAN, for Controller Area Network is a multi-master, "high" bandwith, up to 1mbps, on two wires, with it's node limitation being the occupation of the bus. It also needs termination resistors on each end.

This is the currently the king of automotive protocols, if you have to learn only one, pick CAN. It is also the basis on the higher-level protocols for diagnostics.

The CAN buses are one of two types:
* High speed, up to 1mbps, but you lose fault tolerance.
* Low speed (up to 125kbps in theory, but we've seen 250kbps in practice), for which you have fault tolerance (it can for example run on a single wire, should the other one have an issue).

One of the key characteristics of CAN is it's ID priority, if two nodes send their data in the same time, as it is a broadcast bus with 0 level having priority, when they will send their IDs, the higher ID will see that at some point, the bus is 0 when it just sent an 1, and will stop sending the rest of the data, as there's another node with a lower ID (which has priority) already sending data.

From a high level point of view, a CAN message is:
* An identifier, which can be either 11 bits, from 0x000 to 0x7FF (also called CAN 2.0A) or 29 bits, from 0x00000000 to 0x1FFFFFFF (also called CAN 2.0B)
* A size for the data, which is up to 8 bytes)
* The data, which is $size bytes long

### CAN FD (Flexible Data-rata)

CAN FD, for CAN Flexible Data-rate, is an extension of CAN which allows faster data rates and larger message sizes.

It was released by bosch in 2012, so it is still quite uncommon, but with it's faster data rate and bigger messages, it may become increasingly popular in automotive.

As it is an extension, you have to switch from classic CAN to CAN-FD, and you can even switch the data-rate dynamically, up to 5mbps in high-speed bus.

It uses 29 bits identifieds, and the data size can be up to 64 bytes, but CAN-FD can also manage 11 bits identifiers as well. It also has better error detection. It also supports CAN-TP (see below).

### CAN-TP (Transport Protocol)

CAN-TP, for CAN Transport Protocol, also called ISO-TP, is a standard that defines a higher level protocol to enable sending more than 8 bytes per message over CAN.

Basically, CAN-TP is to CAN what TCP is to IP. it fragment a up to 4095 bytes payload into 8 bytes "packets" (CAN messages) that are then assembled on the receiver side to recreate the longer payload.

It is used with CAN IDs only (called "Normal Addressing", the most common, or with CAN IDs + the first byte of the CAN message used as an additional address (called "Extended addressing"). When used with Extended Addressing, the payload per CAN message is reduced by one byte (due to the first byte being used for the extended address).

It uses a pair of CAN IDs, one for the data, one for the flow control, with four CAN messages types:
* Single Frame (type 0): Used to send only up to 6 (extended addressing) or 7 (normal addressing) bytes of data. Only the first byte is used, for type and size (0 to 7 bytes)
* First Frame (type 1): Used to send longer messages, it is the first frame to be sent. it use the first and second byte for type and size (8 to 4095 bytes)
* Consecutive Frame (type 2): Used for consecutive data (after the first frame), it uses the first byte for type and index (message x of y)
* Flow Control Frame (type 3): used to manage the flow of the data.

NB: When using extended addressing, bytes used by the frames are moved one byte to the right, as the extended address already takes the first byte).

More detailed infos will come in a dedicated page.

## OBD

OBD, for On Board Diagnostics, is easily the most misunderstood set of standards of them all, due to the name being used for a lot of different meanings.

First, OBD is often used as a generic term for "Diagnostics", which we will not do here, we will focus on the OBD-I, OBD-II, JOBD, ADR79 and EOBD standards.

These standards were pretty much only created for emission controls, they are not really used for any kind of diagnostics other than that.

### OBD-I

OBD-I was the first standard, defined by the california state for emission control. Each automaker was free to use their own connector and protocol, which lead to this version being quickly phased out because there was too much protocols and connectors to support to be used effectively. Some cars didn't even had a connector, relying on the dashboard LEDs and buttons to display the data.

A so called "OBD 1.5" exists, but it is only a partial implementation of OBD-II by general motors during the 90's.

### OBD-II

This updated standard is actually in two parts:
* The standard connector (SAE J1962) being mandatory in a location directly reachable from the driver seat
* The protocol, which can be used on top of either CAN, ISO9141 "K-Line", ISO14230 "KWP2000" or SAE J1850

The protocol defines "Services" (previously called "Modes"), that are used to check for faults (called DTC for Diagnostic Trouble Codes), a limited set of live data, general informations or to request a DTC clear (clearing the faults in the ECU).

NB: The DTCs available with OBD-II are limited to the faults that may impact pollution, and such, only a subset of ECU reports DTCs on OBD-II.

Automakers can use reserved DTCs and data IDs to transmit more informations than what the standard require, these are sometime called "EOBD2", not to be mistaken for EOBD (the E in EOBD2 means "Extended" or "Enhanced", where the E in EOBD is for "European").

Beside the target use of emission control, it is possible to do really basic diagnostics (using the live data and DTCs) using an inexpensive dongle, or to use the live data to provide additional features (such as data logger, fleet control, trip computers, or digital gauges). Several products exists for this, with the most famous being the ELM327 and it's clones.

NB: The OBD-II standard being from the 90's, it may be quite daunting to read about so many standards and  such a complex history, but nowadays (since around 2005 to 2010), it is much easier due to CAN phasing out pretty much every automaker specific protocol, as well as most older standard protocols (ISO9141 and KWP2000 for example)

More info will come in a dedicated page.

#### Relation to JOBD, ADR 79 and EOBD

JOBD (Japan), ADR 79 (Australia) and EOBD (Europe)  uses the same SAE J1962 connector as OBD-II, and a mostly compatible protocol, the differences being negligible enough that they don't matter in practice.

## ISO9141 aka K-Line

This is one of the standards that was used as a low level layer for OBD-II. it is basically a serial line  over a single wire, with a data rate of 10.4kbps. there was also an optional so called L-Line that was used for wakeup, and some automaker did some kind of multiplexing on the K-Line itself by using OBD-II identifiers to select the ECU.

## KWP 2000 (or KWP2k)

KeyWord Protocol 2000, or KWP2000/KWP2k, is also one of the tricky protocols because it includes both a low level protocol, as well a higher level diagnostics protocol.

The low level protocol (the physical layer) is actually the same as ISO9141, with 2 wake-up sequences to be used before communication with an ECU can happen, these are often called 5-baud wakeup and fast-init. this is the part used by the OBD-II standards.

The high level protocol can be used on top of K-Line, but it's most common use case is on top of CAN-TP.

KWP2k uses "services" to query the ECUs, that can be used to query DTCs, configure the ECU, update it, execute specific routines, or even control the ECU's I/O directly.

The standard defines most of the protocol, but the actual data/diagnostics/routine/IO IDs as well as the authentication scheme is left to the automaker's choice, and are often proprietary.

More detailed info will come in a dedicated page.

## UDS (Unified Diagnostics Services)

UDS, for Unified Diagnostics Services) is the latest and most commonly used diagnostics protocols in cars from the 2010s. This standard was created to unify the diagnostics standards that existed previously, hence it's name.

This is mostly a superset of the KWP2k high level protocol, and is agnostic to the lower level protocol. In practice, it is most often used with CAN-TP.

Like KWP2k, it defines "services" but the specific data IDs and authentication scheme is still left to the automakers, and are often proprietary. They are required to give access to their specifications to diagnostics tools OEMs, but they are often only available with a contract with a price in the five to six figures.

More detailed info will come in a dedicated page.

## FlexRay

FlexRay is a high bandwith (up to 10mbps), multi-master bus that is designed to be faster than can, but is also more expensive. It was designed mainly for drive-by-wire systems.

This standard was created by a consortium including Freescale, Bosch, NXP, BMW, VW, Daimler and GM. it is only used in a subset of cars made by Audi, Bentley, BMW, Lamborghini, Mercedes, Rolls-Royce, Land-Rover and Volvo, and seems to be phased out in favor of Ethernet.

## Ethernet

Ethernet is a high bandwith (10, 100, 1000 mbps and beyond) network protocol that is widely used in computer networks, and is starting to get a place in the automotive world as well thanks to it's high speed, and being already well known and used in the IT industry, it is easy to recruit developers that already know how to use Ethernet.

It is currently mostly used for ECUs that needs to display multimedia or complex graphics, such as the infotainment system or the digital cluster, with the core ECUs still using CAN, it is for example the case in Tesla cars.

## MOST

Most, for Media Oriented Systems Transport is a high speed (up to 150mbps) network with up to 64 nodes.

It was designed, and is widely used for multimedia systems, including infotainment and digital cluster, and is competing against Ethernet that is used for the same purposes.

# TL;DR/Recap

There is mostly 3 kinds of standards used in the automotive industry:
* Data buses used for inter-ECU communications, these are LIN, VAN, CAN (with CAN FD and CAN-TP) and FlexRay, with CAN being the most used since the mid 2000s
* Multimedia networks used mainly for infotainment, with MOST and Ethernet competing in that space
* Diagnostics and emission control protocols, all using the same connector as OBD-II, these are OBD-II, ISO9141, KWP2k and UDS

Automakers often use a combination of these, with some (OBD-II and UDS) being mandatory, other (CAN, LIN, MOST, Ethernet) being widely used, and other (ISO9141, KWP2k, VAN) being phased out.
These standards often only define a "common base" on top of which automakers can implement their own, proprietary data/protocols. Thus, a common way to write code in automotive is to separate the code into an agnostic codebase, and the automaker-specific part on top of it.

## Other protocols

These are mostly protocols used before OBD-II, KWP2k and UDS standardized the diagnostics

* XR25 by Renault
* SAE J1850, mostly used by GM
* ALDL by GM
* (Unamed protocol) by PSA
* ... to be continued