Field Load Data Acquisition with regard to

Vibration, Shock and Climate including Self-heating of ECUs

Master Thesis

for

the fulfillment of the academic degree

M.Sc in Automotive Software Engineering

Faculty of Computer Science Professorship of Computer Engineering

December, 2014

Submitted by: Nakul Yadur Balagangadhar

Matr. Nr.: 306111

Supervisors: Prof. Dr. W. Hardt

Dr. Ariane Heller

Mr. Walter Gronbach (Robert Bosch GmbH)

i

Acknowledgement

This master thesis would not exist without the extensive support and encouragement of many people. I am very grateful to my mentors Prof. Dr. Wolfram Hardt and Dr. Ariane Heller who supported me throughout my master's degree. It is only with the guidance of Prof. Dr. Hardt, I have been able to successfully pursue by master thesis at Robert Bosch GmbH, Reutlingen under the department of Engineering Electronic Steering (AE/EES3). And, I am very thankful to Dr. Ariane Heller who guided me at every step of my thesis as this thesis was prepared in an industrial environment.

I would like to acknowledge and extend my heartfelt gratitude to my master thesis advisor, Mr. Walter Gronbach, for his constant guidance and support during my thesis work. I would also like to offer my sincere gratitude to my Manager and Head of the department Mr. Johannes Duerr for offering me a chance to identify myself within his team. I wish to acknowledge Robert Bosch GmbH for giving me an opportunity to pursue my master thesis at their Reutlingen facility and also for the financial and technical support provided to me during my thesis work.

I would like to thank all the members of the AE/EES3 department for their warm welcome and the great working environment they created.

Finally, I would like to thank my family, without their continuous support this work would not have been possible.

Thank you.

ii

iii

Abstract

The requirements of micro-electromechanical system (MEMS) technology sensors with respect to sensitivity, quality and environmental requirements are growing steadily. These systems need to be packaged in subsequent processing steps in order to protect them from environmental influences and to provide reliable operation. This package provides the interface between microscopic and macroscopic system application environment. Increasingly, the function and quality of MEMS technology sensors are influenced by the properties of the Assembly and connection technology and the packaging. Thus, the mechanical stress of MEMS during the packaging process and the influence of the packaging life are not negligible. For the reliability design of control devices in motor vehicles, the knowledge of stresses occurring in the field within the Product-service life is essential. In this study, using MEMS acceleration sensors in addition to environmental influences such as temperature, moisture and humidity, the mechanical stress and voltage used are evaluated. To ensure the robustness of the products and they are still easy, inexpensive and portable, they must be interpreted appropriately in the development process. The main aim of the Master Thesis was to develop a new hardware for doing measurements on the vehicle with the acceleration sensors, OBD and GPS. The design of the hardware was to be a small, low power consumption device with measurements of comparable accuracy to the existing measurement hardware. A digital interface for reading back the measurement phase and the measurement cell and if possible, measurements from multiple sensors.

iv

v

Contents 1. Introduction 1 1.1 Motivation 1 1.2 Aim of Master Thesis 1 1.3 Problem Statement 1

1.4 Type of Master Thesis 2 2. State of Art 4 2.1 Fundamentals of Strength of Materials 4 2.1.1 Fatigue Strength 4

2.2 Fundamentals of Signal processing 5 2.2.1 Root Mean Square 5

2.2.2 Maximum Value 5 2.2.3 Mean 5

2.2.4 Crest Factor 6 2.2.5 Discrete Fourier Transform 6

2.2.6 Window Function 6 2.2.7 Fast Fourier Transform 7 2.2.8 Acceleration Spectral Density 7

2.3 Rainflow Counting 9 2.4 On-Board Diagnostics 11

2.5 Standards within the framework of component design for Motor Vehicles 13 3. Concept 16 3.1 Measuring principles of acceleration sensors 16 3.1.1 MEMS Acceleration Sensors 16

3.1.2 Piezoelectric Sensor 18 3.1.3 Market Analysis of Acceleration Sensors 19

3.1.4 Selected Acceleration Sensor 20 3.2 Development platforms 21

3.2.1 Arduino Due 21 3.2.2 Raspberry Pi 22

3.2.3 STM32F4 Discovery 23 3.2.4 Baseboard for the STM32F4 Discovery 24 3.3 OBD-II Adapter 25

vi

3.3.1 ELV Diagnose Adapter 26

3.3.2 OBD-II to DB9 Adapter 26 3.3.3 OBD-II UART Adapter 27 4. Implementation 29 4.1 Software 29

4.1.1 Development Environment 30 4.1.2 Main Program 30

4.1.3 Interrupts 32 4.1.4 Hardware Libraries 34

4.1.5 Software Algorithms 37 4.1.6 Formats of the measurement 40

4.2 Parameter Conversion for OBD-II Data 42

4.2.1 Engine RPM 42

4.2.2 Speed 43

4.2.3 Intake Manifold Absolute Pressure 43

4.2.4 Barometric Pressure 43

4.2.5 Engine Oil Temperature 43

4.2.6 Calculated Engine Load Value 43

4.2.7 Engine Coolant Temperature 44

4.2.8 Intake Air Temperature 44

4.3 Fast Fourier Transform with Radix-4 algorithm 44 4.4 Hardware 45

4.4.1 Data Logger 45 4.4.1.1 Building Data Logger 46

4.4.1.2 RTC 50 4.4.1.3 GPS 51

4.4.1.4 OBD-II 52 4.4.1.5 Operating Data Logger 54

4.4.2 Developed Sensors 56 5. Evaluating the data from Data logger 60 5.1 Measuring points for long-term recording 60

5.2 Evaluation of the data with Matlab 61 5.2.1 Evaluation of EMC fi les 62

5.2.2 Evaluation of OBD files 69 5.2.3 Evaluation of RFM files 71

vii

5.2.4 Evaluation of RAW files 75

5.3 Comparison and evaluation of Measurements from two vehicles 75 6. Conclusion 84 References 85 Appendix 88

viii

List of Figures

Figure 2.1: Outline of Fatigue [2] 4 Figure 2.2: Rainflow Test Signal 10

Figure 2.3: Min – Max RFM representation 11 Figure 2.4: Average – Load cycle RFM representation 11

Figure 2.5: OBD-II pin out 12 Figure 3.1: Sensor X-Axis and Y-Axis 17

Figure 3.2: Sensor Z-Axis 17 Figure 3.3: Sensor system 18

Figure 3.4: Piezoelectric sensor principle 19 Figure 3.5 Arduino Due [1] 22 Figure 3.6: Raspberry Pi [22] 23

Figure 3.7: STM32F4 Discovery [23] 24 Figure 3.8: STM32F4DIS – BB [21] 24

Figure 3.9: STM32F4DIS – LCD [21] 25 Figure 3.10: ELV Diagnose Adapter 26

Figure 3.11: OBD-II to DB9 adapter [25] 27 Figure 3.12: OBD-II UART adapter [26] 27

Figure 4.1: Main program 31 Figure 4.2: Interrupt TIM10 32

Figure 4.3: Interrupt UART 6 33 Figure 4.4: Interrupt UART 1 34

Figure 4.5: Comparison of STM32F4 Radix-4 FFT with Matlab FFT 45 Figure 4.6: Schematic view of the Data logger 46

Figure 4.7: Data logger components 46 Figure 4.8: Side panel of the Data logger 48 Figure 4.9: LCD mount on the Data logger 48

Figure 4.10: Schematic circuit of the Data logger 49 Figure 4.11: STM32F4 Discovery with X1, C16 and C27 50

Figure 4.12: Battery on R26 pad 50 Figure 4.13: Shrink wrap over GPS module 52

Figure 4.14: GPS module with DB9 52 Figure 4.15: OBD-II UART adapter [26] 53

Figure 4.16: OBD port in the vehicle [26] 53

ix

Figure 4.17: OBD-II adapter plugged into the port [26] 54

Figure 4.18: Data logger front panel 55 Figure 4.19: Display of the Data logger 56

Figure 4.20: PCB for LIS3DH 57 Figure 4.21: Schematic circuit of the sensor 57

Figure 4.22: PCB for LIS3DH 58 Figure 4.23: Developed sensor 58

Figure 4.24: Sensor orientation 58 Figure 5.1: Sensor mount on Honda City 60

Figure 5.2: Sensor mount on Golf Steering 61 Figure 5.3: Sensor mount on Golf wheel 61

Figure 5.4: Relative RMS value of the acceleration 62 Figure 5.5: Relative maximum acceleration 63

Figure 5.6: Mean values of acceleration 63 Figure 5.7: Analog voltages 64 Figure 5.8: Overview of the trip [34] 65

Figure 5.9: RMS over GPS 65 Figure 5.10: Maximum value over GPS 66

Figure 5.11: Mean value of X-Axis over GPS 67 Figure 5.12: Mean value of Y-Axis over GPS 67

Figure 5.13: Mean value of Z-Axis over GPS 68 Figure 5.14: Crest factor over GPS 68

Figure 5.15: RPM over GPS 69 Figure 5.16: Speed over GPS 70

Figure 5.17: Absolute load over GPS 70 Figure 5.18: Rainflow matrix in Min-Max form 71

Figure 5.19: Rainflow matrix in logarithmic Min-Max form 72 Figure 5.20: Rainflow matrix in 3D logarithmic Min-Max form 72

Figure 5.21: Rainflow matrix in logarithmic Average-Load cycle form 73 Figure 5.22: Rainflow matrix in 3D logarithmic Average-Load cycle form 73 Figure 5.23: Frequency distribution of Y Axis 74

Figure 5.24: Cumulative load cycle of X Axis 74 Figure 5.25: Overview of the trip with Golf 75

Figure 5.26: Overview of the trip with Honda 76 Figure 5.27: RMS over GPS with Golf 76

x

Figure 5.28: RMS over GPS with Honda 77

Figure 5.29: Rainflow matrix in longitudinal direction with Honda 78 Figure 5.30: Rainflow matrix in longitudinal direction with Golf 78

Figure 5.31: Rainflow matrix in direction of travel with Honda 79 Figure 5.32: Rainflow matrix in direction of travel with Golf 79

Figure 5.33: Rainflow matrix in vertical axis with Honda 80 Figure 5.34: Rainflow matrix in vertical axis with Golf 80

Figure 5.35: Cumulative load cycle for Honda 81 Figure 5.36: Cumulative load cycle for Golf 81

xi

List of Tables

1. Table 2.1: OBD-II Terminal Standard assignment 12 2. Table 2.2: Lifetime requirement [20] 13

3. Table 2.3: Test parameters, broadband noise for sprung masses [20] 13 4. Table 2.4: Test parameter according to IEC600068-2-64[7] 14

5. Table 3.1: Available sensors 20 6. Table 3.2: Overview of development platforms 21

7. Table 4.1: Libraries and Algorithms 29 8. Table 4.2: Configuration for TIM10 35

9. Table 4.3: SPI Configuration 36 10. Table 4.4: UART Configuration 37 11. Table 4.5: OBD data and PIDs 39

12. Table 4.6: Format of EMCxxxx.txt fi les 40 13. Table 4.7: Format of OBDxxxx.txt files 41

14. Table 4.8: Format of RFMxxxx.txt files 41 15. Table 4.9: Format of RAWxxxx.txt files 42

16. Table 4.10: GPRMC data format 51 17. Table 4.11: Pin out and color coding of the sensor 58

18. Table 5.1: Mounting location of the sensor 61 19. Table 5.2: Average RMS acceleration of the trips 77

1

1. Introduction

This chapter aims at giving a clear understanding of the evolution of the master thesis with the topic, “Field load data acquisition with regard to Vibration, Shock and Climate including self heating of ECUs”. It also describes the aim of this master thesis and the problem that is being addressed in this work. The organizing of the complete master thesis is also described.

1.1. Motivation

For the reliability design of Engine Control Unit devices in motor vehicles, the knowledge of stresses occurring in the field within the product service life is essential.

In addition to the environmental influences such as temperature, moisture and humidity, vibration and shock issues are in focus. To ensure the robustness of the products and they are still easily and inexpensively made, they must be interpreted appropriately in the development process. For this, the load spectra for the mechanical influences of road conditions and operating conditions are to be determined.

The essential everyday situations (commuters, taxi, farmer,...) should be considered. This can be achieved by examining a large number of vehicles over a period of time.

1.2. Aim Of Master Thesis

This master thesis gives an overview of the data logger which is used for the measurement of the vibration data from the acceleration sensor mo unted on the electric steering of the vehicle, position data from the GPS module and the real-time condition of the vehicle through the OBD data.

The acceleration sensor is mounted on the test vehicle for the recoding of the vibration data during the running of the vehicle. In order to acquire the self-heating of the ECUs in the vehicle, the OBD-II port is implemented for the communication. With that, the real-time measurements from the vehicle on the CAN bus can be measured.

Finally, the Matlab tool is created in order to analyze the all the data collected on the logger.

1.3. Problem Statement

The measurement technology is already available on the market but this is only possible to a limited extent because their size limits the use of vehicles. The cost of

2

the sensor channel is approximately 1000€ which would greatly reduce the number of vehicles.

Each person has a different way of driving. Two different persons driving the same car in the same route will have different impact on the car. It is all dependent on the way they drive the car. The difference may be small over a shorter route but consider the same short route taken over a long period of time. The difference can be huge especially in the present situation where the roads are uneven. So, the idea is to come up with something that would help in deriving the synthetic profile of the driver which can be done with the OBD data.

Part of this master thesis is the realization of the simple data acquisition unit for autonomous long-term monitoring.

x Use low-cost and readily available components (STM32F4-Discovery) x Autonomy, automatic recording while driving x Determine the driving situation (GPS) x Derive the synthetic profile of the driver (OBD-II) x Low energy consumption x Data reduction x Storage on USB x Display the status (STM32F4DIS-LCD) x 3 measuring points with 3D tracking (9 channels)

The selection of the measuring points for the long-term investigation is done for an electric power steering. These are done based on the reference trips with a calibrated measuring system (Cronos) and advanced sensor count.

With a Matlab routine, the collected data should be combined into collectives. This field data should be evaluated according to the DIN-ISO 16750 with respect to the mounted location.

1.4. Type of Master Thesis

This document is divided into several chapters, which handle different topics. Chapter 1 introduces the topic and requirement of this task. Chapter 2 discusses the backgrounds of signal processing and algorithms used throughout the course of this work. This is followed by Chapter 3 which is about the concept of the development tools used and their comparisons. Chapter 4 introduces the implementation procedure of building the data logger and the software developed to run the data logger. Chapter 5 contains the evaluation of the data from the data logger and comparison of the data from two vehicles.

3

4

2. State of the Art

2.1. Fundamentals of strength of materials

The strength of the materials serves as a basis for the design of the mechanical and electronic components in the vehicle. The majority of the components used in the motor vehicle are subject to the dynamic load. This means that the load of the components is not only static but also time-dependant. For the components used in such conditions, it is important to know the exact load, since it may lead to the costly over-sizing or under-sizing, fatigue and failure of the component.

This master thesis deals with the impact of the vibrations and thereby the resulting problems. This is referred in the literature as the fatigue strength. It is a static stress which will include a dynamic content in the form of vibrations. [4][6][9]

2.1.1. Fatigue Strength

The Fatigue strength can be classified into Low-cycle fatigue and High-cycle fatigue. The range of operating strength is particularly important in this work. The relationship is shown in the Figure 2.1 for clarity. The load-time functions are presented on the upper part of the figure and below are the amplitude spectra and SN lines with relevant areas of failure. [2] [10]

Figure 2.1: Outline of Fatigue [2]

5

The low cycle fatigue is in the range of load cycles. Within this range, the material changes to high, plastic deformation, this results in a rapid failure of the component. This is clearly visible, because it exceeds the SN curve relatively quickly on the basis of the amplitude collectives. For this reason an interpretation of the low cycle fatigues is not recommended. [2]

The high cycle fatigue is in the range of load cycles. The stress amplitude is above the fatigue strength amplitude. Thus, the collective amplitude is high enough to exceed the SN curve to go beyond the failure but only after a high number of cycles. [2]

2.2. Fundamentals of Signal processing

2.2.1. Root Mean Square

The Root Mean Square (RMS) value of a changing acceleration f (t) is equivalent to a static load of the acceleration A, therefore as in 2.1. The RMS is also known as a quadratic mean. [11]

(2.1)

2.2.2. Maximum Value

The maximum value Amax is the absolute largest value occurring in a finite range of values of A[n]. The relation is represented in the equation 2.2. [11]

(2.2)

2.2.3. Mean

The arithmetic mean of the acceleration is the mean value of a finite amount of acceleration. It is referred as and calculated as in the equation 2.3. [11]

(2.3)

6

2.2.4. Crest Factor

The crest factor ks is the ratio of the maximum value Amax to the RMS value A and hence it is always ≥1. This relation is represented in the equation 2.4. [11]

(2.4)

2.2.5. Discrete Fourier transform

The Discrete Fourier transform (DFT) represents a finite, discrete time signal which will continue periodically, on a discrete, periodic frequency spectrum. The representation of the frequency spectrum is also known as image area. The Discrete Fourier transform has a great significance in signal processing, so it is used for the determination of the frequency occurring in the sample signal and their amplitudes as well as phases. It is also used for the implementation of the digital filter wi th large filter length. The calculation of the spectrum for N spectral values for is as given in the equation 2.5. [12] [13] [14]

(2.5)

2.2.6. Window Function

With the DFT, since the continuous signal is processed in the blocks of size N, it can lead to the so called Spectral leakage. The leakage describes the problem, if the block length is not a multiple of the period of a signal contained in it. As a result, the calculated frequency spectrum is too wide. The reason is that the Fourier transform performs a convolution in the frequency domain. [14]

This may be reduced by an appropriate window function, but cannot be avoided. Some of the known Window functions are:

x Rectangular window x Blackman window x Blackman-Harris window x von Hann window x Bartlett window x Hamming window x Kaiser window x Gaussian window x Lanczos window x Tukey window

7

In this work, the Hamming window is selected for all further calculations. It reduces the leakage effect at a reasonable loss of frequency resolution. The window of length N for given in the equation 2.6. [14]

(2.6)

Except in the case of the Fourier transform, window functions are used in the filter design and beamforming.

2.2.7. Fast Fourier transform

The Fast Fourier transform (FFT) is an algorithm to compute the DFT, which is executable with minimum computational cost on a microcontroller. There are a number of such faster algorithms. Like for example the Winograd FFT algorithm or the prime-factor FFT algorithm. In the following, the radix-2 algorithm by Cooley-Tukey is described in detail because it is the basis for the radix-4 algorithm provided by ST [23] as ready library. With the DFT, to transform N values to (2.5), N2 complex multiplications and additions are required. But with the FFT, if N is the power of 2, then only operations are required. This saves at N = 1024 about 99% of operations. Should that have a length to be transposed, which is not a power of 2; this can always be achieved by padding zeros. The efficiency of the FFT is that the periodicities and symmetries that are included in the magnitude of the complex operations, be utilized in the evaluation of the formula (2.5). In order to implement this, according to the principle “Divide and Conquer”, the signal is split into half subsequently until only sequence of two are available. It is characterized into two methods: the reduction in time domain (decimation in time – DIT) and the reduction in the frequency domain (decimation in frequency – DFT). [14]

Through this recursive execution of the algorithm, FFT needs more memory than with the DFT, furthermore, the entire FFT algorithm must be run throughout, however, the value of a frequency can be determined with the DFT. [12][13][14]

2.2.8. Acceleration Spectral Density

With the help of the DFT, the deterministic discrete time signal or the series can be transformed in the frequency domain. Correspondingly, it is possible to get the autocorrelation function consequences of a stationary, discrete random process, such as stochastic vibration, with the help of the DFT in the freque ncy domain. In this work, it is all about the measured acceleration and hence it is referred as Acceleration Spectral Density instead of Spectral Density. In the literature it is also

8

referred as Power Spectral Density (PSD). The PSD is as given in the equation 2.7. [15][16]

(2.7)

The theorem Wiener-Khintchine is known as the relationship between acceleration density and autocorrelation function on the FT. Since the autocorrelation function is conjugated, the acceleration density follows after the definition 2.7. So the acceleration density is given by the equation 2.8. [15][16]

(2.8)

Thus, the acceleration density is a purely real function. Therefore no information on the phases of the random process is obtained from the acceleration density. This is in acceleration density but also not necessarily. For real functions with the symmetry property (2.9) holds for the acceleration density as in (2.10). [15][16]

(2.9)

(2.10)

The definition of the acceleration density results in the ability to calculate the overall performance of the acceleration in the spectral range with the relationship given in the equation 2.11. [15][16]

(2.11)

The integral (2.12) then leads to the relationship (2.13) for the overall performance of the acceleration density. [15][16]

9

(2.12)

(2.13)

2.3. Rainflow Counting

The rainflow counting was published in 1968 by Matsuishi and Endo in Japanese [17]. The method is now also known by the name pagoda roof and rain-flow counting method. In 1972, this method first appeared in an English magazine [5]. Meanwhile, there are numerous publications with different RFM algorithms have appeared. These have resulted primarily to a substantial simplification [17].

The rainflow counting is a two-parametric counting method, in which extremes not sequentially numbered, but each closed hysteresis loops are recorded. The closed hystereses are then entered in matrices. There are a variety of possibilities for entering which can also be converted into each other. The amplitude and the average of the vibration measurements are presented within the framework of this work. Special attention should be paid to the non-closed hysteresis. These are called residuals. Storing open residuals is necessary particularly for rea l-time processing, since usually a limited number of measurement values in the memory are evaluated. Then, the open residuals are given for subsequent measurement as an initial condition for the Rainflow counting.

The counting algorithm is inspired by the shape of the rain flowing. The “Test Signal” is shown in the Figure (). The signal is turned 90° on the time axis in the clockwise direction. Now the rain falls from above on the flanks. This flows over the edge of one roof to the next. This is shown in the picture with the green and red lines. The counting of closed hysteresis is then given by the following scheme:

The rain falls from reversal points (left and right at the turning point) to the bottom, for example from [1 2] leading straight to [6 4] – [7 1] or from [2 4] leading straight to [3 3] – [4 5]. A hysteresis is considered closed when it reaches its starting point, or exceeds it. This happens in for example.1 [8 8] or in example.2 [7 1]. Thus, an entry is stored in RFM as shown in the Figure 2.3 for the example.1 [1 8] and for example.2 [2 5]. Only the closed hysteresis is stored. In Figure 2.2, these are marked in green with a horizontal line at the end. The residuals are shown in green with an arrow at the end. A hysteresis is not counted when the water reaches the impact point of the water that falls from a higher turning point. These cases are shown in Figure 2.2 with red color.

The representation of the RFM in the "MIN to MAX" form may be converted into the "Average Load-cycle" form as follows. The average value is calculated according to

10

the equation 2.14 and the Load-cycle by the equation 2.15, where the average is rounded for better representation.

(2.14)

(2.15)

Figure 2.2: Rainflow Test Signal

The RFM in the "Min to Max" form shown in the Figure 2.3 is obtained considering the equations 2.14 and the RFM in the “Average Load-cycle” is obtained considering 2.15, which is as shown in the Figure 2.4. The advantage of this representation is the column-wise reading of the load-cycles. The “Min to Max” representation is suitable for entering directly as the data in the algorithm exists as minimum and maximum values.

11

Figure 2.3: Min – Max RFM representation

Figure 2.4: Average – Load cycle RFM representation

The algorithm presented above is called as three-point algorithm. This will examine the three consecutive extreme values with respect to the formation of closed hysteresis. If the formation of closed hysteresis undergoes four consecutive extreme values, it is called a four-point algorithm. Four-point algorithms are more preferable than the three-point algorithms, but it can occur in the context of real time processing and the resources on the run-time system to select the three-point algorithm.

2.4. On-Board Diagnostics

On-Board Diagnostics (OBD) is the technology used for monitoring the vehicle performance. It helps in detecting the problems and providing the information about the malfunctions so that they can be monitored. [18]

The first OBD was introduced in the year 1980 which helped in monitoring the fuel, ignition and emission system. These system were called as OBD-I system. In these

12

system, a “check engine light” was implemented which illustrated the fault in the engine when it encountered a fault code. The OBD-I was not standardized and wide variety of interfaces were needed to connect to the OBD system on the vehicles.

The diagnostic version used in this work is the OBD-II which was introduced in 1994. Unlike OBD-I, OBD-II was designed to detect electrical, chemical and mechanical failures in the vehicles. The OBD-II was standardized and a standard protocol was used for communicating with the diagnostic equipment and the link connector. The standard link connector contains 16 terminals with some OBD-II dedicated and some manufacturer discretionary.

The 16-terminal standard link connector is as shown in the Figure 2.5 with the details of the terminals in the Table 2.1

Figure 2.5: OBD-II pin out

The terminals used in this work are terminal-6 and terminal-14. The terminal-6 is CAN-High based on the ISO 15765-4 and SAE J2284, and the terminal-14 is CAN-Low based on the ISO 15765-4 and the SAE J2284. The OBD port is usually located just under the dashboard above the break or gas pedal. [19]

Terminal 1 Manufacturer discretion Terminal 2 Bus positive line of SAE J1850 Terminal 3 Manufacturer discretion Terminal 4 Chassis ground Terminal 5 Signal ground Terminal 6 CAN-High (ISO 15765-4 and SAE J2284) Terminal 7 K-Line Terminal 8 Manufacturer discretion Terminal 9 Manufacturer discretion Terminal 10 Bus negative line of SAE J1850 Terminal 11 Manufacturer discretion Terminal 12 Manufacturer discretion Terminal 13 Manufacturer discretion Terminal 14 CAN-Low (ISO 15765-4 and SAE J2284) Terminal 15 L-Line Terminal 16 Battery Voltage

Table 2.1: OBD-II Terminal Standard assignment

13

2.5. Standards in context of component design for motor vehicles

Standards, in terms of the development of engine control units, are used to define requirements, test conditions and testing of electrical, electronic and mechatronic components and systems, including motor vehicles. In components the specifications deviating from a norm requirements, test conditions and tests are to be defined. Component specifications are different from the standard requirements, the tests and test conditions are to be defined.

One of these standards is the LV124 [20]. This is an OEM standard, which is published by the OEMs. This requirement is the typical lifetime for a vehicle, with the values described in Table 2.2 as specified.

Lifetime 15 Years Hours of Operation 8000 h Mileage 300000 km

Table 2.2: Lifetime requirement [20]

Another is in the standard under “M-04 Vibration Test”, an implementation of the test according to DIN EN 60068-2-64 set for band-shaped vibration excitation.

One of these tests is the "Vibration profile”, which describes the mounting parts on the “Automotive body part (for components built on sprung mass)”. The corresponding test parameters are given in Table 2.3.

Vibration excitation Broadband noise Test duration for each spatial axis 8 h RMS value of the acceleration 30.8 m/s2

Vibration Profile

Frequency [Hz]

Power spectral density [(m/s2)2/Hz]

5 0.884 10 20 55 6.5

180 0.25 300 0.25 360 0.14 1000 0.14 2000 0.14

Table 2.3: Test parameters, broadband noise for sprung masses [20]

The purpose is defined by LV 124 [20] as follows:

“These tests simulate the vibration stress of the component in operation. They are used to safeguard the stability of the component with respect to error patterns such as component separation and material fatigue.”

14

The DIN EN 600068-2-64 is the German takeover of IEC 600068-2-64. This is the second part of the environmental assessment with regards to vibration and wide band noise (digitally controlled).

This standard specifies the parameters for tests at the installation body, given in Table 2.4 [7].

Vibration excitation Broadband noise Test duration for each spatial axis 8 h RMS value of the acceleration 33.8 m/s2

Vibration Profile

Frequency [Hz]

Power spectral density [(m/s2)2/Hz]

10 10 50 10

1000 0.1

Table 2.4: Test parameter according to IEC600068-2-64[7]

15

16

3. Concept

This chapter gives a detailed description of the literature survey conducted for the solution of the master thesis. It aims at giving a detailed overview of all the possible solutions which are present in the market for the implementation of MEMS acceleration sensors. A comparison is made to choose the best suitable sensor for this work. Finally, it tries to conclude with a possible solution which would be used for the implementation.

3.1. Measuring principles of Acceleration Sensors

An acceleration sensor measures acceleration. This is done mostly by the detection of the inertial force on a test mass. It is important to distinguish whether a change in acceleration or the absolute acceleration is measured. For this reason, the two most common sensor principles are presented below. These are MEMS and piezoelectric sensors. Furthermore, there are also sensors based on strain gauges, magnetic induction (microphone) and Eddy-currents. But these are not part of this work.

3.1.1. MEMS Acceleration Sensors

A MEMS acceleration sensor operates on the principle of inertia. Hence, the seismic mass is mounted over the suspension on the substrate. The force act on this mass according to the given equation 3.1 then moves the green comb structure in the Figure 3.1 to the right. Thereby the distance between the fixed part of the Electrode 1 and the movable part of the central Electrode is smaller. According to 3.2, is therefore larger.

The distance is larger between the Electrode 2 and the central electrode for the same force thus is smaller for 3.2.

The capacitances and are converted to an electric signal by an AC bridge which can be digitized in the ASIC sensors and acquired as the acceleration values through the SPI.

This micromechanical structure is for the X-axis and is rotated 90° for the Y-axis used for measuring acceleration. For measuring the acceleration in the Z-axis, the structure shown in the Figure 3.2 is used. With this structure, no comb structure is used, but the capacitance between the seismic mass of the central Electrode and the Electrode 1 is evaluated. Acting on the mass the force according to the equation 3.1, then moves the green plate, which is mounted on the suspension on the substrate, upwards. Due to the increase in the distance the capacitance is smaller according to the equation 3.2.

The capacitance is converted to an electric signal by an AC bridge which is digitized in the ASIC sensors and acquired as the acceleration values through the SPI.

17

(3.1)

(3.2)

Figure 3.1: Sensor X-Axis and Y-Axis

Figure 3.2: Sensor Z-Axis

18

By combining the two types of micro-mechanical structure it is possible to form 3 axis acceleration sensors on a substrate. This is referred to as the 3D acceleration sensors.

The interplay of the individual sensor components and the system ASICs is referred to as sensor system and is shown in Figure 3.3. The individual measured values of the axes are successively passed through the multiplexer to the charge amplifier and then digitized in the ADC. The digitized values are then available via the SPI or I2C-bus. The sensor can also be configured using these interfaces.

Figure 3.3: Sensor system

3.1.2. Piezoelectric Sensors

A piezoelectric sensor works on the principle of inertia. As shown in Figure 3.4, a piezoelectric crystal is mounted between a seismic mass and the fixed structure. A force acts on the seismic mass as a result from acceleration according to the equation 3.1. It also affects the piezoelectric crystal resulting in a potential difference from the left to the right side of the piezoelectric crystal. The resulting voltage is amplified by a preamplifier integrated in the sensor and can be evaluated.

19

Figure 3.4: Piezoelectric sensor principle

Unlike MEMS acceleration sensors which measure the absolute acceleration, only relative accelerations are measured by piezoelectric accelerometers. This means that MEMS acceleration sensors measure the static gravitational acceleration of 1 , however, piezoelectric acceleration sensors only changes in acceleration approximately above 2 Hz.

3.1.3. Market Analysis of Acceleration Sensors

Since there are a variety of sensors available for the measurement of acceleration on the market, a precise search is essential. The aim of this search is to select the sensor which corresponds to all the requirements placed on it.

The requirements of the sensor are as follows:

x Frequency coverage up to 2 kHz x Accelerations up to 250 m/s2 x 3-Axis x Digital Interface(SPI,I2C) x Small size x Low cost

Based on these requirements, the sensors listed in Table 3.1 are evaluated.

20

Sensor Frequency [Hz]

Acceleration Axes x[m/s2]

Interface Size [mm]

Cost

ADIS16227CMLZ 100000 3 x 700 SPI 15 700 € ADXL001-70 22000 1 x 700 Analog 5 28 € ADXL345BCCZ 3200 3 x 160 SPI 5 4.80 € BMA150 1500 3 x 80 SPI 3 4.0 € BMA280 500 3 x 160 SPI 3 0.85 € BU-21771-000 3000 1 x Vibration Analog 8 85 € LIS3DH 5000 3 x 160 SPI 3 2.50 € MMA6825BKW 1000 2 x100 SPI 6 9.50 €

Table 3.1: Available sensors

These are not all the sensors available on the market, as a pre-selection has been made with regard to the task. In particular, the bandwidth of the sensors is very limited especially in the field of MEMS sensors. For example, the BMA280 is a classic sensor for consumer electronics and also costs less than a euro; however, the bandwidth is limited to 500 Hz.

The ADXL001-70 has a high bandwidth and a wide measuring range. However, due to the analog output signal and only one axis, using this sensor is associated with a high circuit complexity.

The ADIS16227CMLZ meets all technical requirements, but it comes with its high price and hence it is not considered.

The only sensor with sufficient bandwidth and an acceptable range of 160 m/s2 is LIS3DH. Through its digital interface and the relatively low price, it is used as the sensor in the context of this work.

3.1.4. Selected Acceleration Sensor

The selected acceleration sensor LIS3DH by STMicroelectronics [23] is a low-power, 3D acceleration sensor in the space-saving LGA16 (3mm x 3mm x 1mm) housing. The communication can be made via the SPI interface or the I2C interface. The measuring range is adjustable to 2 , 4 , 8 and 16 . The sampling rate can be adjusted in the range of 1 Hz to 5 kHz.

According to the data sheet, the following sensor parameters yields for the operation at 5 kHz and with the measuring range of 16 :

x 8-bit resolution x 192 mg/digit

21

This results in a quantization of 1.883 . If you multiply this quantization with

127 for the positive and 128 for the negative sensor range, one comes to the maximum sensor limits of 239.1 and -241. 0 . The sensor according to the data sheet is not specified in the range outside of 16 g.

3.2. Development Platforms

In the context of this work, the tasks greatly restrict the number of development platforms that can be used. So, the platform that works with the 8-bit and 16-bit core is not good enough. The Table 3.2 gives an overview of three platforms which for this work must be examined very closely. [35][22][23]

Arduino Due STM32F4 Discovery

Raspberry Pi Model B

Kernel 32 - Bit 32 – Bit 32 - Bit Architecture ARM Cortex – M3 ARM Cortex – M4F ARM1176JZF – S

Storage 512 KB 1 MB SD – Card RAM 96 KB 192 KB 512 MB USB 9 9 9 SPI 9 9 9

USART 9 9 9 I2C 9 9 9 ADC 9 9 - RTC - 9 9

Operating system - - Linux Debugger - 9 9

Programming language Processing C, C++ C++, Java, Python Programming environment Arduino IDE CooIDE Eclipse, Geany

Cost 39.00 € 14.17 € 39.95 €

Table 3.2: Overview of development platforms

3.2.1. Arduino Due

The Arduino Due [35] is based on the concept of Shields, which makes it possible to connect different hardware to the base system. These shields are standardized in their pin assignment and in the structure and hence they are compatible. Since the shields are mostly intended for the Arduino MEGA with IO levels of 5V, it must be examined before plugging whether they are suitable for the Arduino Due to IO levels 3V. The structure makes it very modular, as it can be seen in the Figure 3.5, that no hardware, such as sensors is installed on the base plate. A disadvantage is that the programming can be done only via the Arduino IDE. This is meant to be used for small projects and it does not offer debugging options.

22

An exclusion criterion is the lack of FPU, for rapid calculation of floating point numbers, in addition to the missing debugger.

Figure 3.5 Arduino Due [35]

3.2.2. Raspberry Pi

The Raspberry Pi [22] is a computer in credit card format. It can be used both in electronics projects, as well as a desktop PC for spreadsheets, word processing and games. It is also possible to play back high definition video. The aim of this development platform is to get young people around the world the opportunity to learn programming.

The advantages of the Raspberry Pi shown in Figure 3.6 are clearly in the high performance of the processor and operating system functionality. However, this comes at the cost of the hardware connection and is not as distinct as for example on an Arduino Due. Standard interfaces such as SPI, I2C and UART are available in simple version, which allows the extension of hardware such as ADC, GPS and sensors. However, as an essential part of this work is the hard real-time requirement, the Raspberry Pi, can be used on the basis of its operating system, only for further processing and analysis of sensor signals.

23

Figure 3.6: Raspberry Pi [22]

3.2.3. STM32F4 Discovery

The STM32F4 Discovery is a development board from ST [23]. It is a microcontroller based on STM32F407VGT6 which also comes with the debugger SWDebugger. With this, it is possible to program on the microcontroller and also debug it. The STM32F4 Discovery microcontroller as shown in the Figure 3.7 also comes with the following sensors and actuators installed on it:

x Audio DAC (CS43L22) x Microphone (MP45DT02) x MEMS Acceleration sensor (LIS302DL) x 4 LEDs

Since the hardware listed above occupies a part of the ports by their hard wiring, this development platform is not as modular as for example Arduino Due. However, all the ports of the microcontroller are routed to the side-mounted pin headers. This makes it easy to connect further hardware.

24

Figure 3.7: STM32F4 Discovery [23]

3.2.4. Baseboard for the STM32F4 Discovery

By the company, Element14 [21], there is a base board as shown in the Figure 3.8, to which the STM32F4 Discovery can be fitted. This baseboard extends the functionality of STM32F4 to a serial interface RS232 specification, Ethernet, SD card slot, camera interface and the ability to connect a LCD display with touch screen.

Figure 3.8: STM32F4DIS – BB [21]

The advantage of this baseboard is to use the functionality provided by the microcontroller directly on this board. This means that the interfaces are connected directly to the pin connector "CON4". So, all the six serial ports, I2C, CAN, SPI interface, four PWM outputs and six digital outputs are available.

The company Element14 [21] provides a LCD, STM32F4DIS-LCD which is suitable for the baseboard with the following specifications:

25

x Display size: 3.5 Inch (8.89 cm) x Display format: 320*240 x Color: 262K colors x Interface: 16-bit 8080 parallel system interface x Backlight: PWM control x Touch screen: 4-wire resistive touch screen x Power consumption: 0.18 A at 5 V

The LCD display shown in Figure 3.9 will be using the 40-pin flat ribbon cable directly connected to “CON3” on the baseboard. The disadvantage of using this LCD is that it occupies the full-fledged port with the 16-bit 8080 parallel system interface. This may cause problems with a lot of additional hardware in the project.

Figure 3.9: STM32F4DIS – LCD [21]

Nevertheless, the baseboard is suitable in connection with the LCD display as the development platform due to the modular design. In addition, the manufacturer Element14 [21] on its homepage provides ready libraries for the control of the display along with the rest of the hardware.

3.3. OBD-II Adapter

The OBD-II adapter is a standardized hardware interface with the female 16-pin J1962 connector. The OBD-II has five signal protocols for the communication. The pins are assigned with particular protocol on the interface. The signal protocols used for communication in the OBD-II are as follows [18][19]:

x SAE J1850 PWM (pulse-width modulation, 41.6 kB/sec )

26

x SAE J1850 VPW (variable pulse width, 10.4/41.6 kB/sec) x ISO 9141-2 x ISO 14230 KWP2000 (Keyword protocol 2000) x ISO 15765 CAN (250 kBits/s or 500 kBits/s)

Most of the vehicles are implemented with only one of the communication protocols, so it is important to select the OBD-II adapter with the suitable signal protocol that exists on the vehicle that would be monitored.

3.3.1. ELV Diagnose Adapter

The ELV Diagnose Adapter from the company ELV [24] as shown in the Figure 3.10 is based on the ISO 14230 KWP2000. It has two lines used for the communication. A single line called K-line with bidirectional serial communication and another L-line for wake up. The K-line occupies the pin 7 on the OBD-II interface and the L-line is on the pin 15. These signal protocols are primarily used in Chrysler vehicles. Since, a Chrysler Voyager vehicle was available for the tests; the initial diagnosis was done with the help of this adapter in this work.

Figure 3.10: ELV Diagnose Adapter

3.3.2. OBD-II to DB9 Adapter

The OBD-II to DB9 [25] shown in the Figure 3.11 is an adapter with OBD-II connector interface on one end and the DB9 serial connector on the other end. It is based on the signal protocol ISO 15765 CAN. It has two lines used for the communication. It uses pin 6 for CAN High and pin 14 for CAN Low. CAN is the protocol widely used for the communication for OBD since the year 2008 [19]. The adapter is also of low cost. Hence, the OBD-II to DB9 was chosen in the context of this work. All the OBD tests in this work are done on the VW-Polo based on the CAN protocol.

27

Figure 3.11: OBD-II to DB9 adapter [25]

3.3.3. OBD-II UART Adapter

The OBD-II UART [26] adapter shown in the Figure 3.12 is based on the signal protocol ISO 15765 CAN. It has two lines used for the communication. It uses pin 6 for CAN High and pin 14 for CAN Low. The adapter is designed for Arduino but it is also compatible with STM32F4 Discovery board. It is based on the ELM327 microcontroller. The adapter is also provided with ready library for Arduino which can be ported to STM32F4 Discovery microcontroller. This also provides the power supply which is converted and regulated from the OBD-II port for the microcontroller and attached devices. Since one of the aim of this work was to reduce the size of the logger, using this adapter helps in reducing the size of the logger in a considerable amount. Hence, this was the adapter chosen in this work.

Figure 3.12: OBD-II UART adapter [26]

28

29

4. Implementation

4.1. Software

The Software for the data logger is completely written in C programming language. Drivers for the hardware components and the necessary algorithms are included using the header files. An overview of the software is given in the table 4.1 in which the functions of the each individual file is described.

File Function

stdio.h Standard library for Input and Output functions math.h Standard library for mathematical functions string.h Standard library for strings lis3dh_driver.c Default driver for LIS3DH from ST [23] stm32_ub_usb_msc_host.c Library used to write on USB Stick using USB OTG

interface [28] stm32f4_discovery_lcd.c Default driver for LCD from ST [23] stm32f4_gpio.c Setting STM32F4 ports as input and output for

buttons and LEDs stm32f4_usart.c Configuring USART 1 for GPS and USART 6 for

OBD-II for basic communication stm32f4_spi.c Configuring SPI for LIS3DH for initializing the

Sensor and communicate stm32f4_isr.c Initialize the TIM10 for cyclic interrupt, UART 1 for

GPS and UART6 for OBD-II stm32f4_adc.c Initialization and readout of ADC functions stm32f4_rtc.c Enable RTC function stm32f4_lcd.c Initialize and update LCD stm32f4_gps.c Function for processing GPS signals raw_eval.c Functions for calculating RMS, mean value,

maximum value and crest factor of the measuring signals

obd_eval.c Functions for calculating RPM, speed, engine load, air temperature, coolant temperature, oil temperature, barometric pressure and absolute pressure

progs_eval.c Library with 3 menus: 1. Display sensor, OBD and GPS values 2. Store EMC, OBD and RFM 3. Store RAW and OBD

rainflow_eval.c Rainflow algorithm

Table 4.1: Libraries and Algorithms

30

4.1.1. Development Environment

The development environment from CooCox, “CooCox CoIDE” with version 1.7.6 is used in this work [36]. This is a new and free software development environment for ARM Cortex MCU based microcontrollers. The IDE also provides the tools, “CoBuilder” and “CoDebugger” for creating and debugging of the software with a user friendly interface. Also, the standard libraries that are provided by ST [23] are already integrated so that addressing the control peripherals are easy to implement.

The compiler from GNU Tools for ARM Embedded Processors [27], “gcc-arm-none-eabi” with version 4.8 is used with the CoIDE. The compiler has to be set initially in the CoIDE by using the path “Project ► Select Toolchain Path” with the Toolchain path being the directory of the compiler.

4.1.2. Main Program

The microcontroller starts with the main program (main.c) when it is switched on. The microcontroller and the devices connected to the microcontroller are initialized in the main program. The initialization takes place as follows:

x Switch to the external quartz (8MHz) x Configure LED ports as outputs x Configure Button ports as inputs x Initialize UART1 as RS232 for GPS x Initialize UART6 at baud rate 38400 for OBD x Initialize SPI interface for communication with LIS3DH x Set LIS3DH to 5367 Hz and 8 Bit x Set TIM10 for cyclic interrupts every 200 µs x Initialize USB-OTG interface to store on USB Stick x Set ADC on the pins PA3 and PA5 with 12 Bit at 3V x Switch on the RTC on the microcontroller x Set the pins and DMA for LCD display

After the initial setup, the structures for RTC, GPS, Rainflow, UART, LIS3DH Raw data and OBD are initialized. So that the initialization is complete, the further sequence of the program corresponds to the flow chart as given in the Figure 4.1.

The individual subroutines are discussed in Chapters 4.1.4 and 4.1.5.

31

Figure 4.1: Main program

32

4.1.3. Interrupts

To guarantee the hard real-time requirement when reading the sensors during the measurement, an interrupt is triggered using the timer “TIM10” every 200 µs. This is executed with the priority “0”, which corresponds to the highest priority and is adjustable according to the flowchart as shown in the Figure 4.2. The processing time of the Interrupt Service Routine for reading from a sensor is 32.4 µs.

Figure 4.2: Interrupt TIM10

33

The second interrupt is triggered when the data from the OBD-II is received on UART6. This interrupt is also executed with the priority “0” and hence it also has the highest priority as that of the “TIM10” interrupt. The data received from the OBD is stored in the register and after receiving the last buffer element, the data is evaluated. The processing of the interrupt is done as shown in the flowchart in Figure 4.3.

Figure 4.3: Interrupt UART 6

34

The third interrupt is triggered on receiving of the data on the UART1 from the GPS. The data sent by the GPS are stored in the buffer of 1024 values and are evaluated after receiving of the last buffer element. The interrupt has the priority of “1” and is thus has the lower priority than that of the “TIM10” interrupt. The processing of the interrupt is done as shown in the flowchart in Figure 4.4.

Figure 4.4: Interrupt UART 1

4.1.4. Hardware Drivers

This chapter describes all the settings that are implemented by each hardware driver used in this work. The settings are based on the datasheet of the STM32F407VHT6 from ST [23].

lis3dh_driver.c

This driver is provided by ST [23]. The driver uses SPI interface for communication. The communication is done by using LIS3DH_WriteReg(…) for writing and LIS3DH_ReadReg(…) for reading.

35

Using the function LIS3DH_GetAccAxesRaw(…), 16 bit data are read out from each of X axis, Y axis and Z axis. Since the sensor is in the 8 bit mode, the sensor values are in high byte. For this reason, the values of the low bytes are discarded.

stm32f4_adc.c

The reading of the ADC is implemented in this driver. The resolution of the ADC is 12 Bit. The data from the ports "PA3" and "PA5" are measured and the average of over 16 values is taken and multiplied by the division factor of 10. The measuring range is between 0.0V to 30.0V.

stm32f4_discovery_lcd.c

This driver is provided from Element14 [21]. It is used with the other drivers directly as it is provided.

stm32f4_gpio.c

This driver is used to initialize the ports for the LEDs and buttons. Once the LEDs are set, it can be controlled by using set_LED(…) function which can be switch the LEDs on and off. Using get_pin(…) function, the status of the buttons can be known.

stm32f4_gps.c

This driver is about the phases of GPS data in the GPS structure. It always stores the current GPS position. The GPS data format is presented in 4.4.1.3.

stm32f4_isr.c

For the continuous reading of the data from the “LIS3DH” sensor, the timer “TIM10” is configured in this driver so that an interrupt is triggered every 200 µs. This calls the interrupt service routine in which the sensor data is read. The processing of the interrupts is described in the chapter 4.1.3. The timer “TIM10” is set according to the Table 4.4.

T10 Clock Divider (CKD) 1 Prescaler (PSC) 2 Counting Direction Up Period (ARR) 11200

Table 4.2: Configuration for TIM10

36

With the clock frequency 168 MHz, according to the equations 4.1, 4.2 and 4.3, an interrupt frequency of 5000 Hz is triggered which corresponds to 200 µs.

(5.1)

(5.2)

(5.3)

stm32f4_lcd.c

This driver is used to initialize and update the display of the logger. It is also used to turn the display off in case of energy saving. This driver is based on the driver provided from ST [21], “stm32f4_discovery_lcd.c”.

stm32f4_rtc.c

The built-in RTC on the STM32F4 Discovery microcontroller is initialized in this driver. The RTC is set and read using this driver. For using the RTC, the conversion described in the chapter 4.4.1.2 is necessary. The conversion is not done if the function init_RTC(…) is commented out in the main.c function and then the program is run.

stm32f4_spi.c

The communication with the sensor LIS3DH is done via SPI using this driver. This driver includes the functions to send and receive the data over the SPI interface. This driver also includes two functions to initialize the sensor in “normal power mode” with 12 Bit resolution and 1344 Hz or “low power mode” with 8 Bit resolution and 5367 Hz. The SPI is configured according to the Table 4.5.

SPI SCK PB10 MISO PC2 MOSI PC3

CS PB9 SPI Mode Master Data size 16 Bit

Division factor 8 Frequency 5.32 Hz

Table 4.3: SPI Configuration

37

stm32_ub_usb_msc_host.c

This driver is used from a website [28]. It provides the libraries and examples for the STM32F4 Discovery microcontroller. This includes the FAT32 file system, which is required for the reading and writing of data on the USB stick.

stm32f4_usart.c

This driver is used to configure the setting of the serial interfaces. The interfaces are configured according to the Table 4.6.

UART1 UART6 Use GPS OBD-II

Rx Pin PB6 PC7 Tx Pin PB7 PC6

Baud rate 9600 38400 Mode Rx Tx Rx Tx

Stop Bits 1 1 Word length 8 8

Table 4.4: UART Configuration

stm32f4_usb.c

This driver makes use of features provided in the driver “stm32_ub_usb_msc_host.c” to write to the USB stick. This driver allows storing of the results in four different formats which are described in the chapter 4.1.6.

4.1.5. Software Algorithms

raw_eval.c

The calculation of the raw values shown on the display and storing them on the USB stick is implemented using the function “raw_eval.c”. It is carried out on all the 3 axes in the same way. For this reason, only the general algorithm is presented here. A measurement always consists of 2048 values. The number of values is chosen to perform the FFT analysis on the data. The processing of the measured values is performed in raw data format. In the end, the results are converted into accelerations by the factor of 1.883 according to the chapter 3.1.4. The Mean value is calculated according to the equation 4.4 and corresponds to the static component of the acceleration. The RMS value is calculated from the individual measured values, minus the mean value according to the equation 4.5. Subtracting the mean value of the RAW data is necessary because the RMS value if the vibration is calculated and therefore it must be independent of the DC component. The same applies for the

38

Maximum value, which is calculated according to the equation 4.6. The Crest factor is calculated according to the equation 4.7 and it indicates whether the shock exists in a measurement.

(4.4)

(4.5)

(4.6)

(4.7)

obd_eval.c

The calculation of the OBD-II data shown on the display and storing them on the USB stick is done using the function “obd_eval.c”. The communication between the microcontroller and the OBD-II adapter is carried out using AT commands [29]. Since the adapter is based on the ELM327, it has specific AT commands. The adapter is first reset before the start of every evaluation by calling AT Z. This returns the device settings to the default value putting it in idle state waiting for further commands. The next command is AT L1, which generates linefeeds after every carriage return character. The third AT command is AT SP 0, which selects the protocol that should be used automatically. After the initial set up, the next commands are selected based on the OBD data that is required by using the mode and the PID of the data. For example, to obtain the data of RPM, after initially setting up the OBD-II adapter, the fourth command should be “010C”, where “01” is the mode which is used to display the current data and “0C” is the PID of the RPM. In this work, eight OBD data are collected. The collected OBD data with their mode and PID are as shown in the Table 4.7. Each of the OBD data has different conversion method to convert to decimal format. This is presented in the chapter 4.2.

39

OBD data PID Engine RPM 010C

Vehicle Speed 010D Intake Manifold Absolute Pressure 010B

Barometric Pressure 0133 Calculated Engine Load 0104 Engine Oil Temperature 015C

Coolant Temperature 0105 Intake Air Temperature 010F

Table 4.5: OBD data and PIDs

prog_eval.c

By the means of the switch installed on the logger, it is possible to select between the three types of measurement programs. This is implemented in the function “prog_eval.c”.

Choosing the measurement program 1 will select the function prog_display(). This function is used to only show all the measured data on the display. It displays the RMS, Mean, Maximum and Crest factor for each of the 3 axes along with the 8 OBD data from the OBD-II adapter. Furthermore, the measured voltages and the GPS position of the vehicle along with speed, direction of travel, time and date are displayed.

The measurement programs 2 and 3 require USB-Stick connected to the logger to start the measurement. The USB-Stick should be connected to the USB-OTG and should be formatted in FAT32 file format.

In the measurement program 2, the measurements listed in the program 1, from RMS up to Crest factor are stored in a *.txt file. In addition, all the OBD data mentioned in the “obd_eval.c” are measured and stored in a different *.txt file. Furthermore, the vibration data are counted with the rainflow algorithm using “rainflow_eval.c” and stored once a day as rainflow matrix in a *.txt file. The data format of all the three files is presented in the chapter 4.1.6.

The measurement program 3 stores the values from the sensor as raw data at real-time. The values are set in the packets of 2048 values in the memory of the microcontroller and then stored on the USB-Stick in a *.txt file. In addition, all the OBD data mentioned in the “obd_eval.c” are measured and stored in a different *.txt file. The data format of both the files is presented in the chapter 4.1.6.

40

rainflow_eval.c

In “rainflow_eval.c”, the rainflow algorithm explained in the chapter 2.3 is implemented. The rainflow matrix has a size of 64x64. The values that are read from the sensor are processed according to the rainflow algorithm in RAW format. The RAW data is first divided by 4 and then with an addition of 32 is associated in the range of 0 to 63. This results in that the value 0 corresponds to the RAW value -128 and 63 corresponds to 127. Through the conversion of the values in the range of 0 to 63, the value itself can be used to address in the algorithm. This makes the algorithm very effective with respect to the memory usage and speed.

4.1.6. Formats of the Measurement

The measured data is stored in the *.txt files depending on the measurement program. The measurement program 2 creates an entry every 409.6 ms in the form of new line to the file EMCxxxx.txt and corresponding to the sampling time of 200 µs, an entry is made into the file OBDxxxx.txt. Furthermore, it creates the rainflow matrix into the fi le RFMxxxx.txt at the start of the new day or end of the measurement. Instead of “xxxx” a sequence number from 0000 to 9999 is entered. The files with the same number always belong together. The format of the values separated by a semicolon and stored in the file EMCxxxx.txt is given in the Table 4.8.

Column Parameter Value 1 Date Date in dd.mm.yy 2 Time Time in HH:MM:SS 3 Mean X-Axis Mean in m/s2

4 Mean Y-Axis Mean in m/s2 5 Mean Z-Axis Mean in m/s2 6 RMS X-Axis RMS in m/s2 7 RMS Y-Axis RMS in m/s2 8 RMS Z-Axis RMS in m/s2 9 Maximum value X-Axis Maximum value in m/s2

10 Maximum value Y-Axis Maximum value in m/s2 11 Maximum value Z-Axis Maximum value in m/s2 12 ADC PA3 Analog Voltage 13 ADC PA% Analog Voltage 14 GPS Status GPS status: V=No Signal, A= Signal 15 Speed Speed in km/h 16 Latitude Latitude in ° 17 Latitude Minutes Latitude in minutes 18 Latitude Direction Direction: N=North, S=South 19 Longitude Longitude in ° 20 Longitude Minutes Longitude in minutes 21 Longitude Direction Direction: E=East, W=West

Table 4.6: Format of EMCxxxx.txt fi les

41

The first line of the OBDxxxx.txt consists of the date and time of the start of the measurement and the second line consists of the type and order of the measurements stored in the file. The measured values are stored from the third line in the file which is separated by a semicolon. The format of the file OBDxxxx.txt is as given in the Table 4.9.

Column Parameter Value 1 Date Date in dd.mm.yy 2 Time Time in HH:MM:SS 3 RPM Engine RPM in rpm

4 Speed Speed in km/h 5 Intake Manifold Absolute Pressure Pressure in kPa 6 Barometric Pressure Pressure in kPa 7 Calculated Engine Load Engine load in % 8 Engine Oil Temperature Temperature in ° 9 Coolant Temperature Temperature in °

10 Intake Air Temperature Temperature in ° 11 GPS Status GPS status: V=No Signal, A= Signal 12 Speed Speed in km/h 13 Latitude Latitude in ° 14 Latitude Minutes Latitude in minutes 15 Latitude Direction Direction: N=North, S=South 16 Longitude Longitude in ° 17 Longitude Minutes Longitude in minutes 18 Longitude Direction Direction: E=East, W=West

Table 4.7: Format of OBDxxxx.txt files

The rainflow matrices of three axes are stored in the RFMxxxx.txt file. The name of the axis is written in order to indicate the corresponding matrix. The format of the RFMxxxx.txt file is as given in the Table 4.10.

Column Parameter Value 1 X-Axis X-Axis name

2-65 Rainflow Matrix Rainflow Matrix values 67 Y-Axis Y-Axis name

68-131 Rainflow Matrix Rainflow Matrix values 133 Z-Axis Z-Axis name

134-197 Rainflow Matrix Rainflow Matrix values

Table 4.8: Format of RFMxxxx.txt files

The measurement program 3 saves the raw data in the range of -128 for the minimum and 127 for the maximum in the file RAWxxxx.txt and the OBD data into the file OBD_RAWxxxx.txt. The data of the axes are separated by a semicolon and stored line by line in the file RAWxxxx.txt. The OBD data are stored just as in the

42

measurement program 2 with the same format. The time between new entries depends on the sampling time of 200 µs. Instead of “xxxx” a sequence number from 0000 to 9999 is entered. The files with the same number always belong together. The entry in the first line of the file RAWxxxx.txt is the date and time of the start of the measurement. The format of the RAWxxxx.txt file is as given in the Table 4.11.

Column Parameter Value 1 X-Axis X-Axis name 2 Y-Axis Y-Axis name 3 Z-Axis Z-Axis name

Table 4.9: Format of RAWxxxx.txt files

4.2. Parameter Conversion for OBD-II data

After the initialization of the OBD-II adapter with the AT commands [29] presented in 4.1.5 in the section “obd_eval.c”, the next OBD commands do not start with AT. These are OBD specific commands which the ELM327 adapter recognizes. The OBD command has two parts. The first part is the mode, which has ten different modes with different functions. In this work, only the first mode “0x01” which show the current data is used. The second part is the PIDs which are given in the Table 4.7.

The OBD-II adapter responds with the ID and the data. The response is based on the type of the data requested. For example, the response for the RPM parameter would be a total of 4 bytes. The first two bytes consists of the identification of mode 1. The next two bytes consists of the current RPM values in Hexadecimal format. The Hexadecimal values are converted into decimal values before storing in the file or displaying on the LCD using the function “hex_decimal ()”.

Each of the PIDs mentioned in the Table 4.7 has different conversion methods to convert to decimal. This is presented in the following chapters.

4.2.1. Engine RPM

The OBD command used for engine’s RPM is 010C. As mentioned, it consists of 4 bytes, with the first 2 bytes as the identification of mode 1 and second 2 bytes with the current RPM values. The second 2 bytes are used in the following equation 4.8 for converting into decimal.

(4.8)

The A and B denote the first and second bytes of the data. The range of the RPM is 0 to 16,383.75 revolutions per minute.

43

4.2.2. Speed

The OBD command used to obtain vehicle speed is 010D. The OBD responds with 1 byte of data for the speed. The speed value can be obtained by just converting the received value into decimal. The range of the speed is 0 to 255 km/h.

4.2.3. Intake Manifold Absolute Pressure

The OBD command used to obtain the intake manifold absolute pressure is 010B. Just like the speed, the intake manifold absolute pressure also contains only 1 byte of data from the OBD. The intake manifold absolute pressure value can be obtained by just converting the received value into decimal. The range of the intake manifold absolute pressure is 0 to 255 kPa.

4.2.4. Barometric Pressure

The OBD command used to obtain the barometric pressure is 0133. The barometric pressure also contains only 1 byte of data from the OBD. The barometric pressure value can be obtained by just converting the received value into decimal. The range of the barometric pressure is 0 to 255 kPa.

4.2.5. Engine Oil Temperature

The OBD command used to obtain the engine oil temperature is 015C. The engine oil temperature also contains only 1 byte of data from the OBD. The engine oi l temperature value can be obtained by converting the received value into decimal using the following equation 4.9.

(4.9)

The A denotes the data received from the OBD. The range of the engine oil temperature is -40 to 210 °C.

4.2.6. Calculated Engine Load Value

The OBD command used to obtain the engine load value is 0104. The engine load value also contains only 1 byte of data from the OBD. The engine load value can be obtained by converting the received value into decimal using the following equation 4.10.

(4.10)

44

The A denotes the data received from the OBD. The range of the engine load value is 0 to 100 %.

4.2.7. Engine Coolant Temperature

The OBD command used to obtain the engine coolant temperature is 0105. The engine coolant temperature also contains only 1 byte of data from the OBD. The engine coolant temperature value can be obtained by converting the received value into decimal using the following equation 4.11.

(4.11)

The A denotes the data received from the OBD. The range of the engine coolant temperature is -40 to 215 °C.

4.2.8. Intake Air Temperature

The OBD command used to obtain the intake air temperature is 010F. The intake air temperature also contains only 1 byte of data from the OBD. The intake air temperature value can be obtained by converting the received value into decimal using the following equation 4.12.

(4.12)

The A denotes the data received from the OBD. The range of the intake air temperature is -40 to 215 °C.

4.3. Fast Fourier Transform with Radix-4 algorithm

The Radix-4 Fast Fourier Transform (FFT) algorithm is implemented on the STM32F4 Discovery in the context of this work. This algorithm is provided by ST [21] as the library. The integration is done via "arm_cfft_radix4_f32.h" and various adjustments in the development environment. The same function arm_cfft_radix4_f32 () performs a FFT on N = 1024 values.

For testing purpose, the signal provided by ST, “testInput_f32_10khz []” is read from STM32F4 Discovery by a FFT in the frequency domain and subsequently sent over the serial interface to the computer. The data is received and stored in the Terminal.

In the next step, the test signal "testInput_f32_10khz []" is read into Matlab and it is subjected to FFT. Both signals are compared as shown in Figure 4.5, to ensure the accuracy of the converted values in STM32F4 Discovery.

45

The time required for the FFT is measured and the resulting value is 10.78 ms. The data is present as complex number. The amount of information which is necessary for further processing requires another 1.33 ms. Hence, together the time required is 12.20 ms for one axis. Thus, it is possible to perform a FFT under real-time requirement.

Figure 4.5: Comparison of STM32F4 Radix-4 FFT with Matlab FFT

4.4. Hardware

4.4.1. Data Logger

The major part of this work is to build the autonomous data logger with smaller in size than that of the previous existing logger for the continuous collection of the OBD data and the acceleration data. The logger is based on the STM32F4 Discovery microcontroller board with the STM32F4DIS-BB baseboard and STM32F4DIS-LCD for the display. The logger is installed with the OBD-II adapter for collecting the real-time data from the car. In addition, an operational amplifier for level matching of the analog inputs and a GPS module for the determination of the position are installed. The power is supplied by a DC/DC convertor and a battery is powered for the RTC even when the voltage is disconnected. This entire are put together in the housing with compact design. The top of the logger is attached with the LCD display and the side with the switches, a pushbutton and indicators. The schematic display of the logger with the interactions between the components used and their associated signaling pathways are as shown in the Figure 4.6

46

Figure 4.6: Schematic view of the Data logger

4.4.1.1. Building Data Logger

The data logger is built on a breadboard of size 130 mm x 100 mm which is a great reduce in size from that of the pervious logger which was bui lt on the breadboard of size 160 mm x 150 mm. The Figure 4.7 shows the components of the logger installed on the breadboard.

Figure 4.7: Data logger components

47

The logger is implemented with a DC/DC convertor (TEL 5-1211) for the power supply which can be seen at the bottom-right corner of the board. This is secured with a 1.25 fuse.

At the top-right corner of the board, an operational amplifier (TS912NI) is mounted which is used as an impedance convertor high impedance tapping of the voltage divider and low impedance binding to the microcontroller. This is necessary because the ports of the microcontroller are already provided with other hardware and the leakage would alter the voltage divider. So the “CLK” signal for the MEMS acceleration sensor located on the STM32F4 Discovery board is connected to the port “PA5”. Since the “CLK” signal acts as the input signal, the port “PA5” can be used. However, the port “PA3” is free. By providing the supply voltage of 3V to the operational amplifier, it is ensured that the analog inputs of the microcontrollers are not damaged by high voltages.

Next to the DC/DC convertor and the fuse is the 3 V Battery (CR2032) installed. This is connected through a jumper to “PIN6” located on the STM32F4 Discovery. This is used to provide the power supply to the RTC even when the voltage is disconnected.

Above the operational amplifier, a female connector for the switches and LEDs is mounted. And below the operational amplifier, a DIP switch is mounted which is used to synchronize the RTC with the GPS. The series resistors for the LEDs and the pull-up resistors for the switches are mounted in between. All the necessary connections between the components on the breadboard and the STM32F4 Discovery are implemented directly by soldering the individual wires.

For the easy connection of the sensor, OBD-II adapter, GPS module, USB-Stick and the power supply, sockets are mounted on the side panel of the data logger. The Figure 4.8 shows the side panel of the data logger with the sockets, switches and LEDs. The pin assignment of the sockets is described in the schematic shown in the Figure 4.10.

The STM32F4DIS-BB baseboard is used only for connecting the STM32F4DIS-LCD display using the 40-pin ribbon cable. The LCD mounted on the top of the data logger is shown in the Figure 4.9.

The schematic of the circuit built for the entire data logger is shown in the Figure 4.10. All the solder connections that go to the pin headers of the STM32F4 Discovery are marked in the schematic indicating “STM32F4” and the associated pin.

To operate the logger and to display the results of all the measured values on the LCD, switches and LEDs are installed on the side panel of the logger. The display is powered and controlled by the 40-pin ribbon cable connected to the baseboard. The control of the LEDs and the polling of the switches are implemented by connecting the pin header to the female connector located on the breadboard. The wiring of the switches and LEDs on the side panel is described in the schematic shown in the Figure 4.10.

48

Figure 4.8: Side panel of the Data logger

Figure 4.9: LCD mount on the Data logger

49

Figure 4.10: Schematic circuit of the Data logger

50

4.4.1.2. RTC

The STM32F4 Discovery has an internal RTC. To use this internal RTC, a SMD Quartz X3 with a frequency of 32.768 MHz must be equipped together with two SMD capacitors C16 and C27 with the value of 6.8 pF. The RTC connections made on the STm32F4 Discovery is shown in the Figure 4.11. In addition to this, the 0Ω resistors on the SB15 and SB16 on the back of the STM32F4 Discovery board must be removed.

Figure 4.11: STM32F4 Discovery with X1, C16 and C27

In order to ensure the store and continue running of the RTC in case of a power failure, a battery must be installed. The connection of such a battery to the STM32F4 Discovery can be done to the pin 6, “VBAT”. This is done by removing the 0Ω resistor on the R26 and soldering the positive terminal of the battery to the pad facing the microcontroller as shown in the Figure 4.12. The negative terminal of the battery is connected to the GND pin of the STM32F4 Discovery board.

Figure 4.12: Battery on R26 pad

51

The RTC must be implemented on the STM32F4 Discovery for the program to be run on the data logger.

4.4.1.3. GPS

The GPS module used for determining the position in this work is the “GPS Bee Kit” from Seeed Studio [30]. This is an ublox-5 GPS receiver fitted with an external antenna. The technical details of the ublox-5 GPS module [31] are as follows:

x 4 Hz position update rate x -160dBm acquisition and tracking sensitivity x UART, USB, DDC and SPI interfaces

The UART is the interface used in this work for the communication of the GPS module with the STM32F4 Discovery board. The GPS position is sent continuously by the GPS module over the UART interface. The GPS Bee Kit uses NMEA 0183 protocol [32] to transmit data and they are ASCII coded. This protocol offers minimum amount of dataset. The dataset used in this work is “RMC” which is one of the protocols NMEA 0183.

The structure of the dataset “RMC” is as follows:

The individual values are separated by commas and are described in the Table 4.12.

Value Meaning Beginning of Data

ID for GPS Recommended minimum data set C

Time Status: A= Okay, V= Warning

Longitude Direction (North or South)

Latitude Direction (East or West) Ground speed Course over ground in °

Date Magnetic Variation Signal integrity Hexadecimal representation of checksum

Table 4.10: GPRMC data format

To use the GPS Bee module in the vehicle, it must be protected against external influence and mounted near a window. For this purpose, the module is packed in a shrink wrap and provided with a wire as shown in the Figure 4.13. The final module

52

which is shown in the Figure 4.14 can be connected to the data logger to the socket named GPS. Therefore the mounting of the data logger is largely independent of the GPS module.

Figure 4.13: Shrink wrap over GPS module

Figure 4.14: GPS module with DB9

4.4.1.4. OBD-II

The OBD-II adapter used in this work is “OBD-II UART Adapter” from Freematics [26]. This OBD-II adapter is designed specifically for the Arduino microcontrollers with a dedicated library for the OBD data measurement. Since the adapter uses UART interface for the communication, it can be used with all the microcontrollers which supports UART. The adapter also comes with the DC/DC convertor which provides with regulated DC 5V power supply. The technical specifications of the OBD-II UART Adapter are as follows:

x Supports CAN bus, KWP2000 and ISO9141-2 protocols x High efficiency DC/DC with 5V power supply

53

x Up to 100 Hz read-out rate x UART interface

The real-time OBD data is collected continuously from the vehicle using the OBD-II UART Adapter through the UART interface. The OBD-II UART Adapter uses CAN bus protocol with ISO 15765 CAN [19] for measuring the OBD data. The OBD data is collected depending on the PIDs of the OBD. It uses ASCII characters for the communication and the command set used is the “AT” command set compatible with ELM327 microcontroller [29]. Any OBD-II adapter compatible with ELM327 can be used for collecting the OBD data in this work. The OBD-II UART Adapter used in this work is as shown in the Figure 4.15. The adapter is plugged into the OBD port on the vehicle which can be usually found under the steering column or just above the pedals. The OBD port is shown in the Figure 4.16. The OBD-II UART Adapter plugged into the OBD port is shown in the Figure 4.17.

Figure 4.15: OBD-II UART adapter [26]

Figure 4.16: OBD port in the vehicle [26]

54

Figure 4.17: OBD-II adapter plugged into the port [26]

4.4.1.5. Operating Data Logger

Before applying the power supply to the data logger, the acceleration sensor LIS3DH, OBD-II adapter, GPS module and the optional USB-Stick should be connected to the logger. These connections are made correctly with their respective name. The wrong connection can lead to the damage or even destruction of the components.

After all the connections are made, the data logger can be turned on by providing the power supply. After the initialization message is displayed on the LCD, the logger is ready for use. If the USB-Stick is required for the measurement, it should be connected before starting the data logger. If the mount of the USB-Stick is successful, a red LED on the side panel of the data logger with the name USB is lit along with the message on the displayed on the bottom-left corner of the LCD.

The controlling of the data logger is done with the switches and push button that is located on the side panel of the data logger. The side panel of the data logger is shown in the Figure 4.8.

The “Display” switch is used to turn the display on and off during the measurement. Once the measurement is stopped, the display is turned on regardless of the position of the switch.

The “Measurement” switch is used to start and stop the measurement. When the measurement is turned on, the green LED named as “Measurement” indicates the measurement in progress by flashing the LED.

The measurement is selected between three options, “Display”, “EMC/OBD” and “RAW/OBD”. To do this, the “Menu” switch is used. If the measurements indicated on

55

the switch “EMC” and “RAW” are selected, the measurement is started and the green LED named as “Save” starts flashing to signal the saving on the USB-Stick. Selecting the function “Display”, the measurements are only displayed on the LCD without storing them on the USB-Stick.

The LEDs on the OBD-II adapter indicates the status of the OBD data. The green LED indicates the adapter is connected to the OBD port and the yellow LED starts flashing once the CAN data is being received.

To turn off the data logger correctly, the USB-Stick must be ejected before turning off. Failure to do so may result in the loss of data. For this purpose, the “Measurement” switch is turned off so that the measuring green LED stops flashing, then by pressing the push-down button “Eject USB” to eject the USB-Stick safely. Only then the data logger can be disconnected from the power supply.

The sensor values of the X-Axis, Y-Axis and the Z-Axis are displayed on the LCD. The front panel with the LCD is shown in the Figure 4.18 and the measurement values displayed on the LCD is shown in the Figure 4.19. The sensor values are calculated according to the equations 4.4, 4.5, 4.6 and 4.7.

Figure 4.18: Data logger front panel

56

Figure 4.19: Display of the Data logger

At the top-right of the LCD, the date and time of the RTC is displayed. Next, a table with the values of all the 3 Axes along with their parameters is displayed. Below that, a second table with the OBD data collected is displayed. In the lower part, the GPS data with date, time, speed and direction of travel is displayed. Along with that the measured analog voltages are also displayed. The last line is used to show the status of the USB-Stick and the names of the current files to which the measured values are being written.

Synchronize RTC with GPS time

To set the RTC, a GPS module has to be connected to the data logger. When the GPS data along with the date and time is shown on the display, the DIP-Switch 2 should be turned on and the STM32F4 Discovery should be restarted using the “Reset” button on the board. Now the screen will display the message “Sync RTC with GPS”. The DIP-Switch 2 is then turned off.

4.4.2. Developed Sensors

Since the sensor LIS3DH is available on the LGA-16 package, it is necessary to equip them on an appropriate Printed Circuit Board (PCB). Hence, the PCB shown in the Figure 4.20 is used to equip the sensor. In addition, a minimum circuit with voltage stabilization of distress is implemented which is as shown in the Figure 4.21.

57

Figure 4.20: PCB for LIS3DH

Figure 4.21: Schematic circuit of the sensor

The PCB used to mount the sensor on it in this work is shown in the Figure 4.22. The cable used to connect to the data logger is PRO POWER – 860180. The pin-out and color coding used is as shown in the Table 4.13. After a functional test, the sensors were casted with epoxy resin at FTAG in Esslingen. This is necessary because the sensors are used on the vehicles in outer and dirty conditions. By the means of casting the on the PCB, the environmental influences can be avoided. The casted sensor is shown in the Figure 4.23 and it can be mounted on various surfaces.

58

Figure 4.22: PCB for LIS3DH Figure 4.23: Developed sensor

Sensor LIS3DH

STM32F4 Discovery

Wire Plug

VDD 3V Red 5 GND GND Black 1 SDI PC3 Blue 3 SDO PC2 Green 4 SPC PB10 Yellow 8 CS PB9 White 6

- GND Shield Housing

Table 4.11: Pin out and color coding of the sensor

The senor orientation of the encapsulated acceleration sensor is as shown in the Figure 4.24. The implementation of the sensor in the vehicle on different positions is elaborated in the following chapter.

Figure 4.24: Sensor orientation

59

60

5. Evaluation of data from Data Logger

5.1. Measurement points for long-term recording

For recording the long-term data two cars, Honda City i-VTEC (5th Generation, 1.5l Petrol, Manual, Year: 2008) in India and Volkswagen Golf (1.2l Petrol, Manual, Year: 2014) in Germany are used. The vehicle Honda City is equipped with the sensor and the GPS module connected to the data logger. The data logger used to record the data in India is without the OBD-II adapter. This is because the data logger with the OBD-II adapter was not yet available when one of the colleagues at Bosch was travelling to India. The Volkswagen Golf is equipped with the sensor, OBD-II adapter and the GPS module connected to the data logger.

The installation location of the sensor and its orientation on the Honda City is as shown in the Figure 5.1. The sensor is mounted on the left side of the power steering. The orientation of the sensor mounted on the Honda City is given in the Table 5.1.

Figure 5.1: Sensor mount on Honda City

The Volkswagen Golf is installed with two sensors. One of the sensors is mounted on the left side of the power steering as shown in the Figure 5.2. The second sensor is mounted on the right wheel column as shown in the Figure 5.3. The orientation of the sensors mounted on the Volkswagen Golf is given in the Table 5.1.

61

Figure 5.2: Sensor mount on Golf Steering

Figure 5.3: Sensor mount on Golf wheel

Alignment in Honda City

Alignment in Golf (Steering)

Alignment in Golf (Wheel)

Corresponds to The vehicle

Z-Axis X-Axis X-Axis Longitude (pos.=right, neg.=left)

Y-Axis Y-Axis Y-Axis Direction(pos.=accelerate, neg.=decelerate)

X-Axis Z-Axis Z-Axis Vertical Axis(pos.=increase, neg.=fall)

Table 5.1: Mounting location of the sensor

5.2. Evaluation of the data with Matlab

The evaluation of the data measured on the data logger is done with Matlab. For each data collected on the data logger there is a custom Matlab script which is used to analyze the data.

62

5.2.1. Evaluation of EMC files

The evaluation of the EMC files recorded on the data logger is done using the Matlab script under the name “EMC_Evaluation.m”. After running the script on the Matlab, one or many number of desired EMC files is selected from the file browser. After running the script, the plots for each individual measurement is created as an image under the folder “EMC” in the directory from where the files were selected. In addition, the total distance traveled over the period of time is determined and the output is displayed on the Matlab console. The different plots are presented on the basis of series of measurements with the Volkswagen Golf over a period of four weeks.

The plot for the RMS value of the acceleration occurring on the 3 axes over a period of two weeks is shown in the Figure 5.4.

Figure 5.4: Relative RMS value of the acceleration

The plot for the maximum value of acceleration occurring on the 3 axes at the position of the installation of the sensor is shown in the Figure 5.5. The period where the vehicle is idle is also shown on the plot.

63

Figure 5.5: Relative maximum acceleration

The plotting of the mean of the acceleration on the 3 axes is shown in the Figure 5.6. The plot shows the acceleration of the speed, the deceleration of the vehicles and the lateral accelerations that occur when driving in the curves.

Figure 5.6: Mean values of acceleration

The plot of the analog voltage corresponding to the battery voltage is shown in the Figure 5.7.

64

Figure 5.7: Analog voltages

In addition, the speed of the vehicle acquired from the GPS is also plotted in the Matlab script but it is not listed here since the speed is also plotted from the data acquired from the OBD.

To derive the information about the road conditions, the data over the GPS position is presented here. In order to implement this, the coordinates are presented in the two-dimensional representation by the Mercator Projection [33]. According to the equation 5.1, the longitude is converted into the normalized coordinate, where describes the center of the map. The normalized coordinate is calculated according to the equation 5.2 from the latitude . The values for the two-dimensional map are obtained by multiplying the radius of the earth.

(5.1)

(5.2)

This representation of the maps is used by Google maps, OpenStreetMap [34] and several others. It is possible to store the results of the measured data with such maps. For the data measured from the data logger with the Volkswagen Golf, the distance travelled is defined on the map from OpenStreetMap as shown in the Figure 5.8. Through this, the precise position of the travel is assigned on the map.

65

Figure 5.8: Overview of the trip [34]

The RMS value over the GPS position is shown in the Figure 5.9. In this plot, the RMS value consists of the quadratic mean of all the 3 axes. It is possible to easily spot the high RMS value over the GPS position.

Figure 5.9: RMS over GPS

66

The maximum value of the acceleration on the GPS position is shown in the Figure 5.10. This is used for detecting the shock events occurring over the map. The maximum value consists of the quadratic mean of all the 3 axes.

Figure 5.10: Maximum value over GPS

The representation of the mean of all 3 axes allows assigning the acceleration in the longitudinal direction, direction of the travel and the vertical axis of the driven route. The mean value plotted in the longitudinal direction is as shown in the Figure 5.11. The mean value in the direction of travel is as shown in the Figure 5.12. The mean value in the vertical axis is as shown in the Figure 5.13. The blue area corresponds to the deceleration of the vehicle and the red area corresponds to the acceleration of the vehicle. These areas are clearly visible in the figures.

The crest factor described in the chapter 2.2.4 is another way of representing the shock occurring on the map. The crest factor shown in the Figure 5.14 is highlighted with a high maximum value to the low RMS value.

Since the number of measurement data can be very high and the available memory for the evaluation on the computer is limited, there is a possibility using the function “reduction.m” on the Matlab to reduce the measured values. The data reduction is done for “N” values and can be changed if necessary in the function “reduction.m”. If the reduction is not required, then the “data_reduction” parameter is set to 1 in the “EMC_Evaluation.m” script.

67

Figure 5.11: Mean value of X-Axis over GPS

Figure 5.12: Mean value of Y-Axis over GPS

68

Figure 5.13: Mean value of Z-Axis over GPS

Figure 5.14: Crest factor over GPS

69

5.2.2. Evaluation of OBD files

The evaluation of the OBD files measured on the data logger is done using the Matlab script under the name “OBD_Evaluation.m”. After running the script on the Matlab, one or many number of desired OBD files is selected from the file browser. After running the script, the plots for each individual measurement is created as an image under the folder “OBD” in the directory from where the files were selected. In addition, the total distance traveled over the period of time is determined and the output is displayed on the Matlab console. The different plots are presented on the basis of series of measurements with the Volkswagen Golf over a period of four weeks.

For the data measured from the data logger with the Volkswagen Golf, the distance travelled is defined on the map from OpenStreetMap and the precise position of the travel is assigned on the map as presented in the previous chapter.

The plot for the RPM values over the GPS position for the period of two weeks is shown in the Figure 5.15. It is clearly visible on the map where the high RPM and low RPM were used.

Figure 5.15: RPM over GPS

The representation of the speed over the GPS position is shown in the Figure 5.16. From this plot, it is possible to map the highways, country roads and traffic areas with speed limits.

The plotting of the engine load over the GPS position is shown in the Figure 5.17. It is possible to detect the position where the high mechanical power was used, for example, driving in the up-hill. This can be seen on the plot.

70

The Matlab script also plots the coolant temperature over the GPS position. It is not listed here but it is listed in the Appendix.

Figure 5.16: Speed over GPS

Figure 5.17: Absolute load over GPS

71

5.2.3. Evaluation of RFM files

The evaluation of the RFM files collected on the data logger is done with the help of the Matlab script under the name “RFM_Evaluation.m”. This script creates the linear and logarithmic Rainflow matrices in the “Min to Max” and “Average Load-cycle” form. The load-cycle is represented as the frequency distribution and cumulative frequency on the distance travelled.

The individual matrices and distributions are presented by the means of a series of measurements with the Volkswagen Golf over a period of four weeks. Only the measurements on the Y-Axis are presented here which corresponds to the direction of travel of the vehicle.

The classic form of the rainflow matrix is shown in the Figure 5.18. Due to the high incidence of small strokes in the area [0 0], the informational representation of this form is not easy. Hence, the same matrix is represented in the logarithmic form as shown in the Figure 5.19.

Figure 5.18: Rainflow matrix in Min-Max form

In the logarithmic form shown in the Figure 5.19, the distribution of the individual points can be seen well. For this reason, the logarithmic representation is usually chosen in this work since the information content is in the distribution of colors and the classic form of rainflow matrix is not so.

72

Figure 5.19: Rainflow matrix in logarithmic Min-Max form

Another form of logarithmic representation is shown in the Figure 5.20. It is a good representation of the fading away of the vibrations from the centre to the outside in the three-dimensional representation.

Figure 5.20: Rainflow matrix in 3D logarithmic Min-Max form

73

The representation of the “Average Load-Cycle” form, as shown in the Figure 5.21, shows the actual acceleration strokes. These are not read directly from the “Min to Max” form. The offset to the centre may also need to be recognized. This would be the case for example with the Z-Axis since this is subject to the acceleration due to gravity.

Figure 5.21: Rainflow matrix in logarithmic Average-Load cycle form

The three-dimensional representation of the “Average Load-Cycle” shown in Figure 5.22 shows the decline of the load cycle with increasing intensity. A rise or increase can be seen better here.

Figure 5.22: Rainflow matrix in 3D logarithmic Average-Load cycle form

74

The frequency distribution of the individual load cycle is shown in Figure 5.23. The information on the average load cycle cannot be seen in this presentation. Nevertheless, this histogram is important because the overall distribution of the cycles is shown.

Figure 5.23: Frequency distribution of Y Axis

By accumulating the load-cycles, it is possible to get the cumulative frequency distribution. In the Figure 5.24, the cumulative load-cycles for a distance over 928 km is shown for the direction of the travel with the Volkswagen Golf.

Figure 5.24: Cumulative load cycle of X Axis

75

5.2.4. Evaluation of RAW files

The evaluation of the RAW files measured on the data logger is done using the Matlab script under the name “RAW_Evaluation.m”. After running the script on the Matlab, one or many number of desired RAW files is selected from the file browser. After running the script, the time signal with all 3 axes is represented in a plot-window in which, with the help of the cursor, the beginning and the end of the area to be analyzed is selected. After the selection, images of the time signal, a spectrogram of the acceleration density over time and the effective acceleration density for all 3 axes are generated under the folder “RAW” in the directory from where the files were selected. Furthermore, the effective acceleration density of all 3 axes is generated. This is also based on the series of measurements with the Volkswagen Golf.

5.3. Comparison of measurements from two vehicles

In order to compare the measurements of two vehicles, the data from the data loggers used in the Honda City in India and the Volkswagen Golf is presented here. In the Volkswagen Golf, the data from the sensor on the steering ECU is used for the comparison since the sensor in the Honda City was mounted on the steering ECU. The overview of the trips travelled during the measurement of both is vehicles are given in the pictures. The Figure 5.25 shows the overview of the trip with Volkswagen Golf and the Figure 5.26 shows the overview of the trips with Honda City in India.

Figure 5.25: Overview of the trip with Golf

76

Figure 5.26: Overview of the trip with Honda

The RMS value with the respective position of the vehicle during the trips presented above is shown in the Figure 5.27 for the Volkswagen Golf and in the Figure 5.28 for the Honda City. It is easy to distinguish the sections of highway since the RMS value of the acceleration in comparison to the remaining roads is relatively high. This is clearly visible on the routes of both the vehicles. Since in Bangalore, the traffic is more it is visible with the high RMS value where the traffic was less. The sections with high RMS values are marked with red. It also includes the driving through the potholes and expansion joints of the bridges.

Figure 5.27: RMS over GPS with Golf

77

Figure 5.28: RMS over GPS with Honda

Another important parameter is the mean value of the effective acceleration while the vehicle is in motion. Through that, the statement about the occurred vibrations throughout the test run can be made. The mean values of the effective acceleration for the trips shown in the Figure 5.25 and Figure 5.26 is shown in the Table 5.3. The axes are grouped together according to the mounting position of the sensors on both the vehicles.

Orientation Vehicle Axis RMS acceleration Longitude Honda Z-Axis 1.0635 m/s2

Golf X-Axis 1.0843 m/s2 Direction of travel Honda Y-Axis 0.9943 m/s2

Golf Y-Axis 0.9803 m/s2 Vertical axis Honda X-Axis 1.3313 m/s2

Golf Z-Axis 1.3012 m/s2

Table 5.2: Average RMS acceleration of the trips

The comparison shows that the Honda City has a larger mean of the effective acceleration with respect to the direction of travel and the vertical axis. The Volkswagen has a higher value in the longitudinal direction.

In order to make the further statements, the “Average Load-cycle” representation of the rainflow counting from both the vehicles is considered.

The rainflow countings of the Honda City and the Volkswagen Golf in the longitudinal direction is shown in the Figure 5.29 and Figure 5.30 respectively. It can be seen that

78

rainflow counting with the Honda City has more load cycles compared to the Volkswagen Golf. The load cycles in the Honda City were counted up to 95 . In comparison, the Volkswagen Golf has less load cycles that of the Honda City. This shows that the average load cycle for this axis on the Honda City is higher suggesting that the vibrations are higher.

Figure 5.29: Rainflow matrix in longitudinal direction with Honda

Figure 5.30: Rainflow matrix in longitudinal direction with Golf

79

The rainflow counting in the direction of travel for the Honda City and Volkswagen Golf is shown in Figure 5.31 and Figure 5.32 respectively. The load cycles in the Volkswagen Golf are larger. The distribution around the mean is more, which is due to the deceleration and acceleration of the vehicle. The Honda City has less load cycles in this direction and the comparison of the average load cycles suggests that the Honda City has a lower burden.

Figure 5.31: Rainflow matrix in direction of travel with Honda

Figure 5.32: Rainflow matrix in direction of travel with Golf

80

The rainflow counting in the vertical axis is shown in the Figure 5.33 for Honda City and in Figure 5.34 for Volkswagen Golf. This is the acceleration due to gravity and the vertical axis is subject to it and hence the values are not distributed around zero but 9.81 . The load cycles of the Honda City are less than the Volkswagen Golf. In contrast, the average effective acceleration of the Honda City with 1.3313 is larger than the Volkswagen Golf with 1.3012 . By this comparison, it can be derived that the Honda City has high stress due to low load cycles. However, in Volkswagen Golf have higher accelerations with lower frequency.

Figure 5.33: Rainflow matrix in vertical axis with Honda

Figure 5.34: Rainflow matrix in vertical axis with Golf

81

For the rainflow counting evaluation, it is always important to take the distance travelled into consideration. The distance travelled by the two test vehicles in the comparisons made are not the same. In order to assess the test runs regardless of the distance travelled, the comparison is made for a distance of 300000km. This is comparison is shown in the Figure 5.35 for Honda City and in Figure 5.36 for Volkswagen Golf. With this conversion to the common distance travelled, it is easy to make the comparison.

Figure 5.35: Cumulative load cycle for Honda

Figure 5.36: Cumulative load cycle for Golf

82

In this comparison, it can be seen that the load cycles on the Volkswagen Golf is more on all the 3 axes. With the Honda City, the amount of load cycles is smaller but with higher frequency. Considering the “LV124” standard, in which the test period of 8 hours is shown in the picture, it can be said that the Volkswagen Golf in the direction of travel is more load cycles. The load cycles of Honda City is less comparatively, however the low-load cycles of both the vehicles lies outside “LV124”. It is important to note that even the slightest load on the sensors corresponds to a high proportion of load cycles. Also, fatigue strength can be assumed under the mechanical aspects of those load cycles. Considering these two points, the low load cycles outside the “LV124” can be neglected. However, the high load cycles could lead to the premature failure of the control units.

83

84

6. Conclusion

In this master thesis, the work on the development of the embedded hardware for the measurement of the vibration data along with the OBD data and the GPS data is presented. The mounting location on the vehicle chosen for the measurement of the vibration data are the electric steering and the right wheel axis column. Two vehicles are used for testing, one in India and the other in Germany.

The collected loads are presented in two ways. Firstly, the RMS values of the acceleration, maximum value and the mean value are stored cyclically along with the GPS position, speed and time. Thus the mapping and determining of the effective acceleration is possible as shown in the chapter 5.

For the determination of the load cycle occurring which corresponds to the standard LV124 given in Table 2.1, the load cycles are measured by the rainflow counting method in the data logger and entered in a RFM. This results in a significant reduction in the data. By the representation of the cumulative load cycle with a common mileage, it is possible to make the comparison of the measurements of several vehicles.

The data logger also collects the OBD data such as RPM, speed, calculated engine value along with the GPS position and time. The mapping of the OBD data along with their respective position is presented in the chapter 5.

The data logger built in the framework of this thesis, has a LCD which displays the measurement values from the sensor, OBD, GPS position, analog voltages, date and time along with the name of the fi le to which the data is being written. The logger is operated with the switches and button provided on the housing. The data is stored on the USB stick in the “RAW” format and the algorithms described in the chapter 4.1.5.

The acceleration sensor used for the measurement in this work is described in the chapter 4.4.2. The current structure of the logger allows the reading and analyzing of the sensor with 3 axes. More sensors can be implemented by making the adjustments with the code.

85

References

[1]. Sun Xiangwen, “Entwicklung und Integration von User-Code zur Realisierung von Diagnosediensten auf dem TTX Datalogger“, Technische Universität Chemnitz, Master Thesis, 2014.

[2]. Buxbaum, O.: “Betriebsfestigkeit, sichere und wirtschaftliche Bemessung

schwingbruchgefährdeter Bauteile . Stahleisen-Verlag”, Düsseldorf, 2. Auflage, 1992.

[3]. Holger Neubert, “Evaluierung von Algorithmen zur Erhöhung der

Systemrobustheit“, Technische Universität Chemnitz, Master Thesis, 2010. [4]. Prof. Dr.-inz Piotr Szulc: “ Fundamentals of mechanics and strength of

materials”, Wrocław University of Technlogy, 2010. [5]. Dowling, M.E.: “Fatigue fai lure predictions for complicated stress -strain-

histories. J. of Mats.”, John Marshall Law School - Atlanta, 1972. [6]. Kurt Magnus, Karl Popp, Walter Sextro: Schwingungen, Physikalische

Grundlagen und mathematische Behandlung von Schwingungen. Springer-Verlag, Berlin Heidelberg, 9. Auflage, 2013.

[7]. IEC 6000068-2-64: Environmental testing - Part 2-64: Tests - Test Fh:

Vibration, broadband random and guidance [8]. Michael Schlecht, “Felddatenerfassung hinsichtlich Vibration und Schock als

Belastung elektronischer Steuergeräte im Automobil“, Hochschule Reutlingen, Master Thesis, Februar 2014.

[9]. Helmut Jäger , Roland Mastel, Manfred Knaebel: “Technische

Schwingungslehre, Grundlagen - Modellbildung – Anwendungen“. Springer Vieweg, Wiesbaden, 8. Auflage, 2013.

[10]. NPTEL, “Design of Machine Elements“, IIT Kharagpur, 2012. [11]. Cartwright, Kenneth V, “Determining the Effective or RMS Voltage of various

Waveforms without Calculus”, Technology Interface, fall 2007. [12]. Smith, Steven W, “The Scientist and Engineer’s Guide to Digital Signal

Processing”, San Diego, California, 1999. [13]. Brigham, E. Oran, “The fast Fourier transform and its applications”, Englewood

Cliffs, N.J, 1988. [14]. Oppenheim, Alan V., Ronald W. Schafer, and John R. Buck, “Discrete-Time

Signal Processing”, Upper Saddle River, NJ, 1999.

86

[15]. Wiliam H. Press, Saul A. Teukolsky, Wiliam T. Vettering, Brain P. Flannery: “Numerical Recipes in C - The Art of Scientific Computing”, Second Edition. Camebridge University Press, Camebridge, 1999.

[16]. Lalanne, C., “Mechanical Vibration and Shock Analysis, volume 3: Random Vibration”, Second Edition, ISTE - Wiley, 2009.

[17]. Matsuishi M., Endo T.: “Fatigue of metals subjected to varying stress”, Japan Soc. Mech. Engineering, Fukuoka, Japan, 1968.

[18]. Birnbaum, Ralph and Truglia, Jerry, “Getting to Know OBD II.”, New York, 2000.

[19]. SAE International, “On-Board Diagnostics for Light and Medium Duty Vehicles Standards Manual”, Pennsylvania, 2003.

[20]. LV124: Electrical and electronic components in motor vehicles up to 3.5 t - General requirements, tests and test conditions: Added: 15.10.2009

[21]. http://www.element14.com Element14 is a distributor of technology products and solutions. Last visit: 12/2014

[22]. http://www.raspberrypi.org

Project site for Raspberry Pi Last visit: 12/2014

[23]. http://www.st.com

ST is a manufacturer of microprocessors and sensors. Last visit: 12/2014

[24]. http://www.elv.com

ELV is a manufacturer of electronic components. Last visit: 12/2014

[25]. https://www.sparkfun.com

Sparkfun is a manufacturer of electronic components. Last visit: 12/2014

[26]. http://www.arduinodev.com

Arduinodev is a manufacturer of electronic components. Last visit: 12/2014

[27]. https://launchpad.net/gcc-arm-embedded

Open source compiler for ARM processors Last visit: 12/2014

[28]. http://mikrocontroller.bplaced.net/wordpress

Source code "C" libraries and examples of ATMega and STM32F4 CPUs Last visit: 12/2014

87

[29]. http://www.elmelectronics.com

Manufacturers of the ELM microprocessors Last visit: 12/2014

[30]. http://www.seeedstudio.com/depot

Seed Studio is a distributor of prototype boards and Shields Last visit: 12/2014

[31]. http://www.u-blox.com

U-blox is a manufacturer of communications and positioning modules Last visit: 12/2014

[32]. http://www.nmea.de NMEA website with NMEA standards Last visit: 12/2014

[33]. http://mathworld.wolfram.com/MercatorProjection.html Wolfram MathWorld is a website for basic Mathematical functions Last visit: 12/2014

[34]. http://www.openstreetmap.org OpenStreetMap is a free source for maps Last visit: 12/2014

[35]. http://www.arduino.cc

Arduino is a manufacturer of the microcontroller boards Last visit: 12/2014

[36]. http://www.coocox.org/index.html CooCox is an open source development environment for ARM Cortex MCU Last visit: 12/2014

88

Appendix Notations

ADC Analog-Digital Convertor ASIC Application Specific Integrated Circuit AT Commands used to communicate with ELM devices

CAN Controller Area Network DFT Discrete Fourier Transform DMA Direct Memory Access ELM Diagnostic device to communicate with vehicle OBD FFT Fast Fourier Transform FPU Floating Point Unit FT Fourier Transform I2C Inter-Integrated Circuit

MEMS Micro-Electro-Mechanical Systems OBD On-Board Diagnostics PSD Power Spectra Density RAW Raw data RFM Rainflow Matrix RMS Root-Mean Square

RS232 Serial Interface RTC Real-Time Clock RX Receiver SPI Serial Peripheral Interface TX Transmitter

USART Universal Asynchronous Receiver Transmitter USB Universal Serial Bus