Hubbry Logo
Local Interconnect NetworkLocal Interconnect NetworkMain
Open search
Local Interconnect Network
Community hub
Local Interconnect Network
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Local Interconnect Network
Local Interconnect Network
Local Interconnect Network
View on Wikipedia
from Wikipedia

LIN is a network protocol used for communication between components in modern vehicles. It is a low-cost single-step serial protocol that supports communications up to 19.2 Kbit/s with a maximum bus length of 40 metres (131.23 ft).

History

[edit]

The need for a cheap serial network arose as the technologies and the facilities implemented in the car grew, while the CAN bus was too expensive to implement for every component in the car. European car manufacturers started using different serial communication technologies, which led to compatibility problems.

In the late 1990s, the LIN Consortium was founded by five automakers (BMW, Volkswagen Group, Audi, Volvo Cars, Mercedes-Benz), with the technologies supplied (networking and hardware expertise) from Volcano Automotive Group and Motorola. The first fully implemented version of the new LIN specification (LIN version 1.3) was published in November 2002. In September 2003, version 2.0 was introduced to expand capabilities and make provisions for additional diagnostics features. LIN may be used also over the vehicle's battery power line with a special LIN-over-DC-power-line (DC-LIN) transceiver. LIN over DC power line (DC-LIN) was standardized as ISO/AWI 17987-8.[1]

CAN in Automation has been appointed by the ISO Technical Management Board (TMB) as the Registration Authority for the LIN Supplier ID standardized in the ISO 17987 series.

Network topology

[edit]

LIN is a broadcast serial network comprising 16 nodes (one primary and up to 15 secondary nodes).[2][3][4][5]

All messages are initiated by the primary node with at most one secondary node replying to a given message identifier. The primary node can also act as a secondary node by replying to its own messages. Because all communications are initiated by the primary node it is not necessary to implement a collision detection.[6]

The primary and secondary nodes are typically microcontrollers, but may be implemented in specialized hardware or ASICs in order to save cost, space, or power.

Current uses combine the low-cost efficiency of LIN and simple sensors to create small networks. These sub-systems can be connected by a back-bone network (i.e. CAN in cars).[7]

Overview

[edit]

The LIN bus is an inexpensive serial communications protocol, which effectively supports remote application within a car's network. It is particularly intended for mechatronic nodes in distributed automotive applications, but is equally suited to industrial applications. It is intended to complement the existing CAN network leading to hierarchical networks within cars.

In the late 1990s the Local Interconnect Network (LIN) Consortium was founded by five European automakers, Mentor Graphics (Formerly Volcano Automotive Group) and Freescale (Formerly Motorola, now NXP). The first fully implemented version of the new LIN specification was published in November 2002 as LIN version 1.3. In September 2003 version 2.0 was introduced to expand configuration capabilities and make provisions for significant additional diagnostics features and tool interfaces.

The protocol’s main features are listed below:

  • Single master, up to 16 slaves (i.e. no bus arbitration). This is the value recommended by the LIN Consortium to achieve deterministic time response.[8]
    • Slave Node Position Detection (SNPD) allows node address assignment after power-up[9]
  • Single-wire communications up to 19.2 kbit/s @ 40 meter bus length.[8][10] In the LIN specification 2.2,[9] the speed up to 20 kbit/s.
  • Guaranteed latency times.
  • Variable length of data frame (2, 4 and 8 bytes).
  • Configuration flexibility.
  • Multicast reception with time synchronization, without crystals or ceramic resonators.
  • Data checksum and error detection.
  • Detection of defective nodes.
  • Low-cost silicon implementation based on standard UART/SCI hardware.
  • Enabler for hierarchical networks.
  • Operating voltage of 12 V.[8]

Data is transferred across the bus in fixed-form messages of selectable lengths. The master task transmits a header that consists of a break signal followed by synchronization and identifier fields. The slaves respond with a data frame that consists of 2, 4 or 8 data bytes plus 3 bytes of control information.[9]

LIN message frame

[edit]

A message contains the following fields:[9]

  • Synchronization break
  • Synchronization byte
  • Identifier byte
  • Data bytes
  • Checksum byte

Frame types

[edit]
  1. Unconditional frame. These always carry signals and their identifiers are in the range 0 to 59 (0x00 to 0x3b). All subscribers of the unconditional frame shall receive the frame and make it available to the application (assuming no errors were detected).
  2. Event-triggered frame. The purpose of this is to increase the responsiveness of the LIN cluster without assigning too much of the bus bandwidth to the polling of multiple slave nodes with seldom occurring events. The first data byte of the carried unconditional frame shall be equal to a protected identifier assigned to an event-triggered frame. A slave shall reply with an associated unconditional frame only if its data value has changed. If none of the slave tasks responds to the header the rest of the frame slot is silent and the header is ignored. If more than one slave task responds to the header in the same frame slot a collision will occur, and the master has to resolve the collision by requesting all associated unconditional frames before requesting the event-triggered frame again.
  3. Sporadic frame. This frame is transmitted by the master as required, so a collision cannot occur. The header of a sporadic frame shall only be sent in its associated frame slot when the master task knows that a signal carried in the frame has been updated. The publisher of the sporadic frame shall always provide the response to the header.
  4. Diagnostic frame. These always carry diagnostic or configuration data and they always contain eight data bytes. The identifier is either 60 (0x3C), called master request frame, or 61(0x3D), called slave response frame. Before generating the header of a diagnostic frame, the master task asks its diagnostic module if it shall be sent or if the bus shall be silent. The slave tasks publish and subscribe to the response according to their diagnostic module.
  5. User-defined frame. These can carry any kind of information. Their identifier is 62 (0x3E). The header of a user-defined frame is always transmitted when a frame slot allocated to the frame is processed
  6. Reserved frame. These shall not be used in a LIN 2.0 cluster. Their identifier is 63 (0x3F).

LIN hardware

[edit]

The LIN specification was designed to allow very cheap hardware-nodes being used within a network. It is a low-cost, single-wire network based on ISO 9141.[11] In today’s car networking topologies, microcontrollers with either UART capability or dedicated LIN hardware are used. The microcontroller generates all needed LIN data (protocol ...) (partly) by software and is connected to the LIN network via a LIN transceiver (simply speaking, a level shifter with some add-ons). Working as a LIN node is only part of the possible functionality. The LIN hardware may include this transceiver and works as a pure LIN node without added functionality.

As LIN Slave nodes should be as cheap as possible, they may generate their internal clocks by using RC oscillators instead of crystal oscillators (quartz or a ceramic). To ensure the baud rate-stability within one LIN frame, the SYNC field within the header is used.

LIN protocol

[edit]

The LIN-Master uses one or more predefined scheduling tables to start the sending and receiving to the LIN bus. These scheduling tables contain at least the relative timing, where the message sending is initiated. One LIN Frame consists of the two parts: header and response. The header is always sent by the LIN Master, while the response is sent by either one dedicated LIN-Slave or the LIN master itself.

Transmitted data within the LIN is transmitted serially as eight bit data bytes with one start bit, one stop-bit, and no parity (break field does not have a start or stop bit). Bit rates vary within the range of 1 kbit/s to 20 kbit/s. Data on the bus is divided into recessive (logical HIGH) and dominant (logical LOW). The time normally is considered by the LIN Masters stable clock source, the smallest entity is one bit time (52 μs @ 19.2 kbit/s).

Two bus states – sleep-mode and active – are used within the LIN protocol. While data is on the bus, all LIN-nodes are asked to be in the active state. After a specified timeout, the nodes enter sleep mode and will be released back to active state by a WAKEUP frame. This frame may be sent by any node requesting activity on the bus, either the LIN Master following its internal schedule, or one of the attached LIN Slaves being activated by its internal software application. After all nodes are awakened, the Master continues to schedule the next Identifier.

[edit]

The header consists of five parts:

BREAK: The BREAK field is used to activate all attached LIN slaves to listen to the following parts of the header. It consists of one start bit and several dominant bits. The length is at least 11-bit times; standard use as of today are 13-bit times, and therefore differs from the basic data format. This is used to ensure that listening LIN nodes with a main-clock differing from the set bus baud rate in specified ranges will detect the BREAK as the frame starting the communication and not as a standard data byte with all values zero (hexadecimal 0x00).

SYNC: The SYNC is a standard data format byte with a value of hexadecimal 0x55. LIN slaves running on RC oscillator will use the distance between a fixed amount of rising and falling edges to measure the current bit time on the bus (the master's time normal) and to recalculate the internal baud rate.

INTER BYTE SPACE: Inter Byte Space is used to adjust for bus jitter. It is an optional component within the LIN specification. If enabled, then all LIN nodes must be prepared to deal with it.

There is an Inter Byte Space between the BREAK and SYNC field, one between the SYNC and IDENTIFIER, one between the payload and Checksum and one between every Data byte in the payload.

IDENTIFIER: The IDENTIFIER defines one action to be fulfilled by one or several of the attached LIN slave nodes. The network designer has to ensure the fault-free functionality in the design phase (one slave is allowed to send data to the bus in one frame time).

If the identifier causes one physical LIN slave to send the response, the identifier may be called a Rx-identifier. If the master's slave task sends data to the bus, it may be called Tx-identifier.

RESPONSE SPACE: Response Space is the time between the IDENTIFIER field and the first Data byte which starts the LIN RESPONSE part of the LIN frame. When a particular LIN frame is transmitted completely, Header + Response, by the LIN MASTER, the LIN MASTER will use the full RESPONSE SPACE TIME to calculate when to send the response after sending the header. If the response part of the LIN frame is coming from a physically different SLAVE NODE, then each node (master & slave) will utilize 50% of the Response Space time in their timeout calculations.

Response

[edit]

The response is sent by one of the attached LIN slave tasks and is divided into data and checksum.[9]

DATA: The responding slave may send zero to eight data bytes to the bus. The amount of data is fixed by the application designer and mirrors data relevant for the application which the LIN slave runs in.

CHECKSUM: There are two checksum-models available within LIN - The first is the checksum including the data bytes only (specification up to Version 1.3), the second one includes the identifier in addition (Version 2.0+). The used checksum model is pre-defined by the application designer.

Slave node position detection (SNPD) or autoaddressing

[edit]

These methods allow the detection of the position of slave nodes on the LIN bus and allow the assignment of a unique node address (NAD).[12]

  • Allows similar or the same devices to be connected on the bus without end of line programming or connector pin programming.

Restrictions:

  • All auto-addressing slaves must be in one line
    • Standard slaves can be connected in any way
SNPD Method SNPD Method ID Company
Extra wire daisy chain 0x01 NXP (formerly Philips)
Bus shunt method 0x02 Elmos Semiconductor
Reserved 0x03 TBD
Reserved 0x04 TBD
Reserved 0xFF TBD

Extra wire daisy chain (XWDC)

[edit]

Each slave node has to provide two extra pins, one input, D1, and one output, D2.

  • The first SNPD node input D1 is either set to GND or connected to the output of the master.
    • The output of the first node, D2, is connected to the input, D1 of the second node, and so on resulting in a daisy chain.

Each configuration pin Dx (x=1-2) has additional circuitry to aid in the position detection.

  1. Switchable resistive pull-up to Vbat
  2. Pull-down to GND
  3. Comparator referenced to Vbat/2

XWDC auto-addressing procedure

[edit]

At the start of the procedure no SNPD devices have a NAD assigned

1 First auto-addressing LIN message

1.1 All outputs (D2) are set to a high level, all pull-downs are turned off
1.2 The first SNPD node is selected. It is identified by having the input D1 low (hardwired).
1.3 The selected node takes the address from the LIN configuration message
1.4 The detected node turns on the pull-down at the output D2

2 Subsequent auto-addressing LIN messages

2.1 The first non addressed SNPD node is selected. It is identified by having the input D1 low (D2 of previous node).
2.2 The selected node takes the address from the LIN configuration message
2.3 The detected node turns on the pull-down at the output D2
2.4 Steps 2.1-2.4 are repeated until all slave nodes are assigned an address

3 All pull-ups and pull-downs are turned off completing the addressing procedure

Bus shunt method (BSM)

[edit]

Each slave node has two LIN pins

  1. bus_in
  2. bus_out

Each slave node needs some additional circuitry compared to the standard LIN circuitry to aid in the position detection.

  1. The standard pull-up must be switchable
  2. Switchable 2 mA current source from Vbat
  3. Shunt resistor
  4. Differential amplifier
  5. Analog to digital converter

BSM auto-addressing procedure

[edit]

At the start of the procedure, none of the SNPD devices have a NAD assigned. The autoaddressing routine is performed during the sync field. The sync field is broken into three phases:

1 Offset current measurement

1.1 All outputs pull-ups and current sources are switched off
1.2 The bus current is measured, Ioffset

2 Pull-up mode

2.1 Pull-ups are turned on and current sources remain off
2.2 The bus current is measured, IPU
2.3 Nodes with ΔI = IPU-Ioffset < 1 mA are "selected"

3 Current source mode

3.1 Selected nodes switch current source on and others switch pull-ups off
3.2 Bus current is measured, ICS
3.3 Node with ΔI = ICS-Ioffset < 1 mA is detected as the last node
3.4 Current sources are switched off and pull-ups are switched on
3.5 The last node will accept the address contained in the LIN configuration message

This technique is covered by the patents EP 1490772 B1 and US 7091876.

LIN advantages

[edit]
  • Easy to use
  • Components available
  • Cheaper than CAN and other communications buses
  • Harness reduction
  • More reliable vehicles
  • Extension easy to implement.
  • No protocol license fee required

LIN is not a full replacement of the CAN bus. But the LIN bus is a good alternative wherever low costs are essential and speed/bandwidth is not important. Typically, it is used within sub-systems that are not critical to vehicle performance or safety - some examples are given below.

Applications

[edit]
Application segments Specific LIN application examples
Roof Sensor, light sensor, light control, sun roof
Steering wheel Cruise control, wiper, turning light, climate control, radio, wheel lock
Seat Seat position motors, occupant sensors, control panel
Engine Sensors, small motors, cooling fan motors
Grille Grille shutter
Climate Small motors, control panel
Door Mirror, central ECU, mirror switch, window lift, seat control switch, door lock
Illumination Vehicle trim enhancement, sill plates illuminated with RGB LED

Addressing

[edit]

Addressing in LIN is achieved with a NAD (Node ADdress) that is part of the PID (protected identifier). NAD values are on 7bits, so in the range 1 to 127 (0x7F) and it is a composition of supplier ID, function ID and variant ID.

You can obtain a supplier ID by contacting CAN in Automation that is the authority responsible for the assignment of such identifiers.

See also

[edit]

Various vehicle (automotive) connectivity buses:

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Local Interconnect Network

View on Grokipedia
from Grokipedia
The Local Interconnect Network (LIN) is a low-cost, serial bus protocol standardized for low-speed communication in automotive and industrial applications, primarily enabling master-slave interactions between electronic control units (ECUs) in non-safety-critical systems such as body electronics. Developed as a UART-based alternative to more complex networks like CAN, LIN supports deterministic, bidirectional exchange at baud rates typically up to 20 kbps, using a single-master, multi-slave to reduce wiring and costs in vehicles. LIN originated in the late 1990s through the LIN Consortium, formed by major automakers including , , and , to address the need for affordable in-vehicle networking beyond CAN's capabilities. The protocol's first specification, version 1.3, was released in 2002, followed by enhancements in versions (2003), 2.1 (2006), and 2.2A (2010), which introduced features like enhanced checksums and support. International standardization came in 2016 via ISO 17987, which defines the protocol across seven parts covering the OSI layers, conformance testing, and powerline transmission; the standard was updated in 2025 with terminology changes (e.g., "commander" for master, "responder" for slave) and auto-addressing improvements. Complementary guidelines, such as SAE J2602 (updated 2021), provide implementation recommendations for automotive use. At its core, LIN operates on a single-wire physical layer with optional bus termination, transmitting frames consisting of a header (break field, sync byte, and 6-bit identifier with parity) generated by the master, followed by a response (up to 8 data bytes and checksum) from a designated slave. Error detection includes parity checks, checksums (classic or enhanced), and frame monitoring, where slaves abort erroneous responses and signal via a Response_Error bit, ensuring reliability without requiring master-side error handling. The protocol supports unconfirmed communication and aligns with diagnostic services in ISO 14229-2, making it suitable for scheduled, event-triggered messaging in clusters of up to 16 nodes. In automotive contexts, LIN is widely deployed for functions like window controls, seat adjustments, door locks, and climate systems, where low bandwidth (under 20 kbps) suffices and cost savings—through reduced cabling and simpler transceivers—are paramount. Compared to CAN, LIN offers lower implementation costs and easier integration with microcontrollers but lacks CAN's multi-master support and robustness for high-priority safety applications, positioning it as a complementary technology in modern vehicle architectures. Beyond vehicles, LIN finds use in industrial automation and requiring simple, reliable local networking.

Introduction

Overview

The Local Interconnect Network (LIN) is a low-cost serial network protocol designed as a single-master, multiple-slave communication for sub-networks, enabling efficient exchange among distributed components. It operates at baud rates of up to 20 kbit/s with a tolerance of ±1.5% for the master and ±2% for slaves, utilizing a single-wire bus that supports one master node controlling up to 16 slave nodes. This architecture ensures deterministic communication without , as the master schedules all transmissions. In automotive applications, LIN supplements the higher-speed Controller Area Network (CAN) bus by handling non-critical, low-bandwidth tasks such as controlling switches, sensors, and actuators in systems like door modules, seat adjustments, sunroofs, and climate controls. Unlike CAN, which is suited for backbone networks with event-driven messaging, LIN offers a simpler and more economical alternative for local interconnects, reducing wiring complexity and costs without replacing CAN's role in critical functions. LIN employs 12 V logic levels compatible with (UART) or interface (SCI) protocols, where the uses a single wire for bidirectional data transmission referenced to ground. Dominant states (logical 0) are transmitted at approximately 20% of the supply voltage and received at 40%, while recessive states (logical 1) are at 80% transmitted and 60% received, ensuring robust operation in automotive environments. The protocol has evolved through consortium specifications to international standardization under ISO 17987 since 2016.

History

The Local Interconnect Network (LIN) protocol originated in the late 1990s when a consortium of European automakers, including BMW, Volkswagen, Audi, Volvo, and Mercedes-Benz, collaborated with semiconductor supplier Motorola and software firm Volcano Automotive to develop a cost-effective serial communication standard for automotive applications. This initiative addressed the need for a simpler alternative to the Controller Area Network (CAN) for non-critical systems like sensors and actuators, leading to the formation of the LIN Consortium in 1998. The first fully implemented specification, LIN 1.3, was published in November 2002 by the LIN Consortium, establishing the foundational master-slave architecture for low-speed, single-wire communication in vehicles. Subsequent releases built on this base: LIN 2.0 in September 2003 introduced key enhancements such as sleep and wake-up mechanisms to support low-power operation in automotive clusters. LIN 2.1 followed in 2006, improving diagnostic capabilities through standardized services for fault detection and configuration. By 2010, LIN 2.2A added support for fractional baud rates and enhanced scheduling options to accommodate diverse timing requirements in complex networks. In 2016, responsibility for LIN standardization shifted from the disbanded LIN Consortium to the (ISO), resulting in the ISO 17987 series, with LIN 2.2A serving as the basis for the initial release. This transition ensured global harmonization and ongoing evolution. In 2019, ISO 17987-8 specified the DC-LIN variant, enabling LIN transmission over DC powerlines without dedicated signaling wires to reduce cabling complexity. As of 2025, updates to parts of the ISO 17987 series, including ISO 17987-2 (transport protocol), ISO 17987-3 (), and others, incorporate inclusive language, additional auto-addressing methods, and refinements to specifications for improved compliance and seamless vehicle network integration. The CAN in Automation (CiA) now acts as the for LIN supplier IDs on behalf of ISO, managing identifier assignments to support .

Physical Layer

Network Topology

The Local Interconnect Network (LIN) employs a single-wire bus topology, consisting of one master node and up to 15 slave nodes connected in a linear or daisy-chain arrangement, with the master typically positioned at one end of the bus to facilitate centralized control in automotive environments. This configuration supports a total of 16 nodes per cluster, minimizing wiring complexity while enabling distributed control of non-critical vehicle functions such as window lifters or mirror adjustments. Wiring in a LIN network utilizes a single unshielded wire with a cross-sectional area of 0.35–0.5 mm², connected in parallel across all nodes alongside shared ground (GND) and (VBAT) lines. Termination is achieved with a 1 kΩ pull-up resistor at the master node to define the recessive (high) state, while each slave incorporates an internal 30 kΩ , ensuring proper signal levels without additional external components beyond the master. The bus is powered directly from the vehicle's 12 V battery (or 24 V in heavy-duty applications), with slave nodes drawing minimal quiescent current (typically under 1 mA) to integrate seamlessly with the automotive electrical system. Optional suppression components, such as capacitors or filters, may be added to mitigate (EMI) in noisy vehicle settings. Maximum bus length is limited to 40 meters at standard rates of 9600 to 19.2 kbps, with shorter distances required at higher speeds up to 20 kbps to maintain and below 10 nF. is enhanced through the master's continuous monitoring of bus voltage levels, enabling detection of open-circuit conditions (resulting in a floating high state) or short-circuits (stuck-at-low), which trigger protective modes or error reporting without disrupting the entire network.

Hardware Components

The master node in a Local Interconnect Network (LIN) typically consists of a integrated with a LIN that complies with the ISO 17987 standard, enabling it to manage message scheduling and bus . Microcontrollers such as the Microchip PIC18 or STM8 series are commonly used for this purpose, interfacing with the transceiver via a UART or SCI module to generate rates up to 20 kbit/s. Slave nodes employ simpler hardware configurations, often integrating low-cost transceivers like the NXP TJA1020 directly into sensors or actuators to minimize complexity and power consumption. These transceivers support low-power modes with quiescent currents as low as 1–8 µA, facilitating efficient wake-up mechanisms in battery-powered applications. LIN transceivers operate on a single-wire bus with recessive (idle) voltage levels near the battery supply (typically 12 V), where a high state exceeds 60% of VBAT and a low (dominant) state approaches ground potential (below 40% of VBAT). To reduce (EMI), transceivers incorporate control, limiting signal edge transitions to 12–27 µs in normal mode or 30–62 µs in low-slope mode. Baud rate timing is derived from the microcontroller's UART/SCI output, ensuring synchronization across nodes at rates up to 20 kbit/s. Additional components, such as optional capacitors (e.g., 1 nF for master nodes or 220 pF for slaves), enhance bus stability by filtering and supporting transient protection. Many transceivers include built-in diagnostic features, like detection for fault identification, to aid in network reliability. All LIN hardware must adhere to ISO 17987-4 for electrical characteristics, including 12 V operation, immunity, and bit timing accuracy, ensuring in automotive environments.

Protocol Specification

Message Frame

The Local Interconnect Network (LIN) message frame is the fundamental unit of data exchange in the protocol, consisting of a header transmitted by the master node followed by a response transmitted by a designated slave node or, in some cases, the master itself. The header initiates the frame and identifies the message, while the response carries the actual . This master-slave division ensures deterministic communication without on the single-wire bus. The header comprises three main parts: a sync break field, a sync field, and a protected identifier field. The sync break is a prolonged dominant (low) signal lasting at least 13 bits, followed by a recessive (high) bit, to signal the start of the frame. The sync field is an 8-bit pattern of 0x55 (alternating 0 and 1 bits), and the protected identifier is an 8-bit field containing a 6-bit identifier plus 2 parity bits. Each byte in the frame, including the sync and identifier fields, is encoded as a 10-bit serial frame (1 start bit, 8 bits, 1 stop bit). The response consists of 1 to 8 bytes followed by an 8-bit byte, also each as 10-bit frames, allowing a maximum response length of 9 bytes. Frame variants, such as unconditional or event-triggered, build on this basic structure but are detailed separately. Timing parameters are critical for reliable operation at the standard baud rate of 20 kbit/s, where each bit duration is 50 µs. The nominal header transmission time is 34 bit times, or approximately 1.7 ms, accounting for the sync break (minimum 14 bit times), sync field (10 bit times), and protected identifier (10 bit times). The response transmission time varies with data length, nominally 10 bit times per byte plus the , up to about 4.5 ms for 8 data bytes; the maximum allowed duration is 1.4 times the nominal to accommodate minor variations. Between bytes in the response, there is no mandatory inter-byte space, as frames are sent back-to-back, but the master monitors for timely completion with a timeout mechanism. These timings ensure frames fit within schedule table slots, typically 5 to 20 ms. Synchronization within the frame relies on the sync break and sync field to align the slave nodes' clocks to the master's without requiring dedicated oscillators in slaves. The sync break's extended low period wakes and resets receivers, while the sync field's alternating pattern allows slaves to measure the bit time precisely using multiple falling edges, achieving baud rate with a tolerance of ±2%. This mechanism supports the low-cost design by enabling slaves to derive timing from the bus signal. Checksums provide error detection for the response data, with two types defined in the protocol. The classic , used in LIN version 1.x and for certain diagnostic frames, is an 8-bit value calculated as the inverted sum (modulo 256) of the data bytes only, including carry-over from addition. The enhanced checksum, introduced in LIN and standard for version 2.x, extends this by including the protected identifier in the sum, improving protection against identifier errors. Both are appended as the final byte of the response, and the receiver verifies by recalculating and comparing; no polynomial-based checksum is specified in the core protocol. Frame error handling is primarily managed by the master, which detects issues such as no response, mismatch, or timing violations through built-in monitoring. In event-triggered frames, if multiple slaves have updates and attempt to respond simultaneously, a collision occurs on the bus. Slaves detect conflicts via bit monitoring and abort transmission. The master detects the and resolves the collision by executing a dedicated collision-resolving schedule table to poll the individual unconditional frames. Timeouts occur if the response exceeds 1.4 times the nominal time or if inactivity persists (e.g., 1000 ms default for certain modes), prompting the master to abort the frame and potentially retry in the next slot. These mechanisms, aligned with ISO 17987-3, ensure robust operation without complex .

Frame Types

The Local Interconnect Network (LIN) protocol defines several frame types to accommodate different communication needs in automotive applications, each distinguished by their triggering mechanisms, response expectations, and integration into the network schedule. These types ensure efficient, low-cost data exchange between the master node and multiple slave nodes, with the master always initiating transmission by sending a header. Unconditional frames are the most common type, where the master sends a header with a protected identifier in the range 0x00 to 0x3B, and a specific slave node—designated as the publisher—responds with the data , such as readings, while other nodes act as subscribers to receive the information. This frame type guarantees periodic transmission regardless of data changes, providing reliable signal updates in a fixed schedule. Event-triggered frames enable dynamic responses to sporadic events by allowing the master to poll multiple potential publisher slaves using a single header with an identifier in the range 0x00 to 0x3B; multiple slaves may be assigned as potential publishers for an event-triggered frame. Each slave responds if it detects a relevant signal change. If multiple slaves respond simultaneously, a collision occurs, which is resolved by the master executing a dedicated collision-resolving schedule table. Sporadic frames group one or more unconditional frames and are transmitted on-demand only when an associated signal update occurs, serving low-priority messages without a fixed ; the master prioritizes the highest-priority pending frame from the group if multiple updates are detected. Diagnostic frames support fault detection and network management using a publisher-subscriber model, with fixed identifiers 0x3C for master requests and 0x3D for slave responses; these always carry 8 data bytes formatted for protocols, enabling multi-frame diagnostic messages. Null frames are master-initiated transmissions with no expected slave response, often used for network wake-up or as placeholders to halt ongoing communications without data exchange. In LIN versions 2.0 and later, these frame types are integrated into master-managed scheduling tables, which group frames for periodic execution based on a configurable time base (e.g., 5 ms or 10 ms slots), allowing seamless switching between normal operation, diagnostics, and configuration modes while ensuring deterministic latency. The LIN header, transmitted solely by the master node, initiates each message frame on the bus and enables slave nodes to synchronize and identify the intended communication. It comprises three distinct fields: the synchronization break, the synchronization field, and the protected identifier. This structure ensures reliable detection and timing alignment in the low-cost, single-wire network environment. The break begins the header as a prolonged dominant (low) pulse, lasting at least 13 bit periods at the nominal baud rate, which demarcates the frame start and awakens any sleeping slave nodes by overriding their recessive idle state. Immediately following a brief recessive (high) transition period, the field transmits an 8-bit byte with the fixed value 0x55 (binary 01010101). This alternating bit pattern facilitates precise bit-time measurement by slave nodes, allowing them to adjust their internal clocks to match the master's baud rate for subsequent data reception. The protected identifier field, an 8-bit value transmitted last in the header, encodes the frame's purpose while incorporating detection. It consists of a 6-bit identifier (ID bits ID5–ID0, ranging from 0 to 63 in decimal) augmented by two parity bits (P1 and P0). The ID value specifies the message's intent as defined in the LIN Description File (LDF). IDs 0–59 are used for unconditional, event-triggered, or sporadic frames; 60 and 61 for diagnostic frames; 62–63 are reserved. The parity bits are computed to detect transmission errors: P0 provides even parity over ID0, ID1, ID2, and ID4 via the P0=ID0⊕ID1⊕ID2⊕ID4P0 = ID0 \oplus ID1 \oplus ID2 \oplus ID4, while P1 ensures odd parity over ID1, ID3, ID4, and ID5 using P1=¬(ID1⊕ID3⊕ID4⊕ID5)P1 = \neg (ID1 \oplus ID3 \oplus ID4 \oplus ID5). Slave nodes validate these parities before processing the frame. The master generates the header with a rate accuracy typically limited to ±0.5% clock tolerance, supporting an overall network rate deviation of up to 2% between master and slaves to maintain reliable communication. The protected identifier's 8-bit length, combined with the preceding fields, totals a fixed overhead that minimizes latency in LIN's time-triggered scheduling.

Response

The response in a Local Interconnect Network (LIN) message frame consists of 1 to 8 bytes followed by a single byte, resulting in a total length of 2 to 9 bytes transmitted by the designated slave node or, in some cases, the master node. The number of bytes is defined in the LIN Description File (LDF) associated with the frame identifier. For instance, simple switch states, such as door lock positions, typically use a 1-byte field to encode binary on/off values, while more complex signals like window lift positions may employ 2 to 4 bytes to represent position percentages, direction, or status combinations. LIN employs a publisher-subscriber model for the response , where a single publisher node (usually the slave associated with the ID) is responsible for generating and transmitting the bytes, while multiple subscriber nodes on the bus can receive and utilize the information without responding. This model ensures efficient, event-driven communication, with the publisher's content defined in the LIN Description File (LDF) for each ID, allowing subscribers to process the independently of transmission duties. The checksum byte appended to the data field provides error detection for the response. In the classic format, used in LIN version 1.3 and for certain diagnostic frames, the checksum is calculated as the (inverted value) of the sum of the data bytes modulo 256, covering only the data bytes to maintain . For LIN versions and later, the enhanced checksum format is standard, computed similarly as the inverted sum modulo 256 but including the protected ID (derived from the header ID) along with the data bytes, which helps prevent false error detections from ID-related transmission issues without requiring the ID to be retransmitted in the response. If a slave node is unable to generate a valid response, it does not transmit, allowing the master to detect the through the absence of a response or validation failure. The master node validates the response by verifying the against the expected value (based on the received data and ID for mode) and confirming the data length matches the frame definition; any mismatch triggers an , such as the "Error in Response" status bit, enabling network diagnostics without halting the bus.

Node Addressing and Configuration

Addressing Scheme

In the Local Interconnect Network (LIN) protocol, the addressing scheme primarily revolves around the Node Address (NAD), an 8-bit identifier used to uniquely distinguish responder nodes, particularly for diagnostic and configuration purposes. Each responder is assigned a unique NAD during network setup, typically ranging from 0x01 to 0x7F to avoid reserved values such as 0x00 (often for commands), 0x7E (functional addressing), and 0x7F (broadcast or wildcard). This static assignment is performed via configuration tools or non-volatile memory like , ensuring each responder's capabilities and signal responsibilities are mapped accordingly. The NAD is integrated with the LIN Description File (LDF), which defines the network , node capabilities via Node Capability Files (NCF), and specific signal assignments tied to each responder's . Responders do not use their NAD for routine signal communication; instead, they respond to messages based on the Protected Identifier (PID) in the frame header, which the schedules deterministically. The node, lacking a dedicated NAD, is identified by its role in initiating all frames and is often implicitly associated with 0x00 in diagnostic contexts or omitted entirely from addressing mechanisms. Conflict resolution in addressing is managed statically during configuration rather than dynamically at runtime, as the commander-responder architecture eliminates needs by granting the commander exclusive control over bus access. No protocol-level mechanisms exist for runtime address collisions; instead, uniqueness is enforced through LDF validation and tools that prevent duplicates. In LIN 2.1 and later versions, enhancements include conditional NAD changes—allowing targeted reassignments via diagnostic services like Assign NAD or Conditional Change NAD—improving flexibility for network reconfiguration while maintaining .

Slave Node Position Detection

Slave Node Position Detection (SNPD) is a feature in Local Interconnect Network (LIN) systems that enables automatic assignment of unique node addresses to responder nodes based on their physical position within the network topology, particularly in daisy-chain configurations. This method eliminates the need for manual configuration tools such as dip switches or programming devices, allowing identical responder nodes to self-identify their sequence from the commander (e.g., as the first, second, or subsequent responder). By leveraging additional signals, bus current measurements, or switch mechanisms during initialization, SNPD ensures that each responder receives a distinct Node Address (NAD) mapped to its position, facilitating seamless integration into the LIN Description File (LDF) for protocol compliance. The primary purpose of SNPD is to automate addressing in multi-responder LIN clusters, reducing installation complexity and errors in automotive applications where nodes like sensors or actuators are deployed in series. For instance, during network startup, the initiates a detection sequence where responders sequentially respond based on propagated signals or differential currents, assigning positions without prior knowledge of the network layout. This approach supports plug-and-play functionality, as new or replacement nodes can automatically detect their position upon connection, enhancing system reliability in dynamic environments. Key benefits include , where the removal or failure of an intermediate responder does not disrupt position detection for downstream nodes, as the process can restart or adapt via commander commands. Additionally, SNPD promotes easier and scalability in daisy-chain setups, minimizing wiring and configuration time compared to static addressing methods. These advantages are particularly valuable in cost-sensitive applications, enabling up to 15 responders per cluster without individual hardware differentiation. SNPD is an optional feature applicable in LIN 2.1 and later specifications, where it is defined as a recommended practice for position-based ID mapping within the LDF, allowing responders to operate in mixed networks with standard nodes. Implementation notes from the LIN Consortium outline its use in automotive sub-bus systems, ensuring compatibility with ISO 17987 standards for vehicle communication. The ISO 17987:2025 update includes improvements to auto-addressing methods, enhancing SNPD flexibility and compatibility. Despite its advantages, SNPD requires specific hardware support, such as integrated current sensors, switches, or additional pins (e.g., SNPD_IN/OUT interfaces), which may increase component costs and design complexity. It is primarily suited for linear or daisy-chain topologies and is not compatible with all layouts, such as configurations, potentially limiting its use in diverse architectures. Furthermore, environmental factors like can affect detection accuracy in some methods, necessitating robust transceivers.

Extra Wire Daisy Chain

The Extra Wire Daisy Chain (XWDC) method enables automatic detection of responder node positions in a Local Interconnect Network (LIN) by using an additional dedicated wire to connect responder nodes in a serial chain, allowing sequential addressing without relying on the main LIN bus. This approach is part of the Slave Node Position Detection (SNPD) feature introduced in LIN 2.1 and later specifications. Each responder node requires two extra pins: an input pin (D1) and an output pin (D2). The D1 pin of the is connected to ground or the commander's output, while the D2 pin of each responder links to the D1 pin of the subsequent responder, forming the daisy chain alongside the standard LIN bus wiring. This setup ensures that only unconfigured responders can be selected in order, propagating the addressing signal through the chain. The procedure begins with the commander sending an SNPD initialization frame (Subfunction ID 0x01) over the LIN bus, prompting all responders to enable pull-up resistors on their D1 inputs (5–30 kΩ) and disable their D2 output drivers, setting the chain to a high state. For default direction addressing (Subfunction ID 0x02), the commander transmits an Assign NAD frame (header 0x3C) with the desired node address. The first unconfigured responder detects a low level on its D1 input (below 0.4 times supply voltage, 7–18 V), accepts the NAD, configures itself, and pulls its D2 output low to activate the next responder's D1. This propagation continues sequentially until all responders (up to 15 in a standard LIN network) are addressed, after which the commander sends a finish frame (Subfunction ID 0x04) to disable pull-ups and drivers. An optional reverse direction subfunction (ID 0x03) allows addressing from the last responder backward if needed. Responders sample the D1 input 50 µs after the LIN frame ends, with output level changes on D2 required within 100 µs to ensure settling before the next frame. Hardware implementation is straightforward, using basic digital input/output pins on responder transceivers or microcontrollers, along with the specified pull-up resistors and low-capacitance lines (≤1 nF per node, ≤8 nF total chain) to minimize delays. No complex counters or RC circuits are mandated, though simple timing logic ensures reliable low-state detection. The extra wire can be a standard automotive-grade conductor routed parallel to the LIN bus, adding minimal cost and complexity. Timing constraints align with LIN frame durations, enabling the full chain configuration in under a second for typical networks. This method offers low implementation cost due to its reliance on passive components and existing node pins, avoids any loading or interference on the LIN bus, and operates fully independently of the LIN physical and protocol layers, ensuring compatibility with LIN 2.1 and subsequent revisions. It supports robust diagnostics and plug-and-play node installation in automotive applications.

Bus Shunt Method

The Bus Shunt Method (BSM) is a technique for Slave Node Position Detection (SNPD) in Local Interconnect Network (LIN) systems, enabling automatic assignment of unique node addresses to identical responder nodes without additional wiring beyond the standard LIN bus. This method relies on measuring bus currents through integrated shunt resistors in each responder to determine their sequential positions along the bus . In the setup, each BSM-compatible responder node incorporates a low-value shunt , typically 0.65–1.25 Ω, connected between its BUS_IN and BUS_OUT pins to route the LIN bus signal through the node. The commander node monitors the cumulative effects of these shunts by injecting controlled currents onto the bus and measuring resulting voltage drops, allowing it to count and identify node positions from the farthest to the nearest. This configuration supports integration with standard LIN responders, as the shunts introduce minimal impedance change under normal operation. The procedure begins with the initiating SNPD by transmitting a specific LIN frame (subfunction 0x02) containing a break field to synchronize nodes. Unassigned responders activate their shunt and associated current sources in a timed across seven steps, where the injects currents (e.g., I_CS_1 at 1–1.24 mA and I_CS_2 at 3.15–3.85 mA) and records shunt currents (I_shunt_1, I_shunt_2, I_shunt_3). The farthest responder is pre-selected when the difference I_shunt_2 - I_shunt_1 falls below a threshold (I_Diff of 2.3–2.9 mA), and it self-assigns the first upon confirming I_shunt_3 - I_shunt_1 < I_Diff, then deactivates its shunt to allow the process to propagate to the next node. This iterative detection continues until all responders are addressed, with the verifying the total node count. Hardware implementation requires BSM responders with integrated transceivers featuring switchable current sources, a differential amplifier for precise current-to-voltage conversion, and the shunt resistor. The commander must include an analog-to-digital converter (ADC) with sufficient resolution (e.g., 10-bit) to measure microampere-level current variations across the bus. These components ensure compatibility with LIN 2.1 and higher specifications, as defined by the LIN Consortium. Timing for the method aligns with LIN bit periods (T-Bit), with measurements occurring at intervals such as the falling edge for Step 1 and 2 T-Bit for Step 2, culminating in an overall analysis window of approximately 120 µs per node to accommodate bus propagation delays. This supports up to 15 BSM responders in a single network, though practical limits may be lower (8–16 nodes) depending on cable capacitance and total bus length. A key advantage of the Bus Shunt Method is its elimination of extra wiring, leveraging the existing LIN bus for position detection and simplifying and assembly in automotive applications. However, it exhibits drawbacks such as heightened sensitivity to cable lengths, which can distort current measurements due to reflections, and reduced tolerance to ground or supply voltage shifts (e.g., 6.98% ground shift immunity with 15 shunts).

Advantages and Applications

Advantages

The Local Interconnect Network (LIN) offers substantial cost-effectiveness through its single-wire architecture and low pin-count integrated circuits, which significantly reduce the complexity and weight of wiring harnesses compared to traditional parallel wiring schemes. This design significantly reduces wiring requirements in non-critical subsystems, lowering material and manufacturing expenses while minimizing vehicle weight. Additionally, the absence of licensing fees and the use of inexpensive nodes further decrease implementation costs to under $0.50 per node. LIN's simplicity stems from its master-slave , which eliminates the need for bus and collision resolution, thereby reducing protocol overhead and software . This deterministic polling mechanism allows straightforward integration with microcontrollers via standard UART interfaces, requiring minimal resources such as less than 8 KB ROM and 256 bytes RAM per node. Reliability in LIN is enhanced by robust error detection mechanisms, including checksums for and timeouts for , ensuring predictable operation in noisy environments. Furthermore, the protocol's low data rates and controlled slew rates—typically between 1 and 3 V/µs—minimize (EMI), improving noise tolerance without additional shielding. Power efficiency is a key strength of LIN, with nodes capable of entering a that consumes less than 10 µA, enabling extended battery life in standby conditions. Wake-up functionality is supported directly via the bus through a dominant signal lasting 250 µs to 5 ms, allowing efficient reactivation without dedicated power lines. LIN provides scalability as a low-cost supplement to higher-speed networks like CAN in distributed automotive systems, handling non-safety-critical tasks while supporting data rates up to 20 kbit/s over a single wire without requiring transformers or complex cabling. This hierarchical integration enables up to 16 nodes per cluster (one master and 15 slaves), facilitating expansion in multi-bus architectures.

Applications

The Local Interconnect Network (LIN) is predominantly deployed in automotive applications for cost-effective communication in non-critical body electronics sub-networks. Primary uses include door modules, where LIN controls window lifts, central locking mechanisms, and mirror adjustments, enabling synchronized operations without high-bandwidth demands. Seat control systems leverage LIN for position adjustments and memory functions, while climate control subsystems, such as HVAC flap actuators, use it for precise regulation based on inputs. Interior and exterior networks, including switch interfaces for headlights and ambient illumination, also rely on LIN for simple on/off and dimming commands. Secondary automotive applications extend LIN to steering wheel controls for multifunction buttons handling audio, , and wiper operations, as well as mechanisms and trunk release systems for remote activation. These sub-networks often integrate with central body control modules (BCMs), where LIN serves as a subordinate bus to higher-speed protocols like CAN, facilitating efficient data routing for comfort features. Beyond vehicles, LIN finds adoption in non-automotive sectors requiring low-cost serial links, such as industrial sensor networks for monitoring environmental parameters in equipment and home appliances for coordinating device states like thermostats and lighting controls. LIN's includes its integration in modern electric vehicles (EVs), where LIN 2.x supports auxiliary battery management tasks, such as monitoring voltage and current in 12V systems via dedicated s, complementing high-voltage main batteries. The DC-LIN variant, defined in ISO 17987-8, enables LIN communication over DC powerlines for diagnostic purposes, reducing wiring complexity in harnesses without dedicated signal lines. Notable case studies highlight LIN's longevity; BMW implemented LIN in door networks starting with the 2000 X5 (E53) model for mirror and module communications, establishing it as a standard for body electronics. By 2025, LIN adoption has expanded to advanced driver assistance systems (ADAS) peripherals, including parking assist and blind-spot detection interfaces, driven by demand for affordable sensor-actuator links in Level 2+ autonomy features.

References

  1. https://www.lin-cia.org/standards/
  2. https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/introduction-to-the-local-interconnect-network-lin-bus.html
  3. https://blog.ansi.org/ansi/local-interconnect-network-lin/
  4. https://www.ti.com/lit/slla383
  5. https://www.st.com/resource/en/application_note/an1278-lin-local-interconnect-network-solutions-stmicroelectronics.pdf
  6. https://community.nxp.com/t5/NXP-Tech-Blog/101-Local-Interconnect-Network-LIN/ba-p/1284877
  7. https://www.csselectronics.com/pages/lin-bus-protocol-intro-basics
  8. https://kvaser.com/about-can/can-standards/linbus/
  9. https://lipowsky.com/downloads/Software/LIN-Basics_for_Beginners-EN.pdf
  10. https://www.lin-cia.org/about-us/
  11. https://www.nxp.com/docs/en/data-sheet/MC33399.pdf
  12. https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ApplicationNotes/ApplicationNotes/00235a.pdf
  13. https://www.st.com/resource/en/application_note/an4101-lin-communication-with-stm8adiscovery-stmicroelectronics.pdf
  14. https://www.nxp.com/docs/en/data-sheet/TJA1020.pdf
  15. https://www.iso.org/standard/85128.html
  16. https://www.mouser.com/datasheet/2/302/MC33662-3138868.pdf
  17. https://www.lin-cia.org/fileadmin/microsites/lin-cia.org/resources/documents/LIN_2.2A.pdf
  18. https://www.lin-cia.org/fileadmin/microsites/lin-cia.org/resources/documents/LIN-Spec_Pac2_1.pdf
  19. https://developerhelp.microchip.com/xwiki/bin/view/applications/lin/data-link-layer/
  20. https://www.renesas.com/en/document/apn/r8c2x-series-lin-quick-facts-frequently-asked-questions
  21. https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf
  22. https://lin-cia.org/fileadmin/microsites/lin-cia.org/resources/documents/Bus_Shunt_Revision_1.pdf
  23. https://www.ti.com/lit/pdf/slda038
  24. https://lin-cia.org/fileadmin/microsites/lin-cia.org/resources/documents/LIN_Switch_Revision_1_0.pdf
  25. https://lin-cia.org/fileadmin/microsites/lin-cia.org/resources/documents/Daisy_Chain_Revision_1.pdf
  26. https://www.nxp.com/docs/en/data-sheet/MC33662.pdf
  27. https://ww1.microchip.com/downloads/en/Appnotes/doc1637.pdf
  28. https://www.ijert.org/design-and-implementation-of-a-lin-driver-in-autosar-architecture
  29. https://www.onsemi.com/download/data-sheet/pdf/ncv7380-d.pdf
  30. https://www.ni.com/docs/en-US/bundle/ni-xnet/page/lin-sleep-and-wakeup.html
  31. https://www.logic-fruit.com/blog/can/can-lin-and-flexray-explained/
  32. https://www.nxp.com/docs/en/product-selector-guide/SG2034.pdf
  33. https://www.embien.com/automotive-insights/automotive-lin-bus-introduction-to-local-interconnect-network
  34. https://resources.altium.com/p/serial-communications-protocols-can-and-lin
  35. https://www.nxp.com/products/MM912_637
  36. https://automotivetechinfo.com/2018/02/bmw-network-marriage-convenience/
  37. https://www.skyquestt.com/report/automotive-lin-transceivers-market
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.