# Understandable Timing Analysis of Service-Oriented Architecture Components in Software-Defined Vehicle

Pavlo Tokariev, Irman Faqrizal, Julien Deantoni

► To cite this version:

Pavlo Tokariev, Irman Faqrizal, Julien Deantoni. Understandable Timing Analysis of Service-Oriented Architecture Components in Software-Defined Vehicle. 20th International Conference on Information and Communication Technologies in Education, Research, and Industrial Applications (ICTERI-2025), Sep 2025, Nice, France. hal-05224373

HAL Id: hal-05224373

https://inria.hal.science/hal-05224373v1

Submitted on 26 Aug 2025

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 Attribution 4.0 International License
Understandable Timing Analysis of
Service-Oriented Architecture Components in
Software-Defined Vehicle

Pavlo Tokariev¹[0000-0002-4603-4770], Irman Faqrizal¹[0000-0001-9260-997X], and
Julien Deantoni¹[0000-0001-6962-7846]

Université Côte d'Azur, Inria, CNRS, i3S, Sophia-Antipolis, France

firstname.lastname@inria.fr

**Abstract.** The transition toward Software-Defined Vehicles is reshaping the automotive industry, with vehicle functionalities increasingly determined by software rather than hardware. This paradigm, enabled by Hardware Abstraction Layers, improves software portability and upgradability; however, it also introduces challenges in timing analysis for safety-critical functions that demand an estimation of their reaction times. Existing timing analysis techniques, including those designed for frameworks like ROS 2, often neglect uncertainties in execution times, fail to attribute delays to specific software components, and provide limited insights into the causes of timing variability—hindering system optimization. This paper presents a novel timing analysis framework for SDVs that overcomes these limitations by leveraging a minimal yet sufficient set of timing information exposed by the HAL. The framework accounts for uncertainty in both hardware and software, models logical timing requirements of components, and estimates reaction time and its variability while explaining their root causes. We demonstrate the applicability and benefits of our approach through a running example, showing how it enables more transparent and informed system design.

**Keywords:** Software-defined vehicle · Service-oriented architecture · Tim-
ing analysis under uncertainty.

# 1 Introduction

The automotive industry is undergoing a significant transformation driven by the emergence of Software-Defined Vehicles (SDV [14]), in which functionalities are increasingly determined by software rather than hardware configurations. This shift is enabled by architectural innovations, notably the use of a Hardware Abstraction Layer (HAL), which decouples application software from the underlying hardware platform. It provides a standardised interface to access hardware resources such as sensors and actuators, thereby facilitating the deployment, update, and portability of software components across heterogeneous platforms [6].

While SDVs promise increased flexibility and upgradability, they also introduce new challenges, particularly in the domain of timing analysis. Critical
automotive functionalities often require early estimation of reaction time, i.e., the time between the occurrence of an event (e.g., obstacle detection) and the corresponding system response (e.g., braking). This timing behaviour is influenced by multiple factors, including hardware-specific delays (e.g., sensor sampling rates, actuator latency, available resources), software architecture choices, and component-specific execution characteristics.

In this context, current timing analysis techniques face limitations. Existing approaches, such as those developed for frameworks like ROS 2, tend to ignore uncertainties in execution times and to overlook the specific contributions of individual software components that cause overall delays [18,1,12,16]. More importantly, when considering uncertainty, they typically lack mechanisms for explaining the causes of reaction time variability [2], which is essential for informed system design and optimisation. To overcome these limitations, this paper proposes a novel timing analysis framework based on a minimal set of timing information and leveraging both simulations and formal property analysis.

More precisely, to address the identified shortcomings, this paper makes the following contributions:

- We define a minimal yet sufficient timing information and its uncertainty, such as sensor sampling rate or communication delay, to be exhibited by the HAL. This ensures that abstraction does not hide critical timing characteristics of the hardware and accounts for uncertainty arising from various hidden elements within the HAL.

- We define the logical timing requirements of software components needed to compute system-wide reaction time while explicitly modelling their triggering and execution time uncertainty.

- We introduce a timing analysis framework that not only estimates the reaction time and its variability, but also makes it understandable by identifying how specific software architecture decisions influence timing behaviour.

These contributions are demonstrated and evaluated using a running example to illustrate the proposed SDV timing extensions and analysis, consequently illustrating the practical benefits of our approach for system designers.

The paper is structured as follows. Section 2 introduces the background knowledge necessary to understand the proposed approach. Section 3 presents the running example, an Automated Emergency Braking System. Section 4 describes the timing information that is used in Section 5, where we present our timing analysis approach and its implementation. Section 6 reports the experimental results, while Section 7 compares our approach with related works. Finally, Section 8 concludes the paper.

## 2 Background

This work proposes to augment existing software architectures used in SDV to allow the uncertainty-aware analysis of functional chains. To better explain the proposal, this section introduces the underlying concepts of software-defined vehicles, existing implementations and their components.
## 2.1 Software Defined Vehicle Concepts

A Software-Defined Vehicle (SDV) represents a shift in how future cars will be designed, built, and experienced. Unlike traditional vehicles, which are defined by their mechanical components (e.g., engines, chassis, or suspension), SDVs are primarily driven by software.

The mechanical concept of the vehicle, such as a sporty chassis, is no longer a differentiator, as many of these components are shared across brands and are largely the same. Instead, software functions and features (such as ADAS/ autonomy, infotainment, and connectivity) have taken over as the key differentiators. These allow manufacturers to shape functionality, user experience, and even the vehicle's identity through code rather than physical design.

In an SDV, software components are executed by centralised high-performance computing platforms. Centralisation enables over-the-air (OTA) updates, meaning vehicles can be continuously improved and enriched with new functions even after delivery to customers. To reduce development costs and make this model sustainable and scalable, there is a strong push to make software modular and reusable across different cars and even across brands. This enables development to occur both within OEMs (original equipment manufacturers) and through collaboration with external teams. As a result, the car becomes a dynamic digital product that evolves over time.

This capability is enabled by an abstraction layer over the vehicle hardware, specifically its sensors and actuators. A clear specification of the signals from sensors and to actuators allows software components to interact with different hardware consistently and simplifies the development of new functionalities.

## 2.2 SDV Implementations

The Software-Defined Vehicle (SDV) is a specialisation of service-oriented architecture, a well-established software development paradigm. In this subsection, we present some relevant existing frameworks, individual software components, description languages, and standards in the context of SDV.

The Vehicle Signal Specification<fnref n="1" /> (VSS) is a language that defines a standardised catalogue of vehicle signals. These signals are organised as an *n*-ary tree, with nodes indicating namespace and leaves defining signal names and their characteristics, such as datatype, unit or description. A signal represents either a value from a sensor or a command issued to an actuator. VSS facilitates the standardisation of core features across manufacturers while allowing them to add, remove, or annotate signals with metadata by overlaying the standard catalogue. VSS provides only a data model, used by other projects such as VISS and KUKSA. VISS (Vehicle Information Service Specification<fnref n="2" />) is a data communication protocol defined on top of HTTP and WebSockets. Eclipse KUKSA is a data broker that offers vehicle data access and management by implementing the Vehicle Abstraction Layer (VAL).

<footnote n="1">¹ https://covesa.github.io/vehicle_signal_specification/</footnote>

<footnote n="2">² https://github.com/COVESA/vehicle-information-service-specification</footnote>
The projects offer API access to vehicle signals, which can be used by software components and their services. For example, Eclipse Velocitas<fnref n="3" /> is a service-oriented framework built on top of KUKSA, dedicated to streamlined vehicle application development. Similarly, originating from the robotics domain, ROS (Robot Operating System<fnref n="4" />) is a publish-subscribe service-oriented framework that has gathered interest in SDV development. Notably, ROS natively supports periodic service calls. Its middleware is an implementation of the DDS standard [15] and includes a set of Quality of Service (QoS) policies, such as durability, reliability, lifespan, and message deadlines. This allows publishers and consumers to agree on some temporal aspects of service provision — an important consideration for correctness in robotic applications.

Android Automotive OS<fnref n="5" /> (AAOS) is an operating system based on Android, tailored for automotive use. Notably, it provides a Vehicle Hardware Abstraction Layer (VHAL), underscoring its relevance for SDV implementations. The VHAL exposes signals from sensors and actuators (similarly to VSS), and signal temporal properties such as minimum and maximum sampling rates. Subscribers to a property can specify the rate at which they wish to receive updates, provided it respects the defined rate range.

AUTomotive Open System Architecture (AUTOSAR) Adaptive is an industrial standard providing service-oriented capabilities through an Architecture Description Language (ADL) and an Interface Description Language (IDL). Unlike AUTOSAR Classic, AUTOSAR Adaptive does not include extensive timing information. Other automotive-related ADLs, however, do support timing. For instance, EAST-ADL [5] is an ageing architecture description language that includes timing analysis features. Specifically, it allows the specification of various synchronisation mechanisms relevant to timing analysis, such as component triggering policies and input synchronisation. This concept has been further developed in the still-evolving Architecture Analysis and Design Language (AADL [8]). In AADL, components define their interactions through data ports and connection policies (e.g., sampling, immediate, or delayed). AADL enjoys extensive tool support, though it is not yet well adapted to service-oriented architecture or SDV.

Among these approaches, AUTOSAR latency constraints and AADL flows serve as examples of functional chain (FC) specifications. Per [20], “a functional chain is an ordered set of references to functions and the functional exchanges that link them, describing one possible path among all the paths forming the dataflow”. The functional chain is a concept complementary to reaction time (also known as end-to-end latency) between stimulus and response in real-time systems. Ensuring satisfaction of this timing is critical for controlling physical phenomena on which the system depends for safety, functionality, or both.

<footnote n="3">³ https://eclipse.dev/velocitas/</footnote>

<footnote n="4">⁴ https://ros.org/</footnote>

<footnote n="5">⁵ https://source.android.com/docs/automotive/</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1: Automated emergency braking system components</figcaption></figure>

From all the technologies associated with SDV, our goal is to leverage impor-
tant temporal information to enable reaction time analysis of functional chains
in an SDV development environment, i.e., frameworks based on HAL and VSS.

3 Running Example

We use an Automated Emergency Braking System (AEBS) to illustrate our approach. AEBS is an embedded vehicular system designed to avoid or mitigate collisions. It perceives the environment and applies automated braking or raises an alarm when some object is too close.

While the approach has been applied to AEBS with eight components, to fa-
cilitate the explanation, we consider a simplified AEBS architecture with three
components, as illustrated in Fig. 1. Components labelled with **s**, **c**, and **a** repre-
senting sensor, computation, and actuator components, respectively. The radar
sensor scans the environment to detect vehicles or obstacles ahead of the host
vehicle. The AEB controller accesses the radar data via the HAL (which uses
VSS as its interface data model) and evaluates the risk of collision by computing
the Time to Collision (TTC). The controller sends the brake commands before
execution finishes; its value depends on whether the TTC indicates that the
collision is imminent or not (which in turn depends on the vehicle speed and
maximum brake force, available in the HAL, but omitted here for simplicity).

It is important to note that the AEBS is subject to strict timing constraints,
particularly with regard to its reaction time. However, without timing informa-
tion from the HAL and software components, meaningful timing analysis is not
feasible. The next section introduces the minimal set of timing-related informa-
tion required to support such analysis.

4 Modelling Timing Information and Uncertainty

In this section, we describe the first part of our proposed methodology: the mini-
mal information about the software architecture that the designer needs to know
and specify in order to perform timing analysis. In the following subsections, we
define the timing constraints of the HAL and of the software architecture speci-
fication, as well as the semantics of functional chains.
## 4.1 HAL Timing Information

To specify the HAL, we extend the Vehicle Signal Specification (VSS) with minimal yet essential timing annotations. These additions focus on the timing characteristics of signals associated with both sensors and actuators.

For sensor-related VSS values, we first specify the *sensor sampling period*, i.e., the time interval between consecutive readings from the sensor drivers. This period is determined by various factors, such as the technology of the sensor, the dynamics of the measured process, the driver, as well as the operating system and its execution platform. Second, we define the *data latency*, i.e., the time elapsed between the sampling of a physical event occurrence in the environment and the moment the corresponding data becomes available in VSS. This latency encompasses the sensor device's internal sampling and processing delay, the execution time of the sensor driver, and the mechanisms involved in delivering the value as a VSS signal through the HAL.

For actuator-related VSS values, we specify two aspects: the actuator's *triggering policy* and the *actuation delay*. The triggering policy specifies whether the driver reads the target value periodically or is event-triggered. This information is important since it may introduce opportunistic interleavings that create variations in the reaction time. If the triggering is periodic, the actuation period is specified in the same way as for sensors. Actuation delay denotes the time interval between the setting of a control command by the software system (e.g., from a controller via the HAL) and the corresponding physical action performed by the actuator. This includes the time required for the actuator driver to read and process the command, and to carry out the physical actuation (e.g., applying brake force or adjusting steering angle).

## 4.2 Software Components

In addition to timing information associated with the VSS, reaction time analysis requires temporal characterisation of the computational components within the system architecture. Computational components include software modules such as sensor fusion algorithms or control logic, which process sensor signals from the VSS or other components and generate outputs consumed by actuators (through the VSS) or by other components.

We annotate each computational component with two timing attributes: the *triggering policy* and the *execution time*. Software components share the definition of triggering policy with actuators. The execution time corresponds to the duration required by the component to perform its computation once triggered.

Together, these two annotations model the temporal behaviour of computational components and make their contribution to the reaction time explicit. Since the components are the elements modified by the system designer and thus can be used to explore different architectural configurations, by varying scheduling order or triggering semantics, under uncertainty.
<figure><img src="image_3.png" /><figcaption>Fig. 2: Timing uncertainties in periodic activation and execution time</figcaption></figure>

## 4.3 Timing Uncertainties

The aforementioned timing information must account for the uncertainties arising from the inherent variability of physical devices and the software components' dynamism. For components with periodic triggering policy, we specify a period jitter, and, for execution time and data latency, best and worst case. Which means that an actual activation of a component may deviate from the true periodicity up to the jitter value (a common definition in the literature [11,9]), and its duration can vary in the specified bounds (see Fig. 2). Furthermore, each timing parameter is associated with a probabilistic distribution, usually normal, truncated to the uncertainty bounds.

In further sections, we use the parameters of sensor period *SP* and sensor period jitter *SPJ*, associated with the radar signal, best case *DL*<sub>min</sub> and worst case *DL*<sub>max</sub> bounds of its data latency (analogously, *AP* and *APJ* for the period and jitter of the actuator, and execution time *ET* for the controller). We consider that these parameters specify 95% of possible values of the actuation period and latency, respectively, from which we derive the mean and standard deviation for a normal distribution (the percentage can be adjusted to the specific case; 95% is just one example).

## 4.4 Semantics of Functional Chains

Reaction time is a meaningful property of real-time systems only when considered in the context of a well-defined functional chain. While individual data flows and timing constraints between executable components offer partial information, they are insufficient on their own to compute a system's reaction time. This is because such relations typically form a network, allowing multiple potential paths from a stimulus to a response.

As discussed in Section 2, a functional chain is an ordered set of service calls from components connected consistently through data exchange links. The definition of a functional chain helps disambiguate the propagation path, making it unique. However, this does not resolve the temporal variation, which remains due to the components' triggering mechanisms and possible data contention between a publisher and subscriber.

In this paper, we rely on the classical definition of reaction time: the duration from the moment a stimulus first appears in the environment to the moment the system produces a response to it that is observable in the environment. In this definition, a particularly important case arises when subscriber components in the chain are triggered periodically: a stimulus may be detected and published multiple times, leading to an accumulation of identical data before the subscriber
<figure><img src="image_4.png" /><figcaption>Fig. 3: Conceptual approach and steps for the timing analysis</figcaption></figure>

actually processes it. For the reaction time computation, we consider only the
chains writing and reading first at each such point.

# 5 Timing Analysis

In this section, we present our timing analysis using the timing information pre-
sented above. We first provide the conceptual architecture of the timing analysis.
Then, a general overview of the implementation is given.

## 5.1 Conceptual Analysis Architecture

The goal of the timing analysis is to provide a probabilistic distribution of the
functional chain (FC) reaction times under uncertainty, along with explanatory
insights to help the designer refine the system specification in light of the results
(see Fig. 3).

The analysis starts from a specification of the SDV software architecture an-
notated with timing information, as described in Section 4. From this informa-
tion, two complementary formal specifications are generated. The first supports
the simulation of the SDV architecture's behaviour under varying assumptions
about the uncertainties and the deployment conditions (e.g., the number of avail-
able CPUs). From this specification, a potentially large set of temporal traces is
produced. These traces are then used to derive the probabilistic distribution of
the reaction times to occur during the execution of the SDV architecture.

The second specification provides a means to construct the complete state
space of the SDV architecture's behaviour. The state space serves as the ba-
sis for both the injection and extraction of information useful to the designer.
More precisely, we inject the execution traces from the first specification into the state space to obtain the system’s probabilistic model. Then, probabilistic behaviours of each component that are not exposed by the simulation approach can be extracted from the model using probabilistic temporal logic querying. Moreover, the model can be further queried to assess the representativeness of the simulation by examining the number of states not covered by the execution traces and the sequences leading to those states.

Both data sources, namely the distribution of FC reaction times and the probabilistic model analysis results, are then reconciled to provide the designer with comprehensive information on how the system needs to be updated, if so. While the capabilities of the framework can be further enhanced, its core contribution lies in the hybridisation of different models to deliver both quantitative results and actionable insights to the designer. This hybrid approach represents a foundational principle of our methodology.

## 5.2 Implementation

Execution traces are required to extract the FC reaction times. These execution traces are obtained by translating the system description into a simulator based on SimPy<fnref n="6" />, a process-based discrete-event simulation library in Python, or into the Modular Real-Time Clock Constraint Specification Language [19].

The algorithm to extract the reaction time assumes a functional chain template, a sequence $e_1 ⋉ e_2 ⋉ … ⋉ e_n$, where $e_i$ is some observable event and ⋉ is either → or ↓, representing an event- or periodic triggering policy between a publisher and a subscriber respectively. Then, functional chains are reconstructed from a trace by applying the following rules:

- occurrence of $e_1$ starts a new chain;

- for $e_i \to e_{i+1}$, if j-th occurrence of $e_i$ is present in a chain, an j-th occurrence of $e_{i+1}$ should be added;

- for $e_i \downarrow e_{i+1}$, adds the first occurrence of $e_{i+1}$ in the trace after $e_i$.

By remembering event timestamps, we compute the chain’s reaction time as the difference between the start and the end timestamps of the chain. Additionally, we remember the number of missed time-triggered event occurrences during the chain execution, which corresponds to the actuation misses in the running example, a sum of the number of *useless* actuations and the actuations that were never possible to use. Next, we compute the reaction time distribution among all extracted chains. Grouping by the number of the misses, we are able to identify the dependency between the number of misses, reaction time and its probability. This gives the system designer a clear understanding of when it is possible to optimise the reaction time by influencing the number of misses, which can be further investigated by inspecting the probabilistic model.

The first step to generate the probabilistic model is to construct the system’s state space, taking into account the timing annotations provided in the software architecture. This state space is represented as a Labelled Transition System

<footnote n="6">⁶ https://gitlab.com/team-simpy/simpy/</footnote>
<figure><img src="image_5.png" /><figcaption>Fig. 4: Timed automata of the system’s components</figcaption></figure>

(LTS), where states encode system configurations and transitions are labelled with important execution events like start and end of a component execution, publication or consumption of data.

To generate the LTS, we rely on the IF toolset [3], which requires specifying the system as a network of communicating timed automata. In this specification, all signals from the VSS and system components are modelled as individual automata. The behaviour of each component is captured through locations and transitions that reflect their activation, execution duration, and interaction with other components. Informally, a timed automaton consists of: (i) locations, and (ii) transitions between locations. Each transition is associated with a conjunction of event-driven, temporal, and boolean guards, which determines when the transition is fireable. If the guards are satisfied and the transition is selected, it is fired, triggering the execution of actions such as variable assignments, clock resets or updates, and event emissions; ultimately leading to entering the target location of the transition.

In Fig. 4, we present the three automata that correspond to the three components of the running example (Section 3). Here, *x* is a local clock, !*e* represents the sending of an event *e* and ?*e* a blocking synchronisation on the reception of *e*. Upper-case strings represent a dedicated log to be added to the transitions of the LTS to ease its exploitation. Note that here the logs are simplified for pedagogical purposes. In the actuator’s automaton, we introduce the notions of *useful actuation* and *useless actuation* to distinguish between an actuation that processes new data and one that does not. This information is crucial for later understanding of how a design can be improved. As specified in the automaton, *data* is incremented every time the actuator receives input from the controller (i.e., ?cData), and it is reset in every actuation. If *data* > 0 when the periodic activation happens, then it is a useful actuation; otherwise, it is a useless one.
The specified network of communicating timed automata is exhaustively simulated, resulting in an LTS, which encodes all possible orders of the components' activations while honouring the timing constraints. Afterwards, the LTS is injected with probabilistic values computed using a set of execution traces produced by the aforementioned simulation approach. This results in a probabilistic model called Probabilistic Transition System (PTS). The details on PTS computation are given in [7]. Essentially, the execution trace is used to guide the LTS traversal; every time a transition is traversed, the probabilistic value of that transition is raised according to its counter and the source state's counter.

We use various tools in the CADP toolbox [10] to perform analysis of the PTS. The EVALUATOR tool is used for probabilistic temporal logic querying. A query is expressed in MCL5<sup>7</sup>, which specifies sequences of executions using regular formulas. The probability of those sequences appearing in a given PTS is obtained when the query is fed into CADP. To obtain the degree of simulation's representativeness, we remove the states preceded by 0 probability transitions (i.e., unreachable states) from the PTS; then, the numbers of states before and after the removal are compared. The sequences of events leading to unreachable states are generated with the EXHIBITOR tool to analyse the exact sequences that can happen according to the timed automata specification, but do not appear in the simulation's execution traces.

# 6 Evaluation

This section presents experimental results using the timing and data exchange specification of HAL and the software components of the running example. The goal is to demonstrate the possible feedback to the designer regarding their design choice, in particular, how it impacts the reaction time, and thus clear hints to specific optimisations, such as reducing the execution time upper bound of a component. The code used to obtain the results of this section is freely accessible in https://github.com/PaulRaUnite/sdv_experiments and additionally includes the full version of the running example.

Table 1 presents the timing configurations for the experiments. Configuration C1 assumes the same periodicity for the radar and the brake signals, with the controller execution time specified between 2 and 8 time units. The frequency of the brake signal is increased in C2, whereas in C3, the controller is optimised. C4 combines both modifications in C2 and C3.

Based on the configurations, we first demonstrate the obtained reaction time distributions. Afterwards, the results of probabilistic model analysis using the IF and CADP tools are presented.

## 6.1 Reaction Time Distribution

Example results of reaction time analysis are shown in Fig. 5, all assuming infinite resources. We use stacked histograms to show the overall reaction time

<footnote n="7">7 https://cadp.inria.fr/man/mcl5.html</footnote>
<table><caption>Table 1: Experimental timing configurations</caption><thead><tr><th rowspan="2">Conf.</th><th colspan="4">Radar Signal</th><th colspan="2">AEB Ctrl</th><th colspan="4">Brake Signal</th></tr><tr><th>SP</th><th>SPJ</th><th>DL<sub>min</sub></th><th>DL<sub>max</sub></th><th>ET<sub>min</sub></th><th>ET<sub>max</sub></th><th>AP</th><th>APJ</th><th>AD<sub>min</sub></th><th>AD<sub>max</sub></th></tr></thead><tbody><tr><td>C1</td><td>15</td><td>1</td><td>1</td><td>3</td><td>2</td><td>8</td><td>15</td><td>1</td><td>1</td><td>3</td></tr><tr><td>C2</td><td>15</td><td>1</td><td>1</td><td>3</td><td>2</td><td>8</td><td>5</td><td>1</td><td>1</td><td>3</td></tr><tr><td>C3</td><td>15</td><td>1</td><td>1</td><td>3</td><td>2</td><td>4</td><td>15</td><td>1</td><td>1</td><td>3</td></tr><tr><td>C4</td><td>15</td><td>1</td><td>1</td><td>3</td><td>2</td><td>4</td><td>5</td><td>1</td><td>1</td><td>3</td></tr></tbody></table>

<figure><img src="image_6.png" /><figcaption>Fig. 5: Reaction time distribution examples</figcaption></figure>

distribution, as well as individual contributions, categorised by the number of missed actuations.

As the number of missed actuations corresponds to the interplay of timing parameters of components, an anomaly in the distribution can help identify a way to improve the reaction time. To accomplish that, further investigation may be needed, including examples of how specific situations can be obtained, for which we use the probabilistic model later. For example, in configuration C1 (Fig. 5a), we see that while utilisation of actuators is good (0 or 1 miss), while the reaction time is high. To solve this problem, we could try a configuration C2, in which we lower the actuator period. While on average, the reaction time is lower (Fig. 5b), there are some outliers, which could be a problem. On another hand, we may try to optimise the controller, as given in C3, but this will result in no major change (Fig. 5c). By only combining the efforts, i.e. by increasing the actuator frequency to catch controller data more often and by lowering execution
<figure><img src="image_7.png" /><figcaption>Fig. 6: Probabilities of useless actuations occurring during component activations</figcaption></figure>

time, we obtain a considerable (approximately twice on average, 25% lower upper bound) reaction time reduction with configuration C4.

## 6.2 Probabilistic Model Analysis

Four probabilistic models (i.e., PTSs) are generated according to configurations in Table 1. From these PTSs, we extract two useful information for the designer.

The first information reveals the probabilistic behaviour of specific components in the architecture by applying probabilistic temporal logic querying. In this experiment, we query the probabilities of having a number of useless actuations during a component activation. The query is performed using the following MCL5 formula, where *N* is the number of useless actuations and *Start* (and *Finish*) can be replaced with an action representing the start (and the end) of activation (e.g., "C_START" and "C_FINISH" for the controller activation).

```
[true* . Start ] prob
((not ("USELESS_ACT" or Finish or Start))* . "USELESS_ACT") {N} .
((not ("USELESS_ACT" or Finish or Start))* . Finish)
is >= ? 0 end prob
```

The query results in the probabilities of useless actuations during radar sensor sampling and AEBS controller execution depicted in Fig. 6. The result provides complementary information to the reaction time distribution in Fig. 5. For instance, optimising the controller (i.e., from C2 to C4) does not significantly reduce the probability of having two useless actuations in the functional chain because there is still a high probability of having one useless actuation during each activation of the sensor and the controller.

The second information addresses the representativeness of simulation's executions. After removing transitions with 0 probability and their subsequent states for each PTS, the state-space coverage presented in Table 2 is obtained. Note that the length and the number of traces for all the configurations are the same. The table shows that the coverage is smaller when the number of states is larger. This informs the designer to execute more simulations when the number of states is large for a more accurate distribution of reaction time. Furthermore,
<table><caption>Table 2: State-space coverage</caption><thead><tr><th rowspan="2">PTS</th><th colspan="3">C1</th><th colspan="3">C2</th><th colspan="3">C3</th><th colspan="3">C4</th></tr><tr><th>States</th><th>Trans.</th><th>Cover.</th><th>States</th><th>Trans.</th><th>Cover.</th><th>States</th><th>Trans.</th><th>Cover.</th><th>States</th><th>Trans.</th><th>Cover.</th></tr></thead><tbody><tr><td>Original</td><td>171</td><td>301</td><td><strong>85.38%</strong></td><td>355</td><td>677</td><td><strong>78.87%</strong></td><td>147</td><td>257</td><td><strong>92.5%</strong></td><td>244</td><td>432</td><td><strong>84.83%</strong></td></tr><tr><td>After removal</td><td>146</td><td>230</td><td></td><td>280</td><td>460</td><td></td><td>136</td><td>211</td><td></td><td>207</td><td>325</td><td></td></tr></tbody></table>

<figure><img src="image_8.png" /><figcaption>Fig. 7: Sequence ending with a 0 probability transition extracted from C3's PTS</figcaption></figure>

we extract an example of a sequence from the PTS of C3 that ends with a 0 probability transition shown in Fig. 7. Transitions from 6 to 8 represent the sensor sampling starts and finishes without an actuator's activation between them. Such a sequence is possible, but improbable because it requires the sensor sampling to start and finish earlier, and the actuation to start later. The result of this extraction can be an alternative to the state-space coverage to determine the simulation's representativeness. For instance, when all the extracted sequences are improbable, we may consider that the simulation used in the analysis is sufficiently representative.

# 7 Related Work

The works in [4,18] present reaction time analyses for ROS systems based on resource reservation to increase predictability by limiting interferences between executions. The key differentiator of the approaches is the assumption about the type of executor: single- or multi-threaded, which both have a very particular implementation in ROS. Both propose analytic ways to obtain the worst-case reaction time of event-driven functional chains in ROS, initiated in a time-triggered way. In contrast, we allow time-triggered components in the functional chains, and as the analysis uses execution traces, it is possible to use both the traces from simulations and from the implemented system itself.

In [2], the authors propose to analyse end-to-end reaction times of ROS systems using Statistical Model Checking (SMC) with UPPAAL [13]. This is done by translating each ROS node into a timed automaton and then synchronising them with auxiliary automata, called host and monitor, to represent the execution platform and to monitor reaction times, respectively. SMC does not require the generation of the complete system's state space, and thus performs faster. However, our method allows the designer to examine the coverage of the state space and the exact sequences that do not occur during the simulation.

In [1], the authors present the timing analysis of an autonomous driving software based on the Apollo framework. The analysis is performed by monitoring, and the results show that systems designed in Apollo exhibit high timing uncertainty. Similarly, our approach relies on the simulation results, but instead
of running Apollo module implementations on some hardware, we use models of timing in generic components, which allows exploration of unlikely scenarios and easy modification of configurations.

The work in [17] provides an overview of Cheddar, a tool for analysing the scheduling of real-time systems. The tool is mainly aimed at AADL architectural models and the design of real-time schedulers. While this integrates into the workflow defined in Fig. 3, their main focus is to ensure system schedulability. In contrast, our approach aims to analyse the system’s probabilistic characteristics originating from timing uncertainties.

## 8 Conclusion

We presented a framework to make an understandable timing analysis of SDV applications based on service-oriented architecture. We first defined the important timing information that should be revealed in both software components and the hardware abstraction layer to enable timing analysis. Then we propose a timing analysis mixing simulation techniques with probabilistic model analysis. As a result, we obtained the probabilistic distribution of reaction time for functional chains. We complement the reaction time with further information by querying a state space augmented with annotations from the simulations. The results help the designer comprehend the timing behaviour of the system and assess possible optimisation for further enhancements.

For future work, we plan to find more appropriate representations to leverage on the probabilistic model queries and to explore a more precise description of component behaviour that can help in providing more feedback to the designer.

**Acknowledgement.** This work is supported by the European Chips Joint Undertaking under Framework Partnership Agreement No 101139789 (HAL4SDV).

**Disclosure of Interests.** The authors have no competing interests to declare that are relevant to the content of this article.

## References

1. Alcon, M., Tabani, H., Kosmidis, L., Mezzetti, E., Abella, J., Cazorla, F.J.: Tim-ing of autonomous driving software: Problem analysis and prospects for future solutions. In: Proc. of RTAS’20. pp. 267–280. IEEE (2020). https://doi.org/10.1109/RTAS48715.2020.000-1

2. Backeman, P., Seceleanu, C.: Verifying ROS-Based Applications Using Timed and Stochastic Timed Automata, pp. 295–325. Springer Nature Switzerland, Cham (2025). https://doi.org/10.1007/978-3-031-85134-6_13

3. Bozga, M., Graf, S., Ober, I., Ober, I., Sifakis, J.: The IF toolset. In: Proc. of SFM-RT’04. LNCS, vol. 3185, pp. 237–267. Springer (2004). https://doi.org/10.1007/978-3-540-30080-9_8

4. Casini, D., Blaß, T., Lütkebohle, I., Brandenburg, B.B.: Response-Time Analysis of ROS 2 Processing Chains Under Reservation-Based Scheduling. In: Proc. of ECRTS’19. LIPIcs, vol. 133, pp. 6:1–6:23. Schloss Dagstuhl – Leibniz-Zentrum für Informatik (2019). https://doi.org/10.4230/LIPIcs.ECRTS.2019.6
5. Debruyne, V., Simonot-Lion, F., Trinquet, Y.: East-adl — an architecture description language. In: Dissaux, P., Filali-Amine, M., Michel, P., Vernadat, F. (eds.) Architecture Description Languages. pp. 181–195. Springer US, Boston, MA (2005)

6. Eckel, A.: Harmonizing software defined vehicle efforts. Auto Electronics (April 2025), https://www.autoelectronics.co.kr/article/articleView.asp?idx=5967, interview by Sang Min Han

7. Faqrizal, I., Salaün, G., Falcone, Y.: Probabilistic analysis of industrial iot applications. In: Proc. of IoT’22. pp. 41–48. ACM (2022). https://doi.org/10.1145/3567445.3567461

8. Feiler, P.H., Gluch, D.P., Hudak, J.: The architecture analysis & design language (aadl): An introduction (2006)

9. Gao, F., Mallet, F., Zhang, M., Chen, M.: Modeling and verifying uncertainty-aware timing behaviors using parametric logical time constraint. In: Proc. of DATE’20. pp. 376–381. IEEE (2020). https://doi.org/10.23919/DATE48585.2020.9116344

10. Garavel, H., Lang, F., Mateescu, R., Serwe, W.: CADP 2011: a toolbox for the construction and analysis of distributed processes. Int. J. Softw. Tools Technol. Transf. 15(2), 89–107 (2013). https://doi.org/10.1007/S10009-012-0244-Z

11. Henia, R., Hamann, A., Jersak, M., Racu, R., Richter, K., Ernst, R.: System-level performance analysis - The SymTA/S approach, pp. 29–74 (01 2006). https://doi.org/10.1049/PBCS018E_ch2

12. Houtan, B., Ashjaei, M., Daneshtalab, M., Sjödin, M., Mubeen, S.: Supporting end-to-end data propagation delay analysis for tsn-based distributed vehicular embedded systems. J. Syst. Archit. 141, 102911 (2023). https://doi.org/10.1016/J.SYSARC.2023.102911

13. Larsen, K.G., Pettersson, P., Yi, W.: UPPAAL in a nutshell. Int. J. Softw. Tools Technol. Transf. 1(1-2), 134–152 (1997). https://doi.org/10.1007/S100090050010

14. Liu, Z., Zhang, W., Zhao, F.: Impact, challenges and prospect of software-defined vehicles. Automotive Innovation 5(2), 180–194 (2022). https://doi.org/10.1007/s42154-022-00179-z

15. Object Management Group (OMG): OMG Data Distribution Service (DDS), Version 1.4. OMG Document Number formal/15-04-10 (https://www.omg.org/spec/DDS/1.4) (2015)

16. Reke, M., Peter, D., Schulte-Tigges, J., Schiffer, S., Ferrein, A., Walter, T., Mathais, D.: A Self-Driving Car Architecture in ROS2. In: Proc. of SAUPEC/RobMech/PRASA’20. pp. 1–6 (2020). https://doi.org/10.1109/SAUPEC/RobMech/PRASA48453.2020.9041020

17. Singhoff, F., Plantec, A., Dissaux, P., Legrand, J.: Investigating the usability of real-time scheduling theory with the cheddar project. Real Time Syst. 43(3), 259–295 (2009). https://doi.org/10.1007/S11241-009-9072-Y

18. Sobhani, H., Choi, H., Kim, H.: Timing analysis and priority-driven enhancements of ROS 2 multi-threaded executors. In: Proc. of RTAS’23. pp. 106–118. IEEE (2023). https://doi.org/10.1109/RTAS58335.2023.00016

19. Tokariev, P.: Modular Real-Time Clock Constraint Specification Language. Ph.D. thesis, Université Côte d’Azur (Dec 2024)

20. Voirin, J.L.: Model-based system and architecture engineering with the arcadia method. Elsevier (2017). https://doi.org/10.1016/C2016-0-00862-8