LIN Protocol Tutorial
The purpose of the LIN Protocol tutorial is to give you a brief explanation of LIN from basic to deep. This will help you to understand and implement it in any project if you are working on it. If you have any doubts after learning from this tutorial please provide us your feedback. Even if you can also comment below if any doubt. If you have any real-time doubt since you are working on any project, then you can ask your question in our forum.
History Of LIN Protocol
The LIN stands for Local Interconnect Network. Whenever the Automotive OEMs were started increasing the use of the huge amount of features in the vehicle with having more sensors and other smart intelligent devices in the vehicle, then the price increased as it was more costly for the costumers. So to make a vehicle with low cost, the OEM’s as BMW, Volkswagen Group, Audi Group, Volvo Cars, and Mercedes-Benz are 5 automakers were developed this LIN protocol in 1990 by Volcano Automotive Group and Motorola. The first LIN was 1.0 version but it was not stable for use in a vehicle. Then the LIN-1.3 version was published in November-2002 where they started using this in the vehicle. Again in September-2003, the LIN-3.0 version was introduced to expand the more features and having the diagnostic features. Even if there is a good advantage of LIN is that it can use as a DC power line for automotive vehicles and is being standardized as ISO/AWI 17987-8.
LIN Protocol Revision History
| Issue | Date of release | Remark |
|---|---|---|
| LIN 1.0 | 1999-07-01 | Initial Version of the LIN Specification |
| LIN 1.1 | 2000-03-06 | NA |
| LIN 1.2 | 2000-11-17 | NA |
| LIN 1.3 | 2002-12-13 | NA |
| LIN 2.0 | 2003-09-16 | Major Revision Step |
| LIN 2.1 | 2006-11-24 | Clarifications, configuration modified, transport layer enhanced and diagnostics added. |
| LIN 2.2 | 2010-12-31 | Updated document according to LIN 2.1 Errata sheet 1.4 Softened bit sampling specification |
| LIN 2.2A | 2010-12-31 | Corrected wakeup signal definition in chapter 2.6.2 |
Introduction to LIN Protocol
The LIN is a CAN and SAE-J1850 compliant application protocol which is not time-critical and does not need extreme fault tolerance since the LIN is not reliable as CAN protocol. Basically, the objective of the LIN protocol was to use where the time and fault-tolerant is not a priority and to implement at a low cost than CAN protocol.
Definition Of LIN Protocol
The LIN is broadcasting, Single Master and Multi Slave (up to 16), SCI/UART-based serial, byte-oriented, time-triggered communication protocol designed to support automotive networks in conjunction with Controller Area Network (CAN), which enables the cost-effective communication with sensors and actuators when all the features of CAN are not required. The main features of this protocol (compared to CAN) are low cost and low speed and used for short-distance networks.
Usually, the LIN protocol is used in Automotive vehicles to support the CAN network for cost-effective to connect between the sensors and actuators with an ECU which is often a gateway with CAN bus. In LIN protocol there is no collision detection capability, therefore in LIN, all the messages are initiated by the Master node with at most one slave will reply with the Transmitted message identifier. The master is typically a moderately powerful microcontroller, whereas the slaves can be less powerful, cheaper micro-controllers or dedicated ASIC’s, etc.
Basically the LIN is a single wire 12V bus networking communication protocol based on the ISO-9141 NRZ based standard protocol. The main feature of the LIN network is the synchronization mechanism which allows the clock recovery by the slave nodes without quartz or ceramics resonator. Only the Master node is having consists of the clock or the oscillator. Like CAN protocol, the LIN nodes also can be added into the LIN network without any hardware or software changes in other slave nodes.
Features of Lin Protocol:
- LIN protocol has a Single Master and Multi Slave (Up to 16 Nodes) network.
- It is a Single ware communication protocol up to 20 kbit/s speed at 40 meters.
- It has Guaranteed latency times for any signal transmission to give reliable and predictable responses in the network.
- Variable length of Data Frame (2, 4, & 8 bytes).
- Configuration Flexibility for the Slaves.
- It has Multicast reception capability with time synchronization without any crystals or ceramic resonators.
- It has the capability of detection of defective nodes in the network.
- The LIN frames are having data checksum and error detection capability.
- It can be designed with Low-cost silicon implementation by using the standard SCI/UART hardware.
Applications Of LIN Protocol
 The LIN bus is having many applications in the automotive vehicles are:
Roof area:
- Rain sensor – possibly interrogated every 10 – 20 ms
- Light sensor
- Light control
- Sunroof
Door / window:Â
- Mirror
- Window control
- Door lock
Steering wheel:
- Cruise control
- Radio
- Mobile phone
- Wiper
- Lights
Seats:
- Seat position control.
- Occupancy sensor.
- Heating control (if installed).
Like CAN protocol, the LIN is also having LIN Controller and LIN
Physical Layer of LIN Protocol
The LIN-bus transceiver is a modified version of the LIN transceiver used by the ISO-9141 standard. The LIN bus is bidirectional and connected to the node transceiver, and also via a termination resistor and a diode to Vbat of the node for error-free data communication in between the Master and Slave with some modifications for the automotive applications; specifically EMC, ESD, Transient pulse response, and so forth.
The transceiver is what facilitates the communication between the bus and the network. The LIN transceiver converts the bit logic from the microcontroller into higher voltage levels as transmission along the bus, and vice versa. The Transmitter (TxD) and Receiver (RxD) of the LIN transceiver facilitate the communication to and from the bus through voltage translation that happens as the signals pass through the transceiver so that the LIN controller will not worry about the physical communication how it is going to happen. Basically, the LIN transceiver will receive the data from Microcontroller (Inside the microcontroller it will be having LIN controller where which will be used by the Embedded firmware developer to write the LIN driver program) in serial UART pin and convert it to LIN bus voltage level. The TxD has connected to the microcontroller nothing but the on-chip LIN controller, where the message is sent and then broadcasted on the LIN bus. The RxD monitors the bus and converts the messages on the LIN bus to voltage levels the microcontroller can interpret, and thus respond to the communication happening on the bus. The typical voltage levels for the TxD and RxD are typical of most microcontroller levels: 3.3 V and 5 V. The LIN bus, and LIN transceivers, typically operate at voltages ranging from 9 V to 18 V, but some go up to 30 V, depending on the application; a typical vehicle is a 12-V battery system, but some larger vehicles go up to 24 V.
Pull-Up Resistor in LIN Protocol
The master node requires an external line pull-up resistor and diode according to the LIN specification. The typical value seen is the 1 kΩ (other typical values are 600 Ω and 500 Ω) in series with a diode – for reverse-polarity protection – connected to the battery voltage. The typical lin pull-up value of the LIN slave is 30 kΩ, and in all modern LIN transceivers, this is integrated within the IC, so no external lin pull-up is necessary
LIN BUS Threshold Voltage Level
The LIN Tx and Rx have different levels that meet these recessive and dominant voltage level requirements. For dominant pulses (low), the sender must drive the voltage level down to 20% of the battery voltage level, while the receiver will interpret a dominant bit when the voltage level reaches 40% on their end. For recessive pulses (high), the sender must drive the voltage to 80% of the battery voltage, while the receiver interprets a recessive bit when the voltage level reaches 60% on the bus. The difference in levels between the receiver and sender is due to the differences in the external supply voltage, and the actual LIN bus voltage. Drops in voltage that may happen in the cabling, ground shifts, or just changes caused by filtering components along the bus are the causes for the deviation of the external supply versus the bus level.
LIN Protocol Data Communication
The LIN protocol is a master-slave networking protocol which is having one master and several Slaves (Up to 16 Nodes). Since the LIN is a Master-Slave communication protocol, always the master will initiate the communication or sending the command to the slave about the data which will send by the master. According to the instruction available in the LIN frame, the Slave will react to the master. Like CAN protocol, the LIN is also message-based protocol, and the communication will be always initiated by the master and there will be one slave who will react/reply to a given message Identifier as required. The important advantage of LIN over the CAN is like as the master always imitates the messages means that there is no need for any form of collision detection within the LIN protocol as the master has complete control on the LIN bus. After then the slave node then fills the data in the data field depending on the header sent from the master and sent back on the LIN bus so that the master can receive the data and take the action as per the application functionality implemented. The data that is exchanged in the frames are referred to as signals.
LIN Protocol Frame Format
The LIN protocol communicates the data between the Master & Slave using the LIN data frame. This frame is having consists of a Header field, a Response field, and the Inter-frame Space (IFS) field. Every LIN frame is a message and the different messages are categorized by their properties which are defined in the Lin Description File (LDF) like CAN database (.dbc). The LIN messages are created whenever the master node broadcasts a frame containing 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 Header
The LIN message header is generated by the LIN master node which consists of:
- Sync Break Field.
- Sync Field.
- Protected Identifier Field (PID).
- Inter Byte Space.
- Response Space.
Sync Break Field
 The BREAK field is used to activate all the attached LIN slaves to listen to the header. The synch field is the signal for the LIN slave nodes to warn the beginning of a new frame. break field is always generated by the master task (in the master node) and it shall be at least 13 nominal bit times of dominant value, followed by a break delimiter. This is used to ensure that the listening LIN nodes or ECUs with a main-clock differing from the set bus baud rate in specified ranges will detect the BREAK as the frame starting the data communication and not as a standard data byte with all values zero (hexadecimal 0x00) values
Sync Field
The objective of the Synch byte is sent to decide the time between two falling edges and thereby determine the transmission rate which the master uses. The LIN slaves are the running on the RC oscillator will use the distance between a fixed amount of rising and falling edges to measure the current bit time on the bus (normally of the master’s time) and to recalculate the internal baud rate
When the break/sync field sequence happens, the transfer in progress shall be aborted and processing of the new frame shall commence.
Protected Identifier Field (PID)
The protected Identifier field having
LIN Frame Identifier
The 6-bit identifier contains the information about to the sender and receiver and the number of bytes which is expected in the response. The values in the range between 0 – 63 can be used.
How to detect DLC of a LIN frame?
The response is as below according to the frame identifier sent by the master as below:
| ID Range (DEC) | ID Range (HEX) | Frame Data Length (Byte) |
|---|---|---|
| 0-31 | 0X00 – 0X1F | 2 |
| 32-47 | 0X20 – 0X2F | 4 |
| 48-63 | 0X30 – 0X3F | 8 |
The frame identifiers are split into three categories are:
- Values from 0 – 59 (0x3B) are used for signal carrying the frames.
- The values from 60 (0x3C) and 61 (0x3D) are used to carry diagnostic and configuration data.
- The values from 62 (0x3E) and 63 (0x3F) are reserved for the future protocol enhancements.
LIN Parity Field
The LIN protocol is also using error checking methods like CRC in CAN protocol for validation of transmitted data. The LIN using the Parity Bit checking method for data validation
P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4 —————-(1)
P1 = ! (ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5) ————(2)
Mapping:Â The mapping of the bits (ID0 to ID5 and P0 and P1) is shown in Figure below:Â
LIN Inter Byte Space
The Inter Byte Space is used to adjust for bus jitter. It is an optional component within the LIN specification. If it is enabled, then all the LIN nodes must be prepared to deal with it. There is an Inter Byte Space IN between the BREAK and SYNC field, one between the SYNC and IDENTIFIER field, one between the payload and Checksum and one between every Data byte in the payload.
LIN Response Space
The Response Space is the time between the IDENTIFIER field and the first Data byte which starts of the LIN RESPONSE part of the LIN frame. When a particular LIN frame is transmitted completely, Header + Response, by the LIN MASTER, the LIN MASTER will use the full RESPONSE SPACE TIME to calculate when to send the response after sending the header. If the response part of the LIN frame is coming from a physically different SLAVE NODE, then each node (master & slave) will utilize 50% of the Response Spacetime in their timeout calculations for the delay.
LIN Slave Response Field
The response is sent by one of the attached LIN slave tasks and is divided into (1) data and (2)Â checksum.
LIN Slave Data Field
The responding LIN slave may send zero to eight data bytes to the LIN bus. The amount of data is fixed by the LIN Master (application designer) and mirrors data relevant for the application which the LIN slave runs in.
LIN Checksum
Like CAN protocol, the LIN is also having the CRC for data validation. There are two checksum-models are available within the 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 for their own product.
Difference between Classic and Enhanced LIN Checksum:
The checksum used in LIN protocol is one byte long and differs from LIN version 1.3 to LIN version 2.1: –> LIN V1.3: The LIN version from V-1.0 to V-1.3 called classic Checksum. In this, the checksum is calculated from the data-bytes only. –> LIN V2.1: The LIN version from V-2.1 to above called enhanced Checksum. In this, the checksum is calculated from the data-bytes and PID fields. The best advantages of LIN is Inside a LIN V2.1 bus, the individual messages can also be transmitted as LIN V1.3 messages, in order to remain compatible with old ECUs in vehicles. The LIN message IDs 60 (0x3C) and 61 (0x3D) are reserved for the classic checksum as per LIN 1.3. A LIN 2.0 master is backward compatible with a LIN 1.3 slave (with limitations). Both LIN 2.0 and LIN 1.3 slaves can coexist in a network but some new features like the improved checksum and automatic baud rate detection have to be avoided by using the above-defined LIN message ID.
How to calculate the CheckSum in LIN Protocol?
The LIN v-2.0 specification defines the checksum calculation process as the summing of all values and subtraction of 255 every time the sum is greater than or equal to 256 (unlike modulo-255 or modulo-256). Per the LIN 2.0 specification, the classic checksum is for use with LIN 1.3 slave nodes and the enhanced checksum is for use with LIN 2.0 slave nodes. It further specifies that IDs 60 through 63 shall always use a classic checksum.
What is the difference between Classic and Enhanced LIN CheckSum?
The below points are changed from older LIN v1.3 to Enhanced LIN 2.1:
- The Byte array signals are supported, thus allowing signal sizes up to eight bytes.
- The Signal groups are deleted as replaced by byte arrays for better performance.
- Automatic bit-rate detection is incorporated in the LIN 2.1 specification.
- The Enhanced checksum including a protected identifier as an improvement to the LIN 1.3 classic checksum.
- In LIN v2.1, Sporadic frames are defined.
- The Network management timing is defined in seconds, not in bit times for flexible application interface.
- The LIN network Status management is simplified and reporting to the network and the application is standardized.
- Mandatory node configuration commands are added, together with some optional commands.
- The Diagnostics features are added for ECU fault detection.
- A LIN Product Identification for each node is standardized to implement and interface easily in a LIN network.
- The API is made mandatory for microcontroller-based nodes programmed in C.
- The API is changed to reflect the changes; byte array, go-to-sleep, wake up, and status reading.
- A diagnostics API is added.
- A node capability language specification is added.
- The configuration language specification is updated to reflect the changes made; node attributes, node composition, byte arrays, sporadic frames, and configuration are added.
LIN Protocol Frame Types
The LIN is having consists of 6 types of frames as the identifier specifies the frame type which can be one of the following:
- Unconditional Frame.
- Event-triggered Frame.
- Sporadic Frame.
- Diagnostic Frame.
- User-defined Frame.
- Reserved Frame.
Unconditional LIN Frame
This frame is the normal type of LIN message format for data communication. Basically, the master node will send this frame header in a scheduled frame slot and the designated slave node will receive and fills the data and send it back. This frame normally carries off the signals and the defined identifiers from 0-59 (0x00 to 0x3B).
Event-Triggered LIN Frame
The purpose of this method is to receive as much information from the slave nodes without overloading the bus with frames. An event triggered frame can be filled with the data from more than one slave node. A slave only updates of the data in an event-triggered frame when the value has changed. If more than one slave wants to update data in the frame a collision occurs. The master should then send unconditional the frames to each of the slaves starting with the one with the highest priority.
Sporadic LIN Frame
The purpose of the sporadic frame is to blend some dynamic behavior into the deterministic and real-time focused schedule table without losing the determinism in the rest of the schedule table.
Diagnostic LIN Frame
The diagnostic frame is used to find the fault in a LIN network by using the Transport Layer (TP). The frame identifier is either 60 (0x3C), called the master request frame, or 61 (0x3D), called the
LIN Protocol BUS Timing
Since the LIN protocol bus is a polled bus, the processing of each frame is allocated a nominal time slot as follows:
- THeader_Nominal = 34 * Tbit.
- TResponse_Nominal = 10 * (NData + 1) * TBit.
- TFrame_Nominal = THeader_Nominal + TResponse_Nominal. Processing of each frame is allocated a maximum time slot as follows:
- THeader_Maximum = 14 * THeader_Nominal.
- TResponse_Maximum = 1.4 * TResponse_Nominal.
- TFrame_Maximum = THeader_Maximum + TResponse_Maximum.
LIN Protocol Behaviour:
The LIN bus connects a single master device (ECU/node) and one or more slave devices (ECU/nodes) together in a LIN cluster. The behavior of each node is described by its own ECU/node capability file. The node capability files are the inputs to a system-defining tool, which generates a LIN description file (LDF) that describes the behavior of the entire cluster. The LDF is parsed by a system generator to automatically generate the specified behavior in the desired nodes. At this point, the master node master task starts transmitting headers on the bus, and all the slave tasks in the cluster (including the master node’s own slave task) respond, as specified in the LDF.
The LDF is used to configure and create the scheduling behavior of the LIN cluster. For example, it defines the baud rate, the ordering and time delays for the master task’s transmission of the headers, and the behavior of each slave task in the response packet. The response queue holds 64 responses, one for each of the maximum number of 64 IDs specified for the LIN. This ensures that the LIN interface slave task can respond to headers within the response time defined by the LIN specification.
LIN Protocol Error Detection and Confinement:
The LIN 2.0 specification states that error detection should be handled by the slave tasks and that error monitoring by the master task is not required which will improve the LIN bus master efficiency. The LIN 2.0 specification does not require the handling of multiple errors within one LIN frame or the use of error counters also. Upon encountering the first error in the frame, the slave task aborts the processing of the frame until the detection of the next break-sync sequence (in the next header transmitted by the master). If the log bus error attribute is set to true, a bus error the frame is logged into the read queue. If the log bus error attribute is set to false, an error is the returned by ncWriteNet or ncWriteNetMult.
LIN protocol also provides for error reporting to the LIN network. The LIN 2.0 specification defines a Response_Error status bit, which the slave is required to report to the master in one of its transmitted frames. This bit is set whenever the frame received or transmitted by a slave node contains an error in the response field. The bit is cleared after it is then transmitted in one of the slave’s published responses.
LIN Protocol Transceiver Behaviour:
With most modern LIN transceivers, there are special functions that help with the specific application needs. Most of the features listed are for systems that focus on low power consumption. Let’s go discuss the different LIN.
LIN Protocol Sleep Feature
The sleep mode is used for power consumption in the LIN vehicle network which might help to use this power in some different purposes or can be used for a long time. The LIN protocol features a mechanism that allows devices to enter the sleep state and potentially conserve power in automotive vehicles. The sleep mode is typically entered by putting a logic low on the Enable pin (if there is one) of the LIN transceiver.
The Sleep Mode implies that the device is in a less functional state means it will consume very little power but is still able to monitor the LIN bus for any wakeup signals. In Sleep mode, the LIN driver is disabled and the internal LIN bus termination is switched off to minimize current draw if the LIN bus is shorted to ground for any reason. So at that time a low-power receiver is enabled and the normal receiver function is disabled, and EN input is still active.
As per the LIN-2.0 specification, all slaves in a LIN network may be forced into sleep mode by the master sending a diagnostic master request frame (ID=60) with the first data byte equal to zero. This special frame is called the go-to-sleep command. Slaves also automatically enter sleep mode if the LIN is inactive for more than four seconds. Upon receiving a full-frame containing a sleep request message from LIN master, or a bus inactive frame indicating four seconds of bus inactivity, the user may choose to put the LIN interface to sleep by setting the LIN Sleep attribute to TRUE in application code.
LIN Protocol Standby Mode
The Standby Mode of a LIN network is also a low-power mode and is the mode the transceiver transitions to when a wakeup request is sent, but the EN pin is still in a low state. The main difference between Standby and Sleep mode is that in Standby mode, the RDX output is low, while in Sleep mode the RDX output is floating. This signals to the controller that the device is in Standby mode after a wakeup request, and can be transitioned into Normal Mode through the control of the EN pin. The LIN transceiver turns on in Standby mode by default if the EN pin will not be held high at power-up.
LIN Protocol Wake-Up Mode
The LIN protocol is having another mechanism for waking the ECUs/Noces/devices on the bus. Wakeup is one task that may be initiated by any node on the bus (a slave as well as the master also). All LIN transceivers have pins specific to waking the device from Sleep mode (if they have sleep mode), and these can be used instead of the LIN bus wake-up request. The WAKE pin on LIN transceivers is typically a high-voltage pin and responds to either a negative transition (high-to-low voltage level), positive transition (low-to-high voltage level), or both. The EN pin is an I/O level pin in LIN transceiver controlled by the LIN controller from microcontroller chip and can also be used to transition in and out of Sleep mode, though the transition polarity matters. A negative transition in this EN pin places the device into Sleep mode, while a positive transition puts the device back into Normal mode.
As per the LIN-2.0 specification, the wake-up request from any ECU/node issued by forcing the bus to be dominant for 250 µs to 5 ms. In a LIN network, each slave should detect the wake-up request and be ready to process headers within 100 ms. The master node should also detect the wake-up request and start sending headers when the slave nodes are ready (within 100 ms to 150 ms after receiving the wake-up request). If the master node does not issue headers within 150 ms after receiving the first wakeup request, then the slave requesting wakeup may try issuing a second wake-up request (and waiting for another 150 ms). If the master still does not respond, the slave may issue the wakeup request and wait 150 ms a third time. If there is still no response from a master node, the slave must wait for 1.5 seconds before issuing a fourth wake-up request.
