Overview of LIN
- Uchi Embedded Solutions

- Mar 27
- 5 min read
Updated: Apr 7
The Local Interconnect Network (LIN) uses a master-slave architecture consisting of one LIN master and one or more LIN slave nodes. Communication begins with a message header, which includes a break field to indicate the start of the frame and a sync field that allows slave nodes to synchronize their clocks. The identifier (ID) field contains a 6-bit message ID along with a 2-bit parity field. This identifier defines the type of message rather than the destination node. Once the ID is received and interpreted, a specific slave node responds with a message consisting of one to eight data bytes followed by an 8-bit checksum. The master node controls the sequence of all message frames based on a predefined schedule, which can be modified as required.
There are multiple versions of the LIN standard. Version 1.3 defines byte-level communication, while versions 2.0 and 2.1 introduce additional messaging features, diagnostics, and configuration services. Despite these enhancements, they remain compatible with LIN 1.3 at the byte level. Various features such as enhanced checksum, node configuration files, diagnostics, functional addressing, and resolution tables are supported depending on the implementation, though some may require application-level handling rather than native API support.

Feature | Supported by NI USB LIN |
LIN 1.3 | Yes |
LIN 2.0 | Yes1 |
Enhanced checksum | Yes |
Off-the-shelf slave node concept | Yes1 |
NCF format | Yes1 |
Diagnostics and slave node configuration | Yes1 |
Byte arrays | Yes |
LIN 2.1 | Yes1 |
New slave node configuration services | Yes1 |
Slave diagnostics class I-III | Yes1 |
Functional addressing | Yes1 |
Resolution table | Yes1 |
1 This feature is not natively supported by the API; however, you can implement the functionality.
Table 1: Comparison of LIN Versions 1.3, 2.0, and 2.1
LIN Frame Format
The LIN bus operates as a polled system with a single master and one or more slave devices. The master node contains both a master task and a slave task, whereas each slave node contains only a slave task. Communication on the LIN bus is fully controlled by the master task. The fundamental unit of communication is the frame, which is divided into a header and a response. The header is always transmitted by the master and includes the break, sync, and identifier fields. The response is transmitted by a slave task, which may reside either in a slave node or within the master node itself, and consists of data bytes and a checksum.
During normal operation, the master polls each slave in a loop by sending a header sequence composed of break, sync, and ID. Before communication begins, each slave is configured to either publish data or subscribe to data for specific IDs. Upon receiving the header, each slave verifies the parity of the ID and determines whether it needs to respond or receive data. If the slave is required to publish, it transmits one to eight bytes followed by a checksum. If it is a subscriber, it reads the incoming data and performs the required internal operations.
In slave-to-master communication, the master broadcasts an identifier, and only one slave responds with the corresponding data. In master-to-slave communication, the master uses its internal slave task to simulate a slave node. This internal task prepares the response data, and when the master sends the appropriate header, the internal slave task transmits the data onto the bus.

Figure 2: LIN Message Frame
1. Break
Each LIN frame begins with a break field consisting of thirteen dominant bits followed by a delimiter bit. This field serves as a clear indication to all nodes on the bus that a new frame is starting.
2. Sync
The sync field follows the break and is transmitted as the fixed value 0x55. This field enables slave nodes with automatic baud rate detection to measure the bit timing and adjust their internal clock to match the master.
3. ID
The identifier field is the final part of the header and determines the meaning of the message and which node should respond. All slave nodes continuously monitor the bus for identifiers, verify their parity, and decide whether to act as publishers or subscribers. The LIN protocol supports a total of 64 identifiers. IDs ranging from 0 to 59 are used for standard data frames, 60 and 61 are reserved for diagnostic communication, 62 is available for user-defined purposes, and 63 is reserved for future use. The ID is transmitted as a protected byte, where the lower six bits represent the identifier and the upper two bits contain parity information calculated using predefined XOR operations.
4. Data Bytes
The data field is part of the response transmitted by the slave and contains between one and eight bytes of payload data, depending on the message requirements.
5. Checksum
The checksum field is used for error detection and is also transmitted by the slave node. LIN supports two checksum calculation methods: classic and enhanced. The classic checksum is calculated using only the data bytes, while the enhanced checksum includes both the data bytes and the identifier. According to the LIN 2.0 specification, the checksum is calculated by summing values and subtracting 255 whenever the sum exceeds or equals 256. Classic checksum is used for LIN 1.3 compatibility, while enhanced checksum is used for LIN 2.0 nodes. However, identifiers from 60 to 63 always use the classic checksum regardless of configuration.

Figure 3: Creation of LIN Frames
LIN Bus Timing
Since LIN is a polled bus, each frame is assigned a specific time slot. The nominal header time is defined as 34 times the bit duration, while the response time depends on the number of data bytes and is calculated as 10 times the sum of data bytes plus one, multiplied by the bit duration. The total frame time is the sum of header and response times. Maximum timing values are also defined, allowing for tolerances in communication delays.
LIN Topology and Behavior
A LIN network consists of a single master node and multiple slave nodes forming a cluster. Each node is described by a Node Capability File (NCF), which defines its features and behavior. These files are used to generate a LIN Description File (LDF), which describes the complete system behavior, including communication schedules, baud rates, and node responses. The master node uses this information to control communication by transmitting headers, while slave nodes respond according to the defined behavior.
LIN Error Detection and Confinement
Error detection in LIN is primarily handled by slave nodes. When a slave detects an error in a frame, it stops processing the frame and waits for the next header sequence. The protocol does not require complex error handling such as multiple error tracking or error counters. LIN also defines a Response_Error status bit, which allows a slave to notify the master about errors in transmitted or received responses. This bit is set when an error occurs and cleared after being reported.
LIN Sleep and Wakeup
LIN supports low-power operation through sleep and wakeup mechanisms. The master can command all slave nodes to enter sleep mode by sending a specific diagnostic frame. Additionally, nodes automatically enter sleep mode if the bus remains inactive for more than four seconds. Wakeup can be initiated by any node by driving the bus dominant for a specified duration. After wakeup, the master resumes communication within a defined time window.
Advanced Frame Types
LIN defines several frame types based on timing and functionality. Unconditional frames are the most commonly used and carry regular data. Event-triggered frames are used to reduce bus load by allowing multiple slaves to respond only when their data changes, although collisions may occur and must be resolved by the master. Sporadic frames are transmitted only when necessary, typically when data changes, and are usually managed by the master. Diagnostic frames are used for configuration and troubleshooting and always contain eight data bytes. User-defined frames allow custom data transmission, while reserved frames are not used and are kept for future expansion.

Comments