Professorship Computer Engineering

Automotive Software Engineering

Prof. Dr. Dr. h. c. Wolfram Hardt
Hasan Saadi Jaber Aljzaere, M. Sc.
Dipl.-Inf. René Bergelt
Practical Basics of automotive software engineering and an Winter Semester
Unit 1 introduction to the evaluation boards 2023/2024

Content
1. Basics ................................................................................................................................................. 1
1.1. ECUs in Modern Automobiles ............................................................................................. 3
1.2. Sensors – ECUs – Actuators .............................................................................................. 4
1.3. Evaluation Board ................................................................................................................... 4
1.4. Practical Examples ............................................................................................................... 5
2. Experimental Procedure .................................................................................................................. 6
2.1. Programming Microcontrollers........................................................................................... 6
2.2. Initial Setup ............................................................................................................................ 7
3. Unit 1 Tasks..................................................................................................................................... 10
3.1 Task 1 - Pin Configuration ....................................................................................................... 10
3.2 Task 2 – Analog Pin Configuration ........................................................................................ 11
3.3 Task 3 – Buttons and Timers .............................................. Fehler! Textmarke nicht definiert.
List of References ............................................................................................................................... 12

1. Basics
For more than a hundred years, motor vehicles are produced and improved. The use of
microelectronics provided new possibilities for engineering and implementation of complex
functionalities for automobiles. Today most car drivers use their automobile for more than one
hour per day, this results in increasing demands of the driver to the vehicle. To meet all the
demands the usage of hardware and software in automobiles increases rapidly. The fast and
reliable reaction of automotive functions is assured by software, electronic control units and
their communication amongst each other. Furthermore former mechanical functions were
replaced by software, electronic control units, sensors and actuators. Today luxury class
automobiles contain up to 80 connected electronic control units i.e. engine management,
airbag control, power locks and electric windows. In the case of the electric windows the
software automatically reverses/stops the window motor if it senses an obstruction while
closing.

1
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
Nowadays 90% of the innovations in car development concern the electronics and the
software. That includes the conversion of classic mechanic functions as well as new features
for example the automatic parking system.

For the practical automotive specific terms are necessary which are explained in Table 1.

Table 1 Automotive specific terms and definitions

Termrm Definition
Embedded system Computer with special purpose. Serves to control and monitor a
system.
Distributed systems Computer network which communicates by message exchange.
Interactive systems Hardware and software components which process user input
and return results.
Reactive systems Hardware- and software components which interact
permanently/cyclic with the environment. Reactive systems
normally do not terminate.
Real-time system Computer system, which guarantees the calculating of a job
within a predefined deadline (time limit). It is differentiated
between hard, firm and soft real time.
Communication The communication in the automotive domain describes the
message exchange of distributed and embedded systems with
the help of protocols.
Reliability Ability of a system to consistently perform its required function
within a specified time limit without degradation or failure.
Availability Proportion of time a system is in a functioning condition.
Security Extent to which a system is protected against data corruption,
destruction, interception, loss or unauthorized access.
Monitoring Observing of the current system status to detect failures and to
initiate counteractions.
Electronic control An electronic control unit (ECU) is an embedded system which
unit controls one or more of the electrical subsystems in a vehicle.
Sensors, actuators and ECUs are often one unit in mechatronic
systems.
Sensors Electronic device used to measure a physical quantity such as
temperature, pressure or loudness and convert it into an
electronic signal
Actuators Transformation of electronic signals from an ECU into mechanical
respectively physical quantities.

2
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
1.1. ECUs in Modern Automobiles
Increasing customer demands, such as lower fuel consumption, improving of driving safety
and comfort are closely related to the use of more and more electronics and software in
modern automobiles. The requirements of the ECUs in today´s automobiles are the following:
• Reliable under rough and changing ambient conditions like temperature, humidity and
vibration
• High demands to the dependability and availability
• High demands to the security

ECUs work as a reactive system. The driver has no influence on the functionality except from
activating sensors (e.g. switches).

Figure 1 ECUs connected by a bus system cf. [1]

This easy, general example demonstrates the interconnection of the controllers and their
communication over a bus. It is typical for a bus that the data transfer is realized via messages.
Therefore the developer has the ability to send information resp. messages (for example the
outdoor temperature) from one ECU to 1 or several others over the bus. The installed ECUs are
divided into the following subsystems:

• Engine
• Chassis
• Car body
• Multimedia
• Security

To stress the importance of the interconnection and the categorization of ECUs, the following
example shall be used. The ACC (Adaptive Cruise Control) is an add-on for the cruise control.
The system maintains a steady speed as set by the driver and automatically keeps the
necessary security-distance. When approaching a slower vehicle the speed is adjusted to the
speed of the preceding vehicle and thus the security distance is kept. If the distance increases
the systems accelerates up to the defined speed. To realize this function several ECUs are
necessary in the automobile. The ACC-ECU communicates with the engine-, the ESP- and the
gearbox ECUs to adjust the driving speed. ESP is necessary to selective decelerate individual
wheels to avoid the vehicle breaks away.

3
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
This simple example shows the importance of the communication between the affected ECUs.
Only by interaction of the different ECUs the functionality of the ACC can be displayed. It also
shows that simple features need complex implementations.

1.2. Sensors – ECUs – Actuators

Sensors deliver the data which is then analyzed by the ECU. They measure physical quantities
and convert them into electric quantities, so they can be processed. There are various types of
sensors that react to different physical quantities, such as air pressure, humidity, light intensity,
distance, temperature or density. The ECU periodically reads the sensor data and processes
the implemented software. At this point it is decided whether an actuator is activated or not. If
the sensor data differs between the periods in most cases the actuators are accessed by the
ECU to react on the environmental changes. Furthermore the actuators can be accessed if
sensor data have arrived at certain threshold. A simple example is the headlight which is
automatically switched on at nightfall. A photodiode measures the light intensity and forwards
it to the ECU. If the intensity of the light falls below a threshold the headlights are turned on.

The following graphic shows the relation between sensor, ECU and actuator.

Figure 2 Components needed for a closed control loop

The graphic shows the function of an electronic window. A simple switch serves as the sensor.
Once the switch is pressed the ECU activates the actuator, in this case the electric window
motor. The ECU is responsible for automatic reversing the electric windows if it senses an
obstruction while closing.

1.3. Evaluation Board

Details about the hardware and software tool chain that are to be used with this practical will
be provided during the lecture

There are several sensors and actuators already on the board, no more components are
needed for simple experiments. Please study the tasks under point 2 and the sources provided
on OPAL.

4
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
1.4. Practical Examples
Closed control loop
Many ECUs form closed control loops, where an
actor is controlled based on the readings of a
sensor. By driving the actor the measured
environment is influenced and subsequently the
future readings change.
A typical example for this is climate control, where
the sensor is a thermometer and the actor is the
heating / cooling unit. Based on the target
temperature the ECU heats or cools the inside of the
car or stays idle.
Another example is the window regulator. The
switch panel serves as sensor and the window
motor as the actuator. The entrapment protection
and the up and down moving functions are software
implementations on the ECU.

Communication between ECUs

To enable the communication between ECUs,
messages are defined and transmitted over wires.
One ECU serves as the user interface (e.g. as part of
the steering wheel) which sends messages to the
indicator ECU when an indicator is activated. There
the message is read and the respective indicator
light is turned off or starts blinking.

Dashboard of a Volkswagen Polo V 6R

The real hardware dashboard serves as a
demonstrator on how a cockpit functions by
communicating with an ECU. All relevant warning
and indicator lights as well as the speedometer and
rev meter can be controlled.
One task of Practical Unit 2 is to control this
dashboard using an ECU which you have to
implement.

Development of functionality for the

Black Pearl Demonstrator Car
The Black Pear provides many sensors and
actuators which can be used for the implementation
of different functions. Amongst others the flashing
indicator control and engine management are
implemented.

5
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
2. Experimental Procedure

2.1. Programming Microcontrollers

Microcontrollers are integrated circuits which contain a processor, memory and specific
hardware periphery modules. The hardware modules can perform digital and analog functions
like general purpose in- and output (GPIO), pulse width modulation (PWM), timers, and analog
to digital converters (ADC). Sometimes peripheral modules for communication are also
integrated, e.g. CAN, FlexRay, Ethernet, SENT, I2C, and SPI. These modules can be accessed
and configured by integrated registers.

Microcontrollers are generally programmed in Assembler or in C language. In this practical

course, the higher level language C is used to program the ECUs. This kind of programming is
similar to programming software for PCs. But in embedded systems, the programs access the
registers directly to configure the peripheral modules by setting certain bits to activate a
desired peripheral function on a particular microcontroller pin. Once the pins are configured
for a particular peripheral function, other registers are used either to control or to receive a
value from the environment. For this purpose the memory addresses of the registers are used,
which are defined in the reference manual of the specific microcontroller. Hence we use
register addresses rigorously to access information from peripheral modules.

In general, the pins of the microcontroller are organized by ports. Every port of the
microcontroller has a set of pins. Each port can only perform certain tasks due to limited
support for remapping peripheral functions. More details of it can be found in the reference
manual.

Figure 3 shows an extract of the reference manual of the microcontroller, which can be found
at [2]. It shows the structure of the pad configuration register (PCR) of the System Integration
Unit Lite (SIUL) module, which is used to configure digital in- and outputs.

Figure 3 SIUL pad configuration register (PCR) [2]

To access the PCR registers in C code, it is possible to directly access the base address of the
registers or to write “SIU.PCR[X].R“, which is a macro defined in the “xpc56el.h“ header file.
The meaning of bit fields is also described in the reference manual.
Example:

Objective: Configure port B8 of an SPC56EL60 microcontroller as a digital output and then set
it low.

6
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
Look into the reference manual and find the port pin. As shown in Figure 4, port pin B8 supports
general purpose in- and output (GPIO) and the corresponding PCR number is 24 (PCR[24]).

Figure 4 Pin list and multiplexing [2]

To configure an I/O pin the “output buffer enable” bit (OBE) must be set. In Figure 3 the OBE
bit is at position 6. To set this bit, “0x0200” (hexadecimal), “0b0000001000000000” (binary),
or “512” (decimal) could be written to the register, but there are also several other ways to set
this bit. The compiler used in this practical course doesn’t care about the way it is done. In C it
can look like this for port B8 of the STM SPC56EL60 microcontroller:
SIU.PCR[24].R = 0x0200; /* configures port B8 as output */
To activate the output as “low signal”, a “0” must be written to the corresponding general
purpose digital output register (GPDO).
SIU.GPDO[24].R = 0; /* sets port B8 low */
Every module on the microcontroller can be configured in a similar way. In the reference
manual all functionalities and registers are described. These are the basics of microcontroller
and driver programming.

Note: Every microcontroller has its own individual modules and registers. That’s why it is
necessary to read the reference manual and to program new drivers when the hardware is
changed.

2.2. Initial Setup

To implement functions on the ECU, the “SPC5 Studio” IDE will be used. To flash code to the
board “UDE Starterkit 5.2” is used.

The first step is opening the “SPC5Studio Ide” that is located on Desktop or on windows
menu in “SPC5Studio” folder.

After successfully opening the Ide then click on File -> Open Projects from File System :

7
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
In the next window click Directory -> (Locate the folder which contains the project of Unit_1
downloaded from OPAL) -> Finish. Now you will be able to see your project folder in “Project
Explorer” Menu located in left side of the IDE.

The project “Unit1\Unit1“ (Source code in the appendix) has to be opened in the SPC5 Studio
IDE. Analyze and study the source code on the file “main.c”. Building the project is done by
pressing the “Build SPC5 Application” button in the IDE. After building the project successfully
without any error, the next step is debugging. Clicking on “Launch UDE debugger” button on
the IDE will open the debugger window. Now the output file generated by the Ide shall be loaded
to the debugger as shown in the figure above :

8
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
After loading the output file to the debugger, the previously flashed code shall be erased by
clicking Erase -> Erase whole FLASH Module -> Start. Next step is flashing the output file that
we loaded to the controller by clicking Program All.

Finally start the program by either clicking the “Start Program” button or by clicking F5.

9
ASE Practical: Automotive Software Engineering Practical Course - Unit 1
3. Unit 1 Tasks

3.1 Task 1 - Pin Configuration

1. Refer to the additional document (“pin_muxing.pdf”) provided to identify the “PCR”
register associated with each port pin.
2. Find the mapping of peripherals onto different pins of the controller on the first page of
the additional document.
3. Identify the IO port pin mapping of the used evaluation board from Table 2. For example,
Rx LED corresponds to port pin PC4, and the “PCR” register number for this LED from
the additional document is “36”.
4. Output pin configuration:
1. Use the function “Siu_Init()” in file “siu.c” to configure the corresponding pin as
an output. For the LEDs, write “0x0200” to the corresponding configuration
register (“PCR”).
2. To turn on an LED, write “0” in the corresponding output register (“GPDO”)
using “SIU.GPDO[X].R = 0;” where X stands for the corresponding “PCR”
register.
3. To turn off an LED, write “1” to the corresponding output register (“GPDO”)
using “SIU.GPDO[X].R = 1;” where X stands for the corresponding “PCR”
register.
5. Input pin configuration:
1. Find the correct "PCR" register for the button or switch you want to use.
2. Configure the button as input by writing "0x0100" to the corresponding PCR
register.
3. Check for a button press or switch "ON" action by reading the input register of the
corresponding pin using "SIU.GPDI[X].R", where X stands for the corresponding
PCR register number.
6. Analog input pin configuration:
1. Modify the “Siu_Init()” function to include the code for the analog pin
configuration.
2. Configure the controller pin mapped to the ADC module for analog input by
writing “0x2500” to the corresponding “PCR” register. Refer to Table 2 for the
corresponding port/pin.

ASE Practical: Automotive Software Engineering Practical Course - Unit 1 10

 Table 2 IO Port Pin Mapping cf. [3]
Feature MCU Pin Name Comments Type
SW1 D[7] 1 - active 0 - inactive Input
SW2 D[6] 1 - active 0 - inactive Input
SW3 D[4] 1 - active 0 - inactive Input
SW4 D[5] 1 - active 0 - inactive Input
BT5 D[9] 1 - active 0 - inactive Input
BT6 D[8] 1 - active 0 - inactive Input
P (LED) A[9] Light when command is high Output
Rx (LED) C[4] Light when command is high Output
Tx (LED) C[5] Light when command is high Output
U1 (LED) A[6] Light when command is high Output
U2 (LED) A[7] Light when command is high Output
U3 (LED) A[8] Light when command is high Output
POT E[2] External analog input Input
LDR C[0] External analog input Input

3.2 Task 2 – Reading Potentiometer

1. Use “task_pot(int value)” function for this task.
2. This task must be called if the condition below is true.
SW1 = 1, SW2 = 0, SW3 = 0
3. Read the value of the potentiometer using “(ADC0.CDR[5].R & 0x00000FFF)” and call
the “task_pot” function using the value as parameter.
4. Control all LEDs according to the Table 3 below.

Table 3 Potentiometer function table

Pot Value (x) U1 U2 U3 Tx Rx P
x < 682 0 0 0 0 0 1
682 < x < 1364 0 0 0 0 1 1
1364 < x < 2046 0 0 0 1 1 1
2046 < x < 2728 0 0 1 1 1 1
2728 < x < 3410 0 1 1 1 1 1
x > 3410 1 1 1 1 1 1

3.3 Task 3 – Reading Light Sensor

1. Use “task_ldr(int value)” function for this task.
2. This task must be called if the condition below is true.
SW1 = 0, SW2 = 1, SW3 = 0
3. Read the value of the light sensor using “(ADC1.CDR[3].R & 0x00000FFF)” and call the
“task_ldr” function using the value as parameter.
4. Control all LEDs according to the Table 3 above but using light sensor value.

ASE Practical: Automotive Software Engineering Practical Course - Unit 1 11

3.4 Task 4 – Binary Counter using Timer
1. Choose a valid timer channel (1-3) to use for the project.
2. Configure the timer by calling "PIT_ConfigureTimer(int timerChannel, unsigned int
time)" with the chosen timer channel and a valid time in milliseconds.
3. Start the timer by calling "PIT_StartTimer(int timerChannel)".
4. Stop the timer by calling "PIT_StopTimer(int timerChannel)".
5. When the interrupt occurs, the corresponding timer function (e.g. "Pit_Channel_1()") is
automatically called.
6. Use “task_counter()” function for this task.
7. This task must be called if the condition below is true.
SW1 = 0, SW2 = 0, SW3 = 1
8. The timer must only operate when SW4 is active.
9. The counter value must be changed every 1 second.
10. Control U1, U2 and U2 LEDs according to Table 4 below.
11. As default the counter must behave as up-counter (incrementing). If the BT6 pressed it
must behave as down-counter (decrementing). If the BT5 pressed it must behave as up-
counter again.
12. The counter must be circular that means;
1. When the value exceeds 7 must return 0.
2. When the value smaller than 0 must return 7.
13. Note that Timer function 0 is already started and used by the controller system itself and
cannot be used.
14. Do not call interrupt functions like "PIT_Channel_1()" as they are preconfigured and
invoked automatically when a particular interrupt occurs.

Table 4 Binary counter function table

Counter Value U1 U2 U3
0 0 0 0
1 0 0 1
2 0 1 0
3 0 1 1
4 1 0 0
5 1 0 1
6 1 1 0
7 1 1 1

List of References
[1] Schäuffele, Jörg; Zurawka, Thomas: Automotive Software Engineering. Wiesbaden: Springer
Vieweg, 2013
[2] STMicroelectronics: SPC56EL60x Family Reference Manual. URL:
https://www.st.com/en/automotive-microcontrollers/spc56el60l5.html (15.04.2020)
[3] Raisonance S.A.S.: REva v3 User Guide. 2010

ASE Practical: Automotive Software Engineering Practical Course - Unit 1 12