Local Interconnect Network (LIN): There are many various protocols used in the automotive sector, and not all of them are designed for speed. Throughput may occasionally be subordinated to cost.
The Local Interconnect Network (LIN) bus is one such inexpensive technology that is essential to contemporary automobiles.
The primary purpose of the low-cost, low-speed LIN bus communication protocol is to facilitate communication between different electrical components in a vehicle.
In this extensive reference to the automobile LIN bus, we will examine the features, uses, benefits, frame structure, frame kinds, important distinctions between LIN and CAN, and other topics.
Local Interconnect Network (LIN) Basics
A key component in enabling communication between parts within cars is the Local Interconnect Network, or LIN Bus.
Created to be an adjunct to the more intricate CAN Bus system, LIN provides a less expensive way to link different components of an automobile’s network.
The LIN protocol is noticeably less expensive than its CAN equivalent, although it makes this trade-off by somewhat sacrificing dependability and performance.
For less important communication jobs, LIN is a suitable solution due to its cost-benefit ratio.
The CAN Bus proved too expensive to use for all vehicle components, which led to the creation of the LIN Bus.
LIN Bus has proven to be an effective option in automobile networking by successfully addressing this financial obstacle and offering a more accessible alternative.
Local Interconnect Network Bus History –
To clarify LIN Bus, let’s take a trip down memory lane and examine how LIN Bus has changed over time.
- 1999: The LIN Consortium, comprising automakers like BMW and Mercedes-Benz, introduced LIN 1.0.
- 2000: The protocol saw its first updates with LIN 1.1 and later LIN 2.0.
- 2002: The consortium released LIN 1.3.
- 2003: A major overhaul came with LIN 2.0, introducing numerous modifications.
- 2006: The LIN 2.1 specification was unveiled.
- 2010: The release of LIN 2.2A marked further advancements.
- 2010 – 2012: The SAE adopted LIN 2.0 into its standards as SAE J2602.
- 2016: LIN was formalized globally as ISO 17987:2016.
LIN Bus is still a widely used standard in the automobile sector today, and it is essential to vehicle networking and communication.
Features of Local Interconnect Network (LIN)
The LIN bus offers several features that make it ideal for automotive applications:
- Low Cost: The LIN bus’s low hardware requirements and ease of use make it an affordable option for in-car connectivity.
- Low Speed: Applications that don’t require high data transfer rates can benefit from the LIN bus’s lower operating speed, which typically ranges from 1.2 to 20.0 kbps.
- Master-Slave Architecture: The master node begins communication and manages the data exchange with slave nodes in the master-slave communication architecture used by the LIN bus.
- Single Wire Communication: Wiring complexity is reduced by the LIN bus, which uses a single line for both data transmission and reception, in contrast to other communication protocols that require numerous wires for communication.
How does Local Interconnect Network (LIN) Bus work & Applications of LIN
In compliance with ISO/AWI 17987-8 regulations, the LIN Bus has extended its usefulness beyond automobiles and is now included in the battery power line through the use of a DC-LIN transceiver.
As an essential in modern automotive design, LIN Bus is employed across a multitude of applications, including:
In addition to transforming automotive features, LIN Bus technology is also making an impact on household goods like stoves and washing machines. The growing adoption of LIN Bus indicates that it has many uses, with electronic control units emerging as one of the most prevalent examples.
The LIN bus finds extensive use in various automotive applications, including:
Body Control Modules: In body control modules, the LIN bus is frequently utilized to regulate features like lighting, temperature control, door locks, and window control.
Seat Control: The ability to modify seat position, heating, and ventilation is made possible by the LIN bus, which facilitates communication between the seat control modules.
Mirror Control: Mirror control systems use the LIN bus to fold/unfold mirrors, modify mirror position, and regulate mirror heating.
Sensor Communication: Sensor-to-control module communication is facilitated by the LIN bus, making it possible for features like tire pressure monitoring, rain-sensing wipers, and park assist.
What is a Local Interconnect Network (LIN) protocol?
The LIN protocol is a structured wired communication system made especially for automotive electronics. The architecture it uses is master-slave, meaning that one master device manages the communication flow to one or more slave devices.
Frames, which consist of a header and a response, are used to structure communication inside the LIN network. A designated slave or, in certain situations, the master itself responds to the header that the master sends out to start the conversation.
Furthermore, two separate operating states are built into the LIN protocol: an active mode for continuous communication and a sleep mode for energy conservation when the network is not in use.
LIN Bus Topology
The LIN protocol functions as a master-slave system, with the commander, or master node, handling communication and the responders, or slave nodes, handling requests from the master.
LIN Bus
The cost of the LIN bus is greatly decreased because it is specifically made to work over a regular UART port with little modification. An adaptable and scalable communication architecture is made possible by the LIN bus’s support for up to nodes.
Data is transferred over the LIN bus using a frame-based communication structure that is standardized. A header, a response, and a checksum make up each frame.
Local Interconnect Network (LIN) Frame structure & types
One master device and one or more slave devices make up the polled LIN bus. A master task and a slave task are both present on the master device.
There is only one slave task on each slave device. The master task in the master device controls all communication over the LIN bus.
The frame, which consists of a header and a responder, is the fundamental unit of transfer on the LIN bus. The break, synchronization (sync), and identifier (ID) are the three unique fields that make up the header, which is always transmitted by the master node.
The answer is made up of a data payload and a slave task that is transferred and resides on either the master node or a slave node.
Typically, a break-sync-ID sequence is transmitted in a header that the master job transmits to each slave task as part of an endless loop of polling.
Each slave task is set up to either publish data to the bus or subscribe to data in response to each received header ID before the LIN is started.
Each slave task receives the header, checks ID parity, and then determines whether to publish or subscribe based on the ID. The slave job sends one to eight data bytes to the bus, followed by a checksum byte, if it needs to publish a response.
The slave task reads the data payload and checksum byte from the bus and performs the necessary internal actions if it needs to subscribe.
In a typical slave-to-master conversation, one slave answers with a payload of data after the master broadcasts the identity to the network.
A distinct slave job in the master node facilitates communication between the master and the slave. All data broadcast to the bus is self-received by this job, which acts like a stand-alone slave node.
The master must first change the data values it wishes to send in the internal slave task’s answer before it may transfer data bytes. The internal slave job then sends its data payload to the bus after the master publishes the relevant frame header.
Let’s dive into the specifics of the LIN frame format, focusing on its critical segments.
Break:
The intentional signal that is longer than the typical data or idle bus signal is contained in the ‘Break’ field.
It signals the beginning of a new frame by grabbing the attention of every node in the LIN network. Before actual data is transmitted, this serves as a sort of wake-up call.
- Starts with the Sync Break Field (SBF) or ‘Break’.
- At least 13 + 1 bits in length, commonly 18 + 2 bits.
- Signals the beginning of a frame.
Sync:
The eight-bit ‘Sync’ field, which always has the same pattern (0x55), comes after the ‘Break’.
Every node in the network can synchronize its internal timer to the master’s timing thanks to this pattern, which offers a regular sequence of rising and falling edges.
To guarantee that all nodes accurately read the data that follows, this synchronization is essential.
- Comprises 8 bits.
- Set to a standard value of 0x55.
- Helps nodes sync by measuring the time between signal edges.
Identifier:
Following the ‘Sync’ field, the ‘Identifier’ field indicates the kind of data being transferred and the node that should reply. It has two parity bits that aid in mistake detection after every six data bits.
Both the message’s content and priority are determined by the Identifier; higher priority is indicated by lower numerical values.
Network nodes utilize this information to determine whether to ignore the message, listen in, or get ready to respond in the data field of the ensuing frame.
- Contains 6 bits plus 2 for parity.
- Uniquely identifies each LIN message.
- Slaves verify the ID field’s validity to decide on data interaction.
Furthermore, one slave answering at a time during LIN connection usually eliminates the possibility of data collisions and the requirement for arbitration.
There are 64 potential IDs with 6 bits for identification; 60–61 are set aside for diagnostic use.
Data Bytes
The slave task transmits the data bytes field in the answer. The payload data bytes in this field range from one to eight bytes.
Checksum
The slave task transmits the checksum field in the answer. The eight-bit checksum field’s value can be determined using one of two checksum techniques, as specified by the LIN bus.
The enhanced checksum is computed by adding the protected ID to the data bytes, while the traditional checksum is determined just by adding the data bytes.
In contrast to modulo-255 or modulo-256, the Local Interconnect Network 2.0 standard defines the checksum calculation procedure as the sum of all values and subtraction of 255 each time the sum is higher than or equal to 256.
According to the LIN 2.0 specification, improved checksums are meant to be used with Local Interconnect Network 2.0 slave nodes, while classic checksums are meant to be used with LIN 1.3 slave nodes.
It further stipulates that the classic checksum should always be used for IDs 60 through 63.
The checksum type can be adjusted to either enhanced or classic using an attribute provided by the NI LIN interface. The classic option is the default.
Regardless of the checksum attribute’s setting, IDs 60 through 63 always employ the classic checksum, as per the LIN 2.0 specification.
Six Local Interconnect Network (LIN) Frame Types
Although there are several varieties of LIN frames, “unconditional frames” are used for the great majority of communication in practice.
Observe that all of the following adhere to the same fundamental LIN frame structure; the only differences are in the data bytes’ timing or content.
Unconditional Frames
The standard method of communication is in which a specific slave is asked for information by the master via a header sent to that slave. The pertinent slave responds appropriately.
Event Trigger Frames
The master surveys several slaves. If a slave’s data has changed, it reacts by putting its protected ID in the first data byte. When more than one responds, there is a collision, and the master reverts to unconditional frames.
Sporadic Frames
The master will only send this if it is aware that a particular slave has updated data. To enable slave nodes to receive “dynamic” information, the master “acts as a slave” by responding to its header.
Diagnostic Frames
IDs 60–61 are used to read diagnostics from slaves or masters since LIN 2.0. 8 data bytes are always present in a frame. The master request uses ID 60, and the slave response uses ID 61.
User Defined Frames
ID 62 is a user-defined frame that can include any kind of data in it.
Reserved Frames
Reserved frames, which have ID 63, cannot be used on LIN networks that comply with LIN 2.0.
Advantages of using the LIN Bus
The LIN bus offers several advantages that make it a preferred choice in automotive systems:
Cost-Effective Solution: The LIN bus, which is based on standard UART, is an affordable substitute for more sophisticated and pricey communication protocols like the MOST/Ethernet bus, making it appropriate for applications with limited resources.
Simplified Wiring: The LIN bus simplifies car wiring harnesses with its single-wire communication, which lowers installation costs and facilitates installation.
Low Power Consumption: Compared to other communication protocols, the LIN bus runs slower and uses less energy, which makes it appropriate for battery-powered applications.
Real-Time Communication: For safety-critical applications, prompt data interchange between ECUs is essential, and the LIN bus ensures deterministic and predictable communication.
Key differences of LIN & CAN communication Protocol
Both the Controller Area Network (CAN) and the Local Interconnect Network (LIN) are communication protocols that are utilized in industrial and automotive settings, although they have different functions and unique features.
The main distinctions between the LIN and CAN communication protocols are as follows:
1. Purpose and Application:
- CAN: When numerous electronic control units (ECUs) need to exchange data fast and reliably, real-time, high-bandwidth communication is the main purpose of CAN, a reliable, fast protocol. It is frequently found in automobile systems that regulate the chassis, engine, and gearbox.
- LIN: In contrast, LIN is a low-cost, low-speed protocol that is intended for low-data-rate communication between various automotive components. In non-critical applications where slower data transfer is acceptable, such as door locks, window control, and seat control, it is frequently employed.
2. Data Rate:
- CAN: Higher data rates—typically between 125 kbps and 1 Mbps—are supported by CAN, enabling quick and effective data exchange between ECUs.
- LIN: The much lower data rates that LIN typically works at (19.2 kbps) are adequate for the kinds of applications that it is intended for.
3. Topology:
- CAN: Multiple ECUs are connected to a single communication line using the bus topology used by CAN. Any ECU connected to the network can start a conversation because it allows multi-master communication.
- LIN: A single-master, multiple-slave topology is commonly used by Local Interconnect Network. Slave nodes react to requests issued by the master node, which manages communication on the bus.
4. Cost and Complexity:
- CAN: The high-speed capabilities of CAN and the requirement for strong error-handling methods can make CAN hardware and implementation more costly and complex.
- LIN: LIN is intended to be reasonably priced. Because of its more affordable and straightforward hardware needs, it is appropriate for situations where budget is a major consideration.
5. Error Handling:
- CAN: Advanced error handling and detection capabilities are available in CAN. To maintain dependability, it may identify mistakes like collisions and put plans in place like data retransmission.
- LIN: LIN’s error-handling mechanisms are less complex than CAN’s. Although its error handling may not be as strong, it is frequently adequate for non-critical applications.
6. Power Consumption:
- CAN: The high-speed operation of CAN results in increased power consumption, which may cause issues in situations where power efficiency is essential.
- For CAN communication to comply with the ISO 11898 standard, the normal operating voltage range (ROV) of VCC must be between 4.75V and 5.25V.
- LIN: LIN is suited for situations where power consumption must be kept to a minimum, including in automobile systems, because of its power-efficient design.
- The LIN bus and transceivers usually operate at 12V
Future of Local Interconnect Network (LIN) bus
As the Local Interconnect Network bus protocol has developed over time, other variations with varying features and capabilities have been created. With data transfer speeds of up to 19.2 kbps and enough bandwidth for the majority of applications in a vehicle’s electrical system, Local Interconnect Network 2.0 is the most widely utilized version.
However, additional variations like Local Interconnect Network 2.1, Local Interconnect Network 2.2, and Local Interconnect Network 2.3 have emerged as car systems become more complicated and demand faster data transfer speeds.
Better error-handling techniques, higher data speeds, and extended addressing capabilities are provided by these variations. They are especially helpful in applications requiring more extensive sensor networks or real-time data exchange.
Local Interconnect Network (LIN) standards are always evolving to meet the demands of current vehicles and remain compatible with pre-existing Local Interconnect Network networks.
The Local Interconnect Network bus is a desirable option for automotive applications because of its versatility and backward compatibility.
Conclusion
Modern automobile systems rely heavily on the Local Interconnect Network (LIN) bus as a communication mechanism.
Many applications within a vehicle find it to be an appealing option due to its affordability, ease of use, and dependability.
Automotive manufacturers can improve the functioning and performance of their vehicles by utilizing the Local Interconnect Network bus by comprehending its characteristics, benefits, and implementation.
The Local Interconnect Network bus is anticipated to change along with the automotive sector, keeping up with the demands of increasingly sophisticated car systems.
The Local Interconnect Network bus is still a crucial piece of technology for dependable and effective communication in automotive applications, albeit with its uncertain future.
