LIN Bus--An Emerging Standard for Body Control Applications

Feb. 22, 2005
Body control electronic control units (ECUs) are one of the fastest growing application segments within the automotive environment. In fact, the expansion of ECUs throughout the vehicle has created a need for expanded communications that has led to the “networked vehicle.” With body controllers implementing functions that control seats, windows, door locks, airflow, lighting and wipers, the comfort and safety subsystems of the vehicle are directly impacted by the performance of body control ECUs. This article will illustrate how the LIN bus addresses the automotive industry’s need for “cost-effective, networked ECUs for body electronics.”

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 that 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 20 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. The LIN specification[1] 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 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 (Figure 1). 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. 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 vs. 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. The main features of the LIN and CAN protocols are shown in Table 1. Thus, 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. 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 (Figure 2). 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.

Communication concept A LIN network is comprised of one master node and one or more slave nodes (Figure 3). 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 (Figure 4). 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 earlier at the next schedule sequence due to the master-slave concept. 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. The LIN physical layer specification puts high-performance requirements on the transceiver (Figure 5). 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.

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 (Figure 6). 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.

LIN bus system example 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. As shown in Figure 7, 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; and • 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. 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 (Figure 8). 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 use 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. 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. 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.

Summary In an environment that permits the distributed processing of data across a networked vehicle of connected electronic modules, the system designer is constantly challenged—despite the fact that distributed computing is a commonly accepted methodology for addressing complex computing problems. One of the most significant challenges addressed with the use of LIN is that of interoperability of networked nodes in the harsh environment of vehicles. LIN not only enables a cost-effective way to support the continued expansion of intelligent sensors and actuators within vehicles, but it also guarantees the interoperability of modules from the viewpoint of hardware and software, coupled with a predictable EMC profile. In the harsh environment of the vehicle, many modules are able to achieve maximum LIN-bus specifications, simply by using a crystal oscillator and designing sufficient filtering to support the desired functions. LIN-compliant solutions are able to demonstrate robustness against common hazards associated with harsh environments, plus overcome challenges accompanying the associated noise spikes, ground shifts, bus loading and variations in the duty cycle and level of the supply voltage. Shorter development cycles and a reduced total cost of ownership are key benefits that today’s system designers gain from the impact of the LIN standard and its guaranteed interoperability. With the ever-increasing number of electronic control modules in the vehicle, cost savings and shorter time-to-market cycles remain as critical indices. With the cost savings gained from many LIN-supported electronic control modules, coupled with shorter development cycles, the designers at tier-one suppliers are able to focus on resolving application-oriented challenges. Plus, not being saddled with the implementation of networks within the challenging vehicle environment, the designer is freed to address demanding customer requirements. Overcoming the challenges present in harsh automotive environments remains critical to the long-term evolution of implementing low-cost solutions that are cost effective and reasonable to maintain under the interoperability requirements of the LIN standard.

Connecting to Component and Other Networks

Based on General Motors (GM) engineering experts’ insight into the networks and protocols in body electronics, body electronics subsystems typically include windows, seat, mirrors, heating ventilating and air conditioning (HVAC) and internal lighting controls—items that the driver or passenger can activate that are important to driving comfort but not necessarily high data rate.

A real-time control system such as powertrain requires Class C communications. Body electronics functions are a Class B network. They are not real time but they still have to have good response time so customers do not perceive the delays. LIN provides the connectivity to sensors and switches at the end of the body electronics network in a Class A communication level.

“There are many ECUs in the vehicle and various types of information being passed between the subsystems,” said Ken Orlando, GM LAN serial data lead engineer. “You’ll find the functions sets that are using the CAN networks are probably in Class B and Class C category,” For GM, the use of LIN is currently being investigated for a number of applications, but it is not in production vehicles.

“At the highest level we see LIN and CAN as compatible and there are synergies between the two buses,” said Kevin Leppek, engineering group manager for serial data, General Motors. CAN being a higher bandwidth bus is good for communicating between modules.

Leppek noted that a variety of CAN products are currently used in body electronics at GM and he sees LIN playing a new role of providing the capability of those modules to communicate with smarter switches and smarter mirrors. For example, a mirror that would have had as many as 15 wires now only requires three. The amount of information that has to be shared with the mirror is significantly lower than with other systems such as an engine controller.

Certain vehicle systems that are modular, such as a door or an HVAC system are prime candidates for LIN. These subsystems do not need high-speed data transfer, and the communications are rather predictable. As a result, they can expect to have significantly reduced wiring and assembly costs by virtue of a simplified wiring harness. “There is a good possibility that it is usable in door switch modules, motor controls in HVAC or mirrors,” said Merv Rose, a GM LIN expert and SAE representative.

“Our end game for LIN is to use an ASIC-based interface solution where the state machine that decodes messages or encodes them is all a piece of silicon­—not microprocessor based,” said Rose. “That’s going to make them very inexpensive and very repeatable.” Rose projects that GM would use as many LIN nodes as possible in this form rather than using a microprocessor-based solution. This will simplify the amount of programming that will have to be performed. GM expects to define the information in the message content up front for a broad variety of applications to ensure this happens. Once this effort is complete, one of the positive benefits they expect is reuse.

“What we are investigating as our mainstream approach is to use the J2602 standard version of LIN components,” said Rose. SAE J2602 was approved and published in August 2004. The standard provides additional requirements that are not present in LIN 2.0 such as fault tolerant operation and network topology that should expand the use of the LIN protocol.


To join the conversation, and become an exclusive member of Electronic Design, create an account today!