LIN (Local Interconnect Network) is a communication protocol used for connecting low-speed electronic components and sensors within a vehicle. It is designed as a cost-effective and simple alternative to CAN protocol.
Table of Contents
What is LIN Protocol?
The LIN bus interface is a sub-system based on a serial communication protocol. The full form of LIN is Local Interconnect Network. LIN protocol is a single master / multiple slave model that uses a single wire to transmit data. Only the Master is able to initiate a LIN communication.
LIN Communication Protocol was invented to be used in simple switching applications like car seats, door locks, sun roofs, rain sensors, mirrors and so on. LIN is not used in safety-critical apps where a high data rate is required.
To reduce costs, components can be driven without crystal or ceramic resonators. Time synchronization permits the correct transmission and reception of data. The system is based on a UART / SCI hardware interface that is common to most micro controllers.
The LIN Bus Communication detects defective nodes in the network. Data Checksum and parity check guarantee safety and error detection. LIN serves as a reasonable, cost-effective supplement to the CAN bus if the bandwidth and versatility of CAN are not required.
SAE J2602 -> LIN 2.0
LIN 1.3 -> released in 2022 (Changes in Physical layer)
LIN 2.0 -> released in 2003
LIN Protocol basics – How LIN protocol works
A LIN frame consists of a header and a response part. To initiate the LIN bus communication with a slave, the Master sends the header part. If the Master wants to send data to the Slave, it goes on sending the response part. If the Master requests data from the Slave, the Slave sends the response part.
Direct communication between slaves is not possible. But as all slaves listen to the bus, a master request can be used to handle slave-to-slave communication.
The LIN communication Protocol is object-oriented and not address-oriented. The header contains the identifier which identifies the LIN frame and the data it contains. The response part mainly consists of the data of selectable length (1 to 8 bytes). An 8-bit checksum secures the data.
The LIN protocol is time-triggered oriented. The Master periodically sends the same sequence of LIN frames. In each sequence, the Master and the slaves update the data they send and receive. The sequence sent by the Master may change depending on the application events.
Example: The Slave is a sensor measuring an analog value, which is communicated to the Master via the LIN bus interface. The Slave continuously measures its analog input independently from the LIN communication. In response to a master request (periodically), the Slave sends up-to-date /or last measured value of the analog input.
In order to achieve a good level of severity, different mechanics exist like parity bits on the identifier or checksum on data bytes. In order to obtain low power consumption, the Master is able to send a sleep frame. Any mode can go into sleep (low power mode). To wake up the network, any node can send a so-called wake-up signal.
Key features of the LIN Protocol
- LIN protocol in automotive is a broadcasting serial network comprising 16 nodes (one Master and typically up to 15 slaves).
- All messages are initiated by the Master, with at most one Slave replying to a given message identifier.
- The master node can act as a slave by replying to its own messages. Because the Master initiates all communication, it’s not necessary to implement collision detection.
- There is no bus arbitration in the LIN network.
- There is guaranteed latency time in LIN due to time-triggered scheduling.
- LIN communication network consists of a single wire with communication speed up to 19.2kbit/sec at a 40-meter bus length. IN LIN specification 2.2, the speed is up to 20Kbits/sec.
- LIN Bus has a Data checksum and error detection mechanism implemented. LIN bus can detect defective nodes.
- The operating LIN bus voltage is 12V.
- LIN baudrate varies from 1 – 20 KBits/sec.
- LIN protocol is serial-oriented communication and has dominant and recessive bits.
- The voltage supply for an ECU should be between 7V and 18V.
- The description or database file for LIN is called LDF (LIN description file). This is similar to the dbc file used in the CAN network. LDF file contains information about frames and signals. This file is used for the creation of software in both Master and Slave.
- The configuration file for LIN is called LCF (LIN configuration file).
- The LIN Physical layer is based on ISO 9141 (K-Line). The physical layer is the same for both LIN and K-Line.
- The LIN Transceiver is a modified version of the transceiver used by the ISO9141 standard. The bus is bidirectional. The bus is connected to the node transceiver and also via a termination resistor and a diode to the Battery Voltage (Vbat) of the node.
- The master node controls and makes sure that the data frames are sent within the right interval and periodicity and that every frame gets enough time space on the bus. The scheduling is based on an LCF file, which is downloaded to the master node software.
- LIN frame contains a header, response, and some response space so that the Slave will have time to answer. Every frame is sent in a frame slot determined by the LCF file.
- Messages are created when the master node sends a frame containing a header. The slave node(s) then fills the frame with data depending on the header sent from the Master.
Different ways of Transmitting frames on the LIN Bus
Frames are transmitted in three different ways on the LIN bus interface. They are explained below:
Unconditional Frames in LIN protocol
This is a ‘Normal’ type of LIN bus communication. The Master sends a frame header in a scheduled frame slot. The destination slave node fills the frame with data.
Event-Triggered Frames in LIN protocol
Their purpose is to receive as much information from slave nodes without overloading the bus with frames. A slave only updates the data in an event-triggered frame when the value has changed. If more than one Slave wants to update the data in the frame, a collision occurs. The Master should then send unconditional frames to each of the slaves, starting with the one with the highest priority.
Sporadic frames in LIN protocol
This method provides some dynamic behaviour to otherwise static LIN protocol. The header of a sporadic frame is only sent from the Master when it knows that a signal has been updated in the slave node. Usually, the Master fills the data bytes of the frame itself, and the slave nodes will be the receiver of the information.
Definition of a Byte Field
The protocol is byte-oriented, which means the data is sent one byte at a time. One byte field contains a start bit (dominant), 8 data bits and a stop bit (recessive). The data bits are sent as L.S.B. first (Least Significant bit). Data transmission can be divided into a master task and a slave task.
The task of Master
Here the task of Master i.e. sending frames to Slaves is explained:
LIN protocol frame Header
LIN frame header contains 3 parts:
- Sync Break
- Sync Byte
- ID field
Each begins with a start bit and ends with a stop bit.
Sync Break
Sync Break marks the start of the message and has to be at least 13 dominant bits long, including the start bit. Synch Break ends with a ‘break delimiter’, which should be at least one recessive bit long. Therefore, the total number of bits in Sync Break is 1+12+1 = 13+1 = 14 bits.
Sync Byte
Sync Byte is sent to decide the time between two falling edges and thereby determine the transmission rate that the Master uses. The bit pattern is 0x55 (01010101 i.e. max number of edges). This is especially usable for compatibility with off-the-shelves slave nodes.
ID Field
The ID field contains a 6-bit long identifier and 2 parity bits. The 6-bit identifier contains information about the sender and receiver and the number of bytes which is expected in the response. The parity bits are calculated as follows:
Parity P0 is the result of logic ‘XOR’ between ID0, ID1, ID2 and ID4.
Parity P1 is the inverted result of logic ‘XOR’ between ID1, ID3, ID4 and ID5.
| ID Range | Frame Length |
|---|---|
| 0 – 31 [0x00 – 0x1F] | 2 |
| 32 – 47 [0x20 – 0x2F] | 4 |
| 48 – 63 [0x30 – 0x3F] | 8 |
LIN frame Response Field (Data field)
The response (data field) from the Slave can be 2, 4, or 8 bytes long depending on the 2 MSB (Most significant bit) of the identifier sent by the Master. This ability comes with LIN 2.0. The older versions of the LIN communication protocol have a static length of 8 bytes.
The task of the Slave
The Slave waits for a Synch Break, and then the synchronization between Master and Slave begins on the Synch Byte. Depending on the identifier sent from the Master, the Slave will either receive or transmit or do nothing at all. A slave that should transmit sends the number of bytes that the Master has requested and then ends the transmission with a checksum field.
Checksum field
There are two different types of checksum in LIN protocol:
Classic Checksum
The classic checksum is used in LIN 1.3 and consists of the inverted eight-bit sum of all data bytes (8) in a message.
New Checksum
The new checksum used in LIN 2.0 also incorporates the protected identifier in the checksum calculations. The inverted eight-bit sum is not the same as modulo-256. Every time the sum is greater than 256, 255 is subtracted. Example: 240+32=272. Then, 272-255=17 and so on….
To save power, the slave nodes will be put into sleep mode after 4 seconds of bus inactivity or if the Master has sent a sleep command. Wake up from sleep is done by a dominant level on the bus, which all nodes can create.
Conclusion
LIN is commonly used to connect various components and sensors in the vehicle, such as switches, lamps, climate control systems, window motors, and other simple actuators. It is not designed for high-bandwidth applications or complex data exchange like those required in advanced driver-assistance systems (ADAS) or multimedia systems.
While LIN is a simple and cost-effective solution, it can work in conjunction with other communication protocols like CAN. Many modern vehicles use a combination of LIN and CAN networks to efficiently handle the communication requirements of different vehicle systems. This approach allows automotive manufacturers to strike a balance between cost-effectiveness and functionality when designing the electronic architecture of a vehicle.