Local Interconnect Network (LIN)

Local Interconnect Network (LIN)

The Local Interconnect Network (LIN) protocol is a low-cost, serial communication protocol primarily used in automotive applications. It is designed to complement the higher-speed CAN (Controller Area Network) bus by handling simpler, lower-speed tasks. LIN is particularly useful for controlling devices like window regulators, seat adjustments, and climate control systems.

Key Features of LIN Protocol:

  • Single-Wire Communication: Data transmission is done via a bidirectional single wire architecture based on K-line principles (ISO 9141). Every LIN node is connected to the single wire LIN bus (LIN), the supply voltage (VBAT) and a shared ground (GND)

Figure: LIN Bus single wire communication

  • Master-Slave Architecture: A LIN network consists of one master node and up to 15 slave nodes. Every LIN node has a 'slave task' (for ignoring, sending and receiving data), while the LIN master also has a 'master task' responsible for scheduling all communication on the bus, ensuring deterministic and collision-free operation.

Figure: LIN Bus Master Slave architecture

  • Low Data Rate: LIN operates at a maximum data rate of 20 kbps, which is sufficient for its intended applications.
  • Deterministic Communication: The communication is time-triggered, meaning that messages are sent at predefined times, ensuring predictable and reliable data transfer.
  • Error Detection: LIN includes mechanisms for error detection, such as checksums, to ensure data integrity.

The LIN message frame format

Sync Break Field (SBF): The Sync Break Field (SBF) is minimum 13 + 1 bits long, with the last bit reflecting a delimiter. The field acts as a 'start of frame' notice to all LIN nodes on the bus.

SYNC Field: The 8 bit SYNC field has a fixed data value of 0x55 (binary 01010101). This allows the LIN slaves to determine the time between rising/falling edges and thus the baud rate used by the LIN master, allowing them to stay in sync.

Protected ID Field (PID): The Protected ID Field (PID) contains the frame ID (6 bits, allowing for 64 unique IDs), followed by 2 parity bits. This acts as an identifier for each LIN message sent. LIN slaves verify the validity of the ID based on the parity bits and react via below.

  • Ignore the subsequent data transmission
  • Listen to the data transmitted from another node
  • Publish data in response to the header

Data Field: When a LIN slave is polled by the master, it can respond by transmitting 2 to 8 bytes of data. The data bytes contain the actual information being communicated in the form of LIN signals using Intel byte order. The data length can be customized, but it is typically linked to the ID range:

  • ID 0-31: 2 data bytes
  • ID 32-47: 4 data bytes
  • ID 48-63: 8 data bytes

Checksum Field: As in CAN, a checksum field ensures the validity of the LIN frame. The classic 8 bit checksum is based on summing the data bytes only (LIN 1.x), while the enhanced checksum algorithm also includes the identifier field (LIN 2.x). IDs 60-61 always use classic checksum.

LIN frame types

Unconditional Frames: This is the default form of communication where the master sends a header to request information from a specific slave, which responds with data. Note that the LIN master may itself transmit data in response to specific headers

Event Triggered Frames: This frame type enables increased responsivity in the LIN cluster. The master requests data from multiple slaves. A slave responds if its data has been updated, with its protected ID (PID) in the 1st data byte, serving the role of a node source address. If multiple slaves respond, a collision occurs and the master switches temporarily to unconditional frames in order to request data individually from each LIN slave

Sporadic Frames: Sporadic frames allow the LIN master to transmit data onto the LIN bus in a dynamic way. Specifically, a sporadic frame corresponds to a group of unconditional frames that share the same slot in the deterministic schedule. If a signal in one of these underlying frames has updated data, the LIN master will transmit it onto the bus in this slot - and otherwise the slot is silent. If multiple frames have new data, the LIN master transmits the frame with the lowest ID (highest priority).

Diagnostic Frames: In LIN 2.x, IDs 60-61 are used for reading diagnostics messages from the master or slaves. ID 60 (0x3C) is used for the master request(where the master sends both header and response) , 61 (0x3D) for the slave response. The LIN master targets a specific LIN slave by including the Node Address (NAD) in the 1st byte of the response.

Transmission and Reception of Messages in LIN Cluster

Transmission of LIN Frame

  1. Master Sends Header:

  • The LIN master node sends a header to initiate communication.
  • API: The master node uses LinIf_SendFrameHeaders to send the header.

2. Header Reception:

  • The LIN slave node detects the header sent by the master.
  • API: The slave node uses LinIf_HeaderIndication to process the received header.

3. Response Preparation:

  • The slave node prepares the response data based on the header.
  • API: The application layer prepares the data and calls LinIf_Transmit to send the data.

4. Response Transmission:

  • The slave node sends the response data back to the master.
  • API: The LIN driver handles the actual transmission using LinIf_Transmit.


Figure: Frame transmission (slave node)

// Master sends header LinIf_SendFrameHeader(masterHeaderId); // Slave processes header LinIf_HeaderIndication(slaveHeaderId); // Application prepares data PduInfoType pduInfo; uint8_t data[] = {0x01, 0x02, 0x03, 0x04}; pduInfo.SduDataPtr = data; pduInfo.SduLength = sizeof(data); // Slave transmits response LinIf_Transmit(slavePduId, &pduInfo);

Reception of LIN Frame

1. Master Sends Header:

  • The master node sends a header indicating it expects data from a specific slave node.
  • API: The master node uses LinIf_SendFrameHeader to send the header.

2. Header Reception:

  • The slave node detects the header and prepares to receive data.
  • API: The slave node uses LinIf_HeaderIndication to process the received header.

3. Data Reception:

  • The slave node receives the data field and checksum field from the master or another slave node.
  • API: The slave node uses LinIf_RxIndication to handle the received data.

4. Data Processing:

  • The slave node processes the received data and performs any necessary actions.
  • API: The application layer processes the data received via LinIf_RxIndication.

// Master sends header

LinIf_SendFrameHeader(masterHeaderId);

// Slave processes header

LinIf_HeaderIndication(slaveHeaderId);

// Slave receives data

LinIf_RxIndication(slavePduId, &pduInfo);

// Application processes received data

processReceivedData(pduInfo.SduDataPtr, pduInfo.SduLength);



Figure : Frame reception (slave node)

References: https://www.autosar.org/fileadmin/standards/R23-11/CP/AUTOSAR_CP_SWS_LINInterface.pdf

https://www.csselectronics.com/pages/lin-bus-protocol-intro-basics

要查看或添加评论,请登录

Vikesh Kumar Mishra的更多文章

社区洞察

其他会员也浏览了