A line on a new wiring protocol for vehicles LIN

Dan Butler
Principal Applications Engineer
Microchip Technology Inc.
Chandler, Ariz.

Edited by Miles Budimir

The controller-area network (CAN) has emerged as the standard high-speed bus or network for connecting electronic systems in today's cars, trucks, and other vehicles. It's fast, has plenty of bandwidth, but it's expensive. And it's overkill for some automotive systems, especially human-controlled mechanical systems such as door locks and windows, wipers, sunroof, and climate controls. These human-initiated events are measured in milliseconds, rather than the microseconds and nanoseconds of other automotive electronic devices. Consequently, they can use slower and less-expensive technology.

This is where the new local interconnect network (LIN) Protocol comes in. LIN was designed as a low-cost, short-distance, low-speed network for events in "human" or "mechanical" time. The spec is the work of European automakers that include Audi AG, BMW AG, DaimlerChrysler AG, Volkswagen AG, and VolvoCar Corp., as well as Motorola Inc. and Volcano Communications Technologies AB.

Network basics
In the digitally connected car, commands on a LIN go over a serial bus instead of through dedicated wires. Each node on the bus contains an inexpensive microcontroller, and each LIN has one master node. Master and slave nodes are identical except that master nodes maintain timing and traffic for all nodes on the LIN. This ensures deterministic timing and eliminates bus overhead associated with devices contending for use of the network. LIN works off the vehicle's battery (8 to 18 V), so just three wires — power, ground, and signal — connect each node. A special LIN transceiver chip isolates the controller at each node from the bus. Besides providing electrical isolation, these chips also limit pulse rise time to reduce EMI and RFI.

The bus length is limited to 40 meters to limit propagation delays and total capacitance. The master node connections are pulled up through a 1-k resistor while the slaves have individual 30-k (nominal) pull-ups of their own. A diode prevents the bus from driving back into the power line.

The bus floats high when idle, pulled up through the weak pull-ups at each node. Zeros are signaled by pulling the bus low. A "1" state exists when all nodes let the bus float, a "0" state when any node pulls the bus low.

To keep the bus economical there are no expensive crystal oscillators at each node. Instead, inexpensive RC oscillators generate clock signals. An autobaud preamble included in each message eliminates the need for crystals and their super-accurate timings. Slave microcontrollers recalibrate their bit timing at the beginning of each message and match the master's current rate. Thus each node synchronizes with the master though RC oscillators may drift at different rates.

Typical LIN networks
A typical LIN node might consist of a switch panel built into a door. It would be scanned by the bus master which receives commands initiated by the person activating the switches that control the door locks, windows, and mirrors. This LIN connects to the CAN bus running through the car. A master node scans for commands at a 20-Hz rate and sends them to the appropriate nodes for actions. Each node might be completely contained within a single door. Commands from the node inside the driver's door node might be sent to nodes in other doors for, say, locking and unlocking or to open or close a window. These commands would be routed over the CAN bus. The interface node in the appropriate door would read commands from the CAN bus and activate the requested functions via its LIN bus. All master nodes scan the control panel every 50 msec and transmit commands onto the bus when they see a closed switch. Limiting the scan rate eliminates the need to debounce the switches.

Door locks are simple two state devices, either locked or unlocked. When the lock node receives a command, it checks the current state of the lock, then drives the lock to the desired state.

Other types of nodes have more than just two states. Windows, for example, may be in any position from fully closed to fully open. Similarly, mirrors may be set anywhere from full left to full right and from full up to full down. In these cases, a control panel sends messages as long as the window or mirror adjust switch is pressed. Window and mirror nodes then drive motors in the appropriate direction. They remain energized until either they stop getting commands or they hit an end stop.

A more complex LIN may involve five control panels, one in each door, and another one in the center console. They could control the four windows and door locks, two mirrors, a sunroof, rear hatch, rear wiper, and defroster. As with the simpler system, a master node would scan a control-panel node and place commands on the LIN, then move on to the next control-panel node. Meanwhile, slave nodes listen for commands intended for them and respond appropriately.

LIN and CAN do not compete, but rather complement each other.

But it is necessary to add an interface between LIN and CAN. This bridge might consist of a processor (PIC16C432) combined with a stand-alone CAN transceiver (MCP2510). These two chips watch both buses and interchange data. To see how this exchange might take place, consider temperature information needed at several locations in the car. Indoor and outdoor temperature sensors incorporated into a door LIN would first send data to the door's master node. The master node would, in turn, place it on the CAN bus. From there, the rear-view mirror and heads-up display pick up the data to display, and the environmental control system uses the data to activate climate controls and defroster grids.

LIN message protocol
LIN messages start with a synch break, synch byte, and identifier byte. The synch break is nominally 13 bit-times long and alerts each slave node to an upcoming message. The synch byte, eight bits of alternating 1s and 0s, helps slave nodes determine current bit timing.

The identifier byte serves several purposes. It signals a node to put its message on the bus while telling the remaining nodes what data follows. The identifier byte is divided into three fields. Four bits encode the message identifier which may be 0 to 15. Two bits encode the length field or amount of data being sent. It can be 2, 4, or 8 bytes of data, not including the checksum byte. The last two bits provide parity-checking protection for the identifier byte.

An interframe response space gives a node time to recognize that it should start transmitting data. The time allowed for sending data is encoded in the identifier byte. A node that recognizes the identifier byte takes over the bus to transmit data and a data checksum. In most cases, the interframe response space allows sufficient time to go out and acquire fresh data to report, which simplifies programming.

LIN incorporates three levels of error checking. Each bit is checked as it is transmitted. As a node transmits each bit, it monitors the bus to verify the bit transmitted is actually what goes on the bus. Zeros are dominant, so this really only applies to transmitting ones which require the bus to float. In case of error, the node stops transmitting and records the error.

The identifier byte is parity protected by two parity bits, P0 and P1. And finally, the data phase includes an extra checksum byte. When an error is detected, the transaction is ignored, but the error may be logged for diagnostic purposes.

Communication of command, control, and status data fits well into the low-rate spectrum for which LIN was designed. Appliance manufacturers are becoming interested in LIN for communicating between switch panels, sensors, motors, and displays. Like automakers, they want reduced wire counts, better reliability, and all the features that digital technology makes possible. Looking ahead, the LIN protocol could emerge in some interesting applications that combine LIN bus technology with low-cost radio modems.