Tunisian Republic

Ministry of Higher Education and Scientific Research

General Directorate of Technological Studies

Higher Institute of Technological Studies of Bizerte

Electrical Engineering Department

G RADUATION P ROJECT
for the degree of

S ENIOR T ECHNICIAN IN E LECTRICAL E NGINEERING

prepared by
Khamassi H IBA
Sadkaoui A SMA

Title of the project:

Development of an e–Service
platform for automotive

Presented on 26 June 2018 in Bizerte in front of the exam jury:

President: M RS B OULEHMI H ELA

Reviewer: M R M ABROUK I SSAM

Examiner: M RS B EN C HEHIDA S ONIA

Advisor: M R M HAMDI A BDELBACET

Co–advisor: M R N AKACH M ARWEN
 Pretty women wonder where my secret lies.
I’m not cute or built to suit a fashion model’s size
But when I start to tell them,
They think I’m telling lies.
I say,
It’s in the reach of my arms,
The span of my hips,
The stride of my step,
The curl of my lips.
I’m a woman
Phenomenally.
Phenomenal woman,
That’s me.
Maya Angelou
 Acknowledgements

The present document, would not have been possible without the help, encourage-
ments and support of many persons. We thank all of them and we present them all
our gratitude.
Special thanks are due to our advisor, Mr Mhamdi Abdelbacet, who initiated this
work and who trusted us by giving us the opportunity to perform it. His help, insight
and encouragements were never missing. He gave us the keys to organise the work
in an efficient, accurate, creative and autonomous way.
We wish to extend our sincere gratitude to Mrs Boulehmi Hela, who have accepted to
chair the examination board. We also like to warmly thank our reviewer Mr Mabrouk
Issam, special mention goes to Mrs Ben Chehida Sonia for being our examiner.
Finally we thank our parents whose presence and encouragements were never miss-
ing. We are extremely grateful to them.
 Glossary

ABS Anti Braking System

ACU Airbag Control Unit
BCU Body Control Unit
CF Constraint Function
CAN Controller Area Network
DLC Diagnostic Link Connector
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
EBCM Electronic Brake Control Module
EGR Exhaust Gas Recirculation
ECU Engine Control Unit
GM General Motors
HTTP HyperText Transfer Protocol
IC Integrated Circuit
MIL Malfunction Indicator Lamp
MAF Mass Air Flow
MF Main Function
OBD On Board Diagnostic
PCM Power–train Control Module
RAM Random Access Memory
ROM Read Only Memory
URL Uniform Resource Locator

i
 Contents

General Introduction 1

1 Presentation of The Project Framework 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Firm presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Firm profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Firm services . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Automotive functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Automotive electronics . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Project charters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.2 External functional analysis . . . . . . . . . . . . . . . . . . . 14
1.5.3 Teleservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Project specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6.1 Project objective . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6.2 Project tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Theoretical Framework 19
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 CAN history . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 CAN frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.3 Message–based communication . . . . . . . . . . . . . . . . . 22
2.3 On–board diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iii
iv Contents

2.3.2 OBD–II system . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.3 OBD–II pinout . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Diagnostic trouble code . . . . . . . . . . . . . . . . . . . . . 25
2.4 CAN bus reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Dual waveform visualization . . . . . . . . . . . . . . . . . . 28
2.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6.1 Boards assembly . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6.2 DB9 to OBD–II connections . . . . . . . . . . . . . . . . . . . 34
2.6.3 Practical assembly . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7.1 Software overview . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7.2 Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . 36
2.7.3 Read Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7.4 Write Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Monitoring and Validation Results 41

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 System preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3 LabVIEW VIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 Front panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2 Block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Serial monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.2 LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.2 Programmer interface . . . . . . . . . . . . . . . . . . . . . . 48
3.6 Waveforms simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.2 Programmer interface . . . . . . . . . . . . . . . . . . . . . . 51
3.7 Virtual dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.7.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.7.2 Programmer interface . . . . . . . . . . . . . . . . . . . . . . 53
3.8 Running the program . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.2 Experimental results . . . . . . . . . . . . . . . . . . . . . . . 54
3.9 Control and visualization . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.9.1 Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.9.2 Web publishing tool . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.3 Web browser output . . . . . . . . . . . . . . . . . . . . . . . 58
Contents v

3.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

General Conclusion 61

Bibliography 63
 List of Figures

1.1 360 Auto garage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Electronic subsystems in a vehicle. . . . . . . . . . . . . . . . . . . . 6
1.3 Mercedes E–class 1985 vs 2018. . . . . . . . . . . . . . . . . . . . . . 7
1.4 EBC–1000 series embedded single board computer[201c]. . . . . . . 7
1.5 Electronic control unit architecture . . . . . . . . . . . . . . . . . . . 9
1.6 Engine electronic control unit[Pan]. . . . . . . . . . . . . . . . . . . . 10
1.7 Sensor and actuator block diagram[Pid]. . . . . . . . . . . . . . . . . 11
1.8 Samples of some sensors. . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Samples of some actuators. . . . . . . . . . . . . . . . . . . . . . . . 12
1.10 Car dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.11 Horned beast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.12 Octopus diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.13 The connected car concept. . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Before CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 After CAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Base frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Extended frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 CAN bus data transmission[ELE18]. . . . . . . . . . . . . . . . . . . . 22
2.6 OBD time–line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7 Diagnostic link connector. . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 CAN High. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 CAN High waveform. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10 CAN Low. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.11 CAN Low waveform. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.12 CAN High and CAN Low waveform. . . . . . . . . . . . . . . . . . . . 28
2.13 Block diagram of the system. . . . . . . . . . . . . . . . . . . . . . . 30
2.14 CAN-bus shield. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.15 Arduino UNO R3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

vii
viii List of Figures

2.16 DB9 to OBD–II adapter cable. . . . . . . . . . . . . . . . . . . . . . . 33

2.17 Boards connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.18 Ports connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.19 Practical assembly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.20 Arduino software flowchart. . . . . . . . . . . . . . . . . . . . . . . . 36
2.21 Screenshot of the MCP2515 initilization. . . . . . . . . . . . . . . . . 37
2.22 Data reading flowchart. . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.23 Data writing flowchart. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 System preview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Arduino IDE serial monitor. . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 LabVIEW serial monitor. . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Serial reading block diagram . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Screen–shot of the authentication front panel. . . . . . . . . . . . . . 47
3.6 Access interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7 Access block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.8 Access Sub VI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9 VIs link block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10 Main VI front panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.11 Main VI block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.12 Virtual dashboard VI front panel. . . . . . . . . . . . . . . . . . . . . 52
3.13 Main VI block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14 Execution flowchart. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15 Serial monitor simulation. . . . . . . . . . . . . . . . . . . . . . . . . 55
3.16 Main VI simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.17 Virtual dashboard VI simulation. . . . . . . . . . . . . . . . . . . . . 56
3.18 Screen–shot of web server configuration. . . . . . . . . . . . . . . . . 56
3.19 Screen–shot of configuring visible VIs and browser access list. . . . . 57
3.20 Screen–shot of the web publishing tool. . . . . . . . . . . . . . . . . 58
3.21 Screenshot of the car parameters control system on web. . . . . . . . 58
 List of Tables

1.1 Mulfunction Indicator Lights. . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Service functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 OBD–II pinout [201e]. . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 CAN High and Low specifications. . . . . . . . . . . . . . . . . . . . . 27
2.3 Arduino boards comparison chart [Ahm17]. . . . . . . . . . . . . . . 32

3.1 Components of a block diagram. . . . . . . . . . . . . . . . . . . . . 43

ix
 General Introduction

Context and motivations

In the last decades, technology has affected many different aspects of our lives with
the aim to bring more comfort and ease of performing everyday tasks.
Vehicles have become increasingly more software driven and at the same time in-
dependent. When it comes to connecting drivers and technology, the auto industry
has a longer and richer track record than any other sector by offering a series of
improvements aimed not only at safer driving but also at improving the driving
experience overall. For instance, cars went from having steam powered engines to
gasoline engines and now it is more common to see electrical powered engines. Not
long ago, cars were completely mechanical systems that consisted of only mechanical
components and some electrical units connected by wires. One of the most impor-
tant changes was the introduction of the Electronic Control Units, which are small
embedded systems. The in-vehicle network of a modern car consists of more than
a hundred ECUs that control almost every functionality of the car, including safety
critical functions, such as acceleration, braking and steering. In order to provide new
features in safety, the On Board Diagnostic was introduced. It enables communication
with its internal system such as the Controller Area Network. Through this connection
it is possible to run diagnostic tests which have always been something reserved to
the specialized repair shops using custom tools and specific methods [Cho94].

Purpose and work strategy

Every automobile is equipped with an electrical instrumentation panel that is used as a
driver information center, formerly known as a dashboard. It contains various gauges
and indicators that provide valuable informations to the driver. Gauges provide scaled
indication of the system condition such as distance, engine speed, vehicle speed, and
fuel level. Whereas, the indicator lights supply information of something is being
turned on or warn the driver about system malfunctioning problems. However, the

1
2 General Introduction

driver don’t pay attention to these malfunction light indicators. It is under this status
that we take initiative into a research project that aims to assure and enhance the
car–to–driver communication by studying how e–service can eliminate the need to
be in the proximity of a car to perform diagnostics. By monitoring all the car aspects,
it is easier to detect any problem in advance by sending all sensor readings to the
maintenance garage where technicians and engineers will apply their expertise to
find and predict imminent failures of key systems integrated in the vehicle.

Outline
The present dissertation is divided into three chapters, organized as follows:

Chapter 1 is essentially devoted to the project framework. The first part concerns
the host company presentation and its services. The second one is reserved
for the description of the automotive field, more specifically its evolution and
electronics.

Chapter 2 is dedicated to the theoretical framework. It represents the used hardware

and software components for the achievement of our work.

Chapter 3 is mainly reserved to the project execution. It contains a full description

of the software design using LabVIEW.
 CHAPTER 1
Presentation of The Project
Framework

Contents

1.1 Introduction . . . . . . . . . 4 1.5.1 Problem statement . . 13

1.2 Firm presentation . . . . . . 4 1.5.2 External functional
1.2.1 Firm profile . . . . . . . 4 analysis . . . . . . . . . 14
1.2.2 Firm services . . . . . . 4 1.5.3 Teleservice . . . . . . 16
1.3 Automotive functions . . . . 5 1.6 Project specifications . . . . 17
1.4 Automotive electronics . . . 6 1.6.1 Project objective . . . . 17
1.4.1 Evolution . . . . . . . 6 1.6.2 Project tasks . . . . . . 17
1.4.2 Architecture . . . . . . 8 1.6.3 Methodology . . . . . 18
1.5 Project charters . . . . . . . 12 1.7 Conclusion . . . . . . . . . . 18

3
4 Chapter 1. Presentation of The Project Framework

1.1 Introduction
This chapter is reserved to present the project framework. The STIMM company and
its associated services are described, at first. Then, we define the automotive functions
and electronics. State of the art and eventually the problematic are exhibited at last.

1.2 Firm presentation

This section is dedicated to the firm presentation profile and services.

1.2.1 Firm profile

Garage 360 Auto is a modern auto repair shop, see Fig. 1.1 that is dedicated to
provide quality services at affordable prices. It is strategically located in Ghazela
Tunis. Since its humble beginnings, the garage have had a tremendous growth rate
due to its reliability and well hearted ambitions. Most of all, it have been able to
provide a comfortable and fulfilling services to all his esteemed clients.

Figure 1.1: 360 Auto garage.

1.2.2 Firm services

Oil Change

Oil maintains as long as possible the life span of the car engine. It reduces friction,
wear, provides lubrication, acts as a seal between the pistons, rings and the cylinder
walls while helping to cool the engine parts. To avoid severe engine damage, this
service should be regularly scheduled after a well determined Mileage.

Maintenance

This may be one of the most demanded service from the average person to take care
for his or her own vehicle. Experts at 360 auto fulfill these needs by installing new
1.3. Automotive functions 5

parts if ever required and doing all kinds of repairs, for instance:

• Engine

• Radiator

• Brakes

• Steering

• Wheel alignment

• Suspension

• Battery, starting and charging.

Air conditioner performance check

When temperatures rise, there’s nothing more refreshing than climbing into a cool,
air–conditioned car. Over time, however, A/C fittings become loose. O-rings, hoses
and seals wear. In case of malfunction, the garage offers the best possible repair.

Diagnostic

Diagnostic tests can reveal problems within a car:

• Engine

• Transmission

• Exhaust system

• Brakes.

As well as performance issues with:

• The fuel injector

• Air flow and coolant

• Ignition coils

• Throttle.

1.3 Automotive functions

A car is a complex machine with several systems functioning simultaneously. Fig. 1.2
illustrates the distributed electronic functions coordinating the vehicle subsystems.
These various functions are often categorized into domains such us:

• The power train domain: control of engine and transmission

• The chassis domain: control of steering, braking, and suspension

6 Chapter 1. Presentation of The Project Framework

• The safety domain: collision warning and mitigation systems

• The body domain: control of door locking and unlocking, interior and exterior
lighting, windshield washing, wiping, and air conditioning

• Infotainment domain: the combination of information and entertainment, it

includes radios and video entertainment systems

• Telematics domain: the combination of telecommunications and computing

such as GM’s OnStar system that provides various navigation, concierge, and
emergency services [Den04].

Figure 1.2: Electronic subsystems in a vehicle.

1.4 Automotive electronics

This section is dedicated to present an exhaustive know–how of the automotive world
and more specifically the electronics behind. We define here the phenomenal growth
of this field as well as the common architecture.

1.4.1 Evolution
Autombiles have come a long way since their beginning in the late 19th century.
Fig. 1.3 compares two models of the Mercedes E–class from 1985 and 2018. One of
the major things that have helped automobiles to provide more safety and conve-
nience, though, is electronics. With the advances in technology and electronics, car
manufacturers have been able to offer a wide variety of services and conveniences
that many new automobile owners appreciate. The field of computer diagnosis
has also helped to shape the way that automobile owners use their cars. The cars
manufactured in the last couple decades have been built with an on-board computer
to help owners easily perceive every engine problems or other problems before any
damage is done. Before the computer diagnosis technology, most car owners did
1.4. Automotive electronics 7

not know something was wrong with the engine until something drastic happened,
such as overheating or running out of gas. Mechanics generally had to endure a
trial–and–error method to find out what was the problem in many cases.

Figure 1.3: Mercedes E–class 1985 vs 2018.

Now, however, modern cars computers, as shown in Fig. 1.4, constantly check the
engine and its components to make sure it is always up to its optimum performance.
It uses many sensors to detect temperature, fluid levels and many other aspects of an
engine’s performance. Many times, the computers in the car will provide a code that
mechanics can read so they know exactly what has malfunctioned.

Figure 1.4: EBC–1000 series embedded single board computer[201c].

The equipment used can be attached to the car and help find out the reason for the
malfunction [Gre15]. It does require however:

• Very expensive equipments, such as oscilloscopes, a digital volt–ohm meter,

8 Chapter 1. Presentation of The Project Framework

sensor stimulator’s and high–tech computers to determine problems

• Extensive knowledge about how to use the technology.

1.4.2 Architecture
Automotive systems consist of mechanical, hydraulic, software and hardware compo-
nents that implement specific vehicle functions. Such architecture have distributed
control and information systems implemented in multiple Electronic Control Units
(ECUs) interconnected by serial communication buses, together with sensors and ac-
tuators locally connected to the Input/Output ports of the ECUs or to sensor/actuator
buses, as indicated in Fig. 1.5 [Uff11].
 1. Engine Management ECU

1 2 3 7 2. Transmission ECU
8
3. Anti-Lock Braking ECU
CAN-bus
4. Traction Control ECU

5. Airbag ECU

9
6. Power Steering ECU

4 5 6 7. On-Board Diagnostic(OBD) Connector

8. Controller Area Network(CAN bus)

Figure 1.5: Electronic control unit architecture

10 Chapter 1. Presentation of The Project Framework

Electronic control unit

ECU is the electronic control unit. This refers to an on-board system controlling one
or more systems or subsystems in a motor vehicle. The ECU often consists of an 8-bit
microprocessor, random access memory (RAM), read only memory (ROM), and an
input/output interface as demonstrated in Fig. 1.6.
They look a lot like a computer hard drive. There are different types of ECUs
implanted in several parts of a car:
• Airbag Control Unit (ACU)

• Body Control Unit (BCU): controls the closing of doors, power windows, interior
lights

• Engine Control Unit (ECU): not to be confused with electronic control unit

• Electronic Brake Control Module (EBCM)

• Power–train Control Module (PCM).

The number of ECUs can vary between old cars and modern ones that can have over
100 Electronic Control Unit [Cho94].

Injection Engine
driver IC Injection
Switch
Switch monitor
IC
MCU

Solenoid
high-side
driver IC
Relay

Sensor Integrated
power IC Solenoid
Multi Low-side
for LAN Power IC driver IC
Relay
Other ECUs

Input Output

Figure 1.6: Engine electronic control unit[Pan].

Sensors and actuators

In any control system application, sensors and actuators are in many cases the
critical components for determining system performance. This is especially true for
automotive control system applications. The availability of appropriate sensors and
actuators dictates the design of the control system and the type of function it can
perform. Fig. 1.7 illustrates the data transmitting process[Rib02].
1.4. Automotive electronics 11

Error
Set point + Control
- calculations

Sensor Actuator
measurement Output

System

Figure 1.7: Sensor and actuator block diagram[Pid].

Sensors

A sensor is a gauge used to register specific physical characteristics and convert them
to an electronic signal. It is the interface between the monitored component and the
control system. Fig. 1.7 shows two types of sensors that can be found in a vehicle.
Among them many others, we can mention:

• Throttle position sensor

• Manifold absolute pressure sensor see Fig. 1.8a

• Engine coolant temperature sensor

• Mass air flow sensor see Fig. 1.8b

• Crankshaft position sensor

• Camshaft position sensor

• Detonation sensor

• Oxygen sensor

• Intake air temperature sensor

• Exhaust gas recirculation (EGR) position sensor

• Knock sensor

• Engine speed sensor

• Fuel pressure sensor

• Anti braking system (ABS) sensor

• Vehicle speed sensor.

12 Chapter 1. Presentation of The Project Framework

(a) Manifold absolute pressure sensor. (b) Mass air flow sensor.

Figure 1.8: Samples of some sensors.

Actuators

Actuators are an essential part of electronic control systems in vehicles. It is their job
to convert the electrical signals from the control unit into an action. Most actuators
are electric motors, stepper motors as illustrated in Fig. 1.9a or electro–magnetic
valves. In the engine control system, actuators regulate and set the correct idle speed,
control air flaps for torque and power optimization and meter fuel for optimum
combustion using an injection nozzle as indicated in Fig. 1.9b below.
In convenience systems, they are used to lock and unlock car doors, for example,
or for the remote control of fuel filler flaps, boot lids, engine bonnets and storage
compartments.

(a) Stepper motor. (b) Injection nozzle.

Figure 1.9: Samples of some actuators.

1.5 Project charters

In this section, we present the problematic and a brief but exhaustive state of art.
1.5. Project charters 13

1.5.1 Problem statement

New vehicles are loaded with advanced technology designed to keep drivers and
passengers safe on the road but not in the breakdown line. A new study by the
American Automobile Association found that there have never been so many repairs
requested by customers all over the world and Tunisia is among them. According to
its experts, it is mainly the lack of maintenance of cars that explains this explosion in
the number of repair calls. Seven vehicles out of ten have an electronic, electrical or
overheating problem [Aa1]. STIMM has noticed the increase of this phenomena on
particularly in the last couple of years. According to the garage specialists, several
factors can contribute to this breakdown such as:

• Poor quality road surfaces

• Speed bumps

• The warm weather

• Hot roads and extended trips.

These factors can be the reason to shattering the shock absorbers and cause damages
to the steering wheels and the under–carriage. The weather temperatures can
influence the engine, increase oil consumption and damage also the tires. Vehicles
manufacturers are using more and more information indicators on the dashboard
as shown in Fig. 1.10 to inform drivers of what features are in use and display a
detected problem with the car and alert the conductor about the issue.

Figure 1.10: Car dashboard.

Tab. 1.1 illustrates the most important warning lights that appear on the dashboard.
Despite all of these warnings, the ignorance of the drivers and inattention to the
details due to the increasing pace of life that keeps them under tremendous pressure
and stress makes them ignore the malfunction light indicator when it illuminates on
the dashboard of their vehicles that can lead to major car failures, stays the number
one concern of STIMM.
14 Chapter 1. Presentation of The Project Framework

Table 1.1: Mulfunction Indicator Lights.

Temperature warning symbol Oil pressure warning

Charging system trouble light Antilock brake warning

Fuel indicator symbol Check engine light symbol

SRS Airbag indicator symbol Tire pressure warning light

We can thus notice that the precise and fast detection of the breakdown is a real
problem in our context, when it is poorly made or simply not done, it can cause
enormous losses on various levels: economic, material, time or even the loss of
human lives in the worst case scenario. The purpose of our work is to:

• Accurately detect the origin of a defect in order to inform the driver or the
mechanic about its appearance

• Accurately and reliably monitor the evolution of the vital components of a

vehicle to warn the driver of the probable arrival of a breakdown

• Assure the clients and take their minds off the regular worries about their cars
safety

• Make the clients save money with preventative maintenance

• Reduce and win time by taking brief mechanic visits and fixing a pre–appointment.

Properly, to answer these questions, we have used External functional analysis

method.

1.5.2 External functional analysis

Functional analysis is a working method to define the requirements of a product
in terms of functions, at the lower cost. This method uses tools to identify usage
functions and esteem.

Analysis of the need

In this part we will study more precisely what we need to do. To this end, we will
follow these steps:

• Enter the need

• State the need

• Validate the need.

1.5. Project charters 15

1. Enter the need

To begin with, this need is basically to study, develop and implement a real time
e–Service platform for automobiles.

2. State the need

This accurately expresses the purpose and limitations of the study by asking the
following three questions:

• Who does the product serve?

• Answer: The driver

• What is it effective on?

• Answer: Car diagnostic

• For what purpose does it exist?

• Answer: Distantly monitor the performance of a vehicle

This investigation is summarized into the “Horned beast” as drawn in Fig. 1.11.

Who does the product serve? On what acts the system?

The driver Car diagnostic

E-service
platform
for automotive

Distantly monitor the

performance of a vehicle

For what?

Figure 1.11: Horned beast.

16 Chapter 1. Presentation of The Project Framework

3. Validate the need

To determine our service functions, we first define the diagram “Octopus” as illus-
trated in Fig. 1.12. This method defines the main functions (MF) in addition to the
constraint functions (CF) to have a global view of our product.

Monitoring the
The mechanic car performance
and data

MF1

CF1 CF4
E-service platform
Electrical power Price
for automotive

CF2 CF3

Safety Time

Figure 1.12: Octopus diagram.

Tab. 1.2 below clarifies our service functions. It constitutes an essential data set
enabling to have a good knowledge of our product.

Table 1.2: Service functions.

MF1 The e–Service allows the mechanic to monitor car performance and date distantly.
CF1 The e–Service runs with electrical power.
CF2 The e–Service provides safety for the driver by anticipating breakdowns.
CF3 The e–Service permits reduced mechanic visits.
CF4 The e–Service has a reasonable price.

1.5.3 Teleservice
At the automobile core market, to make a difference, companies are banking on
new technologies that make the vehicle connected and anticipate failures. Adopting
this strategy yields to positive aspects of safety. Among these new technologies we
shall mention teleservice. In the traditional process of making appointments by
telephone, when a maintenance operation is necessary, the customer is not always
able to accurately determine the nature of the intervention to be performed on his
car but today with teleservice the driver will no longer have to worry about it. This
technology consists of a range of features, all of which are geared to making life as
convenient as possible. It is a remote diagnostic tool that has the major advantage
1.6. Project specifications 17

of real–time inspection of the state of health of the driver’s car. The transmission of
accurate data to its preferred dealer will allow it to prepare in the best conditions
for the visit by ordering the required components, thereby reducing the duration of
its next passage in concession to a minimum. The driver’s visits are limited to what
is strictly necessary and the fixed maintenance intervals are over. This function is a
guarantee of quick and relevant troubleshooting methodology [Hir09].

1.6 Project specifications

This section describes the specificities of the project that will be used as guidelines
when developing and implementing the system.

1.6.1 Project objective

This project, will focus on the development and implementation of an intelligent

embedded system that consists on providing a real time diagnosis to monitor several
vital vehicle parameters in order to anticipate any possible failure.

Figure 1.13: The connected car concept.

1.6.2 Project tasks

• Analyze the Controller Area Network frames

• Choose the appropriate hardware and software for the achievement of the
project

• Set a real time monitoring and warning system in case of an anomaly

• Create a web page for the developed system.

18 Chapter 1. Presentation of The Project Framework

1.6.3 Methodology
In order to satisfy the objectives of the project, a well determined strategy should be
taken to achieve the expected result:

1. Study the CAN bus and the on–board diagnostic system

2. Design the system

3. choose the components and software

4. Place and weld the chosen components

5. Program the board

6. Execute and validate the proposed solution.

1.7 Conclusion
Throughout this chapter, we presented the company STIMM and its services. We also
have located the subject of the project and detailed its specifications. We will try to
specify in the next chapters the steps used to carry out this project.
 CHAPTER 2
Theoretical Framework

Contents

2.1 Introduction . . . . . . . . . 20 2.5 Requirements . . . . . . . . . 29

2.2 Controller Area Network . . 20 2.5.1 Design . . . . . . . . . . 29
2.2.1 CAN history . . . . . . 20 2.5.2 Hardware . . . . . . . . 31
2.2.2 CAN frames . . . . . . . 21 2.5.3 Software . . . . . . . 33
2.2.3 Message–based 2.6 Implementations . . . . . . 34
communication . . . . . 22 2.6.1 Boards assembly . . . . 34
2.3 On–board diagnostic . . . . 23 2.6.2 DB9 to OBD–II
2.3.1 History . . . . . . . . 23 connections . . . . . . . 34
2.3.2 OBD–II system . . . . 23 2.6.3 Practical assembly . . 35
2.3.3 OBD–II pinout . . . . . 24 2.7 Programming . . . . . . . . . 35
2.3.4 Diagnostic trouble 2.7.1 Software overview . . 35
code . . . . . . . . . . 25 2.7.2 Initialization phase . . 36
2.4 CAN bus reading . . . . . . . 25 2.7.3 Read Data . . . . . . . . 37
2.4.1 Connections . . . . . . 26 2.7.4 Write Data . . . . . . . 37
2.4.2 Dual waveform 2.8 Conclusion . . . . . . . . . . 40
visualization . . . . . 28

19
20 Chapter 2. Theoretical Framework

2.1 Introduction

As we said in the previous chapter that a modern automobile consists of up to 100

ECU’s sensing and taking signals of the various parameters of the automobile. This
rapid and complex exchange of signals ensures the proper functioning of the car. To
alleviate the problem of sending these signals efficiently, the Controller Area Network
(CAN) protocol was thus introduced. This chapter is dedicated to present the project
study and implementation. The CAN system will be introduced and explained at
the beginning, followed by the On-board diagnostic system. The project hardware
and software requirements as well as the validation of the proposed solution will be
presented at the end.

2.2 Controller Area Network

CAN is a data exchange system for computing network realized in order to find a
serial communication solution in motor vehicles, which tend to integrate more and
more electronic controls [Nil]. This section will contain the CAN history at first, then
we will explain the CAN protocol. The messages communication process will be
defined at last.

2.2.1 CAN history

In February of 1986, Robert Bosch introduced the Controller Area Network (CAN), a
multi–master serial bus that provides communications between controllers, sensors,
and actuators. In the past, automotive manufacturers connected electronic devices in
vehicles using point–to–point wiring systems. Fig. 2.1 as in [Fai16a] is the pictorial
view of the point to point wiring connection which worked fine when the functions in
the system were limited. Then, manufacturers began using more and more electronics
in vehicles, which resulted in bulky wire harnesses that were heavy and expensive.

Engine Anti-lock Air Power

Control Brakes Lights Conditioner Locks

Dashboard

Trans-
Active Power Power
mission Airbag
Suspension Seats Windows
Control

Figure 2.1: Before CAN.

2.2. Controller Area Network 21

Later, they replaced dedicated wiring with in-vehicle networks, which reduced wiring
cost, complexity, and weight. Fig. 2.2 as in [Fai16b], symbolizes this tremendous
change.
CAN, a high-integrity serial bus system for networking intelligent devices, emerged
as the standard in-vehicle network. The automotive industry quickly adopted CAN
and, in 1993, it became the international standard known as ISO 11898. Since 1994,
several higher–level protocols have been standardized on CAN, such as CANopen and
DeviceNet. Other markets have widely adopted these additional protocols, which are
now standards for industrial communications.

Engine Anti-lock Air Power

Control Brakes Lighting Condition Locks

CAN CAN CAN CAN CAN

High Speed Low Speed

C Dash- C
A board A
N N

CAN CAN CAN CAN CAN

Trans-
Active Power Power
mission Airbag
Suspension Seats Windows
Control

Figure 2.2: After CAN.

2.2.2 CAN frames

Messages in CAN are sent in a format called frames. The CAN protocol supports two
message formats [Par13]:

• CAN 2.0 A: supports a length of 11 bits (base frame) as in Fig. 2.3

• CAN 2.0 B: supports a length of 29 bits (extended frame) as in Fig. 2.4.

The CAN protocol specifies five different frame types for communication:

• Data frame: It assumes a predominant role in a CAN network

• Remote frame: It is generated by a so–called “consumer” node or data requester.

It may be transmitted in either standard or extended format

• Error frame: It is generated by any bus entity during the detection of an error

• Overload frame: It is used to request a lapse of additional time between data

frames or remote frames when they are successive

• Interframe: Data frames and remote frames are separated temporarily by an

interframe [Vos05].
22 Chapter 2. Theoretical Framework

S 11-bit R I R D 0...8 Bytes C A E I

O Identifier T D 0 L Data R C O F
F R E C C K F S

Figure 2.3: Base frame.

S 11-bit S I 18-bit R R R D 0...8 Bytes C A E I

O Identifier R D Identifier T 1 0 L Data R C O F
F R E R C C K F S

Figure 2.4: Extended frame.

2.2.3 Message–based communication

On a CAN bus, data messages passed on from any node that do not contain either
the sending node address or any expected receiving node. Instead, the message
content is tagged with a unique identifier across the network. All other nodes in the
network receive the same message and each one perform an acceptance test on the
identifier to determine whether the message, and thus its content, is relevant to that
particular node. If it is the case, it will be processed; otherwise, it will be ignored.
The unique identifier also determines the priority of the message. The identifier
with the lowest numerical value has the highest priority. In situations where two
or more nodes attempt to transmit messages at the same time, a non–destructive
arbitration technique ensures that messages are sent in order of priority to prevent
loss of messages [Kvab]. Fig. 2.5 simplifies the data transmission process.

CAN NODE 1 CAN NODE 2 CAN NODE 3

Prepare Data Accept Data Ignore Data

Check Data Check Data

Send Data Receive Data ReceiveData

Figure 2.5: CAN bus data transmission[ELE18].

2.3. On–board diagnostic 23

2.3 On–board diagnostic

The on-board diagnostic refers to the automotive electronic system that provides
self–diagnostic and reports capabilities for repair technicians to access the subsystem
of information for purposes of monitoring and repair performance [Kvaa]. The OBD
is what makes telematics and fleet solutions possible. Without it, there would be no
way to send all of the valuable data that the car collects. This section will provide all
relevant pieces of information about the OBD.

2.3.1 History

From 1980, embedded diagnosis have become progressively more sophisticated in

order to allow engines to respect the regulated emission sills. To ensure the precise
control required by this up–to–date technology, since the beginning of the 1980s, all
light automobiles practically have an on–board computer. This computer controls the
performance of the fuel injection system and other engine parameters in dynamic
mode. These “smart” computer systems are also called OBD “On–Board Diagnostic”
systems. Before OBD–I, every manufacturer had his own set of standards for OBD,
meaning that mechanics had to buy expensive scan tools for every manufacturer [Sol].
OBD–I was first introduced in 1980, and contributes tremendously to standardize the
on–board diagnostic. It had sensors that detected emissions and was able to minimize
them by releasing emissions–controlling valves. As a result, it was mandated in 1996
that car manufacturers equip cars and trucks with OBD–II ports. Fig 2.6 simplifies
the OBD history in a time–line.

1980 1996

OBD-I

OBD-II

1994 present

Figure 2.6: OBD time–line.

2.3.2 OBD–II system

OBD–II is the second generation of the OBD specification. It provides monitoring of

nearly all engine controls, and also some other parts of the vehicle (chassis, body,
etc). It is connected to the Malfunction Indicator Lamp (MIL) which is supposed to
alert the driver when something has gone wrong with the vehicles operation [201f].
Depending on the problem, the light either stays on, flashes, or goes away entirely.
The communication between the OBD–II calculator and the maintenance technician
is made from a diagnostic connector.
24 Chapter 2. Theoretical Framework

2.3.3 OBD–II pinout

To better understand how the OBD–II port grants unrestricted access to the CAN bus,
it is worth delving deeper into the Diagnostic Link Connector(DLC). Fig. 2.7 shows a
color–coded diagram of the DLC. Tab. 2.1 lists the standard assignments for each pin.

Figure 2.7: Diagnostic link connector.

For this project, the J1850 bus (pins 2 and 10) and ISO 9141–2 bus (pins 7 and 15)
Tab. 2.1 are out of scope, but they are essentially diagnosis buses that operate in
a similar manner to CAN. As noted in the table below, there are also various pins
dedicated to manufacturer–specific bus types.
Depending on the model of the vehicle being targeted, it may be necessary to delve
into those other bus types to gain greater access to the vehicle’s internal systems.
Other noteworthy pins are pins 4 and 5, which are dedicated to the ground pins,
and pin 16, which provides a constant supply of 12 volts power from the vehicle’s
battery. The purpose of pin 16 is to provide power to scan tools being plugged into
the OBD–II port, so that they do not require an external power source. The most
important pins within the scope of this project, however, are pins 6 and 14, which
are dedicated to the Controller Area Network, or CAN bus. The terms “CAN High”
(CAN–H) and “CAN Low” (CAN–L) are derived from the way in which CAN messages
are physically transmitted.

Table 2.1: OBD–II pinout [201e].

PIN Signal PIN Signal

1 Vendor option 9 Vendor option
2 J1850 bus 10 J1850 bus
3 Vendor option 11 Vendor option
4 Chassis Ground 12 Vendor option
5 Signal Ground 13 Vendor option
6 CAN (2234) High 14 CAN (2234) Low
7 ISO 9141—2K-Line 15 ISO 9141–2K–Line
8 Vendor option 16 Battery power
2.4. CAN bus reading 25

2.3.4 Diagnostic trouble code

Diagnostic Trouble Codes (DTC) are used to identify an issue or an error. They are
stored in the system and are extracted from the OBD–II port. The codes are not
necessarily the same across all vehicles [Kvaa; Lov16].
These codes, can either be generic or unique to the vehicle manufacturer, they take
the following format:

1. First unit identifies the type of error code:

• Pxxxx for power–train

• Bxxxx for body

• Cxxxx for chassis

• Uxxxx for class 2 network.

2. Second digit shows whether the code is manufacturer unique or not:

• x0xxx for government–required code

• x1xxx for manufacturer–specific code.

3. Third digit shows us what system the trouble code references:

• xx1xx/xx2xx show air and fuel measurements

• xx3xx shows ignition system

• xx4xx shows emissions systems

• xx5xx references speed/idle control

• xx6xx deals with computer systems

• xx7xx/xx8xx involve the transmission

• xx9xx notates input/output signals and controls.

4. Digits four and five show the specific failure code:

• xxx00 to xxx99 these are based on the systems defined in the third digit.

2.4 CAN bus reading

This section is dedicated to put under scope the connection required between the
DLC and the oscilloscope, and the obtained waveform.
26 Chapter 2. Theoretical Framework

2.4.1 Connections
CAN bus uses a physical layer comprised of a shielded twisted pair a two wire system,
CAN–H and CAN–L. Each one of them has its own characteristics as indicated in
Tab. ??. These two wires carry anti-phase signals in opposite directions to minimize
noise interruption that simultaneously interferes on the bus. When the CAN bus is
IDLE (free state), both wires carry 2.5V of electricity [201d]. But when transmitting
data, the CAN–H wire voltage increases to 3.75V and the CAN–L wire voltage drops
to 1.25V, creating a 2.5V voltage differential between the two wires. It is this voltage
differential on which CAN communication is based, and which makes the CAN bus
so tolerant to electrical noise and interference. In order to verify that data is being
continuously exchanged along the CAN bus and that a signal is present on both CAN
lines we visualized signals from the OBD connector pins using an oscilloscope. Each
speed visualization requires a specific connection:

• To display the CAN high speed, we plugged the pin 5 (Ground) and the pin 6
(CAN–H) of the OBD connector to channel A of the oscilloscope as shown in
Fig. 2.8b. The obtained waveform is illustrated in Fig. 2.9.

(a) Plugging.
(b) Oscilloscope connection.

Figure 2.8: CAN High.

Clk

CAN–High

Figure 2.9: CAN High waveform.

 Table 2.2: CAN High and Low specifications.

CAN bus low speed CAN bus high speed

Through–put 10kb/s to 125 kb/s 250kb/s to 1 Mb/s
Power Supply voltage 5V 5V

27
Output current > 1 mA over 2.2 kΩ 25 to 50 mA over 60 Ω
Number of nodes on the bus 2 to 20 2 to 20
Dominant level CAN–H = 4V / CAN–L = 1V CAN–H = 3.5V / CAN-L = 1.5V
Recessive level CAN–H = 1.75V / CAN–L = 3.25V CAN–H = 2.5V / CAN–L = 2.5V
Characteristic of the cable 30 pF between line cables 2 × 120 Ω
28 Chapter 2. Theoretical Framework

• To display the CAN low speed, we plugged the pin 5 (Ground) as well as the
pin 14 (CAN–L) of the OBD connector to the channel B of the oscilloscope as
demonstrated in Fig. 2.10b. The waveform is shown in Fig. 2.11.

(a) Plugging. (b) Oscilloscope connection.

Figure 2.10: CAN Low.

Clk

CAN–Low

Figure 2.11: CAN Low waveform.

2.4.2 Dual waveform visualization

We dual visualize both the CAN–H and the CAN–L signals. The obtained waveform
shown in Fig. 2.12. It is a clear evident that the signals are completely synchronized
and opposite. They are mirror image of one another. The edges are linear and
coincide with each other which means that we have a fully functioning system. In
other words CAN bus allows communication between the nodes and the CAN control
unit. This test effectively checks the integrity of the bus at this point in the CAN
network.

Clk

CAN–High

CAN–Low

Figure 2.12: CAN High and CAN Low waveform.

2.5. Requirements 29

2.5 Requirements
Before beginning to design the monitoring system for automobiles, some require-
ments were set.

2.5.1 Design
The e–Service system design is divided into two layers: Hardware and Software. The
architecture model of the system is shown in Fig. 2.13. The hardware layer consists
of electrical specifications of the design. The software layer has the programming
design of the system.
Mass air flow Vehicle Engine Throttle Engine coolant
Oxygen
sensor speed speed position temperature
sensor
(MAF) sensor sensor sensor sensor
Arduino UNO R3 CAN-bus shield

30
Controller
Area
Network
(CAN)
O2 Vehicle Engine Coolant
MAF Throttle
Voltage speed RPM Temperature
Figure 2.13: Block diagram of the system.
2.5. Requirements 31

2.5.2 Hardware
Although the OBD–II port is an unsecured interface, data reading is not as simple as
plugging the computer directly into the OBD–II port. In order to use a computer to
communicate on the CAN bus, some additional hardware peripherals are necessary.

CAN–bus shield

Shields are boards that can be stacked on top of the Arduino circuit board allowing
to extend its capabilities. The CAN–bus shield displayed in Fig. 2.14 provides the
Arduino with CAN–bus data. It will allow us to extract informations from the ECU.

Figure 2.14: CAN-bus shield.

Arduino Uno

Arduino is an easy and an efficient tool to use for wide spectrum of embedded system
applications, due to its open source software availability it was the perfect choice
for this project. Tab. 2.3 represents a comparison chart between the commonly used
boards for this type of application including their most important characteristics.

Figure 2.15: Arduino UNO R3.

 Table 2.3: Arduino boards comparison chart [Ahm17].
Operating voltage

Clock frequency
Microcontroller

Output current

Flash memory

Analog inputs
Input voltage

PWM output
Digital I/O
EEPROM
SRAM

32
Arduino Board
Due ATSAM3X8E 7–12 V 3, 3 V 130 mA 84 MHz 512 KB 96 KB 54 12 12
Leonardo ATmega32U4 7–12 V 5V 40 mA 16 MHz 32 KB 2, 5 KB 1 KB 20 7 12
Mega ATmega2560 7–12 V 5V 20 mA 16 MHz 256 KB 8 KB 4 KB 54 12 16
Pro ATmega328P 5–12 V 5V 40 mA 8 MHz 32KB 2 KB 1 KB 14 6 6
Uno ATmega328P 7–12 V 5V 20 mA 16 MHz 32 KB 2 KB 1 KB 14 6 6
2.5. Requirements 33

DB9 to OBD–II adapter cable

DB9 to OBD–II adapter allows the CAN bus shield to mate with the OBD–II port
directly. It has an OBD–II connector on one end and a DB9 female serial connector
on the other end [Ele], as illustrated in Fig. 2.16.

Figure 2.16: DB9 to OBD–II adapter cable.

2.5.3 Software
With the appropriate hardware in place to establish an appropriate link between the
computer and the CAN-based system, it is also necessary to download and install
the appropriate software to enable computer to vehicle communication. Therefore,
we are going to use the Arduino IDE for programming, as well as LabVIEW for
developing the graphical user interface.

Arduino IDE

Arduino IDE is a programming environment that allows the user to sketch different
kind of programs and load them into the Arduino microcontroller. Arduino uses a
programming language called Processing. IDE compiles and translates the code to the
assembler language, after that it uploads the program to the Arduino microcontroller.
Arduino IDE has a built–in code parser that will check the user written code before
sending it to the Arduino [201b].

LabVIEW

LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench. It is

a graphical programming environment which can be used to develop sophisticated
measurement, test, and control systems. It is different from other software packages
as it uses symbols rather than any textual language for programming purpose. Lab-
VIEW programs are called Virtual Instruments (VIs) because they replace original
instruments with the blocks which carry the same operation as that of the instrument.
34 Chapter 2. Theoretical Framework

Any instrumentation application will have two components, namely, the user interface
and the underlying code. This program will allow us to monitor the car performance
[201a].

2.6 Implementations

This section shows the hardware required implementation for the project.

2.6.1 Boards assembly

The Arduino board comes with an built–in female pin header which has connections
to its input/output pins. The shield comes with the same alignment of pins so it can
be overlaid on the Arduino R3, so there is no need for wires to join the CAN bus
shield and the Arduino. In order to clarify this connection, we created a prototype
using Fritzing as illustrated in Fig. 2.17.

Figure 2.17: Boards connection.

2.6.2 DB9 to OBD–II connections

To extract CAN bus data from the OBD–II system, we need to connect the DB9 pinout
of the CAN–bus shield to the OBD–II port of the vehicle. These connections are
displayed in Fig. 2.18a and Fig. 2.18b.
2.7. Programming 35

(a) Schematic view. (b) 3D view.

Figure 2.18: Ports connection.

2.6.3 Practical assembly

Once we designed the prototype using Fritzing, the next step was the practical
assembly as shown in Fig. 2.19.

Figure 2.19: Practical assembly.

2.7 Programming
2.7.1 Software overview
As a global overview of Arduino programming, it is divided, as established in the
IDE code development, in two main parts: setup and loop functions. The first one
36 Chapter 2. Theoretical Framework

is executed once the application runs. The second one is executed as a loop. it will
run repeatedly unless the power off or reset button is activated as demonstrated in
Fig. 2.20. At the beginning of the Arduino code all the components are delimited:
type, the pin to which is associated and the operation mode. In addition, the global
variables and the librariesto be used are defined.

START

YES

SETUP()

Reset
LOOP() NO
button

Powered YES

NO

END

Figure 2.20: Arduino software flowchart.

2.7.2 Initialization phase

Shield initialization is a must for both read and write programs. Here, we define our
CAN bitrate and import our libraries which are:

• Canbus.h

• defaults.h

• global.h
2.7. Programming 37

• mcp2515.h

• mcp2515–defs.h.
Every vehicle might use different bitrate speeds. For our example, we use 500 kbps.
Fig. 2.21 shows the successful setup loop execution.

Figure 2.21: Screenshot of the MCP2515 initilization.

2.7.3 Read Data

In order to read the CAN bus message, we have programed the Arduino board as
illustrated in the flowchart of Fig. 2.22.

2.7.4 Write Data

Not only we can read from the CAN bus but we can also write to it. The writing
allows us to electronically manipulate practically everything in a car by a simple
code. The main advantage is to allow us to control distantly the vehicle and without
mechanical intervention. Each code has a unique identifier but they unite in the same
following format:
→ CAN.sendMsgBuf(INT32U ID, INT8U Ext, INT8U Len, INT8U *Buf)
This is a function to send data into the bus, in which:
• ID: represents where the data come from

• Ext: represents the status of the frame ‘0’ means standard frame, ‘1’ means
extended frame

• Len: represents the length of the frame

• Buf: is the content of the message.

 START
Include libraries
Variables declaration
Serial setup
if
write:
CAN speed NO
”can’t init OK ”
=500
YES
write:
”CAN init OK ”

38
write:
”1.Speed
2.RPM
3.Throttle
4.Coolant temperature
5.Oxygen voltage
6.MAF sensor”
if if if if if if
UserInput NO UserInput NO UserInput NO UserInput NO UserInput NO UserInput
=’1’ =’2’ =’3’ =’4’ =’5’ =’6’
YES YES YES YES YES YES
Vehicle Engine Engine Coolant Oxygen
MAF
Speed RPM Throtlle Temp Voltage
END
Figure 2.22: Data reading flowchart.
2.7. Programming 39

When writing on the can bus, we can manipulate various things, for instance:

• Turn on and off the engine

• Unlock and lock the vehicle

• Roll up and down windows

• Sounding the alarm

• Switch on and off flashers.

Fig. 2.23 presents the code flowchart that allows us to write to the CAN bus.

START

Include libraries

Variables declaration

Serial setup

if
write:
CAN speed NO
”can’t init OK ”
=500

YES

write:
”CAN init OK ”

CAN.setMode
(MCP-NORMAL)

byte sndStat =
CAN.sendMsgBuf
(INT32U ID,
INT8U Ext,
INT8U Len,
INT8U *Buf)

if write:
(sndStat NO ”Error Sending
= CAN-OK) Message”

YES

write:
”Message Sent
Successfully!”

END

Figure 2.23: Data writing flowchart.

40 Chapter 2. Theoretical Framework

2.8 Conclusion
In this chapter, we have presented the operating principle of the Controller Area
Network and the On Board Diagnostic system. We also specified and implanted both
needed hardware and software for the project. The following and final chapter will
present the results validation.
 CHAPTER 3
Monitoring and Validation Results

Contents

3.1 Introduction . . . . . . . . . 42 3.6.2 Programmer interface . 51

3.2 System preview . . . . . . . 42 3.7 Virtual dashboard . . . . . . 51
3.3 LabVIEW VIs . . . . . . . . . 42 3.7.1 User interface . . . . . . 51
3.3.1 Front panel . . . . . . 43 3.7.2 Programmer interface 53
3.3.2 Block diagram . . . . 43 3.8 Running the program . . . . 53
3.4 Serial monitor . . . . . . . . 43 3.8.1 Overview . . . . . . . 53
3.4.1 Arduino . . . . . . . . 43 3.8.2 Experimental results . . 54
3.4.2 LabVIEW . . . . . . . . 44 3.9 Control and visualization . . 56
3.5 Authentication . . . . . . . . 47 3.9.1 Web server . . . . . . 56
3.5.1 User interface . . . . . . 47 3.9.2 Web publishing tool . . 57
3.5.2 Programmer interface 48 3.9.3 Web browser output . 58
3.6 Waveforms simulation . . . . 49 3.10 Conclusion . . . . . . . . . . 59
3.6.1 User interface . . . . . . 49

41
42 Chapter 3. Monitoring and Validation Results

3.1 Introduction

In this chapter, we will precede to the project software implementation. It will start
by explaining the used program, followed by the design of both user and programmer
interfaces developed for the monitoring process. Afterward, the program will be
put to the test and the obtained results will be discussed. The chapter then ends by
creating a web page.

3.2 System preview

As we mentioned previously that the goal of this project is to create a system that
will allow a qualified agent to distantly monitor a car performance on the garage
computer, who will instantly call the conductor and fix a checkup appointment in
case of the appearance of an anomaly. In order to achieve this goal and to guarantee
the serial communication between the hardware and the monitor that should contain
real–time data collected by the multiple sensors implanted in the vehicle, we used
LabVIEW to insure this process, as displayed by Fig. 3.1.

Figure 3.1: System preview.

3.3 LabVIEW VIs

LabVIEW programs are called virtual instruments, or VIs. LabVIEW contains a

comprehensive set of VIs and functions for acquiring, analyzing, displaying, and
storing data. This section is dedicated to describe the main components of a VI which
are the front panel window and the block diagram.
3.4. Serial monitor 43

3.3.1 Front panel

The front panel is a highly customizable user interface. It is a tremendously important
part of virtual instrument. No matter the software operations, input, output, or results,
all of these depend on the virtual graphical interfaces of the front panel, which make
real interactions between computers and users possible.

3.3.2 Block diagram

The block diagram is the “backplane” of the LabVIEW program where the actual code
resides. Any control or indicator placed on the front panel creates an icon on the
block diagram which acts as a connection between them. Tab.3.1 describes some of
the main components that can be found on the block diagram.

Table 3.1: Components of a block diagram.

Component Description
Terminals Terminals are the entry and exit ports that exchange information
between the front panel and block diagram. You can view terminals
as icon conserve space.
Nodes Nodes are objects on the block diagram that have inputs and/or
outputs and perform operations when a VI runs. Nodes are analogous
to statements, operators, functions, and subroutines in text-based
programming languages. Nodes can be functions, subVIs, or structures.
SubVIs SubVIs are VIs that run on the block diagram of another VI. They have
front panels and block diagrams. Any VI has the potential to be used as
a subVI. When you double–click a subVI, the front panel and block diagram
open.
Icon Icons are the graphical representations of VIs.
Use the icon from the upper–right corner of the front panel as the icon that
appears when you place the subVI on a block diagram.
Connector pane The connector pane is the map of inputs and outputs of a VI.
The connector pane terminals correspond to the controls and indicators on the
front panel of the VI. You cannot access the connector pane from the
block diagram window.

3.4 Serial monitor

This section is dedicated to the serial data monitoring from both Arduino IDE and
labVIEW interface.

3.4.1 Arduino
Once we upload the sketch onto the Arduino board using a USB connector, we open
up the serial monitor window to visualize the data streaming in from the OBD–II
port, as represented in Fig. 3.2.
44 Chapter 3. Monitoring and Validation Results

Figure 3.2: Arduino IDE serial monitor.

3.4.2 LabVIEW
Using LabVIEW software, we created a similar interface to the Arduino’s, that allows
us to receive continuous data from serial port.

Front panel

All of the Data will be displayed on the following interface as indicated in Fig. 3.3. In
order to initialize the monitoring process, the used COM port must be chosen from
the VISA resource name out control. Six indicators will be laid out, each one of them
will show a specific data.

Figure 3.3: LabVIEW serial monitor.

3.4. Serial monitor 45

Block diagram

Fig.3.4 shows the details of the block diagram that describes the monitoring process.
The operation begins with placing a VISA configure serial port which is a standard
Input/Output language for instrumentation programming, then connecting a control
to the input. The default baud rate is 9600. The obtained response shows the
complete data that is coming from the serial port, so we used several VISA read
functions that scans the specified number of bytes from the interface specified by
VISA resource name in order to split and show each data in deferent sequence as
follow:

• Engine RPM

• Vehicle speed

• Temperature

• Throttle

• O2 Voltage

• Mass air flow.

The obtained output enters the match regular expression function which splits the
string into two substrings, for the purpose of extracting the units that comes with the
data:

• rpm

• km

• °C

• %

• V

• g/s.

This entire process is inside six frames in a flat sequence structure. The chosen loop
executes from left to right when all data values wired to a frame are available. The
data leaves each frame as the frame finishes executing. This means that the input of
one frame can depend on the output of another frame. Finally, we have placed a Visa
close function that closes the device session when the program is finished.
 46
Figure 3.4: Serial reading block diagram
3.5. Authentication 47

3.5 Authentication
The visualization of the car’s performance is confidential between the customer and
the maintenance garage. The purpose of the login interface is to implement security,
so access will only be granted to a particular garage agent. This section is dedicated
to design the front panel and the graphical representation of the authentication
interface.

3.5.1 User interface

Before launching the program, the authentication interface, as shown in Fig. 3.5,
will be the first one to appear to the agent. A user name and a password will be
demanded at entry. Fig. 3.6 shows that the application starts only if both are correct,
if not, an SOS button will appear.

Figure 3.5: Screen–shot of the authentication front panel.

(a) Access granted. (b) Access denied.

Figure 3.6: Access interface.

48 Chapter 3. Monitoring and Validation Results

3.5.2 Programmer interface

Access diagram

The block diagram of the access VI as shown in Fig. 3.7 contains an event structure
that allows the user to write highly efficient code that waits for the events to happen.
Inside the loop, both login and password strings are connected to a sub VI as indicated
in Fig. 3.8. This whole operation is placed inside a “While Loop” which is enabled by
the RUN/STOP switch. As long as the switch is in the “RUN” position, its terminal
counterpart in the block diagram outputs a “TRUE” to the condition terminal keeping
the While Loop enabled and a “FALSE” disables the “While Loop”. As long as the
Loop is enabled, the code inside it is repeatedly executed.

Figure 3.7: Access block diagram.

Figure 3.8: Access Sub VI.

3.6. Waveforms simulation 49

Link diagram

The block diagram as represented in Fig. 3.9 was designed for the purpose of creating
a link between the access VI and the main VI. The code will allow the user to have an
instantaneous transfer to the main VI once the access is granted. This operation was
created using at first an open VI function and declaring main as a reference VI, the
output will go through the invoke node and at the end we used the close reference
function. This process is inside a flat sequence structure.

Figure 3.9: VIs link block diagram.

3.6 Waveforms simulation

This section contains both user and programmer interfaces of the main VI.

3.6.1 User interface

In order to carefully control and follow the car performance, we designed an interface,
as illustrated in Fig. 3.10, that contains both RPM and temperature charts, these will
continuously show point–by–point data in a real–time analysis. The panel is provided
with a brief description to help the agent to distinguish between them. Finally, to
allow the command of the panel, three different control buttons are displayed:

1. Start

2. Stop

3. Exit.
 50
Figure 3.10: Main VI front panel.
3.7. Virtual dashboard 51

3.6.2 Programmer interface

The execution of the code written on the following block diagram will only start once
the appropriate COM port is chosen. The output of the VISA resource name is linked
directly to the input of the monitor subVI that generates both RPM and temperature
flowing data. We used the Fract/Exp function to convert the string to a number that
will go as an input to the charts. This code is inside a while loop as displayed in
Fig. 3.11 that will keep executing unless the abort button is activated.

Figure 3.11: Main VI block diagram.

3.7 Virtual dashboard

The following section is reserved to the creation of a virtual dashboard VI.

3.7.1 User interface

In order to interact with the costumers vehicles, we have created a virtual customized
dashboard that looks similar to the existing one in their cars. This will allow the
garage agent to monitor several real time car parameters at the same moment which
are:
• Speed

• Temperature

• RPM.
Fig.3.12 illustrates our design that contains two virtual digital gauges.
The left one indicates the rounds per minute (RPM) of the vehicle which is scaled
from 0 to 10000, as for the right one, it displays the car velocity and it is scaled from
0 to 200. The car temperature appears in the center of the dashboard, a rated scale
was associated as well as a numeric display.
 52
Figure 3.12: Virtual dashboard VI front panel.
3.8. Running the program 53

3.7.2 Programmer interface

The block diagram as shown in Fig. 3.13 consists of the monitor Sub VI that decom-
poses into three different strings outputs. The first one will go to the RPM gauge,
the second string goes to the speed indicator, as for the third and final one it will be
headed towards the temperature gauge. Once again we used the Fract/Exp function
for the conversion process from a string to a number.
The code resides inside a “While Loop” that contains an abort button.

Figure 3.13: Main VI block diagram.

3.8 Running the program

The main objective of this section is to run the final simulation on LabVIEW and
eventually evaluate the obtained results.

3.8.1 Overview
Once the system is designed, the next step is to run the program. The execution of
the VIs will not be all at once, the access VI has the highest priority to guarantee the
confidentiality. If the access is granted, the monitor VI will start working to provide
data to the main VI that will appear instantaneously to the user followed by the
virtual dashboard interface. The flowchart in Fig. 3.14 describes this order.
54 Chapter 3. Monitoring and Validation Results

START

Access VI

Access
NO SOS
guaranteed

YES

Monitor VI

Main VI

Dashboard VI

END

Figure 3.14: Execution flowchart.

3.8.2 Experimental results

Monitor VI

After running the program and selecting the appropriate serial COM port, the monitor
VI will start showing the divided car parameters in their convenient indicators, as
presented in Fig. 3.15.
3.8. Running the program 55

Figure 3.15: Serial monitor simulation.

Main VI

Fig. 3.16 shows the obtained results of the main VI simulation, the operation started
by pressing the “Start” button. Once activated, both waveforms began displaying the
point–by–point data variation over time.

Figure 3.16: Main VI simulation.

Dashboard VI

The virtual needles as displayed in Fig. 3.17 follows the exact same pace of the actual
dashboard that exists in the conductor’s car.
56 Chapter 3. Monitoring and Validation Results

Figure 3.17: Virtual dashboard VI simulation.

3.9 Control and visualization

LabVIEW includes a server that allows us to export front panels easily. In this purpose,
we used this server to allow the 360 garage agent to distantly view and control the
interfaces.

3.9.1 Web server

LabVIEW web server can create HTML documents by opening front panels in a web
browser. They can be remotely monitored and controlled through the web browser
using TCP/IP services.

Figure 3.18: Screen–shot of web server configuration.

3.9. Control and visualization 57

This feature greatly expands the application as several persons sitting at different
locations can simultaneously access the same front panel. In order to proceed the
remote communication operation, a LabVIEW configuration must be held. The default
port number for the web server is 8080, we changed it to 8000. In web server local
debugging, we enable remote panel server and ticked to allow distant connection
while debugging. Also, from web configuration we changed HTTP port in local
debugging window to 8000, this number must be the same one as the debug HTTP
port that we set previously. The next step was to set the control time limit which is
very useful if the VI will be accessed by multiple users. If there is no control time
limit, a single user could monopolize control of the application, preventing other
users from assuming control. In our configurations, we ticked allow access in case
more than one garage agent wanted to visualize the interfaces. The final step is to
tick the first icon in the browser access, this will allow the user to have viewing and
controlling privileges. Fig. 3.19, presents the parameter’s configuration of the web
server option.

Figure 3.19: Screen–shot of configuring visible VIs and browser access list.

3.9.2 Web publishing tool

In web publishing tool dialog box, the select VI and viewing option allows us to
specify the VIs that we want to access remotely. At first, we browsed the access VI
and selected it embedded option for viewing mode. The chosen panel will be seen in
the preview window. The next step was to give the proper document information as
the title of HTML file, header and footer details. Finally we saved the web page in a
destination directory with proper filename. Once all steps are successfully done, the
document was saved within the web server’s root directory. We used the obtained
URL to connect and access the web page from a browser. Fig. 3.20 displays the HTML
content of our web page.
58 Chapter 3. Monitoring and Validation Results

Figure 3.20: Screen–shot of the web publishing tool.

3.9.3 Web browser output

We followed the exact same previous steps and created four web pages for each VI.
Fig. 3.21 shows an example of the obtained results of the web page for the Main VI,
published on the browser window.

Figure 3.21: Screenshot of the car parameters control system on web.

3.10. Conclusion 59

3.10 Conclusion
This chapter describes the entire process of the software design and the achieved
results. The obtained system is considered as a competitive product in the market
thanks to its low cost and its efficiency comparing to the regular diagnostic systems.
 General Conclusion

We recapitulate here the results obtained during our internship at the maintenance
workshop “360 Auto”, then we present the perspectives relative to this work.

Summary
Our major contributions in this work revolves the realization of a system that can
monitor the condition of the vehicle in real time. The first contribution concerns the
understanding of the automotive field and the electronics being involved, as well as
the identification of the project subject and its specifications.
The second contribution considers the theoretical framework. The approach is based
on the study of both Controller Area Network and the On Board Diagnostic followed
by programming the Arduino R3 and the CAN–bus shield.
The third and final contribution is dedicated to the design of the monitor interfaces
using LabVIEW. The proposed solution successfully detected the vehicle parameters
and displayed them on the designed virtual dashboard and show it point–by–point
on the main VI charts. Since this whole project, research and implementation work,
a lot of advancement can be added.

Ongoing and future work

By the end of this project, numerous problems still remain open. Several points
deserve further investigations:

I Change the Arduino program by adding more specific instructions allowing us

to extract data from all type of cars even the secured ones

I Enhance the LabVIEW program by setting references for an automatic alert

I A GSM module could be implanted to the hardware to instantly receive and

send voice calls and SMS in case of an emergency

61
62 General Conclusion

I Creating an android application to allow and facilitate the monitoring operation

even if the agent has no access to the garage computer

I Developping a “CAN writing” program to manipulate vehicles parameters

without mechanical intervention.
 Bibliography

[201a] 2016, ed. What Is LabVIEW? URL: http://www.ni.com/en- lb/shop/

labview.html.
[201b] Arduino Software (IDE). 2015. URL: https : / / www . arduino . cc / en /
Guide/Environment.
[201c] embedded single board computer. 2014. URL: https://www.animalsystems.
co . uk / mobile / latest - news / 52 - the - new - ebc - 1000 - series -
embedded-single-board-computer.
[201d] OBD II diagnostic interface pinout. Dec. 2, 2017. URL: http//pinoutguide.
com/CarElectronics/can_obd_pinout.shtml (visited on 11/03/2018).
[201e] Obd2 Wiring Diagram. Aug. 6, 2017. URL: http://davidbolton.co/
obd2-wiring-diagram/ (visited on 06/04/2018).
[201f] OBDII Bus. OBDII Bus Description. June 13, 2015. URL: http : / / www .
interfacebus.com/Design_Automotive_OBDII_Bus.html (visited on
11/03/2018).
[Aa1] URL : http://fortune.com/2016/07/20/aaa- breakdown- new- tech-
study/.
[Ahm17] T. Ahmad. Arduino Comparison Chart: Boards & Modules. June 29, 2017.
URL : https://www.element14.com/community/docs/DOC- 87084/l/
arduino-comparison-boards-modules (visited on 12/04/2018).
[Cho94] E. Chowanietz. Automobile Electronics. Newnes, 1994.
[Den04] T. Denton. Automobile Electrical and Electronic Systems. Butterworth-
Heinemann, 2004.
[Ele] S. Electronics, ed. OBD II to DB9 Cable. URL: https://www.sparkfun.
com/products/10087 (visited on 12/04/2018).
[ELE18] C. ELECTRONICS, ed. CAN bus explained- A simple intro. 2018. URL:
www . csselectronics . com / screen / page / simple - intro - to - can -
bus/language/en (visited on 05/04/2018).

63
64 Bibliography

[Fai16a] G. Fairhurst. Controller Area Network(CAN). 2016. URL: www.erg.abdn.

ac.uk/users/gorry/eg3576/CAN.html (visited on 10/03/2018).
[Fai16b] G. Fairhurst. Controller Area Network(CAN). 2016. URL: www.erg.abdn.
ac.uk/users/gorry/eg3576/CAN-phy.html (visited on 10/03/2018).
[Gre15] R. Green. Car: The Evolution of the Automobile. Andre Deutsch, 2015.
[Hir09] C. Hiraoka. Technology Acceptance of Connected Services in the Automotive
Industry. Gabler, 2009. DOI: 10.1007/978-3-8349-8309-1.
[Kvaa] Kvaser, ed. Introduction to the OBD II Standard. The OBD-II Diagnostic Con-
nector. URL: https://www.kvaser.com/about- can/can- standards/
introduction-to-obd-ii/ (visited on 10/03/2018).
[Kvab] Kvaser, ed. Understanding CAN Bus Messages. URL: https://www.kvaser.
com/about- can/the- can- protocol/can- messages- 33/ (visited on
10/03/2018).
[Lov16] R. Lovetere. How to Read and Understand OBD-II Codes | YourMechanic
Advice. June 7, 2016. URL: https://www.yourmechanic.com/article/
how - to - read - and - understand - check - engine - light - codes - by -
jason-unrau (visited on 10/03/2018).
[Nil] S. Nilsson. CAN Controller Area Network Information. URL: http://hem.
bredband.net/stafni/developer/CAN.htm (visited on 02/03/2018).
[Pan] Panosonic, ed. Automotive IC. Engine ECU. URL: https://b2bsol.panasonic.
biz/semi-spt/apl/en/products/analog/automotive-ic/ (visited on
10/03/2018).
[Par13] B. Parikh. CAN Protocol - Understanding the Controller Area Network
Protocol. Feb. 25, 2013. URL: https : / / www . engineersgarage . com /
article / what - is - controller - area - network ? page = 4 (visited on
01/2018).
[Pid] PID Control. URL: https://learn.parallax.com/tutorials/language/
pbasic/pid-control (visited on 03/04/2018).
[Rib02] W. Ribbens. Understanding Automotive Electronics (Sams Understanding
Series). Newnes, 2002.
[Sol] O. Solutions, ed. What is OBD? OBD-I. URL: http://www.obdsol.com/
knowledgebase / on - board - diagnostics / what - is - obd/ (visited on
09/03/2018).
[Uff11] C. V. Uffelen. Automobile Architecture. Braun Publishing, 2011.
[Vos05] W. Voss. A Comprehensible Guide to Controller Area Network. Ed. by C.
Media. Copperhill Media Corporation, 2005. Chap. Message frame archi-
tecture, p. 148.