Beruflich Dokumente
Kultur Dokumente
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
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
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
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
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.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
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.
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
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
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
Message frame
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
Master
LIN-bus
Slave
Slave
Slave
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-bus
Slave
Slave
Slave
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-bus
Slave
Slave
Slave
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
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.
26
SYNC-break by master
Start 0
7 Stop
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.
27
Notional generation
Transmission completed
Notional consumption
TGL
TSL
TT Max age
TNL
TCL
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 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
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
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.
30
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.
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.
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.
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.
Figure 3.15 A LINgo graphical display of LIN message activity in a simulation in LINspector.
35
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.
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.
38
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.
40
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.
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.
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
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.
43
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.
44
45
3 LIN
MASTER
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
LIN
MASTER
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
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
...
Backplane-poll LED-status
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
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.
50
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.
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
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.
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 " " " "
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 " " "
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
LCP-functionality software
P modules (AD, PWM, timers) LCP
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
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
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
24V
Dimmer thumbwheel
LCP
Hazard LED
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
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
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.
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
[MIC423]
[MIC433]
[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,
66
Appendix
Appendix
Appendix A
A.1
Development tools
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
A.3
A3
Appendix
Appendix B
B.1
Prototype
LCP-microcontroller circuitry
B1
Appendix
B.2
timer.asm
main.asm
id00.asm
id01.asm
id60.asm
source-files:
linevent.inc
timer.nc
id00.inc
id01.inc
id60.inc
header-files:
lindefc
linker-files:
definition-files:
B2
Appendix
B.3
Yes
No
Yes
Yes
Yes
No
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
Yes
Yes
Yes
Calculate checksum
Yes
Yes
Checksum received No
No
B3