Local Interconnect Network (LIN) Data Link Layer

In the OSI model, Data Link Layer protocols are concerned with establishing/terminating a connection between two nodes and ensuring reliable data transfer. They also implement protocols for flow control between the nodes.

Overview

Local Interconnect Network (LIN) is a broadcast-serial network. The data link layer implements a Master-Slave principle for medium access control. All messages are initiated by the Master with at most one Slave replying to a given message identifier. The Master node controls the issuance of data frames on the bus, makes sure that they are sent with the right interval and periodicity, and that every frame gets enough time space on the bus.

The LIN bus was designed to transport short control messages (2, 4, or 8 bytes). The data that are exchanged in the frames are referred to as signals.

The LIN Data Transfer model is based on the publish-subscribe model, for example:

Back to top

Summary

A LIN cluster contains (at most) 1 node designated as the LIN-Master:

• Contains a Master Task which sends Headers at regular intervals based on the LIN Description File (LDF).
• Contains a Slave Task which either:
  • Sends a Response.
  • Reads a Response.
  • Ignores the Header.

A LIN cluster contains up to 16 nodes designated as LIN-Slaves:

• Contains a Slave Task which either:
  • Sends a Response.
  • Reads a Response.
  • Ignores the Header.

LIN Message Frame

All data is sent in a Frame Slot which contains a Header, a Response, and some Response Space so the Slave will have time to answer. Every frame is sent in a frame slot determined by the LDF. Messages are created when the Master node broadcasts a frame containing a header. The Slave node(s) then fills the frame with data depending on the header sent from the Master. The data that are exchanged in the frames are referred to as signals.

Back to top

Master Header

Sync Break Field The Sync Break is specified as a dominant condition (bus low) at least 13-bit times. This is longer than the worst-case data pattern of all dominant, thus ensuring that the bus will see it as a break.
Sync Field The Sync Field byte is sent to enable the Slave to determine the time between two falling edges and thereby determine the transmission rate that the Master uses (auto baud detection). The bit pattern is 0x55 (0b01010101).
Protected Identifier Field (PID) The Protected Identifier Field (PID) consists of two sub-fields; the frame identifier and the parity. Bits 0 to 5 are the frame identifier and bits 6 and 7 are the parity.
Frame ID Bits The 6-bit frame identifier contains information about the sender and receiver and the number of bytes which is expected in the response. Frame IDs are split into three categories: 0-50 (0x00-0x3B) are used for normal signal/data carrying frames. 60 (0x3C) and 61 (0x3D) are used to carry diagnostic and configuration data. 62 (0x3E) and 63 (0x3F) are reserved for future protocol enhancements.	ID Range (Dec) ID Range (Hex) Data Length 0-31 0x00-0x1F 2 32-47 0x20-0x2F 4 48-63 0x30-0x3F 8
Parity Bits The parity bits are calculated as follows: P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4 P1 = ! (ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)

Back to top

Slave Response

Data Field Once the header sent by the Master node has been transmitted, it's time for the transfer of actual data to begin. Based on the transmitted identifier, a Slave will recognize that it's been addressed, and reply with a response in the data (signal) field. Several signals can be packed into one frame. Data bytes are transmitted LSB first. ​A frame carries between one and eight bytes of data. The publisher and all subscribers shall agree on the number of data bytes contained in a frame with a specific frame identifier. Multi-byte numerical quantities are transmitted LSB-first.

Checksum Field The data response of the Slaves is checked by means of a checksum. The use of classic or enhanced checksum is managed by the Master node and it is determined per frame identifier; classic in communication with LIN 1.x Slave nodes and enhanced in communication with LIN 2.x Slave nodes. ​Frame identifiers 60 (0x3C) to 61 (0x3D) shall always use a classic checksum. A detailed description of the Checksum calculation (with examples) is provided in Section 2.3.1.5 of the "LIN v2.2A Specification".

Back to top

Signals

A signal is transported in the data field of a LIN frame. Each signal has exactly one publisher, i.e. it is always written by the same node in the cluster. Zero, one, or multiple nodes may subscribe to the signal. All signals have initial values. The initial value for a published signal is valid until the node writes a new value to this signal. The initial value for a subscribed signal is valid until a new updated value is received from another node.

Signal Types

For a given data frame, a signal is either a scalar value or a byte array.

• A scalar signal is between 1 and 16 bits long.
  • A 1-bit scalar signal is called a boolean signal
  • Scalar signals in the size of 2 to 16 bits are treated as unsigned integers.
• A byte array is an array of between one and eight bytes.

Signal Distribution Example

The following data frame depicts four varying-width scalar value signals (A, B, C, D, E):

Back to top

LIN Frame Types

There are several different frame types in the LIN, each contributing specific functionality to the data link layer.

Unconditional Frames This is the “normal” type of LIN communication. The Master sends a frame header in a scheduled frame slot and the designated Slave node fills the frame with data. Unconditional frames carry signals and their frame identifiers are in the range 0 (zero) to 59 (0x3B).

Event-Triggered Frames

The purpose of an event-triggered frame is to increase the responsivity of the LIN cluster without assigning too much of the bus bandwidth to the polling of multiple Slave nodes with seldom occurring events.

• Master asks Slaves if a certain event has occurred.
• Only those who have seen the event publish a response.
• Identifiers 0x00 to 0x3b (0-59).
• Collisions are possible - if more than one Slave has detected the specified event, all respond simultaneously, resulting in a collision.
• When detected, Master reverts to unconditional frames.
• Can result in better utilization of bandwidth.

Scenario #1 No Slaves have an event to report, no one publishes:
Scenario #2 SLAVE1 has an event to report and publishes a response:
Scenario #3 Two (or more) Slaves detect and publish responses:

Back to top

Diagnostic Frames

These are used in the Transport Layer Specification section of the LIN v2.2A Specification. Their primary function is in the area of implementing diagnostics and configuration functions on LIN Slaves.

• Carry diagnostic/configuration data.
• Always contain an 8-byte data payload.
• Designated Identifiers:
  • 0x3C (60) Master Request Frame.
  • 0x3D (61) Slave Response Frame.

Data Field Definitions:

• Node Configuration:
  • Configuration of standard Slaves.
  • Universal usage.
  • Off-the-shelf sensors can be used.
• NAD (Node Address)
  • Initial NAD: Origin address of Slave (Slave answers to this address in case of a Master Request).
  • NAD: Address of Slave. Can be assigned by configuration.
• Supplier ID:
  • Supplier Identification e.g. 0x0014 = Microchip.
• Function ID:
  • Function Application e.g. 0xAA55 = Window Lift Switch.
• Variant:
  • Application Type e.g. 0x3C = Anti Pinch Function.

Example (Master Request Frame)
Example (Slave Response Frame)

Network Management Frames

Network management in a LIN cluster refers to cluster wakeup and go-to-sleep only.

All Nodes Sleep Command The Master sets the cluster into Bus Sleep mode by transmitting a go-to-sleep command. The go-to-sleep command is a Master request frame with the first data field set to 0 and rest set to 0xFF:
WakeUp Any node can request a wakeup. Node forces dominant from 250 µs – 5 ms. All nodes should then wakeup within 100 ms from end of wakeup signal. Master node must transmit within 150 ms.

Back to top

Frame Timing

A key property of the LIN protocol is the use of schedule tables. Schedule tables make it possible to assure that the bus will never be overloaded. They are also the key component to guarantee the periodicity of signals.

The Schedule Table in the LDF defines the sequence and time grid in which messages are sent. Once the table has been worked through, the Master begins with the first message again.

In order to develop the schedule table, you need to be able to calculate the duration of LIN messages (i.e. the frame slot width).

Nominal Message Length

The accompanying image demonstrates the basic minimum frame slot duration, t_{Frame_Nom}:

Where:

• n = #bytes in the response data field (1 to 8)
• t_bit = baudrate^-1
  • ex. (19.2 kBit/s)^-1 ~ 52.1 µS

Back to top

Time Reserve

LIN slaves are typically implemented using low-cost, lower-speed microcontrollers. Thus, the specification allows a time reserve of up to 40% to be added to each Serial Communications Interface (SCI) frame (Universal Asynchronous Receiver Transmitter (UART) byte) as shown in the accompanying image:

Frame Slot Width

Finally, a small delay tolerance is specified for the Master node, called t_Jitter in order to create the final frame slot width:

Back to top

LIN Schedule

Now that we understand the frame slot width of a LIN message, we can begin to understand the LIN schedule table.

The following depicts an example LIN schedule and corresponding LIN frame slots

Time Base

LIN frame slots are scheduled based on a LIN cluster time unit, called the LIN time base, T_base, which is usually 5 or 10 mS.

Example

The accompanying example depicts a LIN schedule table within an LDF. The table has a "Main" sub-table defining four frame slots. The time base is 5 mS (not shown). The delay parameter specifies the frame slot duration in mS. The value must be a multiple of the time base.

Back to top