Hello Readers, 👋😍
My name is Aravind B N, and I work at "Luxoft India" as a Junar Software Developer. Luxoft has given me several opportunity to work on various projects, which has inspired me to discuss the important processes involved in developing a LIN (Local Interconnect Network) protocol in physical layer part 1. This is part 2 of the LIN protocol. Here we will discuss the LIN data link layer and application layer.
LIN Data Link Layer
In the OSI architecture, the Data Link Layer is responsible for reliable data transfer as well as the establishment and termination of connections between two nodes. It is also in charge of overseeing the flow control methods used by these nodes.
The LIN network is a broadcast-serial one. A Master-Slave approach to medium access control is used by the data link layer. Only one Slave may respond to a certain message identification; all messages are started by the Master. The Master node manages the issue of data frames on the bus, ensuring that they are sent at the proper intervals and periodicities and receiving enough time on the bus for each frame.
LIN Frame Format
LIN Master
Break Field : The Sync Break Field (SBF) aka Break is minimum 13 + 1 bits long. The Break field acts as a “start of frame" notice to all LIN nodes on the bus.
Sync Field : The sync field, transmitted by the master task in the header as 0x55/0xAA, enables automatic baud rate detection and synchronization for slave devices on the bus.
ID Field : The ID field in a LIN network header identifies messages for node communication with 64 supported IDs (0 to 59 for data), (60-61 for diagnostics), (62 for extensions, and 63 reserved). It is a protected byte with lower 6 bits as raw ID and upper 2 bits as parity.
Frame IDs are split into 3 categories:
- Normal signal/data carrying frames are 0-50 (0x00-0x3B).
- Diagnostic and configuration data are carried by registers 60 (0x3C) and 61 (0x3D).
- The addresses 62 (0x3E) and 63 (0x3F) are reserved for future protocol improvements.
Parity Bits
The parity bits are calculated as follows:
P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4
P1 = ! { ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5 }
LIN Slave
Data Bytes: The data bytes field is transmitted by the slave task in the response. This field contains from one to eight bytes of payload data bytes.
Checksum: The LIN network's checksum field, sent by the slave task in the response, can be calculated using two algorithms. The Classic checksum sums only the data bytes, while the Enhanced checksum includes both the data bytes and the protected ID.
The Master node manages the use of classic or enhanced checksums, which are determined per frame identifier; classic in communication with LIN 1.x Slave nodes and enhanced in communication with LIN 2.x Slave nodes.
Signals
A signal is carried in the data field of a LIN frame. Each signal has exactly one publisher, which means it is always written by the same node in the cluster. The signal can be subscribed to by zero, one, or multiple nodes. All signals have initial values. The initial value of a published signal is valid until the node writes a new value to this signal. The initial value of a subscribed signal is valid until a new updated value is received from another node.
Signal Types
A signal is either a scalar value or a byte array for a specific data frame.
A scalar signal is between 1 and 16 bits long.
A 1-bit scalar signal is referred to as a Boolean signal.
Scalar signals with sizes ranging from 2 to 16 bits are treated as unsigned integers.
A byte array is an array of one to eight bytes.
Frame Type
_Unconditional Frames :_The standard mode of communication in which the master sends a header requesting data from a specific slave. The relevant slave responds appropriately.
Event Trigger Frames : The master polls a large number of slaves. If its data has been updated, a slave responds with its protected ID in the first data byte. When multiple people respond, a collision occurs, and the master falls back to unconditional frames.
Sporadic Frames : Only sent by the master when it knows a specific slave has updated data. The master "acts as a slave" and responds to its own header, allowing it to provide slave nodes with "dynamic" information.
Diagnostic Frames : IDs 60-61 have been used for reading diagnostics from masters and slaves since LIN 2.0. Frames are always 8 bytes long. ID 60 is assigned to the master request, and ID 61 is assigned to the slave response.
User Defined Frames : ID 62 is a user-defined frame that can hold any type of data.
Network Management (NM)
Sleep mode
The Master enters the LIN cluster into Bus Sleep mode by sending a go to sleep command. The go to sleep command is a Master request frame with the first data field set to 0 and the rest field set to 0xFF. 
Wake Up
- Any node can request a wakeup.
- From 250 s to 5 ms, node forces are dominant.
- All nodes should then wake up within 100 milliseconds of the end of the wakeup signal.
- The master node must transmit within 150 milliseconds.
Time Reserve
Delays may occur because low-cost LIN slaves are frequently underperforming. To mitigate this, inter byte space can be added as shown below. Furthermore, there is a'response space' between the header and the response that gives slave nodes enough time to react to the master's header. 
LIN Application Layer
The Local Interconnect Network (LIN) network cluster configuration, i.e. the specification of:
Network publishers and subscribers.
The LIN Description File (LDF) manages signal frames.
This is an ASCII-text file generated by the network designer and distributed to vendors developing LIN Master/Slave node hardware/software.
ANSI-C driver code and header files are generated automatically from the LDF using appropriate tools.
LDF
Defined by consortium.
Global description language: - One single file describes a complete LIN network. - Universal file for embedded software, test, validation, and analysis tools.
Defines cluster information: - Protocol Version. - Language Version. - Bus Speed. - Node List. - Signals. - Frames. - Schedule Tables.
LDF Header Section
LIN_description_file;
LIN_protocol_version = "2.1";
LIN_language_version = "2.1";
LIN_speed = 19.2 kbps;
Nodes {
Master: MyECU, 5 ms, 0.1 ms ;
Slaves: Slave1, Slave3 ;
}
LDF Signal Section
Signals {
Sig_ErrBit_RearECU: 1, 0, Slave1, MyECU ;
Sig_ErrBit_Slave3: 1, 0, Slave3, MyECU ;
Sig_StartAppl_LinData_Tx: 8, 0, MyECU, Slave1 ;
Sig_StartAppl_LinData_Rx: 8, 0, Slave1, MyECU ;
Sig_LinTr_MyECU2_0: 6, 0, MyECU, Slave3 ;
Sig_LinTr_MyECU2_1: 14, 0, MyECU, Slave3 ;
Sig_LinTr_Slave3_0: 4, 0, Slave3, MyECU ;
Sig_LinTr_Slave3_1: 12, 0, Slave3, MyECU ;
Signal1_Tx_msg1: 8, 0, MyECU, Slave1 ;
Signal2_Tx_msg1: 8, 0, MyECU, Slave1 ;
Signal3_Tx_msg1: 8, 0, MyECU, Slave1 ;
Signal4_Tx_msg1: 8, 0, MyECU, Slave1 ;
Signal1_Rx_msg1: 8, 0, Slave1, MyECU ;
Signal2_Rx_msg1: 8, 0, Slave1, MyECU ;
Signal3_Rx_msg1: 8, 0, Slave1, MyECU ;
Signal4_Rx_msg1: 8, 0, Slave1, MyECU ;
Signal1_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal2_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal3_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal4_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal5_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal6_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal7_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal8_Tx_msg2: 8, 0, MyECU, Slave1 ;
Signal1_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal2_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal3_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal4_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal5_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal6_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal7_Rx_msg2: 8, 0, Slave1, MyECU ;
Signal8_Rx_msg2: 8, 0, Slave1, MyECU ;
}
LDF Frame Section
Frames {
Frame_LinTr_MyECU: 17, MyECU, 1 {
Sig_StartAppl_LinData_Tx, 0 ;
}
Frame_LinTr_Slave1: 18, Slave1, 2 {
Sig_StartAppl_LinData_Rx, 0 ;
Sig_ErrBit_RearECU, 8 ;
}
Frame_LinTr_MyECU2: 19, MyECU, 3 {
Sig_LinTr_MyECU2_0, 0 ;
Sig_LinTr_MyECU2_1, 6 ;
}
Frame_LinTr_Slave3: 21, Slave3, 3 {
Sig_LinTr_Slave3_0, 0 ;
Sig_LinTr_Slave3_1, 4 ;
Sig_ErrBit_Slave3, 16 ;
}
Tx_msg1: 35, MyECU, 4 {
Signal1_Tx_msg1, 0 ;
Signal2_Tx_msg1, 8 ;
Signal3_Tx_msg1, 16 ;
Signal4_Tx_msg1, 24 ;
}
Rx_msg1: 48, Slave1, 4 {
Signal1_Rx_msg1, 0 ;
Signal2_Rx_msg1, 8 ;
Signal3_Rx_msg1, 16 ;
Signal4_Rx_msg1, 24 ;
}
Tx_msg2: 36, MyECU, 8 {
Signal1_Tx_msg2, 0 ;
Signal2_Tx_msg2, 8 ;
Signal3_Tx_msg2, 16 ;
Signal4_Tx_msg2, 24 ;
Signal5_Tx_msg2, 32 ;
Signal6_Tx_msg2, 40 ;
Signal7_Tx_msg2, 48 ;
Signal8_Tx_msg2, 56 ;
}
Rx_msg2: 1, Slave1, 8 {
Signal1_Rx_msg2, 0 ;
Signal2_Rx_msg2, 8 ;
Signal3_Rx_msg2, 16 ;
Signal4_Rx_msg2, 24 ;
Signal5_Rx_msg2, 32 ;
Signal6_Rx_msg2, 40 ;
Signal7_Rx_msg2, 48 ;
Signal8_Rx_msg2, 56 ;
}
Send_Frame_1: 49, MyECU, 4 {
Send_Signal_1, 0 ;
Send_Signal_2, 8 ;
Send_Signal_3, 16 ;
Send_Signal_4, 24 ;
}
Send_Frame_2: 50, MyECU, 8 {
Send_Frame_2_Signal_1, 0 ;
Send_Frame_2_Signal_2, 8 ;
Send_Frame_2_Signal_3, 16 ;
Send_Frame_2_Signal_4, 24 ;
Send_Frame_2_Signal_5, 32 ;
Send_Frame_2_Signal_6, 40 ;
Send_Frame_2_Signal_7, 48 ;
Send_Frame_2_Signal_8, 56 ;
}
}
This is Second part of the LIN Protocol next article based on Communcation process of LIN protocol alone with example.
Do let me know if you have any queries in the comments below.
Thanks for reading.
Top comments (0)