Vehicle Networks & Protocols · Chapter 3

Local Interconnect Network (LIN)

The LIN bus is a single-wire bus used for low-speed communication between ECUs. It was developed in 1999 as a low-cost alternative to CAN. It's used for non-critical systems such as door locks, mirrors, wipers, and climate control.

History

A brief history of LIN:

  • 1999 — LIN 1.0 is released by the LIN consortium (BMW, Volkswagen, Audi, Volvo, Mercedes-Benz, Volcano Automotive and Motorola).
  • 2000 — LIN 1.1 and LIN 1.2 are released.
  • 2002 — LIN 1.3 is released with some revisions to the physical layer, improving compatibility between nodes.
  • 2003 — LIN 2.0 is released with an improved checksum, support for sporadic and event-triggered frames, and reading diagnostic information from nodes.
  • 2006 — LIN 2.1 is released with improved diagnostics and configuration.
  • 2010 — LIN 2.2A released, correcting some minor errors and changing rules for bit sampling.
  • 2016 — LIN standardized as ISO 17987.
  • 2025 — The ISO 17987 series was updated. This chapter follows the current ISO terminology: commander and responder.

Physical Layer

A LIN bus consists of one commander and up to 16 responder nodes. The commander node is responsible for scheduling the communication on the bus. Responders can only send data when requested by the commander. The bus can be up to 40 m long and run at a maximum speed of 19.2 kbit/s (20 kbit/s for LIN 2.0). It supports up to 8 bytes of data per frame.

The physical specification is based on ISO 9141 (K-Line) and only requires a single wire. The bus is pulled high to 12 V by a pull-up resistor. A dominant bit is sent by pulling the bus low. A recessive bit is sent by releasing the bus. The bus is idle when it's pulled high.

LIN Frame

A LIN transaction starts with a frame header from the commander node with the following content.

LIN frame showing the header from the commander and the response from the addressed responder.
LIN frame showing the header from the commander and the response from the addressed responder.

  • SBF (Start Bit Field) — Used to indicate the start of a frame. It contains 13 (or more) dominant bits, followed by one recessive bit, the Sync delimiter.
  • Sync — The Sync Field is used to synchronize the clock between the commander and the other nodes. It consists of a single byte with the value 0x55, containing alternating dominant and recessive bits.
  • PID (Protected Identifier) — Contains the 6-bit frame identifier and two parity bits (computed over the ID). The frame identifier is used by the responder to determine if it should respond to the frame.

The responder then transmits the response. It is also possible for the commander to reply to its own header to send data to one or more responders.

  • Data — The data field contains the actual payload of the frame. It can be 2, 4 or 8 bytes long.
  • Checksum — Contains an 8-bit checksum. For LIN 1.x this was computed over the data bytes only, while for LIN 2.x the identifier is also included in the checksum.

Types of Frames

The following types of frames can be distinguished:

  • Unconditional Frame — The most common type of frame, where the commander requests data from a responder. The commander initiates the transaction and a single responder replies with the data.
  • Event Triggered Frame — Used to receive data that does not change very often. Using event-triggered frames saves bandwidth by not needing to poll each responder individually. The commander asks all responders if they have new data to send. Then all responders may respond simultaneously with the data, but most of the time this will be only one node. When multiple nodes respond at the same time, the commander detects a collision and interrogates each node individually using unconditional frames.
  • Sporadic Frame — Sometimes the commander needs to send data to responders. In this case the commander starts the transaction, but then replies to its own header with the data.
  • Diagnostic Frame — The LIN 2.2A specification reserves ID 60 and 61 for diagnostic and configuration purposes, such as dynamically assigning a node address or issuing sleep commands.