Local Interconnect Network (LIN) Data Link Layer

Last modified by Microchip on 2023/11/10 11:17

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 network is described by a LIN Description File (LDF), which contains information about frames and signals (including timing). This file is used for the creation of software drivers in both Master and Slave nodes.

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:

Unconditional frames

Note:

  • Frame Slot A, Frame Slot B, and Frame Slot C are cyclic (i.e. they cycle regularly through all the nodes).
  • The Nodes that reply to the header are the PUBLISHERS.
  • The Nodes that listen are the SUBSCRIBERS.
  • Frame Slot A
    • Point-to-Point (Slave-to-Master or Slave-to-Slave) communications.
      • SLAVE1 Publishes and MASTER and/or SLAVE2 Subscribes.
  • Frame Slot B
    • Multicast (Master-to-one-or-more Slaves) communications.
      • MASTER Publishes and SLAVE1 and/or SLAVE2 Subscribes.
  • Frame Slot C
    • Point-to-Point (Slave-to-Master or Slave-to-Slave) communications.
      • SLAVE2 Publishes and MASTER and/or SLAVE1 Subscribes.

Back to top

Summary

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

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.

frame slot

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.

Master header sync 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).

master header sync field

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.

master header ID field

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-310x00-0x1F2
32-470x20-0x2F4
48-630x30-0x3F8

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.

slave response data field

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

slave response checksum field

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.

Slave response signal distribution

Signal Distribution Example

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

​All Signals in a LIN cluster are defined in the LIN Description File (LDF).

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

Unconditional frames

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:

Event frame 1

Scenario #2

SLAVE1 has an event to report and publishes a response:

Event frame 2

Scenario #3

Two (or more) Slaves detect and publish responses:

Event frame 3

Sporadic Frames

Sporadic frames blend some dynamic behavior into the deterministic and real-time focused schedule table without losing the determinism in the rest of the schedule table.

  • Sent by Master only when it is known that a Slave has updated information to publish.
  • Blends dynamic behavior into the schedule table.

Sporadic frames

 

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)

Diagnostic frame master request

Example (Slave Response Frame)

Diagnostic frame master response

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:

go to sleep frame

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.
wake up signal

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, tFrame_Nom:

minimum frame slot duration

Where:

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

​LIN message fields are described in detail here.

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:

max frame slot duration

Frame Slot Width

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

frame message 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

LIN schedule

​The length of each frame slot varies and depends upon the number of expected data bytes in the response message.

Time Base

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

​Tbase and tjitter are both defined in the "Nodes" section of the LDF as shown in the accompanying image.

LIN time base

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.

LIN schedule table

Back to top