Local Interconnect Network

From Wikipedia, the free encyclopedia

The introduction to this article provides insufficient context for those unfamiliar with the subject. Please help improve the article with a good introductory style.

This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (April 2008)

The LIN-Bus (Local Interconnect Network) is a computer networking bus-system used within current automotive network architectures. The LIN specification is enforced by the LIN-consortium, with the first exploited version being 1.1, released in 1999. Since then the specification has evolved to version 2.1 to meet current networking needs.

The LIN bus is a small and slow network system that is used as a cheap sub-network of a CAN bus to integrate intelligent sensor devices or actuators in today’s cars. Recently LIN may be used also over the vehicle's battery power-line with a special DC-LIN transceiver.

[edit] Network topology

This section does not cite any references or sources. (April 2008) Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed.

LIN is a broadcast serial network comprising one master and many (up to 16) slaves. No collision detection exists, therefore all messages are initiated by the master with at most one slave replying for a given message identifier.

The master is typically a moderately powerful microcontroller, whereas the slaves can be less powerful, cheaper microcontrollers or dedicated ASICs.

Current uses of LIN combine several such networks — usually with 16 nodes — all linked to a CAN upper layer network via their respective masters.

[edit] LIN hardware

The LIN specification was designed to allow very cheap hardware-nodes being used within a network. It is "Low cost single-wire implementation based on enhanced ISO 9141."^[1] In today’s car networking topologies, either microcontrollers with 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 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.

[edit] LIN protocol

This section does not cite any references or sources. (April 2008) Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed.

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, while the response is sent by only one dedicated LIN-Slave.

Transmitted data within the LIN is transmitted serially as eight bit data bytes with one start & stop-bit and no parity. Bit rates vary within 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 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] Header

This section does not cite any references or sources. (April 2008) Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed.

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

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.

[edit] Response

This section does not cite any references or sources. (April 2008) Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed.

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.

[edit] LIN API

This section does not cite any references or sources. (April 2008) Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed.

The LIN API (Application Programmers Interface) provides a given set of function calls (base is the programming-language C) which have to be 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 sped up.

[edit] References

[edit] External links

• LIN-consortium website
• [1] Oakland University Embedded Engineering Research Laboratory "Please Request Persmission to Enter Website"