1

LIN Bus – An Emerging Standard for Body Control Applications

By Johann Stelzer, European Marketing Manager

Automotive Products Group

Microchip Technology Inc.

Introduction

The Local Interconnection Network (LIN) standard is the first to address Class A open-multiplexing protocols within vehicles. It defines a low cost, serial communication system for distributed electronic systems which are expanding within the vehicles of today and the future. LIN complements the existing portfolio of automotive multiplex networks led by CAN. By 2010, it is estimated that an average of twenty LIN nodes per vehicle will exist. With the continuing emergence of automotive electronics, body control applications represent a significant segment of the vehicle wherein LIN supports the facilitation of networks that do not need excessive bandwidth, performance or complexity.

LIN is a holistic communication concept for local interconnect networks in vehicles. LIN enables a cost-effective communication network for switches, smart sensors and actuator applications within the vehicle where the bandwidth and versatility of CAN is not required. The communication protocol is based on the SCI (UART) data format, a single-master/multiple-slave concept, a single-wire 12V bus, and a clock synchronization for nodes without a stabilized time base. The LIN consortium developed a standard for serial low cost communications in conjunction with a development environment, that enables car manufacturers and their suppliers to create, implement and handle complex hierarchical multiplex systems in a very cost-effective manner.

The LIN specification covers the transmission protocol, the transmission medium, the interfaces for development tools and application software. LIN supports the interoperability of network nodes from the viewpoint of hardware and software, with predictable EMC behavior. This concept allows the implementation of a seamless chain of development and design tools while enhancing the speed of development and the reliability of the network.

Typical Body Control Applications for LIN

Body control electronics improve the comfort and safety of vehicle occupants. Advancing body control electronics is an essential element in the ability of car manufacturers to produce smarter vehicles that are pleasing to drive, reliable and safer. Body control electronics improve the safety factor of a vehicle by simplifying the operation of the vehicle and releasing the driver of distractions from secondary activities

Typical applications for the LIN bus include assembly units such as doors, steering wheel, seats, and motors and sensors in climate control, lighting, rain sensors, smart wipers, intelligent alternators, switch panels and RF receivers. They can be easily connected to the car network and become accessible to all types of diagnostics and services. The commonly used analog coding of signals is being replaced by digital signals, leading to an optimized wiring harness.


Figure 1: Body Control Electronics - LIN Bus Application Targets

In a centralized body control system, actuators and sensors are hardwired to one electronic control unit (ECU) with CAN connectivity. One ECU exchanges signals via a CAN link with other main ECUs. Hardwiring is chosen if the local actuators and sensors require high computing performance. In systems where the local performance can be low, an alternative distributed system based on smart actuators and sensors can be used. This partitioning is chosen in order to achieve a scalable system architecture with universally applicable components.

This architecture is cost effective if the additional expenditure for the local intelligence and networking can be compensated by cost savings in production and development, due to fewer total electronic components. The key enablers for this architecture are the sub-bus LIN standard, low-cost mechatronic assembly and semiconductor integration.

With LIN residing in low-end applications, two factors are critical: (a) the communication cost per node must be significantly lower compared with CAN; (b) the performance, bandwidth and versatility of CAN are not required. The main cost savings of LIN versus CAN are derived from: (1) the single-wire transmission of LIN, (2) the low cost of implementation as hardware or software in silicon, and (3) the avoidance of crystals or ceramic resonators in slave nodes. These advantages are compromised of a lower bandwidth and the restrictive single-master bus access scheme. The main features of the LIN and CAN protocols are shown in Table 1.


Table 1: Overview of LIN and CAN Protocols

LIN Protocol

LIN is a single-wire serial communications protocol based on the common SCI (UART) byte-word interface. UART interfaces are available as low-cost silicon modules on almost all microcontrollers. LIN can also be implemented with software-equivalent code or pure state machines. The medium access in a LIN network is controlled by a master node so that no arbitration or collision management of the slave nodes is required, thus providing a guarantee of the worst-case latency times for signal transmission.

Figure 2: Automotive Communication Protocols


The Key Features of LIN are:

- Low-cost, single-wire implementation
- Enhanced ISO 9141, VBAT-Based
- Speeds of up to 20Kbit/s (limited for EMC reasons)
- Single Master/Multiple Slave Concept
- No arbitration required
- Low-cost silicon implementation based on common (UART/SCI) interface hardware
- Self synchronization in the slave nodes without a crystal or ceramic resonator
- Significant cost reduction of hardware platform
- Guaranteed latency times for signal transmission
- Predictable systems possible

A particular feature of LIN is the synchronization mechanism that allows the clock recovery by slave nodes without the need for a crystal or ceramic resonator. The specification of the line driver and receiver follows the ISO 9141 single-wire standard with some enhancements. The maximum transmission speed is 20 kbit/s, resulting from the requirements by EMC and clock synchronization.

A node in LIN networks does not make use of any information about the system configuration, except for the denomination of the master node. Nodes can be added to the LIN network without requiring hardware or software changes in other slave nodes. The size of a LIN network is typically under 12 nodes (though not restricted to this), resulting from the small number of identifiers and the relatively low transmission speed. The clock synchronization, the simplicity of UART communication, and the single-wire medium are the major factors for the cost efficiency of LIN.

Figure 3: LIN Bus Network


Communication Concept

A LIN network is comprised of one master node and one or more slave nodes. All nodes include a slave communication task that is split into a transmit and a receive task, while the master node includes an additional master transmit task. The communication in an active LIN network is always initiated by the master task.

The master sends out a message header that contains the synchronization break, the synchronization byte and the message identifier. Exactly one slave task is activated upon reception and filtering of the identifier, and starts the transmission of the message response. The response contains two, four or eight data bytes and one checksum byte. The header and the response form one message frame.

The identifier of a message denotes the content of a message but not the destination. This communication concept enables the exchange of data in various ways: from the master node (using its slave task) to one or more slave nodes, and from one slave node to the master node and/or other slave nodes. It is possible to send signals directly from slave to slave without the need for routing through the master node, or broadcasting messages from the master to all nodes in a network. The sequence of message frames is controlled by the master. The number, sequence and frequency of messages in the scheduling frame of the master determine, along with the baud rate, the system response time and time behavior. Careful system design is necessary since, if the master missed a slave message, this message will reach the master earliest at the next schedule sequence due to the master-slave concept.

Figure 4: LIN Message Frame

The LIN protocol provides a dedicated synchronization pattern with the start of every message frame that allows slave nodes without crystal or a ceramic resonator to synchronize their local time base to that of the master.

LIN Physical Layer

The LIN bus is a single wire bus being supplied via a termination resistor from the positive battery node Vbat. The bus line transceiver is an enhanced implementation of the ISO 9141 standard. The bus can take two complementary logical levels: The dominant value with an electrical voltage close to ground represents a logical ‘0’, and the recessive value with an electrical voltage close to the battery supply voltage represents a logical ‘1’.

The bus is terminated with a pull-up resistance of 1 kOhm in the master and 30 kOhm in a slave. The termination capacitance is typically 220 pF in the slave nodes. The capacitance in the master node is higher in order to make the total line capacitance less dependent on the number of slave nodes.

Significant electrical parameters of the LIN physical layer are listed in Table 2.

Table 2: Major Parameters of the LIN Physical Layer

The LIN physical layer specification puts high performance requirements on the transceiver. The switching of the transceiver must not disturb other electronic components. Special care has to be taken to meet the EMC requirements of the carmakers. Wave shaping or edge rounding is applied to minimize radiated emissions of the transceiver.

Figure 5: Example of a Physical LIN Transceiver Implementation with Integrated Voltage Regulator

LIN System Implementation and Development Process

Right from the beginning, the LIN consortium not only specified the communication protocol but put high emphasis on a consistent, homogenous and defined LIN system-development process. The LIN workflow concept allows for the implementation of a seamless chain of design and development tools. The key element of the whole development process is the LIN Description File (LDF). LDF describes the complete behavior of the LIN network or LIN cluster as it is called since the release of LIN specification 2.0.


LDF can be created manually or with the System Generator Tool. Also, new with LIN 2.0 are the LIN Node Capability Files. Node Capability Files define baud rates, protocol versions, and define signals and messages. The LIN Node Capability Language provides the syntax for specification of off-the-shelf slave nodes. Thus, Plug –and-Play with nodes in a cluster becomes reality.

Manufacturers of Slave Nodes supply the Node Capability File with the components. This enables the system integrator to develop the LIN Description File for his specific cluster.

Figure 6: LIN Work Flow Concept

LIN Bus System Example: Door/Mirror Module

The increasing numbers of electronic functions in car doors make them a good example for the usage of LIN bus. Functions can be added or removed while maintaining the same system design and without any impact to hardware and software of the remaining slave nodes. It allows the integration of pre-assembled and pre-tested modules as the functions or options grow during the development process and at the end-of-line assembly of the vehicle. The functions in the door LIN cluster include:

· Window Lift with/without anti pinch control

· PWM control of the motor, position monitoring of the window

· Door lock actuator control, including motor control (dead lock) and door opening contact control

· Switch panel control

· Switch illumination

The mirror function can be integrated on one or more LIN slave nodes, depending on the flexibility the OEM plans in order to offer optional functions to the user. These mirror functions include mirror up/down, in/out motor control, heating, puddle lamp, turn indicator, dimming (electro-chromatic mirrors) and power fold.

Figure 7: LIN Door Module

The requirement for the master node can be covered by high-performance 8-bit microcontrollers with CAN interface and USART/Enhanced USART. Memory requirement and package size demand depend on the software functions, CAN software stack and hardware I/O requirements.

Slave node functions in this example are typically within the scope of lower performance but cost-effective 8-bit microcontrollers. Generally, I/O demand is covered in 14-pin to 28-pin packages while program memory ranges from 2 KB to 16 KB, depending on the complexity of control functions.

LIN Slave Implementation

Depending on the complexity of the LIN slave application and budget allocated for the slave microcontroller, LIN can be implemented in software, by using a Standard USART, with an Enhanced LIN USART or with dedicated LIN hardware.

Pure software implementation works for systems with low complexity, such as for example switch panels, temperature sensors and LED displays. At the expense of a relatively high CPU load, the customer achieves the lowest cost solution. The PIC16C433 from Microchip Technology is an example of an integrated microcontroller solution with an on-chip RC oscillator and the physical transceiver interface in a single package. This configuration offers a highly integrated low-cost LIN solution for space-constrained applications.

More complex systems, such as actuators and motors, require more CPU performance and utilize LIN implementations with a standard USART. The CPU is offloaded, compared to a software LIN solution, by USART hardware features. Sync Break is detected with the USART hardware, generating a Frame Error. The costs of a slave node using a standard USART are higher, due to a larger silicon area and the need for an external resonator or crystal. Microchip’s PIC16F7X family supports this type of implementation.

Systems with higher complexity require even more free CPU performance for the application. This need can be addressed with an Enhanced LIN USART (EUSART). The EUSART features automatic Sync Break detection and Auto Baud Rate measurement and generation. These features offload the CPU. They also work well with the on-chip RC oscillator, and thus help reduce system costs. Microchip’s PIC16F688 supports this implementation.

One of the key features of the LIN protocol is its synchronization capability for slave nodes using low cost oscillators. The LIN specification allows +/-15% clock deviation for an unsynchronized slave node. If the clock deviation is greater than 15%, a data byte with the value zero sent by the master will be recognized from the slave as a Sync Break. For correct communication, the slave must be able to resynchronize and remain stable for the time of a LIN frame with better than +/- 2%.

This requirement can be met with the calibrated internal RC oscillators of some semiconductor vendors’ implementation on microcontrollers. The internal oscillator is tuned and compensated against temperature and voltage variation.

Figure 8: Example of LIN Slave Node

Summary

Never before in the automotive electronics market has a standard been adopted so quickly. From the concept of the LIN Standard in late 1998 to the introduction of the first production car series in 2001, less than 3 years elapsed. With its emergence in the European market, LIN has gained significant global interest.