You are here

LIN - Local Interconnect Network

The LIN is a new bus technology which brings a more possibilities. The main field of usability is the vehicle industry. It should be considered as the low-cost alternative to a CAN (Controlled Area Network) bus. The both - CAN and LIN - are usable in several industries not only in the car industry. The low-cost and wide applicability has been the main reason for the LIN development. The LIN bus seems like a good solution and we can expect a big advancement of the technology.


The LIN is the serial asynchronous bus based on a very simple idea - there is only a single wire to connect all devices in the vehicle. The LIN supports no so high bandwidth and no so long cables as more expensive bus technologies. There are the typical applications in the car: controlling of a wing mirror, windows, seats, lights, doors, steering wheel. It means all devices which are mostly not connected because of the other buses cost. The other buses are most expensive for this use. The next picture shows the comparison between the LIN and the other communication interfaces.

Fig.1: Bandwidth of LIN and other protocols

Summary of the LIN features

  • single master with multiple slaves concept
  • low cost silicon implementation based on common UART/SCI interface hardware, an equivalent in software, or as pure state machine
  • self synchronization without a quartz or ceramics resonator in slave nodes
  • low cost single-wire implementation
  • speed up to 20 kbit/s

Summary of the CAN features

  • multi-master conception, each node can be a master point
  • multicast reception with time synchronization
  • multicast reception with time synchronization - quartz oscillator is required
  • guarantee of latency times and system flexibility
  • speeds up to 1 Mbit/s (depending on bus length)

The LIN is derived from the single-wired standard ISO 9141 which is mostly used in diagnostic devices and has a few enhancements. The LIN standard includes the specification of the transmission protocol, the transmission medium, the interface between development tools and the software programming interface.

LIN layers

Fig.2: Structure of LIN layers

These layers are quite different in the CAN...

  • The Object layer - concerned with messages (message filtering, message and status handling)
  • The Transfer layer - represents the kernel of the CAN protocol (timing, transfer rate, error detection, arbitration)
  • The Physical layer - defines how signals are actually transmitted (signal level and bit representation, transmission medium)


A cluster consists of one master task and several slave tasks. In the master node we can find the both tasks - master and slave, in a slave node is the slave task only.

Fig.3: Structure of master and slave nodes in LIN


  • defining transmission speed
  • sending synchronization pulse
  • data monitoring
  • switching slave nodes to sleep/wake up mode


  • waiting for synchronization pulse
  • synchronizing using synchronization pulse
  • digesting message identifier

The LIN is different from the CAN which has a multi-master structure. It means any node might be the master node - every unit (node) may start to transmit a message when the bus is free.


There are two types of data messages in the network. The first one is the signal message (data which are sent in the data frame). The second one is the diagnostic message.

The CAN bus manages 4 basic messages

  • Data frame - includes the Standard frame (CAN 2.0A specification - length of 11 bits) and the Extended frame (CAN 2.0B specification - length of 29 bits).
  • Remote Frame - a station acting as a receiver for certain data can initiate the transmission using this frame
  • Error Frame - error signalization on a CAN bus, consists of two different fields - the error flag and the error delimiter
  • Overload Frame - contains the two bit fields - the overload flag and the overload delimiter


A frame consists of a header and a response. Headers are situated in a master task, contains breaks, synchronization pattern and identifier which has a specific signification. A response contains data and checksum fields. The slave task is connected to the identifier and receives the response, verifies the checksum and uses the data transport.

Fig.3: Structure of master and slave nodes in LIN

The system of headers and responses has a lot of advantages, for example :

System flexibility: Nodes can be added to the LIN cluster without requiring hardware or software changes in other slave nodes.

Message routing: The content of a message is defined by the identifier2.

Multicast: Any number of nodes can simultaneously receive and act upon a single frame.

The LIN uses frames for data communication. A frame is constructed this way: a break followed by four to eleven byte fields, labeled as in the figure 4. The time required for sending a frame is the sum of the time to send each byte plus the response space and the inter-byte spaces. The inter-byte space is the period between the end of the stop bit of the preceding byte and the start bit of the following byte. Both of them must be non-negative. The inter-frame space is the time from the end of the frame until start of the next frame. The inter-frame space must also be non-negative. On the next figure we can see the details of the frame.

Fig.4: Structure of LIN frame

Each byte field is transmitted as a serial byte. The LSB (least significant byte) of the data is sent first and the MSB (most significant byte) last. The start bit is encoded as a bit with value zero (dominant) and the stop bit is encoded as a bit with value one (recessive).

Fig.5: LIN byte field

The break symbol is used to signal the beginning of a new frame. A break is generated by the master task (in the master node) and it shall be at least 13 bits of dominant value, including the start bit, followed by a break delimiter. The break delimiter shall be at least one nominal bit time long.

A synchronization byte is a byte field with the data value 0x55. A slave task shall always be able to detect the break/synchronization symbol sequence, even if it expects a byte field. If this happens, detection of the break/synchronization sequence shall abort the transfer in progress and processing of the new frame can begin.


The network management in a LIN cluster contains wake up and goto sleep clusters only. There are two basic features, which are used in LIN. Other network management features are available only in the applications which are the next level of LIN bus.


Any node in a sleeping LIN cluster can send a request for wake up cluster. The wake-up request can change the bus to the dominant state for 250 is to 5 ms.
Every slave node can detect the wake-up request (a dominant pulse longer than 150 is) and be ready to listen to bus commands within 100 ms, measured from the ending edge of the dominant pulse.

The master node can also wake up and, when the slave nodes are ready, start sending frame headers to find out the cause of the wake up. If the master does not gain frame headers within 150 ms from the wake up request, the node sending the request can try to send a new wake up request. After three failing requests the node shall wait minimum 1.5 seconds before sending a fourth wake up request.


All slave nodes in an active cluster can be changed into sleep mode by sending a diagnostic master request frame (frame identifier = 0x3c) with the first data byte equal to zero. This special use of a diagnostic frame is called a go-to-sleep-command. Slave nodes can automatically enter a sleep mode if the LIN bus is inactive for more than 4 seconds.


The model for power management of a LIN node is on the next figure. It represents the using of the previously described clusters - wake up and goto sleep

Fig.6: LIN power management



is responsible for generating a correct headers and maintaining correct timing between frames. Interesting fact is that monitoring of errors is not required in this mode. All errors are filtered in slave task level. For task machine concept look at the figure 7.

Fig.7: Master task concept


The slave task is responsible for transmitting the frame response. The slave task is modeled with two state machines:

  • Break and synch detector

  • A slave task is required to be synchronized at the beginning of the protected identifier field of a frame, so it must be able to receive the protected identifier field correctly. This sequence is unique in the whole LIN communication and provides enough information for any slave task to detect the beginning of a new frame and be synchronized at the start of the identifier field.
  • Frame processor

  • Frame processing consists of two states, Dormant and Active. Active contains five
    sub-states. As soon as BreakAndSynch is signaled the Active state is entered in the
    Receive Identifier sub-state. This implies that processing of one frame will be aborted
    by the detection of a new break and synch sequence. The frame processor state
    machine is depicted in figure 8.

    Fig.7: Frame processor state machine


    There are used three main methods for gathering information. All of these methods can be used together in one node


    • low overhead in slave nodes
    • standardized in concept when uses normal frames
    • inflexible since the data contents is fixed in the frame structure


    • uses free range of diagnostic frames
    • non-standardized and non-portable
    • reasonable in overhead when is made to fit the needs


    • low load on master
    • full ISO diagnostics directly on the LIN slaves
    • targeting clusters built with powerful nodes (CAN based system)

    Fig.8: System setup for LIN using the transport layer

    When we consider all the LIN bus advantages and disadvantages, we realize the LIN is not a full replacement of the CAN bus. But the LIN bus is a good alternative everywhere costs are essential and speed/bandwidth is not essential. We can await a large grow of this bus system although it was primary developed for the car industry.


    Hodnocení článku: