Institutionen för systemteknik
Department of Electrical Engineering
Examensarbete
A study of efficient sensor I/O interface and signal
acquisition techniques for electrical control units.
Examensarbete utfört i elektroniska komponenter vid Tekniska högskolan i Linköping
av
Michael Pettersson LiTH-ISY-EX--10/4400--SE
Linköping 2010
Department of Electrical Engineering Linköpings tekniska högskola
Linköpings universitet Linköpings universitet
acquisition techniques for electrical control units.
Examensarbete utfört i elektroniska komponenter
vid Tekniska högskolan i Linköping
av
Michael Pettersson LiTH-ISY-EX--10/4400--SE
Handledare: Professor Atila Alvandpour
isy, Linköpings University
Examinator: Professor Atila Alvandpour
isy, Linköpings University
Division of Electronic Devices Department of Electrical Engineering Linköpings universitet
SE-581 83 Linköping, Sweden
2010-04-12 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-54797
ISBN — ISRN
LiTH-ISY-EX--10/4400--SE Serietitel och serienummer Title of series, numbering
ISSN —
Titel Title
En studie av effektiva sensor-I/O-gränssnitt och signalhämtningstekniker för elek-triska kontrollenheter
A study of efficient sensor I/O interface and signal acquisition techniques for elec-trical control units.
Författare Author
Michael Pettersson
Sammanfattning Abstract
Agricultural vehicles use electronic control units (ECUs) as control system. His-torically ECUs have only been equipped with a minimum of features. With the recent progress in electronics, which have made components faster, smaller and cheaper, the trend is now to integrate more advanced functionality into the ECUs. Agricultural vehicles are present all over the world and they have to operate under a wide variety of conditions. This put high requirements on the system and it is critical that a modern ECU can detect and locate errors. For an ECU to be able to operate on a world-wide market it is required to be flexible, expandable and robust. In addition to these requirements it is also wanted that an ECU have a long lifespan and a low cost.
In this thesis different problems that modern ECUs have to face are inves-tigated. Suggestions of how to solve these problems are also presented. There are two focuses in the thesis, 1) how ECUs can acquire information from its in-puts/outputs; and 2) the requirements of the ECU hardware.
This thesis does not aim to deliver a fully specified system description but rather to provide an overview of how an ECU can be designed and which problems that it has to face.
A selection of areas of ECU design which are investigated in this thesis are, 1) typical inputs/outputs; 2) analog-to-digital converters and their application; 3) how multiplexers can be used; 4) requirements of general purpose inputs/outputs (GPIO); 5) monitoring of a controller area network (CAN); 6) power-supply re-quirement and monitoring; 7) monitoring of the vehicle’s battery; 8) memory; 9) requirement of the microcontroller (MCU);
Nyckelord
Keywords ECU, Electrical control units, Agricultural vehicle, I/O interface, CAN, MCU, Multiplexers, ADC, Solenoids, Sensors, Motors
Abstract
Agricultural vehicles use electronic control units (ECUs) as control system. His-torically ECUs have only been equipped with a minimum of features. With the recent progress in electronics, which have made components faster, smaller and cheaper, the trend is now to integrate more advanced functionality into the ECUs. Agricultural vehicles are present all over the world and they have to operate under a wide variety of conditions. This put high requirements on the system and it is critical that a modern ECU can detect and locate errors. For an ECU to be able to operate on a world-wide market it is required to be flexible, expandable and robust. In addition to these requirements it is also wanted that an ECU have a long lifespan and a low cost.
In this thesis different problems that modern ECUs have to face are inves-tigated. Suggestions of how to solve these problems are also presented. There are two focuses in the thesis, 1) how ECUs can acquire information from its in-puts/outputs; and 2) the requirements of the ECU hardware.
This thesis does not aim to deliver a fully specified system description but rather to provide an overview of how an ECU can be designed and which problems that it has to face.
A selection of areas of ECU design which are investigated in this thesis are, 1) typical inputs/outputs; 2) analog-to-digital converters and their application; 3) how multiplexers can be used; 4) requirements of general purpose inputs/outputs (GPIO); 5) monitoring of a controller area network (CAN); 6) power-supply re-quirement and monitoring; 7) monitoring of the vehicle’s battery; 8) memory; 9) requirement of the microcontroller (MCU);
Acknowledgments
I would like to thank the following people who have been of great help when writing this thesis:
• My supervisor and examiner Atila Alvandpour for letting me do this thesis with his group at the department of electronic devices. I am grateful for the insightful advice and feedback that I have received during the work with this thesis.
• My contact person at the business partner of this thesis. Thank you for all your useful advices and technical help during this thesis, without you this thesis would not have been possible.
• Daniel Svärd for proof-reading my thesis and improving its readability.
Michael Pettersson, April 2010
Contents
1 Introduction 1
1.1 Purpose . . . 2
1.2 Method . . . 2
1.3 Anonymity . . . 2
1.4 Typical ECU Model . . . 3
1.4.1 ECU Requirements . . . 3
1.5 Limitations . . . 3
1.6 Structure of the Report . . . 4
2 Input/Output Overview 5 2.1 Solenoids . . . 6
2.1.1 Solenoid Driver . . . 7
2.1.2 Conclusion Solenoid Driver . . . 9
2.1.3 Solenoid Signal . . . 11
2.2 Sensors . . . 13
2.2.1 Sensor Power-Supply . . . 14
2.2.2 Conclusion Sensor Power-Supply . . . 14
2.2.3 Sensor Output Monitor . . . 16
2.2.4 Conclusion Sensor Monitor . . . 18
2.3 Motors . . . 19
2.3.1 Motor Driver . . . 19
2.3.2 Conclusion Motor Driver . . . 23
2.3.3 Motor Signal . . . 25
2.4 Input/Output Signal Summary . . . 28
3 System Research 29 3.1 ECU Overview . . . 30
3.1.1 MCU Overview . . . 30
3.2 Analog-to-Digital Converter (ADC) . . . 31
3.2.1 Requirements . . . 31
3.2.2 Survey of MCUs . . . 33
3.2.3 Conclusion Analog-to-Digital Converter . . . 34
3.3 Multiplexer . . . 34
3.3.1 Structures . . . 35
3.3.2 Requirements . . . 37
3.3.3 Survey of Multiplexers . . . 37
3.3.4 Multiplexer Delay . . . 38
3.3.5 Fastest Conversion Rate . . . 38
3.3.6 Conclusion Multiplexer . . . 39
3.4 General Purpose Input/Output (GPIO) . . . 39
3.4.1 Requirements . . . 40
3.4.2 Survey of MCU GPIO pins . . . 41
3.4.3 Flexibility Vs Hardware-Resources . . . 42
3.4.4 Chip Select Signal . . . 45
3.4.5 Conclusion General Purpose Input/Output . . . 45
3.5 Controller Area Network (CAN) . . . 45
3.5.1 CAN-Bus Description . . . 46
3.5.2 Survey of MCU CAN Controllers . . . 47
3.5.3 Requirements on Error Detection . . . 47
3.5.4 Short Circuit . . . 48
3.5.5 CAN-Line Interrupt . . . 49
3.5.6 Termination Resistors . . . 49
3.5.7 Incorrect Pulse-Width . . . 50
3.5.8 Slow Slope . . . 52
3.5.9 Problems with the CAN-Driver . . . 52
3.5.10 Conclusion Controller Area Network . . . 53
3.6 Power Supply . . . 53 3.6.1 Power-Supply Generator . . . 54 3.6.2 Low-Voltage Detection . . . 56 3.6.3 Power-Supply Monitor . . . 60 3.6.4 Conclusion Power-Supply . . . 63 3.7 Battery Health . . . 63 3.8 Environment . . . 65 3.8.1 Temperature . . . 65 3.8.2 Water . . . 66 3.8.3 Acceleration . . . 68 3.8.4 Conclusion Environment . . . 70 3.9 Memory . . . 71
3.9.1 Survey of MCU Memory . . . 71
3.9.2 External Memory . . . 72
3.10 Summary System Research . . . 74
3.11 MCU . . . 75 3.11.1 Requirements . . . 75 3.11.2 MCU Choice . . . 76 3.11.3 Conclusion MCU . . . 77 4 Summary 79 4.1 Future Work . . . 80 Bibliography 83
List of Tables
2.1 Solenoid driver PROFETs . . . 8
2.2 Solenoid driver ICs . . . 9
2.3 Solenoid driver pin requirement . . . 11
2.4 Solenoid I/Os . . . 11
2.5 Solenoid A/D signals speed-rates . . . 11
2.6 Sensor power-supply specification . . . 14
2.7 Sensor power-supply pin requirement . . . 15
2.8 Sensor power-supply I/Os . . . 16
2.9 Sensor power-supply A/D signals speed-rate . . . 16
2.10 Sensor monitor specification . . . 16
2.11 Sensor monitor pin requirement . . . 18
2.12 Sensor monitor I/Os . . . 19
2.13 Sensor-monitors’ A/D signal speed-rates . . . 19
2.14 Motor specification . . . 20
2.15 H-bridge requirement of switches . . . 21
2.16 Motor driver PROFETs . . . 23
2.17 Motor driver ICs . . . 23
2.18 Motor driver pin requirement . . . 24
2.19 Motor I/Os . . . 24
2.20 Motor A/D signals speed-rates . . . 25
2.21 Summary I/Os . . . 28
2.22 I/O ADC speed-rate . . . 28
3.1 Suitable MCUs . . . 31
3.2 A/D signals overview . . . 32
3.3 ADC subsystem requirements . . . 33
3.4 ADC overview . . . 33 3.5 ADC structure 1 . . . 36 3.6 ADC structure 2 . . . 36 3.7 ADC structure 3 . . . 37 3.8 Multiplexer overview . . . 38 3.9 GPIO requirement . . . 40 3.10 GPIO overview . . . 41
3.11 A/D signal requirements . . . 43
3.12 Multiplexer signal distribution . . . 44
3.13 Multiplexer pin requirements . . . 44
3.14 GPIO subsystem pin requirements . . . 46
3.15 MCUs’ CAN protocol support . . . 47
3.16 Can-bus short-circuit behavior . . . 48
3.17 MCUs’ support for external interrupt . . . 51
3.18 CAN subsystem pin requirements . . . 54
3.19 MCUs’ power-supply requirements . . . 55
3.20 Switched power-supply generator overview . . . 56
3.22 Low-voltage detection pin requirements . . . 60
3.23 Voltage drop required action . . . 61
3.24 Power-supply supervisor overview . . . 61
3.25 Power-supply monitor’s pin requirements . . . 62
3.26 Power-supply’s subpart conclusions . . . 63
3.27 Power subsystem’s pin requirements . . . 63
3.28 Battery health subsystem pin requirement . . . 64
3.29 Temperature survey . . . 66
3.30 Temperature pin requirements . . . 67
3.31 Water pin requirements . . . 68
3.32 Overview accelerometers . . . 69
3.33 MCU I2C support . . . . 69
3.34 Acceleration pin requirements . . . 70
3.35 Environment subsystem pin requirements . . . 70
3.36 MCUs’ internal memory overview . . . 71
3.37 Parallel interface overview . . . 72
3.38 Serial interface overview . . . 73
3.39 GPIO overview . . . 74
3.40 Memory pin requirements . . . 74
3.41 System requirements A/D signals . . . 75
3.42 System requirement GPIO signals . . . 75
3.43 System requirement summary . . . 76
3.44 MCU requirements . . . 76
3.45 Possible MCU choices . . . 77
List of Figures
1.1 Agricultural vehicles . . . 1
1.2 ECU example . . . 1
1.3 Typical ECU Model . . . 3
2.1 Input/Output overview . . . 5
2.2 Duplomatic solenoid . . . 6
2.3 Schematic solenoid driver . . . 8
2.4 Schematic solenoid driver . . . 10
2.5 Waveform of ”SafeTrack lock valve” . . . 12
2.6 Waveform ”SafeTrack proportional valve Duplomatic” free . . . 12
2.7 Waveform ”SafeTrack proportional valve Duplomatic” blocked . . . 13
2.8 Proximity sensor . . . 13
2.9 Schematic sensor power-supply . . . 15
2.10 Schematic sensor monitoring . . . 17
2.11 Schematic sensor monitoring . . . 18
2.12 Motor photo . . . 19
2.13 H-bridge example . . . 20
2.14 H-bridge with motors that share common stage . . . 22
2.15 Schematic motor driver . . . 22
2.16 Schematic motor driver . . . 24
2.17 Waveform motor rotating forwards . . . 25
2.18 Waveform motor rotating backwards . . . 26
2.19 Schematic differentiator . . . 27
2.20 How the differentiator works . . . 27
3.1 System overview . . . 30
3.2 A selection of MCUs . . . 30
3.3 ADC black-box . . . 32
3.4 Multiplexer approach to ease A/D pin requirement . . . 34
3.5 A/D conversion with and without multiplexers . . . 35
3.6 Multiplexer layer approaches . . . 36
3.7 GPIO black-box . . . 40
3.8 Multiplexers sharing control pins . . . 42
3.9 Detailed CAN bus . . . 46
3.10 CAN message . . . 48
3.11 Peak detectors . . . 49
3.12 CAN-line interrupt . . . 49
3.13 Detection of incorrect pulse-width . . . 51
3.14 Slow slope detector . . . 52
3.15 CAN-driver monitor . . . 53
3.16 Power-supply . . . 54
3.17 Low-voltage detection . . . 58
3.18 MCU’s low-voltage behavior . . . 59
3.20 Battery internal resistance . . . 64
3.21 Measure battery’s internal resistance . . . 64
3.22 Temperature measurement . . . 67
3.23 Water measurement . . . 68
3.24 Water-sensor placement . . . 68
4.1 System overview . . . 80
A.1 CAN-bus 4m cable with termination resistor mounted . . . 88
Acronyms
A/D Analog-to-Digital
ADC Analog-to-Digital Converter
CAN Controller-Area Network
CPU Central Processing Unit
EBI External Bus Interface
ECU Electrical Control Unit
FET Field-Effect Transistor
GPIO General-Purpose Input/Output
I/O Input/Output
I2C Inter-Integrated Circuit
IC Integrated Circuit
LVD Low Voltage Detection
MCU MicroController Unit
NTC Negative Temperature Coefficient
PCB Printed Circuit Board
POR Power-On Reset
PROFET PROtected FET
PTC Positive Temperature Coefficient
RAM Random Access Memory
RISC Reduced Instruction Set Computer
SMC Static Memory Controller
Chapter 1
Introduction
Figure 1.1. Two examples of agricultural vehicles. [1, 2]
This report is a part of my master thesis done at the department of electronic devices at Linköping University. The goal of this report is to investigate how an electrical control unit can be designed and to investigate potential problems that the electrical control unit has to be able to deal with.
An electrical control unit, or an ECU, is an embedded system that controls an electronic system or subsystem in a motor vehicle.
Figure 1.2. An example of an ECU used in the motor industry. [3]
Historically ECUs have only been equipped with a minimum of features. With the recent progress in electronics, which have made components faster, smaller and cheaper, the trend is now to integrate more advanced functionality into the ECUs. Modern ECUs should not only be able to control the electronic system, it should also be able to diagnose and locate errors. The ECU should then be able to present these errors to the user in an understandable way.
An ECU for agricultural vehicles has to be robust since it is used in harsh conditions. Normal problems that the ECU face are e.g. salt, water, chemicals and temperature shifts. It is critical that the ECU can detect when it is exposed to a condition that might affect its performance so the user can be informed and take countermeasures.
1.1
Purpose
The purpose of this report is to investigated problems that have to be faced when developing an electrical control unit.
The aim is not to give a fully specified ECU but rather to investigate potential problems and see which ones could be issues and, equally important, which ones will not be issues. The report will discuss pros and cons of different solutions to the investigated problems.
1.2
Method
The department of electronic devices at Linköping University and a business parter have decided to collaborate in these investigations. The business partner, with experience of development of ECUs for agricultural vehicles, provide information of what kind of problems a modern ECU has to be able to deal with.
This report investigates problems that are identified after discussions in the business collaboration. After potential problems are identified, solutions to these problems will be investigated. To make the results of this report easier to under-stand an ECU system is purposed during the investigations. The business partner has provided information of how a modern ECUs can look like (see section 1.4) and some errors that can occur in agricultural vehicles.
Much of the work will be done by surveys and investigations of datasheets and application notes.
One thing that has been noticed during this report is that there exist very few books that cover design of ECUs. Therefore the references list mostly consists of datasheets and application notes.
1.3
Anonymity
The business partner wants to be anonymous and therefore this report does not contain any information that can identify the business partner.
1.4
Typical ECU Model
The business partner has provided with an model of how a modern ECU can look like. This model will be used when problems, that the ECU has to face, are investigated and also when the requirements of the ECU are specified.
Sensors Solenoids Motors
Micro-controller
Interface
CAN-ECU
Memory
MCUs
Other
Figure 1.3. A model of how a typical ECU can look like. The different parts of this
model are explained in Chapter 2 and Chapter 3.
This model should only be seen as a overview. More parts, than the ones pre-sented in the figure, will be added and discussed later. This model’s only purpose is to provide a foundation from which this report can start its investigations.
1.4.1
ECU Requirements
The following properties are desired of an ECU:
1. Long lifespan. This is to avoid having too many products on the market simultaneously and to lower the development cost in the long run.
2. Extensive error detection. This is to make the agricultural vehicles more robust and also to decrease the maintenance cost.
3. Expandable. The ECU should have capacity for extra functions to be added in the future. This makes it possible to add new functionality without a redesign (e.g. change the MCU for one with higher performance) of the ECU.
4. General design. A general design makes it easy to change something in the system, e.g. sensor type (see Chapter 2).
5. Low cost.
1.5
Limitations
The following areas will not be considered in this report. These limitations have been chosen according to suggestions from the business partner of what are critical issues in ECU design.
1. The system’s power consumption.
2. The PCB area of the system.
3. The software implementation.
1.6
Structure of the Report
This report is divided into four chapters:
1. Introduction: Presents the goal, method and purpose of the report. A short introduction an ECU is also presented.
2. Input/Output Overview: The system’s I/Os are presented and the re-quirements of them are investigated.
3. System Research: The subparts of an ECU are discussed and different solution of how to use them are also presented.
4. Summary: A summary of the results of the report and suggested future work is presented.
Chapter 2
Input/Output Overview
An ECU is responsible to retrieve and interpret information from the Inputs/Outputs (I/Os). It is also responsible to provide I/Os with the correct power so that these devices can function properly.
The goal of this chapter is to investigated how an ECU can operate I/Os which are common in agricultural vehicles, and also how the ECU can detect if any problem with the I/Os occur. Another goal in this chapter is to see which requirements the handling of the I/Os inflicts on the ECU.
Our business partner has provided with a model of an ECU that has 10 motors, 10 sensors and 14 solenoids that will be used in the investigations in this chapter.
System
Solenoids
14
Sensors
10
Motors
10
Figure 2.1. An overview of the I/Os in the system.
In this chapter it is investigated how the ECU can operate these devices. All three types of I/Os have to have a driver in order to operate. In addition to these drivers, the I/Os also have to be equipped with monitor functionalities. The monitor functionality is needed to provide the ECU with diagnostic features which increase the system’s robustness.
Each type of I/O is investigated in a separate section. This chapter consists of four sections:
• Solenoids • Sensors • Motors
• Input/Output Signal Summary
In the first three sections, i.e. Solenoids, Sensors and Motors, solutions are proposed of how to use the I/Os. A solution usually consist of a recommended schematic or a recommended device. The signals of interest are presented in each schematic. Some of these signals need to be analog-to-digital converted before the ECU can read them. The signals, that need to be analog-to-digital converted, are classified into three categories according to which frequency they have to be sampled. These are:
• Slow : 10 Hz
• Intermediate : 100 Hz • Fast : 2 kHz
The categories are specified as a result of discussions with the business partner. In the fourth section information about the system’s signals found in the pre-vious three sections is summed up.
Schematics used in Chapter 2 are based on sketches provided by the business partner. When a schematic is presented it should not be considered to be any-thing other than an illustrative solution. This report will not make any deep investigation of these schematics to see if they can be improved or simplified. The schematics will only be investigated to see which requirements they inflict on the rest of the system.
The I/Os in this chapter are not all the I/Os that the ECU have to deal with. More I/Os are investigated in Chapter 3. This is done because no other I/O is known at this stage of the report.
2.1
Solenoids
A solenoid is a device that converts electric power into mechanical movement. An example of a solenoid is shown in Figure 2.2.
Figure 2.2. A solenoid from Duplomatic. Inside of this solenoid there is a valve for
A solenoid driver is the circuit/device used to provide the solenoid with power. The solenoid driver does not only have to drive the solenoid but it also needs to monitor its output signal to the solenoid. The monitoring is needed for the ECU to be able to locate problems with the solenoid, which is needed to make the system robust.
2.1.1
Solenoid Driver
A solenoid driver provides the solenoid with the correct power-supply. The require-ments of the solenoid driver are discussed in this section. After this discussion it is investigated how the system can reach these requirements.
To specify the requirements of the solenoid driver the requirements of an agri-cultural vehicles commonly used solenoid are needed to be investigated. The Du-plomatic 41150A solenoid is used for this purpose.
Requirements
The Duplomatic 41150A [17] has the following requirements:
• Current capability up to 2.72 A. • Runs at 12 V power-supply.
Two approaches on how the system can reach these requirements are investi-gated. These two approaches are:
• Circuit with PROFET • Integrated circuit
A PROFET is a transistor that is special designed to be used in high voltage and high current applications.
In order to detect a problem with the solenoid, the solenoid has to be monitored. Our business partner has suggested which signals that need to be monitored and at which sampling frequency the A/D signals have to be sampled. These are specified as following:
• Solenoid input : Slow-rated (10 Hz) • Feedback current : Fast-rated (2 kHz) Circuit with PROFET
The schematic in Figure 2.3 use a PROFET to drive the solenoid. As can be seen in the figure, the schematic contains a BTS5236 [19] device which is the driver circuit. The reason why this device is chosen as a driver is discussed in the conclusion of this section.
The schematic also contains two A/D signals (ADC_1 and ADC_2) and one GPIO (IN_1) signal. The IN_1 signal turns the BTS5236 device on and off.
V
BATSolenoid Input
ADC_1
ADC_2 (IS1)
IN_1
BTS5236
Figure 2.3. The figure illustrates how a solenoid driver circuit with the BTS5236 device
could look. The output voltage of the BTS5236 is monitored with an ADC. The BTS5236 has one output (IS1) for the feedback current from the solenoid. This output is connected to a resistor so that the value can be measured with an ADC. The reason why the feedback current has to be measured is discussed in section 2.1.3 (page 11).
The output of the driver is monitored with one A/D channel (ADC_1) while the feedback current from the solenoid is monitored by the other A/D channel (ADC_2).
To monitor the feedback current with an ADC, the resistor is needed to convert the feedback current into voltage. The reason why the feedback current has to be monitored is discussed in section 2.1.3 (page 11).
Survey of PROFETs
A survey has been done to see which PROFET devices are available on the market. The result of this survey is presented in Table 2.1.
Device Producer Price Note
BTS5236 Infineon $1.3 Dual channels high-side
driver. Two diagnostic pins.
MC10XS3412 [33] Freescale $4.5 Quad channels high-side
driver. 16-bit SPI for di-agnostic.
L6370D [34] STMicroelectronics $6.5 High-side driver
Table 2.1. A selection of PROFETs which fulfills the requirements to drive the system’s
solenoids.
The goal of the survey was to find devices that fulfill the requirements of the solenoid driver, and to give an estimation of how much they cost.
All the devices in Table 2.1 fulfill the requirements of the solenoid driver. All devices also have built-in protection against e.g. overload, overtemperature and short circuits.
Integrated Circuit
The second approach of how to construct the solenoid driver is to use an integrated circuit instead of a PROFET. This approach is investigated in this section.
First of all, what is the difference between a PROFET and an IC?
• PROFET : Works as a power switch. Has basic built-in protection against e.g. overload, overtemperature and short circuits. Does not have any built-in support for signal diagnostics.
• IC : Has one or several integrated power switches1. Has built-in protection
against e.g. overload, overtemperature and short circuits. Usually have a larger variety of functions than the PROFETs. Have intelligent built-in error detection which the IC usually communicates to the MCU over an SPI bus.
Survey of Integrated Circuits
In this section it is investigated which ICs on the market fulfill the requirements of the solenoid driver.
Device Producer Price Note
L9950 [36] STMicroelectronics $6 SPI for diagnostics
TLE8201 [18] Infineon $6 SPI for diagnostics.
Table 2.2. A selection of ICs that fulfill the requirements to drive the solenoids. The
approximate prices of the devices are also presented.
The result of the survey of ICs is presented in Table 2.2. The devices in the table offer built-in functions as undervoltage and overvoltage detection, short circuit protection etc. Both ICs in Table 2.2 communicate with the MCU over an SPI bus and will inform the MCU if any problem is detected.
2.1.2
Conclusion Solenoid Driver
In this section it has been investigated how to construct a solenoid driver. Two approaches have been investigated. The first approach uses a PROFET device as a driver while the second approach uses an IC as a driver.
The PROFET approach requires fewer pins to operate but it does not have any built-in support for error detection. If the PROFET approach is chosen as a solution extra pins are needed to monitor the device externally. As can be seen in Figure 2.4 (page 10), one A/D signal is needed to monitor the output to the solenoid and one A/D signal to monitor the feedback current from the solenoid.
The IC approach requires more pins to operate but it has built-in support for undervoltage and overvoltage detection. The ICs found in the survey do not have enough error detection for the ECU to rely on the IC’s error detection only. It is not enough for the system to have undervoltage and overvoltage detection. The
system must be able to monitor the output to the solenoid. The reason why this is the case is discussed in section 2.1.3 (page 11). Since none of the found ICs monitors the output voltage or the feedback current, two additional A/D signals are needed to monitor these signals. Note that these two additional A/D signals are needed in both the PROFET approach and in the IC approach.
Which approach is the best choice for the system? Since it is desired that the system should have a low cost, it is logical to choose the PROFET approach since it is the cheaper of the two approaches.
If the PROFET approach is chosen, I recommend using the BTS5236 since it offers a cost-effective solution and it fulfills the system’s requirements.
The ICs found in the survey contain many built-in functions but many of these functions are not required of the system. E.g. the L9950 offers 10 different drivers but only four of them fulfill the system’s requirements.
It is possible that the IC approach could be a better choice if an IC with more application-specific features could be found. This was however not the case in the survey and the IC approach is therefore not recommended.
Pin Requirements When Using the Recommended Solenoid Driver The schematic in Figure 2.4 is the recommended solution for solenoid driver.
V
BATSolenoid Input
ADC_1
ADC_2 (IS1)
IN_1
BTS5236
Figure 2.4. The figure illustrates how a solenoid driver with the BTS5236 device could
look. The output voltage of the BTS5236 is monitored with an ADC. The BTS5236 has one output (IS1) for the feedback current from the solenoid. This output is connected to a resistor so that the value can be measured with an ADC. The reason why the feedback current has to be measured is discussed in section 2.1.3 (page 11).
If this schematic is used as a solution and if requirements of sampling frequency must be fulfilled, the system has to be able to handle the signals in Table 2.3.
As mentioned in the beginning of this section, the system will have 14 solenoids and each solenoid will have one driver. The required number of pins needed is presented in Table 2.4.
According to Table 2.4 the solenoids in the system require 42 pins in total and 28 of these are ADC pins. As known from the classifications done in Table 2.3,
Signal name Type Speed rate Function
IN_1 GPIO - Activate BTS5236 driver
ADC_1 ADC Slow (S) Solenoid input
ADC_2 ADC Fast (F) Solenoid feedback current
Table 2.3. This table presents a summary of the MCU pin requirements of the solenoid
driver. This numbers are only valid when the BTS5236 is chosen as driver.
Type Amount
Number of solenoids 14
GPIO pins 14
A/D pins 28
Table 2.4. This table presents the required number of pins that the MCU needs to have
if the recommended solution is chosen.
each solenoid driver contains one fast-rated and one slow-rated A/D signal. This information about the A/D signals’ speed-rates is summarized in Table 2.5.
A/D speed-rate Amount
Slow 14
Intermediate 0
Fast 14
Table 2.5. This table presents the signals’ required sampling frequencies. This
infor-mation is summed up from Table 2.3 and Table 2.4.
2.1.3
Solenoid Signal
In this section it is investigated which type of information it is possible to get from the solenoids.
Two types of solenoids with different waveforms are investigated:
• SafeTrack proportional valve Duplomatic • SafeTrack lock valve
In order for the system to fulfill the requirement of robustness, the system has to be able to detect if the solenoids are operational or not. Can this be done and in that case what are the requirements on the system to do this?
Requirements
One way to monitor the solenoids is to analyze the current waveforms that the solenoids produce.
As can be seen in Figure 2.5, the ”SafeTrack lock valve” has a characteristic dip in their waveforms. This dip occurs as a result of movement of the valve inside
0 5 10 15 20 25 30 0 20 40 60 80 100 120 140 160 180 time (ms) Voltage (mV)
Figure 2.5. This figure shows the waveform of the ”SafeTrack lock valve”. It has a
characteristic dip which indicates that the valve inside of the solenoid has moved.
of the solenoid. If the valve inside of the solenoid is supposed to move but no dip is detected, the system must be able to signal that a faulty behavior has occurred. The ”SafeTrack proportional valve Duplomatic” has a different waveform, which can be seen in Figure 2.6. Instead of a dip when the valve moves, it has a slower slope. 0 10 20 30 40 50 60 70 0 20 40 60 80 100 120 140 160 time (ms) Voltage (mV)
Figure 2.6. Waveform of the ”SafeTrack proportional valve Duplomatic” when it is
moving freely. Compared with the waveform of when the solenoid is blocked (see Figure 2.7) this curve has a slower slope.
If the ”SafeTrack proportional valve Duplomatic” is blocked, the waveform will look as in Figure 2.7 and as can be seen this waveform is missing the slower slope that occurs when the valve inside of the solenoid moves (as in Figure 2.6).
0 10 20 30 40 50 60 70 0 20 40 60 80 100 120 140 160 time (ms) Voltage (mV)
Figure 2.7. Waveform of the ”SafeTrack proportional valve Duplomatic” when it is
blocked. As can be seen this curve has a faster increasing slope than when the valve inside of the solenoid is moving freely (as in Figure 2.6).
Both types of solenoids can be monitored with an ADC. When the signals are sampled, the dip-detection can be done in software.
2.2
Sensors
Figure 2.8. A proximity sensor from Omron. [28]
The system will consist of several types of sensors. All sensor circuits have to be equipped with:
• Power-supply • Monitor functions
Why a power-supply is needed is self-explanatory. The monitoring functionality is needed so that the system can read the sensor’s value.
2.2.1
Sensor Power-Supply
In this section the sensor power-supply is investigated.
Requirements
A selection of sensor types are presented in Table 2.6. These sensor types are regarded as the types that the system has to be able to use.
Sensor Producer Type Supply voltage
E2A [29] Omron Proximity sensor 12-24 V
424.00A [15] Elobau Angle sensor 10-30 V
424.06A [15] Elobau Angle sensor 4.5-5.5 V
Table 2.6. This table contains the specifications of a selection of the sensors. The
system needs to be able to use all these types of sensors.
A requirement is that the system must use a general design which in case of sensor power-supplies corresponds to that all power-supplies must be able to provide power to all types of sensors listed in Table 2.6. This is required so that the sensor type can be changed without redesigning the system.
How can the sensor power-supply be designed so it fulfills the requirements? Since the power-supply is only required to have basic power-supply features, it is logical to use a discrete circuit rather than a more advanced IC.
In discussions with the business partner it has been decided that it suitable to monitor a sensor’s power-supply with a sampling frequency of 10 Hz (that is slow-rated).
Discrete Circuit
One straightforward design that fulfills the system’s requirements is to use a dis-crete circuit. The schematic in Figure 2.9 can be used for this purpose.
The schematic contains a manual switch which position is set depending on the type of sensor it is supplying with power. If a sensor that requires 5 V power-supply is connected, the switch has to be in downwards position. If another sensor type is connected the switch has to be in upwards position. The schematic also has three A/D signals that are used to monitor the different voltages in the power-supply circuit.
One could argue that it would be enough with either ADC_1 and ADC_3 or only ADC_2. The reason why three A/D signals are in the schematic is to simplify pinpointing of potential errors and to provide redundancy.
2.2.2
Conclusion Sensor Power-Supply
In this section it has been investigated how to fulfill the requirements of the sensor power-supply. The power-supply is required to have a general design that can deliver power to different types of sensors presented in Table 2.6.
V
BAT
PTC Switch5 V
Output
ADC_1 ADC_2 ADC_3Figure 2.9. This figure shows an example of how the schematic of the sensor’s
power-supply could look. This schematic should only be considered as an example and its structure will not be explained in detail. The PTC device is explained later in section 3.8.1 (page 65).
It is recommended to use a discrete circuit to solve this problem. A discrete circuit fulfills the requirements of a general design and provides a low-cost solution.
Pin Requirements When Using the Recommended Sensor Power-Supply It is specified that the power-supply needs to be monitored with a 10 Hz sampling frequency. If the schematic in Figure 2.9 is used and if the requirement of sampling frequency is fulfilled, this requires the system to be able to handle the signals in Table 2.7.
Signal name Type Speed rate Note
ADC_1 ADC Slow (S) VBAT
ADC_2 ADC Slow (S) Output voltage
ADC_3 ADC Slow (S) 5 V battery
Table 2.7. This table presents the requirements on MCU pins if the schematic in Figure
2.9 is chosen as sensor power-supply.
As mentioned in the beginning of this section, 10 sensors will be used in the system. Each sensor requires one power-supply circuit and therefore the system is required to have no GPIO pin and 30 A/D pins as described in Table 2.8.
To sum up, 30 A/D pins are required for the sensor power-supply. According to Table 2.7 all these are slow-rated signals. This information is summed up in Table 2.9.
Type Amount Number of sensor power-supplies 10
GPIO pins 0
A/D pins 30
Table 2.8. This table presents the number of I/Os that the sensor power-supplies require
the system to have.
A/D speed-rate Amount
Slow 30
Intermediate 0
Fast 0
Table 2.9. This table presents the required sampling frequency of the A/D signals in
Table 2.8.
2.2.3
Sensor Output Monitor
To read the sensor’s value all sensor outputs have to be monitored. How this can be done is investigated in this section.
Requirements
As mentioned earlier, the system is required to have a general design, which in the case of sensors corresponds to that the system must be able to handle several types of sensors. A sensor monitor has to monitor the outputs of different sensor types.
A selection of different sensor types that the system has to be able to monitor is presented in Table 2.10.
Sensor Producer Type Output
E2A [29] Omron Proximity sensor Frequencies up to 2kHz
424.00A Elobau Angle sensor 1-5 V
424.01A [15] Elobau Angle sensor 4-20 mA
424.06A Elobau Angle sensor 0.5-4.5 V
Table 2.10. This table presents a selection of sensors that the system has to be able to
monitor. The table presents the requirements that the system must fulfill in order to be able to monitor the sensors.
The sensor monitor, as the sensor’s power-supply (see section 2.2.1 on page 14), is required to have a general design that allows the sensor type2 to be changed
without requiring to redesign the system.
It has been specified in the business collaboration that a sampling frequency of 100 Hz (that is intermediate-rated) is enough to monitor the sensors’ current outputs and voltage outputs.
How can the system reach these requirements? One direct approach is to use a discrete circuit.
Discrete Circuit
The schematic in Figure 2.10 could be used to monitor the sensor outputs.
TTL Sensor Output ADC_1 MCU Switch ADC_2
Figure 2.10. This figure shows a discrete circuit which is suggested as sensor monitor.
The lower part (below the switch) of the schematic is used for current output sensors. The upper part (above the switch) is used for voltage output sensors and also for frequency output sensors.
The schematic contains a switch which is set depending on which type of sensor is monitored. The functionality of the part below the switch is to handle current output sensors. The functionality of the part above the switch is to monitor voltage output and frequency output sensors.
It is possible to question if it would not be better to separate the schematics for frequency monitoring and voltage monitoring. It might seem like a waste of resources to have two pins (ADC_1 and MCU) connected to the output in the top part of the schematic, because the sensor will either have voltage output or frequency output. No sensor in Table 2.10 requires the system to monitor both frequency and voltage to read the sensor’s value. However to split the frequency monitoring and the voltage monitoring into two parts is not a good idea for the following reasons:
• Reduces the degree of general design • Takes away crucial error detection functions
The first point is easy to understand but the second point needs to be further explained. The reason why a separation of the schematic would take away crucial error detection is that, for example, the sensors with frequency output are required to have voltage monitoring capabilities since this is the only way to detect if the sensor is functional. How this works depends on the sensor. One example is a sensor that has an internal pull-up which pulls the signal up to VBAT if the sensor is broken. The only way to detect this is to monitor the sensor’s output voltage.
2.2.4
Conclusion Sensor Monitor
In this section it has been investigated how to monitor the sensor outputs. It is known that the system will have several different types of sensors. The system is required to be designed generally enough so that the sensor type can be changed without requiring a redesign of the system. To fulfill this requirement the schematic in Figure 2.11 is proposed as a solution.
TTL Sensor Output ADC_1 MCU Switch ADC_2
Figure 2.11. This figure shows a discrete circuit which is suggested as sensor monitor.
The lower part (below the switch) of the schematic is used for current output sensors. The upper part (above the switch) is used for voltage output sensors and also for frequency output sensors.
This schematic fulfills the system’s requirement of generality since it can mon-itor all required sensors. The schematic also fulfills the system’s requirement of low cost since it only uses cheap discrete components.
Pin Requirements When Using the Recommended Sensor Monitor If the schematic in Figure 2.11 is used as a solution, this requires the system’s MCU to have the pins listed in Table 2.11.
Signal name Type Speed rate Note
ADC_1 ADC Intermediate (I) Sensor output
ADC_2 ADC Intermediate (I) Sensor output
MCU GPIO - Output frequency
Table 2.11. This table presents which signals the MCU has to have if the schematic in
Figure 2.11 is chosen as sensor monitor.
As mentioned in the beginning of this section, 10 sensors will be used in the system. One monitor circuit will be connected to each sensor. As can be seen in Table 2.11 each monitor circuit requires two A/D signals and one GPIO signal. The required number of pins for all 10 sensor circuits can be seen in Table 2.12.
As can be seen in Table 2.12 the sensor monitor circuits require a total of 30 pins, of which 20 are A/D pins. According to the information in Table 2.11 all
A/D speed-rate Amount Number of sensor monitor circuits 10
GPIO pins 10
A/D pins 20
Table 2.12. This table presents the number of I/Os that the system has to handle to
use the proposed solution.
these 20 pins are of intermediate speed-rate.
A/D speed-rate Amount
Slow 0
Intermediate 20
Fast 0
Table 2.13. This table presents the required sampling frequencies of the A/D signals in
Table 2.12.
2.3
Motors
In the beginning of this section it has been specified that the system will have 10 motors. One type of motor that will be used in the system is shown in Figure 2.12.
Figure 2.12. A photo of the DME34 motor from Nidec servo that will be used in the
system. [4]
This section about motors is divided into two parts:
• Motor driver • Motor signal
2.3.1
Motor Driver
All motors require a driver in order to function. In this section the motor driver is investigated.
Requirements
Table 2.14 presents a selection of motors that the system has to be able to use.
Motor Producer Power-supply Current
DME34SA [13] Nidec servo 12 V 0.2 A
DME34BA [13] Nidec servo 12 V 0.65 A
Table 2.14. This table presents the types of motors that will be used in the system.
One requirement on the motors is that they must be able to rotate both for-wards and backfor-wards. A very popular circuit for driving motors is the h-bridge [12]. An h-bridge and its functionality are presented in Figure 2.13.
Figure 2.13. The area marked red in the figure presents an h-bridge. An h-bridge
provides functionality to rotate a motor both backwards and forwards. For forward rotation switches S1 and S4 are closed while S2 and S3 are opened. For backwards rotation switches S2 and S3 are closed while S1 and S4 are opened. [8]
Motors can be in three modes: • Rotating forwards
• Rotating backwards • Stopped
In a system with several motors it is possible that a group of motors always will be in the same mode. If this is the case it is possible to reduce the number for switches by letting some motors share common stage (i.e S1 and S2) in the h-bridge.
To make the system robust the motor driver is required to be monitored. Both the driver circuit’s output and the feedback current have to be monitored. The following specification of sampling frequencies has been decided after discussions with the business partner:
• Feedback current monitor: 2 kHz (fast-rated)
Two approaches on how to fulfill the requirements of the motor driver are investigated. These two approaches are:
• Circuit with PROFET • Integrated circuit Circuit with PROFET
It is known from the requirements of the motor driver, that motor drivers are required to be able to rotate motors both forwards and backwards. This feature can be provided with an h-bridge.
As discuss earlier it is possible that not all motors are required to have full independent control. If e.g. some motors always will be in the same mode it is possible to let these motors share common stage in an h-bridge. By doing this several switches can be saved as can be seen in Table 2.15.
Type Required switches
Independent h-bridge 4n
H-bridge with shared common stage 2+2n
Table 2.15. This table shows how many switches are required for an independent
h-bridge and for an h-h-bridge with common stage. The ”n” is the number of motors. Note that the numbers of required switches for the shared common stage are only valid when all motors are in the same h-bridge.
In Figure 2.14 it is illustrated how an h-bridge can look when two motors share common stage. One limit due to this structure is that all motors in the same block have to run in the same direction or not run at all.
The schematic shown in Figure 2.15 can be used to drive a motor. This schematic will then correspond to one h-bridge stage.
The schematic in Figure 2.14 is simplified in order to give an overview of the functionality of an h-bridge block. Figure 2.15 contain a more detailed schematic of circuit used to drive a motor. The dashed black line in the figure corresponds to one h-bridge stage in Figure 2.14. As can be seen in the figure this schematic, as the solenoid driver, uses the BTS5236 device as a driver. Why this device is chosen is discussed in the conclusion of the motor driver.
Survey of PROFETs
The devices found in the survey are shown in Table 2.16. During the survey it has been noticed that it is difficult to find a PROFET that is better than the BTS5236 that was found in the survey of solenoid drivers.
Integrated Circuit
Another approach to construct a motor driver is to use an integrated circuit. Are there ICs on the market that fulfill the requirements on the motor driver?
Motors
V
BATFigure 2.14. This figure illustrates how motors can share common stage in an h-bridge.
One limitation of this solution is that all motors in the same h-bridge block have to run in the same direction or not run at all. The common stage is marked with the dashed red line. Note that this figure is simplified and it does not provide the whole motor driver. A detailed schematic of the area marked with the dashed black line is shown in Figure 2.15.
V
BAT
BTS5236
IS1
Output
MCU
IN1
ADC_3
ADC_2
ADC_1
Figure 2.15. This figure illustrates how the motor driver could look if the PROFET
approach is used. The area marked by the dashed black line corresponds to the area marked by the dashed black line in Figure 2.14.
Survey of ICs
Device Producer Price Note
BTS5236 Infineon $1.3 Dual channels high-side
driver. Two diagnostic pins.
MC10XS3412 Freescale $4.5 Quad channels high-side
driver. 16-bit SPI for di-agnostic.
L6370D STMicroelectronics $6.5 High-side driver
Table 2.16. This table presents a selection of PROFETs that fulfills the requirements
to drive the system’s motors. Note that this is the same devices as were found in the survey of solenoid drivers (Table 2.1 on page 8).
Device Producer Price Note
L9950 STMicroelectronics $6 SPI for diagnostics
TLE8201 Infineon $6 SPI for diagnostics.
Table 2.17. This table presents a selection of ICs found in the survey. Note that the
found devices are the same as the ones found in the survey of the solenoid driver. See Table 2.2 (page 9) for more information.
Both ICs in Table 2.17 have built-in h-bridges. Both ICs also fulfill the re-quirements listed in Table 2.14 (page 20).
One big disadvantage of the ICs are the price. No cheaper ICs which fulfill the system’s requirements were found in this survey.
2.3.2
Conclusion Motor Driver
The motor driver has been investigated in this section. The requirements of the motor have been presented and also two approaches of how the system can fulfill these requirements. The first approach is a circuit with PROFET and the sec-ond approach uses ICs with built-in h-bridges. For information of the difference between PROFETs and ICs, please refer to the conclusion of the solenoid driver (Section 2.1.2 on page 9).
Both approaches fulfill the system’s requirements. My recommendation is to use the circuit with PROFETs which is illustrated in Figure 2.16. This approach is cheaper than the IC approach, which goes well along with the desired requirement of a low-cost system.
Pin Requirements When Using the Recommended Motor Driver If the recommended PROFET approach illustrated in Figure 2.16 is chosen, the system is required to be able to handle the signals presented in Table 2.18.
The hardware requirements of all 10 motor signals in the system can be seen in Table 2.19. The table shows that there are 10 motors in the system and it is known from Table 2.18 that each motor driver circuit has three A/D signals and
V
BAT
BTS5236
IS1
Output
MCU
IN1
ADC_3
ADC_2
ADC_1
Figure 2.16. This figure illustrates how the motor driver could look if the PROFET
approach is used. The area marked by the dashed black line corresponds to the area marked by the dashed black line in Figure 2.14.
Signal name Type Speed rate Note
ADC_1 ADC Slow (S) Output voltage
ADC_2 ADC Fast (F) High-side driver current
ADC_3 ADC Fast (F) Low-side driver current
MCU GPIO - Low-side motor driver
IN_1 GPIO - Activate BTS5236 driver
Table 2.18. This table presents which signals the system has to handle if the PROFET
approach is chosen as motor driver. The signals can all be seen in the schematic in Figure 2.16 (page 24). Note that this numbers exclude the GPIOs needed to control the common stage(s) in the h-bridge(s). Two GPIO pins per h-bridge are required.
two GPIO signals. The total pin requirement of the motors is presented in Table 2.19.
A/D speed-rate Amount
Number of motors 10
GPIO pins 20
A/D pins 30
Table 2.19. This table shows the required number of pins if the schematic in Figure
2.16 is chosen as motor driver.
According to Table 2.19 a total of 50 pins are required for the motor I/Os and 30 of these pins are ADC pins. Of these 30 ADC pins, 20 are fast-rated and 10
slow-rated. This information is summarized in Table 2.20.
A/D speed-rate Amount
Slow 10
Intermediate 0
Fast 20
Table 2.20. This table presents the required sampling frequency for the A/D signals in
Table 2.19.
2.3.3
Motor Signal
The motor signal is investigated in this section. The goal is to see what kind of information it is possible to get from the motor signals. It is also investigated which requirements the system has to fulfill in order to get the necessary information from the motors.
Motor Waveform
Figure 2.17 presents a waveform of when a motor is rotating forwards and Figure 2.18 presents a waveform of when a motor is rotating backwards. From Figure 2.16 (page 24) it is known that the motor outputs will be monitored. What kind of information will the system be able to monitor?
0 5 10 15 20 25 30 35 40 45 50 0 20 40 60 80 100 120 140 160 time (ms) Voltage (mV)
Figure 2.17. Waveform of when a motor rotating forwards.
First of all, it will be possible to determine if the motor is working properly by measuring the voltage. This because a broken motor is likely to have a voltage of
0 5 10 15 20 25 30 35 40 45 50 0 20 40 60 80 100 120 140 160 time (ms) Voltage (mV)
Figure 2.18. Waveform of when a motor is rotating backwards.
Our business partner has specified that it is possible to calculate traveled dis-tance3 if the system is able to count the number of waveform ripples. What are
the requirements that the system has to fulfill to be able to count the number of ripples?
Requirements
Measurements in Figure 2.17 and Figure 2.18 shows that the smallest ripple swing occurs when the motor is rotating forwards. This smallest ripple swing sets the toughest requirements on the system and it is therefore interesting to measure this swing to see what the requirement for the system is count the ripples.
Measurements of the waveform in Figure 2.17 gave the following waveform properties:
• Fastest ripple-frequency ≤ 500 Hz • Ripple peak voltage ≥ 2 mV
The measured maximum frequency of 500 Hz is no problem4 for the system to handle. The ripple swing of 2 mV can however be problematic to detect. One ripple has to be sampled several times in order to safely detect the swing (or at least a sufficiently accurate approximation of the swing). It is hard to say how small voltages the system has to be able to measure to accurately measure the swing. I assumed that the system has to be able to detect voltages that are at least four to five times smaller than 2 mV to be able to count ripples accurately. How small voltage differences can the system detect?
3In fact the traveled distance is then calculated indirectly by counting the number of motor turns.
Assume that one ripple has to be sampled five times and that off-the-shelf ADCs typically have an A/D resolution of 10 bit5. If it is assumed that ADCs measure a swing of 3.3 V, this means that the smallest voltage that the ADCs can detect is 3 mV (see equation 2.1). This is not even close to be enough to detect a 2 mV peak accurately.
3.3 210 =
3.3
1024 ≈ 3 mV (2.1)
If these assumptions are correct it is not possible to measure a 2 mV ripple swing directly with an ADC. If it is wanted that the system can measure this swing this issue has to be solved in another way.
One other approach of how to measure the swing is to use a differentiator (see Figure 2.19) to get the derivative of the voltage waveform.
V
inC
R
V
outFigure 2.19. This is a differentiator. This circuit makes it possible for the system to
measure the derivative of the input signal. In this way any resolution problem of the ADC will not be an issue since the output voltage can be scaled to a desired value (see Equation 2.4).
The differentiator circuit uses the capacitor’s properties to derivate the input signal. By using this circuit the system is not required to be able to measure small voltages to count the number of ripples in the motor waveform. An illustration of how the differentiator works can be seen in Figure 2.20.
Phase 1 2 3
(a) Output without differentiator
Phase 1 2 3
(b) Output with Differentiator
Figure 2.20. This figure illustrates how a differentiator works. The differentiator can
be used in the system to ease the requirement of ADC resolution. Note that the output with differentiator can be scale to a suitable range according to Equation 2.4.
According to Equation 2.4 it is possible to scale the output by changing the resistor’s size in the circuit. In this way it is possible to scale the output to a range where the ADC can detect the voltage level.
Capacitance current to voltage relationship: I = CdV dt (2.2) Ohm’s law: I = V R (2.3) 2.2, 2.3 ⇒ Vout= −RC dV dt (2.4)
2.4
Input/Output Signal Summary
In Table 2.21 below there is a summary of the I/O investigations done in this chapter. As can be seen in the table, the system is required to have a total of 152 pins (108 A/D pins and 44 GPIO pins).
Most modern MCUs have 8 to 40 A/D pins6. Based on this information it is clear that it needs to be investigated if it is possible to lower the required amount of ADC pins or if it can be solved in another way.
Type Amount
GPIO pins 44
ADC pins 108
Total number of pins 152
Table 2.21. A summary of the I/Os needed for the sensors, the solenoids and the motors.
Note that in addition to the GPIOs listed in this table, two GPIO pins per h-bridge are required.
It is also important to know the nature of all these 108 ADC pins. Therefore the information about the A/D signals’ speed-rates is summed up in Table 2.22.
Type Amount
Total number of ADC pins 108
A/D speed rate Amount
Slow 54
Intermediate 20
Fast 34
Table 2.22. Known from Table 2.21 is that the system will have at least 108 ADC
signals. In this table the required sampling frequencies of these signals are presented.
Chapter 3
System Research
In this chapter the requirements of an ECU are investigated. The previous chapter focused on the I/Os and this chapter will focus on internal parts of the ECU. Problems that the ECU has to face is also investigated. After the presented problems, it is examined how to solve these problems.
The problems are divided into sections according to which subsystem of the ECU they belong to.
As the report continues it will become clearer which subsystems have to be focused on more deeply than others. The depth were then decided after discussions with the business partner.
Each subsystem will, if suitable, be approached according to the following steps:
1. The subsystem will be regarded as a black-box. Inputs, outputs and the functionality of the black-box will be described.
2. Requirements of the black-box will be investigated.
3. Problems that need to be solved or investigated will be specified.
4. A survey will be done to see what kind of off-the-shelf devices are avail-able on the market. The performance and the cost of these devices will be investigated.
5. Solutions to the specified problems will be investigated. My recommended solution will be presented.
6. An overview of the subsystem’s requirements of MCU pins will be presented.
Each section of a subsystem will also contain a conclusion where the results of the investigations are presented.
3.1
ECU Overview
A black-box representation of the ECU is illustrated in Figure 3.1. The main subsystems can be seen in the figure (that is the MCU, the ADC and the sensor). Note that these subsystems themselves can contain more subsystems.
The figure also shows which external I/Os that is connected to the ECU. The MCU’s task is to control these I/Os so that the ECU work as intended. If anything in the ECU does not work as intended, it is crucial to detect the incorrect behavior.
Solenoids Sensors Motors
Multiplexers MCU CAN Interface Power-Supply Block System Battery Memory Block ADCs Temperature Sensors Acceleration Sensors Water Sensor Other MCUs I/Os ECU
Figure 3.1. An overview of the system. The illustration shows the ECU’s main
compo-nents and the system’s I/Os. Note that this figure only gives an overview of the system.
3.1.1
MCU Overview
(a) The LPC292x from NXP [5] (b) The MPC5567 from Freescale [6] (c) The STM32 from STMicroelectronics [7]Figure 3.2. A selection of MCUs that are possible choices as the MCU in the electrical
control unit.
that are suitable for an ECU. The list is presented in Table 3.1. The prices listed in the table should not be considered as exact numbers. They are only listed here for comparison purposes only.
MCU Producer Approximate price
MPC5534 [31] Freescale $15 MPC5554 [32] Freescale $35 MPC5567 [30] Freescale $40 LPC1768 [25] NXP $10 LPC2939 [26] NXP $15 STR912 [35] STMicroelectronics $15 STM32F103 [37] STMicroelectronics $10
Table 3.1. Suitable MCUs that can be used in an ECU. The table also lists the producer
of each MCU and the approximate market price of MCU.
Our business partner has informed that the MCUs in Table 3.1 are common choices within the agricultural industry. No other MCU, than the ones in the table, is investigated in this report.
3.2
Analog-to-Digital Converter (ADC)
The analog-to-digital converters are a crucial part of the system. This section aims to give a first (rough) estimate of the requirements of the A/D converters. This estimate will also give an idea of what kind of performance (speed, number of pins, resolution etc.) is possible to receive from the A/D converters.
It is likely that more requirements will be added after investigations in later sections but this first estimate is still necessary in order to decide where the focus should be in this report. As an example, if investigations later in this chapter show that requirements from Chapter 2 are too demanding for a straightforward solution, the focus will be to investigate whether it is possible to lower these requirements.
3.2.1
Requirements
What are the requirements on the ADC subsystem? As a start, the ADC subsys-tem will be considered to be a black-box as can be seen in Figure 3.3. Note that the ADC block in the figure could contain several A/D converters.
From section 2.4 (page 28) it is clear that the system has to have support for at least 108 ADC channels. Speed requirements of the slow-, intermediate- and fast-rated signals are also described in that section. This information is compiled in Table 3.2.
ADC Block 108 Solenoids Sensor Power-Supply Sensor Monitor Motors 28 30 20 30 I/O Block
Figure 3.3. A black-box illustration of the ADC subsystem. The figure shows the
number of A/D signals, from the I/O block, that are specified so far in this report. (see Chapter 2 for more information about these A/D signals.
Type Amount
Total number of A/D pins 108
A/D speed rate Amount
Slow 54
Intermediate 20
Fast 34
Table 3.2. This table shows the number of A/D signals that the system has to interact
with. The sampling-speed requirements of the signals are also shown in the table.
Speed Requirement
The slow-rated signals are required to be sampled with a speed of 10 Hz. This is equivalent to a sample period of 100,000 µs. According to Table 3.2, the system has 54 slow-rated signals. The system therefore has to sampled one slow-rated signal at least every 1850 µs in order to sample all slow-rated signals in the required sampling period of 100,000 µs.
The intermediate-rated signals are required to be sampled with a frequency of 100 Hz, which equivalent to that the intermediate-rated signals have a required maximum sampling period of 10,000 µs. The system has 20 intermediate-rated signals according to Table 3.2. Thus the system needs to sample one intermediate-rated signal at least every 500 µs.
The fast-rated signals are the ones setting the limit for the maximum sample period of the system. They are required to be sampled with a speed of at least 2 kHz. This is equal to a maximum sample period of maximum 500 µs.
To sum up, one slow-rated signal has to be sampled every 1850 µs and one intermediate-rated signals every 500 µs. According to Table 3.2 there are also 34 fast-rated signals in the system. All these have to be sampled in one sample period. Since the minimum requirements are of interest, I assume that 36 signals (34 fast-, one intermediate- and one slow-rated) signals have to be sampled within one sample period.
to be able to perform an A/D conversion in at least ≈ 13 µs. This is if the system has one ADC core. If more cores are available, the required conversion speed will be lower.
Pin Requirement
It is clear from Table 2.22 (page 28) that the system requires a minimum of 108 ADC pins. As mentioned before in this chapter, this only states a minimum requirement. It is likely that even more ADC pins will be required after investi-gations in later sections.
Resolution Requirement
The required ADC resolution is hard to specify since not all applications, where an ADC is needed, are investigated at this point. It is however clear that the higher resolution the better it is. As was shown in 2.3.3 (page 26) it is sometimes possible to design a custom solution which lowers the resolution requirement.
The ADC’s requirements are compiled in Table 3.3.
Type Amount
Total number of A/D pins 108
Minimum A/D conversion time 13 µs
Table 3.3. The requirements of the ADC subsystem. Note that these numbers are
based on the investigations up to this point. It is likely that the A/D pin requirement will change after coming investigations.
3.2.2
Survey of MCUs
The results of the survey of MCUs are presented in Table 3.4.
MCU ADC cores ADC pins Information
MPC5534 2 40 2.5 µs, 10 bit resolution MPC5554 2 40 2.5 µs, 10 bit resolution MPC5567 2 40 2.5 µs, 10 bit resolution LPC1768 1 8 1.0 µs, 12 bit resolution LPC2939 3 16 2.44 µs, 10 bit resolution STR912 1 8 0.7 µs, 10 bit resolution STM32F103 2 32 1.17 µs, 12 bit resolution
Table 3.4. An overview of the performance of the available MCUs (that is the MCUs
