The LIN-Bus (Local Interconnect Network) is a vehicle bus standard or 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.2 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.
Contents |
LIN is a broadcast serial network comprising one master and typically up to 12 slaves. All messages are initiated by the master with at most one slave replying for a given message identifier. Therefore it is not necessary to implement a collision detection. [1]
The master is typically a microcontroller, whereas the slaves are implemented as ASICs.
Current uses combine the low cost efficency of LIN and simple sensors to create small networks. These sub-systems can be connected by back-bone-network. (i.e. CAN in cars) [2]
The LIN bus is an inexpensive serial communications protocol, which effectively supports remote application within a car’s 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’s main features are listed below:
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[4].
A message contains the following fields[4]:
Frame Types:
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.
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.[6] In today’s car networking topologies, microcontrollers with either 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 clocks by using RC oscillators instead of crystal oscillators (quartz or a ceramic). To ensure the baud rate-stability within one LIN frame, the SYNC field within the header is used.
The LIN-Master uses one or more predefined scheduling tables to start the sending and receiving to the LIN bus. These scheduling tables contain 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.
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.
The response is sent by one of the attached LIN slave tasks and is divided into data and checksum[4].
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.
These methods allow the detection of the position of slave nodes on the LIN bus and allow the assignment of a unique node address.
Restrictions:
| 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 |
Each slave node has to provide two extra pins, one input D1 and one output D2.
Each configuration pin Dx (x=1-2) has additional circuitry to aid in the position detection.
At the start of the procedure no SNPD devices have a NAD assigned
1 First auto-addressing LIN mesasge
2 Subsequent auto-addressing LIN messages
3 All pull-ups and pull-downs are turned off completing the addressing procedure
Each slave node has two LIN pins
Each slave node needs some additional circuitry compared to the standard LIN circuitry to aid in the position detection.
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
2 Pull-up Mode
3 Current Source Mode
This technique is covered by the following patents:
EP 1490772 B1
US 7091876
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.
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
The LIN application programming interface (API) 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.
When developing and/or troubleshooting the LIN bus, examination of hardware signals can be very important. Logic analyzers and bus analyzers are tools which collect, analyze, decode, store signals so people can view the high-speed waveforms at their leisure.
|
|||||||||||||||||||||||