Precursor: This article assumes the reader is familiar with the Controller Area Network (CAN). If you are new to the Controller Area Network, check out our Introduction to the Controller Area Network (CAN) article first.
Additionally, this article refers to Leader / Follower terminology in place of recognized industry terms that could be construed as expressions of bias.
The Local Interconnect Network (LIN) was developed as a complementally bus standard to the Controller Area Network (CAN bus) to address the need for a cost-efficient network for lower performance devices within the vehicle. While the CAN network was already in place within vehicles, its high bandwidth and advanced error detection capabilities were overkill (and thus, cost-prohibitive) for lower performance applications such as seat and window controllers. Today’s vehicles use a combination of CAN for powertrain and body communications, LIN for low-cost applications such as body electronics, and FlexRay for high-speed synchronized data communication.
NXP's Irina Costachescu provides an overview of CAN FD standard:
History
After the CAN specification was developed in the late 1980s, it was increasingly used by automotive manufacturers to network the various Electronic Control Units (ECUs) together within the car. However, for lower speed, less critical functions the CAN bus became too expensive to implement. Manufacturers began using a variety of serial communication technologies to address this, but this caused compatibility issues. A consortium comprised of five European automakers (Audi, BMW, Mercedes-Benz, Volkswagen and Volvo), along with technology companies Volcano Automotive Group (now Mentor Graphics) and Motorola (now NXP) was founded in the late 1990s to develop the LIN specification, and the first version was published in 1999. The LIN Consortium developed and maintained the specification up to v2.2 in 2010. In 2013, the LIN specification was transcribed to the International Organization for Standardization (ISO) and was released as ISO standard ISO 17987 in 2016.
Architecture
The LIN bus is a broadcast serial network with one leader node and up to fifteen follower nodes configured on a single, 12V wire up to 40 meters in length. A leader contains both a leader task and a follower task, and the leader task controls all communication over the LIN bus. Follower nodes contain a follower task only and cannot initiate communication at all; they can only (1) ignore, (2) subscribe (receive) or (3) publish a response. The leader node can also act as a follower by replying to its own messages.
LIN nodes are usually comprised of a microcontroller and a LIN transceiver, but custom hardware or ASICs could also be used. Sensors, actuators or other control devices are connected into the LIN network through the MCU. This arrangement of a LIN leader and its follower nodes as shown in Figure 1 is often referred to as a “LIN cluster.”
Figure 1: LIN Cluster Example
Typically, a LIN leader node transmits a request, known as a header, to each of the follower nodes in turn. This action triggers the follower nodes to returns a response with up to eight data bytes. The header and response together are known as a LIN message frame. The following fields make up the header and response of a LIN frame.
Header:
- Break – Minimum of 13 + 1 bits but most often 18 + 2 bits; acts as Start of Frame.
- Sync – Predefined as Hex0x55 (01010101) and allows LIN nodes to determine the baud rate used by the leader node so they can stay in sync.
- Identifier – 6-bit ID followed by 2 parity bits. The ID identifies each LIN message sent and which nodes should react to it. The parity bits aid followers in determining the validity of the ID so they know whether they should Ignore the data transmission, listen to it, or publish data in response.
Response:
- Data – Followers may respond to a header with 2, 4 or 8 bytes of data. The data length depends on the ID range with values 0-31 indicating 2 bytes, 32-47 indicating 4 bytes and 48-63 indicating 8 bytes.
- Checksum – 8-bit field; ensures validity of LIN frame.
Figure 2: Standard LIN Frame
Frame Types
There are six different types of LIN frames, although most often the first one – unconditional – is used. The differences between the various types only have to do with timing of how they are transmitted or the content of the data bytes; the structure of a frame does not vary between frame types. Let’s look at the different types of frames used.
- Unconditional (ID 0-59) – This is the default form of communication used on the LIN bus in which the leader sends a header requesting information from a specific follower, and the follower reacts accordingly.
- Event triggered (ID 0-59) – The leader polls multiple followers, and if a follower’s data has been updated it responds with its protected ID in the first data byte. A collision can occur if multiple followers respond to an event-triggered frame. In this case, the leader defaults to sending an unconditional frame.
- Sporadic (ID 0-59) – A sporadic header is only sent by leader if it knows a specific follower has updated data. In this case, the leader acts as a follower and provides a response to its own header allowing it to provide follower nodes with dynamic information.
- Diagnostic (ID 60-61) – IDs 60-61 are used to read diagnostics with ID 60 used for leader request, 61 for follower response. Frames always contain 8 data bytes.
- User Defined (ID 62) – Can contain any type of information.
- Reserved (ID 63) – Must not be used in LIN 2.0
Operation
As previously stated, all communication on the LIN bus is initiated by the leader node. The leader controls the sequencing of message frames, which is fixed in a schedule table. A schedule table organizes message frames into slots and sets the interval between the start of a frame and the start of the following frame. LIN frame slots are scheduled based on a LIN cluster time unit which is usually 5-10 milliseconds.
Within an individual LIN cluster, the leader node loops through each of the follower nodes with a request for information, and each follower responds with data when polled. Data is transmitted as data bytes serially over the LIN bus, with a maximum baud rate of 20 kbit/s. Where LIN really gets useful, however, is when multiple LIN clusters are connected via the CAN bus within a larger system, such as a vehicle, as shown in Figure 3 below.
Let’s look at a practical example for this. Figure 3 indicates four LIN clusters connected within a vehicle signifying the four doors. If the driver wants to roll down the passenger window, she pushes a button on the driver door. This triggers one LIN cluster to send a message to another LIN cluster via the CAN bus, telling the second LIN cluster to roll down the passenger window. Similarly, the driver could hit a button on her door to lock all the vehicle doors. The LIN cluster would again send a message to the CAN bus, which passes it along to other LIN clusters, alerting them to lock their doors.
Figure 3: Architecture Example with Multiple LIN Clusters
Error Detection
Per the LIN protocol, error detection is handled by the follower tasks utilizing the checksum field, eliminating the burden of error monitoring from the leader task. If a follower encounters an error in a frame (known as a bit error), it aborts processing of the frame until it detects the next header transmitted by the leader. In the original LIN specification, the classic checksum calculation was done over the data bytes only. Since LIN 2.2 was published, an enhanced checksum algorithm has been used to protect the data bytes as well as the protected ID.
LIN can also provide for error reporting to the network. Whenever a frame received or transmitted by a follower node contains an error in the response field, the follower is required to report a Response_Error status bit to the leader in one of its transmitted frames.
Power Management
In addition to saving on costs the LIN bus also saves power. This is accomplished by utilizing two modes: Sleep and Active. When the leader node sends a diagnostic request (ID 60), each follower on the bus will automatically go into Sleep mode after four seconds of bus inactivity. A wake-up frame may be sent by any node requesting activity on the bus, either the Leader node enacting on its schedule or a Follower node activated by its internal software application (ie button press). After a wake-up signal is received, all nodes run through their start up procedures and wait for the leader to send a Break field.
Benefits of LIN
To summarize the points above, the LIN bus offers several advantages for automotive and industrial use cases. It is particularly useful in complementing the CAN bus by offloading devices where speed and fault tolerances are not critical.
- Lower Cost – LIN’s single-wire implantation, lack of licensing fees and cheaper nodes make it a significantly lower cost bus than CAN overall.
- Commodity Components – The number of automotive nodes has increased from 200 million in 2010 to 700 million today. The advantage of cheaper, smaller, more readily available components for LIN follower nodes cannot be understated.
- Deterministic – Because the leader node delegates pre-determined frame slots on the LIN bus, message frames are predictable, and collisions should not be introduced.
- Self-synchronization – The sync field within a LIN frame allows follower nodes to always stay in sync with the leader, eliminating the need for external oscillators.
- EMI Mitigation – The 20 kbit/s maximum data rate and 40m maximum line length help diminish Electromagnetic Interference (EMI).
- Low-power Mode – Utilization of the Sleep mode is favorable when only sporadic events occur (ie button press) and the bus is not used otherwise.
LIN Applications
LIN’s simplicity and low cost make it an attractive option for automotive subsystems where speed and bandwidth are not the primary concerns. Today’s vehicles contain multiple LIN clusters to control these subsystems and interface with the vehicle’s CAN network via the LIN leaders. Automotive applications where LIN is used today include:
- Steering wheel cluster – radio, cruise control, blinkers, windshield wipers, climate control
- Comfort cluster – sensors for temperature, sunroof, light, humidity
- Powertrain – sensors for speed, position or pressure
- Engine cluster – sensors, small motors, cooling fan motors
- Car doors – side mirrors, windows, seat control and locks
- Seats – occupancy sensors, position motors
Beyond the automotive sector, the LIN bus is being increasingly adopted within appliance and industrial markets as it provides an inexpensive, feature-rich option for applications with multiple connected nodes, such as:
- Manufacturing equipment
- Washing machines
- Refrigerators
- Stoves
- Ovens
- Metal-working machines
NXP LIN solutions
As the world’s largest provider of automotive semiconductors, NXP provides multiple CAN and LIN solutions including MCUs and processors with integrated CAN/LIN controllers, CAN and LIN transceivers, LIN bridge chips, System Basis Chips and development tools and software that support all of these. To get started using LIN in your application, take a look at the examples included within our Model-Based Design Toolbox (MBDT), or within the MCUXpresso IDE or S32K Design Studio IDE.