# The Challenges posed by the Aeronautical Certification of Open-Hardware System in Package

Joseph Adelaide, Henri Bollon, Frédéric Boniol, Eric Debes, David Deschans, Antoneta Fabre, Anthony Fernandes Pires, Jean-Christophe Jammes, Franck Jeulin, François Leroy, et al.

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

## To cite this version:

Joseph Adelaide, Henri Bollon, Frédéric Boniol, Eric Debes, David Deschans, et al. The Challenges posed by the Aeronautical Certification of Open-Hardware System in Package. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.17. hal-05513599

HAL Id: hal-05513599

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

Submitted on 19 Feb 2026

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# The Challenges posed by the Aeronautical Certification of Open-Hardware System in Package

Joseph Adelaide¹, Henri Bollon¹, Frédéric Boniol², Eric Debes³, David Deschans⁴, Antoneta Fabre⁵, Anthony Fernandes Pires², Jean-Christophe Jammes¹, Franck Jeulin³, François Leroy¹, Laurent Marianne¹, Alfonso Mascarenas Gonzalez², Christophe Vlacich⁵

¹SAFRAN ELECTRONICS & DEFENSE, France
firstname.surname@safrangroup.com

²ONERA, France
firstname.surname@onera.fr

³Thales Group, France
firstname.surname@fr.thalesgroup.com

⁴Thales Canada Avionics, Canada
firstname.surname@thalesgroup.com

⁵Airbus, France
firstname.surname@airbus.com

## ABSTRACT

Safety-critical airborne embedded processing devices must undergo certification processes according to standards that were written for custom developments and COTS devices usage. However, modern electronic devices are evolving from monolithic chips toward System in Package (SiP) architectures and from proprietary IPs toward Open-source Hardware IPs, paving the way to more tailoring, modularity and potential reuse of components across projects. This shift raises the question of whether the existing certification baseline remains adequate for such modern electronic devices and whether evolutions are required. The article aims to address this question by formalizing both the Open Hardware SiP domain and the certification baseline using ontologies, framing the adequacy between these two formal models as an ontology alignment problem and drawing conclusions from this alignment.

## 1. INTRODUCTION

Avionic systems undergo a rigorous certification process to guarantee the airworthiness and safety of aircraft. Certification involves an independent authority systematically evaluating whether the product has been developed to meet safety requirements. As avionic systems evolve and grow in complexity, certification authorities provide regulatory objectives acting as “acceptable means of compliance” to demonstrate the system is safe.

In the case of airborne embedded processing devices, the certification baseline addresses a large scope of concerns from software to hardware aspects. Nowadays, these types of devices are based on general-purpose COTS (Commercial-

Off-The-Shelf) processors, mainly based on monolithic integrated circuits and the certification baseline is written to be applicable to such architectures. The certification baseline considers COTS component as a component that is developed by an industry for the commercial market and supplied to a variety of different users. It is then the responsibility of the supplier to control the design and the configuration of COTS components.

Additionally, mainstream processors are facing strong changes. One such change is the emergence of open hardware, which is changing the design paradigm. This approach gives the designers the opportunities to control and to fully master the architecture and behavior of their own processors. Another important change is the rise of more integrated and smaller dies for modularity and scalability reasons. This has led to a new architecture paradigm called "System in Package" (SiP) bringing higher performances and other benefits to embedded systems.

The aim of the OHPERA (OpenHw Processeur Embarqué pouR l'Aéronautique) project funded by the DGAC (Direction Générale de l'Aviation Civile) is to consider these two significant changes for the aeronautics sector and to study the feasibility and industrial viability of a solution based on modular and scalable processor architectures using Open-Hardware SiPs. In this context, the work presented in this paper focuses on reviewing the current certification baseline applicable to airborne embedded processing devices and evaluating its adequacy in the face of the changes brought by Open-Hardware SiPs. This evaluation is based on two ontologies, one pertaining to the domain of the Open-Hardware SiPs and the other one formalizing the current certification baseline. The adequacy problem between the two domains is then formulated first as an ontology alignment problem, and second as a coverage problem of the regulatory objectives linked to the matching concepts of the Open-Hardware SiP ontology in the Certification baseline ontology.

<footnote>Adelaïde et al. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>
This paper is structured as follows. In Section 2, we give the background of the work, presenting a summary of processor evolution leading to Open-Hardware SiPs, the certification baseline and the problem statement. In Section 3, we present the ontology-driven approach used to tackle our problem. In Section 4, we give an overview of the defined ontologies. In Section 5, we present an analysis of the relationships between them and the issues found during the analysis. We discuss related work in Section 6. We conclude in Section 7.

**Scope of the article.** Not that the article only takes into account hardware component proper usage without considering software aspects or physical aspects such as thermal, mechanical, and vibrational constraints.

## 2. BACKGROUND: FROM MONOLITHIC INTEGRATED CIRCUITS TO OPEN-HARDWARE SIP PROCESSORS.

**Processor evolution.** The embedded processors have significantly evolved from the early monolithic integrated circuit designs, which integrated a single CPU core alongside essential peripherals and memory controllers on a single silicon die to optimize size, power consumption, and cost for embedded applications. As performance demands and parallel processing requirements increased, these devices evolved to incorporate processing units composed of two, four, eight or more processing cores, enabling parallel execution of multiple threads and improved throughput while maintaining power efficiency. Meanwhile, in the mainstream domain, two key trends are redefining processor design: the rise of Open-Hardware and the adoption of System in Package (SiP) integration.

**Trend 1.** The emergence of Open-Hardware has fundamentally shifted processor design paradigms on aspects such as the architecture design and the Instruction Set Architectures (ISAs). For instance, unlike proprietary ISA, initiatives like RISC-V offers a common, shared, and royalties-free ISA allowing the development of binary-compatible architectures and tools. Moreover, the development of Open-Hardware designs enables full transparency of the RTL code and allows designers to implement custom microarchitectures, and extensions tailored to specific workloads without the constraints of proprietary IP. This fosters specialization over general-purpose design, leading to more efficient and domain-specific processors (e.g., for real-time and low-power applications).

**Trend 2.** More recently, System in Package (SiP) technology has emerged as a new solution, integrating multiple heterogeneous dies (including multi-core processors, memory modules, and specialized accelerators) within a single compact package. This approach introduces a new level of modularity, and improves scalability and thermal management compared to monolithic integrated circuits, enabling the deployment of high-performance embedded systems in constrained form factors typical of IoT, automotive, and industrial environments.

**Current certification baseline.** Certification is a key concern for safety-critical systems. Certification of airborne embedded processing devices involves a critical and rigorous process governed by standards such as DO-254/ED-80 [1] and AMC 20-152A [2] for hardware, and AMC 20-193 [3]

for multi-core processors. DO-254/ED-80 provides a structured framework for the development and certification of airborne electronic hardware, such as processors, FPGAs, and ASICs, according to its level of complexity and assigned Design Assurance Levels (DALs). This industrial standard mandates rigorous processes including requirements capture, validation, design, implementation, verification, configuration management, process assurance, and traceability throughout the hardware lifecycle to meet safety objectives. AMC 20-152A, issued by EASA, recognizes DO-254/ED-80 as acceptable Means of compliance and complements it on specific topics such as custom devices, COTS IPs and COTS devices usages, and also CBA (Circuit Board Assemblies). Together, DO-254/ED-80 and AMC 20-152A establish the core of the current certification baseline for avionic airborne embedded processing devices. For multi-core aspects in these devices, AMC 20-193 provides ten certification objectives for showing compliance with regulation, ranging from planning, resource usage, error handling to software verification.

Other certification standards come in support of this core baseline. For instance, DO-160G/ED-14G [4] outlines testing procedures for environmental conditions for electronical equipment in civil aviation to ensure they can operate safely under real-world environmental conditions. There is also the AMC 20-189 [5] that describes the acceptable means of compliance with regulations for the management of Open Problem Reports (OPR) for the certification of systems, software and hardware. Obviously, there are also the DO-178C/ED-12C [6] and the AMC 20-115D [7] that identify essential activities and design recommendations for the software development process in order to be compliant with airworthiness regulations. However, they are outside the scope of hardware usage and will not be discussed further in this paper.

**Problem statement.** The core certification baseline addresses monolithic integrated circuit architectures and do not fully consider the two aforementioned trends (open hardware and SiP based on COTS). Different obstacles can be foreseen.

In the case of the SiP, the main obstacle to their aeronautical certification is the novelty of the technology in an aeronautic usage, which results in many challenges to overcome. The first one is that today's certification standards may not be precise enough to cover all the specificities of a SiP to ensure airworthiness as a SiP is not mentioned in any standard. As we will show, a SiP comes with a set of new concerns that needs to be taken into account in any Verification & Validation activities. A second challenge is that there is no experience of aeronautical certification of SiPs and no in-service experience in complex airborne systems although such experience is available in other embedded systems domains that are highly interested in SiPs, such as mobile phones, IoT and automotive. It means that the aeronautical certification process may require additional considerations to ensure the compliance with regulations. It is then crucial to ensure that any certification plan covers all the critical aspects of the SiP. Among the critical aspects that need a particular attention, one could expect (1) the requirements definition at an adequate level for certification, and (2) the Verification & Validation activities that will need to be
carried out on this particular type of integrated component and the choices of criteria for their coverage. One advantage brought by the SiP paradigm is the modularity of its internal architecture, which would allow reusing components across development. That leads to a subsequent challenge that is to be able to find a way to sough credits from the reuse and try to think the certification in an incremental way at this level of hardware.

The Open-Hardware paradigm also prompts some difficulties for certification. For instance, some royalties-free Open-source Hardware IPs may lack documentation and traceability between requirements (if any) and design, which conflicts with basic regulation requirements. Similarly, open designs often lack standardized validation and thorough testing, making it difficult to demonstrate reliability to ensure compliance with regulation. Furthermore, long-term maintenance is uncertain, as the Open-Hardware community is not structured to ensure long-term support. Consequently, while Open-Hardware comes with true benefits (notably transparency and customization capabilities), its adoption in safety-critical systems demands strict risk mitigation strategies that would be required for certification.

Therefore, the issue tackled in this paper is: is the certification baseline suitable for Open-Hardware SiPs, or does it require reinterpretation or extension?

The certification baseline studied in this paper is composed of the core certification baseline for the airborne embedded processing devices, namely DO-254/ED-80, AMC 20-152A and AMC 20-193, with the addition of the AMC 20-189. The latter applies to hardware and raises the issue of the management and classification of problem report at the new hierarchical levels introduced by the SiP technology. Other standards that may be related to Open-Hardware SiPs are left out of the work presented in this paper as they are not specific to hardware usage. DO-160G/ED-14G, which is dedicated to the testing procedures for environmental conditions for electronical equipment, falls in the certification of physical aspects such as thermal, mechanical and vibrational constraints that are out of the scope of this work.

# 3. AN ONTOLOGY-DRIVEN APPROACH

## 3.1. Why using ontologies?

To address the question raised in the previous section about the suitability of the current certification baseline with Open-Hardware SiPs, we rely on the creation of the ontologies of both domains and their comparison. There are several reasons behind this choice. First, the field of open-hardware SiP is relatively new in the aeronautical domain and we need a way to capture its characteristics in a usable and unambiguous way. Second, the certification standards deal with many concepts and considerations, and we need a means to master the size and complexity of their contents at an appropriate scale to conduct an analysis. In this context, the use of ontology appears appropriate. There are many definitions of ontology in the literature of the past decades that are reported in [8]. The one we are relying on comes from the work of [9]: "An ontology is a formal, explicit specification of a shared conceptualisation". Based on this definition, the creation of an ontology for each domain

ensures that the relevant concepts and their relationships are explicitly defined and consensual among a group of subject matter experts. This definition also requires that the resulting ontology is formal, i.e. it may be processed by a program, which may prove useful if computing support is needed in our approach. The comparison of ontologies is also an existing field of research known as *ontology alignment* [10], or *ontology matching*, that can be of value to guide our work.

## 3.2. Modus Operandi

The ontology-driven approach used in this work is based on a two-steps process. The first step consists in creating the ontologies for the certification baseline and for the Open-Hardware SiP domains and proceeding to their alignment. This alignment allows positioning the Open-Hardware SiP with respect to the hardware elements covered in the current certification baseline and understanding which part of the certification baseline would be applicable to each feature of an Open-Hardware SiP or identifying the features that are not covered at all. The second step consists in studying the coverage of the objectives and activities from the certification baseline associated to the concepts of the Open-Hardware SiP in the first step. In this context, *coverage* is intended as the ability of the associated certification objectives and activities to cover all the crucial aspects of the concepts of the Open-hardware SiP they are associated to, in order to ensure the airworthiness. The output of this two-steps process is a precise mapping of the Open-Hardware SiP concepts on the current certification baseline and the identification of the extensions or simplifications of the baseline that are needed in their specific case. An overview of this two-steps process is represented in Figure 1.

<figure><img src="image_3.png" /><figcaption>Figure 1: Two-steps process overview</figcaption></figure>

The work presented in this paper focuses on the achievement of the first step. This step is based on the use of our own customized graphical notation to create ontology diagrams based on the prominent ontology language OWL (Web Ontology Language) [11].

First, the ontologies for both the certification baseline domain and the Open-Hardware SiP domain have been defined based on this language during working sessions with ten industrial subject matter experts coming from Airbus, Safran and Thales. These experts were proficient in hardware certification and hardware development. In addition, three experts from ONERA were organizing and managing the working sessions, and the ontology diagrams. Seven working sessions were necessary to obtain the ontologies presented in this paper. Each working session was done remotely and lasted between 1h30 and 2h. Between six and ten experts were present at each session. The first three meetings allowed defining a simple version of both ontologies
composed of the core concepts. These first versions were
then extended before being discussed and amended in the
next four sessions (two sessions dedicated to each ontology).
For the Certification Baseline ontology, the concepts and
relationships of the extended version were first chosen by the
ONERA experts from the certification baseline based on the
importance of the concept in the certification. For instance,
in the AMC 20-152A, the concept of “COTS device” was
deemed important as a whole part of the document and a set
of objectives is dedicated to it. The ontology was then
discussed and amended by the industrial experts based on
their knowledge and experience. For the Open-Hardware SiP
ontology, the concepts and relationships of the extended
version were first chosen by the ONERA experts from their
experience, the knowledge acquired during the project and
the material available in the project (e.g. presentations,
minutes of meeting, state of the art, deliverables, etc.). The
selection of the concepts was made based on the frequency
of their appearance across the different materials and the
discussions occurring during project meetings. In the same
vein as the certification baseline ontology, the Open-
Hardware SiP ontology was then discussed and amended by
the industrial experts based on their knowledge and
experience.

From these two ontologies, an ontology alignment was
performed during two working sessions of 2h done remotely
with the industrial experts. As explained in [10], the
ontology alignment is usually performed by combining
different types of alignment techniques. In our work, we use
terminological techniques and structural techniques to match
the concepts of the Open-Hardware SiP ontology with the
concepts of the Certification Baseline Ontology. [10] defines
terminological techniques as the comparison of terms, strings
and texts. In our case, we compared the definition of the
concepts and look for similarity in the terms, by mainly
comparing the nature of the concept described (hardware
element, code, composite component, etc.). Structural
techniques are defined by [10] as the evaluation of the
similarity between concepts by exploiting structural
information, such as attributes or relations with other
concepts. In our case, we evaluated the similarity of the
relationships with other concepts. The more relationships to
matching concepts were present, the stronger was the
correspondence between the two evaluated concepts. The
ontology alignment was performed by first applying the
terminological technique and then the structural technique,
both based on the experts' judgments.

3.3. Validation risks

The ontology-driven approach brings many advantages for
tackling our problem. However, there are several validation
risks associated with the results obtained, which we
endeavoured to mitigate as much as possible. First, one of
the risks can be that the identified certification baseline is not
complete and miss key standards. We mitigated this risk by
exchanging with EASA on the identified certification
baseline. The result of these exchanges was that while our
core certification baseline was correct, some supporting
standards could be added to help cover some specific
features of the Open-Hardware SiPs. They are not taken into
account in the ontologies presented in this paper as they have
been deemed to have no impact on the result of the ontology

alignment by the experts. Consequently, this risk is
considered very low. Another risk can be that we did not
have enough experts or the right experts to build the
ontologies and perform the alignment. Based on the number
of experts present at each working session and the extent of
their experience, this risk is considered low. Ultimately,
another risk could be that we did not detailed enough either
of the ontologies. As the ontologies are still evolving by
adding some supporting standards, the risk is evaluated as
low in terms of ontology alignment, but could be moderate
for the evaluation of the coverage of the objectives and
activities from the certification baseline.

4. THE ONTOLOGIES

The ontologies of the Certification Baseline and the Open-
Hardware SiP domains have been defined following the
method presented previously. The resulting ontology for the
Certification Baseline consists in 28 concepts (or classes)
and 37 relationships (inheritance relationships included). The
ontology for the Open-Hardware SiP consists in 24 concepts
and 31 relationships, which is approximately the same order
of magnitude as the Certification Baseline ontology. Both are
described in this section.

4.1. Certification Baseline Ontology

As expressed previously, the Certification Baseline ontology
has been modelled based on DO-254/ED-80, AMC 20-152A,
AMC 20-193, and AMC 20-189 standards. This ontology is
represented in Figure 2. Each concept, their definition, and
relationship represented in the ontology are expressed in
these standards with very few exceptions.

The central concept of this ontology is the Airborne
Electronic Hardware (AEH) which is an “Electronic
Hardware Item intended to be installed in airborne
equipment/systems” [2]. An Hardware Item is “an item that
has a physical being” following DO-254/ED-80. Based on
this definition, an AEH can have an Hardware DAL, i.e. the
level of rigor of development assurance tasks performed on
the hardware item, a complexity, i.e. “an attribute of [...]
items, which makes their operation, failure modes, or failure
effects difficult to comprehend without the aid of analytical
methods” [12], and some Open Problem Reports. Based on
AMC 20-189, a Problem Report is “a means to identify and
record the resolution of anomalous behaviour, process non-
compliance with development assurance plans and
standards, and deficiencies in life-cycle data” which
possesses a classification, i.e. the type and the severity of the
effects of the problem, and a state (recorded, classified,
resolved or closed). An OPR is then “a problem report that
has not reached the state ‘Closed’ at the time of approval”
[5]. The Hardware DAL and the Open Problem Report are
considered dependent from the Certification Project, i.e. the
product and the context of the certification application. AEH
is mainly regulated by the DO-254/ED-80 standard and its
associated objectives and activities.

If we look in more details at AEH, the DO-254/ED-80 states
it can be an LRU, Circuit Board Assemblies (CBA), COTS
components, Custom micro-coded components or Integrated
technology components. We chose to consider all of them in
the ontology except LRU as we do not expect a SIP to be
replaceable on the field. In the DO-254/ED-80, an integrated
<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /><figcaption>Figure 2: Certification Baseline Ontology</figcaption></figure>

technology component is not explicitly defined but can represent for instance a hybrid or multi-chip module. A CBA corresponds to a board or a collection of boards. A CBA is composed of devices that can be Commercial-Off The Shelf (COTS) or Custom. A COTS device is a COTS component defined as follow: "*a device, integrated circuit or multi-chip module developed by a supplier for a wide range of customers, whose design and configuration is controlled by the supplier or an industry specification*" [2]. A Custom device is the opposite of COTS device. It is a device developed by the applicant to answer a particular need. Most parts of the design and configuration are under the control of the applicant. A custom device usually corresponds to a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuits (ASICs). They are referred to as custom micro-coded components in the DO-254/ED-80. A device can be of

type Multi-Core Processor (MCP), which is "*an AEH device that contains two or more processing cores*" as defined in the AMC 20-193 that provides their regulation. A COTS device can also store Microcode, which is "*a hardware-level set of instructions [...] typically stored in the COTS device's high-speed memory*" [2].

The Custom device is the only type of device to be further decomposed in IPs in the AMC 20-152A through a Custom Device Design, as the design is under the control of the applicant. A Custom Device Design is the description of the Custom device in terms of IPs, functional blocks, connections and interfaces. Even if this concept is expressed in the standards, there is no definition and the one given here is our interpretation. To go further, an IP is "*a design function (design module or functional blocks, including IP libraries) used to design and implement a part of or a*
complete custom device" [2]. In the same vein of the device, an IP can be COTS (i.e. "a commercially available function used by a number of different users in a variety of applications and installations [2]) or custom (i.e. "IP developed for a few specific aircraft equipment" [2]). A COTS IP is further refined in the AMC 20-152A into three formats: Soft IP, Firm IP, Hard IP. A Soft IP is a "COTS IP defined as register transfer level (RTL) code, captured in an HDL such as Verilog or VHDL, that may be readable or encrypted. It is instantiated by the IP user within the custom device HDL code or by selecting the COTS IP function in a library" [2]. A Firm IP is a "COTS IP defined as a technology-dependent netlist. It is instantiated within the custom device netlist" [2]. A Hard IP is a "COTS IP defined as a physical layout (stream, polygon, GDSII format, etc.). Hard IP is instantiated by the IP user during the physical design layout stage; alternatively, Hard IP is embedded into the silicon of the FPGA/PLD by the FPGA provider/device manufacturer" [2]. Based on AMC 20-152A, a COTS IP can have Errata, just like COTS device. Errata are considered as reports of errors and corrections made by the supplier of the COTS element to inform the customer that the element does not fully comply with its specification. A COTS IP can also have configuration settings, just like Custom device. The definition of Configuration settings is not explicit in the certification baseline even if it is widely used. We consider Configuration settings as physical or logical parameters applied to establish the configuration and the behaviours of an element. For instance, AMC 20-193 gives the following examples for MCP: which cores are activated, the execution frequencies of the cores, the priorities and allocation of shared interconnect, etc.

In addition to all these concepts found in the certification baseline, we added one that seems relevant to our specific problem but overlooked in the standards because its certification is built in the overall certification of the device. We thought that the granularity at which it is located was necessary to rationale on our problem. This is the concept of "Custom Functional Block", i.e. a custom HDL level block in the design that performs a specific function. A Custom Functional Block can then be instantiated by the Custom Device Design and can instantiate other functional blocks or IPs. We also added concepts representing the objectives of each standards of the certification baseline and linked them in the ontology to the concepts they are associated to in the standards. They are colored in green in the ontology.

Note that we have two concepts in this ontology that are isolated from all others concepts with the exception of their inherited relationships: Custom IP and Integrated Technology Component. This is explained by the fact that even if these concepts seem relatively important to determine where and what to do to apply the certification baseline, they are overlooked in the standards and only mentioned once. They are represented in a different color in the ontology diagram.

## 4.2. Open-Hardware SiP Ontology

In parallel, we also review the main concepts that are structuring an Open-Hardware SiP. This ontology is represented in Figure 3. For the remainder of the description, we consider the following definitions for COTS element and

Custom element inspired by [2]. A COTS element is intended as an element developed by a commercial supplier for a wide range of customers (not restricted to airborne systems), whose design and configuration is controlled by the supplier or an industry specification. A Custom element is intended as an element developed by the applicant to answer a particular need. Most parts of the design and configuration are under the control of the applicant.

The key concepts of this ontology are SiP, Chiplet, Open-source Hardware IP and Open-Hardware. A SiP is a set of chiplets that can be combined on a substrate, or layers of substrate, within a single package. A SiP has also a DAL and can have Configuration settings and Errata. A DAL is intended in this ontology as a DAL in the sense of the certification baseline, i.e. the level of rigor of development assurance tasks performed on the element. Configuration settings have the same definition as in the Certification Baseline ontology, i.e. physical or logical parameters applied to establish the configuration and the behaviours of an element. Errata are defined as a generalized version of the Errata defined in the Certification Baseline ontology. Here, Errata represent reports of errors and corrections made by the creator or provider of the element to inform the user that the element does not fully comply with its specification.

From there, a SiP can be COTS or custom. In our ontology, we focus on the case of Custom SiP. Following the definition of a SiP, a Custom SiP is composed of chiplets and a substrate. A chiplet is an unpackaged semi-conductor integrated circuit that performs specific functions (e.g., processing, memory management, I/O operations) and possesses at least a means to connect to another chiplet. It can be COTS or custom. The substrate represents the semiconductor material that supports and connects integrated circuits (ICs) between themselves but also to the external environment. Depending on the technology, it can be an interposer. It can also be COTS or custom, and be composed of other layers of substrate or interposer. In addition, we consider that a custom SiP complies with a template, also called chassis or architectural model. A SiP template is a model or template representing the conceptual view of the SiP architecture. It encompasses the description of a software API for the configuration. It could also be COTS or custom. Having a COTS substrate or COTS SiP Template could seem arguable. But for the sake of completeness, we did not want to close any doors and miss any specificities that could be significant in the certification.

The concept of Chiplet is central in the ontology. A Chiplet has a DAL and can have Configuration settings and Errata, in the same way as a SiP. A Chiplet also has a Hardware Type that represents the type of the integrated circuit. For instance, it could be a single-CPU, a multi-CPU, a PLD, a memory, an I/O, etc. To go further, a Chiplet is organised by a Chiplet Design, also called a Chiplet Architecture, which is the description of the structure of the chiplet in terms of connections, interfaces and functional blocks. This description is typically written in a formalized language, such as VHDL, System Verilog, etc. In this context, we considered that a Chiplet Design instantiates Functional Blocks. A Functional Block is defined here as a RTL level element in the design that performs a specific function. We consider there are four kinds of possible Functional Block.
<figure><img src="image_6.png" /><figcaption>Figure 3: Open-Hardware SiP Ontology</figcaption></figure>

First, a Custom Functional Block is a Functional Block that is created and managed by the designer of the chiplet. In an Open-Hardware context, we could imagine that a Custom Functional Block can originate from Open-Hardware but has been modified to fit the specificities of the Chiplet designer. Open-Hardware is intended in this ontology as physical artefacts of technologies designed and provided by the Open-Design community. Moreover, we consider that a Custom Functional Block can be composed of other Functional Blocks. Next, we can consider a Functional Block as an IP that can be COTS or Custom. In this case, we consider a COTS IP as a Functional Block subject to an intellectual property owned by the commercial provider of the IP. A Custom IP is considered as a Functional Block subject to an intellectual property owned by the designer of the chiplet, and that is available for different projects in a library owned

by the designer. Finally, a Functional Block can also be an Open-source Hardware IP. In this ontology, an Open-Source Hardware IP is defined as a Functional Block taken directly from the Open-Hardware as it is, i.e. its design has not been altered. In addition, we consider that every Functional Block can have Configuration settings and Microcode. Microcode is intended as in the certification baseline ontology, i.e. a hardware-level set of instructions, but extended to custom elements.

# 5. POSITIONING OF THE OPEN-HARDWARE SIP RELATIVE TO THE CURRENT CERTIFICATION BASELINE

## 5.1. Ontology alignment analysis and results

As explained in Section 3.2, to position the Open-Hardware SiP in relation of the current certification, we use the
ontologies defined in Figure 2 and Figure 3 to perform an
ontology alignment, or matching, based on two criteria: first,
terminological similarity and then structural similarity.

The first observations show that the concepts of DAL and Configuration settings have an apparent correspondence based on terminological similarity: their definitions in the Open-Hardware SiP ontology are borrowed from the certification domain. The definition of the concept of Microcode is also borrowed from the certification domain, but extended to Custom elements as well. Therefore, the concept of Microcode from the Open-Hardware SiP domain encompasses the concept of Microcode coming from the certification. The matching of the concept of Errata is also peculiar. Even if this term is present in both ontologies, the definition is more general in the Open-Hardware SiP domain than in the Certification one. Indeed, in the Open-Hardware SiP domain, the definition seems to encompass the notion of problem report, OPR and errata from the certification domain without distinction between custom or COTS, while in the certification domain the definition is only dedicated to COTS elements. In this case and based on the evaluation of terminological similarity, we can deduce that there is not a one-to-one mapping for this concept, but rather a coverage of two concepts (namely OPR and Errata) from the certification domain.

Regarding the key concepts of the Open-Hardware SiP
ontology, the alignment is less trivial. Let us start with the
concept of Chiplet on which the SiP relies on. For instance,
one could think that a Chiplet could be considered as a Hard
IP. However, there is a terminological incompatibility as a
Chiplet represents an integrated circuit, i.e. a physical chip,
while the Hard IP represents a physical layout in a code
format. In terms of terminological similarity, the closest
concept to Chiplet in the Certification Baseline ontology is
the concept of Device. Even if this concept does not have a
proper definition but is rather defined as either a COTS
device or a Custom device, their definitions can give us clues
to reach this conclusion. For instance, the definition of
Custom device refers to FPGA, PLD and ASIC which are all
integrated circuits while the definition of COTS device
directly refers to integrated circuits. This suggests that an
integrated circuit, by extension a Chiplet, can be considered
as a Device from a certification point of view. However, this
terminological evaluation is not enough to be confident in
the similarity. By carrying out a structural evaluation, we can
observe that considering a Chiplet as a Device covers many
structural properties expressed in the Open-Hardware SiP
domain. First, both Chiplet and Device can be COTS or
Custom. Second, each of them has a DAL and possibly
Configuration settings, both concepts having been evaluated
as matching between the two ontologies. Third, a Chiplet is
linked to Errata in the Open-Hardware Ontology while a
Device is linked to an OPR and Errata in the certification
baseline ontology. As these concepts have been deemed
similar, the structural correspondence is also achieved for
this relationship. Fourth, the concept of Chiplet is linked to a
Hardware Type that can be a multi-CPU. Likewise, the
concept of Device has a similar link to the specific type of
MCP. Finally, each concept has a relationship to a design:
Custom Device Design and Chiplet Design. From a
terminological point of view, these two concepts are similar.
Moreover, their structural evaluation show "instantiates"

relationships to Functional Block and IP in both cases, which
reinforces our belief. To sum up, the similarity between
Device and Chiplet can be foreseen by terminological
evaluation and confirmed by structural evaluation.

Concerning the concept of Functional Block from the Open-Hardware SiP domain, it does not seem to have an homonym in the certification baseline domain. However, its subtypes Custom Functional Block, COTS IP and Custom IP have all namesakes in the Certification Ontology and their correspondences are confirmed by terminological evaluation. In terms of structural evaluation, the similarity seems roughly consistent. However, the relationship between Custom Functional Block and Open-Hardware is something new and missing in the Certification Baseline ontology. Same observation for the concept of Open-source Hardware IP: following evaluations, there is not direct correspondence with a concept from the certification baseline and an alternative needs to be considered for its positioning.

The key concept of SiP, SiP Template and Substrate are also
challenging. There is no explicit correspondence in terms of
terminological similarity and the structural evaluation does
not give additional clue. In the case of the SiP, and if a
Chiplet is considered as a Device, a structural evaluation
could lead to think that SiP could match with a CBA. Yet,
the structural similarity is weak and so is the terminological
similarity regarding their definitions. Alternatives need to be
chosen for the positioning of these key concepts.

## 5.2. Positioning challenges

The absence of correspondences of concepts of the Open-Hardware SiP ontology with concepts of the Certification Baseline ontology suggests that these concepts do not have an explicit coverage in the current certification baseline. Therefore, they illustrate some of the main challenges posed by the Open-Hardware SiP for the certification. In this scope, alternatives can be recommended for each of them.

In the case of Open-source Hardware IP, the main issue is the confidence in the retrieved IP. For instance, in the case of the use of open-source code *off-the-shelf* in a certification context, there is no means to justify the used development process. So, the user would probably need to go through the whole certification process without taking advantage of the off-the-shelf solution. Using an Open-source Hardware IP may bring similar concerns, as it is unlikely to have a support or a point of contact to retrieve key information. If we want to position it with an existing concept in the certification baseline, a preliminary suggestion would be to see it as a COTS IP, as it may cover regulations for *off-the-shelf* solutions from providers and possesses specific requirements in case key information for certification cannot be retrieved. In the case of Custom Functional Block coming from Open-Hardware, a similar concern on how to deal with the part retrieved from Open-Hardware can be raised but this topic still need further discussions and analysis.

The concept of SiP is the focal point of the exercise. We already discussed that it could be seen as a CBA but the similarity evaluation was relatively weak. If we take the analysis further, an adequate matching could be the Integrated Technology Component. It allows covering all the basic requirements for an AEH while emphasizing the
importance of the integration of the elements composing the SiP. Yet, no definition is given for the concept in the standard and no specific objectives are dedicated to it. Further discussions on this topic are necessary to understand if additional regulation requirements would be needed, especially for the integration aspect.

Substrate/Interposer has no correspondence either in the Certification Baseline ontology. In the scope of certification and if we consider the SiP as an Integrated technology component, the concerns about the substrate may be covered by additional regulation requirements that should cover the integration aspect of the SiP. An alternative could be to explore the similarity with the concept of Printed Circuit barely mentioned in the certification baseline, but further discussions are needed.

Finally, the SiP Template has also no existing correspondence in the certification baseline. One possible explanation is that this concept is associated to the specific modular and reuse aspects of the SiP (for instance, one could reuse the same SiP template across different products in a product line and seek to draw credits from past certification). Yet, the reuse aspect in the certification is not taken into account for the moment in the ontology. This concept is still kept in the ontology as it points out an important aspect of the SiP and may pave the way to addressing the question of reuse in the certification.

# 6. RELATED WORK

## 6.1. Other studies on certification challenges for modern hardware

Other works have studied the challenges posed by new hardware technologies for the certification. For instance, the authors of [13] and [14] describe an analysis of CAST-32A and its difficulties for the MCP of that period, before it becomes AMC 20-193. In [14], the authors analyse specific concepts of CAST-32A related to robust partitioning in order to highlight the difficulties behind it and to provide insights for the implementation of this type of partitioning. In the same vein as us, this work relates definitions from the standard to definitions from the MCP domain. However, our purpose is different and no ontology of all the identified concepts is provided. In [13], the authors review the difficulties behind applying the CAST-32A to the COTS multicore design from that period and evaluate these difficulties on a use case. While this work identifies and defines the key concepts behind the CAST-32A, it is more oriented on the identification of the challenges posed by the application of the standard on a particular use case than evaluating the challenges posed by the emergence of a new technology to an existing certification baseline.

The work carried out in the PHYLOG<fnref n="1" /> project on the certifiability of multi-core architectures is also relevant to the topic. Their recent works study the applicability of standards to modern hardware. In [15], the authors study how the AMC 20-152A for AEH applies to hybrid platforms, i.e. platform embedding cores and accelerators in the same package. The hybrid platforms are positioned in regards to the concepts of the AMC-20-152A to understand the

objectives to apply. The positioning is carried out directly through the review of the standard. In comparison, our approach is more systematic. In [16], the authors study the DO-326B/ED-202B [17] and DO-356B/ED-203B [18] standards about cyber-security and evaluate its applicability for an MCP platform. The evaluation is carried out by a review of the contents of the standards and an illustration on a use case. Here again, our approach is more systematic.

Outside of the hardware domain, recent works have also evaluated the challenges of the certification for other emerging technologies. For instance, [19] identifies the certification challenges for machine learning certification for embedded systems. The identification is carried out by a workgroup composed of experts from different domains. In this scope, the authors propose a combination of various analyses to systematically identify the challenges, going from the analysis of a classical ML workflow to the definition of High Level Properties (HLP), i.e. properties required to ensure the confidence in the system. The HLP are then related to engineering choices during ML development in order to evaluate the consequences of the latter. Even if our approaches differ, both works tend to establish repeatable approaches guided by experts' consensus. The definition and analysis of HLP in our scope could be an interesting avenue to explore in order to strengthen our approach. To go further, the ontologies we defined could also be coupled to the definition of assurance cases for HLP introduced in [19]. For instance in [20], the authors define assurance cases to build the argumentation for the reachability of HLP for ML-based systems verification. The properties and terms used to define these assurance cases are provided by a glossary composed of the concepts of the domain, similarly as what our ontologies could provide. This could create a bridge between the definition and analysis of HLP and our ontology-driven approach.

Apart from these works that focus on identifying the certification challenges posed by new technologies or the application of the standards, we are not aware of any works that use an ontology-driven approach to position a new technology with the certification baseline, or that specifically address the Open-Hardware SiP in this context.

## 6.2. Ongoing initiatives

An initiative by the bodies in charge of defining and publishing the certification standards is underway in order to update the DO-254/ED-80, which has been released 25 years ago. Over the course of these two decades, the certification authorities have recognized this standard as an acceptable means of compliance for AEH certification and its usage has been widespread among numerous projects. However, the field of AEH has significantly evolved since its first release and, even if some evolutions have been considered in AMC 20-152A and AMC 20-193, there is a need to update DO-254/ED-80 with guidance for the most recent technologies of the field (e.g. multi-core processors). To do so, the working groups WG-128² from EUROCAE and SC-243³ from RTCA have been tasked to update, to clarify or to extend the DO-254/ED-80 with a new version expected for 2028. Yet, no

<footnote n="1">¹ https://w3.onera.fr/phylog/</footnote>

<footnote n="2">² https://www.eurocae.net/working-group/wg-128/</footnote>

<footnote n="3">³ https://www.rtca.org/sc-243/</footnote>
public information is currently available on the results and
no information is provided regarding the consideration of
Open-Hardware SiP in the discussions.

7. CONCLUSION

The work presented in this paper investigates the adequacy
of the current certification baseline in the face of the changes
brought by Open-Hardware SiPs to airborne embedded
processing devices. The suggested approach to achieve this
objective is based on the definition of an ontology for each
domain and the search of matching through ontology
alignment. In this way, a positioning of the Open-Hardware
SiPs with regard to the certification baseline is obtained in
order to identify the part of the existing baseline that could
possibly cover the key concepts brought by these new
technologies, and also the gaps. These gaps are then
discussed to identify potential challenges for the
certification.

The initial results are promising and show the positioning of
a key concept of the Open-Hardware SiP domain, namely the
Chiplet, with an existing concept from the certification
baseline. The results also highlight the challenging concepts
for the certification that could not be matched. Overall, the
ontologies help rationalizing matching alternatives. The
suggested approach also includes a second step that is not
presented in this paper but will be covered in future work. It
consists in the analysis of the coverage of the certification
objectives and activities related to the concepts of the
certification baseline matched with the concepts of the Open-
Hardware SiPs in order to get a more accurate assessment of
the adequacy.

In addition to completing this second stage, future works will
focus on various avenues. One of the most important is
taking into account concepts related to the reuse of
components previously certified and integrating them into
the ontologies. This topic is essential as it allows taking
advantage of the modularity of Open-Hardware SiPs in order
to enable the development of family of SiPs across aircraft
and equipment programs, using a product line approach. The
concepts of Previously Developed Hardware (PDH) and
Certification Credit from the Certification Baseline, and the
concept of the SiP template could be a good starting point. In
parallel, an extension of both ontologies is expected in order
to consider more specificities of each domain and more
standards. Either way, we do not expect any changes in the
matching concepts already identified, as the key concepts of
both domains were already included. However, it may have
an impact on the second step of the approach. Another
activity will be to discuss the ontologies with EASA,
especially the one about the certification baseline, in order to
validate our modelling. Indeed, it may exist a potential bias
in the definition of the ontologies that have been introduced
by using the same group of experts to define both ontologies.
An independent and expert opinion from an agency such as
EASA could mitigate this bias. A more complex activity
would be to take advantage of the OWL formal foundation of
the ontologies to try to automate or ease the ontology
alignment by having a computer-aided evaluation. While it
may be straightforward for structural evaluation, it could be
more complex for the terminological evaluation. The
creation of generic tags for each concept, such as their nature

(e.g. physical, conceptual, etc.) could ease this evaluation by
providing an initial set of results from computer-based
analysis that could be refined by experts' reviews. Finally, if
the success of the approach is confirmed after the
performance of the second step, we could think about
generalizing the approach for supporting the evaluation of
the adequacy of certification baselines with newly introduced
technologies.

ACKNOWLEDGMENT

The work presented in this paper is part of the OHPERA
project partially funded by the Directorate General of Civil
Aviation (DGAC).

REFERENCES

[1] RTCA and EUROCAE, DO-254 / ED-80 Design Assurance Guidance for Airborne Electronic Hardware, 2000.

[2] EASA, AMC (Acceptable Means of Compliance) 20-152A Development Assurance for Airborne Electronic Hardware (AEH), 2020.

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

[4] RTCA and EUROCAE, DO-160G / ED-14G Environmental Conditions and Test Procedures for Airborne Equipment, 2010.

[5] EASA, AMC (Acceptable Means of Compliance) 20-189 The Management of Open Problem Reports (OPRs), 2020.

[6] RTCA and EUROCAE, DO-178C / ED-12C Software Considerations in Airborne Systems and Equipment Certification, 2020.

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

[8] N. Guarino, D. Oberle and S. Staab, "What is an ontology?," in *Staab, S., Studer, R. (eds) Handbook on Ontologies*, Berlin, International Handbooks on Information Systems. Springer, 2009.

[9] R. Studer, R. V. Benjamins and D. Fensel, "Knowledge Engineering: Principles and Methods," *Data & Knowledge Engineering*, vol. 25, no. 1-2, 1998.

[10] F. Ardjani, D. Bouchiha and M. Malki, "Ontology-alignment techniques: survey and analysis," *International Journal of Modern Education and Computer Science*, vol. 7, no. 11, p. 67, 2015.

[11] G. Antoniou and F. Van Harmelen, "Web Ontology Language: OWL," in *Staab, S., Studer, R. (eds) Handbook on Ontologies*, Berlin, International Handbooks on Information Systems. Springer, 2009.

[12] SAE and EUROCAE, ARP4754B / ED-79B Guidelines for Development of Civil Aircraft and Systems, 2023.

[13] I. Agirre, J. Abella, M. Azkarate-Askasua and F. J.
Cazorla, "On the tailoring of CAST-32A certification guidance to real COTS multicore architectures," in *12th IEEE International Symposium on Industrial Embedded Systems (SIES)*, Toulouse, 2017.

[14] F. J. Cazorla, J. Abella and E. Mezzetti, "Dissecting Robust Resource Partitioning, Robust Time Partitioning, and Robust Partitioning in CAST-32A," SAE Technical Paper 2021-01-5101, 2021.

[15] B. Lesage, F. Boniol, K. Delmas, A. Gauffriau, A. Mascarenas Gonzalez and C. Pagetti, "Towards the Certification of Hybrid Architectures: Analysing Interference on Hardware Accelerators through PML," in *12th European Congress on Embedded Real Time Software and Systems (ERTS)*, Toulouse, 2024.

[16] A. Fernandes Pires, J. Brunel and K. Delmas, "Considering the Aeronautics Cyber-Security Standards for Multi-Core Platforms," in *12th European Congress on Embedded Real Time Software and Systems (ERTS)*, Toulouse, 2024.

[17] RTCA and EUROCAE, *DO-326B / ED-202B Airworthiness Security Process Specification*, 2024.

[18] RTCA and EUROCAE, *DO-356B / ED-203B Airworthiness Security Methods and Considerations*, 2024.

[19] E. Jenn, A. Albore, F. Mamalet, G. Flandin, C. Gabreau, H. Delseny, A. Gauffriau, H. Bonnin, L. Alecu, J. Pirard, B. Lefevre, J.-M. Gabriel, C. Cappi and L. Gardès, "Identifying challenges to the certification of machine learning for safety critical systems," in *12th European Congress on Embedded Real Time Software and Systems (ERTS)*, Toulouse, 2024.

[20] V. Mussot, E. Jenn, F. Chenevier, R. Conejo Laguna, Y. Id Messaoud, J.-L. Farges, A. Fernandes Pires, F. Latombe and S. Creff, "Assurance Cases to face the complexity of ML-based systems verification," in *12th European Congress on Embedded Real Time Software and Systems (ERTS)*, Toulouse, 2024.