Engineering Degree Project

Programming of Automotive
Electronic Control Units
Over CAN Bus

Author: Simon Lundh

Supervisor: Dr. Kostiantyn Kucher
External Supervisor: Martin Tibrat
Semester: Spring 2022
Subject: Computer Engineering
 Abstract

The automotive industry has significantly shifted towards electronic control units
(ECUs) for managing various vehicle functions. These ECUs communicate with
each other using a standardized protocol called the Controller Area Network (CAN)
bus. This project aims to explore the adaptation aspects of automotive ECUs over
the CAN bus and develop a comprehensive understanding of the process. This was
done by analysing the CAN bus communication and trying to replicate the traffic.
The CAN bus protocol is explored in detail, covering its architecture, message struc-
ture, and communication modes. The implementation presents practical examples of
adapting ECU settings. Overall, this project contributes to the understanding of pro-
gramming automotive ECUs over CAN bus and its implications for efficient vehicle
management. The final result was a prototype-level OBD2 scan tool capable of ad-
justing some non-safety-related parameters in the car’s ECU. The project was done
in collaboration with BSR, a company with many years experience in the car-tuning
field. The software was evaluated by testing the software on actual cars.

Keywords: On-Board Diagnostics 2 (OBD2), Controller Area Network (CAN)

bus, Electronic Control Units (ECUs)
Preface

Thanks to BSR for helping me in this project and providing both hardware and knowledge.
I would also like to thank my supervisor at Linnaeus University for his great patience with
my slow progress in this project.
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.7 Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theory 5
2.1 OBD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 DTCs and other protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 STM32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Method 9
3.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Research Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Implementation 14

5 Experimental Setup and Results 17

5.1 Read info from Toyota Yaris . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Explanation of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Read info from VW Caddy . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 VW Golf 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Sending messages to and from the PPC-unit . . . . . . . . . . . . . . . . 18
5.6 Performing an adaption on the Toyota . . . . . . . . . . . . . . . . . . . 19
5.7 Performing an adaptation on the VW Golf . . . . . . . . . . . . . . . . . 19

6 Analysis 20

7 Discussion 24
7.1 Expert’s Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2 Results and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Project Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8 Conclusion 27
8.1 Thesis Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2 Milestones Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3 Feedback from the company . . . . . . . . . . . . . . . . . . . . . . . . 28
8.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

References 30
A Appendix 1 PPC code A

B Appendix 2 PC code A
1 Introduction
Cars today are full of technology to improve everything from fuel efficiency to automatic
air conditioning. These are all done with embedded systems (ECUs), these come with
settings and options also known as "adaptations" which are not accessible to users any
other way than via a diagnostics tool. This project wants to take a look at what is needed.
In this section, we will discuss the background for this project, some related work, what
this project wants to do, give an idea of the project’s milestones and limitations as well as
the target group if this was a finished product.

1.1 Background
Cars today rely heavily on computers, and more and more systems are being implemented
to improve performance, safety, and reliability — a trend that is only set to continue
over the coming years as we move towards electric- and self-driving cars. While the
computerization of cars has led to a lot of benefits, such as direct injection and adaptive
cruise control (ACC), it has also led to it being harder for an owner to modify and/or
repair their car. The project will focus on activating "hidden" features/adaptations in the
car’s Electronics Control Unit (ECU) which is the main computer of the car and controls
most electric functionality [1]. The work will be done together with the Växjö-based
company BSR which specializes in tuning cars via their so-called PPC-units [2] which
provide access to a few different cars as well as a development version of their "PPC"-
units. BSR is interested in this since it could become an interesting feature to possibly
include in their PPC units going forward.
The PPC units use the OBD2 interface for access to the ECU. The OBD2 is a diagnostics
port that became standardized by law in California in 1994 [3] and is today widely used
across the world for accessing the ECU in a diagnostic setting. There are a few different
protocols specified in this interface to work on top of it. The most commonly used is
CAN-BUS (shortened to CAN continuing) [3] and is what this project will focus on.

1.2 Related Work

In "A design for automotive CAN bus monitoring system" [4] the authors discuss a way of
reading the messages sent over the CAN via a USB port. They have made a custom PCB
to achieve this and PC software to read the data over the USB port. The PCB contains
among other components, A LM2596 voltage regulator to provide DC power to the rest of
the components, an NXP MC9S12DP256 16-bit microcontroller as the main processor in
this embedded system, an NXP PDIUSBD12 to communicate over USB. Looking at the
official documentation on the NXP microcontroller it does support CAN communication
so no separate component to communicate with the car over CAN is needed. The project
used C and C++ as programming languages for both the firmware for the microcontroller
and the PC. The authors tested their hardware and software using a Kvaser OBD2 system
running on a separate computer. That project is very interesting in regards to this project
since it uses a lot of similar ideas: the idea of using an embedded system to act as an inter-
mediary between the computer and the car, programming in C/C++, and using Kvaser to
verify the results. The project however only reads messages and does not attempt sending
messages over CAN.

In "M3 Pi: OBD-II Touchscreen Car Computer" [5] the author has created a vehicle
display for his BMW M3 car from 1997 that displays different values read from the car’s

1
OBD2 port. It differs from this project since it mostly reads data from the OBD2 port and
has more focus on the hardware. The project does however share a lot with this project
since it focuses more on the CAN-BUS system and how to access different data.

"Evaluation of CAN Bus Security Challenges" [6] is an article in which the authors from
the IVHM Centre at Cranfield University discuss current and future threats to cars, specif-
ically in the CAN-Bus system. The authors explain the inner workings of the CAN-Bus
protocol and then continue to explain the current vulnerabilities that the protocol faces.
The authors claim that with physical access such as via the OBD2 port, there is currently
little to no protection against attacks. They specifically focus on disruptive attacks in this
segment, meaning that they focus on attacks that will deliberately try to flip bits or flood
the network with data. This part is interesting to this project since it describes how an
OBD2 device potentially could stop all communication between the different nodes in the
car. Depending on the car this could of course have drastic consequences. This is also
something this project has to think about, the device cannot disrupt the system since for-
getting it plugged in could lead to accidents. The authors also discuss other ways of attack
such as over Bluetooth. In the later parts, they discuss a few potential solutions/remedies
to the vulnerabilities discussed, such as Network segmentation, Encryption, Authentica-
tion, and different types of IDS ("Intruder Detection System"). While doing this project
there are some points to be discussed here since it was found out that one of the test cars
(2014 Golf) had some level of Network segmentation since it was not possible to read all
data on the can-bus, this was different to the other car (2012 Yaris) where all data was
readable. It also seems to have some primitive authentication since certain action has to
be performed to access certain systems. It might be only this model and it might also be
primitive however and easy for a potential intruder to avoid. Although their conclusion
that more research and development in this particular field is still something that the au-
thor of this report agrees with.

In the book "CAN and FPGA Communication Engineering: Implementation of a CAN

Bus based Measurement System on an FPGA Development Kit: Implementation of a CAN
Bus based Measurement System on an FPGA Development Kit" [7], the author Yu Zhu
discusses his project to use an FPGA development kit to read CAN-bus messages. The
book goes into great detail about both CAN-Bus and FPGA programming and is a good
reference to the more in-depth parts of CAN-Bus. Although that project does not have
that much in common with this project overall it is still connected since it also tries to
read CAN-Bus messages, and does show a different approach than the one taken by BSR
in their PPC-unit.

The article "A CAN-Bus Lightweight Authentication Scheme" [8] tries to fix one of the
drawbacks of CAN-Bus. Which has been criticised in other reports as well, like in pre-
viously mentioned "Evaluation of CAN Bus Security Challenges" [6] and in CAN-Bus
Attack Detection With Deep Learning [9], which is its safety. This article tries to add
security to the protocol by changing the current CRC field into a MAC field. This would
according to the authors only add a minor time delay to the transmissions, yet still create
a much safer communication system. This does require an update to the protocol however
and would not necessarily be compatible with current systems. And at that point might it
be better to replace CAN-Bus completely? The authors do mention that one of the reasons
their project increases safety even though it only creates 255 possible combinations the
relatively slow speed of CAN-Bus to other protocols today. Relying on the speed of the

2
current version of CAN-Bus seems like a bad idea when the authors themselves mention
in passing the increase in speed seen in CAN-FD. The article is still interesting and helps
further understand the security aspect of the protocol. Although its direct relevance to the
project is limited.

1.3 Problem Formulation

The expected result from this project is to create a computer program prototype capable
of programming some changes into the ECU of a VAG (Volkswagen AG) car via BSRs
PPC units. The changes are based on features that people have requested online and what
can be done without major changes having to be done to the ECU.
The project is divided into three parts: firstly to investigate what settings can be changed
in a specific car computer unit (ECU), secondly how to access and change a setting over
the OBD2 port, and finally implement a prototype program that can perform that change
together with the PPC on a real ECU. The project is limited to Volkswagen AG cars with
a focus on Volkswagen specifically. It is possible to extend the support for other brands in
the future if there is enough time, e.g., for BMW cars. The knowledge gap in this project
is relatively large due to the relative lack of publicly available documentation of the VAG
ECU. However, BSR has years of experience in this field and has provided some valuable
knowledge. BSR also provided a developer version of its PPC for the project together
with a programming tool and access to some ECUs.

1.4 Motivation
Cars have over the years gotten more complicated with more and increasingly advanced
systems. The goal of this project is to research and develop a computer program that
can change some of the hidden settings in a car ECU, while this is not a spectacular
achievement in of itself it is very similar to how other functions of the car are accessed
through the CAN-bus. Making it interesting not only by the adaptations themselves but
also on a bigger scale for how communication between an OBD2-scanner and a car is
done in other situations as well.

1.5 Milestones

Table 1.1: Thesis Project Milestones

M1 Decide on a suitable and available automotive ECU to focus on

M2 Investigate the available data access and modification options for the
CAN bus using OBD2
M3 Investigate how to implement the modifications
M4 Design and implement the PPC and PC software
M5 Test the software on a real automotive ECU
M6 Address potential issues (bugs)
M7 Outline the generalization steps towards other ECUs

1.6 Scope/Limitation
The project is limited to what cars are available and what can be done in a reasonable time
frame. The priority is to make one change in the settings of an ECU and then continue

3
with the next. The project is also only to use the BSR-provided PPC-unit and not any
other OBD2-capable device. The code is limited to C# for the PC software and C for the
PPC unit. Since this project uses other tools (described in the theory section) to check
what is possible to do, the project is also limited to what they can do.

1.7 Target Group

The target group for this report is people who want to develop something for the OBD2
port, whether that be something that codes the ECU or just reads fault codes. While the
target group for the physical project is people who want to change the not easily accessible
settings in their cars.

1.8 Outline
The "Theory" chapter discusses the different technologies used in this project, such as
ECU and CAN-Bus. "Method" discusses how the project is planned to proceed with help
from the milestones. It also contains a discussion of the reliability and the validity of the
results, as well as a discussion of the ethical considerations. While "Implementation"-
chapter is an explanation of the project, and what has been done. The chapter "Experi-
mental Setup and Results" discusses the tools used during the testing phase and how it
went while "Analysis" discusses the results from the tests in the previous section. The
"Discussion" chapter talks about what the project has accomplished compared to what
the expectations were. And finally "Conclusion" talks about the conclusions that can be
drawn from the project, if anything should have been done differently, and if it could be
in a final product.

4
2 Theory
In this section, we will discuss further how cars communicate with a diagnostics tool and
internally via CAN-Bus. As well as a few other topics relevant to the subject.

2.1 OBD2
According to [5], On-board diagnostics (OBD) is a system that monitors the performance
of a vehicle’s engine, transmission, and other critical systems. The OBD system is regu-
lated by the Environmental Protection Agency (EPA) in the United States and is required
in all vehicles sold in the US since 1996. With the EU following in 2001 for gasoline cars
and in 2003 for diesel cars. As highlighted by [4], the OBD system uses a standardized
diagnostic connector, known as OBD2, and a set of diagnostic trouble codes (DTCs) to
communicate the status of the vehicle’s systems. This information can be accessed by me-
chanics and technicians using specialized diagnostic tools, allowing them to diagnose and
repair issues with the vehicle. The OBD2 system is designed to provide real-time infor-
mation about the vehicle’s performance and any problems that may arise. It continuously
monitors the vehicle’s systems and generates a DTC when it detects a malfunction [7].
The DTC is a code that corresponds to a specific problem, and it can be used by techni-
cians to diagnose and fix the issue. OBD2 is also able to send real-time information about
the vehicle such as fuel efficiency. [1]
In the figure below the two green pins are the ones for CAN-High and CAN-Low i.e. the
pin used for the CAN protocol. Pin 4 and 5 are ground connectors, and pin 16 is a 12-volt
line from the car battery. [10]

Figure 2.1: OBD2 Connector (female) [11]

In total OBD2 supports five communication protocols/standards: [10]

• ISO 15765 (CAN bus) (on pins 6 and 14)

• ISO 14230-4 (KWP2000)

• ISO 9141-2

• SAE J1850 (VPW)

• SAE J1850 (PWM)

Except for CAN-Bus, these are not in wide use in the US or the EU anymore [12]. And
it is not common for cars to support all of these protocols. In 2008 CAN-Bus became
mandatory in the US so cars there are expected to support it, this has since led to the other
standards becoming less common.

5
In the future it is looking like a replacement for OBD2 might come in the form of OBD3,
this then being a wireless standard. This is however mostly rumours and concepts, no
actual ISO standard has yet been ratified that specifies an OBD3 interface of any kind. A
change to wireless is however mentioned as a possibility in ISO 27145-1:2012.

2.2 CAN-Bus
In the physical layer, CAN works by having two wires like in Figure 2.2. The two re-
sistors at the ends of the wires are specified to be 120 ohms. [13] All nodes in the CAN
network will have to be connected to both wires to accurately tell what going on, as well
as if they want to send anything.
CAN is traditionally seen as a normally high although CAN uses a high and a low voltage
wire. When both wires are at 2.5V the nodes should consider this a 0 in the logic and if
the high-can is 5V and low-can is 0V this is seen as a 1.

The CAN frame is composed as shown in Figure 2.3. A CAN frame consists of ei-

Figure 2.2: Example of CAN-BUS physically

ther 112-bits or 128-bits depending on if it uses an extended frame or not. The first bit
is a "Start of frame" meaning that it starts sending a frame if no node complains. The
next 13 bits are part of the "Arbitration" field and contain 11 bits of "Can ID" and then an
RTR bit. The "Arbitration"-field is followed by the control part, which contains a total of
7 bits, the last four are of value since they inform how many bytes should be read. After
the "Control"-field there is the "Data"-field where the data is sent, this can be between
0 and 8 bytes long in a single frame. Sending data over multiple frames is possible and
is often done both to talk to diagnostics tools as well as internally. The "Data"-field is
then followed by the CRC section for control, the ACK delimiters, and finally the end
of the frame which is to indicate that the bus is being freed up by putting ones for 9
bits. [7] [8] [14] [10]

Figure 2.3: Example of CAN-BUS data

The data field contains bytes as shown in Figure 2.4. These are written in hexadecimal to
simplify reading.

6
 Figure 2.4: Example of CAN-BUS data

2.3 DTCs and other protocols

DTCs stand for Diagnostic Trouble Codes, these codes are used by the OBD system to
send information about problems and anomalies internally and to diagnostics units. The
DTCs are specified in SAE J1939. [15] SAE J1939 is however not the only protocol which
works on top of CAN-Bus. Other examples are CANOpen, ISOBUS, SDS, etc. [16] These
protocols may introduce other trouble codes but are outside the scope of this report.
Working on some of the same layers in the OSI model as CAN-bus, there are a few
other protocols that also may provide further trouble codes or in other ways change the
communication for example UDS, SAE J1587, SAE J1708, etc.
Of the previously mentioned protocols only UDS and SAE J1939 will be further touched
upon in this report. They are both common in modern cars while SAE J1708 is designed
for buses and trucks. [17]
DTCs are codes written with 5 characters, for example: P0135. Figure 2.5 shows how
what they represent.

Figure 2.5: Example of DTC

2.4 ECU
ECU stands for Electronic Control Unit and is referring to one of several ECUs in a
modern car. ECUs have different functions and sometimes are confused to only be the
cars Engine Control Unit. The Engine Control Unit is also an ECU. [18] The ECUs are
usually connected via CAN-Bus but other protocols do exist for example FlexRay, and

7
LIN. [19] The ECUs often have settings that can be enabled or disabled only by talking
the ECU directly, and that is what this project hopes to accomplish. In this report we will
use the singular "ECU" to simplify and to refer to the whole system.

2.5 STM32
In this project, BSR provided a PPC unit using a STM32 micro-controller. This micro-
controller does have support for both CAN-Bus and USB [20] and that is why it was
chosen for this version of their PPC. It will in handle the communication between the
computer and the car by being on its board with a USB Type-C connector on one end
and an OBD2 connector on the other. The STM32 is a popular microcontroller made by
ST-Technologies and has its own IDE based on the Eclipse IDE. The following flowchart
(Figure 2.6) might give a better idea of how the previously mentioned parts relate to each
other.

Figure 2.6: Example of CAN-Bus structure

To summarise the figure, it shows three ECUs that would in a car control different areas
of the car, for example, windshield wipers, door mirrors, instrument clusters, or the main
ECU for the engine. These are all connected to the same CAN-bus in the figure, the
CAN-bus is also connected to an OBD2-port for diagnostics purposes and it is here that
mechanics and technicians usually insert their diagnostics tools but in this project it is
where we insert the DEV-PPC board to make out changes. The DEV-PPC itself contains
a male OBD2-port and a STM32 processor along with some other components to power
the PPC and receive commands from a PC.

8
3 Method
3.1 Methodology
This section is about what methods were used to reach the milestones in this project,
as well as ethical considerations and repeatability. Figure 3.1 shows the methodology
in the project, the project is based on a lot of expert feedback from BSR so therefore
it has guided the project throughout. Otherwise, the project started with an analysis of
how ECUs in cars are integrated, followed by an analysis of what the requirements of the
project should be. Thereafter began the implementation with some direct feedback from
the IDE (Integrated Development Environment), Expert feedback, and results of the Use
Case analysis, lastly, the project was also subject to critical discussions on its outcomes.
The "Reliability and Validity" and "Ethical considerations" were always a priority and can
not be put in a certain position in figure 3.1.

Figure 3.1: Method

The methodology does rely on certain guidance by "experts" in the field and is perhaps
the biggest criticism towards the project’s methodology, but guidance by experts can also
be very helpful, especially when it comes to ethical concerns since they often have faced
similar problems or concerns, there is also definitely an argument that more human aspects
in software development are a good thing [21].

3.2 Research Project

In a previous section, some milestones were mentioned and in this subsection, some fur-
ther explanation will be given. Milestone 1 "Decide on a suitable and available automo-
tive ECU to focus on" This milestone was done by discussing different types of ECUs
with BSR to find one that was easy to get started with, available during the project, and
some interesting adaptions. BSR also wanted it to be done on an ECU which their cus-
tomers might have. Milestone 2 "Investigate the available data access and modification
options for the CAN bus using OBD2" would be done by both looking at what others have
been able to do online as well as checking with VCDS and Autel to see what they can do.
This also sets the direction for the project. Milestone 3 "Investigate how to implement the

9
modifications" was done by looking at what other diagnostics systems are doing to acti-
vate/deactivate different settings in the ECU, specifically looking at the communication
between them. Milestone 4 "Design and implement the PPC and PC software" was done
using IDEs Visual Studio 2022 and the C# language for the PC software and STM32Cube
IDE and C for the PPC. Milestone 5 "Test the software on a real automotive ECU", In
practice this implies testing the PPC on real cars. Milestone 6 "Address potential issues
(bugs)" Was done by reading the communication logs of the PPC and ECU, and trying to
address them either during testing or after. Milestone 7 "Outline the generalization steps
towards other ECUs". After being done with an adaptation focus should shift to see if
there are any other cool adaptions for that ECU or if changing the ECU is a better idea.

3.2.1 Literature Review The literature review conducted for this project explored the
available data access and modification options for the Controller Area Network (CAN)
bus using On-Board Diagnostics 2 (OBD2). In [12], it was revealed that OBD2 has be-
come a widely accepted standard for accessing diagnostic information and communicat-
ing with ECUs in modern vehicles. It provided a standardized interface for retrieving real-
time data, accessing trouble codes, and performing various diagnostic functions. In [9],
authors explored different techniques and methodologies for utilizing OBD2 to access and
modify ECU parameters over the CAN bus. The review also highlighted the importance
of understanding the communication dynamics between the diagnostic tool and the ECU
to ensure effective and reliable data access and modification.

3.2.2 Requirements Analysis The requirements analysis for the project involves sev-
eral milestones. Milestone 1 focused on selecting a suitable and available automotive
Electronic Control Unit (ECU) by considering various types of ECUs in discussions with
BSR. Milestone 4 involved designing and implementing the PPC Software and PC soft-
ware. For the PC software C# in Visual Studio 2022 and C in STM32Cube IDE for the
PPC. Milestone 5 focused on testing the software on a real automotive ECU, which re-
quired conducting tests on actual cars. Milestone 6 involved addressing potential issues
and bugs by analyzing communication logs between the PPC and ECU and resolving
them during testing or post-testing [18]. Milestone 7 aimed to outline the generalization
steps towards adapting the software to other ECUs, assessing the potential for additional
adaptations on the same ECU, or considering a change of ECU if needed.

3.2.3 Prototype Implementation The prototype implementation phase of the project

involved applying the methods discussed in the previous section to achieve the specified
milestones. Milestone 1 focused on selecting a suitable automotive Electronic Control
Unit (ECU) through discussions with BSR. The chosen ECU needed to meet criteria such
as accessibility, availability, and potential for interesting adaptations that would be valu-
able to BSR customers. Milestone 2 involved extensive research into data access and
modification options for the Controller Area Network (CAN) bus using On-Board Diag-
nostics 2 (OBD2). This investigation encompassed online resources as well as consulta-
tions with VCDS and Autel to determine their capabilities and further guide the project’s
direction. Milestone 3 entailed investigating the implementation strategies used by other
diagnostic systems to activate or deactivate various ECU settings, with a specific focus
on studying the communication protocols involved [9]. For Milestone 4, the PPC and
PC software were designed and implemented using Visual Studio 2022, the C# language
for the PC software, and STM32Cube IDE and C for the PPC. This phase included the
development of the necessary software components to enable the desired modifications.

10
Milestone 5 involved testing the developed software on real automotive ECUs, providing
an opportunity to validate the functionality and effectiveness of the prototype. During
this stage, the PPC was tested on actual cars to ensure its compatibility and performance.
Milestone 6 focused on addressing potential issues and bugs encountered during testing.
This was achieved by carefully examining the communication logs between the PPC and
ECU, aiming to identify and resolve any inconsistencies or errors that may arise [13]. Fi-
nally, Milestone 7 outlined the steps required to generalize the prototype implementation
for other ECUs. This involved considering additional adaptations for the selected ECU or
exploring the feasibility of transitioning to a different ECU for future implementations.
The prototype implementation phase critically involved the practical application of the
chosen methods and the iterative refinement of the software and hardware components to
achieve the project’s objectives.

3.2.4 Use Case Use Case refers to the comprehensive examination and validation of
a system or product in the specific context where it is intended to be deployed, encom-
passing not only functionality testing but also the evaluation of its suitability, reliability,
and effectiveness within real-world scenarios. This involves simulating or replicating the
conditions and tasks that the system will encounter during its operational use, allowing
for thorough assessment and refinement of its performance, user experience, and overall
viability [22].

3.2.5 Expert feedback As previously mentioned, the project was conducted in collab-
oration with BSR. Their involvement was vital not only for the project’s success but also
for the competence, experience, and support they provided. Additionally, they offered
valuable feedback throughout the project’s duration. While it is hard to determine who
is an expert in a certain field as Crispen and Hoffman talks about in their article "How
many experts?" [23], however, based on "Carrer Analysis" their 15+ years in the car tun-
ing business speaks for itself. A valid criticism of the project in general would perhaps be
that more experts would be needed to make sure that the outcomes were inline with what
the wider industry thinks and does. However, the expert feedback was inline with other
sources such as Vector [24] and Kvaser [16].

3.2.6 Critical Discussion Critical discussion involves looking at project results, finding
areas to improve, and thinking about future challenges and opportunities. Reflecting on
what could be done better and staying aware of ongoing challenges helps with continuous
improvement and innovation. In qualitative software engineering research, it is important
to practice reflexivity, which means researchers think about their own assumptions and
biases during the study. This practice improves the credibility and trustworthiness of the
findings by making sure researchers understand how their views affect the research results.
Also, using different methods can reveal a wider range of insights and help understand
complex issues better [21].

3.3 Reliability and Validity

The project has several reliability concerns because cars, even of the same make and
model, come from the factory with different configurations. These configurations can
include different engines or sound systems, and while these components are designed to
not interfere with other CAN-BUS equipment and are set up to only respond to specific
calls, this cannot always be assumed to be the case. This is especially true with third-party

11
equipment like an aftermarket stereo system, which can increase the chance of interfer-
ence and pose a significant reliability issue. Additionally, the variability in equipment
means that different systems might respond differently to the same commands. For ex-
ample, one car might have a digital instrument cluster, while another, even within the
same model range like the MK7 Golf, might use a traditional analog cluster. These differ-
ences mean that while the appearance and basic functionality might seem the same, the
underlying systems might not operate in the same way, leading to potential issues in com-
munication and control. For instance, diesel cars often have a different instrument cluster
than gasoline cars because of differences in engine performance characteristics such as
RPM range, making it harder to standardize CAN-BUS messages.

In the context of empirical research in software engineering, these variability issues high-
light several key threats to validity. According to Verdecchia et al., [25], threats to validity
are potential shortcomings in empirical studies that affect the reliability and generaliz-
ability of the findings(other). For this project, these threats are evident in the differing
hardware configurations and their impacts on system behaviour. To mitigate these threats,
it is important to carefully document all variables and consider how different configura-
tions might affect the outcomes of the project. This includes acknowledging the poten-
tial impact of third-party components, which might not adhere to the same standards as
factory-installed systems.

Furthermore, Petersen and Gencel emphasize that the philosophical worldview of the re-
searcher influences the selection and reporting of validity threats in empirical studies [26].
For our project, adopting a pragmatist approach, which values practical solutions and
multiple methods, is essential given the complex, real-world environment of automotive
systems. This approach allows for a more comprehensive assessment of the reliability
and validity threats, considering both qualitative and quantitative aspects of the study.

3.4 Ethical considerations

Making an ECU behave in another way than what the manufacturer intended contains a
certain risk. This risk is amplified by the low understanding of the meaning behind the
CAN-BUS messages. We (in this subsection refers to any person or company not being a
manufacturer of ECUs for example Bosch, or the intended car brand) only have guesses
of what they might do based on what other programs which in turn has also only made
guesses based on their results. This leads to the potential of something going wrong to
be high. When this risk is applied to cars we are potentially putting life at risk, since we
do not know entirely how every car will react to the changes in the ECU, potential faults
with systems like the cruise control could lead to the car either braking or accelerating
unexpectedly, obviously causing a huge risk to people inside and outside of the car and
potential loss of life. Therefore all changes made to an ECU have to be well tested be-
forehand to limit this risk.

Another consideration would be the adaptations themselves, the main chosen adaptation
in this project was the option to make the needles on the dashboard go to their maximum
value and then return to idle when the ignition is turned on, this adaptation was chosen
due to its limited risk and quick response to whether or not the adaptation went trough
or there was an error. Other adaptions that were possible to do contained among other

12
things, the option of turning off the seatbelt warning chime. This was decided against
since it would promote driving without a seatbelt.

It was also decided against this project doing anything with the engine settings them-
selves, this was not only because that would make the project more complicated and
require a lot more knowledge but because the risk of something going wrong was much
larger. The project overall was focused more on small adaptations to the car with limited
risks for people both inside and outside of the car.

13
4 Implementation
Thanks to BSR not much time had to be spent on the physical hardware since they pro-
vided a development version of their PPC. The exact components of the PPC will be kept
secret and censored in the coming information since BSR does not want this to be public
knowledge. What can be disclosed is that it is a board with USB-C and an OBD2 port,
and it is based on an STM32 microcontroller. It also has two LEDs which were used for
debugging purposes.

Even though the PPC was provided by BSR, some research surrounding the development
of the board was still needed. In the end, this version of the PPC was essentially only a
standard STM32 micro-controller with a board for power-delivery, OBD2-connectivity,
and a way of connecting it to a PC, which happened to be a USB. A simplified view can
be seen in Figure 4.1.

Figure 4.1: Simplified PPC

With this in mind, the development resulted in two small-scale experimental software’s.
One for the PPC and one for the PC which acted as an HMI (Human Machine Interface).
The PC software was developed with C# and Windows Forms, due to its simplicity and
ease of use. In a relatively short time frame a simple Windows GUI was created with the
needed functionality, an example can be seen in Figure 4.2.

Figure 4.2: PC UI

The GUI is built so that it has several levels, A user starts by choosing a car brand (ei-
ther VW or Toyota since they are the brands that have been experimented on during the
project), then the user may choose the car model, and thereafter the adaptation and what
setting to put it on. The project is limited to only one or two adaptations per car but the
software in both the PC and PPC is designed to be easily expandable with more adapta-
tions, cars, and brands.
The PC software uses the built-in library in C# for reading and writing on one of the se-
rial ports in Windows. This is for communicating with the PPC which connects to the PC
over USB as a serial device. The user chooses which serial port to connect to and then
tries to connect to the PPC over it. The software also has some basic timeout and other
error handling for the serial port. (This is one area that will be further discussed in later
sections).

14
The software in the PPC is written in a version of C known as Embedded C which does
lack some functionality of C, although it does have some STM32-specific additions in this
case. At first a concept of using some type of RTOS (Real Time OS) but this was decided
against due to the complexity it would come with. In this project it was only needed for
one specific task, to periodically tell the ECU that there was a "tester connected". "tester
connected" is a term used by VCDS and Autel to denote the CAN-Bus message to the
ECU often called "heartbeat" signal in other scenarios. It simply informs the ECU that
there is still a tester connected and that it should expect calls from it. Depending on the
car the ECU might or might not respond to these calls with a simple ACK. The PPC is
however programmed to do nothing until told to do so, So while it waits it simply listens
to both the USB and OBD2 interfaces. When told to do an action over the USB interface
from the PC software it will simply get a set of bytes as a serial string. These bytes are
read in an if-else statement for simplicity, which then calls a method with hard-coded
instructions on how to do that adaptation and what values to expect in response. Figure
4.3 displays a diagram of the code.

Figure 4.3: PPC code (simplified)

As seen in the diagram the program does try to re-use code as much as possible and meth-
ods are limited as much as possible to only do one thing.

The PPC-program flows as shown in Figure 4.4 when trying to do an adaptation. The
PPC waits for input of what adaptation to do and then sends the first command to the
ECU. If the response is other than expected it will return an error to the PC, but if it is as
expected it will check if any more commands need to be sent to complete the adaptation.
If no more commands need to be sent it will instead test if the adaptation was successful
by asking for the status of the the setting. If the answer is what the PPC expects it will
return a positive message to the PC-software.

15
Figure 4.4: Flowchart of program

16
5 Experimental Setup and Results
This project had several experiments which will be discussed in short in this section and
then further evaluated in the analysis. All were performed with the same laptop running
Windows 11 OS-version: 22000.856. With the VCDS software at version 22.3, and the
Kvaser software at version 2.0a. The laptop was a Lenovo IdeaPad 14ITL05 with an i5
1135G7 and 8GB of RAM. The Autel Unit was a MaxiSys MS908S with the 2020-4
firmware. The VCDS unit to adapt between USB and OBD2 was a "Hex-V2". To read
the messages between the Autel unit and ECU or VCDS and the ECU a Kvaser USBCan
Professional for almost all experiments, but some were also performed with a generic
CAN to USB adapter. The result shown here will exclusively be from the Kvaser device
and software unless otherwise stated.

The first few experiments were to see how the data between the ECU and VCDS and/or
Autel looked to get a better understanding of what those systems did to change settings in
the ECU.

5.1 Read info from Toyota Yaris

The car in this experiment was a 2011 Toyota Yaris with a 1.0-litre 3-cylinder gasoline
engine. The objective was to read how the Autel device talked to the Toyota Yaris ECU
and determine what the different messages meant. This report focuses on the experiments
to change the "Key in ignition-warning chime" between its three settings "fast" "normal",
and "slow". Not that only the result from the first test is included here below although
Figure 6.1 is also part of this experiment. Figure 5.1 below shows the CAN traffic when
the key-in-ignition-chime is changed.

Figure 5.1: Key-in-ignition-chime adaptation

Rows (as indicated by the counter column) 1, 5, and 7 can be read as the Autel unit
asking the ECU what the setting is currently in. While row 2, 6, and 8 are responses to
these questions with the last two hexadecimal numbers telling the speed of the key-sound-
chime. Row 3 is the Autel unit telling the ECU to change the setting to the middle setting
(10) instead of the fast setting (20). The last two lines are saving the setting and leaving
the sub menu in the ECU.

17
5.2 Explanation of data
The data in Figures 5.1 and 5.3 is very cryptic, especially without knowledge of the hex-
adecimal number system. Therefore it will be quickly explained here in Figure 5.2 focus-
ing on the first two rows of Figure 5.1 which contains two separate CAN-frames.

Figure 5.2: Zoom on the first rows of Figure 5.1

Under the column "CAN Id" we have the self-reported ID number of the unit sending
the message. The column "Time" is the time Kvaser recorded the message from when
the recording was started in Kvaser. "DLC" stands for "Data Length Code". It signifies
how long the data section is and is specified in the CAN-standard [16], in this project all
CAN-communication had a DLC of 8. The "Data" column is the main focus of the project
and contains 8 sections of two bytes. The first section is just a field to tell the unit reading
the frame how many of the sections contain useful data. In the first row, this is 02, and
looking at the other sections we see that they are "21 a1 00 00 00 00 00" showing that it’s
only the first two bytes that contain the message for the receiver. "21 a1" is the setting
"Key-chime" in the ECU. In row two this column has changed to "03 21 a1 20 00 00 00
00" showing that the "20" is also important in this frame. "20" specifies at what speed
the key chime is set to. The "ASCII" column was not used in the project and it is only an
ASCII representation of the same data. The "Counter" is the message number since the
start of the recording. The "Signals" column was not used.

5.3 Read info from VW Caddy

The car in this experiment was a VW Caddy from 2016 with a 2.0-litre four-cylinder
diesel engine. The objective was to read the messages between both VCDS and the ECU
and between Autel and the ECU. Using both systems to see if there are different ways
of communicating the same instructions to the ECU. Figure 5.3 below shows the CAN
traffic when turning on "Gauge-sweep". The lines that have been filtered out were not
relevant to the adaptation.

5.4 VW Golf 7
The Caddy was not always available so the project started focusing on a VW Golf 7
from 2014 instead. The communication between VCDS/Autel remained the same when
activating gauge-sweep. By doing this on at least two very different cars Milestones 1,
and 2 are completed.

5.5 Sending messages to and from the PPC-unit

BSR provided a small program to see how the PPC worked but this code needed to be
rewritten to also be expanded upon. A program for the PC also had to be developed.
The first test to communicate between the PC and a car was to simply read the VIN
and make the PC software display it. The first couple of tries were failures due to some
minor mistakes in the code, but after a few iterations the test was successful and the VIN
appeared on the computer. This was verified to be the correct VIN by what the sticker on

18
 Figure 5.3: Gauge-sweep adaptation

the inside of the driver’s door said. The "B-pillar" is a common spot for such a sticker in
most cars on the road. By this Milestone 3 is started.

5.6 Performing an adaption on the Toyota

It was decided to adapt the Toyota a simple change of the speed at which the "key left
in ignition"-chime sounded. The first few tests failed for different reasons but after some
tweaking the car accepted the adaptation.

5.7 Performing an adaptation on the VW Golf

The experiment was to activate and then deactivate the setting called "needle-celebration"
or "Gauge-sweep" in the instrument cluster. This experiment failed at first due to the
"tester present"-the call did not get sent before the call to change the setting. Figure 5.4
shows a picture of the adaptation being performed. The adaptation was only successful 6
out of 10 times however and will be further discussed in the next chapter. This completes
Milestones 3-6. Figure 5.4 shows Gauge-sweep adaptation with the DEV-PPC.

19
 Figure 5.4: Gauge-sweep adaptation

6 Analysis
Data was gathered from the ECU using Autel for the Yaris, and both Autel and VCDS for
the Caddy and Golf. This was done by connecting a Kvaser unit between VCDS/Autel
and the car. The results then appeared in the Kvaser PC software, similar to what is shown
in Figure 5.2. To simplify the logs, some filtration was needed, especially on the Yaris
for reasons mentioned in further sections. Kvaser had an inbuilt filter used to filter out
completely unrelated calls on the CAN-Bus. Looking at some of the data gathered from
Yaris in Figure 6.1 below.

Figure 6.1: Changing Key-Chime to fast

20
In this image, there are six columns. The image is taken from a reading that tested what
happened when Autel was asked to change the ’Key in ignition-warning chime’ to fast.
The first column indicates which CAN-Id is sending the message. All units on the CAN-
Bus should have their CAN-Id, although, in this image, all except for the ECUs CAN-Id
for communication with Autel and Autel’s CAN-Ids have been filtered out. In practice,
hundreds of messages in the observed time frame were filtered out from the image to
increase clarity and readability. The second column simply shows how many seconds
have passed since Kvaser was instructed to record messages.
The third column informs that there are 8 bytes in every message. This is not relevant
in this project since CAN-BUS always uses 8 bytes. The fourth column, ’Data [Hex],’
is where the data of interest is found, showing what is being sent between the units in
Hexadecimal. Observing this a bit closer: ’02 21 a1 00 00 00 00 00’. The first part (02)
indicates how many of the bytes are active/in use in the message. It’s also where it can
be observed if the data requires more than one message/packet to be transmitted. In this
figure, it did not need to do that at any point; throughout the project, the only time that
was needed was during the reading of VINs since they are too long to be transmitted
otherwise.
Continuing on ’02 21 a1 00 00 00 00 00’, ’21 a1’ are the active bytes in the trans-
mission. It is not entirely clear why it is ’a1’, but it relates to the status of the ’Key in
ignition-warning chime’. ’21’ is a request for information according to the UDS protocol,
an open standard for CAN-Bus. The zeros at the end lead to the next row: ’03 61 a1 00’.
This row has 3 active bytes not counting the first one. ’61’ follows the UDS protocol for
responses, as ’61’ is a response to ’21’. Explaining the UDS protocol in its entirety is
outside the scope of this section.
Continuing, ’a1’ appears once again, suggesting it is the code for the ’Key in ignition-
warning chime’. In this message, the first two zeros indicate that the requested setting is
set to ’00’, which is based on other results not visible in Figure (6.1) but part of the same
test, including Figure 5.1. Continuing the reading, line three shows a request from Autel
to the ECU to change the setting of ’a1’ to ’20’ (which means ’fast’). ’3b’ is a request to
write to a setting, while ’7b’ is a positive response to that, as seen in line 4. Autel then
checks to see if the new value was accepted on lines 5 and 7, and finally disconnects at
line 9.

Figure 6.2 Gauge-Sweep activation communication.

21
 Figure 6.2: Gauge-sweep adaptation

This figure contains similar information to the last figure but is taken using VCDS on a
VW Caddy. When examining the data here, rows that are filtered out can be seen. In this
case, they are all ’tester present’ calls and would take up the whole figure if they were
all included. Therefore, they are all removed from the figure. It starts with checking the
status of something on the first row. During the project, the reason why VCDS checks this
setting was investigated, but the exact reason could not be determined. It was assumed
that it relates to whether or not the setting is active. In the next section, VCDS requests to
write data to the ECU, which the ECU accepts. VCDS then proceeds to ask if it can send
data over several packets. The ECU accepts, and VCDS writes two times, with the ECU
sending an ACK in between and after. The exact purpose of this action is not known, but
it appears that VCDS is changing some settings by doing this. In the second to last sec-
tion, VCDS attempts to change a setting, presumed to be the actual gauge-sweep setting.
The ECU initially declines but then changes its mind after 50ms. This was repeatable,
suggesting it is either an error in the ECU or a regular response to a change that cannot
be handled immediately. The last section shows a check from VCDS to see whether the
change has gone through.

The objective then was to read the VIN from the car and display it on the PC. After a
few attempts, this was successful, although there is no image of the results. This process
was a bit tricky since it involved reading several messages from the ECU and combining
them on the PPC before sending them to the PC, which read and displayed the VIN in a

22
box. This was only possible on the Caddy and Golf; attempts to do the same on the Yaris
failed. After checking with the Autel, it could not read the number either, leading to the
assumption that the Yaris lacks this capability. Further efforts with other tools have also
been unsuccessful in retrieving the VIN from the ECU. Figure 6.3 shows the UI before it
was able to retrieve the VIN from the VW Caddy, and another part of Figure 6.3 shows a
picture of the program while reading the VIN.

Figure 6.3: UI

Since the Yaris is a much simpler car in terms of ECU capabilities, an adaptation was
started on it first. It took a few tries since it was uncertain if it would work until it was
tested in an actual car. However, the key chime adaptation went well and was as simple
in terms of CAN messages as thought.
The last task was to try to activate and deactivate gauge-sweep. This task was much harder
to make work, even with the Yaris adaptations already done and most of the code being
reused. It still took some time to get it to work, mainly due to the ’tester present’ calls.
These calls had to be made before and at certain intervals. It was tested 10 times in a
row, with 5 activations and 5 deactivations. Only 4 activations and 3 deactivations were
successful. The exact reason for this was not determined due to time constraints, but one
guess is that the ECU might send a ’7f’ at first, which confuses the PPC. It could also be
a problem with the connection or with the ’tester-present’ call. Sadly no pictures of this
task were saved.

23
7 Discussion
The project revealed that adaptations in cars are more varied than initially expected. Cars
have different ECUs depending on brand, age, model, and engine. Occasionally, an ECU
is not capable of even the simplest tasks, such as responding with a VIN. However, these
simpler ECUs are often easier to understand and explain. In such cases, we can be rea-
sonably certain that a specific byte value has a specific meaning, such as "a1" referring
specifically to the "key in ignition" chime. In other situations, it can be significantly more
complicated to understand the bytes and their functions, especially when it is unclear why
a tool requests the status of a certain byte that is completely different from the one it later
changes. This lack of clarity is an area where car manufacturers could improve, making
the information more accessible to individuals not working directly for the manufacturer
or Bosch. Bosch, as the largest manufacturer of ECUs, has produced ECUs for all three
cars studied, yet they are very different across different brands. Companies like BSR of-
ten have to guess the meaning of the ECU signals when working with a new one, which
complicates their efforts to tune cars. A more open standard from the car industry or a
comprehensive manual on the ECU would benefit the industry as a whole.

Regarding the work done in this project, due to time constraints, The project was un-
able to develop a system that could also read fault codes, which was one of its initial
goals. Referring to the milestones from section 1.3, M1 was to decide on a suitable ECU.
In practice, however, work on the Yaris and the Caddy took place concurrently, partly due
to the Caddy not always being available. This concurrency did not significantly affect the
project; instead, it led to a better understanding of the CAN messages. M2 and M3 were
involved in investigating possible adaptations and how to implement them. This part of
the project was relatively straightforward. The project researched adaptations online and
in the VCDS and Autel software, then analyzed the log files created by Kvaser. M4 was to
design and create software for both the PPC and PC. This milestone undoubtedly required
the most time. Creating two software programs that communicate over serial is challeng-
ing with unfamiliar hardware. However, The project was successful in developing them
after some time of programming. We are not entirely satisfied with the end result or the
program’s current functionality. It lacks scalability in its present form, even though it
could be converted into the program we envision from Figure 8.1. Achieving this would
require time the project did not have. The project should have tested the software more
thoroughly at the beginning, but due to concerns about potential issues, it took the project
some time to test it as it was the next milestone. Eventually, the software was tested, and
it worked partially. At this point, the first adaptation was almost complete. It did not
work as initially predicted, so M6 was added to the list. M7 was never truly part of the
project since the work was carried out concurrently, but should we expand the program,
the project would follow that part as well.

7.1 Expert’s Feedback

BSR’s feedback on the finished project indicated overall satisfaction with the prototype
implementation. They described it as a "neat little program" that appeared to work well.
However, they highlighted areas where improvements were needed, particularly in terms
of code quality and the program’s flexibility. Regarding code quality, BSR emphasized
the need for enhancements to meet the standards required for a finished product. They

24
noted that the program lacked sufficient error checking and suggested implementing error
messages to enhance the user experience and provide better feedback in case of issues
or unexpected behaviour. Additionally, BSR mentioned that the process of adding other
cars or brands to the program could be made easier. This feedback suggests that the pro-
totype’s adaptability and scalability could be further refined to allow for more seamless
integration with different vehicle models or manufacturers.

This feedback aligns with the project’s aim to outline generalization steps toward other
ECUs, emphasizing the importance of considering additional adaptations and ensuring
ease of use for different contexts. BSR’s comments underscore the importance of contin-
uous improvement and refinement in software development projects. While the prototype
demonstrated positive functionality, addressing code quality, error handling, and ease of
adaptation are critical aspects to consider when aiming to develop a robust and market-
ready product. These insights from BSR provide valuable input for further enhancing
the program’s effectiveness, user-friendliness, and compatibility with various automotive
ECUs.

7.2 Results and Limitations

The result of the project is a successful prototype implementation of software aimed at
modifying automotive ECUs through the Controller Area Network (CAN) bus using On-
Board Diagnostics 2 (OBD2). The milestones achieved, including the selection of a suit-
able ECU (M1), investigation of data access and modification options (M2), implementa-
tion strategies(M3), design and implementation of the PPC and PC software(M4), testing
on real automotive ECUs(M5), and addressing potential issues(M6), have demonstrated
the feasibility and functionality of the prototype. However, there are limitations to the fi-
nal result and areas for improvement identified in the project. BSR’s feedback highlighted
the need for code quality improvements to meet the standards required for a finished prod-
uct. The program should incorporate better error checking and handling to provide users
with informative error messages and enhance overall reliability. Another limitation dis-
cussed is the ease of adding other cars and brands to the software. This suggests that
the prototype’s functionality could be improved to accommodate variations in ECU be-
haviour across different vehicle models and manufacturers. Variations in ECU behaviour
can arise due to differences in communication protocols, software configurations, and
hardware specifications between various car models. Therefore, developing a compre-
hensive understanding of these variations and implementing corresponding adaptations is
crucial for achieving broader compatibility across a wide range of vehicles. To address
these limitations and variations in ECU behaviour, further research and development may
be required. This could involve conducting more testing on different car models and ana-
lyzing the differences in their communication protocols and response patterns. By gaining
insights into these variations, the software can be changed to handle other ECUs, thereby
improving its flexibility and compatibility. Overall, while the project has successfully
demonstrated the potential of modifying ECUs through the CAN bus using OBD2, the
limitations and variations in ECU behaviour highlight the need for continuous refinement
and adaptation.

7.3 Project Reflection

Reflecting on the project, it has been a valuable learning experience that encompassed
various aspects of automotive technology, software development, and problem-solving.

25
The project involved modifying automotive Electronic Control Units (ECUs) through the
Controller Area Network (CAN) bus, requiring extensive research, experimentation, and
iterative development. Working closely with BSR, discussions and feedback played a
crucial role in shaping the project’s direction and ensuring that the chosen ECU and mod-
ifications aligned with their goals and customer needs. This collaborative approach was
instrumental in selecting a suitable ECU, understanding data access and modification op-
tions, and addressing potential issues. In terms of technical implementation, developing
the PPC and PC software using appropriate integrated development environments (IDEs)
and programming languages significantly enhanced my technical knowledge. The project
served as a platform for gaining practical experience in automotive technology, software
development, and problem-solving. It highlighted the complexities and challenges asso-
ciated with modifying ECUs and navigating the CAN bus.

26
8 Conclusion
These are some of the conclusions drawn after the project, highlighting areas that need
improvement and potential future work.

8.1 Thesis Summary

In this project, We have researched how the CAN-Bus system operates and programmed
a microcontroller to perform simple adaptations for two different cars. We utilized both
Autel and VCDS tools to understand how they interact with the ECU to make changes and
recorded these interactions to enable my microcontroller to perform similar adaptations.
Although the results are smaller in scope than initially hoped, We believe they will be
beneficial for future research into CAN-Bus systems and how to read from and write
to them. While my results are specific to the cars used in this project, they should be
generally applicable to other brands and CAN-Bus systems. There is much more we
would have liked to accomplish given more time. One improvement We would make
is to ensure better documentation of certain aspects, as some parts of this report were
challenging to write due to a lack of images and detailed documentation on how the tests
were conducted.

8.2 Milestones Summary

Table 8.1: Thesis Project Milestones

M1 Decide on a suitable and available automotive ECU to focus on

M2 Investigate the available data access and modification options for the
CAN bus using OBD2
M3 Investigate how to implement the modifications
M4 Design and implement the PPC and PC software
M5 Test the software on a real automotive ECU
M6 Address potential issues (bugs)
M7 Outline the generalization steps towards other ECUs

Looking back at the milestones they were completed by:

27
 Table 8.2: Thesis Project Milestones Summary

M1 The project took the cars available at hand, In this case, one Toyota
and two VW.
M2 Was done by plugging in an of the shelf OBD2 tool in the ports and
reading the data via a Kvaser tool
M3 Was done by performing an analysis of the CAN-Bus data traffic
when applying different settings making sure to filter out unwanted
data
M4 Was done throughout the project by continuously switching between
writing code and analysing the CAN-bus traffic
M5 Was done by plugging in the DEV-PPC in the cars and performing a
test run and reading the results from the Kvaser tool
M6 Was done throughout the coding process but especially after the first
tests of the software connected to an actual car
M7 This will be further described in section 8.4 but in short the whole
project was done with an emphasis on expandability so that adding
more ECUs would be simple.

8.3 Feedback from the company

Since BSR was a part in this project, their opinion is important to get an idea of the
finished project. In short their feedback was that it was "a neat little program" that seemed
to work well. In terms of code quality, it would have to be improved to be able to go into
a finished product. The program doesn’t check enough for error messages, and the ability
to add other cars or brands could be a bit easier. These are things discussed a bit in the
next section.

8.4 Future Work

First and foremost, a more reliable source of information on how the ECUs operate,
preferably from Bosch or the car manufacturer, would be highly beneficial, although such
sources do not seem to be readily available. This would reduce much of the guesswork
involved in the project and allow a greater focus on the code development. The current
code, while functional, is not optimal. Transitioning from the current state, as depicted
in Figure 4.4, to a more advanced version, as shown in Figure 8.1, would facilitate the
easy addition of further adaptations and enable the same adaptation function to be applied
across multiple cars where applicable. Additionally, extensive research on adaptations for
various brands and models, followed by integration into the improved code, would sig-
nificantly enhance the project’s applicability. Incorporating the ability to read fault codes
would be a valuable addition, though it would require substantial work and modifications
to the existing code.

28
 Figure 8.1: Intended PPC-Code structure

This would enable the easy addition of further adaptations and also connect the same
adaptation function to several cars in a situation where they are the same. We would also
like to research a lot more adaptations for more brands and models and put them into my
improved code.
We would also like to add the ability to read fault codes but that would require a lot work
and changes to the code.

29
References
[1] Y. Niimi, ECU Technologies from Components to ECU Configuration. John Wiley
& Sons, Ltd, 2014, pp. 1–15.

[2] “BSR Webpage,” https://sv.bsr.se/, accessed: 2024-05-22.

[3] N. Navet, Y. Song, F. Simonot-Lion, and C. Wilwert, “Trends in automotive com-

munication systems,” Proceedings of the IEEE, vol. 93, no. 6, pp. 1204–1223, 2005.

[4] R. Li, C. Liu, and F. Luo, “A Design for Automotive CAN bus Monitoring System,”
in 2008 IEEE Vehicle Power and Propulsion Conference, 2008, pp. 1–5.

[5] G. Wacker, “M3 Pi: OBD-II Touchscreen Car Computer,” California Polytechnic
State University, Computer Engineering Senior Project, 2017.

[6] M. Bozdal, M. Samie, S. Aslam, and I. Jennions, “Evaluation of Can Bus

Security Challenges,” Sensors, vol. 20, no. 8, 2020. [Online]. Available:
https://www.mdpi.com/1424-8220/20/8/2364

[7] Y. Zhu, CAN and FPGA Communication Engineering Implementation of a CAN bus
based Measurement System on an FPGA Development Kit. Hamburg: Diplomica
Verlag, 2010.

[8] J.-N. Luo, C.-M. Wu, and M.-H. Yang, “A CAN-bus Lightweight Authentication
Scheme,” Sensors (Basel, Switzerland), vol. 21, no. 21, p. 7069, 2021.

[9] F. Amato, L. Coppolino, F. Mercaldo, F. Moscato, R. Nardone, and A. Santone,

“Can-bus attack detection with deep learning,” IEEE Transactions on Intelligent
Transportation Systems, vol. 22, no. 8, pp. 5081–5090, 2021.

[10] C. Smith, The Car Hacker’s Handbook: a Guide for the Penetration Tester.
William Pollock, 2016.

[11] [Online]. Available: https://commons.wikimedia.org/wiki/File:OBD-II_type_A_

female_connector_pinout.svg

[12] C. Electronics, 2022. [Online]. Available: https://www.csselectronics.com/pages/

obd2-explained-simple-intro

[13] “Road Vehicles — Controller Area Network (CAN) — part 1: Data Link Layer and
Physical Signalling,” Standard, Dec. 2015.

[14] M. Di Natale, Understanding and Using the Controller Area Network Communica-
tion Protocol: Theory and Practice. Springer Verlag, 2011.

[15] S. International, 2018. [Online]. Available: https://www.sae.org/standards/content/

j1939_201808/

[16] KVASER, 2022, accessed: 2024-05-22. [Online]. Available: https://www.kvaser.

com/

[17] S. International, 2016. [Online]. Available: https://www.sae.org/standards/content/

j1708_200408/

30
[18] Tim, “ECU Explained,” 2022. [Online]. Available: https://www.ecutesting.com/
categories/ecu-explained/

[19] J. Sobotka and J. Novák, “Qualitative Software Engineering Research: Reflections

and Guidelines,” Measurement: journal of the International Measurement Confed-
eration, vol. 100, pp. 213–222, 2023.

[20] “Documentation STM32F407/417,” 2022. [Online]. Available: https://www.st.com/

en/microcontrollers-microprocessors/stm32f407-417.html#overview

[21] P. Lenberg, R. Feldt, L. Gren, L. G. Wallgren Tengberg, I. Tidefors, and D. Graziotin,

“Qualitative Software Engineering Research: Reflections and Guidelines,” Journal
of software : evolution and process, 2023.

[22] Y. S. L. Norman K. Denzin, The SAGE Handbook of Qualitative Research. SAGE,

2011, ch. 17.

[23] P. Crispen and R. R. Hoffman, “How Many Experts?” IEEE intelligent systems,
vol. 31, no. 6, pp. 56–62, 2016.

[24] Vector, accessed: 2024-05-22. [Online]. Available: https://elearning.vector.com/

mod/page/view.php?id=333

[25] R. Verdecchia, E. Engström, P. Lago, P. Runeson, and Q. Song, “Threats to Validity

in Software Engineering Research: A Critical Reflection,” Information and software
technology, vol. 164, pp. 107 329–, 2023.

[26] K. Petersen and C. Gencel, “Worldviews, Research Methods, and their Relationship
to Validity in Empirical Software Engineering Research,” 2013.

31
A Appendix 1 PPC code
Link to GitHub: https://github.com/S253/PPC_CODE

B Appendix 2 PC code
Link to GitHub: https://github.com/S253/PPC_APP