My work has long focused on CAN Bus and SAE J1939, but I was curious to learn more about LIN Bus and the reasons behind its development. Why did the automotive industry need another communication network when CAN was already well established? Exploring that question led me to LIN’s simpler design, lower cost, and role in connecting devices that do not require CAN’s capabilities. This post reflects what I learned and explains how these two technologies complement each other.
CAN and LIN: Different Roles in Automotive Networks
CAN Bus and LIN bus frequently appear together in automotive electronics, but they serve different requirements. CAN provides communication between electronic control units that need reliable message exchange, priority handling, and relatively high data rates. LIN provides an economical way to connect simpler devices whose communication needs are much more modest.
LIN was developed specifically for automotive applications, where adding a full CAN interface to every small sensor, switch, or actuator could introduce unnecessary expense. CAN also originated in the automotive industry, but its use expanded into industrial automation, medical equipment, marine electronics, and many other areas. The distinction is therefore one of design priorities and application scope: LIN was created for inexpensive local automotive networks, while CAN became a broadly adopted communication technology.
Why LIN Was Created
Consider the communication requirements of an electrically adjustable mirror. Its controller may need to receive a position command and report a few status values. A ventilation flap actuator has similarly limited needs: move to a requested position and indicate whether that position has been reached.
These functions do not require large amounts of data or particularly high communication speeds. Nevertheless, connecting each device through CAN requires a CAN controller, a suitable transceiver, and the associated wiring and software.
LIN, short for Local Interconnect Network, was developed to address this situation. It provides a standardized, low-cost network for devices that do not need CAN’s capabilities. Its intended role was to complement CAN within the vehicle, allowing manufacturers to select a communication system appropriate to each subsystem. Typical applications include mirrors, seats, door electronics, and climate-control actuators.
How LIN Keeps Costs Down
LIN’s cost advantage comes from several design decisions working together.
First, LIN uses one communication wire referenced to ground. Conventional high-speed CAN uses two communication wires, CAN_H and CAN_L, with differential signaling. LIN can therefore reduce communication wiring and connector requirements. The single-wire description applies to the communication connection; LIN devices still need power and ground.
Second, LIN communication can be implemented using a microcontroller’s UART, supported by suitable software or dedicated LIN features. A LIN transceiver is still required to connect the microcontroller to the physical bus. This allows inexpensive microcontrollers to serve as network nodes without requiring a CAN controller.
Third, responding LIN nodes can synchronize their communication timing from the header transmitted by the controlling node. Suitable implementations can consequently avoid a separate precision crystal or ceramic resonator at each responding node. Across the many small devices installed in a vehicle, these component savings become significant.
Different Ways of Sharing the Bus
CAN and LIN also differ in how they decide when a device may transmit.
CAN uses message-based arbitration. Multiple nodes can attempt to transmit when the bus becomes available. If transmissions begin simultaneously, the arbitration process determines which message continues according to its identifier. The other nodes wait and try again without corrupting the winning message.
LIN uses one commander node, traditionally called the master, to organize communication. It transmits message headers according to a schedule, and the designated publisher supplies the response. Depending on the frame, that publisher may be the commander itself or another node.
This arrangement removes the need for CAN-style arbitration and makes routine communication predictable. It also means that the schedule must provide suitable opportunities for commands and status updates. A device’s response time depends partly on when its information is scheduled for transmission.
Speed and Data Capacity
LIN supports communication rates up to 20 kbit/s. That is modest, but entirely adequate for many switches, sensors, and small actuators. A ventilation flap does not need a high-speed network to receive an occasional position command.
Classical CAN supports bit rates up to 1 Mbit/s, subject to network length and physical design. CAN FD increases available throughput by permitting a faster data phase and expands the maximum data payload from eight bytes to 64 bytes per frame. These capabilities make CAN more suitable when numerous devices must exchange information frequently or transfer larger amounts of data.
The additional capacity carries additional implementation requirements. Where only a few bytes need to move at modest intervals, LIN’s lower performance can be an appropriate engineering choice.
CAN and LIN at a Glance
The CAN wiring comparison refers to conventional high-speed CAN; other CAN physical-layer variants exist.
How They Work Together
A vehicle can use CAN to connect its main control units while using LIN for smaller groups of local devices. A control unit equipped with both interfaces acts as the connection between the two networks. Texas Instruments describes this use of LIN as a sub-bus for CAN as a common application.
For example, a climate-control unit could receive information over CAN and control several ventilation flap actuators over LIN. The climate-control unit translates the required actions into scheduled LIN messages and collects status information from the actuators.
The two buses remain electrically and logically separate. Connecting them requires a controller that understands both interfaces and implements the necessary application behavior. A LIN transceiver alone cannot convert LIN messages into CAN messages.
Automotive Origins, Different Reach
Both technologies have automotive roots, but their subsequent roles differ. CAN developed into a communication foundation for many industries, supported by higher-layer protocols that define how devices exchange application data. Its adoption extends well beyond passenger vehicles.
LIN remains closely associated with the automotive requirement that motivated its creation: connecting numerous inexpensive devices without giving every device a more capable network interface than it needs. Its use is not technically restricted to vehicles, but automotive subsystems remain its principal application area.
Choosing between CAN and LIN therefore starts with the application’s communication requirements. CAN offers greater capacity and flexibility. LIN offers an economical solution for simple, scheduled communication. Within a vehicle, combining them allows each function to use the network best suited to its needs.
For more technical background information see Introduction to the Local Interconnect Network (LIN) Bus.