Back to résumé

Using the LIN Bus in an RKE System

Early this year Audi, BMW, Daimler-Chrysler, Volvo and Volkswagen teamed with Motorola's Semiconductor Products Sector to back the Local Interconnnect Network (LIN) Protocol for a low-cost, low-speed network bus in automotive applications.  The bus is a single-wire, multidrop topology with a maximum of 16 nodes on the bus.

This standard will enable automotive manufacturers to eliminate hundreds of feet of wiring from the average car. The LIN Protocol is designed to communicate low-rate data such as switch positions at the lowest possible cost. It will be used for simple on-off devices such as car seats, door locks, sun roofs, rain sensors, HVAC flaps, cruise control, windshield wipers and mirrors, and any other application where high speed is not a requisite.      

This article shows how a remote keyless entry (RKE) application is implemented using a combination of the traditional Controller Area Network (CAN) bus and the newly-defined LIN bus.

Most automotive networks are broken up into several smaller sub-networks located in various parts of the vehicle such as the door, engine, and trunk. Figure 1 (figures were not available at the time I uploaded this file) shows an example network that uses the LIN bus in network locations where high speeds are not required.   

The main network, or body control network, runs on the standard CAN communication protocol. All the sub-nodes are based on the LIN bus protocol. As an example of how the LIN bus is implemented, the following describes what happens in the Microchip KEELOQ RKE system when someone pushes a button on a key fob to unlock a car door. 

An RKE system always has an encoder and a decoder. The encoder is located in the key fob and the decoder is embedded in the body controller. When the appropriate button is pushed on the key fob, it transmits a code to a receiver inside the car that determines if the code is valid. The receiver is usually integrated into a body controller that provides communication between nodes inside the car and the power train.

After validating the received code, the message to unlock the door is passed from the CAN bus via a CAN-LIN gateway to the LIN bus master, which then transmits the data to the appropriate nodes in its network.

There are several criteria that have to be met in order to provide secure communication between the key fob and the body controller unit. The first criterion is that the transmitter code must be secure against code scanning. There are a large number of possible combinations available to prevent code scanning.

The second criterion is that the transmitted code must be secure against code grabbing.  This can be achieved by setting up the system so it never responds twice to the same code.

In this application example the HCS300 encoder from Microchip is used. The body controller, which is usually a 16- or 32-bit microprocessor, runs the decoder software. Figure 2 (figures were not available at the time I uploaded this file) illustrates how the KEELOQ^® decoder algorithm works.

In total, 32 bits of data, consisting of a counter value and a constant, are fed into the encryption algorithm. The encryption algorithm uses this data and a 64-bit encryption key to generate a 66-bit-wide word that is transmitted to the receiver (in our example, the body controller). The 66-bit wide word is broken up into a 32-bit hopping-code section, a 28-bit serial number, four function bits and two status bits.

The receiver first validates the 28-bit serial number against the serial numbers stored in its memory. If the serial number is not identical to one of its stored numbers the receiver will ignore the transmission because this means that the transmitter code was sent from a key that does not belong to the vehicle. If the serial number is identical, the receiver continues with the second stage. Figure 3 (figures were not available at the time I uploaded this file) depicts the decoding process.

During the second stage an encryption key is generated out of the 28-bit transmitted serial number and a 64-bit manufacturer’s key. This key is used to decrypt the 32-bit hopping-code section. The output of the KEELOQ decryption algorithm is a 16-bit counter value, a 10-bit discrimination value, four function bits and two overflow bits. The 16-bit counter value is used to determine if the transmitter and the receiver are synchronized. If the counter value is greater than the stored counter value from the last transmission, the encoder may ignore this transmission and wait for the next one in order to synchronize with the transmitter.

The 10-bit discrimination value can be the same as the low 10 bits of the serial number and can be used as a second pass check for the serial number. The four function bits represent the key that has been pressed on the encoder device. Different keys may have different functions, such as unlocking the door, opening a window or unlocking the trunk.  The two overflow bits indicate if the counter on the transmitter side rolled over from 0xffff to 0x0000.

If all checks are successful the body controller issues a message via the CAN to carry out the command.

In order to unlock the doors, the message has to be sent via the CAN to the door nodes, which are connected via separate LIN buses (see Figure 1 ). To accomplish this a CAN-LIN gateway is employed.

Figure 4 (figures were not available at the time I uploaded this file) shows a CAN-LIN gateway. This gateway uses Microchip’s MPC2510 standalone CAN controller and an 82C251  as a CAN Interface and an  SI9241-EY as a LIN bus interface. In between the MPC2510 and the SI9241 is a  PIC16C873 microcontroller.

In Microchip’s KEELOQ system, the MPC2510 handles the CAN bus transmission and reception of data as well as error detection. The message to be transmitted is passed via an  SPI interface from the microcontroller to the standalone CAN controller, which handles communication via the CAN bus.  In addition to sending and transmitting, the controller takes care of error handling such as sending error frames or incrementing the transmit or receive error counter.

In our example a CAN message of "unlock doors" is transmitted from the body controller. The door node CAN-LIN gateways identify this message by the identifier segment in the CAN data frame. The CAN controller of the CAN-LIN door nodes takes the message and stores it in its receive buffer.

The receive-buffer-full pins (RX0BF and RX1BF) are used to indicate that a valid message has been loaded. The receive-buffer-full signal generates an interrupt on PORT B of the microcontroller, and the microcontroller reads the content of the receive buffers via the SPI interface.

After the message is received by the microcontroller, the CAN-LIN gateway has to determine which node the message is meant for, since there are several other nodes connected to the LIN bus network (see Figure 1 ). It does this by decoding the identifier field.

The decoding from the CAN is done by a look-up table. For a standard identifier of 21 bits, three look-up tables are used. The results determine which node has to be addressed in the LIN bus network. If only the lower eight bits have to be considered, one look-up table is sufficient.

Once the correct identifier for the door node is found, the CAN-LIN gateway transmits the synchronization break. While this signal is transmitted the gateway firmware calculates the parity bits for the LIN bus identifier field. For LIN bus communication the USART of the PIC16C873 is used.

The synchronization signal of the LIN bus is defined as 13 Tbits (where Tbit = 1 bit time). In order to generate a signal of 13 Tbits, the USART is configured to a slower baud rate than the LIN bus baud rate. For example, the LIN bus runs at 19.2 Kbaud, which equals a bit time of  Tbit = 52 us. A synchronization signal of 13 Tbits would take 677 us. Dividing this number by 8 gives the bit time for the synchronization signal. Thus the baud rate for the synchronization signal is 11.8 Kbaud. The transmit register of the USART is loaded with 0x00. Transmitting this value at 11.8 Kbaud gives a synchronization signal of 13 Tbits for a 19.2 Kbaud network.

After the synchronization signal is transmitted, the CAN-LIN gateway sends the synchronization field, which the slave nodes use to adjust their baud rate. After synchronizing the slave nodes, the CAN-LIN gateway sends the identifier field. This field contains the ID for the door node and the parity bits. The identifier bits will tell the door node controller to unlock the door. If the command is to lock the door, the body controller as well as the CAN-LIN gateway would have issued a different identifier.

The complete LIN Protocol Specification will be available via the worldwide web at www.lin-subbus.com. Until then, copies of the LIN Protocol Specification can be obtained from Audi AG, BMW AG, Daimler Chrysler AG, Motorola, Inc., Volcano Communication Technologies AB, Volk­swagen AG, and Volvo Car Corporation.

Back to top           Back to résumé

Back to Word Sculptors main page