# Investigating EVT-based Hybrid WCET Analyses

Benjamin Rouxel, Slim Ben Amor, Kossivi Kougblenou, Liliana Cucu-Grosjean

Cucu-Grosjean

► To cite this version:

Benjamin Rouxel, Slim Ben Amor, Kossivi Kougblenou, Liliana Cucu-Grosjean. Investigating EVT-based Hybrid WCET Analyses. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.4.1. hal-05513191

HAL Id: hal-05513191

https://hal.science/hal-05513191v1

Submitted on 16 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Investigating EVT-based Hybrid WCET Analyses

Benjamin Rouxel<fnref n="1" />, Slim Ben Amor², Kossivi Kougblenou³, Liliana Cucu-Grosjean⁴

1,2,3 StatInf, Vector France S.A.S

benjamin.rouxel@vector.com

slim.benamor@vector.com

kossivi.kougblenou@vector.com

⁴ StatInf, INRIA

liliana.cucu@inria.fr

## ABSTRACT

One mandatory analysis in assessing time constraints of real-time systems is the Worst-Case Execution Time (WCET) estimation of programs executed on computing platforms. The ever increasing complexity of computing platforms makes this analysis difficult, if not impossible with deterministic methods. A good candidate to overcome this difficulty is a statistical analysis such as Extreme Value Theory (EVT).

In this paper, we propose to evaluate the applicability of hybrid WCET estimation techniques using EVT-based estimators on measured execution times of programs. Measurement-based estimators require test scenarios covering the whole program to be sound, but 100% coverage is not easy to reach. Therefore, we shed some lights on hybrid timing analyses that feature such statistical estimators. While hybrid timing analyses are not new, our objective is to compare several possible (existing and novel) analyses that may capture the advantages of EVT-based estimators.

We evaluate different approaches to cover all the range of embedded safety-critical systems from low-end robotics with micro-controller running small control loops to more advanced systems with image processing requirements. Our main conclusion of this evaluation is the ability for EVT-based WCET analyses to cover such a wide range of application domain, but hybrid analyses exhibit an accumulated over-pessimism.

## 1. INTRODUCTION

One mandatory analysis in assessing timing constraints of real-time systems is the Worst-Case Execution Time (WCET) analysis [33] of programs targeting a specific platform. Three main categories of WCET estimation analysis exist: 1. static, 2. dynamic, and 3. hybrid. Static analyses involve studying the timing behavior of programs without an actual execution, a process increasingly challenging when considering modern computing platforms. Consequently, dynamic analyses (or measurement-based only) appear more suitable for such platforms by directly considering execution time measurements of programs on the target platform. The Maximum Observed

Execution Time (MOET), with or without an engineering margin<fnref n="1" />, is easily extracted and considered as the WCET estimate. However, dynamic analyses may exhibit optimism in results, due to the impracticality of exploring all hardware and software states while executing a program during a reasonable timeframe. To address limitations of both static and dynamic methods, various hybrid WCET estimation analyses [7, 34, 24] integrate dynamically collected information into static methods, extending the state space coverage and thereby increasing confidence in WCET estimation results.

One may also consider the evolving complexity of real-time systems, which no longer solely consist in independent control loops but incorporate richer algorithms involving object detection, vision in the loop, or sensor fusions for localisation [27]. Such complexity requires the use of more modern and powerful computing platforms. The combination of complex software and hardware increases the range of possible execution time values, and larger execution times are rare events with low probability of appearance. Building on this rarity, probabilistic and statistical methods have been proposed. They can be classified into three main categories, similar to more traditional analyses [12], accounting for different concretisation of the hardware: 1. static being an abstract model of the system, 2. dynamic actually using the concrete platform, and 3. hybrid a mix of both. A major statistical dynamic analysis method is based on Extreme Value Theory (EVT) [11]. EVT aims to study the distribution of rare event appearance, in order to compute, in this case, the probability that any execution time is smaller than a given value. EVT provides convergence proofs indicating that if there exists a bound for the maximal values of a variable - here, the execution time - then this bound necessarily belongs to a precise family of distributions.

A measurement protocol is followed to collect execution traces obtained by executing the program on the target platform. From these execution traces, the list of execution times for a given entrypoint is extracted and used as input for the statistical estimators at the core of EVT. Measurement protocols commonly dictate to execute the program multiple times with varying feasible input states to mimic real scenarios, hence covering the whole spectrum of possible executions. For instance, the program functional verification tests could be used to generate

<footnote>Benjamin Rouxel et al. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>

<footnote n="1">¹For instance, such MOET can be inflated by 20% to generate a WCET estimate as in [31].</footnote>
appropriate set of execution traces. Defining a methodology
and the boundaries of such a measurement protocol is out of
the scope of this work. In our experiments, we indicate the
program coverage which in turns explain the results of some
comparisons.

In this paper, we propose to evaluate the applicability of hy-
brid WCET estimation techniques using EVT-based estima-
tors with a thorough evaluation of different methods including
static, dynamic and hybrid statistical analyses. While hybrid
analyses are not new, our objective is to compare several ex-
isting and novel analyses that may capture the advantages of
EVT-based estimators.

Our contributions are threefold:

1. a novel adaptation of an existing hybrid techniques featuring EVT-based estimators;

2. an empirical comparison with existing techniques both industry-ready and academic;

3. an empirical comparison of possible implementation strategies for hybrid analyses with their respective advantages and drawbacks.

This paper is organised as follows: Section 2 recalls some background concepts used throughout this paper. Section 3 surveys existing techniques focusing on WCET analysis tools and hybrid solutions. Section 4 presents the design of a hybrid WCET estimation tool and its different steps. Section 5 introduces the context of the experiment, with the use-case applications and platforms. Results of our experiments are available in Section 6 along with a discussion on the applicability of hybrid EVT-based WCET estimation methods. Finally, Section 7 concludes this work.

## 2. BACKGROUND

Most reasoning about programs employs the Control Flow Graph (CFG) representation. In a CFG, each node is a basic block, i.e. a sequence of non-branching instructions eventually finishing with a branch instruction. Edges in a CFG are directed and indicate possible paths of execution from one basic block to another. Each execution of a program leads to the execution of a sequence of instructions which can be mapped to a path on the CFG. Counting the number of paths in a graph, is a combinatorial problem due to conditional branches, e.g if-then-else constructs, and loops.

A single program often embeds multiple functions, and so, is a collection of CFGs with a one to one relationship between CFGs and functions. A call graph is used to represent the interaction between functions. In a call graph, nodes are functions and directed edges represent the call sequence with the source being the caller, and the sink being the callee.

Static WCET estimation analyses study the timing behaviour
of a program without executing it, relying instead on a timing
model of the target hardware platform. Static timing analy-
sis tools typically operate on the program's binary representa-
tion to remain as close as possible to the ultimately executed
code. These tools first disassemble the binary to reconstruct
the CFG and subsequently perform analyses at various lev-
els of granularity. Low-level analyses use details of the target
μ-architecture, e.g. pipeline depth or cache configuration, to

assign a WCET estimate to each basic block. Once all basic
blocks have a WCET estimate attached, the high-level analysis
aims to find the path in the CFG which leads to the longest ex-
ecution time, i.e. the critical path. Summing up the WCET es-
timates of all the basic blocks on the critical path finally gives
the global WCET estimate of the whole program. Implicit
Path Enumeration Technique (IPET) is one of the most com-
mon method used as the high-level analysis. It represents the
program as an Integer Linear Program (ILP) which can then
be solved to find both the critical path and the global WCET
estimate. The main drawback of static timing analyses lies
in the difficulty to create a complete and sound model of the
hardware.

Dynamic timing analysis techniques, however, rely on actual
measurements collected by executing the program on the tar-
get hardware platform. A simplistic WCET estimation method
consists in using the MOET plus an engineering margin, e.g.
20% [31]. As it is unlikely that the MOET (+engineering
margin) leads to a safe WCET estimate, more evolved statisti-
cal model can be applied on the collected measurements [12]
leading to a probabilistic WCET distribution. This distribution
can further be concretised to recover a single WCET estimate.
In this case, the concrete WCET estimate is a possible execu-
tion time which is guaranteed to be higher than any possible
execution times according to a domain-specific probability of
exceedance.

To estimate a WCET distribution, EVT studies the evolution
of the tail of the execution time distribution, i.e., the rare events.
EVT first identifies a list of maximas within the sequence of
measured execution times, and then computes the parameters
of a distribution which best fits these maximas. One should
note that measurement protocols require specific properties
[26, 12]. On a given sequence of execution times, two main
techniques are available to extract the maximas:

1. Block Maxima which splits the initial distribution into
   blocks, then picks the maximas of each block to create
   a Generalised Extreme Value (GEV) distribution; and

2. Peak Over Threshold (POT) which selects as maximas all execution time values over a given threshold to create a Generalised Pareto Distribution (GPD).

The GEV or the GPD are then the basis to form the WCET
distribution.

Measurement-based WCET estimation analyses, so is EVT,
are tightly coupled with the program path coverage enforced
by the test cases used to collect the data. A full path cover-
age means that all feasible program paths have been executed
at least once during the data collection. Reaching a full path
coverage is still an open challenge as the number of paths is
extremely difficult to count for complex programs. While still
difficult, a complete basic block coverage is simpler to achieve
as it requires to execute all basic blocks at least once during
data collection. However, a complete basic block coverage
does not imply a complete path coverage. To overcome this
code coverage completion issue, hybrid WCET analysis meth-
ods tend to couple dynamic and static techniques by mixing in-
formation from executed path (measurements) and program's
structural knowledge (IPET).
## 3. RELATED WORK

The most notable tools featuring successful hybrid WCET analyses are TimeWeaver [22] and RapiTime [9, 7]. They both rely on execution traces collected with different techniques. The collected information is then used to annotate and enrich the statically reconstructed CFG of the related application with execution information. This information is not limited to the execution time of programs, but can also include PMU counters among others, e.g. [19]. The main difference between TimeWeaver and RapiTime lies in their static analysis components. While RapiTime is based on probabilistic methods using convolution laws, TimeWeaver combines abstract interpretation and IPET techniques.

Since dynamically extracting execution information at the basic block level is expensive, in [23] the authors use smaller code chunks, hereafter referred to as code snippets, for which 100% coverage is guaranteed. Then, the proposed technique relies on genetic algorithms for the WCET estimation. Later, the Instrumentation Point Graph is formalised by [8], motivating the interest points in RapiTime and way/trace points in TimeWeaver.

Other recent solutions which consider hybrid WCET estimations are WE-HML [2] and CAWET [3]. Both are based on machine learning and infer the WCET of code snippets of varying length. Subsequently, the static analysis tool Heptane [20] uses the WCET estimates of each BB to populate an IPET problem. We further use WE-HML in our experiment Section 5 for comparison. CAWET sources could not be made available to us.

Previous hybrid WCET estimation analyses featuring EVT-based estimators are proposed in [34, 24] for computing platforms with cache randomized memories. While in [24] qualified technology is required to make semantic-preserving modifications on program sources, the authors of [34] base their proposition on the existence of a path independence property for the execution time of basic blocks, which is not necessarily true for existing computing platforms.

Compared to previous work, our novel hybrid WCET analysis is based on EVT and does not require specific properties on the target computing platforms. Indeed, EVT-based WCET estimators remain a serious candidate for estimating the WCET of programs in critical industries as it is shown to be less pessimistic than the other existing WCET estimators [1]. Moreover, computing platforms do not need to fulfil any requirements, while measurement protocols should [26, 12].

To collect basic block level information, tracing is an important step. Depending on the computing platform, different tracing mechanisms may be available, e.g. CoreSight<fnref n="2" /> for ARM cores, or [29] for Leon3 platforms. Both previous commercial debug interfaces are compatible with Lauterbach probes which access them using JTAG and trace connectors. As the size of execution traces can rapidly grow, in [13] the authors propose a mechanism based on FPGA filtering to reduce the information transmitted by the CoreSight unit. Accessing the debug unit can sometimes be cumbersome, if not impossible on some hardware due to vendor's locks. As an alternative,

we resort to software instrumentation entailing the addition of minimal instrumentation code [19] to extract the required data at specific moments during the execution of the program.

The software instrumentation has two primary drawbacks: additional overhead, and what is known as the probe effect. Hence, the work on the IPG is of utterly importance to decrease the additional code to its minimum. The probe effect can be largely solved by leaving the code into production, still, in existing papers, authors recreate the production memory layout at probing time, e.g. [25].

In this paper, we use both hardware tracing and software instrumentation mechanisms as our range of embedded computing platforms and programs does not permit to rely on a single technique.

## 4. HYBRID WCET ANALYSIS OVERVIEW

In this section, we present our main contribution: a hybrid WCET analysis that belongs to the class of static timing analysis that combines at basic block level, measured-based estimations. For a given sequence of collected execution times of the analyzed program executed multiple times with varying inputs, our analysis has the following steps: *Step 1* For executed basic blocks, we compute the respective probabilistic WCET distributions and we extract a scalar value from these distributions that become the WCET estimation of the basic block. *Step 2* For non-executed basic-blocks, we use the WCET estimator described in Section 5) to fill the gap by assigning a WCET estimate for each non-executed basic block. *Step 3* We build an IPET of the entire program to provide the final WCET estimate.

We provide in Figure 1 global view of our WCET analysis. One may note that by considering scalar values extracted from the pWCET distribution for a given probability, we avoid the problem of dependence between measured execution times of consecutive basic blocks. Nevertheless, this does not cover the safeness concern of our analysis. Indeed, under precise representativeness analysis of execution factors as done in [14] (pages 147-148), one may analyze the impact of dependencies between basic blocks by comparing static analysis estimations against EVT-based estimations for the same program. In this paper, we consider that measurements are provided under appropriate representativity hypotheses and we leave as future work, the identification of these hypotheses.

### 4.1. Collecting Execution Traces

For a WCET estimation analysis the collected data correspond to the execution paths. They need to cover the whole set of scenarios leading to all feasible program paths. The collected data include several executions of the program under analysis which are stored into a *trace* file.

Covering all possible scenarios can be extremely tedious due to the quantity of feasible paths and hardware states in nowadays programs and hardware platforms. Therefore, the data collection must focus on the domain specific knowledge where all possible scenarios of execution must be identified beforehand. Then, collecting the data can be performed at different levels of granularity. For this work, we focus on hardware based solutions, and software instrumentation techniques.

<footnote n="2">²https://developer.arm.com/Architectures/CoreSight%20Architecture</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1. Methodology Overview</figcaption></figure>

### 4.1.1. Hardware Traces

Hardware traces can be extracted using a trace hardware probe that is connected on one side to the target platform, and on the other side to a host computer.

This is the least intrusive way to collect the data as the debug probe fetches the listing of executed instructions by observing the processor from the outside, e.g. ARM CoreSight. For a WCET analysis, it is not necessary to collect all executed instructions but only the BB boundaries which are usually marked by branch instructions. The resulting trace includes the ordered list of executed branch instructions, each associated with a monotonically increasing timestamp.

The drawback of this method lies in the availability of a compatible hardware probe for the target platform, as well as a specific trace port to connect the probe.

### 4.1.2. Software Traces

Another possible technique to collect program execution times involves software instrumentation. This corresponds to adding some extra piece of code at specific points in the program to collect the required data. Instrumentation code can be added at different granularity depending on the desired details of the execution. This ranges from adding an event at each BB of the program to adding a start and stop event at, respectively, the beginning and end of the program.

This method is the most intrusive one as it adds a lot of pressure on the program itself. Indeed executing the instrumented code at a too low granularity can drastically degrade the overall performance of the program. At the highest granularity, the collected data are very shallow as they would only include the information on the program start and end times without any further information, such as the preemption from the OS. Nonetheless, software instrumentation is by far the most flexible technique.

The main drawbacks are its intrusiveness at low granularity,

and lack of information at high granularity. Software instrumentation also jeopardises the certification of the system as the instrumentation code must also be certified as non modifying the initial behaviour of the program.

In addition, it might be necessary to discriminate between a version of the code for the analysis versus the production version in order to limit the performance degradation in production. To achieve this, engineers can remove the instrumentation code for the production version. However, the memory layout of the program can drastically change, thus invalidating any previous WCET estimates.

Defining the correct granularity while minimising the overhead and impact on the production code is a complex challenge and requires a tailored solution.

## 4.2. Trace and Binary Mapping

Execution traces contain all information about the execution of the entire program including some code that is not part of the specific program under analysis. To isolate the bits of the trace that are only relevant for the current WCET estimation analysis, it is necessary to reconstruct the CFG of the specific entry point alongside with all functions present in its underlying call graph.

The entry point address is then detected within the execution trace, and subsequent entries are then mapped onto the reconstructed CFGs. It is then possible to collect the list of execution times for each executed basic block present in the CFGs.

The static program analysis tool Otawa [6] allows to reconstruct the CFG of compatible programs from an ELF file. It uses a series of steps to disassemble the binary, read and identify the instructions semantics in order to reconstruct the basic blocks and the flow of control connecting them. With the help of an Otawa module, we are able to reconstruct the CFG of the program and correlate the timing information present in the trace.
## 4.3. Statistical WCET Estimator

Statistical WCET estimation analyses, a.k.a probabilistic WCET estimation analyses, offer the possibility to estimate a probabilistic WCET distribution. From the distribution, a single execution time value can be extracted according to a probability of exceedance. This execution value is then a concrete WCET estimate. For a given value *e* and its associated probability *p*, this means that any possible execution time has a probability *p* of being larger than *e*, i.e., the WCET estimate is equal to *e*. Said otherwise, over $\frac{1}{p}$ executions of the program (i.e. a return period), there is one chance that the execution of the program may exceed the estimated WCET value (i.e. the corresponding return level).

Our in-house statistical WCET estimation tool RocqStat™ relies on EVT estimators. It uses a mixture of GEV and GPD to find the best compromise for a safe and tight WCET estimates at low probability of exceedance, i.e. $10^{-9}$.

## 4.4. Other WCET Estimator

As 100% code coverage is a hard task to accomplish, and so having statistical WCET for all basic blocks, other types of WCET estimators can be used at the basic block level. We here refer to two types of analysis but some other may be employed following the same schema.

### 4.4.1. Static WCET Estimation Analysis

A static analysis is commonly divided in two phases:

* low-level: performs a WCET estimate of each BB using a precise model of the micro-architecture, and

* high-level: looks for the longest path in the CFG, where the length depends on the WCET of the BB along that path.

The low-level analysis can be used to compute the WCET estimate of all basic blocks which have not been visited while collecting the execution traces. With a micro-architecture and a timing model of the considered platform, Otawa [6] is able to provide to us the missing basic block WCET estimates. In Figure 1, this step is related to *Other WCET estimator*.

Once all BBs have a WCET estimate attached, we also use Otawa to perform the high-level analysis by building the IPET formulation considering the program under analysis. Solving the IPET problem finally results in the longest path and a WCET estimate for the program. In Figure 1, this step is related to *Static WCET estimator (IPET only)*.

### 4.4.2. Machine Learning WCET Estimation Analysis

Another technique to assign a WCET estimate to a basic block without executing it can rely on machine learning. This idea is based on training a machine learning algorithm with some data which connects execution times and instructions. After the training process, the machine learning algorithm is able to assign a WCET estimate value to any other sequence of instructions.

An example using machine learning has been presented by Amalou et al. [2] with WE-HML. This tool provides a random C code generator that generates an initial dataset. This

dataset is then compiled and executed on the target platform while collecting the execution times of the controlled instruction sets. To train the machine learning algorithm, WE-HML also employs EVT on the collected execution times, more precisely, it uses GEV with a probability of exceedance fixed at $10^{-3}$. Further calls to WE-HML triggers the inference of a WCET estimate for each basic block, and finally an WE-HML builds an IPET formulation using the Heptane software [20] to compute the WCET estimate of the whole program.

## 4.5. Selected WCET Estimation Methods

Figure 1 capitalises on Static methods (Section 4.4.1) which can be separated in two distinct steps, i.e. low level and high level analyses. The low level analysis can safely be replaced by any other WCET estimation analysis offering BB level WCET estimation. Conversely, the high level analysis can perform on BB level WCET estimates originating from any method. The next evaluation section (Section 5) presents multiple scenarios combining different BB level WCET estimation methods combined with a Static high-level analysis (IPET).

Considering the baseline methods and hybrid analyses, the evaluation section compares:

1. Maximum Observed Execution Time (MOET): represents the maximum execution time over all executions of the entry point function;

2. Static: represents the WCET estimate using purely static method;

3. Statistical: represents the WCET estimate using a statistical extrapolation of all measurements;

4. WCET Estimation Hybrid Machine-Learning (WE-HML): represents the WCET estimate based on state of the art machine learning technique;

5. Hybrid MOET and Static (HMS): presents a WCET estimate using the MOET for basic blocks when available with fallback on a static analysis;

6. Hybrid EVT and Static (HES): similar to HMS but uses EVT instead of MOET;

7. Hybrid EVT and WE-HML (HEW): similar to HES but uses WE-HML as fallback method instead of static.

As any WCET analysis based on IPET method, the presented hybrid methodology from Figure 1 requires the considered programs to be well-structured, e.g. no goto or indirect branches, and all loops must be bounded.

# 5. EVALUATIONS

We evaluate the proposed hybrid WCET method combining EVT-based estimators and an IPET formulation with state-of-the-art tools. This evaluation considers various contexts accounting for small single-core control loops targeting microcontrollers, to more complex dataflow applications targeting real-time friendly CPU cores and finally to more advanced software running on performance oriented System-On-Chip (SoC).
# 5.1. Application Use Cases

## 5.1.1. TACLeBench

The TACLeBench benchmark suite [17] offers a collection of programs of different sizes and complexities. We use a subset of the sequential benchmarks that we consider representative enough for the single-core small control loop cases. We only use a subset to limit the experiments time as some of the considered methods require an extensive preparation time (see Section 4.5). The selected benchmarks are presented in Table 1.

<table><caption>Table 1. Selected TACLeBench benchmarks</caption><thead><tr><td>Name</td><td>Description</td></tr></thead><tbody><tr><td>binarysearch</td><td>Binary search of 15 integers</td></tr><tr><td>bsort</td><td>Bubblesort program</td></tr><tr><td>countnegative</td><td>Counts signes in a matrix</td></tr><tr><td>fir2dim</td><td>2-dimensional FIR filter convolution</td></tr><tr><td>h264_dec</td><td>H.264 block decoding functions</td></tr><tr><td>insertsort</td><td>Insertion sort</td></tr><tr><td>jfdctint</td><td>Discrete-cosine transformation on a 8x8 pixel block</td></tr><tr><td>matrix1</td><td>Generic matrix multiplication</td></tr><tr><td>petrinet</td><td>Petri net simulation</td></tr></tbody></table>

All benchmarks are single-core applications compiled with GCC without optimisations ($-O0$). For the measurements, they have been executed 10k times baremetal.

## 5.1.2. STR2RTS

Considering nowadays more complex real-time software targeting multi-core platforms, we use the STR2RTS [30] benchmark suite which provides a set of parallel applications, each represented by a graph and associated source code. We use again a subset of the provided benchmarks, excluding those with overly simple graphs (chain), or where the code complexity of nodes is limited as we deem these to be redundant with the TACLeBench. The selected benchmarks are presented in Table 2.

<table><caption>Table 2. Selected STR2RTS benchmarks</caption><thead><tr><td>Name</td><td>Description</td></tr></thead><tbody><tr><td>BeamFormer</td><td>Multi-channel beam former</td></tr><tr><td>CFAR</td><td>Constant False Alarm Rate detection</td></tr><tr><td>ComplexFIR</td><td>FIR filter with complex data types</td></tr><tr><td>DES</td><td>DES encryption algorithm</td></tr><tr><td>FFT</td><td>Fast Fourier Transform</td></tr><tr><td>FilterBank</td><td>Filter bank for multirate signal processing</td></tr><tr><td>FMRadio</td><td>FM radio with multi-band equalizer</td></tr></tbody></table>

We consider the sequential version of these benchmarks and execute them on a single core. This allows us to perform a comparison with a static WCET analysis. All benchmarks are compiled with GCC without optimisations ($-O0$). For the measurements, they have been executed 10k times baremetal.

## 5.1.3. ORB-SLAM

Timing sensitive applications are not anymore limited to small control loops but require complex algorithms running on hardware accelerators. Hence, we include in our comparison a Simultaneous Localisation and Mapping (SLAM) application [28]. This application consists in localising an autonomous

vehicle and mapping it in its surrounding environment only using cameras. It includes four periodic tasks, where one is a complex typed graph in which seventeen nodes run on the CPU and twelve on the GPU. We here only focus on the graph task represented by Figure 2.

<figure><img src="image_3.png" /><figcaption>Figure 2. ORB-SLAM3 task graphs resulting from our code refactoring.</figcaption></figure>

For this work, we slightly modified the ORB-SLAM application to run on a single-core. The modifications only include the removal of thread creation calls, which are replaced by sequential calls to the corresponding functions. This is a common practice when performing a WCET analysis especially to compare with static WCET analysis methods. The CPU tasks have been compiled for GCC with no optimisation ($-O0$) to cope with restrictions on static analysis, this is however not mandatory when using purely statistical or machine learning WCET estimation techniques.

For the sake of this work, we solely focus on the CPU nodes as we do not have the corresponding tools for a comparative study on GPU tasks. We can refer the interested reader to [21] for a static WCET analysis of GPU kernels, and to [8] for a hybrid WCET one.

As input for ORB-SLAM, we used the sequence number four from the Kitti benchmark suite [18]. This suite provides black & white, size 1241×376, image sets captured at 10 fps to evaluate self-driving cars. The sequence four represents a simple straight trajectory which we consider enough to evaluate the methods from this paper. Other sequences could improve the basic block coverage but would neither impeach nor improve the evaluation of the hybrid WCET analysis.

The sequence four contains 270 frames (×2 for images), hence we collect 540 measures for image related tasks, e.g. Extract Key Points, and 270 measures for frame related tasks, e.g. Track. This software is executed on a vanilla Ubuntu Linux provided by NVIDIA specifically for this platform.
## 5.2. Computing Platforms

For our low-performance, predictable platform, we selected a STM32H753I evaluation board. This architecture is used, e.g., to execute drone auto-pilot bench programs [32]. It features a single-core ARMv7 Cortex-M7 @470MHz with 2×16kB for instructions and data cache, 8MB SDRAM and 1MB SRAM.

For our middle range platform, we focus on the dual-core complex of a Xilinx MPSoC ZCU102 with two ARM Cortex-R5F @2.2GHz, leaving the other compute units switched off, and 4GB of LPDDR4. Mounted in other SoCs, these specific cores bring a good performance at a reasonable cost for robotic applications.

The final and more powerful platform we considered is the Nvidia Jetson Orin as it well represents the computation power needed in the automotive industry. It features 12 ARMv8.2 Cortex-A78AE CPU cores @2.2GHz, an Ampere integrated GPU with 2048cores running at a maximum frequency of 1.3GHz, and 32GB of LPDDR5.

## 5.3. WCET Analyses Setup

This section provides the configuration details used on the tools providing the WCET estimation methods listed in Section 4.5

The static method is provided by Otawa [6]. Static analyses are complex to apply in general. In our case, the Cortex-M7 and Cortex-R5F are fully supported (ISA+μ-architecture) and with the annotated programs (loop bounds) from TACLeBench and STR2RTS, they form a suitable combination towards safe and tight static WCETs. To model these platforms in Otawa, we followed the guidelines provided in their respective technical reference manual [5, 4]. With the Orin board, only the ISA is supported by Otawa. The μ-architecture is not suitable for static analysis as it uses a complex out of order processor, and a complex cache hierarchy. Moreover, we cannot know the number of cycles each instruction can take, or bound memory access latency as these details are not provided by the vendor. Nonetheless, for the Jetson Orin, we will use an arbitrary assumption of 5 cycles per instruction and 500ms for the memory latency. Despite being wrong, these values still allow to show that the hybrid methods can be applied if one knew the correct values.

As a statistical analysis tool, we chose our in-house state-of-the-art tool RocqStat™<fnref n="3" />. It is based on the well-accepted EVT technique [11, 16, 15] which requires to first collect execution traces and then, extrapolates a WCET value from the collected timing information. With the STM32H753I and ZCU102 platforms, we are able to use a Lauterbach probe to collect traces in a non-intrusive manner. However, with the Orin, we use software instrumentation techniques as the access to the CoreSight debug unit seems locked, and the board does not feature a trace port like the other platforms. Presented estimations are computed with a probability of exceedance set to 10⁹, a common value for railroad safety regulation.

Our baseline hybrid WCET technique is based on machine learning: WE-HML [2]. It employs several machine learning algorithms trained with randomly generated code. For each

platform, we used the code generator provided by the authors of [2], executed the generator on the target platform. We collected the execution traces with Lauterbach probes or software instrumentation depending on the platform. We finally trained the model for each platform indivirually with their respective data.

For all three hybrid methods, i.e. HMS, HES and HEW, we use for each basic block the maximum observed or a statistical estimation using RocqStat™. Then for each basic block for which we do not have measurements, we either use a static analysis from Otawa or an estimation from WE-HML. Finally, Otawa<fnref n="4" /> is employed to provide an IPET formulation to finally estimate the WCET of the whole program.

## 5.4. Software Instrumentation

The software instrumentation is performed by compiling ORB-SLAM with LLVM. We developed a compiler pass for LLVM which adds 2 instructions at the beginning of each basic block. This prelude branches the program control flow to a profiling function which:

* Collect the return address (i.e. the address of the calling basic block);

* Collect the current timestamp;

* Writes a packet containing both information into a non-blocking FIFO socket.

At the other side of the FIFO socket, we connect a program which continuously reads the packets and writes them into a trace file. We chose to separate the file writing from the ORB-SLAM profiling to limit the overhead into ORB-SLAM. We pinned both the single-core ORB-SLAM version and the reader onto different cores in order to limit the interference between them to a minimum.

There might be more sophisticated software techniques to even more limit the profiling overhead and interference. Finding the best software instrumentation technique is outside the scope of this paper as it does not influence the applicability of a hybrid WCET analysis.

# 6. RESULTS

## 6.1. STM32H753I+TacleBench

The results presented in Table 3 are very encouraging. All hybrid methods always give a safe answer higher than the MOET, and tighter than a static analysis (except form : *insertsort*). We can observe that HMS estimates are higher than MOET ones, and so are HES estimates compared to statistical ones. This shows that the IPET formulation leads to a critical path which has not been covered during the measurement step, which is also reflected by a coverage below 100%. We can, however, moderate this observation as the critical path found by solving the IPET formulation may be infeasible.

The case of *insertsort* shows that the HMS estimate is above the static one. It comes from the input data used for the measurements that did not trigger the worst-case loop iteration number. In the function *insertsort_main*, there are two nested

<footnote n="3">³https://www.statinf.fr</footnote>

<footnote n="4">⁴Please note, that solving the calling the IPET solver from Otawa or Heptane is equivalent as they both use the same solver, here CPLEX.</footnote>
<table><caption>Table 3. STM32H753I+TACleBench WCET estimation comparison</caption><thead><tr><th></th><th>BB coverage (%)</th><th>MOET (ns)</th><th>Static (ns)</th><th>Statistical (ns)</th><th>WE-HML (ns)</th><th>HMS (ns)</th><th>HES (ns)</th><th>HEW (ns)</th></tr></thead><tbody><tr><td>binarysearch</td><td>80</td><td>1,650</td><td>8,183</td><td>2,984</td><td>2,259</td><td>2,427</td><td>6,410</td><td>3,902</td></tr><tr><td>bsort</td><td>59</td><td>2,126,427</td><td>15,566,241</td><td>2,126,427</td><td>7,914,182</td><td>7,824,750</td><td>10,163,756</td><td>10,163,750</td></tr><tr><td>countnegative</td><td>75</td><td>92,157</td><td>332,083</td><td>92,157</td><td>119,325</td><td>138,962</td><td>330,016</td><td>501,687</td></tr><tr><td>fir2dim</td><td>66</td><td>386,367</td><td>1,985,008</td><td>465,936</td><td>677,146</td><td>638,352</td><td>1,803,958</td><td>1,383,022</td></tr><tr><td>h264_dec</td><td>17</td><td>569,730</td><td>2,557,891</td><td>1,139,460</td><td>1,333,332</td><td>641,887</td><td>2,549,845</td><td>2,139,031</td></tr><tr><td>insertsort</td><td>60</td><td>22,070</td><td>75,477</td><td>22,115</td><td>55,926</td><td>84,643</td><td>164,077</td><td>163,418</td></tr><tr><td>jfdctint</td><td>77</td><td>34,720</td><td>220,387</td><td>69,076</td><td>68,928</td><td>73,220</td><td>109,625</td><td>109,625</td></tr><tr><td>matrix1</td><td>70</td><td>119,280</td><td>1,859,266</td><td>119,280</td><td>151,589</td><td>356,802</td><td>698,612</td><td>698,612</td></tr><tr><td>petrinet</td><td>54</td><td>11,590</td><td>146,697</td><td>23,180</td><td>52,351</td><td>18,629</td><td>138,625</td><td>33,391</td></tr></tbody></table>

loops with both an upper loop bound set to 9, the body of the most inner loop can therefore be executed, in the worst-case, $9 \times 9 = 81$. However, looking at the execution traces, the body of this loop has been executed at most 44 times. Hybrid methods based on IPET formulations use the upper loop bound, then lead to higher estimates.

HMS estimates are tighter than static ones (except for *insert-sort*), hence showing than using measurements has a positive impact on overly pessimistic static analyses. HES estimates exhibit more pessimism compared to HMS estimates as to increase the safety of hybrid methods. However, we can note that HES is on average 3 times larger than HMS while the statistical estimates are very close to the MOET. In HES, the pessimism of EVT is applied on each basic block, and therefore accumulated in the final WCET estimation.

HES and HEW are difficult to compare as HES is sometimes higher than HEW, and sometimes it is the opposite. This means that sometimes the machine learning algorithm gives a lower estimation than the static analysis for the same corresponding basic blocks. However, with HEW estimates being higher than WE-HML, we can again observe the accumulation of the EVT pessimism at the basic block level.

Finally, we can notice that both HES and HEW give the same result for *matrix1* and *jfdctint*, which means that no unexplored block is part of the critical path.

## 6.2. ZCU102/R5+STR2RTS

For this scenario, the results presented in Table 4 are mostly confirming the observations previously made for the STM32H753I+TACleBench. We can observe that HMS estimates are in between MOET and static ones, except for *Filtterbank* and *FMRadio*. These two cases exhibit MOET values for some basic blocks that are larger than the estimates given by the static analysis. Hence showing that our platform model is not accurate due to some missing or incomplete information from the technical reference manual [4] and the ZCU102 documentation. This has the effect of even more increasing the pessimism in HES. Then, looking at HES and HEW estimates, the additional pessimism induced by EVT detected in the previous experimental scenario is exacerbated.

As a side observation, EVT-based analyses at the basic block level might be used to validate platform models employed by static analyses, or might also be used to build probabilistic platform models, e.g. [10]. This is however not the case for machine learning algorithms as no stable comparison is reflected by our results (sometimes HEW > HES, and sometimes the opposite), showing the difficulty to trust this type of algorithms to generate trustworthy WCET estimates.

## 6.3. Orin+ORB-SLAM3

The results presented in Table 5 are as expected. Estimation methods relying on static estimations are quite flawed due to the unrealistic platform model (5 cycles per instruction). However, hybrid methods can still lead to safe estimations as it is unlikely that all basic blocks executed for a frame will reach their WCET. Hence, building an IPET formulation using for each basic block the MOET or an EVT augmented value leads to HMS/HES/HEW estimates that are way larger than the MOET.

We also observe that both static and WE-HML are unsafe as this use-case uses dynamically linked library, e.g. OpenCL. None of this method has the ability to know which instructions are executed as the parsing of the single ELF file does not contain them, and neither Otawa nor Heptane support dynamically linked library. But, the execution times of dynamically linked called functions are included in the execution times of the caller basic block, and thus accounted for when using the MOET or EVT augmented WCET estimates for executed basic blocks in HMS, HES and HEW.

To deal with dynamically linked library and to avoid incorrect platform model, the only WCET analysis technique which works is the statistical one provided by Rocqstat™. All required information are included when collecting the execution times at the task level.

From Table 5, another issue we can observe comes from *GetFrame*. All IPET related analyses fail to estimate the WCET, error reported by the solver. We believe it to be linked to the usage of I/O library calls messing around with the CFG reconstruction, and so the IPET formulation creation.

Overall this shows that hybrid WCET analysis can be applied on such complex combination of software and hardware. However only pure statistical approach are more effective in limiting the pessimism compared to hybrid techniques when 100% coverage is reached, e.g. *Get.Pyra*.

## 7. CONCLUSION

In this paper we investigate how to drive a hybrid WCET analysis based on EVT that ensures safety and tightness for real-time systems. We compare both existing and novel hybrid WCET analysis with both commercial and academic state-
<table><caption>Table 4. ZCU102/R5+STR2RTS WCET estimation comparison</caption><thead><tr><th></th><th>BB coverage (%)</th><th>MOET (ns)</th><th>Static (ns)</th><th>Statistical (ns)</th><th>WE-HML (ns)</th><th>HMS (ns)</th><th>HES (ns)</th><th>HEW (ns)</th></tr></thead><tbody><tr><td>BeamFormer</td><td>83</td><td>10,861,320</td><td>41,268,717</td><td>10,863,902</td><td>26,354,325</td><td>16,554,393</td><td>21,252,448</td><td>21,235,681</td></tr><tr><td>CFAR</td><td>79</td><td>1,471,332</td><td>3,983,222</td><td>1,471,683</td><td>1,892,868</td><td>2,974,340</td><td>4,581,676</td><td>4,587,464</td></tr><tr><td>ComplexFIR</td><td>47</td><td>55,310</td><td>91,732</td><td>56,092</td><td>66,514</td><td>79,138</td><td>136,700</td><td>120,359</td></tr><tr><td>DES</td><td>76</td><td>22,195,720</td><td>52,508,254</td><td>44,391,440</td><td>109,415,990</td><td>47,919,355</td><td>58,831,537</td><td>58,905,369</td></tr><tr><td>FFT2</td><td>84</td><td>9,198,106</td><td>245,730,355</td><td>9,198,245</td><td>147,693,799</td><td>187,509,039</td><td>291,606,159</td><td>515,077,031</td></tr><tr><td>FFT4</td><td>73</td><td>2,234,806</td><td>3,568,069</td><td>2,235,334</td><td>2,672,769</td><td>3,497,880</td><td>3,608,198</td><td>3,615,478</td></tr><tr><td>FilterBank</td><td>79</td><td>5,193,344</td><td>9,399,940</td><td>5,241,266</td><td>9,285,273</td><td>10,580,780</td><td>18,161,539</td><td>18,183,502</td></tr><tr><td>FMRadio</td><td>84</td><td>1,156,486</td><td>1,875,674</td><td>2,312,972</td><td>1,995,485</td><td>2,234,110</td><td>2,505,172</td><td>2,509,494</td></tr></tbody></table>

<table><caption>Table 5. Orin+ORB-SLAM3 WCET estimation comparison</caption><thead><tr><th></th><th>BB coverage (%)</th><th>MOET (ns)</th><th>Static (ns)</th><th>Statistical (ns)</th><th>WE-HML (ns)</th></tr></thead><tbody><tr><td>GetFrame</td><td>66</td><td>206,754</td><td>-</td><td>413,508</td><td>-</td></tr><tr><td>Prep. Kernels</td><td>94</td><td>137,136</td><td>2,788</td><td>138,411</td><td>4,012</td></tr><tr><td>Get Pyra.</td><td>100</td><td>64,532</td><td>150</td><td>112,420</td><td>276</td></tr><tr><td>Copy Pyra.</td><td>95</td><td>12,875</td><td>2,642</td><td>13,070</td><td>3,561</td></tr><tr><td>Get Desc.</td><td>90</td><td>424,376</td><td>1,765</td><td>425,407</td><td>2,589</td></tr><tr><td>Extract Key Points</td><td>86</td><td>21,798,555</td><td>1,336,619</td><td>43,597,110</td><td>861,000</td></tr><tr><td>Compute BoW</td><td>80</td><td>682,253</td><td>240,507</td><td>1,051,794</td><td>246,282</td></tr><tr><td>Features to Grid</td><td>78</td><td>11,615,045</td><td>956,973</td><td>19,597,874</td><td>1,229,588</td></tr><tr><td>Stereo Match</td><td>69</td><td>38,165,887</td><td>957,115</td><td>76,331,774</td><td>1,048,271</td></tr><tr><td>Track</td><td>43</td><td>558,669,630</td><td>47,323,938</td><td>1,117,339,260</td><td>35,708,287</td></tr></tbody></table>

<table><thead><tr><th></th><th>HMS (ns)</th><th>HES (ns)</th><th>HEW (ns)</th></tr></thead><tbody><tr><td>GetFrame</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Prep. Kernels</td><td>421,282</td><td>442,143</td><td>442,171</td></tr><tr><td>Get Pyra.</td><td>65,545</td><td>130,305</td><td>130,307</td></tr><tr><td>Copy Pyra.</td><td>207,556</td><td>370,070</td><td>370,112</td></tr><tr><td>Get Desc.</td><td>630,043</td><td>636,160</td><td>636,186</td></tr><tr><td>Extract Key Points</td><td>1,167,249,679</td><td>1,735,859,361</td><td>1,735,894,264</td></tr><tr><td>Compute BoW</td><td>94,132,028</td><td>142,253,720</td><td>142,261,016</td></tr><tr><td>Features to Grid</td><td>222,789,236</td><td>279,794,770</td><td>279,816,608</td></tr><tr><td>Stereo Match</td><td>183,384,440</td><td>188,773,370</td><td>188,791,080</td></tr><tr><td>Track</td><td>25,759,601,646</td><td>27,649,912,180</td><td>27,650,764,407</td></tr></tbody></table>

of-the-art tools. The comparison of the different methods includes representative boards for various execution scenarios, including avionics, robotics/automation and automotive applications. This comparison enables us to categorise the different techniques based on safety and accuracy. Results of the experiments show that no system constraints prevent from using hybrid WCET analysis but usefulness and accuracy of the results depend on the quality of the measurement protocol.

## ACKNOWLEDGEMENT

This work was supported by the European Chips Joint Under-
taking project HAL4SDV, grant agreement No.101139789.

## REFERENCES

[1] Jaume Abella, Damien Hardy, Isabelle Puaut, Eduardo Quinones, and Francisco J Cazorla. On the comparison of deterministic and probabilistic WCET estimation techniques. In *2014 26th Euromicro Conference on Real-Time Systems*, pages 266–275. IEEE, 2014.

[2] Abderaouf N Amalou, Isabelle Puaut, and Gilles Muller. We-hml: hybrid wct estimation using machine learning for architectures with caches. In *2021 IEEE 27th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA)*, pages 31–40. IEEE, 2021.

[3] Abderaouf N Amalou, Elisa Fromont, and Isabelle Puaut. CAWET: Context-aware worst-case execution time estimation using transformers. In *35th Euromicro Conference on Real-Time Systems (ECRTS 2023)*. Schloss Dagstuhl-Leibniz-Zentrum f’ur Informatik, 2023.

[4] ARM. ARM Cortex-R5 Processor - Technical Reference Manual. https://documentation-service.arm.com/static/5f04288cdbdee951c1cd8969, 2010.

[5] ARM. ARM Cortex-M7 Processor - Technical Reference Manual. https://documentation-service.arm.com/static/5e906b038259fe2368e2a7bb, 2014.

[6] Clément Ballabriga, Hugues Cassé, Christine Rochange, and Pascal Sainrat. Otawa: An open toolbox for adaptive WCET analysis. In *8th Springer International Workshop of Software Technologies for Embedded and Ubiquitous Systems (IFIP 2010)*, 2010.

[7] Guillem Bernat, Antoine Colin, and Stefan M. Peters. WCET analysis of probabilistic hard real-time system. In *the 23rd IEEE Real-Time Systems Symposium (RTSS)*, pages 279–288. IEEE Computer Society, 2002.

[8] Adam Betts and Alastair Donaldson. Estimating the wct of gpu-accelerated applications using hybrid analysis. In *2013 25th Euromicro Conference on Real-Time Systems*, pages 193–202. IEEE, 2013.
[9] Adam Betts, Nicholas Merriam, and Guillem Bernat. Hybrid measurement-based WCET analysis at the source level using object-level traces. In *10th International Workshop on Worst-Case Execution Time Analysis (WCET 2010)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2010.

[10] Francisco J Cazorla, Eduardo Quiñones, Tullio Vardanega, Liliana Cucu, Benoit Triquet, Guillem Bernat, Emery Berger, Jaume Abella, Franck Wartel, Michael Houston, et al. Proartis: Probabilistically analyzable real-time systems. *ACM Transactions on Embedded Computing Systems (TECS)*, 12(2s):1–26, 2013.

[11] Liliana Cucu-Grosjean, Luca Santinelli, Michael Houston, Code Lo, Tullio Vardanega, Leonidas Kosmidis, Jaume Abella, Enrico Mezzetti, Eduardo Quinones, and Francisco J Cazorla. Measurement-based probabilistic timing analysis for multi-path programs. In *2012 24th euromicro conference on real-time systems*, pages 91–101. IEEE, 2012.

[12] Robert Ian Davis and Liliana Cucu-Grosjean. A survey of probabilistic timing analysis techniques for real-time systems. *LITES: Leibniz Transactions on Embedded Systems*, pages 1–60, 2019.

[13] Boris Dreyer, Christian Hochberger, Simon Wegener, and Alexander Weiss. Precise continuous non-intrusive measurement-based execution time estimation. In *15th International Workshop on Worst-Case Execution Time Analysis (WCET 2015)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2015.

[14] Marwan Wehaiba El Khazen. *Statistical models for the optimization of energy consumption in cyber-physical systems*. PhD thesis, Sorbonne Universite, 2024.

[15] Marwan Wehaiba el Khazen, Adriana Gogonel, and Liliana Cucu-Grosjean. Work-in-progress: Lessons learnt from creating an extreme value library in python. In *41st IEEE Real-Time Systems Symposium, RTSS*, pages 415–418. IEEE, 2020.

[16] Marwan Wehaiba el Khazen, Liliana Cucu-Grosjean, Adriana Gogonel, Hadrien Clarke, and Yves Sorel. Work-in-progress abstract: Wks, a local unsupervised statistical algorithm for the detection of transitions in timing analysis. In *27th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, RTCSA*, pages 201–203. IEEE, 2021.

[17] Heiko Falk, Sebastian Altmeyer, Peter Hellinckx, Björn Lisper, Wolfgang Puffitsch, Christine Rochange, Martin Schoeberl, Rasmus Bo Sørensen, Peter Wägemann, and Simon Wegener. TACLeBench: A benchmark collection to support worst-case execution time research. In *16th International Workshop on Worst-Case Execution Time Analysis*, 2016.

[18] Andreas Geiger, Philip Lenz, and Raquel Urtasun. Are we ready for autonomous driving? the kitti vision benchmark suite. In *2012 IEEE Conference on Computer Vision and Pattern Recognition (CVPR 2012)*, 2012.

[19] Jeremy Giesen, Enrico Mezzetti, Jaume Abella, Enrique Fernández, and Francisco J Cazorla. epapi: performance application programming interface for embedded platforms. *Openaccess Series In Informatics*, 2019.

[20] Damien Hardy, Benjamin Rouxel, and Isabelle Puaut. The heptane static worst-case execution time estimation tool. In *17th International Workshop on Worst-Case Execution Time Analysis (WCET 2017)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2017.

[21] Louison Jeanmougin, Thomas Carle, Pascal Sotin, and Christine Rochange. Warp-level cfg construction for gpu kernel wcet analysis. In *21st International Workshop on Worst-Case Execution Time Analysis (WCET 2023)*, volume 114, pages 1–1. Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2023.

[22] Daniel Kästner, Markus Pister, Simon Wegener, and Christian Ferdinand. TimeWeaver: A tool for hybrid worst-case execution time analysis. In *19th International Workshop on Worst-Case Execution Time Analysis (WCET 2019)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2019.

[23] Raimund Kirner, Ingomar Wenzel, Bernhard Rieder, and Peter Puschner. Using measurements as a complement to static worst-case execution time analysis. *Intelligent Systems at the Service of Mankind*, 2(8):20, 2005.

[24] Leonidas Kosmidis, Jaume Abella, Franck Wartel, Eduardo Quiñones, Antoine Colin, and Francisco J. Cazorla. PUB: path upper-bounding for measurement-based probabilistic timing analysis. In *26th Euromicro Conference on Real-Time Systems, ECRTS.*, pages 276–287. IEEE Computer Society, 2014.

[25] Haoxuan Li, Ken Vanherpen, Peter Hellinckx, Siegfried Mercelis, and Paul De Meulenaere. Component-based timing analysis for embedded software components in cyber-physical systems. In *2020 9th Mediterranean Conference on Embedded Computing (MECO)*, pages 1–8. IEEE, 2020.

[26] Cristian Maxim, Adriana Gogonel, Irina Asavoea, Mihail Asavoea, and Liliana Cucu-Grosjean. Reproducibility and representativity: mandatory properties for the compositionality of measurement-based wcet estimation approaches. *ACM SIGBED Review*, 14(3): 24–31, 2017.

[27] Sajid Mohamed et al. The IMOCO4.E reference framework for intelligent motion control systems. In *ETFA*, 2023.

[28] Filippo Muzzini, Nicola Capodieci, Roberto Cavicchioli, and Benjamin Rouxel. Brief announcement: Optimized GPU-accelerated feature extraction for ORB-SLAM systems. In *35th ACM Symposium on Parallelism in Algorithms and Architectures (SPAA 2023)*, 2023.

[29] Xavier Palomo, Sylvain Girbal, Jaume Abella Ferrer, Laurent Rioux, Mikel Fernández, Enrico Mezzetti, and Francisco Javier Cazorla Almeida. Tracing hardware monitors in the GR712RC multicore platform: Challenges and lessons learnt from a space case study. In *32nd Euromicro Conference on Real-Time Systems (ECRTS 2020): 7-10 July 2020: proceedings*, volume 165, pages 15–1. Schloss Dagstuhl–Leibniz-Zentrum f’ur Informatik, 2020.

[30] Benjamin Rouxel and Isabelle Puaut. STR2RTS: Refactored StreamIT benchmarks into statically analyzable parallel benchmarks for wcet estimation & real-time scheduling. In *17th International Workshop on Worst-Case Execution Time Analysis (WCET 2017)*. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2017.

[31] Franck Wartel, Leonidas Kosmidis, Code Lo, Benoit Triquet, Eduardo Quinones, Jaume Abella, Adriana Gogonel, Andrea Baldovin, Enrico Mezzetti, Liliana Cucu, et al. Measurement-based probabilistic timing
analysis: Lessons from an integrated-modular avion-
ics case study. In *2013 8th IEEE International Sym-
posium on Industrial Embedded Systems (SIES)*, pages
241–248. IEEE, 2013.

[32] Marwan Wehaiba el Khazen, Kevin Zagalo, Clarke Hadrien, Mehdi Mezouak, Yasmina Abdeddaïm, Avner Bar-Hen, Slim Ben-Amor, Rihab Bennour, Adriana Gogonel, Kossivi Kougblenou, Yves Sorel, and Liliana Cucu-Grosjean. Work in progress: Kdbench - towards open source benchmarks for measurement-based multicore WCET estimators. In *28th IEEE Real-Time and Embedded Technology and Applications Symposium, (RTAS 2022)*, 2022.

[33] Reinhard Wilhelm, Jakob Engblom, Andreas Ermedahl, Niklas Holsti, Stephan Thesing, David Whalley, Guillem Bernat, Christian Ferdinand, Reinhold Heckmann, Tulika Mitra, et al. The worst-case execution-time problem—overview of methods and survey of tools. *ACM Transactions on Embedded Computing Systems (TECS)*, 7(3):36, 2008.

[34] Marco Ziccardi, Enrico Mezzetti, Tullio Vardanega, Jaume Abella, and Francisco J. Cazorla. EPC: extended path coverage for measurement-based probabilistic timing analysis. In *IEEE Real-Time Systems Symposium, RTSS*, pages 338–349. IEEE Computer Society, 2015.