LIN – Local Interconnect Network – for use
as sub-bus in Volvo trucks
Anders Rylander & Erik Wallin
Master’s Thesis
Computer Science and Engineering
CHALMERS UNIVERSITY OF TECHNOLOGY
Department of Computer Engineering
Göteborg 2003
Innehållet i detta häfte är skyddat enligt Lagen om upphovsrätt, 1960:729, och
reproduceras eller spridas i någon form utan medgivande av författaren. Förbudet gäller
hela verket såväl som delar av verket och inkluderar lagring i elektroniska och magnetiska
media, visning på bildskärm samt bandupptagning.
© Anders Rylander och Erik Wallin, Göteborg 2003
II
Abstract
This thesis describes and investigates the possibilities and the advantages of using LIN as
a multiplexed electrical system in a modern FH/FM-range Volvo truck. LIN is a
communication protocol designed for controlling simpler electrical components in a
vehicle, like for example switches, sensors and actuators. In a modern truck there can be
up to 20 ECUs controlling various functions such as ABS, gearbox, lighting etc. in the
truck. However, today many of the simpler functions in the truck are connected directly
to the controlling ECUs and the amount of wiring is therefore substantial. The
introduction of a multiplexed network such as LIN would not only cut the wiring cost
and weight considerably but also introduce new and more flexible solutions of
connecting component in the truck.
Investigations have been done concerning the technique behind LIN as well as the
hardware and software recourses needed in order to implement LIN-communication
between components in the truck. A demonstrational implementation of the LIN-protocol
was successfully carried out on the light control panel of a Volvo truck, which enlightens
some of the benefits of using LIN.
Due to the complexity of the electrical systems in a truck today, an incorporation of a
supplementary network such as LIN would not be possible without the support of
development tools. Therefore the thesis work takes a look at various tools on the market
today and their basic properties and functionality is presented
III
Sammanfattning
Denna rapport beskriver och undersöker möjligheterna och fördelarna med att använda
LIN som ett multiplexat elsystem i en modern Volvo- lastbil ur FH/FM-serien. LIN är ett
kommunikationsprotokoll som är designat för att styra enklare elektriska komponenter i
fordon t.ex. switchar, sensorer och aktuatorer. I en modern lastbil kan det finnas upp till
20 ECU:er som kontrollerar olika funktioner i lastbilen såsom ABS, växellåda, belysning
etc. Idag är dock många av de enklare funktionerna direkt kopplade till de kontrollerande
ECU:erna och mängden kablage är därför mycket stor. Införandet av ett multiplexat
nätverk som exempelvis LIN skulle inte bara minska kostnader och vikt för kablage utan
även introducera nya och flexiblare lösningar för att sammankoppla komponenter i en
lastbil.
Undersökningar har gjorts rörande tekniken bakom LIN liksom de nödvändiga resurser
för hårdvara och mjukvara som behövs för att implementera LIN-kommunikation mellan
komponenter i lastbilen. I demonstrationssyfte har en implementation av LIN-protokollet
med framgång genomförts på reglaget för ytterbelysningen på en Volvo lastbil, vilket
belyser några av fördelarna med LIN.
På grund av lastbilens idag så komplexa elektriska system, skulle en införande av
ytterligare ett nätverk som t.ex. LIN vara omöjligt utan tillbörligt stöd från
utvecklingsverktyg. Därför undersöks i denna rapport några av de verktyg som finns på
marknaden och beskriver deras grundläggande egenskaper och funktionalitet.
V
Preface
This report is the outcome of a thesis work conducted at the Computer Engineering
Department at Chalmers University of Technology, Gothenburg, Sweden as a part of the
Master of Science Degree Program in Computer Science.
The thesis work was originally issued by Volvo Truck Corporation and was implemented
by the writers of this document in the facilities of Volvo Truck Corporation at Lundby,
Gothenburg.
During our work we have had plentiful of support and guidance from our supervisors,
Björn Villing and Jan Söderberg for which we are very grateful. Also there are a number
of people in The Volvo Group that has offered us great assistance. We also like to thank
our examiner at the Department of Computer Engineering, Jan Jonsson.
Anders Rylander & Erik Wallin
VII
Table of Contents
1
INTRODUCTION
1.1
1.2
1.3
2
METHOD
2.1
2.2
2.3
3
INITIAL STUDIES OF LIN
ELECTRICAL SYSTEM ANALYSIS
IMPLEMENTATION
THE LIN CONCEPT
3.1
3.2
3.3
3.4
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.6
3.6.1
3.6.2
3.6.3
3.7
3.7.1
3.7.2
3.7.3
3.8
3.8.1
3.8.2
3.8.3
3.9
3.9.1
3.10
4
BACKGROUND
PROBLEM FORMULATION
SCOPE AND OBJECTIVES
M ULTIPLEXED ELECTRICAL SYSTEMS
THE LIN CONSORTIUM
W HY LIN?
PERFORMANCE AND RESOURCE REQUIREMENTS OF LIN VERSUS CAN
TECHNICAL OVERVIEW
LIN message frame
Error Detection, fault confinement and data protection
Scheduling
Sleep command
REAL-TIME PROPERTIES
Signal latencies
Frame delay and time base
Jitter
LIN-COMPONENTS ON THE MARKET
Transceivers
Microcontrollers
LIN software core modules
DEVELOPMENT TOOLS
The LIN Description File
Kvaser Navigator
Volcano Linspector
COMPETING PROTOCOLS
TTP/A
12/24-VOLT SYSTEMS
ELECTRICAL SYSTEM ANALYSIS OF A FH/FM TRUCK
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.5.6
4.6
4.6.1
4.6.2
A RCHITECTURE
THE CASE STUDIES
REAL-TIME CALCULATIONS
LCP
Usage today
LIN solution
Real-time properties
Conclusions
PANEL-SWITCHES
Usage today
LIN solution
Alternative 1: “One slave per switch”
Alternative 2: “Backplane”
Real-time properties
Conclusions
REAR LAMP MODULE
Usage today
LIN solution
15
15
16
16
17
17
17
17
19
19
20
20
22
22
23
26
26
26
27
27
29
30
30
31
32
33
33
34
34
35
36
36
38
39
39
40
40
41
41
42
43
44
44
44
45
46
47
48
50
50
50
51
IX
4.6.3
4.6.4
5
Real-time properties
Conclusions
IMPLEMENTATION
5.1
COMMUNICATION MODEL DEVELOPMENT
5.1.1
Network configuration
5.1.2
Simulation
5.2
A PPLICATION DEVELOPMENT
5.2.1
Slave node
5.2.2
Master node
5.3
HARDWARE DEVELOPMENT
5.3.1
LCP/Microcontroller interface
5.3.2
Hardware components
6
CONCLUSIONS AND DISCUS SION
6.1
6.2
6.3
6.4
6.5
LIN SPECIFICATION
THE USAGE OF LIN IN VOLVO TRUCKS
IMPLEMENTATION OF THE DEMONSTRATOR
DEVELOPMENT TOOLS
FUTURE WORK
REFERENCES
APPENDIX
A PPENDIX A
DEVELOPMENT TOOLS
A.1
Example of a LIN Description File
A.2
Screenshot of the Kvaser Navigator
A.3
Screenshot of the Volcano LINspector
A PPENDIX B
PROTOTYPE
B.1
LCP-microcontroller circuitry
B.2
Files included in slave node software
B.3
Flowchart of the LIN-communication
X
51
52
53
53
53
54
55
55
57
57
57
59
61
61
61
62
62
62
65
1
1
1
3
3
1
1
2
3
Terms and Abbreviations
12
ABS
Antilocking Brake System. Computer controlled brake
system that prevents the wheels of a vehicle from locking.
Anti Spin System
Computer controlled system that prevents the wheels of a
vehicle from spinning and loosing traction with the road
surface.
Bluetooth
Wireless personal area networking technology
CAN
Controller Area Network. High speed network for handling
real-time data.
ECU
Electronic Control Unit. Computational unit in the vehicle
in which certain functions are monitored and controlled.
Composed of a micro-controller with various I/O and
communication interfaces.
EMC
Electromagnetic Compatibility. The degree of
electromagnetic tolerance and emission for a component.
EME
Electromagnetic Emission. A measurement on how much of
electromagnetic emission a component emits.
EMI
Electromagnetic Interference. A measurement on how much
electromagnetic emission a component is exposed to.
FlexRay
Deterministic and fault-tolerant bus system for advanced
automotive control applications.
ISO
International Organization of Standardization
LDF
LIN Description File. A file where configuration information
(signals, frames, speed…) about the LIN-network can be
found.
LIN
Local Interconnect Network. Low speed network for
connecting simple functions in a vehicle
MCU
Microcontroller Unit
MOST
Media Oriented System Transport. Very high speed network
for media traffic in a vehicle
OEM
Original Equipment Manufacturer
Power train
An assembly of gears and associated parts by which power is
transmitted from an engine to a driving axle.
Real-time system
A computer system that executes tasks and communicates
with various nodes and where response times for tasks and
arrival times for messages are important as well as their
correctness.
SAE
Society of Automotive Engineers. A standardization
organization for automotive technologies
Slew-rate
The time it takes for an electric signal to fall from a high
level to a low level and vice versa. The shorter time and
greater difference between high and low, the higher slewrate. High slew-rate generates more EME.
TTP
Time Triggered Protocol. A family of time-triggered
protocols for real-time communication.
TT-CAN
An extension to CAN-networks where messages are sent in a
time triggered manner in contrast to CAN’s event driven,
priority based sending
Twisted pair
Two cables twisted together to minimize EMI.
VTC
Volvo Truck Corporation. The company within the The
Volvo Group manufacturing trucks.
13
Introduction
1 Introduction
In the early 1980s ABS (Antilock Braking System) was introduced in vehicles, which
was the starting point for onboard electronics. In a vehicle with ABS mere mechanics
were not enough to control the wheels from locking with maintained braking power so
computerized control was introduced. Since then the amount of electronics in vehicles
has had an ever- increasing pace. Almost everything in a vehicle today interacts with
some kind of electronic unit, from climate control, anti spin systems and throttle control
to switches, lights and sensors.
To get some structure of all the electronics in a vehicle today a number of ECU’s
(Electronic Control Unit) exists that handles the control of various functions and interact
with each other over some kind of on-board network. Each ECU in the vehicle is
connected to a number of components e.g. valves, sensors, actuators and servomotors
from which it collects information and to which it sends commands. This structure, with
ECU’s directly connected with various functions using lots of wires, has some
weaknesses concerning scalability and flexibility.
Today the number of ECU’s and particularly the wiring in vehicles are at a level where
one has to take the cost and space required into serious consideration when adding new
functionality and designing new models. Not just the cost and space for wiring is
becoming a problem in modern vehicles but also the increasing size of the model
program that the new functionality enables. Different models require different wiring at
production time and difficulties arise when the number of versions to be handled
becomes too large. The cost of flexibility becomes very high.
1.1 Background
Volvo Truck Corporation is a part of The Volvo Group and has its headquarters at
Lundby, Gothenburg, Sweden. Volvo has been developing trucks since 1928 and is, after
the overtaking of Renault Trucks and Mack Trucks, Inc. in 2000, the largest truck
manufacturer in Europe and the second largest in the world. Since 1928 Volvo trucks
have become a lot more advanced. From the very first models with a few meters of wire
to a modern truck where there are more than 20 ECU’s interconnected and the wiring
stretches for several kilometers.
The whole vehicle industry is investigating different ways of attacking the problems
mentioned earlier in the chapter. One possible solution is to add intelligence to the
various components (switches, sensors, servos etc.) in the vehicle and to communicate
with these over a data bus instead of via a number of traditional analog wires. With this
angle of attack new components could simply be hooked on to the data bus wire and after
a reconfiguration of the controlling software the functions would be in operation. The
technique of communicating with several different nodes over a single wire is in the
automotive industry called multiplexed electrical systems. Multiplexed electrical systems
will be discussed in greater detail in chapter 3.1.
15
Introduction
1.2 Problem formulation
In the last few years there has come up protocols designed with focus on cost efficiency
and aimed for use as simple multiplexed electrical systems. One of these protocols is LIN
(Local Interconnect Network) and is likely to become a de-facto standard in the
automotive industry. LIN is considered by VTC (Volvo Truck Corporation) to be the
most prominent contender for simpler multiplexed electrical networks. Therefore VTC
wants to examine this technology closer in the form of this thesis work and find out if it
is suitable to integrate LIN in futures trucks and if so, what possible advantages and
drawbacks the new technique might bring.
1.3 Scope and objectives
In order to give as much guidelines and results to VTC as possible from this thesis work
the project consists of two main parts. The first part is of a more theoretical nature where
the goal is to answer the following questions:
1. How does the LIN-protocol work (logical, communication and electrical aspects)?
2. What development tools are available in the market today?
3. Is LIN the number one protocol on the market for the targeted applications or are
there competing protocols that are better suited?
The second part of the thesis work consists of constructing a demo. The considerations
when choosing an appropriate demo should concern both the properties and limitations of
LIN as well as suitability and constraints of the function in the truck. The goals of the
construction of the demo are the following:
1. Demonstrate different features of the LIN specification
2. Demonstrate the possibilities and benefits of using LIN in the chosen application
3. Calculate response times to check reasonability of the LIN implementation and
verify these
4. Point at potential problems and difficulties when implementing a LIN network
5. Determine whether the LIN concept is suitable for integration in Volvo trucks
16
Method
2 Method
This chapter concerns the way the thesis work was conducted and planned. The work
was divided into three major parts: the initial studies of LIN, the electrical system
analysis and the implementation phase of the project. These parts can be summarized by
the following sub-chapters.
2.1 Initial studies of LIN
To get a feeling of what LIN is and what its capabilities, limitations and general
properties are, an initial study of the protocol was conducted. Suitable and existing
application areas were key concerns when looking at LIN in a more general view.
Existing and emerging LIN-components on the market and how they were used, were
also areas of interest. An effort of scanning the market was therefore made and most of
the information gathered was retrieved from the Internet but also by interviews with
various knowledgeable people with experience with LIN.
2.2 Electrical system analysis
From the work laid out in the initial studies, an evaluation of the capabilities of
incorporating LIN in the electrical architecture of the truck could be started. This
naturally inquired an extensive intake of how the architecture was build up and how
various parts of the system communicated with each other.
From this study three cases were chosen for further analysis. The aspects taken into
consideration when chosen the cases were:
•
Their technical suitability for LIN
•
The possibility for cost reduction by implementing LIN
•
The possibility of more flexible solutions by implementing LIN
2.3 Implementation
The analysis of the three cases included not only estimations and calculations of their
real-time and electrical properties when a hypothetical LIN solution was applied, but also
aspects on how these cases would point out the advantages and disadvantages of LIN
compared to the original solutions.
The analysis also included approximations on how much time and effort an
implementation, i.e. a demo, of one of these cases would take to implement. As a result
of the analysis and in conjunction with concerned people at VTC, the LCP (Light Control
Panel) was chosen as the application to be controlled by a LIN-implementation.
To be able to show the properties of the LCP with LIN in an impartial way, the
implementation was not allowed to put any constraints on the LCP and its original
functionality. Also, in order to make the implemented LCP as similar to a production-line
unit i.e. cost effectiveness; efforts were made to make the hardware components as
simple and cheap as possible. Therefore considerable time and work was made to find
the right components for the implementation.
17
Method
Time was also taken to evaluate different development tools from some of the top
suppliers of LIN networks tools. Analysis of the tools was done hands-on and in parallel
with the implementation of the demo. That way a unique first-time experience of the
tools was given. However, the utilization of the tools was mostly limited to emulation
and simulation of nodes and the messages passed between them.
18
The LIN concept
3 The LIN concept
LIN is a new serial communication protocol designed to operate in distributed electronic
systems. Its primary usage will be as a low-cost network connecting simple components,
such as smart sensors and actuators, in automotive applications. LIN is not intended to
replace existing protocols e.g. MOST (Media Oriented System Transport) and CAN
(Controller Area Network), but to complement them.
3.1 Multiplexed electrical systems
In a multiplexed electrical system, several components share the same circuitry. One can
regard multiplexed electrical systems as ordinary data networks or data buses (e.g.
TCP/IP) where a common infrastructure is used to distribute information. Instead of
using separate control wires for each function in each component, say 4 functions in 4
different components (=16 wires), it is possible to use one “data bus”-wire. This data
wire will then be used to send special commands to the different components. Adding
ground and feed to the data wire, 13 lines are saved in the example above. The meaning
of components is anything in the truck that is electrically connected to another
component (e.g. switches, sensors, and displays) or to an ECU. In this report, a
distinction will be made between ECUs and components, where ECUs should be
considered central parts of the electrical system.
The components in a multiplexed electrical system must contain logic that enables them
to react on certain messages on the bus (e.g. start a stepping motor, light a LED, or give
an answer with a sensor reading). Further it is required that a certain communication
protocol is used on the bus over which the components talk. This makes it necessary for
the components to follow a certain standard or specification.
In today’s modern vehicles (especially cars), there are several different multiplexed
systems covering a number of functions. As the safety-, performance- and legally related
requirements differ, so does the network type. An example of a car making fully use of
multiplexed electrical systems, that might be a reality in the not so far future, can be seen
in Figure 3.1.
Figure 3.1 – Car with several multiplexed electrical systems.
19
The LIN concept
Up to this date the most prominent multiplexed system has been CAN. CAN handles
complex functions with high real-time requirements in a modern vehicle. Examples of
these functions are power train control, anti-spin systems and central vehicle
communication networks. In the recent years MOST has come forward as a high
bandwidth data bus suitable for multimedia applications in vehicles. For simpler
functions such as switches and sensors the multiplexed approach has not yet gained the
same popularity. This is partly due to the fact that no appropriate protocol has been
available and the benefits of using a multiplexed system have been too small.
3.2 The LIN consortium
The idea behind LIN was formed by the co-operation between several leading car
companies, a tool and an electronic manufacturer. This collaboration later led to the
forming of the LIN-Consortium in 1998. Figure 3.2 shows the companies that are part of
the steering committee. Today more than 20 companies have become associated
members and strive for further development of LIN.
The specification written by the consortium covers in addition to the definition of the
protocol and the physical layer also the definition of interfaces for development tools and
application software. The plan is to make LIN a de-facto standard for car manufacturers,
their suppliers and tools and application software developers before an application to ISO
(International Organization of Standardization) or SAE (Society of Automotive
Engineers) is made for standardization of the protocol, see [LINWEB].
Figure 3.2 – The LIN consortium
3.3 Why LIN?
There are four distinct areas of applications using network communication and protocols
for controlling different functions in vehicles today. Each of these areas needs its own
type of protocol and there is no single “universal” protocol that can be used as a solution
for all types. Each type requires specific features:
20
The LIN concept
• Conventional body and powertrain applications, use protocols with known realtime properties, mainly CAN.
• Multimedia applications, calling for protocols that should provide high bandwidth
and speed and even wireless interconnection. Bluetooth, MOST or Firewire are
typical examples.
• Safety critical applications, needing protocols that are fault tolerant and reliable.
X-by-wire is an emerging market that calls for protocols like TTP/C (Time
Triggered Protocol classified as a SAE type C network), FlexRay and TT-CAN
(Time Triggered CAN).
• Mechatronic type applications such as smart sensors and actuators, or even
complex ECUs with simple communication needs. These applications are
addressed by protocols like LIN, TTP/A and other OEM (Original Equipment
Manufacturer) specific protocols.
Figure 3.3 shows how the different protocols are related to each other. CAN protocol is
adopted amongst most of the vehicle manufacturers and in many other areas as well. To
shed light on the differences between CAN and LIN concerning performance and use of
resources, the next sub-chapter will compare the two protocols and present some
properties.
Figure 3.3 – Data rate versus cost for various automotive real-time networks
21
The LIN concept
3.4 Performance and resource requirements of LIN versus CAN
There is no meaning of comparing CAN and LIN in the aspect of competition since they
don not address the same issues. However it will give a general view of LIN in the big
picture. LIN targets low-end applications where the communication cost per node must
be two to three times lower compared to CAN but where the performance, robustness
and versatility of CAN are not required. The main economical factors in favor of LIN are
the single-wire implementation, the low cost of silicon implementation since the
communication is based on UART/SCI-interface (Serial Communication Interface), and
the avoidance of high cost quarts or ceramics resonators in slave nodes. However the
drawbacks are lower bandwidth and less effective bus access scheme with the masterslave configuration. The main features of the LIN and CAN protocol can be viewed in
Table 3.1.
Table 3.1 – Comparison of general features of LIN and CAN derived from [BAD00]
LIN
CAN
single master
multiple masters
2.4, 9.6 and 19.2kbps
62,5…1000kbps
Multicast message routing
6 bit identifier
11/29 bit identifier
Typical size of network
2…16 nodes
4…20 nodes
0… 8
2…8
Transmission time for 4 data bytes
6 ms at 20kbps
0.8 ms at 125kbps
Error detection (data field)
8-bit checksum
15-bit CRC
Physical layer
single-wire, 12 V
twisted-pair, 5 V
master only
Yes
Medium access control
Typical bus speed
Data byte per frame
Quarts/ceramic resonator
Relative cost per network connection
x 0.5
1
x 1.0
3.5 Technical overview
The configuration of a LIN Network consists of a single master and one or several slaves
(up to 16 is recommended by the LIN specification [LIN02]). The master initiates all
data transfers on the bus. Thus no arbitration scheme is necessary and contention for bus
access is not an issue. This leads to deterministic traffic behavior and guarantees the
latency times calculated for the specified frames transmitted on the LIN-network.
The LIN network is implemented using a single wire, which generally means higher
values in EME (Electromagnetic Emission) compared to differential “twisted pair”- wire
implementations such as CAN. To keep the EME values low, the slew-rate of the signals
and also the bandwidth of the data transferred are controlled. See for explanation of slew
rate. The data rate may not exceed the specified value of 20kbit/s and most LIN-devices
will support standard bit rates of 2400, 9600 and 19200bits/sec. Since there is a trade-off
between slew rate/baud rate and EME, it is important to take this into consideration when
designing or evaluating the system in which LIN will operate.
22
1
see [LINWEB]
The LIN concept
The LIN-protocol is built on top of the UART-protocol. This means that all messages
sent on the LIN-bus are byte-encoded according to the UART-protocol. The only
exception is the synchronization (SYNC) break in the LIN message frame, which is
discussed in sub-chapter 3.5.1. The only feature of UART that is necessary to discuss
here for understanding the LIN-protocol, is that for every data byte (except the SYNCbreak) a start and stop bit is put before and after the data byte. The start bit is represented
with a zero (active low) and the stop bit with a one (active high). So when a byte is sent
to the UART-interface, the UART- interface will encode it to 10 bits and send it to the
LIN-transceiver i.e. the bus, in its turn. The format of the UART-byte can be seen in
Figure 3.4.
UART -byte
Data byte
Start 0
bit
1
2
3
4
5
6
7 Stop
bit
Figure 3.4 – The format of a UART-byte
3.5.1 LIN message frame
The LIN message frame consists of a header and a response part. The header has a fixed
length while the response part consists of 0 to 8 bytes of data. The inter-frame-response
time is the time it takes for a slave to respond to a request (i.e. to a ID) from the master
and it may vary among the nodes on the network since it depends on the hardware and
software implementation in each node. At the end of the response part a checksum,
which is calculated for the data part, is attached. The header is broken up into three
fields: the SYNC-break, SYNC-field and the identifier- (ID) field, which are discussed in
the following sub-chapters. The structure of the message frame can be seen in Figure 3.5.
Dominant level
≥ 13 bits
Delimeter
≥ 1 bit
Sync.
8-bits
ID
code
# data ID
Inter-frame- Data
bytes parity respond
0.. 8 byte
Checksum
1 byte
0 1 2 3 4 5 P P
Synchronization break
Synchronization field
Identifier
Frame header
Response
Message frame
Figure 3.5: Message Frame (not according to scale)
23
The LIN concept
Synchronization break
The first part of a LIN-message is the SYNC-break, whic h consists of at least 13 bits of
zeroes. The break is needed in order for the slaves to detect that a message is transmitted
on the bus. According to the specification [LIN02] the slaves are allowed to have a clock
frequency (i.e. baud rate) that differs with 15% to the masters. With this in mind, for a
unsynchronized slave node with a clock frequency that is 15% slower than the master´s
clock to detect a break, it has to sample at least 10 bits as zeroes since 9 zeroes can still
be found in a ordinary UART-byte. For the master this would mean that 10 x 1.15 12
bits would be sufficient to send in order for the slaves to detect the break. However, the
specification states that a minimum of 13 bits should be sent.
For a microcontroller with a UART- interface this means that a framing error is flagged
when a SYNC-break is received since the stop bit in the UART-byte is sampled as a zero
instead of a one. Further, the LIN-software routines in the slave have to check that all the
bits in the data byte received are zeroes in order to be sure that a break has been received.
For the master node, implemented in a microcontroller, the procedure of sending a
SYNC-break also involves some tampering with the UART-protocol (assuming that the
UART-module is used) since it is impossible to send 13 bits of zeroes in a row. One way
is to change the baud rate to a slower rate so that the time taken to send a UART-byte
corresponds to 13 bits with the right baud rate.
Synchronization field
Since the master always initiates a transmission by sending a header, the slaves are able
to synchronize their clocks every time a new message is received. This makes it
unnecessary to implement expensive resonators or oscillators on the slave nodes and only
one, by comparison, accurate resonator is necessary in the master as a time reference.
The slave synchronizes its clock by measuring the time taken from the first falling edge
of the ID-field (i.e. the falling edge of the start bit) to the fifth falling edge i.e. bit 7 of the
SYNC-byte and divides it by 8 in order to get the bit time or baud rate of the master.
Identifier field
In the last part of the message header the ID- field is placed. The ID- field denotes the
content of the data part of the message and is protected with two parity bits. In the LINspecification rev.1.2 (see [LIN00]), two of the bits in the ID-field are used for specifying
the length of the data part of the message and the number of bytes allowed were 2, 4 or 8.
In the current revision this is no longer the case and 0 to 8 bytes of data can be used.
The slave nodes on the network are addressed by the ID- field. The nodes do not have
physical addresses (e.g. MAC-address or any other hardware address) but instead use a
pre-programmed list of valid IDs in memory that they use to filter out which messages to
respond to. This way the ID can have different meaning for different nodes and it enables
3 ways of passing data between the master and its slaves:
24
The LIN concept
Master
LIN-message
header
LIN-message
response
LIN-bus
Slave
Slave
Slave
Figure 3.6 – Data from master to slave(s)
• Master – slave(s) communication, see Figure 3.6. The first alternative of passing
data is when the master sends out a complete message frame i.e. both header and
response for one ore more slaves (multicast if more than one or broadcast if all
slaves listen for it) and is usually referred to as a command frame (CMD frame).
Master
LIN-message
header
LIN-message
response
LIN-bus
Slave
Slave
Slave
Figure 3.7 – Data from slave to master
• Slave – master communication, see Figure 3.7. This alternative is conducted when
the master requests a response from one specific slave (polling) and is usually
referred to as request frames (REQ frame).
Master
LIN-message
header
LIN-message
response
LIN-bus
Slave
Slave
Slave
Figure 3.8 – Data from slave to slave(s)
• Slave – slave(s) communication, see Figure 3.8. The last alternative is when one
slave sends its response to one or more slaves and can be used when there is no
need for data processing by the master e.g. information sent between sensor and
actuator.
25
The LIN concept
3.5.2 Error Detection, fault confinement and data protection
The actions taken by the nodes on the network when a message gets corrupted is not
specified by the LIN-specification and therefore it is up to the application layer to take
care of the fault confinement procedures. The LIN-protocol only specifies basic error
detection schemes for bit-, checksum-, ID-parity-, slave not responding-, inconsistent
synch field- and no bus activity-errors.
The fault confinement is taken care of by the master, since it is the only node that can
issue a re-scheduling of a message. Slave nodes cannot directly signal errors, therefore
the master has to poll the slaves for errors. Bit-errors at the transmitter (at both master
and slaves) are detected by comparing the outgoing message stream with the monitored
message stream. Checksum- and ID-parity-errors are easily detected by locally
calculating and comparing data. The inconsistent-synch- field-error is detected when the
edges of the synch-field are outside the given tolerance. The slave not responding- and
no bus activity are easily detected by use of timers. If a slave node observes an
inconsistency it can save this as diagnostic information, which it can relay to the master
when requested.
3.5.3 Scheduling
The master on a LIN-network handles all transmissions of frames according to schedules.
The schedules are built-up with respect to the real-time requirements of the signals
included in the frames. Each frame takes up a certain amount of time in the schedule and
is called frame-delay. It is the time given for a frame to be transmitted before next frame
in the schedule is transmitted. The actual time taken for a frame to be transmitted is less
than the frame-delay and therefore some slack time is introduced in-between the entries
of the schedule. The concept of frame-delay and slack time is discussed more in detail in
sub-chapter 3.6.2.
The LIN-specification supports the use of multiple schedules, which can be useful in
many cases. One example is the door- module with various functions such as motorized
window-lift, motorized controlled rear- view mirror with heating, lock etc. of a vehicle. In
this example an extra schedule could be useful when the up-button of the window- lift
function is pressed. The master switches to a schedule that prioritizes the messages sent
to and from the window- lift motor in order to cut down the response-time for when the
button is released. This is important since you don not want any delays for this event, e.g.
a finger could be pinched.
3.5.4 Sleep command
The LIN-specification supports a certain mode of operation called sleep. It is favorable to
use when only sporadic events occur (e.g. a button is pressed) and the bus is not used
otherwise. The master is the only valid node that can put the network to sleep, while all
nodes are able to terminate the sleep- mode and activate the bus again. The master puts
the network to sleep by broadcasting a predefined command frame (ID = 0x3C) with
predefined data (first data byte = 0x00) to the slaves on the network. The slaves respond
to this command by putting their transceivers in low-power mode and wait until a wakeup signal is received from the bus or issued by the node itself (e.g. a button connected to
the slave is pressed).
26
The LIN concept
Wake-up signal
by slave
Wake-up
delimiter
SYNC-break
by master
Bus sleep
Start 0
1
2
3
4
5
6
7 Stop
Figure 3.9 – Format of the wake-up signal
The wake-up signal consists of a simple data byte with the character ‘0x80’ as data. After
a wake-up signal has been received from the bus, all nodes run trough their start up
procedures and waits for the master to send a SYNC-break field. The bus must be
recessive for a period of at least 4 bit-times after the dominant period of the wake- up
signal in order for the nodes to be able to run through their start-up procedures.
3.6 Real-time properties
Since the communication between nodes on the network is governed and controlled by
the master, there are relatively little real-time conflicts that can occur on the bus. There is
no bus arbitration and therefore no collisions will ever occur (except when something
goes very wrong), which excludes retransmissions and makes the transmissions very
predictable.
Despite the deterministic behavior there are some factors that are important when
designing and scheduling frames and signals fo r the network. Some of these factors
concern signal latencies, see Figure 3.10, that are inflicted in various points in the
communication and which effects the real-time properties of the system. Sub-chapter
3.4.1 discusses some of the general characteristics of these latencies, of which some are
specific to LIN while others are present in most communication systems. Other factors
that make real-time scheduling more interesting is jitter and this is covered in sub-chapter
3.4.3 and some important other terms are discussed in sub-chapter 3.4.2.
3.6.1 Signal latencies
The time- model in Figure 3.10 shows six time points between generation and
consumption of a signal value. Note that this model describes a single consumer. There
can be several consumers of a single signal on the network and the values of the
described latencies are specific for each node. This is because the system might have
different kinds of software and hardware solutions for the nodes in the system.
27
The LIN concept
Signal value
available to
publishing
application
Notional
generation
Frame enters
transmission
TGL
TSL
Signal value
available to
subscribing
application
Transmission
completed
TT
TNL
Notional
consumption
TCL
Max age
Figure 3.10 – Signal and frame latencies
Generation latency, TGL
Defines the time taken from that an event has occurred (e.g. a button is pressed) to that
the corresponding signal is updated in buffer (by the publishing application) and
available for the LIN-drivers for transmission. This is a latency that depends on the
properties of the publishing application (e.g. what kind of hardware and software that is
used) and hence does not affect the real- time properties of the LIN-protocol.
Schedule latency, TSL
Defines the time taken before the actual transmission is done and depends on when the
frame with the signal is due for transmission and is determined by the master’s schedule.
The latency is the same for all signals in the frame and also common for all subscribers
of the signal. This latency depends on how the scheduling of the frames is done, if it’s a
tight schedule or if it uses a lot of slack time between frames for other task executions on
the microcontroller, see sub-chapter 3.6.2.
Transmission latency, TTL
TTL is the time required for transmitting a frame on the bus and depends on the speed of
the transmissions and the length of the bus.
Notification latency, TNL
Defines the time taken between the reception of the updated signal and the subscribing
application has stored the value in buffer. Is like TGL, dependent of hardware and
software implementations and does not affect the real-time properties of the LINprotocol.
Consumption latency, TCL
Defines the time from that the application is notified by the updated signal, to that the
corresponding action is performed by the application. Like TNL, dependent on the
hardware and software and not specific for the LIN-protocol.
28
The LIN concept
3.6.2 Frame delay and time base
Each frame transmitted on the bus is given a certain amount of time for completing its
transmission before the next frame in the schedule table is started. This is called the
frame delay and is not necessary the same for all frames in the schedule. The delay
depends on the size of the frames and also the time base of the system. In some systems
it’s perhaps mandatory to have great time-gaps between frames so that other tasks on the
nodes (both master and slave) are given more time to execute. On other systems the
schedule needs to be as tight as possible due to tight real-time demands.
Start of
schedule
Frame 1
2
3
Time base
1
Slack
2
Time
Frame delay
Frame period
Figure 3.11 – Time base and frame delay
The time base of the system gives the resolution of the frame delay in milliseconds. With
a smaller time base the frame delay can be more tightly formed to the actual time
constituted by the frame i.e. minimizing the slack between frames. The time base is not a
value specified by the LIN-specification but is something that the system developer
configures. Figure 3.11 shows the concept of frame delay and time base. An example in
complement to the figure can be given:
A frame F consists of 2 bytes of data. The maximum bit length of the frame gives the
maximum time within which the transmission of the frame must be completed. It is
calculated according to the LIN-specification as:
lengthmax ( F ) = lengthmin ( F ) * 1.4 ⇒
lengthmax ( F ) = ((10 * n data + lengthmin ( header ) + checksumbyte) + 1) *1,4 ⇒
lengthmax ( F ) = ((10 × 2 + 34 + 10) + 1) × 1.4 = 91 Bits
As one can see, the minimum length of a frame is extended 40% to give the maximum
allowed length. This is done so that the subscribing frames will have some inter- frame
response time for calculations and other tasks.
If the speed of the transmissions is set to 9.6kbits/s the maximum response time is
calculated to::
max time =
91
≈ 9.5 ms
9600
Now, if the time base of the system is configured to 5 ms one can see that the delay of
the frame F would be a minimum of 2 * 5 ms = 10 ms. The 0.5 ms left before the next
entry in the table, is slack time for the master.
The time base is often implemented as a timer that gives a “tic” (e.g. interrupt) every
time a time base period has elapsed. The use of a time base is a recommendation given
by the LIN specification as a way of implementing the scheduling functionality of the
master.
29
The LIN concept
3.6.3 Jitter
Jitter is a time variance that is usually due to more or less imperfect clocks. With LIN,
the jitter is more likely due to time variances of when frames are transmitted. These
delays are naturally important to look at and to measure so that the design and scheduling
of frames and signals meet their real- time deadlines. When sending frames between
nodes, jitter can occur at both the master and slave.
Table entry 1
Header
L
Table entry 1
Table entry 2
Response
Header
Response
G
Delay frame 1
H
Header
E
Response
time
Delay frame 2
Figure 3.12 – Jitter from inter-frame response and transmit delays
The jitter introduced by the master can be defined as the difference between the
maximum and the minimum delay from the time base start point to the frame header
sending start point (falling edge of SYNC-break field). Figure 3.12 illustrates this. In this
example the jitter introduced by the master would amount to the subtraction of L and E,
where L is the maximum delay and E is the minimum.
In the case with the slave node, the jitter can be defined as the difference between the
maximum and the minimum inter- frame response time introduced when the slave
responds to a request message from the master. This can be expressed as H - G in Figure
3.12.
3.7 LIN-components on the market
In this sub-chapter will discuss some of the compone nts found on the market which in
some form is used when communicating data over the LIN-bus. This can either be
hardware products such as transceivers or microcontrollers from major semiconductor
producers (e.g. Motorola, Microchip, Infineon etc.) or it can be software modules such as
FPGA core packages. The LIN-components are almost exclusively intended for usage in
the automotive industry. The suppliers for the automotive industry are sensitive to the
technical trends and innovations and are developing their own solutions, which
contributes to the continuing growth of the LIN-market. The most prominent of the
various components and their features will be discussed in this chapter.
30
The LIN concept
3.7.1 Transceivers
The LIN-transceivers on the market today are constructed to function as a physical
interface between the master/slave protocol controller (e.g. microcontroller) and the LINbus. As the LIN-bus is primarily found in vehicles, the transceivers have to function in an
environment that can be quite hostile to electronic components. It has to deal with factors
such as dirt, heat and moisture that can affect its functionality. Normally, the transceivers
are shielded together with the rest of the electronic parts incorporated in e.g. an ECU to
protect it from these influences. It also has to withstand EMI, voltage load dumps, shortcircuits and other electrical fluctuations generated by other parts of the electrical system
of the vehicle. Since the LIN-protocol uses a single wire as physical bus, the transceiver
needs to control the amount of EME emitted from the transceiver/bus. This is done by
slope control (or often called slew-rate control) of the signals transmitted on the bus.
In order to minimize the current consumption, which is an important issue in the vehicle
industry, the transceivers supports a standby/sleep mode in which it only consumes up to
a few microamperes of current. From this mode the transceiver can either be woken up to
normal operating mode by the controlling component e.g. microcontroller, by a local
signal (e.g. switch) or by a dedicated message on the LIN-bus.
Figure 3.13 – Block diagram of the Motorola MC33399 transceiver
The features discussed above are all supported by the transceivers on the market today,
with very few exceptions and the schematics of a typical transceiver can be seen in
Figure 3.13. There are however features that some of them support while others don’t.
There are those that have the ability to recognize, when in sleep, if the wake-up source is
local or external and to notify the controller of the wake- up event (e.g. Philips TJA1020).
Others have a built- in voltage regulator to supply a connected microcontroller with
power (e.g. Microchip MCP201), while others only have the ability to control an external
regulator (e.g. Motorola MC3339).
31
The LIN concept
The transceivers are built in accordance to the LIN-specification and are as such
primarily suited for the automotive industry. This is noticeable when looking at the
voltage levels that are specified for the LIN-bus. Most of the transceivers can handle
operating voltages of up to 18V, which is the specified maximum level of the LIN-bus.
Still, there are transceivers that can operate with supply voltages of up to 40V (e.g.
Infineon TLE6259-2). These transceivers would in theory be more suitable to use in a
24V-truck environment. However, if supplied with 24V, the transceivers would not
operate within the specified levels required by the specification and as a result it would
be hard to tell how the properties such as baud-rate and EMI- values would affect the
system in general.
3.7.2 Microcontrollers
When looking at a master or a slave node implementation with LIN, it is not exclusively
the LIN-implementation that sets the requirements for the kind of microcontroller to use.
It is the application that runs on the node in conjunction with the LIN-implementation
that determines this. In fact, the LIN- interface requires very little of the microcontroller
as we will see. There are many different ways of implementing the LIN-interface in a
microcontroller and they relate to what kind of hardware- and software- support the
microcontrollers can give. Some microcontrollers with different kinds of LIN-solutions
will be discussed here.
With or without UART
As mentioned in sub-chapter 3.5, the LIN-protocol uses the UART-protocol as a means
for transmitting and receiving data on the bus. The functionality of the UART can be
implemented in software but many of the microcontrollers on the market today have a
UART implemented in hardware. The software solution does however put extra load on
the processor since it has to execute extra instructions generated by the software
implementation of the UART. So the procedures executed for every transmission on the
bus will have to be compensated for by extra processing power (i.e. higher clock
frequency). This is naturally not the case with the hardware solution.
Time requirements
A hardware module that is necessary for a LIN-implementation in a microcontroller is
the timer. It is used to keep track of the different time properties of the protocol e.g.
maximum frame-time and the idle-time between transmissions on the bus. Like UART,
many of the microcontrollers on the market are equipped with at least one timer (8-bits or
more).
The synchronization procedure conducted by the slave nodes when a message header is
received is done in order to calibrate the slave’s sampling rate (i.e. baud-rate) to the
master’s. This is done in order to be able to sample the bit stream at the right moment
and to receive a message correctly. The specification states that the difference between
the master’s and the slave’s baud-rate can at most be 2% after a successful
synchronization, otherwise it’s not guaranteed that a message can be received correctly.
The synchronization procedure is enabled with the use of a hardware- timer. This is
discussed in more detail in chapter 3.5.
32
The LIN concept
Special features
In complement to ordinary microcontrollers, with the basic LIN-features discussed
above, several other specially designed microcontrollers are emerging with the focus on
the LIN-node market. Examples of new LIN- features in microcontrollers are enhanced
UART-interface (e.g. Motorola 68H908EY16, see [MHC908]) where the notification of
a synchronization break of the message header is done automatically in hardware and is
flagged upon reception. Therefore there is no need, as in ordinary UART, to have
software routines for checking if a SYNC-break was received, see sub-chapter 3.5.1.
Another interesting hardware-feature can be found on the new microcontrollers from
Microchip (PIC16C432 and PIC16C433, see [MIC432] and [MIC433]), which have the
LIN-transceiver incorporated in the microcontrollers. This makes the controller very
compact, small and easy to use.
3.7.3 LIN software core modules
The market of LIN-products does not only consist of microcontrollers and transceivers.
Many companies are focusing on making solutions that are more cost effective for big
production volumes. The LIN-solutions for targeting big production volumes available
on the market today are LIN-reference core modules designed in ASIC or FPGA. The
core module from for example Intelliga is designed as a LIN-controller that handles
single slave messages response filtration and a software interface that allows the
connected microcontroller to perform address filtration, see [INTLIN]. The reference
module is specifically designed to be integrated with application specific ASIC or FPGA
solutions but can also be used with ordinary microcontrollers. AMIS has designed
another example of a LIN-core solution. It is a mixed signal ASIC that supports the
physical layer and the state machine based protocol for LIN, see [AMILIN]. Mixed
signal means that it consists of both digital and analog circuits and in contrast to the
Intelliga solution it has an integrated LIN-transceiver.
Another way of creating a more tailor- made LIN-solution is to use PSoC (Programmable
System on Chip) from for example Cypress. The PSoC enables a user to choose the
appropriate system components to integrate on a chip. The chip is not programmed at the
gate-level as in FPGAs but on function level. A PSoC consists of configurable analog or
digital blocks analogous to hardware peripherals e.g. timers, A/D-converters, UART etc
for a microcontroller that are integrated with a microprocessor on the same chip. This
enables a user to customize the chip to the requirements of the application at hand. The
benefit is that this leads to less hardware redundancy (also the case with ASICs and
FPGAs), which may not be the case with microcontroller-solutions i.e. you pay for more
functions than you need, see [CYPLIN].
3.8 Development tools
A very important issue when designing new communication protocols such as LIN, is the
existence of tools for designing, managing, analyzing and verifying systems using the
protocol. For the LIN-protocol, there are a number of tools on the market, many from
companies with extensive former experience in automotive communication technologies
such as CAN. The advantage of this experience is that the companies already have tools
developed for other protocols e.g. CAN, MOST, which can be adapted to incorporate
LIN. This is the case with one of the tool discussed in greater detail later in the chapter.
33
The LIN concept
There is also a span among the tools concerning scope and objective. Some existing tools
are aimed for mere analysis and simulation, e.g. Volcano Linspector and Kvaser
Navigator, which will be discussed in greater detail later in the chapter. These are made
to tap onto a real LIN-network and interact with or analyze them. To do this, some kind
of hardware interface is required. These interfaces are available from the providers of the
analyzing software. A typical setup can be seen in Figure 3.14.
LIN bus
Slave node
Slave node
Slave node
Linspector
/
Navigator
Figure 3.14 – Typical setup for measurement and simulation with LINspector and Navigator
Other tools incorporate functionality for managing LIN-signal databases, generating
network communication properties (discussed in sub-chapter 3.8.1) and setting up
complete networks. Among these, Volcano LNA can be found. Volcano Automotive
Group and Vector Informatik GmbH also provide complete suits for handling the entire
workflow (from designing communication models and managing network entities for
entire vehicle programs to testing and verification). These tools can be very useful when
developing vehicles where there is extensive use of LIN.
3.8.1 The LIN Description File
A LIN network can consist of up to 17 nodes (one master and 16 slaves) which
communicates with each other by a number of frames, each containing several signals.
To handle all these entities, the LIN-specification states that all included nodes,
schedules, frames and signals (plus other network dependant data) should be specified in
a LDF, LIN Description File. This file, which is common for the complete network is the
central part for the tools for LIN-networks. The analysis and simulation tools use it as a
reference platform, setting the rules by which the traffic should flow. The LDF is
normally generated by the tools used in the earlier parts of the development process e.g.
Volcano LNA. It is a text-based file generated with a strict syntax, specified in [LIN02]
and an example can be seen in appendix A.1.
3.8.2 Kvaser Navigator
The Kvaser Navigator, from the Gothenburg-based company Kvaser AB, is a tool for
analyzing the traffic on CAN and LIN networks as well as testing the correctness of
nodes. For the analysis, the tool provides a number of windows, displaying various data
from and enabling interaction with the network. A screenshot of Navigator’s graphical
user interface can be seen in appendix A.2. When using Navigator, a setup is required
before measurements/simulation is started. This consists of providing a LDF with the
network configuration as described in chapter 3.8.1, setting up the windows to display
data in desired form and possibly writing necessary scripts to emulate nodes internally.
The simulation is then started and information about specific frames and network
statistics appears in the windows. Both numerical and graphic data can be presented.
34
The LIN concept
The scripting language Navigator is using is called USR (Universal Scripting Real-time
Language) and is used to simulate the behavior of emulated nodes in the tool. The syntax
of USR is C- like and an editor is included in the tool. Although LIN is time triggered, the
arrival of messages triggers actions in the nodes, which is why USR is using an event
driven model to execute. The script is configured so that the arrival of certain messages
trigger actions e.g. setting status bits used by the simulated node or setting up data for the
next outgoing message. The language also enables the user to setup timers in the code,
which could be used to simulate latencies in the node or other periodic events.
One feature in Navigator when simulating a master node, which is not found in
LINspector, is the possibility to alter what messages that are sent in the schedule at run
time. This feature is useful when one does not desire to alter a very large LDF but still
needs to test specific functions in a slave node.
3.8.3 Volcano Linspector
LINspector is developed by Volcano Communications Technologies AB and is, like
Kvaser Navigator, a tool designed for analysis of LIN-networks. The similarities between
the two programs are numerous and so is the functionality. A difference between the two
programs is that LINspector is exclusively targeted for LIN. In appendix A.3 a
screenshot of LINspectors graphical user interface can be seen.
In order to emulate nodes in LINspector LEC (LIN Emulation Control) scripts are used.
The function of the script is the same as for the USR-script for Kvaser’s Navigator and
also the syntax is similar. However LEC-scripts, do not use event driven execution but an
infinite loop that runs during the whole simulation. This is not as intuitive as the event
driven approach used in USR-scripts but the functionality is the same.
In LINspector there is a possibility to use an add-on program for giving a graphical
display of the events in a simulation, called LINgo. This program lets the user design
graphical displays to show the events of a simulation. The display can be connected to
the simulation and react to messages and data. An example can be seen in Figure 3.15.
When, for example simulating an ECU that handles light functionality, the user can make
the direction indicators blink upon reception of a certain signal. The reverse relationship
between the LINgo display and the simulator is also possible, changing signal values by
user interaction with the display e.g. pushing a button.
Figure 3.15 – A LINgo graphical display of LIN message activity in a simulation in LINspector.
35
The LIN concept
3.9 Competing protocols
The LIN-protocol is becoming the de-facto standard in the vehicle industry today but
there are many old and reliable as well as new protocols out in the market, which has
both advantages and disadvantages to LIN. Most of the protocols are custom or
proprietary to the car manufacturers and many of these are gradually being phased out
[CAL03]. Examples of proprietary protocols are CCD from Chrysler, BEAN from
Toyota, UBP from Ford and UART (ALDL) from GM.
Since these protocols are proprietary they will not have the same widespread usage as
LIN. There are however protocols that are contenders to LIN if we look at the issue of
involvement of multiple companies of creating and handling the development of a
protocol. One of these is TTP/A, which will be discussed in more detail in this chapter
since it is the primary competitor to LIN.
3.9.1 TTP/A
TTP/A started as an academic development project at the University of Vienna and has
broadened to include various Universities in Europe. The standardization process and
license fees is now handled by the TTA Group [TTAWEB], which is a consortium with
companies such as Audi, Renault, Peugeot, Citroen and Airbus as founding members.
The TTP architecture family, of which TTP/A is a child, has its special focus on faulttolerant high-speed system and the TTP/A is their field-bus variant for non-safety critical
applications in vehicles. TTP/A is developed with the intention to be a well- integrated
sub-bus to the TTP/C, which is the protocol for high-speed safety critical
communication.
General properties
The TTP/A protocol focuses on the smart transducer market. A smart transducer is a
sensor or actuator (or both) with processing capabilities (e.g. micro-controller) and
communicating capabilities (e.g. a transceiver).
The TTP/A specification [TTA02] does not address the same communication layers as
LIN does. This is clear when looking on how the physical layer should be implemented.
Unlike the LIN-specification, the TTP/A-protocol does not clearly state which physical
bus to use or what type of voltage levels to use etc. but leaves these issues for the system
developer to decide. The TTP/A also uses a more complex or structured way of
addressing data in the node. It uses a file system called IFS (Interface File System) that
every node has to conform to when implementing the protocol. The IFS is a system used
to standardize the interface to the functions supported by a smart transducer. The IFS
enables on- line configuration, diagnostics and maintenance of smart sensor nodes. The
data structure of the IFS is not discussed further in this chapter but it suffices to say that
it interfaces the application running on the node with the communication drivers for the
protocol.
Communication
The communication is like LIN, based on the UART-protocol and the TTP/A-protocol
was designed with the intention of using single-wire cables as the physical medium.
However the protocol does not specifically specify which physical bus to use, but it do
states that it works well on standards like ISO-9141 and RS485. The baud rates allowed
are therefore variable.
36
The LIN concept
Both protocols require the usage of a central master that initiates the communication for
the slave nodes. The structure of the master slave dialogue is build in the same manner as
with LIN; a frame header is transmitted by the master and a response is sent by either the
master or a slave. Similarly to LIN, the slave nodes on the network are able to
synchronize their clocks to the master’s clock by a synchronization procedure and thus
the need for expensive oscillators on the slaves are unnecessary.
The format of the data transmitted in a message is however structured in a different way
than LIN since TTP/A uses a higher layer- interface (i.e. IFS) in order to deliver data
received from the bus to the application running on the node. A schematic overview of
the types of message that can be transmitted can be seen in Figure 3.16. Two different
types of messages are specified:
• The multipartner round, used for passing real-time data (e.g. sensor readings) to
the slaves. Consists of a configurable amount of data of up to 64 bytes.
• The master-slave round, used for detection of new nodes, configuration of nodes,
diagnostics etc.
Figure 3.16 – Different types of TTP/A-messages (rounds)
Comparison
Although there are a number of similarities about LIN and TTP/A there are just as many
differences. It’s hard to compare the protocols since they address different software
layers used for passing data between nodes. However some interesting aspects can still
be presented about the differences of the protocols.
Timeliness – The difference of temporal behavior is that the LIN protocol allows for a
variable length of inter- frame gap that can be up to 40% of the frame length. The TTP/A
protocol only allows for a constant fame length in order to minimize the jitter. Therefore
the inter- frame variance is less than 1%. These differences are due to different
perspectives regarding the importance of how the temporal behavior of the protocol
design affects the nodes. With LIN, the tasks executing in the node are prioritized
relatively to the communication task. With TTP/A it is the other way around, the
communication protocol has priority over the local timing properties within the node.
Dependability – Both protocols have ways of dealing with errors presented during
transmission. LIN protects its data with a checksum of one byte in every frame while
with TTP/A one can protect one byte, a nibble or no bits or bytes at all. The command
header is with LIN protected by a 2-bit parity field where as TTP/A uses a 5-bit check
field. From this one can see that there is more protection given by the TTP/A- protocol
The fact that the TTP/A-protocol does not specify which physical bus to use is, makes
the necessity of higher data protection more or less a requirement since the environment
in which it is deployed is unknown beforehand.
37
The LIN concept
Complexity – The complexity of implementing the LIN protocol in slave nodes is
simplified by the allowance of variable inter-frame gap. There is a more restrained
attitude introduced by TTP/A to this matter and this would practically result in more
easily implemented LIN- slaves compared to TTP/A slaves. Also, the TTP/A protocol
addresses higher layer issues as it applies a generic solution on how the application and
its data should be interfaced with the communication part of a node. So, although a node
is very simple and the functionality is limited, it has to conform to the standard given by
TTP/A, which in many cases will add to the complexity of the system. This is not the
case with LIN as the system developer decides how the application and the data is
structured in a node.
Conclusion
It is hard to make a just comparison between the LIN and TTP/A and this is because the
TTP/A protocol is almost exclusively focused on the smart transducers market, which
LIN is not. It also has a standardized interface (IFS) for the usage of the functionality and
addressing the data of a node, which is in the LIN-case more flexible and less complex.
Every node on the market has to comply with this standard no matter how simple its
functionality is.
There is no real difference in the hardware recourses required in order to implement LIN
and TTP/A. Both can be implemented on a microcontroller and uses the UART-protocol
for encoding data. The software constituted by the TTP/A might consume more memory
but the differences are small. Both protocols need a transceiver for sending messages on
the bus. In the LIN-case the physical layer is specified and the costs of transceivers well
known, while in the TTP/A-case the transceiver might be of a more expensive type
depending on what type of physical bus used. On the basis of this the implementational
costs for a node would practically the same. The license fees for implementing the
protocols are stated by the consortiums to be free for e.g. car manufactures, tier 1
suppliers, tool manufacturers or any other company using chips from licensed semiconductor companies.
3.10 12/24-Volt systems
The LIN-protocol is designed to be used in the automotive industry. As such it is
specified to work in the electrical system of cars, which is not the same as in trucks. The
big difference is that trucks use the 24 volt-system (i.e. 24 volts is supplied from the
batteries) while the cars use the 12- volt system. As a result from this, the LINcomponents and the physical bus is specified to be run at and supplied with voltage
levels that can be found in cars (8-18 volts). So if used in a 24-volt environment, the
components have to be supplied with a voltage that is regulated and transformed from 24
volt to 12 volts. This can be done either locally in the nodes or by a central unit which
distributes the power to the LIN-components.
38
Electrical system analysis of a FH/FM truck
4 Electrical system analysis of a FH/FM truck
This chapter will cover the underlying studies of the electrical system in a new FH/FMrange Volvo truck. This incorporates three case studies that will be presented and for
which investigations were made to determine the suitability for implementing a LIN
solution for. This led to the choice of function for which a prototype was constructed
with LIN communication. The new FH/FM truck range consists of the FH12, FM12 and
FM9 and they are the newest models in VTC’s program. The range was released in early
2001 and has been developed with a common architecture. Therefore no distinction will
be made between the different models when discussing the electrical system. Figure 4.1
shows two trucks from the new FH/FM range, a FH12 on the left and a FM12 on the
right.
Figure 4.1 – FH12 tractor with Globetrotter XL cab and FM12 tractor with sleeper cab
4.1 Architecture
The backbone of the electrical system in the FH/FM truck consists of a number of ECUs
connected with two different network types. In the most fully specified trucks there are
close to 20 ECUs. The reasons to have two networks are, on one hand to be able to
separate different categories of traffic and on the other to ha ve a backup if the most
safety critical network fails.
One of the networks is based on CAN and uses SAE J1939 as higher level protocol. On
this network, control signals are transmitted and only part of all ECUs are connected to it
(e.g. engine control unit, transmission control unit, and vehicle control unit). The other
network uses the older SAE J1708/J1587 protocol, which has lower data rate and is used
for information- and diagnostic signals. All units are connected to this network and in
case the CAN network stops functioning the J1708/1587 can take over, although with
limited capacity.
39
Electrical system analysis of a FH/FM truck
Besides the networks, ECUs are also connected to a number of sensors, actuators and
displays. The communication with these components are to the major part not
multiplexed but utilizes simple electrical wires which are dedicated to one function or
signal each. This gives rise to, not just a huge amount of cables but also a number of
different ways of communicating with the components. The non-standardized
communication means that the ECUs may have to handle several different ways of
reading information and controlling components. These include PWM (Pulse Width
Modulated) signals, analog values and digital information.
4.2 The case studies
A FH/FM truck contains a vast number of electrically connected components that either
work solitary or together as a part in a subsystem. They include everything from human
controlled switches and continuously measuring level sensors to valves in automatic
controlled systems. When studying the functions of these components and subsystems
one realizes that they span a wide field of operation. The following list shows some
interesting aspects when determining whether LIN could be useful when communicating
with the components:
• Amount of information delivered/received
• Real-time demands on the data
• Necessity to be able to distribute information to other parts of the truck
• The nature of its surroundings
• Legislated constraints
• Cost effectiveness
Based on the criteria above, three functions in the truck were selected and for each of
these a case study was performed. The case studies are meant to shine light on the
question of how the communication with the functions could benefit from a LIN solution.
4.3 Real-time calculations
The calculations of real-time properties performed for each case study is limited to the
specific transfer of LIN messages on the bus. This is due to the time variance different
implementations of nodes will have. Various types of internal architecture of
microprocessors and FPGAs etc will affect the delay between when an event occurs or a
timer times out and the time an updated message leaves the slave. The real-time
properties of LIN are discussed in greater detail in chapter 3.6.
When looking at response times, it is the worst case that is of interest. When looking at a
schedule for a LIN-network, the frame-delay (time slot) for each message gives a bit of
slack before the next message is sent as seen in Figure 3.11. This implies that, for
example a slave node receives a complete CMD- message before the end of the time slot.
Table 4.1 shows the differences in message transfer times and frame delays for different
sized messages
40
Electrical system analysis of a FH/FM truck
Table 4.1 – Calculatins of frame delays and transfer times
Time base = 5ms
Frame
size
1
2
3
4
5
6
7
8
sleep
wake-up
9.6 kbps
Frame delay Message transfer
[ms]
time [ms]
10 = t1
8,0
10 = t2
9,5
15 = t3
10,9
15 = t4
12,4
15 = t5
13,9
20 = t6
15,3
20 = t7
16,8
20 = t8
18,2
20 = tsleep
twake-up
18,2
1,25
Max difference:
Slack
[ms]
2,0
0,5
4,1
2,6
1,1
4,7
3,2
1,8
Frame delay
[ms]
5 = t1
5 = t2
10 = t3
10 = t4
10 = t5
10 = t6
10 = t7
10 = t8
19.2 kbps
Message transfer
time [ms]
4,0
4,7
5,5
6,2
6,9
7,7
8,4
9,1
Slack
[ms]
1,0
0,3
4,5
3,8
3,1
2,3
1,6
0,9
1,8
-
10 = tsleep
twake-up
9,1
0,6
0,9
-
Max difference:
4,5
4,7
To be noted is that the slack for a three-byte message when running a network at 19.2
kbps is quite substantial. In this case a time base of 6 ms would be better. The difference
between frame delays and transfer times for the three case studies in this chapter will
however be of maximum 6% and is therefore negligible.
4.4 LCP
LCP stands for Light Control Panel and is a panel in the cab just to the left of the steering
wheel in current FH/FM trucks. It is used by the driver to control various functions
concerning exterior and interior lighting and is normally very rarely used. The LCP, seen
in Figure 4.2 consists of a turn-knob for controlling the head light mode and front/rear
fog light, a thumb-wheel for controlling the background light intensity in the dashboard
instruments and a push button for turning on and off the hazard warning light.
Figure 4.2 – The Light Control Panel
4.4.1 Usage today
In FH/FM trucks the LCP is connected with single-signal-dedicated wires to the LCM
(Light Control Module), an ECU that handles various lights around the truck. Totally 12
wires are used for the communication:
• Six wires for the five functions operated by the switches in the LCP
• Four wires for lighting the LEDs in the LCP
41
Electrical system analysis of a FH/FM truck
• Two wires for ground and voltage feed
Over these 12 wires, signals are sent both in the form of PWM signals (the dimmable
background light), on/off digital signals (the rest of the LEDs and the switches) and
analog signals (the thumb-wheel controlling background light intensity). With a LIN
based control of the LCP, all signals have to be quantified to comply with the protocol. A
total of ten signals are transmitted and eight of these are digital. These eight signals will
easily be adapted to the new way of communicating but the analog signal of the thumbwheel has to be transformed into a discrete value before sent over the bus. This is also the
case with the PWM signal.
4.4.2 LIN solution
In the proposed implementation of LCM-LCP communication with LIN, only two nodes
are present in the network. The LCM acts as a master and the LCP acts as a slave. This
network configuration is rather trivial and does not show the potential in building large
LIN-networks. However, the interest from Volvo was significant and they wanted this
case investigated. Not only the network layout is simple, but the communication as well.
Only two different frames are used, one where the master sends updated status
information of the LEDs in the LCP (CMD message) and one where the slave responds
with status about its switches to the LCM (REQ message). The easiest way to insert these
in a schedule is to send each frame every other turn as shown in Figure 4.3. The amount
of information needed to be transferred between the LCM and LCP is so small that it fits
in a frame with two bytes of data.
REQ-message
Data: LCP → LCM
CMD-message
Data: LCM → LCP
Figure 4.3 – The schedule used with two frames
One property to take under consideration when implementing LIN communication
between the LCP and LCM is the frequency with which the LCP is used. Setting the head
lights to half- light or parking light or activating the hazard warning light are things one
do very seldom. Long haul trucks for example, are on the road for several hours in a
stretch and the driver only turns on the half- light when taking off and maybe turns on full
light after a few hours. Here the sleep feature of LIN comes in handy. Instead of sending
status between the LCP and LCM continuously, the master in the LCM can put the LIN
network to sleep and only “wake up” the network if the driver does activate a function on
the LCP. The schedule is then run for a short period of time and if nothing is changed on
the LCP, the network is again put to sleep. The benefit of this is that the LIN slave node
in the LCP can go to low-power mode and hence decrease the current drained from the
truck’s batteries.
The benefit of a LIN solution partly consists of the decrease in wires necessary for the
communication. From today’s 12 wires down to only three for a LIN solution is a
reduction of 75%. Not only the cost of the wires but also space is saved. On the LCMside a number of I/O-pins can be removed and thus simplifying the I/O control in the
LCM internally.
42
Electrical system analysis of a FH/FM truck
4.4.3 Real-time properties
Since a human controls the LCP and its functions, the real-time demands on the LCP can
not be considered hard, they are indeed quite soft. The only demand one can have on the
system concerning response time is that it has to respond in such short time that the
driver does not notice any delay when for example turning the turn-knob on the LCP. If
the headlight does not change from Off to Drive within about hundred milliseconds the
latency gets annoying and the driver might think that something went wrong and tries to
turn the turn-knob again. The same reasoning applies to the situation when turning on the
front and rear fog lights with the difference that the result is only shown on the LCP in
terms of a lit LED. For all functions but the head light mode the result of a pushed button
is showed on the LCP in terms of lit or dimmed LEDs. This means that there has to be
communication both ways between the LCP and LCM before feedback is given. The
calculations for response times will cover this case.
The WCRT (Worst Case Response Time) occurs when a switch on the LCP is activated
just too late for it to be registered by the logic and sent with the next scheduled response
to a REQ message. This REQ-message is also the last message that the master sends
before turning the network to sleep with a sleep command. Then the LCM will not be
notified of the event until the following has occurred:
• The sleep message from the master has been sent
• A wake- up request has been sent from the slave
• One REQ-message in the schedule has once again been sent
The WCRT for the LCP-case will occur as shown in Figure 4.4. The reasoning above is
valid under one assumption. That is that there is enough slack after each frame in the
schedule for the master to update the frame to be sent next based on the information in
the most recent incoming message.
New event
New status
REQ-message
Old switch status
SLEEP-command
WAKE-UP
REQ-message
New switch status
CMD-message
New LED status
Figure 4.4 – WCRT for the schedule
The WCRT, concerning the transmission, for activating the switch and seeing the LED
light up on the LCP will for schedule one be:
t WCRT = t 2 + t sleep + t wake −up + 2 * t 2 = 51.25ms (9,6 kbps) *
t WCRT = t 2 + t sleep + t wake −up + 2 * t 2 = 25,63ms (19,2 kbps)
In the case with the LCP, the schedule described in Figure 4.3 will be convenient for the
application as the response times for transportation of data are quite low. If they are low
enough cannot be determined straight away since the implementation of the hardware
and software will introduce latencies and affect the overall response time. It is however
unlikely that a microcontroller running at a few MHz will contribute with more than a
fraction of the times above.
*
t x is referred to Table 4.1
43
Electrical system analysis of a FH/FM truck
4.4.4 Conclusions
Implementing LIN communication between the LCP and LCM with the LCP as a slave
does not demonstrate the features of the LIN protocol to its full extent, especially
concerning network complexity, bus load and slave node configuration. The sleep feature
is however useful due to the low frequency with which the LCP is used. This enables the
slave node in the LCP to save power.
4.5 Panel-switches
All switches placed in, and around the dashboard in the cab of the truck is referred to as
panel-switches. They include switches for differential gear locking, cab heating, interior
light, rear view camera and many other functions. In total there are about 100 functions
controlled by the panel-switches. Most of these functions are however very seldom
present in the trucks. Some are used as rarely as in less than 100 trucks and will not be
considered in this chapter. The majority of the switches each have two LEDs that
indicate the switch’s position and that the function the switch is representing is activated.
The panel switches are mainly placed in the dashboard around the steering wheel but also
above the windshield in front of the driver. There are a great number of functions
handled by the panel-switches in a FH/FM truck but not room for more than 36 of them
at once. Many of these functions are however used in very few trucks, some in as few as
10 trucks. Obviously, all functions will not fit in one single truck. This is no problem
since a number of them are mutually exclusive and a truck normally has less than 15
switches and extremely rarely more than 30.
Besides the panel-switches there are other instruments and components in the dashboard
e.g. climate control panel, Dynafleet panel and radio. These components are not regarded
as a part of the panel switches case study.
4.5.1 Usage today
The functions handled by the panel-switches each have their own dedicated positions in
the dashboard and this can make certain collections of switches quite spread out. The
most commonly used switches, though, are placed around the steering wheel in an
ergonomic way. Certain functions require the switch to have a tilt-resist in one direction,
others have not two, but three positions and some have spring-cushioned operation in one
or two directions. They all have six to eight connections, which results in a lot of wiring
on the backside. Two or three of the pins (depending on the type of switch) are used for
lighting LEDs in the switch for backlight and for indicating that the switch is active.
Figure 4.5 – Schematic picture of three different panel-switches
44
Electrical system analysis of a FH/FM truck
4.5.2 LIN solution
As the switches today both are connected to ECUs and directly wired to other
components, a new communication design for the panel switches, completely based on
LIN, will force other parts of the electrical system to be redesigned. This could be
avoided by partly keeping the old wires, which do not connect to an ECU. When
considering how LIN could be implemented to handle the panel-switches, a great number
of alternatives come up. A few of these are presented here:
• One slave per switch or one slave per backplane (controlling a few switches)
Letting each slave function as a LIN slave-node on the bus or grouping them
together, working under the surveillance of a common slave.
• Statically predetermined schedules or dynamically configured schedules
To have a LDF/database with nodes, schedules, frames and signals and have full
control of the network prior to run-time or letting the network determining the
configuration and schedules achieving better performance.
• Completely LIN-based solution or compromised solution with old system
Be conservative and introduce LIN in a small part of the truck adapting the LIN
solution to the existing truck or adapting the surroundings to LIN.
In this chapter two different approaches will be accounted for and in both cases there will
be no consideration to the surrounding electrical system. Hence a completely LIN-based
implementation will be deployed. Because of the great number of functions controlled by
the panel-switches only the 40 most used will be handled by the two approaches
discussed here. The two approaches include one where a slave node is implemented in
every panel-switch and one where panel-switches are mounted in groups on a backplane,
which in turn acts as a slave node. Both approaches use a kind of self-configuration and
dynamic scheduling and the idea is to make the panel switches more flexible, both
concerning assembly and configuration. The flexibility does come with a drawback. Due
to the fact that no predetermined schedule with frames and signals is available before
runtime it is not possible to generate a LDF and therefore simulation with development
tools is limited.
The case study with the panel-switches is of a more technically intriguing nature than the
LCP-case and the possibilities of practically implementing the approaches have not been
investigated thoroughly. Neither have the economical aspects. One thing in common with
the LCP-case though, is that the usage of the panel-switches is quite infrequent and the
sleep func tionality will be useful in this case too. If no panel-switch has changed state in
a certain amount of time, the master puts the network to sleep. First the two approaches
will be presented and then the calculations of the real- time properties will be shown.
45
Electrical system analysis of a FH/FM truck
4.5.3 Alternative 1: “One slave per switch”
In this approach each panel-switch will act as a LIN slave as mentioned earlier. A
schematic layout of the topology for the approach can be seen in Figure 4.6. As there are
more than 32 positions for the switches, three masters have to be used to handle the
slaves (max 16 slaves per master). How the bus from each master is drawn is not critical
but smart layout might improve response times, i.e. even distribution of slaves between
the masters. In order for the panel-switches to function properly, a number of
initialization-steps have to take place:
• First, switches have to be given a predetermined LIN-ID, a specific ID for every
function.
• Then, at startup, the master has to detect which switche s that are placed on its bus.
This is done by polling all possible switches and seeing what IDs that answer (40
functions).
• Finally, from the initial polling a schedule for the needed frames has to be
constructed for reading switch status and delivering LED information.
At the same time as the switch is given a LIN-ID it is also programmed to listen to
certain bits in a pre-determined broadcast message sent out by the master. This is done in
order for the switch to read and use information about the states of its LEDs determined
by the master. The last two steps discussed above should be performed automatically but
when and how often is not discussed in detail here. It could be done every time the truck
starts to just the very first time the truck is started.
1
2
3
n
MASTER
LIN
Figure 4.6 – System with one slave per switch
One benefit of having function-based LIN-IDs is that the switches can be placed in any
position. The three masters poll the 40 most often used functions and no matter where a
switch is placed one master will control it. From the slave’s point of view this polling
message will look like an ordinary polling message although the master uses it for
checking if the switch is on its network. Because any of the 40 switches may answer,
each master has to have specific application code in memory for each function although
it might not be used. This also enables switches to be moved around between the
positions without the need to reconfigure the networks.
When a master has received answers from the slave nodes present on its network, it has
to set up a schedule for polling the switches for status and sending a broadcast message
with LED states. The schedule that then will run is made up of up to 16 polling frames
where the switches answers with information of its current state. After the pollingframes, the master sends out a broadcast where data to each switch is present. Which
switch that listens to which bits are as mentioned earlier determined by the LIN-ID of the
switch.
46
Electrical system analysis of a FH/FM truck
4.5.4 Alternative 2: “Backplane”
As the introduction of logic in form of LIN slaves will bring extra cost for the panelswitches, this approach tries to reduce the number of slave nodes. The idea is to have a
few backplanes, one for each panel for the switches. On each backplane, a LIN slave
node will handle the communication with the master node and the interaction with the
switches placed on the backplane. A schematic layout of the topology for the approach
can be seen in Figure 4.7. The slave nodes will handle up to 10 switches each in this case
and therefore they have to be more powerful than the ones in the “one switch, one slave”approach discussed earlier. The interaction between the switches and the slave node is
off-topic for this report and will not be presented here.
LIN
MASTER
Figure 4.7 – System with switches on a backplane
The dynamic behavior of network setup and schedule generation is somewhat different
from the previous approach. Here one has a fixed number of slave nodes that is quite low
and can therefore have one schedule used to gather information of what switches are
present and one schedule that includes polling and LED-state broadcast messages.
Before the initial polling routine initiated by the master takes place, each slave node has
to scan its backplane to see what panel-switches are present. To identify the switches one
could use different switches for every function, programmed with an ID.
When the slave node has identified its own switches, the master runs an initial poll to
determine which backplane each switch is located on. After the master has established
what switches that are present, it changes schedule and starts polling the slave node for
switch status. When polled each slave answers with two bits of data for each switch on
its backplane. The broadcast message has the same properties as in the approach with one
LIN-slave per switch. The properties of the backplanes in a probable organizational
layout in a FH/FM truck concerning LIN are summarized in Table 4.2.
Max number
of switches 1
Size of polling message in
“normal operation” [byte] 2
Backplane 1
10
3
Backplane 2
7
2
Backplane 3
5
2
Backplane 4
5
2
Backplane 5
5
2
Backplane 6
4
1
Table 4.2 – Summation of the backplane-slaves
1
2
Numbers derived from current layout of the panel-switches in a FH/FM truck
Number of bytes required to hold data about the state of the panel-switch (2 bits per panel-switch)
47
Electrical system analysis of a FH/FM truck
4.5.5 Real-time properties
Both approaches discussed use an initial polling routine to establish what panel-switches
are present. As this procedure only occurs once it will not affect the “normal operation”
response times (a loop containing a number of polling messages for switch-positions and
one broadcast message with LED-state information for the switches) and will not be
included in this sub-chapter. The response times calculated here will only cover the
“normal operation”. The schedules used in the case study can be seen in Figure 4.8.
There is a difference between the two approaches concerning “normal operation”- mode
and that is the number of polling messages and the size of them.
1
2
...
Switch-poll n <= 16
n
LED-status
Backplane-poll
LED-status
Figure 4.8 – Schedules used in panel-switches case study
In the case study with the panel-switches it is useful to distinguish between the following
response times:
• Time taken from flipping a switch until the master detects the event
• Time taken from flipping a switch until the LED in the switch is lit
The first case relates to the actual initiation of the function the switch represents and the
second is of a more HMI (Human Machine Interaction) perspective. In today’s Volvo
trucks, there is no checking of the status of the function before turning on the LED in the
switch. This means that the LED is lit in the same instant as the switch changes state. It
could be useful though, to get a receipt (a lit LED) that indicates that the function really
is activated or deactivated. One example is the switch controlling the differential gear
locking where a driver can damage the truck if he does not know whether the lock is on
or off.
First, the “one switch, one slave”-approach will be discussed. For polling the switches
(REQ-message) the master node receives one data byte per switch containing 2 bits
representing the state of the switch. The CMD- message contains only one bit of
information per switch, telling it whether it should light its activation. The switch for
which the WCRT occurs is in this sub-chapter called “switch W” and the following
conditions must prevail:
• An event in switch W occurs just too late to be sent with the next scheduled REQmessage.
• The REQ- message is the last one sent for switch W before the network is put to
sleep by the master.
• In the schedule the REQ-message for switch W is placed just after the broadcast
message. The new LED-data for Switch W is not sent until the master is finished
polling the other switches.
• The network on which switch W is located has 16 slave nodes.
48
Electrical system analysis of a FH/FM truck
The events of the WCRT can be seen in Figure 4.9.When considering the conditions
above and using the frame delays given Table 4.1 on page 41, the following calculations
can be done, giving the WCRT for switch W.
WAKE-UP
REQ 1
REQ 2
...
REQ 16
REQ 1
REQ 2
...
REQ 16
CMD
SLEEP
Figure 4.9 – Events when WCRT occurs for the “one slave, one switch”-case study
Time for one lap in the schedule:
t loop _ 9 , 6 = 16 * t1 + t 5 = 175ms (9,6kbps)
t loop _ 19, 2 = 16 * t 1 + t 5 = 90ms (19,2 kbps)
Worst Case Response times for switch W:
t WCRT, Switch→ Master = t loop _ 9 , 6 − t 5 + t sleep + t wake− up + t1 = 186 ms
( 9,6 kbps)
t WCRT ,Switch→Master = t loop _ 19, 2 − t 5 + t sleep + t wake −uo + t1 = 96ms
(19,2kbps)
t WCRT, Switch→ LED = t loop _ 9 , 6 − t 5 + t sleep + t wake −up + t loop _ 9 , 6 = 351ms ( 9,6 kbps)
t WCRT, Switch→ LED = t loop _ 19 , 2 − t 5 + t sleep + t wake− up + t loop _ 19 , 2 = 181ms (19,2kbps)
If feedback from the function itself is necessary to light a LED in a switch or if it can be
done locally in the switch is not discussed further here. If the lighting of the LED is done
locally the one-way response times are of interest and they are quite low. As no functions
controlled by the panel-switches have hard real-time demands (of course) the delay
between flipping a switch to activating the function is quite small.
For the approach with switches mounted on a backplane, the conditions for WCRT are
almost the same. The events occur as in Figure 4.9 but with less REQ- messages being
sent. The differences are the layout of the network, i.e. number of messages sent, and the
size of the messages. Here the slave for which the WCRT occurs is in this sub-chapter
called “slave W”. Again using the frame delays given in Table 4.1on page 41 and
looking at the size of the messages in Table 4.2 on page 47 one gets:
Time for one lap in the schedule:
t loop _ 9 , 6 = t 3 + 4 * t 2 + t1 + t 5 = 80ms (9,6kbps)
t loop _ 19 , 2 = t 3 + 4 * t 2 + t1 + t 5 = 45ms (19,2 kbps)
Worst Case Response times for slave W:
t WCRT, Slave→Master = t loop _ 9 , 6 − t 5 + t sleep + t wake −up + t 3 = 101ms
(9,6kbps)
t WCRT, Slave→ Master = t loop _ 19 , 2 − t 5 + t sleep + t wake −up + t 3 = 56ms
(19,2kbps)
tWCRT , Slave→ LED = t loop _ 9 , 6 − t 5 + t sleep + t wake −up + t loop _ 9 , 6 = 166 ms (9,6kbps)
t WCRT, Slave→ LED = t loop _ 19 , 2 − t 5 + t sleep + t wake− up + t loop _ 19 , 2 = 96ms (19,2kbps)
For this approach, with backplanes, the response times decrease significantly. Here one
could use feedback from the function in terms of a lit LED in the switch without having
long delays.
49
Electrical system analysis of a FH/FM truck
4.5.6 Conclusions
Compared with LIN-communication for the LCP, the case with introduction of LINcommunication for the panel switches will have much greater impact on the electrical
system. This is due to two reasons:
• Today, connections from the panel-switches go to both ECUs and other
components. This forces a decision whether LIN should coexist with traditional
wiring to components or if a revision of a greater part of the electrical system
should be done.
• The current connections to ECUs not only go to one but many different ECUs.
This means that the information from the panel-switches in a LIN oriented
architecture has to be distributed by the master/masters on the CAN network to the
concerned ECU. This is opposed from today’s function where the panel-switches
are connected directly to the ECUs.
Another aspect is the response times. Without function activation feedback (i.e. the LEDs
in the panel-switches are lit locally) the LIN network introduces a delay of up to 100 ms.
Response time-wise the backplane approach is by far the best but the practical
considerations for the backplanes have not been investigated.
One thing that definitely speaks in favor of a LIN-based communication with the panelswitches is the reduction of wiring. From today’s six to eight wires to every switch to
three wires shared between the switches is a major reduction. This is valid for the
backplane approach where one single master, and hence one network, will handle all
panel-switches and the saving will be (for a truck with 10 panel-switches) 6 wires * 10
switches - 1 network * 3 wires = 57 wires saved. For the “one slave, one switch”approach the saving will be ) 6 wires * 10 switches - 3 network * 3 wires = 51 wires
saved.
4.6 Rear lamp module
This, the third case study, has not been investigated as thoroughly as the two others have.
This is because the case does not present any new aspects or features that the two former
cases do. The rear lamp modules contain all the regular rear bulbs found in other rear
lamp module in any vehicle.
4.6.1 Usage today
The rear lamp modules are directly connected to the LCM in the front of the truck, which
feeds the bulbs with 24V from its output pins with seven wires. Two wires are required
to handle the direction indicators and the remaining five wires are shared between the left
and right module for brake light, position light, fog light, reversing- light and ground. As
the modules are located up to six meter from the LCM on a tractor chassis (and up to11
meters on a rigid chassis); a lot of wiring is needed. Since it is important that the bulbs
are functioning from a safety perspective, diagnostics are performed on the wires in
terms of current measuring by the LCM.
50
Electrical system analysis of a FH/FM truck
4.6.2 LIN solution
In case of implementing communication with the rear light module with LIN, the seven
power-out pins from the LCM can be reduced to one data wire, one 12V feed and one
ground wire. This saves four I/O pins on the LCM and up to 11*(7-3)=44 meters of wire
(on a rigid chassis). As the LCM no longer can measure current in the bulbs for
diagnostic purposes, the slave has to carry out this action and report to the LCM. The
data transfer from the Rear Light Module to the LCM will entirely consist of this
diagnostic feedback. From the LCM, simple commands will be sent to the slave, which
states what bulbs that should light up.
CMD-message
Rear light status
REQ-message
Diagnostics
Figure 4.10 – Simple schedule for Rear Light Module case study
The simplest solution for a communication model is in this case a schedule consisting of
a light status message followed by a message containing diagnostics as seen in Figure
4.10. With this configuration both messages will have the same WCRT under the
assumption that the diagnostics can fit in a minimum size. A request to send a light status
message (pressing the brake pedal) can always occur just after a light status message has
started to be sent. The notification then has to wait for three messages before delivered to
the rear lights. It is however possible to minimize the number of occurrences when this
will happen and that is to use a schedule where not one, but many light status messages
are sent in a row followed by one diagnostics message. Here the decision has been made
not to use the sleep feature of LIN since response times would be affected negatively.
4.6.3 Real-time properties
Since the rear light module indicates for vehicles driving behind the truck that it is
braking, it is very important that the delay from pressing the brake pedal to lighting the
braking light is minimal. With a round robin time triggered schedule as used in LIN
networks, the only way to decrease the WCRT for light status messages is to minimize
the time taken for one lap in the schedule. The scenario occurs for the WCRT for lampactivation.
New lamp status
New status
CMD-message
REQ-message
CMD-message
Old lamp status
Diagnostics
New lamp status
Figure 4.11 - Events when WCRT occurs for the rear lamp module case study
Using one-byte frames for both messages (which gives enough space for data) and taking
the message times from Table 4.1, the following times are retrieved:
t WCRT = 3 * t1 = 30ms (9,6 kbps)
t WCRT = 3 * t1 = 15ms (19,2 kbps)
The delays calculated seem quite low. One must however remember that this is a delay
introduced by the LIN network that does not exist in today’s FH/FM trucks.
51
Electrical system analysis of a FH/FM truck
4.6.4 Conclusions
The most obvious advantage of controlling the rear lamp modules with LIN is the saving
of wires. Instead of the seven wires, three can be used (if the 24V feed for the bulbs is
taken from other components that already reside in the end of the truck). The delay
introduced in the system by the LIN network must however be considered when
calculating response times for the whole system.
One thing that could present a problem for integrating a LIN slave-node with the rear
lamps is the heat generation of the lamps. The seven bulbs, ranging from 5Wto 21W
generates a lot of heat that could present trouble for ICs. This is because automotive
specified ICs are built to handle up to +125°C, a temperature that could be exceeded in
the rear lamp modules. To separate the LIN node from the housing of the bulbs solves
this problem but the cost would increase significantly with an individual housing.
Another solution to the heat problem, which lies a bit further in the future, is to use LEDbased rear lights. Today these lights are rarely used and most often in luxurious cars e.g.
the new Audi A8, where cost is not critical. A drop in price will give LEDs for rear
lighting wider deployment in the automotive industry as they have a number of
advantages such as: extremely long life expectancy, low power consumption, fast
response times etc.
52
Implementation
5 Implementation
On the basis of the case studies in chapter 0, an implementation of a LIN-slave node was
done. The choice of which component to implement was discussed with concerned
people at Volvo and the decision was settled on the LCP. The choice was based on
several factors. One of the key factors was the complexity of the solution, i.e. the time it
would take to implement LIN-solution and the amount of reconstruction of other parts
involved with the control of the LCP. The LCP has fix functionality that is easily adopted
with the LIN communication and it is favorable when it comes to showing the
advantages on using LIN (e.g. cable and I/O pin reduction). Although it would be more
effective to show the full networking capabilities of LIN with the panel-switches case
discussed in sub-chapter 4.5, it is not practically viable to implement as a LIN-demo. The
panel-switches case solution would demand extensive investigations about how it would
affect the electrical system since it concerns and includes many other parts and
components of the truck. It would therefore not be possible to implement a solution that
would be as close to a real solution as the LCP- implementation in the same amount of
time. The rear lamp-solution would be practically realizable but it is not as interesting as
a demo since the interactivity between the master and slave nodes would be very limited,
which is not the case with the LCP.
The LIN-implementation was done on the LCP but not on the LCM. This was done due
to insufficient amount of time necessary to the implementation of both a master and a
slave. However, this limitation did not affect the demo considerably since the master was
fully emulated by the LIN-tools used in the project. It is of more value to see how an
implementation of a slave node is done since most of the LIN-components in a LINnetwork will inevitable be slave nodes. In addition to this, the master implementation in
the LCM would not only affect the LIN-communication but it would also put other
constraints to the LCM in form of new hardware requirements.
5.1 Communication model development
This sub-chapter will deal with the communication model with which the master and the
slave interact with each other. The model specifies the frames and the signals used to
send information between the slave and the master. A lot of the work with the
implementation was done with the help of LIN-tools, see sub-chapter 3.8. They were
especially useful when building and testing the network model since one can use them to
simulate not only the master but also the slave application and also see how the real-time
properties of the LCP-application was affected by different models.
5.1.1 Network configuration
The functionality of the LCP, described in sub-chapter 4.4, has to be controlled by the
use of signals that are sent to and polled from the LCM. The necessary signals used to
request status informa tion about the switches on the LCP are defined and placed in the
frame F_LCP_REQ and can be seen in Table 5.1.
53
Implementation
F_LCP_REQ (ID 2)
Data 0
Data 1
Action (Master)
S_Main_Sw
000XXX11
X
Receive Data
S_FF_Sw
000XX1XX
X
"
S_RF_Sw
000X1XXX
X
"
S_HW_Sw
0001XXXX
X
"
S_DimPot_Sw
X
0x00..0xFF
"
Table 5.1 – Signals in frame F_LCP_REQ (0 = not used, x = left alone)
The name of the signal describes the meaning and purpose of the signal. As an example
one can take the S_Main_Sw signal which is used for polling the status for the main
switch of the LCP. The abbreviations FF, RF, HW and DimPot stands for Front Fog light
switch, Rear Fog light switch, Hazard Warning light switch and the Dimmer
Potentio meter which all can be found on the LCP. Most of the switches only need one bit
to encode the status information and can either be 1 i.e. ON or 0 i.e. OFF. The status of
the main switch is encoded with 2 bits since it has 4 different modes; OFF, half light, full
light and full light with supplementary lighting. The dimmer switch is encoded with a
discrete value representing the voltage level from the potentiometer of the dimmer.
The signals defined for the feedback to the LCP from the LCM that are used to turn
on/off or dim the LEDs for the switches on the LCM, are sent with the F_LCP_CMD
frame and can be seen in below.
F_LCP_CMD (ID 0)
Data 0
Data 1
Action (Master)
S_FF_LED
00000XX1
X
Send Data
S_RF_LED
00000X1X
X
"
S_HW_LED
000001XX
X
"
S_BL_LEDs
X
0x00..0xFF
"
Table 5.2 – Signals in frame F_LCP_CMD (0 = not used, x = left alone)
As can be seen in the table, the signals in the command frame that is sent from the LCM
to the LCP, is encoded in the same manner as described for the F_LCP_REQ frame. The
signal S_BL_LEDs represents the discrete value of the dimmable backlights on the LCP.
5.1.2 Simulation
By creating a LDF for the frames and signals in accordance with the LIN-specification
[LIN02] the communication between the LCM and the LCP could be tested by
simulation with existing development tools. The goal with this was not only to get a
feeling of the tools but also to see how the real- time properties of the frames coincided
with the calculations done in the case study of the LCP. The tests were done between two
computers which both had a LIN-hardware- interface to the LIN-bus controlled by the
tools.
Since the master node was not implemented on a real node the tools were used to
program scripts that could emulate the LCM as a master. For more information about the
capabilities of the tools, see sub-chapter 3.8.
54
Implementation
5.2 Application development
When talking about the application development for the prototype, one should realize
that this took place, in a traditional way (assembler programming in this case), only in
the slave node. Built- in script languages in the development tools were used to mimic the
behavior of a real master with the tools. In both cases a platform for handling the LIN
communication was already present in more or less complete form. For the simulated
master node it consisted of a complete development program (Volcano Linspector and
Kvaser Navigator) that provides abstract interfaces for a user to design and to simulate
nodes or complete networks. For the slave node in the LCP, a LIN-protocol software
implementation from Microchip Technology Inc was used [MICLIS]. This chapter will
discuss how the software in the slave node was constructed and how the simulation of the
master in the development tools was done.
5.2.1 Slave node
The application running in the slave node can logically be divided into two categories:
software for handling the LIN protocol communication and software for handling the
switches, LEDs and other functions on the LCP. A schematic overview can be seen in
Figure 5.1. All code is written in assembler for the PIC16F870 microprocessor from
Microchip Technology Inc.
LCP-functionality
software
Microchip LIN protocol
implementation
UART
µP modules (AD, PWM, timers)
LIN-transceiver
LCP
Figure 5.1 – Layered overview of the software in the slave node
The Microchip LIN-protocol implementation can be regarded as a low level API
(Application Program Interface) allowing the user to make procedure calls from a higher
level of abstraction, hiding lower level functionality. It was retrieved from Microchip’s
web page [MICWEB] and consists of source files and definitions, written in assembler
for the Microchip’s PIC processors. It provides functionality for handling the LIN
protocol based on an existing UART module. The organization of the included source
files and how generic they are can be seen in Figure 5.2. See appendix B.2 for all files
included in the slave node software.
IdX.asm
timer.asm
lin.asm
linevent.asm
No change
Configuration needed
dependant on IDs
New content dependant
on application
Figure 5.2 – Files included in the Microchip LIN protocol implementation
55
Implementation
• The files lin.asm and timer.asm contain the most basic and general functionality
for the LIN protocol
• In the file linevent.asm the IDs are defined that the slave should react to and this
file has to be reconfigured for each slave
• For every ID that the node should react on there is a corresponding file that
handles the actions taken upon receiving a message header with the ID
The Microchip LIN protocol implementation was developed before the first specification
was released from the LIN consortium, which means that there are parts in the
implementation not in compliance with the LIN specification [LIN02]. Hence a few
alterations has been made to adapt the protocol implementation to the LIN specification,
[LIN02]. One example is the introduction of a synchronization procedure, which the
implementation originally does not use. This is because it assumes that accurate clocks
are used in the slave nodes, which means that the slaves and master always have baudrates so closely matched that no synchronization is needed.
The software for the LCP-functionality utilizes different modules in the microcontroller,
e.g. timers, PWM modules (Pulse Width Modulation) and A/D-converters, to detect
changes in switches and to light the LEDs in the LCP. It is also here that data sent from
the master is taken care of. This functionality is included in the idXX.asm files. Figure
5.3 presents a flow chart on how all the source files in the slave node software interact.
For a detailed description of how the communication part of the code is organized, see
appendix
main.asm
id00.asm
id01.asm
iid60.asm
timer.asm
lin.asm
linevent.asm
Figure 5.3 – Flow chart on how the files in the slave software interact
56
Implementation
5.2.2 Master node
As described in sub-chapter 3.8, the development tools are capable of emulating nodes
on a LIN network. This feature was utilized to build up a master node, which controlled
the communication with the LCP. The behavior of the master was defined in a LEC (LIN
Emulation Control) file for Volcano Linspector and in a USR (Universal Scripting Real
Time Language) file for Kvaser Navigator. In a real master in an ECU it is likely that the
hardware handles other functions besides the LIN communication. These activities were
however not taken under consideration when writing the scripts.
The organizations of the scripts are quite similar for the two tools although execution of
scripts is handled in different ways (infinite loop in Linspector and event based in
Kvaser). Since the objective of the implementation was to build a slave node for the
LCP, the interest lay in verifying the function of the slave node and the network. This led
to relatively little code in the scripts representing the application of the master and simple
relaying of signals. When a signal comes from the LCP e.g. saying that the front fog light
switch is activated, the master notices this and sets the appropriate signal in the next
outgoing (CMD) message. This tells the LCP that is should light the LED indicating that
the front fog light is activated.
Due to legal constraints, some combinations of headlight usage on the truck are illegal.
An example is that the front fog light can not be activated when the half- light is on.
These constraints are also implemented in the master node scripts besides the standard
relaying of signals.
5.3 Hardware development
In this sub-chapter the hardware coupling of the original LCP i.e. the LCP used in
FM/FH-trucks today, and the LCP with LIN is discussed. Further a closer look will be
taken at the hardware-components used to the build the LIN-implementation.
5.3.1 LCP/Microcontroller interface
A demonstrational requirement on the hardware implementation was to use the LCP in
its original form. The advantage with this was that it was easier to use the already present
circuitry in the LCP instead of creating a new one. The circuitry in its original form is
powered with 24 volt and consists of switches for the main light, the hazard warning
light, the front and rear fog light, LEDs for the background lighting, LED- indicators for
some of the switches, a potentiometer for the dimmer thumb-wheel and some current
limiting resistors.
57
Implementation
Original LCP coupling
In its original usage, all of the switches except the dimmer thumb-wheel switch are all
wired from ground to the LCM, meaning that when a switch is closed a zero will be
detected at the connected LCM port. The dimmer switch is implemented with a simple
potentiometer, which delivers voltage levels between 2 and 22 volt to the LCM. Based on
the value received from the dimmer, the LCM controls the background LEDs in the LCP
with a PWM-signal in order to change the intensity of them i.e. dim the LEDs. The front
and rear fog-LEDs are lit with a fix light intensity when the switches are activated. The
hazard warning LED is switched between lit and unlit in a fix interval i.e. it blinks when
activated. A schematic overview of the components included in the circuitry can be seen
in Figure 5.4.
Connections
from/to the LCM
Main light
switch
24V
Front fog
switch
Dimmer
thumbwheel
LCP
Rear fog
switch
Hazard
switch
Background
LEDs
Front fog
LED
Rear fog
LED
Hazard
LED
Figure 5.4 – Schematics over the circuitry of the LCP
LCP with microcontroller coupling
The LIN-solution does not introduce any considerable problems for powering and
controlling the LCP. The switches are connected to input pins of the slave node (i.e the
microcontroller) together with a pull- up resistor for each switch. This is done in order to
have a well-defined high input level when the switch is open, otherwise the input-pin on
the microcontroller would be left floating. The potentiometer of the dimmer thumb-wheel
switch is simply connected to an A/D-converter in the microcontroller. A resistor
connected between ground and the potentiometer is necessary to adjust the analog input
to appropriate values for the microcontroller.
The only discrepancy from the original LCP is that it is powered with 12 volt instead of
24 volt. However, this does not affect the functionality of the LCP and is only done for
convenience purposes. The only difference is that another power supply source of 24 volt
would have to be added in order for the LIN-solution to be in accordance with the
original solution.
The LEDs for the switches is thus powered with 12 volt. Since the microcontroller only
supplies 5 V, an OP-amplifier acting as a comparator was connected to and controlled by
the microcontroller to supply the necessary power to the LEDs. A discrete control signal
would trigger the comparator and provide the LEDs with either 0 or 12volt. One can
view the comparator as a switch triggered by a digital signal. Since the background LEDs
also had to be dimmable, a PWM-signal from the microcontroller was used to control
one of the outputs on the comparator. For the schematics of the LCP- microcontroller
circuitry see appendix B.1.
58
Implementation
5.3.2 Hardware components
In addition to the original LCP hardware the LIN- implementation was constructed with
the following components:
•
Microcontroller from Microchip (PIC16F870) with the following recources:
o An internal clock running at 2.5 MHz generated by a RC-oscillator.
o 3 timers, used for the PWM-signal generation, the LIN-communication
and the hazard light.
o An A/D-converter, used for converting the voltage levels of the dimmer
potentiometer to digital values.
o A PWM- module used for dimming the background LEDs of the LCP.
o A UART- module used for the LIN-communication
o 22 I/O ports of which 15 were used (e.g. used for A/D-conversion, PWM,
LIN-communication etc.).
o 2 Kbyte flash program memory, 128 byte RAM and 64 byte EEPROM
•
LIN-transceiver from Microchip (MCP201)
•
OP-amplifier from Texas Instruments (TL084CN)
•
Various resistors and capacitors (e.g. used for decoupling, pull- up, oscillator etc.)
The list above consists mainly of components necessary for controlling the LCPapplication. The recourses used for implementing the LIN-communication in the
microcontroller are a small part of the total usage. One timer was necessary for frametiming and baud rate synchronization; the UART module was also used in order to
encode the data bytes; and of the total 15 I/O-pins used, 5 were used in order to
communicate with the LIN-transceiver.
59
Conclusion
6 Conclusions and discussion
During the progression of this thesis work, a rather clear view of the aspects of LIN has
been developed, aspects of which some have implications on possible implementation in
Volvo trucks. In this chapter, conclusions made during the work will be presented
together with some discussions.
6.1 LIN specification
One thing to be noted with LIN is that it is tailored for the automotive industry and
especially for the car industry. Consideration has been taken to several key properties
ranging from lowest physical level to framing of messages and error detection. A number
of key features follows:
• Enabling of easy integration in a vehicle with respect to EMC thanks to the low
EME values specified by the slew rate/slope control of the pulses on the bus. Also,
the relatively high voltage level at which LIN operates tolerates more EMI than a
5-volt system that contributes to good EMC. A feature, more and more important
as the amount of EMI in vehicles increases with added electronic equipment.
• Low cost implementation thanks to usage of existing protocols and hardware
modules (UART) and single-wire implementation for the bus i.e. weight reduction
is maximized. Also, the master/slave architecture avoids the need for contention
control of the bus, simplifying hardware.
• Specified data rates implying focus on a distinct area of operation. LIN does not
contend for the title “best general purpose vehicle bus” but focuses on
communication between nodes with low real- time demands and fairly little data to
send. This avoids any compromises concerning data rate, EME and cost.
6.2 The usage of LIN in Volvo trucks
When it comes to the multiplexing nature of LIN this is a major step forward for
connecting components in a truck compared to single-signal dedicated wires. In many
cases the mere reduction of wiring needed to connect to a component may make up for
the increase in cost for logic introduced in the component. This speaks in favor of further
investigation of LIN for use in Volvo trucks.
One property derived from the car industry is the fact that LIN operates at 12 volt, which
is what car batteries provide natively. In a greater perspective it is however not so
convenient to have one specified voltage level. One concern arises when thinking of the
extensive discussion about desired new voltage levels in vehicles with 14/42-volt
systems. For integration of LIN in a vehicle with such an electrical system there is a need
for a separate 12- volt powering of the LIN network. Many truck producers looking at
LIN today are already facing this issue with separate 12-volt power since many trucks
use a 24- volt electrical system.
61
Conclusion
The interest in LIN is however quite big in the truck industry and this has given rise to a
call for a truck-adapted version of LIN, running at 24 volt. It is technically not
impossible but the specified EME properties in the current specification of LIN will not
be met. Whether Volvo should wait for a possible LIN specification for 24-volt electrical
systems or invest in the current version of LIN is not in the scope of this thesis work.
However, we think that substantial benefits can be found in using LIN in Volvo trucks.
6.3 Implementation of the demonstrator
When implementing a LIN slave node with the LCP, a hands-on experience of what LIN
is was achieved. The most obvious reflection from the work with the slave node is how
little that was required in hardware to get the node communicating over LIN. The
software implementation of the LIN protocol that was used came from Microchip
Technologies Inc., see [MICLIS]. It uses approximately 450 words of program memory
and approximately 25 bytes of data memory, see [MICLID]. This implementation took
use of only an UART module and one timer in the microprocessor for the
communication.
The existence of an UART module is more or less vital when implementing a slave node
with a microcontroller. The reception and sending of data together with framing control
handled in the UART greatly simplifies the source code and saves a lot of computation.
There are also UART modules for microcontrollers with more features (called enhanced
UART, EUART), such as automatic break detect and possibility to sent break signals.
The lift in ease of use that these features provide is however, not as big as the lift that the
basic functions of an ordinary UART module provide. Hence an ordinary UART in a
microcontroller will suffice for use with LIN communication.
6.4 Development tools
The existence of well adapted development tools is essential for the success of LIN. The
ones introduced to us in this thesis work were of great help when debugging and
analyzing our implementation. Although the communication in the implementation is
quite simple and few nodes are present on the network the overview of the
communication in real-time gave a very good picture of what was happening on the
network. The more complex a network is with communication with several real nodes,
the more important the simulation/analysis tools become.
When networks start getting bigger and different versions on networks is needed for
different setup of the vehicle, the importance of a tool for managing signals and nodes
gets bigger. Vector’s CANoe and Volcano’s LNA have a lot of functionality for this
purpose with signal database interaction, visualization of schedules and network
configurations etc, functions which are important when developing large LIN-networks.
6.5 Future work
There are a great number of aspects before a decision can be made whether LIN should
be incorporated in future trucks. All of these aspects have not been fully investigated in
this thesis work. Here are the two most important:
62
Conclusion
• Economical aspects. Conduct a thorough economical analysis of savings and new
costs for integrating LIN in the truck. Key issues here are benefits from LIN in
variant handling, production line costs/savings, development cost, component
pricing.
• Electrical consequences. In order to check the compatibility of LIN with the rest of
the electrical system in the truck one have to make detailed tests about EMC and
power consumption.
The LIN-implementation for the LCP was only conducted for a demonstrational purpose
and it would be insightful to test the LCP with LIN-communication in a real truck. The
next natural step would be to implement the LIN-protocol in the LCM. One would then
get real test results on how the real-time properties of LIN behave together with an
operational ECU.
63
References
References
[LINWEB]
LIN consortium, Frequently Asked Questions And Answers,
http://www.lin-subbus.org/main.asp?cls=online&method=view
&id=985, April 1 2003, visited 2003-04-03
[BAD00]
J. Will Specks, Antal Rajnak, LIN – Protocol, development tools and
software interfaces for Local Interconnect Networks in vehicles, 9th
international conference on Electronic systems in vehicles, Baden-Baden
October 5 2000
[LIN00]
LIN Consortium, LIN Protocol Specification Package , Revision 1.2,
November 17 2000
[LIN02]
LIN Consortium, LIN Protocol Specification Package , Revision 1.3,
December 12 2002
[MHC908]
Motorola Semiconductors, MC68HC908EY16 Advance Information rev 4,
http://e-www.motorola.com/brdata/PDFDB/docs/
MC68HC908EY16.pdf, February 2003, visited 2003-03-10
[MIC423]
Microchip Technologies Inc., PIC16C432 Datasheet,
http://www.microchip.com/download/lit/pline/picmicro/familie
s/16c43x/41140b.pdf, 2002, visited December 10 2002
[MIC433]
Microchip Technologies Inc., PIC16C433 Datasheet,
http://www.microchip.com/download/lit/pline/picmicro/familie
s/16c43x/41139b.pdf, 2002, visited December 10 2002
[INTLIN]
Intelliga Integrated Design, Electronic, Design Conslultants, UK based
ASIC design house, http://www.intelliga.co.uk/pages/
mainframe.htm, visited March 1 2003
[AMILIN]
AMI Semiconductors, Mixed-signal sensor interface ASICs,
http://www.amis.com/mixed_signal/auto_lin.cfm, visited April 3
2003
[CYPLIN]
Cypress semiconductor corporation, REFERENCE DESIGN:
CY3220LINBUS-RD, http://www.cypress.com/support/
reference_designs.cfm?objectID=DBB46B1E-F953-4B84BC0A89B0561E00A3&tid=54A040FA-2262-424A-B14741267CBD1308,
visited April 1 2003
[CAL03]
Christopher A. Lupini, Multiplex Bus Progression 2003, SAE Technical
Papers Series, March 6 2003
[TTAWEB] Time triggered Architecture group web-site, www.ttagroup.org, visited
January 18, 2003
[TTA02]
Hermann Kopetz et al., Specification of the TTP/A-Protocol V 2.00, RealTime Systems Group, University of Technology Vienna, September 2002
65
References
[MICLIS]
Dan Butler, Thomas Schmidt, Thorsten Waclawczyk, AN729 – LIN
Protocol Implementation using PICmicro® MCU – source code,
http://www.microchip.com/download/appnote/pic16/00729.zip,
Februari 4 2000, visited 2003-01-15
[MICWEB] Microchip Technologies Inc., Microchip Graphic Explorer Homepage,
http://www.microchip.com/1010/index.htm, visited 2003-04-03
[MICLID]
Dan Butler, Thomas Schmidt, Thorsten Waclawczyk, AN729 – LIN
Protocol Implementation using PICmicro® MCU documentation,
http://www.microchip.com/download/appnote/pic16/00729a.pdf,
Februari 4 2000, visited 2003-01-15
66
Appendix
Appendix
Appendix A
A.1
Development tools
Example of a LIN Description File
// This is a LIN description example file, Lin_12.ldf
//-------------------------------------------------------------------------LIN_description_file ;
LIN_protocol_version = 1.2;
LIN_language_version = 1.2;
LIN_speed = 20 kbps;
//-------------------------------------------------------------------------Nodes {
Master: DOOR_CONTROL, 2.5 ms, 0.1 ms;
Slaves: LOCK, LIFT;
}
//-------------------------------------------------------------------------Signals {
Lock_Action_Sig:1, 0, DOOR_CONTROL, LOCK;
Lock_Status_Sig:1, 0, LOCK, DOOR_CONTROL;
Door_Close_Status_Sig: 1, 0,LOCK, DOOR_CONTROL;
Lift_Action_Sig:1, 0, DOOR_CONTROL, LIFT;
Lift_Set_Speed_Sig:2, 0, DOOR_CONTROL, LIFT;
Lift_Set_Direction_Sig:1, 0, DOOR_CONTROL, LIFT;
Lift_Status_Sig:1, 0, LIFT, DOOR_CONTROL;
Lift_Close_Level_Sig:7, 0, LIFT, DOOR_CONTROL;
}
//-------------------------------------------------------------------------Frames {
//------------------------------------Lock_Action_Frm:16,DOOR_CONTROL, 2 {
Lock_Action_Sig, 0;
}
Lock_Status_Frm:12, LOCK, 2 {
Lock_Status_Sig, 0;
Door_Close_Status_Sig, 1;
}
Lift_Status_Frm:14,LIFT, 2 {
Lift_Status_Sig, 0;
Lift_Close_Level_Sig, 1;
}
Lift_Action_Frm:18 ,DOOR_CONTROL, 2 {
Lift_Action_Sig, 0;
Lift_Set_Speed_Sig, 1;
Lift_Set_Direction_Sig, 3;
}
}
//-------------------------------------------------------------------------Schedule_tables {
Status_Table {
Lift_Status_Frm delay 250 ms;
Lock_Status_Frm delay 250 ms;
}
Lock_Status_Table {
Lock_Status_Frm delay 500 ms;
}
Lift_Status_Table {
Lift_Status_Frm delay 500 ms;
}
}
A1
Appendix
//-------------------------------------------------------------------------Signal_encoding_types {
Lock_Action_Type {
logical_value, 0, "Lock";
logical_value, 1, "unLock";
}
Lock_Status_Type {
logical_value, 0, "Locked";
logical_value, 1, "UnLocked";
}
Close_Status_Type {
logical_value, 0,"Closed";
logical_value, 1,"Open";
}
Lift_Status_Type {
logical_value, 0, "Stopped";
logical_value, 1, "running";
}
Lift_Action_Type {
logical_value, 0, "StartLift";
logical_value, 1, "StopLift";
}
Lift_Speed_Type {
logical_value, 0, "NoSpeed";
logical_value, 1, "HalfSpeed";
logical_value, 2, "FullSpeed";
}
Lift_Dir_Type {
logical_value, 0, "Up";
logical_value, 1, "Down";
}
Lift_Close_Level_Type {
physical_value, 0, 100, 1, 0, "Percent";
}
}
//-------------------------------------------------------------------------Signal_representation {
Lock_Action_Type: Lock_Action_Sig;
Lock_Status_Type: Lock_Status_Sig;
Close_Status_Type: Close_Status_Sig;
Lift_Status_Type: Lift_Status_Sig;
Lift_Action_Type: Lift_Action_Sig;
Lift_Speed_Type: Lift_Set_Speed_Sig;
Lift_Dir_Type: Lift_Set_Direction_Sig;
Lift_Close_Level_Type: Lift_Close_Level_Sig;
}
//--------------------------------------------------------------------------
A2
Appendix
A.2
Screenshot of the Kvaser Navigator
A.3
Screenshot of the Volcano LINspector
A3
Appendix
Appendix B
B.1
Prototype
LCP-microcontroller circuitry
B1
Appendix
B.2
Files included in slave node software
The files below are included in the project for which the software in the slave node was
developed. For every source file but main.asm, a header file is present holding
declarations for global variables and subroutines. The linker file is used by the assembler
to map generated machine code to memory positions in the microcontroller. The
definition file holds definitions for the LIN communication and oscillator frequencies for
the microcontroller.
timer.asm
id00.asm
id01.asm
id60.asm
lin.inc
linevent.inc
timer.ínc
id00.inc
id01.inc
id60.inc
linker-files:
lin.lkr
definition-files:
main.asm
linevent.asm
header-files:
lindefc
lin.asm
B2
source-files:
Appendix
B.3
Flowchart of the LIN-communication
Interrupt handler
Interrupt from falling
edge in sync-field
Yes
No
Yes
First edge
detected
Yes
Framing error received
Last edge
detected
Start synctimer
No
Yes
No
No
Sync break
already received
ERROR, reset
state flags
No
Sync break
already received
Detect sync
break
ERROR, reset
state flags
No
Yes
Check if data =
0x55
ID field already
received
Stop timer and
Calculate baudrate
Wait for next
falling edge
Yes
No
Sync field already
received
Yes
No
No
Yes
Wait for ID -field
ERROR, reset
state flags
Yes
Check if ID means send
or receive or nothing
Yes
Receive data
No
Yes
ID means send
Yes
Calculate checksum
Yes
Compare checksums
for validity of data
Last data byte
received
No
Yes
Calculate and
send checksum
No
Last byte sent
No
No
Yes
ID means receive
Send data byte
Checksum
received
Transmit one byte
No
Wait for incoming data
Wait for next sync break
Receive data byte
B3