LIN Local Interconnect Network for use as sub-bus in Volvo trucks

Anders Rylander & Erik Wallin

Masters Thesis Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY Department of Computer Engineering Gteborg 2003

Innehllet i detta hfte r skyddat enligt Lagen om upphovsrtt, 1960:729, och reproduceras eller spridas i ngon form utan medgivande av frfattaren. Frbudet gller hela verket svl som delar av verket och inkluderar lagring i elektroniska och magnetiska media, visning p bildskrm samt bandupptagning. Anders Rylander och Erik Wallin, Gteborg 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 undersker mjligheterna och frdelarna med att anvnda LIN som ett multiplexat elsystem i en modern Volvo- lastbil ur FH/FM-serien. LIN r ett kommunikationsprotokoll som r designat fr 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 ssom ABS, vxellda, belysning etc. Idag r dock mnga av de enklare funktionerna direkt kopplade till de kontrollerande ECU:erna och mngden kablage r drfr mycket stor. Infrandet av ett multiplexat ntverk som exempelvis LIN skulle inte bara minska kostnader och vikt fr kablage utan ven introducera nya och flexiblare lsningar fr att sammankoppla komponenter i en lastbil. Underskningar har gjorts rrande tekniken bakom LIN liksom de ndvndiga resurser fr hrdvara och mjukvara som behvs fr att implementera LIN-kommunikation mellan komponenter i lastbilen. I demonstrationssyfte har en implementation av LIN-protokollet med framgng genomfrts p reglaget fr ytterbelysningen p en Volvo lastbil, vilket belyser ngra av frdelarna med LIN. P grund av lastbilens idag s komplexa elektriska system, skulle en infrande av ytterligare ett ntverk som t.ex. LIN vara omjligt utan tillbrligt std frn utvecklingsverktyg. Drfr undersks i denna rapport ngra av de verktyg som finns p marknaden och beskriver deras grundlggande egenskaper och funktionalitet.

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, Bjrn Villing and Jan Sderberg 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 BACKGROUND PROBLEM FORMULATION SCOPE AND OBJECTIVES 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

METHOD 2.1 2.2 2.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 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

IX

4.6.3 4.6.4 5

Real-time properties Conclusions

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

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

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

Terms and Abbreviations

ABS Anti Spin System Antilocking Brake System. Computer controlled brake system that prevents the wheels of a vehicle from locking. Computer controlled system that prevents the wheels of a vehicle from spinning and loosing traction with the road surface. Wireless personal area networking technology Controller Area Network. High speed network for handling real-time data. 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. Electromagnetic Compatibility. The degree of electromagnetic tolerance and emission for a component. Electromagnetic Emission. A measurement on how much of electromagnetic emission a component emits. Electromagnetic Interference. A measurement on how much electromagnetic emission a component is exposed to. Deterministic and fault-tolerant bus system for advanced automotive control applications. International Organization of Standardization LIN Description File. A file where configuration information (signals, frames, speed) about the LIN-network can be found. Local Interconnect Network. Low speed network for connecting simple functions in a vehicle Microcontroller Unit Media Oriented System Transport. Very high speed network for media traffic in a vehicle Original Equipment Manufacturer An assembly of gears and associated parts by which power is transmitted from an engine to a driving axle.

Bluetooth CAN ECU

EMC EME EMI FlexRay ISO LDF

LIN MCU MOST OEM Power train

12

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. Society of Automotive Engineers. A standardization organization for automotive technologies 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. Time Triggered Protocol. A family of time-triggered protocols for real-time communication. An extension to CAN-networks where messages are sent in a time triggered manner in contrast to CANs event driven, priority based sending Two cables twisted together to minimize EMI. Volvo Truck Corporation. The company within the The Volvo Group manufacturing trucks.

SAE Slew-rate

TTP TT-CAN

Twisted pair VTC

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 ECUs (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 ECUs directly connected with various functions using lots of wires, has some weaknesses concerning scalability and flexibility. Today the number of ECUs 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 ECUs 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 todays 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 automotiv e 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 Medium access control Typical bus speed Multicast message routing Typical size of network Data byte per frame Transmission time for 4 data bytes Error detection (data field) Physical layer Quarts/ceramic resonator Relative cost per network connection single master 2.4, 9.6 and 19.2kbps 6 bit identifier 216 nodes 0 8 6 ms at 20kbps 8-bit checksum single-wire, 12 V master only x 0.5
1

CAN multiple masters 62,51000kbps 11/29 bit identifier 420 nodes 28 0.8 ms at 125kbps 15-bit CRC twisted-pair, 5 V Yes 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

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

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 Frame header Identifier 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 masters 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 Bus sleep

Wake -up delimiter

SYNC-break by master

Start 0

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 Signal value available to subscribing application

Notional generation

Frame enters transmission

Transmission completed

Notional consumption

TGL

TSL

TT Max age

TNL

TCL

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 masters 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 its 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 its 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 Time base Frame delay Frame period 2 3 1 Slack 2 Time

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 Table entry 2 Table entry 1

Header L

Response G

Header

Response H

Header E

Response time

Delay frame 1

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 dont. 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 slaves sampling rate (i.e. baud-rate) to the masters. 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 masters and the slaves baud-rate can at most be 2% after a successful synchronization, otherwise its 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 Navigators 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 Kvasers 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 masters 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. Its 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 VTCs 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 1,8 4,7 Frame delay [ms] 5 = t1 5 = t2 10 = t3 10 = t4 10 = t5 10 = t6 10 = t7 10 = t8 10 = tsleep twake-up 19.2 kbps Message transfer time [ms] 4,0 4,7 5,5 6,2 6,9 7,7 8,4 9,1 9,1 0,6 Max difference: Slack [ms] 1,0 0,3 4,5 3,8 3,1 2,3 1,6 0,9 0,9 4,5

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 trucks batteries. The benefit of a LIN solution partly consists of the decrease in wires necessary for the communication. From todays 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 REQ-message Old switch status SLEEP-command WAKE-UP REQ-message New switch status CMD-message New LED status New 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 switchs 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.

3 LIN

MASTER

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 slaves 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 slaveapproach 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 Backplane 1 Backplane 2 Backplane 3 Backplane 4 Backplane 5 Backplane 6 10 7 5 5 5 4 Size of polling message in normal operation [byte] 2 3 2 2 2 2 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.

...

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 todays 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 SLEEP REQ 1 REQ 2 ... REQ 16 CMD

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 ,SwitchMaster = 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, SlaveMaster = 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 todays 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 todays 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 switchapproach 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 CMD-message Old lamp status REQ-message Diagnostics CMD-message New lamp status New 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 todays 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) S_Main_Sw S_FF_Sw S_RF_Sw S_HW_Sw S_DimPot_Sw Data 0 000XXX11 000XX1XX 000X1XXX 0001XXXX X Data 1 X X X X 0x00..0xFF Action (Master) Receive Data " " " "

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) S_FF_LED S_RF_LED S_HW_LED S_BL_LEDs Data 0 00000XX1 00000X1X 000001XX X Data 1 X X X 0x00..0xFF Action (Master) Send Data " " "

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.

Microchip LIN protocol implementation

UART LIN-transceiver

LCP-functionality software
P modules (AD, PWM, timers) 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 Microchips web page [MICWEB] and consists of source files and definitions, written in assembler for the Microchips 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.
No change IdX.asm Configuration needed dependant on IDs New content dependant on application linevent.asm

timer.asm

lin.asm

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 iid60.asm

Figure 5.3 Flow chart on how the files in the slave software interact

id00.asm timer.asm

id01.asm lin.asm

linevent.asm

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 Front fog switch

Front fog LED

24V

Dimmer thumbwheel

LCP

Rear fog switch

Rear fog LED

Hazard switch Background LEDs

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. Vectors CANoe and Volcanos 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 LIN Consortium, LIN Protocol Specification Package , Revision 1.2, November 17 2000 LIN Consortium, LIN Protocol Specification Package , Revision 1.3, December 12 2002 Motorola Semiconductors, MC68HC908EY16 Advance Information rev 4,
http://e-www.motorola.com/brdata/PDFDB/docs/ MC68HC908EY16.pdf, February 2003, visited 2003-03-10

[LIN00] [LIN02] [MHC908]

[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 AMI Semiconductors, Mixed-signal sensor interface ASICs, http://www.amis.com/mixed_signal/auto_lin.cfm, visited April 3 2003 Cypress semiconductor corporation, REFERENCE DESIGN: CY3220LINBUS-RD, http://www.cypress.com/support/
reference_designs.cfm?objectID=DBB46B1E-F953-4B84BC0A89B0561E00A3&tid=54A040FA-2262-424A-B14741267CBD1308,

[AMILIN]

[CYPLIN]

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.
linevent.asm

timer.asm

main.asm

id00.asm

id01.asm

id60.asm

lin.asm lin.inc lin.lkr

source-files:

linevent.inc

timer.nc

id00.inc

id01.inc

id60.inc

header-files:

lindefc

linker-files:

definition-files:

B2

Appendix

B.3

Flowchart of the LIN-communication

Interrupt handler

Interrupt from falling edge in sync-field No

Yes

First edge detected

No

Yes

Framing error received No

Yes Start synctimer

Last edge detected

Yes

Yes

Sync break already received Yes

No

Stop timer and Calculate baudrate

ERROR, reset state flags

No Detect sync break

Sync break already received No

Wait for next falling edge

ERROR, reset state flags

Sync field already received Yes

No

Check if data = 0x55 ID field already received Yes Check if ID means send or receive or nothing Yes Receive data No ID means send No No

Yes

Wait for ID -field

ERROR, reset state flags

Yes

Yes

Last data byte received No

Yes

No Last byte sent Transmit one byte

Calculate checksum

Calculate and send checksum

No ID means receive Send data byte

Yes

Yes

Checksum received No

No

Wait for incoming data

Compare checksums for validity of data

Wait for next sync break

Receive data byte

B3