LIN Networks in the Automotive Industry
1.
Introduction
Centralized control of all nodes within the automotive environment has long been the
solution of many high volume car manufacturers. These centralized nodes are responsible
for the interfacing and control of several user interactions, such as window lift, door
locking and mirror positioning.
Traditionally these centralized nodes would be based around a high performance
microcontroller (MCU), with this single MCU responsible for the various functions
within a module.
As in most car platforms, these modules would typically be connected via the
Controller Area Network (CAN). While this resolves many networking issues, it results
in complex, high-speed architectures.
The dynamics of the automotive industry continue to place increasing demands on the
manufacturer. Innovations and feature enhancement are constant drivers in a very
aggressive marketplace -- implementing these features on existing platforms is becoming
more and more difficult.
While increasing the power of the MCU at each centralized node is one solution to the
problem, bigger MCUs, increased interconnections, and lack of flexibility all act to
reduce the effectiveness.
An alternative approach is to de-centralize the intelligence and migrate some of the
functionality into smaller, more robust nodes. The Local Interconnect Network (LIN) is
an ideal network for this purpose offering a low-speed, reduced cost implementation
approach. This article will discuss these simplified networks focusing on the Local
Interconnect Network (LIN); several of its implementations; and the advantages and
disadvantages of each solution.
1
2.
LIN Overview
The LIN Bus is an automotive serial protocol that has been developed for very low cost
applications. It is intended to complement existing CAN networks, enabling hierarchical
networks within cars. The protocol is a simple master/slave arrangement, with the main
processing being performed in the master node. The slave nodes are intended to be
‘simple’ in order to reduce costs.
The LIN bus is a master slave protocol where the master node initiates all data transfer.
There are two fundamentally different methods to transfer data to the slave nodes. These
are ‘master-to-slave’ transfer or ‘slave-to-slave’ transfer (master initiates a slave to send
data to another slave). Each method has distinct advantages and disadvantages, which
will be discussed later.
The timing of message transfer using the LIN protocol is predictable. The protocol is
time triggered, there is no bus arbitration and the worst-case timing for each message
frame can easily be calculated. The transmission of each message frame is controlled
through a schedule table that executes on the master node. The table transmits the
message frame headers at known intervals.
For further information on the LIN protocol, please refer to:
Reference LIN Protocol Specification. Version 1.2, 17th November 2000
2
3.
Network Implementation
These areas will be discussed with respect to a single LIN network structure, multiple
LIN networks and finally a mixed CAN / LIN network.
3.1. Single LIN Network (multiple door nodes)
In a single LIN network, the Body Controller Module (BCM) will interconnect via a
single LIN connection to each of the nodes. In the comfort area of the car this would take
the following appearance:
BCM
Passenger door
Driver door
Rear door
Rear door
Keypad
This type of network is a very straightforward architecture, with the LIN connections
effectively replacing a CAN solution. While LIN has been designed to complement CAN
rather than replace it, it is possible to realize a simple solution using this approach.
This is a reduced cost solution, since there is no requirement for any CAN nodes. The
BCM forms the single LIN master, so therefore all nodes on the network will have access
to every single message transmitted on the network.
With this type of solution there would typically be around 5 LIN nodes on the network.
By minimizing the number of nodes in this manner, defining the initial messaging
strategy would be straightforward.
However, scheduling (defining which messages will be on the network and in which
sequence) will be difficult. If slave-to-slave communication is designed into the system,
this would simplify defining the schedule table, since this effectively reduces network
traffic to a minimum. An example of this would be the master determining if there has
been any keypad activity in one of the doors: any one of the nodes on the network could
respond within the same message frame.
This type of network will have the shortest length leading to minimal EMC problems.
Again traffic density will be low which will also help reduce emissions.
3
Since only a single wire is connecting all the nodes together, the number of connectors is
reduced to an absolute minimum. This will lead to an increase in reliability.
Since there are so many apparent advantages in this approach, then why aren’t many
manufactures implementing this solution? First, complexity of each node on the network
will not differ significantly from a CAN solution. Each door node will still have to
maintain control over the mirrors, windows, and locks at a minimum. This necessitates a
high performance MCU solution.
In safety critical applications such as the automotive arena, it must be remembered that
each node is completely dependent on a single master / single wire connection. If a car
using this network were involved in a crash, every node would be extremely vulnerable
and may not respond.
In low power applications the network will frequently be returned to a low power state
with each node placed in sleep mode. Although any LIN node is inherently capable of
restoring power to the system by waking up the network, it may take the master some
time to determine which node was responsible for bringing the network out of sleep
mode.
4
3.2. Dual LIN Network (left and right sides)
To overcome some of the disadvantages of the single LIN Network approach, some
companies have explored the possibility of using a dual LIN network, which would take
the following appearance:
BCM
Passenger door
Driver door
Rear door
Rear door
Keypad
Defining the schedule table now becomes a much simpler task, since the BCM takes
control of two completely independent networks. This will facilitate much more timely
communication on each of the networks. Since there are now two completely
independent networks, resilience has been greatly enhanced. Therefore if a crash is
encountered, there is a much higher probability that much of the network will remain
intact.
However, several disadvantages still persist. First, the intelligence of each node has not
been reduced, hence high performance MCUs are still a requirement. Secondly, although
message definition is simpler, moving information between the two networks will be
troublesome and sometimes slow. In this particular configuration the keypad is shown as
a LIN node on the right hand network, but much of its functionality will be controlling
actions on the left hand network. This will lead to many latency issues.
5
3.3. CAN with LIN hierarchy
Overcoming the above limitations using only a LIN solution is at best problematic and at
worst impossible.
So where is LIN implemented in the automotive arena? In the introduction, it was stated
that LIN is to complement CAN and not replace it. The following simplified diagram
illustrates a CAN / LIN solution:
LIN
Network 2
BCM
LIN
Network 1
Mirror
Keypad
Mirror
Passenger
door
Driver
door
Keypad
Lock
Lock
Window Lift
Window Lift
Rear door
LIN
Network 4
CAN
Network
Rear door
LIN
Network 3
In this example a single CAN network is shown connecting together the BCM and the
four doors. This is typical of a solution employed by many manufacturers today, with the
MCU in each of the doors a high performance device, such as the popular HC908AZ60A.
This MCU then directly controls the mirror, window, etc.
Adopting a LIN structure for the doors functionality allows the selection of a much
smaller MCU (eg HC908GZ16). This maintains the required CAN interfacing module for
communicating with the BCM, but enough provides horsepower to control a single LIN
network. In this example, the Driver Door MCU would act as LIN master for its mirror,
keypad, lock and window lift. Each individual node would have a much smaller MCU or
state machine controlling their behavior.
This has the overall effect of increasing the number of MCUs within the door, but careful
selection of MCUs and state machines results in a much more powerful and flexible
distributed system.
This flexibility is key in today’s rapidly changing industry, where customers demand
much more customization of products for their own needs. The introduction of these
smaller, standalone modules into the car allows the manufacturer to facilitate quick
changes to their standard car platforms.
6
3.4. Door control
The previous example illustrated a typical LIN network within the door and overcomes
many of the earlier disadvantages discussed. However, the door network is still prone to
several issues, particularly malfunctioning and fraud. The mirror -- the single most
vulnerable part in this system -- is frequently removed during inner city driving, which
leads to a network breakdown – an unacceptable risk to some manufacturers. As to fraud,
potential criminals can easily remove the mirror from the car, allowing direct access to
the complete LIN network within the door -- again an unacceptable risk.
There are several permutations to reduce this risk, one of which is:
LIN
Network 1
Driver
door
Mirror
Keypad
Lock
LIN
Network 2
Window Lift
In this example, there are two LIN networks within the door. As can be seen from the
diagram, the mirror is effectively isolated from the rest of the system, reducing network
impact of the mirror being removed. Any attempt at fraud will only allow access to the
Driver Door – Mirror network, rather than the key components such as the door lock.
An alternate approach would be to control the mirror from a LIN sub-node:
LIN
Network 1
Driver
door
Keypad
Mirror
Lock
Window Lift
7
In this example, the fraud and reliability concerns are still addressed, with the mirror
being either controlled directly by the keypad MCU, or again as a further LIN node. Both
would be appropriate system designs.
4. Typical LIN nodes
The above illustrations demonstrated the use of LIN networks within the door.
The following are examples of typical LIN nodes within the car:
4.1 Driver Door Module
In the previous example, the Driver Door Module was shown as the Master for the door
network, providing control and timing for the LIN network within the door. While
controlling all the local items within the door, it also acts as a gateway into the Body
Control Module (BCM), typically via a CAN network.
4.2 Mirror Module
Typically the modern mirror will support X, Y and fold functionality. Such details as
mirror position may also be stored within the mirror module. Either the driver mirror or
the passenger mirror sometimes house temperature sensors for continual monitoring of
external conditions. This information is obviously used for driver information, but is also
employed as part of the more sophisticated Engine management Systems.
The mirror module would normally be a LIN slave node.
4.3 Window Lift Module
Electric windows contain up, down and anti-pinch control.
The window lift nodes would normally be LIN slave nodes, though there are some
instances of the front window module being a LIN slave to the BCM, but also a master to
a rear door.
4.4 Door Lock Module
Door Locking comprises both standard ‘lock’ and ‘deadlock’. Localized control within
the door sometimes interfaces directly into the module, which also necessitates a Child
Lock function, allowing the driver to disable certain doors.
The door lock module would normally be a LIN slave node.
4.5 Front Switch Panel
Many of the control functions for within the car comfort area (door locking, window lift,
mirror control, etc) are sometimes collected into a single module. This module then lends
itself to being a LIN slave node on the network.
8
5. Communication methods
As previously stated, there are primarily two differing methods for data communication
on the LIN network: master-to-slave transfer and slave-to-slave transfer.
Either method is controlled via the master, but each has its own advantages and
disadvantages.
5.1 Master-to-Slave communication
The master initiates the data transfer by transmitting the message ID (see section 2). All
LIN nodes on the network interpret this message and act accordingly.
With this master-to-slave communication style, there is a slave task running within the
master. It responds to the appropriate ID and transfers the necessary bytes onto the LIN
bus. The various LIN nodes see the complete LIN frame on the network, with the
‘master’ data and process as per their individual application.
For example, the master may wish all door locks to open. Each door lock node could be
programmed to react to a single message and unlock. Alternatively the master could
selectively open the door locks in turn by transmitting four messages.
This technique puts most of the overhead on the master while simplifying the nodes.
This allows the LIN node hardware to be greatly reduced, possibly down to a simple state
machine. Another benefit is that since the master can communicate to all nodes
simultaneously, the number of messages transmitted and IDs required is very much
reduced.
Since the master is initiating all data transfer to all nodes (and receiving all data from
nodes before passing onto others), it is in a position to check all data for validity. This
allows the master to police all communications and reduce / eliminate potential errors.
Unfortunately this communication method can be slow. The action of retrieving data
from a LIN node, processing it and then selectively transmitting it to other nodes in a
timely manner is problematic.
5.2 Slave-to-Slave communication
The master initiates the data transfer as before. However, in this scenario the ‘slave task’
responding is in one of the remote nodes, such as the keypad. As the keypad ‘fills in’ the
data bytes of the message frame, all nodes on the network see this complete transmission
and may act accordingly. In this example, a window may operate in response to the
keypad data.
Compared to the Master-to-Slave communication method, this approach is much faster.
Information is being shared between nodes on each message frame, making for very fast
responses. The single message could potentially open two windows, close one, open three
doors, move a mirror, etc. This obviously minimizes the data traffic on the network.
On first inspection this seems to be a much better approach than Master-to-Slave
communication. However, it does have one or two disadvantages. The first is related to
the clock source. Every LIN master must have a highly accurate clock source, since it
provides the master clock for all activity on the LIN bus. This allows the LIN slaves
9
much more flexibility and latitude in their clock selection, since the protocol allows the
node to re-synchronize onto the master clock.
In a ‘slave responding to master’ communication, this works well, as the master has a
high degree of tolerance to data variation. However, another LIN slave receiving this
same data may have a less accurate clock, potentially leading to a misinterpretation of
data.
Another disadvantage is that the master has no indication that this ‘slave-to-slave’
communication has been invalid.
6. Data Transmission rates
Message frame transmission duration
The following table illustrates the maximum transmission duration for 2,4 and 8 Byte
messages when transmitted at 9600bit/sec and 19200bit/sec. These transmission rates are
recommended in the LIN specification, although the protocol is specified to operate
between 1kbps and 20kbps.
Number of
Bytes in
Message (N)
(Bytes)
2
4
8
Standard messages transmission times
TFRAME_MIN
Tx Time @
TFRAME_MAX
9600bit/sec
(TFRAME_MIN+1) x
(10xN) +44
(ms)
(Bits)
1.4
(Bits)
64
91
9.45ms
84
119
12.4ms
124
175
18.23ms
Tx Time @
19200bit/sec
(ms)
4.74ms
6.12ms
9.11ms
While these data rates may seem slow, particularly when compared against CAN
(capable of up to 1Mbit), they have been specified this way for various reasons. Probably
two of the main ones are to minimize EMC emissions and simplify the slave nodes.
7. Conclusions
As functionality and intelligence is moved around the car to the smallest of nodes, there
is an increasing demand for small, robust microprocessors to address this requirement.
The LIN approach is an ideal solution, making the interconnecting of many nodes simple
and cost effective. The vast availability of MCUs, from the HC908QT1 to the HCS12
family, allows the system designer great flexibility in determining the best solution for a
particular car platform.
10