Available online at www.sciencedirect.

com Procedia
Engineering
Procedia Engineering 00 (2011) 000–000
Procedia Engineering 30 (2012) 983 – 988 www.elsevier.com/locate/procedia

International Conference on Communication Technology and System Design 2011

Worst Case Execution Time Analysis of Automotive

Software
Sneha Chattopadhyaya, Tresina M.Jb, Shankar Narayanb, a*
a,b
Dept. of Electronics and Communication, Amrita School of Engineering, Bengaluru Campus
Kasavanahalli, Carmelaram P.O. Bengaluru - 560 035, India

Abstract

Knowing the program timing characteristics is fundamental to the successful design and execution of real-time
systems. The Worst-Case Execution Time (WCET) of a program is the longest execution time that will ever be
observed when the program is run on its target hardware. The WCET is needed for many different types of system
analysis for real-time systems. Timing becomes the most important factor while considering the distributed
automotive embedded real-time systems. Handling real-time constraints to add more functionality to a vehicle is
required while modelling these systems. In this present study the WCET estimate is obtained by measurement-based
method using in-circuit emulator for a given set of input data. Many existing methods of WCET analysis require the
availability of the source code of the program in order to estimate WCET. Here, the measurement-based analysis is
performed which is solely based on execution traces of the program and is independent of the program semantics.

© 2011 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of ICCTSD 2011
Open access under CC BY-NC-ND license.
Keywords:Worst case execution time; measurement method; CPU load; embedded system

1. Introduction

Most of the manufactured computer processors are used in embedded systems. The embedded systems
have time constraints, which mean that the computer that controls such a system not only has to compute
the correct result, but is also required to produce the correct result in a specific time interval. The time
constraints are often expressed by temporal deadlines that must be met by the software tasks in the
system. It is therefore important to know how long the system needs to execute each individual task. The
maximum or worst-case execution time, WCET, is an upper bound for all the possible execution times of
such a task and it is one of the timing properties that should be studied in order to have a feasibility study

* Sneha Chattopadhyay. Tel.: 080-25294389

E-mail address: [email protected]

1877-7058 © 2011 Published by Elsevier Ltd. Open access under CC BY-NC-ND license.
doi:10.1016/j.proeng.2012.01.954
984 Sneha Chattopadhyay et al. / Procedia Engineering 30 (2012) 983 – 988
Sneha Chattopadhyay, Tresina M. J., Shankar Narayan/ Procedia Engineering 00 (2011) 000–000

of a system. The WCET may be obtained by various methods. Generally, these methods are classified
into two categories: dynamic methods and static methods. Dynamic methods derive the WCET by
measurements. The program code executes, and the execution time is measured by hardware or software,
such as an in-circuit emulator and time-functions provided by the operating system. The determination of
the WCET of a program or task is an important prerequisite when verifying response times in hard real-
time systems [1]. Dynamic WCET analysis is based on executing the program with many different inputs
and measuring the execution time for each run. The advantage of using this method is that the actual
hardware can be used to execute the program, which gives more accurate worst case timing information.
There are different kinds of measurement techniques used in practice, the most important techniques and
tools used today are: emulators, oscilloscopes, logic analyzers, hardware traces, high-resolution timers,
performance counters, etc. These techniques are described in more detail in [2]. In the present work the
WCET is measured by dynamic method. This analysis is performed based on execution traces of the
program and is independent of the program semantics. An in-circuit emulator is used for the timing
measurements. The objective of the present study is to analyse the worst case execution time for a given
set of periodically running tasks which are the time consuming elements in the electronic control unit
(ECU) software modules, and subsequently calculate the CPU load of the ECU under the stressed
condition.

2. Methodology used in WCET analysis

2.1 Measurements (dynamic timing analysis) for WCET analysis and CPU load
In this approach, the program is executed many times with different inputs and the execution time is
measured for each test run. An in-circuit emulator behaves like a particular processor, but with better
debug and inspection capabilities. The measure of the time spent doing idle processing, in a sense,
indicates how much real-time processing is occurring. The CPU utilization or time-loading factor, U, is a
measure of the percentage of non-idle processing. A system is said to be time-overloaded if U >100%. U
is calculated by summing the contribution of utilization factors for each task. Suppose a system has n ≥ 1
periodic tasks, each with an execution period of pi , and hence, execution frequency, fi = 1/pi. If task i is
known to have (or has been estimated to have) a maximum (worst case) execution time of ei , then the
utilization factor, ui , for task ei is given by[3],
ui ei / pi (1)
Then the overall system utilization is given by [3],
n n
U ui ei / pi (2)
i 1 i 1
2.2 Test Setup for WCET Measurement
The ECU software is run in 3 tasks, all tasks are assigned a priority as shown in Table 1.
 Sneha Chattopadhyay, Tresina M. J., Shankar Narayan / Procedia Engineering 00 (2011) 000–000
Sneha Chattopadhyay et al. / Procedia Engineering 30 (2012) 983 – 988 985

Table 1: Tasks and their assigned priorities

Task Priority
A 1
B 2
C 3

Task A has the highest priority and Task C has the lowest priority. Priorities are defined statically and
cannot be changed at run-time. At a context switch the task with the highest priority gets to execute.
Tasks of identical priority are activated in FIFO (First In First Out) order. Each task has a given set of
requirements running periodically. Each requirement is an ECU software module, which has a certain
functionality in the vehicle, such as, antilock-brake system, cruise control system, etc. Task A has 2
requirements, task B has 4 requirements and Task C has 2 requirements. Table 2 shows the periodicity of
each requirement.

Table 2: Requirements of each task with their respective periodicity

Periodicity
Task Name of Requirement
(in milliseconds)
A Req_1 10
A Req_2 10
B Req_3 20
B Req_4 20
B Req_5 20
B Req_6 20
C Req_7 100
C Req_8 65

In the OS based system a task overrun is a scenario where every periodic requirement in the task with
least priority would get its turn for execution without fail under all conditions. In case of the ECU it can
be observed that the task C has the least priority and the hard requirement is that all the periodic
requirements in task C would get its turn for execution. A watchdog timer can be configured for the
100ms requirement in task C, 20ms requirement in task B and a 10ms requirement in task A. If any of the
requirements does not execute due to overruns, then the watchdog timer would cause a reset of the ECU.
2.3 Test Procedure for WCET Measurement

The motivation behind the measurement-based approach is that computing hardware (the CPU in
particular) has reached a complexity which is extremely hard to model. In particular, the modeling
process can introduce errors from several sources: errors in chip design, lack of documentation, errors in
documentation, errors in model creation; all leading to cases where the model predicts a different
986 Sneha Chattopadhyay et al. / Procedia Engineering 30 (2012) 983 – 988
Sneha Chattopadhyay, Tresina M. J., Shankar Narayan/ Procedia Engineering 00 (2011) 000–000

behavior to that observed on real hardware. Thus the measurement method accounts for these errors since
the analysis is performed on the actual hardware.
In the present procedure, the inputs for each requirement is fed in, processed and then the outputs are
collected back. During this process a timer is used to measure the time taken to process the given set of
inputs Time values for all available inputs are collected and the minimum and the maximum (worst case)
measurements observed for these set of inputs is used for the analysis. During the time measurement all
the interrupts are disabled so that the time measured is only the time consumed by the software
requirements under the test. The minimum and maximum CPU load due to each task is calculated from
the corresponding time measurements using formula (1) and (2). The deviation in the CPU load is then
obtained.

2.4 Test procedure for trace logs

The time consumption (in %) per requirement is obtained from experiments when the individual tasks are
run, and the total time consumption for each task is obtained which corresponds to the current CPU load
due to the respective task. Thus, the possible increase in CPU load for each task can be calculated from
the value of deviation obtained from time measurement applied to the current value of CPU load obtained
from the trace results. The new value of CPU load is used to determine a theoretical WCET for the ECU.

2.5 Worst case execution analysis observation

Results from the time measurement setup and the trace logs are used in the WCET analysis for the ECU
and are tabulated.

2.5.1 Time measurement test results

Table 3: Time Measurement Test Results

Task A Requirements Deviation

Module Min time(in µs) Max time(in µs)
Req_1 455.76 465.45
Req_2 123.64 140.61
%Load 5.79% 6.06% 0.05
Task B Requirements
Module Min time(in µs) Max time(in µs)
Req_3 1760.00 2096.97
Req_4 853.33 976.97
Req_5 12.12 16.97
Req_6 2298.18 3706.66
%Load 24.62% 33.99% 0.38
Task C Requirements
Module Min time(in µs) Max time(in µs)
Req_7 734.54 906.67
Req_8 72.73 121.21
%Load 0.85% 1.09% 0.29
 Sneha Chattopadhyay, Tresina M. J., Shankar Narayan / Procedia Engineering 00 (2011) 000–000

Sneha Chattopadhyay et al. / Procedia Engineering 30 (2012) 983 – 988 987

2.5.2 Trace results

The results of the execution traces are obtained and tabulated as follows.
Table 4: Task A Requirements

Module and function names %Time Consumption

Req_1 0.69
Req_2 0.32
Function_1 2.58
Function_2 2.22
Function_3 0.44
Total time consumption in %(Task A
Requirements) 6.25%

Table 5: Task B requirements

Module and function names %Time consumption

Req_3 7.97%
Req_4 4.53%
Req_5 1.56%
Req_6 0.05%
Function_1 3.48%
Function_2 7.20%
Function_3 1.70%
Total time consumption in %(Task B
Requirements) 26.49%

Table 6: Task C requirements

Module and function names %Time consumption

Req_7 1.25
Req_8 0.17
Function_1 1.03
Function_2 2.18
Function_3 0.34
Total time consumption in %(Task C
Requirements) 4.97%

Table 7: Deviation from Minimum to Maximum for Trace Logs

New Value on
Task Current value on TRACE
TRACE

Task A 6.25% 6.54%

Task B 26.49% 36.57%
Task C 4.97% 6.42%
Total 37.71% 49.53%
988 Sneha Chattopadhyay et al. / Procedia Engineering 30 (2012) 983 – 988
Sneha Chattopadhyay, Tresina M. J., Shankar Narayan/ Procedia Engineering 00 (2011) 000–000

Table 8: Current CPU load and possible CPU load during WCE

Current Load Due to Task A, B and C 37.71%

Current CPU load due to other Tasks and interrupts 45.79%
Current CPU load 83.5%
Possible increase in CPU load due to application tasks 11.82%
Possible increase in CPU load due to other Tasks and interrupts 0.00%
New possible CPU load (Based on available results) 95.32%

4. Salient Findings

Many of the existing methods of WCET analysis require the availability of the source code in order to
estimate WCET. But the present measurement-based analysis is solely based on execution traces of the
program and is independent of the program semantics.

5. Conclusion
In this paper the worst case execution time (WCET) analysis is done using measurement technique. The
present WCET analysis is merely based on the program-execution traces. The CPU load is obtained for
three different tasks having a set of periodically running requirements using time measurement test and
trace logs. The present value of CPU load due to the tasks A, B and C alone is calculated to be 37.71%.
The CPU load due to other tasks and interrupts is separately measured to be 45.79%. The new increase in
CPU load due to all the tasks is found to be 95%, which suggests that the system is not time-overloaded.

References
[1] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whalley, et al. , ―The worst-case execution time
problem—overview of methods and survey of tools,‖ ACM Transactions on Embedded Computing Systems (TECS), vol.
7, no. 3, Apr. 2008.
[2] Andreas Ermedahl and Jakob Engblom.‖ Execution time analysis for embedded real-time systems.‖ Handbook of Real-
Time and Embedded Systems, CRC Press, 2007, pages 35.1 – 35.17.
[3] Laplante Phillip A., Real-time Systems Design and Analysis, John Wiley & Sons Inc., 2004