LIN - Local Interconnect Network
The Local Interconnect Network (LIN) bus system as a low-cost bus system from a manufacturing consortium designed with Motorola and Freescale Semiconductor manufacturers and a number of automotive manufacturers. Its objective was: to create a sub-bus system for CAN, which should be less expensive than CAN for sensor / actuator networks.
LIN – Local Interconnect Network
LIN bus access is used as the master-slave principle. A master control unit that also functions normally as a gateway between CAN and LIN, inform the individual slave controllers by a master request message to each of the token. The slave nodes themselves do not require configuration information, and have low requirements on the clock accuracy. They can be as cost-perhaps even executed without quartz. The bus system contains relatively few mechanisms to detect transmission errors and few mechanisms for error correction. This must all be implemented within the software.
LIN has gone through despite its relatively short history, already a number of versions of a specification versions that were more extensive. The version 1.3 has been installed correctly the first version. Shortly thereafter, however, already in 2006 and 2.0 to version 2.1. The enhancements, which are not always forward compatible, include inter alia the ability to diagnose messages from KWP 2000 and UDS can be tunneled via LIN.
The LIN bus itself has a very simple physical layer. The requirements for the microcontrollers to implement LIN is low. It does not take communication controller - a simple UART enough. The rest of the protocol can be handled in software. However, one should at LIN sub-bus systems do not underestimate that particular gateway functions between CAN and LIN, as well as the adaptation of different timings to make this overall vehicle networks relatively complex.
Physical Layer and bus topology
The transmission works with character-based UART-like characters. The physical layer corresponds substantially to the K-Line. That is, it is a one-wire bus with battery voltage level. It is not necessary communication controller. The protocol is so simple that it can be implemented with each UART and the corresponding software. The requirements for the timing, as I said, relatively low. A master can control a number of slaves. The bit rate is in terms of simple physical layer up to 20 kbit / s. Real are in use bit rates of 9.6 kbit / s, 10.4 kbit / s or 19.2 kbit / s.
Bus-und Physical Layer Topologies
Data Link Layer
The bus system uses the message format shown in the figure. The header is always transmitted from the master. Then follows a short break and followed by a response. This is also available from the master control device when the master has something to send to the slaves or a slave control device when a reply is expected.
The header begins with a 13 up to 26 bits long zero and a 1 to 14-bit high-bit sequence. Then comes a byte with zeros and ones, known as the sync byte. The sync byte of the synchronization of the receiver on the bit rate of the master control unit. Then follows the so-called protected-Identifier (PID) - a kind of message identifier with a very similar function as in CAN. It uniquely identifies the content of the message and the sender of the following response. Because the development has been clearly established, which control device has to send a response to that PID. The PID contains only 6 bits for the actual PID. That is, there are more than 64 different messages. Two more bits are used for error detection than parity bits. In the area of the body are very common tasks in which the control unit must also work with the ignition off yet.
There, however, the power consumption is important. That is why we put bus systems and controllers in this case, often saving in a sleep mode to save energy. To take control this sleep mode and stops again to, you have provided in the LIN specification that the bus system after 4 seconds Businaktivität, so it was when the bus more than four seconds at rest, automatically goes into sleep mode . By a message sent by the master with the PID 0x3C, the bus can be moved actively in the sleep mode. Conversely, any control device on the bus system LIN bus wake up with a "wake-up pattern (WUP) again. The master control device must follow one Aufweckvorgang within 100 ms to start again, the regular communication.
The Master of the LIN bus system operates synchronously. This usually contains a so-called Sceduling-table, set in which it is sent at what time which PGD. The configuration of the network is typically done using a so-called LDF file (LIN-Description Format).
Given the low bit rate is the data rate of 1.2 / s kByte relatively modest. It is thus about 25 times slower than high-speed CAN.
Message types
Although use at all LIN messages always the same message format, the specification is different following different message types:
-
Unconditional frames (Standard frame)
- Normal cyclically transmitted standard frames
-
Event-triggered frames
- For data, they rarely change
- Multiple slaves can respond to a request
- It answers only the slaves in which data may have changed
- Master detects slave on the first data byte of the response of standard PID → Frames
- Recognizes the master collision, it asks for the standard frames before again sending event-triggered frames
- Nondeterministic
-
Sporadic frames
- Placeholders in the scheduling table for dynamic behavior of the Masters
- Otherwise, the bus remains in that slot in peace
- Master can use one of several possible PIDs
- Selection of the Message on static priority scheduling → Table
- Event-driven, non-deterministic
- Then, when data has changed in the master or the master answers are required (master and slave)
-
Diagnostic frames PID (0x3C and 0x3D)
- Always with 8 data bytes
- For configuration and diagnostics of the slaves
- Diagnosis of ISOTP or UDS without flow control
- Master sends diagnostic request of 0x3C and collects the response from the slave to 0x3D
-
User defined frames (PID 0x3E)
- Data field may be longer than 8 bytes
-
Reserved frames (PID 0x3F)
- For future extensions
- Must not currently be used
Unconditional frames are the standard frames that are sent in each communication cycle in the corresponding time slots need to be. The main difference of event-triggered frames over standard frames is that, in principle at a standard frame each PID is assigned to a control device for the response. In response to the PID of an event-triggered frames, however, several control units. You can of course not simultaneously. If they do, nevertheless, there is a collision. This specification describes how such conflicts should be dissolved. Similarly, the Sporadic frames. These represent placeholders for messages, not sent in each time slot will have. For sending diagnostic messages, the standard reserve two PIDs, one for the diagnostic request (0x3C), the other for the diagnostic response (0x3D). Two other PIDs (0x3E and 0x3F) are reserved for future or vendor-specific extensions.
See also
-
Created12. January 2011
-
Version4
-
Amended05. April 2011
-
Hits1693