Local Interconnect Network

China Suppliers


Network topology

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2008) multilayer pcbs

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. multilayer pcb design

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

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

Overview

The LIN bus is an inexpensive serial communications protocol, which effectively supports remote application within a car 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, Volcano Automotive Group and Freescale. 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 main features are listed below:

Single master, up to 16 slaves (i.e. no bus arbitration).

Slave Node Position Detection SNPD allows node address assignment after power-up

Single wire communications up to 19,2 kbit/s @ 40 meter bus length.

Guaranteed latency times.

Variable length of data frame (2, 4 and 8 byte).

Configuration flexibility.

Multi-cast reception with time synchronization, without crystals or ceramic resonators.

Data checksum and error detection.

Detection of defect nodes.

Low cost silicon implementation based on standard UART/SCI hardware.

Enabler for hierarchical networks.

Operating Voltage of 12 V.

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 between 2, 4 and 8 data bytes plus 3 bytes of control information.

LIN Message frame

A message contains the following fields:

Synchronization break,

Synchronization byte,

Identifier byte,

Data bytes,

Checksum byte.

Frame Types:

1- Unconditional Frame:

Unconditional frames 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 an event triggered frame is to increase the responsibility 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 its protected identifier. The publisher of an associated unconditional frame shall only provide the carried by its frame is updated. 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, the master has to resolve the collision by requesting all associated unconditional frames before requesting the event triggered frame again.

3- Sporadic Frame

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

Diagnostic frame 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 requires 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 the response according to their diagnostic module.

5- User-Defined Frame

User-Defined frames 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

Reserved frames shall not be used in a LIN 2.0 cluster. Their identifier is 63 (0x3F).

LIN hardware

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. In today 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 crystal oscillator (quartz or a ceramic). To ensure the baudrate-stability within one LIN frame, the SYNC field within the header is used.

LIN protocol

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2008)

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 kbit/s to 20 kbit/s. 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 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 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.

Header

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2008)

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

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

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2008)

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.

Slave Node Position Detection (SNPD) ie autoaddressing

These methods allow the detection of the position of slave nodes on the LIN bus and allow the assignment of a unique node address.

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 Phillips

Bus Shunt Method

0x02

Elmos

Reserved

0x03

TBD

Reserved

...

TBD

Reserved

0xFF

TBD

Extra Wire Daisy Chain (XWDC)

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.

Switchable resistive pull-up to vbat

Pull-down to gnd

Comparator referenced to vbat/2

XWDC Auto-addressing Procedure

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

1 First auto-addressing LIN mesasge

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)

Each slave node has two LIN pins

bus_in

bus_out

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

The standard pull-up must be switchable

Switchable 2mA current source from VBAT

Shunt resistor

Differential amplifier

Analog to digital converter

BSM Auto-addressing Procedure

At the start of the procedure no 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 < 1mA 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 < 1mA 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 following patents:

EP 1490772 B1

US 7091876

LIN advantages

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 costs are essential and speed/bandwidth is not essential.

Applications

Application Segments Specific LIN Application Examples

Roof Sensor, light sensor, light control, sun roof

Steering Wheel Cruise control, wiper, turning light, climate control, radio

Seat Seat position motors, occupant sensors, control panel

Engine Sensors, small motors

Climate Small motors, control panel

Door Mirror, central ECU, mirror switch, window lift, seat control switch, door lock

LIN API

This section does not cite any references or sources.

Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2008)

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.

See also

List of network buses

References

^ a b c "Clemson Vehicular Electronics Laboratory: AUTOMOTIVE BUSES". http://www.cvel.clemson.edu/auto/auto_buses01.html.  090114 cvel.clemson.edu

^ LIN Node Configuration and Identification Specification Rev 2.1

^ "LIN Bus Description, Automotive Bus, Local Interconnect Network". http://www.interfacebus.com/Design_Connector_LIN_Bus.html.  090114 interfacebus.com

^ LIN Technical Overview

External links

LIN Consortium

CAN/LIN Training

Brief CAN/LIN Background Information (Chinese)

v  d  e

Computer bus & interconnection standards (wired)

Main articles

Front-side bus  Back-side bus  Daisy chain  Control bus  Address bus  Bus contention  Electrical bus

List of bus bandwidths

Computer bus standards (desktop)

S-100 bus  MBus  SMBus  Q-Bus  ISA  Zorro II  Zorro III  CAMAC  FASTBUS  LPC  HP Precision Bus  EISA  VME  VXI  NuBus  TURBOchannel  MCA  SBus  VLB  PCI  PXI  HP GSC bus  CoreConnect  InfiniBand  UPA  PCI-X  AGP  PCI Express  Intel QuickPath Interconnect  HyperTransport  more...

Computer bus standards (portable)

PC Card  ExpressCard

Storage bus standards

ST-506  ESDI  SMD  Parallel ATA  DMA  SSA  HIPPI  USB MSC  FireWire (1394)  Serial ATA  eSATA  SCSI  Parallel SCSI  Serial Attached SCSI  Fibre Channel  iSCSI

Peripheral bus standards

Multidrop bus  Apple Desktop Bus  HIL  MIDI  Multibus  RS-232 (serial port)  DMX512-A  EIA/RS-422  IEEE-1284 (parallel port)  UNI/O  1-Wire  IC  SPI  EIA/RS-485  Parallel SCSI  USB  FireWire (1394)  Fibre Channel  Camera Link  External PCI Express x16  Light Peak

Vehicle buses

LIN  J1708  J1587  FMS  J1939  CAN  VAN  FlexRay  MOST

Note: interfaces are listed in speed ascending order (roughly), the interface at the end of each section should be the fastest

Categories: Serial busesHidden categories: Wikipedia articles needing context from March 2009 | All Wikipedia articles needing context | Wikipedia introduction cleanup from March 2009 | Articles needing additional references from April 2008 | All articles needing additional references