Re-evaluating the role of the LIN Bus in vehicle sensor and control applications -

Re-evaluating the role of the LIN Bus in vehicle sensor and control applications


When Galvin Manufacturing Corp. (today’s Motorola) introduced the fitted car radio in the 1930s, few could imagine what the future would look like. For years the only electronic component in a car was the radio. The infotainment system in today’s automobile is just one of the many systems that are electrically controlled: the number of electronic control units (ECU) in a modern car today can be as high as 80 (Figure 1 ). No wonder the market for automotive electronic components has been on the rise and is expected to hit $18.5B by 2018.

In the initial years, the practice was to have standalone autonomous electronic systems. It was soon realized that there was a need for a mechanism to enable systems to communicate with each other. This led to the introduction of networks such as serial communication channels (bus) that would co-ordinate the individual electrical systems and lead to improved functionality of the vehicle as a whole.

Figure1: Multiple electrical systems in a car

In 1983, Bosch began developing the Controller Area Network (CAN) bus and officially released the protocol in 1986. Even today, when different vehicle bus standards are available, CAN continues to be the most popular. In a CAN network, all the nodes (originating from different ECUs) act as master (i.e., there is no master-slave topology) and are not assigned specific addresses. Rather, messages contain ‘identifiers’.

At a given time, multiple nodes may transmit data to the CAN bus. The message identifier then helps determine the priority of the messages. The highest priority message will pull the CAN bus to the dominant state and all the other nodes stop transmitting. The nodes are in fact transceivers and, based on specific functions, they may look out for specific messages from the bus, apart from transmitting messages. Thus, information flow happens between different nodes connected to a CAN bus.

CAN is highly reliable because of multiple error checks, such as stuffing errors, bit errors, checksum errors, frame errors, and acknowledgment errors. In terms of data rate, CAN supports up to 1MB/s. Thus CAN is the default choice for connecting critical function ECUs in vehicles (e.g., gear box, temp sensor, etc.).

However, the role of electronics in automobiles is not limited to these critical units only. Over the years, the market for automotive body electronics has been increasing. Example body control applications are seats, windows, smart wipers, and climate control sensors. For body electronics, the key requirement is to ensure improved comfort and safety of the vehicle. These are systems that may not require as high reliability as the critical ECUs do, but they still require an automotive standard for communicating over a network.

The different systems and the type of network they require are categorized below:

  • Conventional body and power train applications use protocols with real-time properties, and mainly require CAN.
  • Multimedia applications require higher bandwidth, speed, and even wireless interconnection. Bluetooth, MOST, or Firewire are some of the networks used for these applications.
  • Safety critical applications require protocols that are reliable and fault tolerant. TT-CAN (Time-Triggered CAN) and FlexRay are typical of such networks.
  • Smart sensors and actuators in seats, windows, wipers, and even some complex ECUs have simpler communication needs. These applications are usually addressed by custom OEM protocols and don’t require a CAN or FlexRay interface for communication.

For the last category, where OEMs use their own protocols, difficulties arise such as the complexity and expense for suppliers to the OEMs to design different systems without the benefit of a standard. Thus arose the formation of the LIN consortium by different automakers in the late 1990s. The consortium eventually implemented a standard for networking in these types of systems called LIN in 2002.

Unlike the more sophisticated and widely used CAN bus, LIN (Local Interconnect Network) is a serial network protocol used for communication between components in vehicles and arose out of the need for an inexpensive serial communications protocol between microcontroller-based sensors within an automobile.

CAN is more expensive to implement than LIN. Factors that contribute to the higher cost of CAN include:

  • Each node in a CAN network requires a clock generator or crystal
  • At a silicon level, CAN is more complex to implement
  • 2-wire transmission is used.

Most importantly, the entire expensive architecture is overkill for applications that demand neither high reliability nor high data rates.

Due to the above drawbacks, the need for LIN networks has increased. The role of the LIN bus is to complement the CAN bus, not replace it. It is an inexpensive serial communications protocol that supports remote and non-critical applications in a car’s network. Unlike CAN, LIN works on a master-slave topology. Typically the network comprises one master and up to 16 slaves. All communication is initiated by the master node. Because all the nodes are clocked by the master, a precision clock is required only in the master node. This is one of the reasons that LIN is less expensive than CAN (where all the nodes require crystal or precision clock generator).

Features and benefits of LIN
The key features and benefits of LIN are as follows:

  • Complementary role – As already stated, the role of LIN is not to replace CAN but to complement it. This feature helps CAN to extend to remote hierarchical sub-networks within applications.
  • Single-wire implementation – LIN’s low-cost, single-wire implementation (contrary to CAN’s twisted pair implantation) reduces cost considerably.
  • Data rate – Data rates are limited to 20Kbps (for EMI control reasons). This helps maintain the reliability of the network.
  • Broadcast serial network – The LIN network can have one master and up to 16 slave nodes. All messages originate at the master, and at most one slave responds, based on the message identifier.
  • Self-synchronization – No crystal or resonator is required, thus lowering implementation cost significantly.
  • Latency time – LIN networks provide guaranteed latency times, making it a more predictable network
  • Overall implementation- LIN is less expensive and simpler to implement than CAN. In the case of CAN, each node requires a CAN interface, crystal, and 2-wire connection. LIN can work with a simple serial communication block (SCB) and an enhanced ISO 9141 interface. No crystal is required and the connection is a single wire.

Table 1 offers a quick comparison of LIN and CAN features to assist developers in selecting one network over the other, depending on the requirements for different parameters:

Table1: Comparison of LIN and CAN

Components of a LIN-based system
Setting up a LIN based systemis far less complicated than setting up a CAN based system. Thecomponents required in LIN-based systems are:

  • Physical transceivers (PHY)
  • Microcontroller with serial communication blocks (SCB)/interfaces
  • Development tools: s/w

A typical LIN network looks like the system shown in Figure 2, with one master and multiple slaves nodes.

                                                      1 Engine Control Unit
                                                      2 Serial Communication Block
                                                      3 Physical transceiver

Figure 2: Typical LIN network

Noteon physical transceivers: Most LIN implementations use a transceiver tomanage the interfacing and support the higher voltage levels. Thesetransceivers are typically external to a microcontroller.

To actas a Slave node in a LIN network, an MCU requires an SCI (serialcommunication interface) or an SCB (serial communication block) that cansupport a UART for interfacing. The LIN protocol uses UART as the basemeans for transmitting and receiving. If a UART is not available in thehardware of the MCU, it can alternately be implemented using software.However, such a method is not recommended as it unnecessarily loads theprocessor. To act as a master node, we would need a more high-end MCU.Apart from the UART supporting SCI, another requirement for the masternode is the clock generator.

The BUS used in a LIN connection issingle-wire and has to comply with ISO9141. Nowadays, we have moresophisticated automotive-qualified MCUs that have dedicated support forLIN in the form of a built-in LIN PHY. This integration makesimplementation more compact and simple.

Most MCU supplierssupport a LIN interface in at least one of their device families. Anexample is Cypress Semiconductor’s PSoC (Programmable System-On Chip),(, which offers a system-on chiparchitecture integrating programmable logic, memory, and an MCU on asingle chip. These devices support serial communication interfaces thatcan be configured as a LIN, and hence have a good potential to fit inautomotive applications that require LIN.

Apart from the MCU andLIN PHY, development tools such as software modules are usuallyrequired to configure the different parameters of the LIN interface.Processor vendors usually provide design environments that enableconcurrent hardware and firmware design. Cypress, for example, provides PSoC Designer and PSoC Creator . Such tools provide a flexible LIN component or user module that can be programmed to work as per the design requirements.

MCUsuppliers also need to get their LIN interface validated or certifiedagainst conformance tests meeting the LIN specification. Almost all OEMsmandate this requirement, and MCU suppliers need to have compliance as apart of their development process.

The LIN message frame

TheLIN message frame consists of a header and a response. The header has afixed length while the response consists of 0 to 8 bytes of data. Theinter-frame response time is the time it takes for a slave to respond toa request from the LIN master. It may vary among the nodes on thenetwork since it depends on the hardware and software implementation ofthe individual node. Following the response is a checksum, which iscalculated for the data portion of the message frame.

The header is broken up into three fields:

  1. The SYNC-break field is used to activate all attached LIN slaves to listen to the following parts of the header. It consists of one start bit and several dominant bits.
  2. The SYNC-field is a standard data format byte. LIN slaves running on RC oscillator will use the distance between a fixed amount of rising and falling edges to measure the current bit time on the bus to recalculate the internal baud rate.
  3. The identifier (ID) field is sent by the master node to all LIN nodes and normally contains one of 64 different values and includes two parity bits in the 8-bit data. The identifier contains information such as sender, receiver, purpose, and data field length that are subsequently transmitted on the LIN bus.

The structure of the message frame can be seen in Figure 3 .

Figure 3: LIN message frame structure

LIN applications
Wehave already seen what types of automotive applications require LIN.Let’s take a quick look at a list of example applications that LINnetworks are used in (Table 2 ). This is shown in comparison to applications that require CAN to get a better understanding of the differences.

Table 2: Typical LIN applications

Theamount of electronics in a car is constant rising, and so is thecomplexity of its networks. Not far in the future we will see driverlesscars that talk to each other. With the increase in the number andcomplexity of automotive electrical networks, simpler and cheaperalternatives are also growing, and the most popular amongst them happensto be LIN.

LIN has already become the standard for most bodycontrol applications that don’t require CAN type security, and willcontinue to be the most popular option in the future as well. LIN alsokeeps itself updated with latest requirements, releasing newer versions(latest being 2.2A) to meet the newer automotive standards. This alsocalls for the automotive MCU suppliers to be equipped with the latestand greatest version of LIN interfaces, enabling them to play a role inbody control applications.

Sivaguru Noopuran () is a Product Marketing Engineer at Cypress Semiconductor , with more than five years of experience. His primary interests include User Interface products and product management.

Anirban Sengupta works as a pricing manager at Cypress Semiconductor .He holds a BE in Electrical Engineering from the National Institute ofTechnology, India, and an MBA in Marketing from Symbiosis Centre forManagement and Human Resource Development (SCMHRD), Pune, India.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.