# Considerations on Software Verification of Multi-Core Processors in Pursuance of Aeronautical Certification

Frédéric Boniol, Anthony Fernandes Pires, Philippe Foubert, Benjamin

Lesage, François Thurieau

► To cite this version:

Frédéric Boniol, Anthony Fernandes Pires, Philippe Foubert, Benjamin Lesage, François Thurieau. Considerations on Software Verification of Multi-Core Processors in Pursuance of Aeronautical Certification. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.18. hal-05513718

HAL Id: hal-05513718

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

Submitted on 19 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
# Considerations on the Software Verification of Multi-Core Processors
in Pursuance of Aeronautical Certification

Frédéric Boniol¹, Anthony Fernandes Pires², Philippe Foubert³, Benjamin Lesage⁴ and François Thurieau⁵

1,2,4 ONERA, 31400 Toulouse, France

firstname.lastname@onera.fr

3,5 SAFRAN ELECTRONICS & DEFENSE, 91300 Massy, France

firstname.lastname@safrangroup.com

## ABSTRACT

Embedded systems undergo a rigorous certification process to ensure the airworthiness of aircraft. The process becomes increasingly difficult as the systems become complex. Nowadays, multi-core processors (MCPs) are present in everyday equipment. Naturally, the question of their certification for aeronautical use then arises. Indeed, while they offer many advantages, they come with risks concerning the potential use of shared resources leading to interference between applications, and therefore unsafe behaviour for airworthiness. The AMC 20-193 is one of the most prominent certification standards for the use of MCP in avionic systems and equipment. It provides a set of ten objectives, going from software planning to verification of the MCPs. While these objectives enlighten the applicant on the path to certification, they are not prescriptive on the means to satisfy them. Our work aims at investigating a way to satisfy a particularly challenging objective of the AMC 20-193 dealing with software verification, named *MCP Software 1*, in a particular context. In this paper, we present our understanding of *MCP Software 1* and suggest a strategy for its satisfaction for MCPs in our scope. We also recommend an adapted process to apply the strategy.

## 1. INTRODUCTION

Given the prevalence of multi-core processors (MCPs) in everyday equipment, the aeronautic domain has to deal with their emerging use in avionic systems and therefore with their certification. MCPs present multiple advantages, allowing different applications to run in parallel on different cores while sharing resources, offering better performance and reducing costs. Nevertheless, with these advantages come risks that make their certification more difficult: the use of a shared

resource may end up creating interference between applications hosted on MCPs, potentially leading to unsafe behaviour. Naturally, solutions exist to prevent or mitigate these interference. For instance, the use of a spatial and temporal mapping to enforce the path and schedule of the applications' transactions through the MCPs hardware resources is a possible solution in some cases [13]. But this mapping must be supported by the hardware platform. Another example is the use of a time-driven execution model to reach temporal partitioning and avoid temporal interferences [2]. However, it comes at the expense of performance.

Even though many solutions are available to tackle the risks associated with the usage of MCPs, their safe usage needs to be verified and demonstrated for certification. In the context of MCPs, the AMC 20-193 [5] (previously known as the CAST32A [6] position paper) standard issued by the EASA introduces acceptable means to demonstrate the compliance with airworthiness regulations for the usage of MCPs in embedded systems. While not the only means to show compliance with regulation, the AMC offers a set of objectives an applicant can satisfy for this demonstration. There are ten objectives in total, each focusing on specific topic of interests going from software planning, to resource usage and software verification on MCPs. How to reach these objectives is up to the applicant which mean that they need to precisely understand them in order to come up with an acceptable means of satisfaction. While this task may seem trivial at first glance, it can prove to be complex [16].

In our context, we are interested in satisfying a particularly challenging objective of the AMC 20-193 dealing with software verification, named *MCP Software 1*, in the context of the certification of a MCP platform with a DAL A certified hypervisor. This paper describes the work done to attempt to tackle this objective, through our analysis of the objective, the identification of the key underlying points, and our leads to reach its satisfaction.

It is organised as follows. In Section 2, we give the back-

<footnote>Frédéric Boniol 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>
ground of the work, introducing multi-core processors and the problem of their certification, and briefly introducing the AMC 20-193 with a focus on the particular objective we are interested in. In Section 3, we describe our understanding of the *MCP Software 1* objective. In Section 4, we suggest a strategy to satisfy *MCP Software 1* while structuring the reasoning to demonstrate this satisfaction for the family of MCPs covered in the scope of this paper. In Section 5, we recommend a process tailored to the strategy. Section 6 positions our work with related work. We conclude in Section 7.

## 2. BACKGROUND

### 2.1. Hardware Background

As expressed in [7], a Multi-Core Processor (MCP) is a hardware device composed of different computing elements such as two or more cores on which software applications are executing, internal memories that can be private or shared, and interconnects for communication. A Multi-Core Platform, is a platform composed of a hardware architecture including MCPs, a configuration, and an executive layer.

While MCPs offer much needed benefits [10], they come with risks. As discussed in [5], MCP allows executing in parallel various software applications hosted on different cores. As a result, some of these software applications may attempt to concurrently access the same shared resource, causing conflicts among them. These conflicts can manifest themselves in the form of delays in the access of the resource, and as such in the execution of the applications. These delays are referred to as *time interference*. Furthermore, the parallel execution of the software applications offered by the MCP may affect their data and control coupling, leading to possible data errors or undeterministic behavior. These issues are referred to as *functional interference*.

### 2.2. Certification Background

The AMC 20-193 [5] describes the Acceptable Means of Compliance with airworthiness regulation for the use of MCPs in avionic systems. It conveys ten objectives that the applicant should satisfy. Some simply require descriptive enumeration, such as the planning objectives. Some, on the other hand, require more complex activities such as the objectives covering the resource usage analysis for instance. In our context, we focus on the objectives covering software verification, in particular the objective called *MCP Software 1* (SW1).

This objective states that "*The applicant has verified that all the software components hosted by the MCP meet the objectives of the applicable software guidance. In particular, the applicant has verified that all the hosted software components function correctly and have sufficient time to complete their execution when all the hosted software and hardware of the MCP is executing in the intended final configuration.*". However, the means to satisfy this objective depends on the type of the MCP platform. This point will be developed in Section 3.

## 3. UNDERSTANDING MCP SOFTWARE 1

### 3.1. Overview

Our work focuses on the *MCP Software 1* objective of AMC 20-193. As introduced in Section 2.2, this objective addresses the need for the applicant to verify that all the software components hosted by the MCP are compliant with the objectives of the applicable software guidance, i.e. AMC 20-115D [4] and project-specific guidance. By software components, the AMC 20-193 means "*any part of software which may access shared resources in the MCP*", including software application, operating system or hypervisor. The objective states that there are two key points to check for hosted software components. Firstly, that they function correctly within the Intended Final Configuration (IFC). Secondly, that they have sufficient time to complete their execution within the IFC. For each of these points, the AMC distinguishes two cases, depending on the capabilities of the MCP platform. Either the MCP has robust partitioning and the applicant can verify the hosted software components separately and calculate their Worst-Case Execution Time (WCET) on the processor separately. Or the platform does not have this robust partitioning and the applicant has two options for ensuring that the hosted software components function correctly and have enough time to complete their execution. If the functional (respectively time) interference of the software component are mitigated, or excluded by design, the applicant can check this software component separately from a functional (respectively temporal, i.e. determine the WCET) point of view. Otherwise, the applicant must carry out the verification with all the software components running on the IFC. A summary of the various possible cases for satisfying *MCP Software 1* is given in Table 1.

<table><caption>Table 1. *MCP Software 1* understanding</caption><thead><tr><th colspan="2">Platform with Robust Partitioning</th><th>Verification of the functional correctness of software components</th><th>Verification of the temporal correctness of software components</th></tr></thead><tbody><tr><td rowspan="2">Platform without Robust Partitioning</td><td>Functional interference (resp. time) mitigated or excluded by design</td><td>Each software component can be verified separately</td><td>Each software component can be verified separately</td></tr><tr><td>Functional interference (resp. time) not mitigated and not excluded by design</td><td>Each software component can be verified separately</td><td>Each software component can be verified separately</td></tr><tr><td colspan="2"></td><td>The software components must be tested on the target MCP platform with all the software components running in the IFC, including robustness tests of the MCP interfaces.</td><td>The WCET must be determined by analysis and confirmed by tests on the target MCP, with all software components running in the IFC.</td></tr></tbody></table>

From this representation, there are two matters that appear crucial to conduct the verification of the functional and temporal correctness of the software components. First, there is the need to understand if the applicant has robust partitioning to figure out which case of the objective it is dealing with. The second point is that in the case where there is no robust partitioning, the applicant needs to do its verification activities
in the scope of the Intended Final Configuration (IFC). This
requirement leads to the need to investigate what is an IFC.
Although definitions are provided in the AMC for both robust
partitioning and the IFC, these definitions could remain open
to interpretation. We discuss our analysis of these two con-
cepts and their implications in the next sections in order to
reach a full understanding of the *MCP Software 1* objec-
tive.

## 3.2. The property of Robust Partitioning

The AMC defines the robust partitioning as the fact than an
MCP exhibits both robust resource partitioning and robust time
partitioning. The definitions of these two concepts are also
given in the AMC.

Robust resource partitioning for an MCP is defined as "robust resource partitioning is achieved when: software partitions cannot contaminate the storage areas for the code, I/O, or data of other partitions; software partitions cannot consume more than their allocation of shared resources; and failures of hardware unique to a software partition cannot cause adverse effects on other software partitions.".

Robust time partitioning for an MCP is defined as "this is achieved when, as a result of mitigating the time interference between partitions hosted on different cores, no software partition consumes more than its allocation of execution time on the core(s) on which it executes, irrespective of whether partitions are executing on none of the other active cores or on one, more than one, or all of the other active cores.".

Claiming and justifying the robust partitioning on an MCP is a delicate problem. For instance, the applicant could claim robust partitioning is achieved by the IFC as a whole. This would be supported by evidence that the software partitions do not interfere with each other at the functional and temporal level, e.g. through tests on the target MCP under the IFC and under various configurations of active software partitions to highlight that no partition is impacted by the others. This is not that much different or less expensive that conducting the verification activity that is expected in *MCP Software 1* for an MCP platform without robust partitioning. One could see it as a *chicken-or-egg paradox* situation and ask oneself the following question: what is coming first ? the robust partitioning or the testing of the MCP platform ?

Robust partitioning may be supported and justified by a subset of the IFC. As an example, the MCP platform may offer robust resource partitioning [1] irrespective of the actual software partitions: tests must support the claim across configurations covering various resource allocations and software partitions, and the IFC must be shown to fall in scope of the covered configurations. The provision of evidence to support the claim is more complex, as it must hold irrespective of portions of the IFC; it is not a small feat to achieve, but the evidence may then be reused across systems. Native partitioning support often means degrading properties that made an MCP platform of interest [8]. In a domain like critical embedded systems where performance is also crucial, it is an important trade-off. So ultimately, this property would primarily depend on the software architecture that has been chosen for the MCP platform and it would need to be justified by tests or uses a

very specific software architecture which inherently possesses
the property.

## 3.3. The matter of the Intended Final Configuration (IFC) and its consequences

The AMC defines the IFC as: "*the configuration of the software and hardware in which the set of the MCP resources had been defined by implementing the configuration settings and all software components have been installed on the target MCP*" [5]. From our point of view, this definition fits the description of a Final Configuration, i.e. the configuration of the platform that is going to be embedded, while the term "*Intended*" remains ambiguous. If we follow the definition of the verb "*intend*" from the Cambridge Dictionary, it means "*to have as plan or purpose*". It would suggest that it is something that is planned, but not yet tangible.

Yet, the AMC specifies the following statement for the objectives dedicated to software verification such as *MCP Software 1*: "*The WCET of a software component or task may increase significantly when other software components or tasks are executing in parallel on the other cores of an MCP. [...] Interference and interactions between software applications or tasks occur via the proprietary internal mechanisms of an MCP. Any simulation of those mechanisms is, therefore, less likely to be representative in terms of functionality or execution time than testing conducted on the target MCP in the intended final configuration, and thus is less likely to detect errors.*". It substantiates the definition given for the IFC and that it needs to be considered on the target MCP with all the configuration settings implemented and all the software components installed.

This definition has a significant consequence. For platforms without robust partitioning, it requires the applicant to find ways to test, to measure and to return results in the specific layout defined by the IFC for *MCP Software 1*, i.e. testing occurs on the target MCP platform with all the software components running in the IFC. For the remainder of the paper, we will use the term *instrumentation* to refer to the implementation of techniques to carry out tests and observations on an MCP platform. Instrumentation can be intrusive [3, 17], i.e. the software or configuration of the MCP platform needs to be extended to carry out tests and observations, or non-intrusive [14, 12], i.e. the testing and observations are achieved using external probes.

Both have benefits and drawbacks but either way, instrument-
ing the IFC comes with many challenges. The first challenge is
that the instrumentation cannot alter the functional behaviour
of the MCP platform. To be compliant with *MCP Software 1*, the testing must be done in the IFC on the target MCP which
means that the IFC needs to remain the same through the in-
strumentation. Any extension of the IFC in the case of an
intrusive instrumentation, or the use of specific interfaces of
the MCP in the case of external instrumentation, would need
to be carefully justified and agreed with certification author-
ities. A second challenge is that the instrumentation should
not bring bias to the observations. For instance, the probe ef-
fect [9] is a well-known issue for the measurements of timing
or functional properties, whether the instrumentation is intru-
sive or not. A third challenge is that the testing and collection
of observations enabled by the instrumentation should not be
time consuming. The applicant should be able to obtain re-
sults quickly enough in order to detect and fix issues, but also
in order to facilitate repeatability for certification. A last chal-
lenge is to ensure the coverage of the observations to ensure
confidence on the verification activity. Indeed, the more soft-
ware components an applicant would have on its MCP plat-
form, the more complex the platform would be in terms of
IFC and the more test cases the verification will require. So
this problematic of coverage is directly linked to the ability of
the instrumentation to enable all the required tests and capture
the necessary observations. This coverage challenge is crucial
as it may be related to the other challenges. Indeed, the cover-
age criteria will not only need to ensure the confidence in the
verification but also ensure that the duration of the test cam-
paign is acceptable to reiterate the campaign. It will also need
to ensure that all the functional modes and all the possible time
interferences are covered by the tests, without interfering with
the original IFC.

Note that intrusive and non-intrusive instrumentations alike
are affected by these challenges; non-intrusiveness does not
imply the absence of impact on the IFC and such instrumen-
tations need to be justified. As an example, the NEXUS Trace
facilities on the QorIQ T1042 can be used to collect execution
time on the MCP without the injection of additional code [14].
But the facilities are inactive by default, and unlikely to be ac-
tive in a deployed system due to security concerns. Therefore,
their activation and their impact on supporting *MCP Software*
1 should be justified.

4. A STRATEGY TO SATISFY MCP SOFTWARE 1

From our understanding of *MCP Software 1*, we present a
strategy to satisfy the objective, and in particular the temporal
aspects relevant to our scope. In this section, we first describe
the assumptions derived from our scope that define the aspects
to be addressed, and we then present the strategy itself before
discussing its justification risks and the open problems.

**4.1. Assumptions on the scope**

As described in Section 3.1, *MCP Software 1* requires two
key points to be verified on the software of the MCP. First, the
applicant must show that the software components function
correctly within IFC. Second, the applicant must show that
they have sufficient time to complete their execution within the
IFC. Our work focuses on the latter *i.e.* temporal correctness.
In our scope, we consider that the verification of functional
correctness has already been achieved [3]. This corresponds
to Assumption 1.

**Assumption 1** *The functional correctness of the software components of the MCP platform has already been verified and demonstrated.*

The scope of our work also considers that the MCP platform
offers no support for robust partitioning or that we take no
credit from such support: there are time interference that have
not been excluded by design but are mitigated through provi-
sions in the allocated execution time to account for possible
interference. Yet we still need to verify that the provisions
are sufficient. This decision reflects the point of view we ex-

pressed in Section 3.2: even if it would be possible to demon-
strate the robust partitioning of the MCP platform, putting our-
self in the case where we consider there is not, allows us to fo-
cus on the verification of the IFC as a whole with the most de-
manding conditions, and be more confident on the robustness
of the platform. This assumption is stated in Assumption 2.

**Assumption 2** *The MCP platform is considered to have no demonstrated robust partitioning.*

Based on Assumption 1 and Assumption 2, we acknowledge
that our work focuses on the part of *MCP Software 1* that
is dedicated to the verification that software components have
sufficient time to complete their execution based on the deter-
mination of the WCET of each software component by anal-
ysis and the confirmation of this WCET by tests on the tar-
get MCP, with all software components running in the IFC
(bottom-right cell in Table 1). The strategy presented in the
following will allow satisfying this part of the objective while
structuring the reasoning.

In this context, we consider that we use intrusive instrumen-
tations for the MCP platform of our scope. This is expressed
in Assumption 3. The rationale for this assumption is similar
to the one supporting Assumption 2: we focus at this stage
on harsher conditions to improve confidence regarding the ro-
bustness of the platform in the IFC. To that end, we expect
to test the WCET in adverse conditions by injecting stress to
exacerbate time interference. In our particular scope, this can
only be achieved using intrusive instrumentations.

**Assumption 3** *Intrusive instrumentations are used for the MCP platform.*

Finally, we noted in Section 1 that the MCP platform consid-
ered in our scope uses a supervisor DAL A. This supervisor
allows guaranteeing Assumption 4.

**Assumption 4** *The MCP platform has an executive layer which performs tasks in a manner that respects functional dependencies, functional determinism and memory protection, provided that the tasks do not exceed the allocated execution time.*

Based on Assumption 1, we know that the software compo-
nents function correctly for the MCP platform in the IFC.
Based on Assumption 4, we consider that functional determin-
ism is ensure by the supervisor. In that way, we can conclude
that if the software components terminate in the allocated ex-
ecution time, then we consider that the functional correctness
is preserved.

4.2. Arguing the WCET analysis and testing in the IFC

In the scope of *MCP Software 1* and for MCP platforms
without robust partitioning, we present a strategy based on the
instrumentation of the IFC to test and analyse the WCETs
of its software components, and to carry out the verification
that said software components have sufficient time to complete
their execution. This strategy relies on a number of support-
ing properties. An overview of said properties and the related
concepts is given in the conceptual diagram in Figure 1.

The first concept is of course that of IFC, as defined in the
<figure><img src="image_2.png" /><figcaption>Figure 1. Conceptual model of the concepts structuring the strategy</figcaption></figure>

AMC (see Section 3.3). For the sake of clarity, we restate the definition of IFC in Definition 1.

**Definition 1 (IFC)** *The configuration of the software and hardware in which the set of the MCP resources had been defined by implementing the configuration settings and all software components have been installed on the target MCP.*

The second concept is that of instrumentation, as presented in Section 3.3 and reiterated in Definition 2. We distinguish two purposes for instrumentation. The first purpose is *stress injection* in order to exacerbate time interference and explore the temporal behaviour of software components in different adverse scenarios. For instance, a stress injection instrumentation could use applicative code to exacerbate time interference on software components by overwhelming shared resources with additional accesses. This kind of approach has been used for several years in order to analyse time interference effects and estimate WCET in the context of MCPs [19, 18]. The other purpose of instrumentation is the *measurement* of the behaviour of software components, in particular in reaction to stress injection.

**Definition 2 (Instrumentation)** *The implementation of techniques to carry out tests and measurements in an IFC on an MCP platform.*

From this definition, we introduce the concept of authorized instrumentation. An instrumentation of the IFC is authorized if it only extends the IFC without altering its composing elements, e.g. the functional behaviour of existing software components should not be impacted by an authorized instrumentation,

or a software component may perform additional accesses to shared resources due to interference but not less. The definition is given in Definition 3.

**Definition 3 (Authorized Instrumentation)** *An instrumentation is authorized if it only extends the IFC without altering the functional behaviour, resource usage, resource access of the elements of the IFC. "alter" is understood in this definition as an action that will remove or hinder elements of the IFC. Any mechanism that is only adding to IFC without modifying or altering the expected behaviour of the MCP platform in the IFC is authorized.*

Based on these concepts, we introduce the cornerstone of the strategy in the Definition 4: the concept of Instrumented IFC Template. An Instrumented IFC Template is an IFC for which authorized instrumentations have been identified, implemented, and parametrised but not yet instantiated i.e. the applicant knows where and how to introduce instrumentation in the IFC without altering it, but the applicant has yet to configure the instrumentation. The same instrumentation mechanism may support various configurations and thus be instantiated in various ways. Note that an Instrumented IFC Template should be based on a stress injection and a measurement instrumentation to support the observable evaluation of software components under duress in our scope. For instance, in the case of an instrumentation for stress injection, parameters could be the software code to generate the stress, the intensity of the stress, the target of the stress in terms of resources or software components, etc. These parameters are called *Instrumentation*
parameters for the remainder of the paper.

**Definition 4 (Instrumented IFC Template)** *The IFC for which authorized instrumentations allowing stress injection or measurements have been identified and implemented but the actual parameters have yet to be populated.*

An Instrumented IFC template is considered as encompassing the IFC, i.e. any behaviour, resource usage and resource access attainable through the IFC must remain so in the Instrumented IFC Template for all software components. To ensure this relationship, the Instrumented IFC Template must satisfy three properties as defined in Property 1, Property 2, and Property 3. These three properties can only be guaranteed if the authorized instrumentations enforce them. By complying to these three properties, we consider that the instrumented IFC template can only exacerbate the worst-case behaviors of the MCP platform in the IFC while ensuring that the original behaviors are still observable.

**Property 1 (Encompassing resources access)** *Each software component from the Instrumented IFC template has access to the same resources as in the IFC.*

**Property 2 (Encompassing resources usage)** *Each software component from the Instrumented IFC template has greater or equal resource usage as in the IFC.*

**Property 3 (Encompassing functional behavior)** *Each software component from the Instrumented IFC template has the same functional behaviour as in the IFC.*

Once an Instrumented IFC Template is defined, it can be instantiated to obtain an Instrumented IFC as per Definition 5. An Instrumented IFC is the IFC in which the authorized instrumentations identified in the Instrumented IFC Template have been implemented and are fully parametrised. It is possible to instantiate more than one Instrumented IFC following the same Instrumented IFC Template: each instrumented IFC is a parametrised instance of the Instrumented IFC Template. In other words, an instrumented IFC can be seen as a specific testing scenario for one or more software components.

**Definition 5 (Instrumented IFC)** *An IFC that is fully instrumented based on an instrumented IFC template in order to conduct testing on a specific software component based on specific parameters, to observe events and gather information for verification purposes.*

The set of all possible instrumented IFC of an MCP platform is called the Instrumented IFC domain. However, only a subset of the domain is necessary to the analysis and testing of the WCET. There are many reasons for this. First, the domain for a MCP platform contain cases that are actually not feasible under the IFC. For example, accesses to a shared resource from a specific core may be precluded by the IFC using a memory protection unit, and no configuration of a stress instrumentation will be able to trigger accesses from that core to the resource without causing unexpected exceptions. Second, measurements of a software component to validate its WCET may not require that all instrumented IFC applying stress have

been observed; the applicant may want to select a particular set of instrumented IFC for each software component that are adequate to obtain a trustful validation of its WCET, e.g. focusing on the shared resources used by the component, or selecting high stress instrumented IFC. Third, testing should not be prohibitively time-consuming in order to be able to obtain measurements quickly enough in order to detect and fix issues, but also in order to facilitate repeatability for certification, as expressed in Section 3.3. Therefore, we introduce the concept of *Observed Instrumented IFC Domain* given in Definition 6.

**Definition 6 (Observed Instrumented IFC Domain)** *The set of all instrumented IFC of an MCP platform instantiated according to a unique instrumented IFC Template by an applicant for observation.*

The Observed Instrumented IFC Domain is therefore limited to a subset of possible instrumentation parameters and values. It should ensure the reliable evaluation of the WCETs of all the software components of the MCP platform. This set is referred as the Coverage of the Instrumentation Parameters. Its definition is given in Definition 7. In other words, the Observed Instrumented IFC Domain is restricted by the Coverage of Instrumentation Parameters, as represented in Figure 1.

**Definition 7 (Coverage of Instrumentation Parameters)**

*The set of instrumentation parameters that is sufficient to ensure that the measurements for the evaluation of the WCET of every software component is reliable.*

This concept represents the coverage between all scenarios for all the software components. We further consider that the applicant needs to ensure that enough measurements are collected within each scenario, i.e. Instrumented IFC, to ensure a reliable evaluation of the WCET per scenario. Therefore, the concept of Coverage of execution time distribution is defined in Definition 8. In that sense, an Instrumented IFC requires a coverage of its own execution time distribution, as expressed in Figure 1.

**Definition 8 (Coverage of execution time distribution)**

*The quality of observations under an instrumented IFC that is sufficient to derive a WCET for this instrumented IFC.*

The evaluation of the WCET for a software component in the scope of the Observed Instrumented IFC Domain is achieved by deriving the WCET from all the WCET derived from each observed instrumented IFC related to the software component. If this derived WCET is in the allocated execution time of the software component, then we consider that this software component has sufficient time to complete its execution in the IFC. Yet, to reach this conclusion, the Observed Instrumented IFC Domain must possess a property of dominance in order to ensure that the derived WCET from the observations is always greater or equal to the theoretical WCET under the IFC. This property is defined in Property 4 and can only be ensured if the Instrumented IFC Template complies with Property 3, Property 2 and Property 1, so that each instrumented IFC can only exacerbate the worst-case behaviours of the MCP platform in the IFC while ensuring that the original behaviours are still observable.
**Property 4 (Overall WCET Dominance)** The WCET of a software component derived from a set of Observed Instrumented IFC is greater than or equal to the derived WCET of the same software component in the IFC.

**4.3. Discussion**

The strategy described in this section offers a way for the applicant to carry out the analysis and testing of the WCET of software components in the IFC while backing up their demonstration based on the proposed structuring concepts, properties and reasoning. This strategy nevertheless presents some justification risks and open problems.

**4.3.1. Justification Risks**

One of the main justification risks is that the concept of Instrumented IFC is not mentioned in *MCP Software 1*. The objective requires that the WCET must be determined by analysis and confirmed by tests on the target MCP with all software components running in the IFC, and a way to measure the execution time of software components under the IFC is thus unavoidable. Which means that the burden of justification rests on showing that the authorized instrumentations do not alter the IFC and are acceptable by the certification authorities. It is an open problem that is discussed further.

Another central justification risk is the Overall WCET Dominance property expressed in Property 4. This property ensures that the WCET that we derived from the measurements in each instrumented IFC is always greater or equal to the theoretical WCET that could be derived from the IFC. As previously discussed, this property can be ensured if the Instrumented IFC Template complies with Property 3, Property 2, and Property 1. In turn, these properties can only be guaranteed if the authorized instrumentations enforce them, shifting once more the burden of justification onto the choice of the authorized instrumentations. However, even if these properties are ensured, there is still a phenomenon that can cause an issue: *timing anomalies* [15]. A timing anomaly is a situation where a local slowdown may result in an overall faster execution, e.g. a cache miss may result in a faster execution than a cache hit. Thus a software component under aggravated stress may run faster than in its nominal condition of execution. In this case, one can argue that if all the observed Instrumented IFCs are subject to this phenomenon, the Overall WCET Dominance property no longer holds. While we are confident that this phenomenon is negligible during the testing, we need to justify that it does not affect our strategy.

For instance, let us illustrate the Overall WCET Dominance property for a software component in the Figure 2. The figure presents the theoretical Cumulative Distribution Functions (CDF) for the IFC and a number of observed CDF for observed Instrumented IFCs. The CDF captures the portion (y-axis) of actual (IFC) or observed executions which execution times falls below a given value (x-axis); the WCET or highest observed execution time (HWM) thus occurs when the curve reaches 1. Any sound WCET estimate should thus be greater or equal to the actual WCET, that is on the right of that point.

The leftmost curve corresponds to a timing anomaly where the software component in the observed Instrumented IFC (dashed

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

<figure><img src="image_4.png" /><figcaption>Figure 2. Illustration of the overall WCET dominance for a software component</figcaption></figure>

line) consistently executes faster than the software component in the IFC (solid line). While the majority of CDFs for observed Instrumented IFC are on the right side of the curve of the IFC (i.e. the software component has a longer execution time under the observed Instrumented IFCs than under the IFC), we need a way to gain confidence that it is always the case. One solution would be to justify that the coverage of instrumentation parameters ensures there is always a majority of Observed Instrumented IFCs where the software component has a longer execution time than in the IFC. But it means shifting the burden on the justification of the coverage. Another solution would be to justify that the WCET analysis techniques applied to each observed Instrumented IFCs do result in higher estimates than in the IFC, similarly shifting the burden of justification on said analysis.

**4.3.2. Open Problems**

The justification risks revolve around two main open problems: the justification that the authorized instrumentations do not alter the IFC and are acceptable by the certification authorities, and the justification of the coverage of the instrumentation parameters, i.e. the coverage of the testing scenarios.

For the first problem, while verifying that the authorized instrumentations are acceptable by the certification authorities can be achieved by interacting with the authorities (which is expected during a certification process), choosing the authorized instrumentations and justifying that they do not alter the IFC while enforcing Property 1, Property 2, and Property 3 will require a more structured approach. Our initial prospect is to start by identifying the elements composing an IFC in order to understand what could alter it. Our view on the composition of an IFC is summarised in Table 2. This composition is structured through two categories: elements in the scope of the architecture (i.e. a container) or in the scope of the software implementation (i.e. a content).

In the case of an intrusive instrumentation, our initial opinion is that the only elements open to instrumentation, without altering their functional behaviour and while allowing the insertion of measurement points, are the contents of software components. The instrumentations should add code before
<table><caption>Table 2. IFC Composition</caption><tr><td>Containers (i.e. architecture aspects)</td><td><ul><li>Software Components: Kernel, tasks</li><li>Planning/temporal mapping (Allocated execution time, scheduling constraints)</li><li>Configuration Settings (core and memory frequency, scheduling policies, communication choices)</li><li>Software Components Mapping<ul><li>On Software Components (tasks, communications, message queues, shared variable, etc.)</li><li>On Hardware Components (memory, core, devices components, etc.)</li></ul></li><li>Access Policies (MMU configuration)</li><li>Scheduling plan</li></ul></td></tr><tr><td>Contents (i.e. implementation aspects)</td><td><ul><li>Software Components: tasks source code, Driver(s) (BSP level)</li><li>Software Components: Kernel (Data table + Kernel libraries insertion in applications)</li></ul></td></tr></table>

or after that of existing software tasks. In this way, the code could allow exacerbating the time interference caused by some software components on others, while preserving the existing configuration settings, mappings, and original code in turn preserving functional behaviour. One could argue that this could cause a change in memory alignment. A verification that the impact is negligible should be done in this regard. Another consideration for defining authorized intrusive instrumentations is the available storage space in the target MCP to carry the tests and store measurements. Finding available storage space in the target MCP can be problematic as an MCP usually has a limited amount of space and it is usually primarily optimised to host the software components. Storage should also be accessible to the instrumentation within the confines of the IFC, e.g. access policies.

The second problem is to choose and justify the coverage criteria for the instrumentation parameters in order to ensure that worst case scenarios have been covered and avoid the justification risk linked to timing anomalies. Our initial prospect to partially answer to this problem would be to actually use the instrumentation for measurements in order to observe the IFC without any stress injection. In this way, we could possibly obtain an approximation of the solid curve represented in Figure 2 and compare the curves obtained from the observed Instrumented IFCs to gain confidence on their dominance and their coverage of worst-case scenarios.

## 5. SUGGESTED PROCESS

From the strategy proposed in Section 4 and the scope of the considered MCP platform, we propose a preliminary process to support an applicant in the definition of Instrumented IFCs, i.e. testing scenarios, in ensuring that every software component has sufficient time to complete their execution. Our proposal is described in Figure 3.

Step 1 consists in exploring the platform in order to build an understanding of its behaviour. In particular, we will obtain a model of the hardware architecture, an identification of possible interference channels, etc. It will also be necessary to identify the adequate granularity to model the platform and the resources to be considered in the IFC. For example, if the platform supports only SRAM memory, without caches or DRAM, memory access times are likely to be constant irrespective of the memory placement and therefore said memory placement should not affect the WCET. This step could be supported by the PHYLOG framework described in [7], especially for the identification of the possible interference channels.

In Step 2, any programming or configuration constraint specific to the project must be identified. This will provide part of the "applicable software guidance" mentioned in *MCP Software 1* (the other part corresponding to the involved certification standards).

Step 3 consists in implementing and configuring the platform. In particular, it will define the IFC and the software architecture.

Step 4 identifies available memory regions on the platform for intrusive instrumentations, e.g. to store the stressing injection and to store measurements during their collection, contributing to the definition of feasible authorized instrumentations.

Step 5 consists in identifying the authorized instrumentations for an IFC while taking into account the constraints of the scope. It also consists in justifying that these instrumentations do not tamper with the functional and temporal behaviour of the software components in the MCP. It is in this stage that Property 1, Property 2, and Property 3 must be justified. The result is an Instrumented IFC Template as per Definition 4.

Step 6 encompasses the selection of the Instrumented IFC, i.e. testing scenarios, from the Instrumented IFC Domain. It is in this step that the coverage criteria for instrumentation parameters must be defined and justified to tackle the problems reported in Section 4. It results in the definition of a set of testing scenarios, i.e. the Observed Instrumented IFC Domain.

Step 7 covers the definition of the testing campaign based on the testing scenarios. In this step, the coverage criteria for the observed execution time distributions must be defined and justified.

Step 8 consists of the collection of measurements by implementing the defined test campaign, ensuring that appropriate coverage has been achieved for each scenario.

Step 9 consists in the estimation of the derived WCET and the provision of the results. These results are then evaluated in the following way: if the derived WCET shows that the software components have sufficient time to complete their execution on the MCP platform within the IFC, then the process is over and the results can be used to demonstrate the satisfaction of this part of *MCP Software 1*. Otherwise, the software architecture needs to be amended to verify this property and the process needs to iterate as described in Figure 3.

In the case of an iteration, the step 10 covers the revision of the software architecture and, by extension, the revision of the IFC. Note that as the software architecture is revised, all artefacts used or created downstream of the process are also likely to be modified, including the instrumentation parameters.
<figure><img src="image_5.png" /><figcaption>Figure 3. Preliminary proposal</figcaption></figure>

# 6. RELATED WORK

Numerous contributions consider the challenges of instrumentation, to address either stress injection [3, 17, 12] or measurements [11, 14, 3]. RapiDaemons [3] and Kryptonite [17] use intrusive software stressors to add pressure on shared resources. Where the selection of RapiDaemons [3] is guided by the expected interference channels, Kryptonite [17] incrementally builds stressors tailored to a software component by composing smaller kernels. [12] uses a non-intrusive hardware method. They propose a WCET computation mode, where the MCP platform delays every request to a shared resource by the theoretical maximum latency resulting from interference. All three techniques [3, 17, 12] operate outside the IFC, as they isolate the software component during analysis to inject stressors or to delay requests. [3] relies on instrumenting the software component's code to collect timestamps at key moments of its execution. Conversely, [14] addresses measurements using the platform trace unit and an external probe. Both approaches need further justification to ensure either the additional code or the use of the trace unit (should it be absent from or deactivated in the IFC) fall within the scope of authorised instrumentations.

In [11], the authors present a non-intrusive approach for hybrid WCET analysis in order to answer to the time analysis requirement of the *MCP Software 1* objective. Their approach is dedicated to COTS (Commercial-off-the-shelf) MCP, in the same way as our work, and it is based on the coupling of two tools. First, an FPGA-based tool for trace analysis, called CEDARtools, processes and decodes the incoming compressed trace data at runtime in order to reconstruct the control flow of the system under observation and to provide traces for offline analysis. Second, an hybrid WCET analysis tool, named TimeWeaver, analyses these traces to estimate WCET. Yet, the non-intrusive instrumentation approach presented in [11] requires an MCP platform in the IFC able to output traces with the required information, in order to conduct the analysis. The different ways to output traces from an Embedded Trace Unit (ETU) to an external tool are discussed in the paper, some of them presenting minimal intrusive instrumentation

to ensure the generation of the required traces (shared bus usage with application, empowering of the application to communicate relevant trigger point to the ETU). However, it is not clear which solution was chosen to feed the approach, the representation of the process only mentioning that the Trace Data Output shall be continuous and non-intrusive for embedded systems. Concerning the compliance with AMC 20-193, the authors state that their approach is compliant with the software verification requirements, yet no detailed argumentation is given for the whole tool chain. Moreover, the authors claim that "*the use of a stressors during measurement-based timing verification contradicts objective *MCP Software 1*.*". We state differently, arguing that the use of stressors during measurement-based timing verification could be compatible with *MCP Software 1* provided that they are used in the target MCP and in an Instrumented IFC that is demonstrated to not prevent any observations that should be available in the original IFC. The concepts, definitions and properties described in our work aim at serving as building blocks for an argumentation.

In a different scope, [16] describes a guidance in order to create a job-aid for AMC 20-193. A job-aid acts as an aide-memoire to help in the completion of the certification process. The work of [16] focuses on the analysis of the contents of each objective, including *MCP Software 1*, and the definition of the questions an applicant should ask itself when attempting to satisfy each objective. While the authors join our concerns on the difficulty to achieve robust partitioning, the questions defined for the guidance are not expressed at the same level of details as the topics covered in our work. Their analysis is more at the level of the *what* than the *how*. Yet, there is no question raised about the nature of the IFC. Our work could be complementary and enable the definition of a set of questions to check for an applicant who would want to use an intrusive stressing instrumentation for the satisfaction of *MCP Software 1*. This job-aid could then be discussed with certification authorities in order to validate it and to see if it could serve as an additional guidance for applicants.
## 7. CONCLUSION

In conclusion, we presented our understanding of the objective from the AMC 20-193 referred as *MCP Software 1* and we introduced a strategy to satisfy the *MCP Software 1* requirement related to the verification that software components have sufficient time to complete their execution. This strategy outlines the building blocks that are manipulated to structure the reasoning as well as the critical points that will need to be justified. In addition, we presented a preliminary process based on this strategy in order to carry out the activity necessary for the satisfaction of the requirement of *MCP Software 1*. Our work provides a first glance into the complexity inherent to certification objectives for an applicant. It highlights the need to conduct similar analyses for the most complex certification objectives in order to define adequate means to satisfy them. Such means could benefit the growing aeronautical community on MCPs.

In future work, we need to address the open problems described in Section 4 and define repeatable methods to soundly define the coverage criteria to ensure the reliability of our strategy and measurements, and to identify and justify authorized instrumentations. Then we will need to apply the recommended end-to-end process to gain confidence in the approach. An important work will also be to present and discuss the argument with certification authorities in order to validate and to refine our strategy and process. Finally, starting from the reasoning highlighted by the strategy, we need to create an argumentation pattern to support the applicant in demonstrating the satisfaction of the *MCP Software 1* requirement covered in this work. This future work will be carried out in keeping with what was achieved within the PHYLOG project<fnref n="1" /> [7] where argumentation patterns for some of the objectives of the AMC 20-193 were defined. As *MCP Software 1* was not part of it, our work would complement and extend the results of the PHYLOG project.

## ACKNOWLEDGMENT

The work presented in this paper partially relies on the PHYLOG 2 project supported by the Directorate General of Civil Aviation (DGAC). The PHYLOG 2 project is funded by the French government through the France Relance program, based on the funding from the European Union through the NextGenerationEU program.

## REFERENCES

[1] Irune Agirre, Jaume Abella, Mikel Azkarate-Askasua, and Francisco J. Cazorla. On the tailoring of CAST-32A certification guidance to real COTS multicore architectures. In *2017 12th IEEE International Symposium on Industrial Embedded Systems (SIES)*, pages 1–8, 2017. doi: 10.1109/SIES.2017.7993376.

[2] Frédéric Boniol, Hugues Cassé, Eric Noulard, and Claire Pagetti. Deterministic execution model on COTS hardware. In *Andreas Herkersdorf, Kay Römer, and Uwe Brinkschulte, editors, Architecture of Computing Systems - ARCS 2012 - 25th International Conference, Munich, Germany, February 28 - March 2, 2012. Proceedings*, volume 7179 of Lecture Notes in

*Computer Science*, pages 98–110. Springer, 2012. doi: 10.1007/978-3-642-28293-5\_9.

[3] Damien Chabrol, Jean Guyomarc'H, Fabien Siron, Guillaume Phavorin, Sam Thompson, Eric Jenn, and François Thurieau. Separation of functional and time interference concerns for efficient AMC 20-193 compliance. In *ERTS2024*, Toulouse, France, June 2024. URL https://hal.science/hal-04649192.

[4] EASA. AMC (Acceptable Means of Compliance) 20-115D Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178, 2017.

[5] EASA. AMC (Acceptable Means of Compliance) 20-193 Use of multi-core processors, 2022.

[6] FAA Certification Authorities Software Team. Multi-core Processors - Position Paper. Technical Report CAST-32A, 2016.

[7] Anthony Fernandes Pires, Frédéric Boniol, Kevin Delmas, Benjamin Lesage, Alfonso Mascarenas González, Claire Pagetti, and Thomas Polacsek. Combining Argumentation-Based and Model-Based Approaches for the Certification of Multi-Core Architectures: The PHYLOG Methodology. In *AIAA DATC/IEEE 43rd Digital Avionics Systems Conference (DASC)*, 2024.

[8] Thilo L. Fischer and Heiko Falk. WCET Analysis of Shared Caches in Multi-Core Architectures using Event-Arrival Curves. In *2023 Design, Automation and Test in Europe Conference and Exhibition (DATE)*, pages 1–2, 2023. doi: 10.23919/DATE56975.2023.10137034.

[9] Jason Gait. A probe effect in concurrent programs. *Softw. Pract. Exper.*, 16(3):225–233, March 1986. ISSN 0038-0644. doi: 10.1002/spe.4380160304. URL https://doi.org/10.1002/spe.4380160304.

[10] Pawel Gepner and Michal Filip Kowalik. Multi-core processors: New way to achieve high system performance. In *International Symposium on Parallel Computing in Electrical Engineering (PARELEC)*, pages 9–13, 2006.

[11] Daniel Kästner, Gernot Gebhard, Markus Pister, Simon Wegener, Christian Ferdinand, Albert Schulz, Martin Sachenbacher, Martin Leucker, and Alexander Weiss. Multi-core WCET Analysis Using Non-Intrusive Continuous Observation. In *ERTS 2024*, Toulouse, France, June 2024. URL https://hal.science/hal-04614448.

[12] Marco Paolieri, Eduardo Quiñones, Francisco J. Cazorla, Guillem Bernat, and Mateo Valero. Hardware support for wct analysis of hard real-time multicore systems. In *Proceedings of the 36th Annual International Symposium on Computer Architecture*, ISCA '09, page 57–68, New York, NY, USA, 2009. Association for Computing Machinery. ISBN 9781605585260. doi: 10.1145/1555754.1555764. URL https://doi.org/10.1145/1555754.1555764.

[13] Quentin Perret, Pascal Maurere, Eric Noulard, Claire Pagetti, Pascal Sainrat, and Benoit Triquet. Temporal isolation of hard real-time applications on many-core processors. In *2016 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS)*, pages 1–11, 2016. doi: 10.1109/RTAS.2016.7461363.

<footnote n="1">¹https://w3.onera.fr/phylog/en/patterns</footnote>
[14] Thomas B. Preußer, Smitha Gautham, Abhi D. Rajagopala, Carl R. Elks, and Alexander Weiss. Everything you always wanted to know about embedded trace. Computer, 55(2):34–43, 2022. doi: 10.1109/MC. 2021.3098965.

[15] Jan Reineke, Björn Wachter, Stefan Thesing, Reinhard Wilhelm, Ilia Polian, Jochen Eisinger, and Bernd Becker. A Definition and Classification of Timing Anomalies. In Frank Mueller, editor, 6th International Workshop on Worst-Case Execution Time Analysis (WCET’06), volume 4 of Open Access Series in Informatics (OASICS), pages 1–6, Dagstuhl, Germany, 2006. Schloss Dagstuhl – Leibniz-Zentrum für Informatik. ISBN 978-3-939897-03-3. doi: 10.4230/OASICS.WCET.2006.671. URL https://drops.dagstuhl.de/entities/document/10.4230/OASICS.WCET.2006.671.

[16] James Sharp, Mike Standish, Jaspal Sagoo, and Edwin van de Sluis. Towards a multi-core certification Job-Aid

for AMC 20-193. Computer Standards & Interfaces, 96:104049, 2026. ISSN 0920-5489. doi: https://doi.org/10.1016/j.csi.2025.104049.

[17] Nikhilesh Singh, Karthikeyan Renganathan, Chester Rebeiro, Jithin Jose, and Ralph Mader. Kryptonite: Worst-case program interference estimation on multicore embedded systems. ACM Transactions on Embedded Computing Systems, 22(5s):1–23, 2023.

[18] William Vance, Roshini Ashok, John Ross, Bruce Jacobs, Tuan Bui, and Mark Wotell. Analysis of cache memory interference on multicore systems utilizing shared memory aggressor applications. In AIAA DATC/IEEE 43rd Digital Avionics Systems Conference (DASC), 2024.

[19] Steven H. VanderLeest and Samuel R. Thompson. Measuring the impact of interference channels on multicore avionics. In AIAA/IEEE 39th Digital Avionics Systems Conference (DASC), 2020.