Local Interconnect Network

Overview

The LIN-Bus (Local Interconnect Network) is a bus-system used within current automotive network architectures. The LIN specification is forced by the LIN-consortium - the home address is [1]. The first used-in-car specification was the Version 1.1, released in 1999. The current version is the 2.0, which has received a lot of adjustments to modern network needs.

The LIN bus is a small and slow network system. The integrated members are intelligent sensor devices or actuators. To lower the networking costs in today’s cars, a cheap sub network to CAN (Controller Area Network) was needed integrating this small and lean devices.

Network topology

The messages within a LIN network are broadcasted. Therefore, one dedicated node is set up as a LIN Master while the network design phase. All other attached nodes are the LIN Slaves. This topology is fixed and cannot be changed afterwards. Messages are always initiated by the LIN Master. Only one LIN slave is allowed to send data back to the LIN bus upon this header, because no mechanism of conflict resolving is foreseen. The concrete action is given by the Identifier which is contained within the header. The LIN Master microcontroller is typically a very powerful one, while the LIN Slaves may be small and cheap microcontroller or dedicated LIN hardware. To provide the Master with the ability to send data (e.g. status-variables) to some or all attached LIN Slave-nodes, it consists from software point of view not only of a LIN Master-, but also a LIN Slave-task.

Current network topologies combine several LIN sub networks via CAN to an upper layer network.

A typical LIN network consists of one LIN Master and up to 16 LIN Slaves - from physical point of view. In theory, up to 64 different Slave-nodes may be attached to one LIN network.

LIN hardware

The LIN specification was implemented to allow very cheap hardware-nodes being used within a network. In today’s car networking topologies, either microcontroller with a UART as subset included or dedicated LIN hardware working in a LIN network only 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.

Due to the fact, that LIN Slave nodes should be as cheap as possible, they may generate their internal clock by a RC-oscillator combination instead of a quartz or a ceramic oscillator. To ensure the baudrate-stability within one LIN frame, the SYNC field within the header is used.

LIN Protocol

The LIN-Master uses one or more predefined scheduling tables to start the sending and receiving to the LIN bus. These scheduling tables contains 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, the response is sent by only one dedicated LIN-Slave.

The basic data format within the LIN specification is defined to consist of eight data-Bit, one Start-, one Stop-Bit, no parity. The LIN speed can be chosen from the range of 1 kbaud to 20 kbaud. Data on the bus is divided into recessive (logical HIGH) and dominant (logical LOW). The time normal is considered by the LIN Masters stable clock source, the smallest entity is one Bit Time (52 µsec @ 19.2 kbaud).

Two bus states - Sleep-mode and active - are used within the LIN protocol. While data is on the bus, all LIN-nodes are requested to be in active state. After a specified timeout, the nodes enter the Sleep mode and will be released back to active state by the WAKEUP frame. This frame may be send 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 being woken up, the Master continues to schedule the next Identifier.

Header The header consists of three 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 Bit. 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-combinations will use the distance between a fixed amount of rising and falling edges to measure the current Bit Time on the bus (the Masters time normal) and to recalculate the internal baud rate.

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. It the Masters slave task sends data to the bus, it may be called Tx-identifier.

Response The response is sent by one of the attached LIN Slave tasks and is divided into data and checksum.

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.

LIN API

The LIN API (Application Programmers Interface) provides a given set of function calls (base is the programming-language C)which have to implemented within each LIN software driver. Using this pre-defined set of driver routines, all LIN functions may be accessed.

The usage of API-compliant functions eases the implementation of standard software drivers. Also the testing is speed up.

--Laschewskir 05:47, 13 Aug 2004 (UTC)