Semantic-based systems engineering for digitalization of space mission design

The engineering of space systems is a collaborative, iterative process that integrates various domain-specific viewpoints to represent the final system. To ensure consistency across these viewpoints, the European Space Agency (ESA) employs Model-Based System Engineering (MBSE) and Semantic-Based System Engineering (SBSE) methodologies together to improve digital continuity and interoperability across collaborative space system developments. One significant application of semantic engineering in SE is the ESA MBSE Methodology. The ESA MBSE Methodology provides a standardized approach aligned with the European Cooperation for Space Standardization (ECSS), promotes interoperability across MBSE methodologies and tools, and overcomes integration challenges. ESA MBSE Methodology is the input for the Overall Semantic Modeling for Space System Engineering (OSMoSE) which leverages interoperability in the space community. Case studies, such as the EagleEye Earth Observation mission, demonstrate practical applications, highlighting how semantic models enhance efficiency in complex space systems. This paper discusses the importance of semantics and data management in SE and presents a practical solution derived from the ESA MBSE Methodology.

1 Introduction

In alignment with its Agenda 2025, ESA aims to fully digitalize its project management processes, making digital twins integral to their operations. This initiative involves leveraging MBSE for engineering purposes, to achieve seamless digital continuity with industrial partners. Central to this agenda is the Digital Spacecraft (DtSC) concept, designed to drive the digital transformation of collaborative space system development and operations throughout the project lifecycle. The core aspect of DtSC is the comprehensive integration of data into a unified, cohesive framework that encompasses all facets of the space domain (Terraillon, 2022).

The engineering of space systems is a collaborative iterative process in which various domain-specific viewpoints are integrated to represent the final system. Accordingly, SE is evolving beyond mere data integration toward semantic integration (McDermott et al., 2020), in this paper called Semantic-Based SE (SBSE). SBSE serves to elucidate the essence and configuration of engineered systems, assisting domain engineers in understanding system complexities within their socio-technical environments (Yang et al., 2019). This shift underscores the significance of semantic interoperability in SE, ensuring clear and consistent interpretation of exchanged data among diverse stakeholders (Knizhnik et al., 2020; Nagowah et al., 2018). Compared to existing MBSE approaches, semantic-based ones offer a wider design space exploration and enhanced capabilities for domain knowledge reuse (Arista et al., 2023). By leveraging ontologies, semantic interoperability among diverse systems becomes more attainable, facilitating the integration of information derived from disparate modeling tools. Furthermore, employing formal, ontology-based information representation can mitigate the issue of system elements lacking awareness of each other’s states (INCOSE, 2021).

The relationship between MBSE and SBSE is inherently close within ESA. The interdependency between semantics and standardization is crucial for achieving interoperability in ESA’s digitalization initiatives (Valera and Wijnands, 2022). The European space community ensures standardization through the ECSS which provides a comprehensive set of standards, handbooks, and technical memoranda, creating a unified and user-friendly reference system. ECSS fosters cooperation among organizations to achieve international consensus, enabling global interoperability¹. As a result, ensuring the compatibility of ECSS standards across various domains with both current and future digitalization efforts is of great importance. A key feature of ECSS standards is that requirements are defined in terms of what must be accomplished rather than prescribing how the work should be organized and performed. This approach allows for flexibility in applying existing organizational structures and methods and evolving them without rewriting the standards. However, this causes ECSS standards to be often semantically ambiguous and require human interpretation. Therefore, extracting, reusing, and analyzing the semantics within ECSS is central to digitalization, ensuring a common vocabulary and shared understanding of processes, activities, and work products. Several initiatives within the ESA adopt this approach to extract ECSS semantics as a prerequisite for digitalization projects. These efforts illustrate the commitment to integrating semantic representation and standardization in digitalization initiatives, ensuring successful and interoperable space missions (Vorobiev et al., 2022).

ESA is committed to enhancing collaboration between internal and external stakeholders through the implementation of advanced systems engineering support mechanisms. This includes developing methodologies such as the ESA MBSE Methodology and offering comprehensive training programs to ensure proficient application of these approaches and associated toolsets. The ESA MBSE Methodology aims to support the Agency’s SE processes. It offers flexibility to tailor processes to each mission’s specific needs, aligning with ECSS standards and supplemented by ESA-internal processes. It is independent of major European industrial actors to ensure fair competitiveness; provides a comprehensive set of processes, methods, and tools; is scalable and extensible with decisions documented for future reference; and is based on international standards such as Object Modeling Group (OMG) Systems Modeling Language (SysML). These additions are beneficial for other space organizations as well, making the methodology applicable to any organization complying with ECSS standards in systems engineering.

The ESA MBSE Methodology has been presented in different events (Whitehouse et al., 2022; Gonzalez Fernandez et al., 2024). This paper aims to present it through a semantic lens. Our focus here is not presenting the ESA MBSE Methodology itself, but the semantic model empowering its interoperability in a Semantic-Based SE approach. In doing so, Section 2 is dedicated to the literature review and related works. Section 3 presented a review of Space System Semantic Modeling at ESA. Section 4 explains the semantic model behind the ESA MBSE Methodology. Section 5 presents the mission design from the EagleEye Earth Observation mission. Finally, Section 6 draws discussion, and future work.

2 Related work

MBSE, using SysML, is becoming the primary method in aerospace for developing complex systems. For comprehensive systems engineering, especially where interdisciplinary communication and standardized modeling are essential, SysML is considered the most suitable choice. It enhances project development by ensuring consistent system requirements and architecture communication, serving as a central “single truth” for interdisciplinary teams. Customizing UML with Stereotypes is a well-accepted approach in the Integrated Services architectural view (Gorski, 2023). Although not strictly an ontology, SysML is a widely used modeling language based on UML that supports the specification, analysis, design, and verification of complex systems (Pierce et al., 2023).

Recognizing the longstanding need for a standardized SysML profile to address safety and reliability aspects, NASA promotes SysML models to integrate early safety requirements and analysis effectively. This includes synthesizing crucial reliability models such as Reliability Block Diagrams, Failure Modes and Effects Analysis (FMEA), and Fault Tree Analysis (FTA). The initiative aims to standardize MBSE practices agency-wide, fostering user-friendly viewpoints for non-expert modelers and directly embedding safety requirements into launch models. (Biggs et al., 2018; Evans et al., 2020). Model-based safety and reliability (S&R) analysis, supported by SysML, is integral to MBSE (Hu et al., 2023). In a similar approach, GOPPRRE (Graph, Object, Point, Property, Role, Relationship, and Extension) is used in various semantic-driven SE. AIRBUS incorporates meta-metamodels for GOPPRRE with Extensions to facilitate model-based design and verification of assembly systems (Lu et al., 2022). This method includes defining an application ontology for generating semantic models, transforming these into simulation models, executing simulations for verification, and using results to optimize assembly processes (Zheng et al., 2024).

From an ontological point of view, the IOF (Industrial Ontologies Foundry)² categorizes ontologies into five kinds, arranged from the most general concepts at the top to the more application-oriented at the bottom: (Drobnjakovic et al., 2022; Polenghi et al., 2022):

1. Foundational ontologies, such as Basic Formal Ontology (BFO)³, Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE)⁴, PROTo ONtology (PROTON), General Formal Ontology (GFO), and Standard Upper Merged Ontology (SUMO).

2. Domain-independent reference ontologies, encompassing time, geospatial, or unit of measure ontologies;

3. Domain-specific reference ontologies, like those for maintenance or product domains;

4. Subdomain ontologies, focusing on specific areas such as prognostics or maintenance planning;

5. Application ontologies, tailored for specific applications like machine tools prognostics in manufacturing.

ESA faces significant constraints against using external ontologies due to several key factors:

• Standardization for Interoperability: ESA and the European space Industry are mandated to adhere to the ECSS as the authoritative reference across all space domains. This obligation necessitates that all vocabularies, definitions, and relationships used within ESA’s projects and collaborations are sourced from ECSS. Any deviation from ECSS standards could lead to compatibility issues and hinder interoperability within the space community.

• Diverse SE Methodologies and Tools: ESA collaborates with a wide range of space actors, each employing their own distinct SE methodologies and tools. Achieving uniformity across these varied approaches is impractical and counterproductive. Instead, adopting an interoperable ontology based on ECSS allows ESA to maintain consistency while accommodating the diverse practices of its collaborators.

In summary, ESA’s commitment to ECSS as the foundational standard for space-related ontologies ensures interoperability, accommodates diverse methodologies, and maintains clarity through consistent terminology and definitions. ESA is advancing towards adopting the ESA MBSE Methodology for the digitalization of space mission design, leveraging core Systems Engineering (SE) principles. This approach is based on two key principles: the ECSS-based commitment provides a standardized approach to space system development, ensuring interoperability and consistency across projects and teams, and reducing miscommunication and errors. The SysML-based methodology offers a versatile modeling language that supports visualization, specification, analysis, and design of complex systems, enabling detailed and accurate models of space missions, and improving collaboration, decision-making, and problem-solving. ESA MBSE Methodology informs its perspective in the OSMoSE initiative, which aims to create an open, standardized reference data model for space engineering. By contributing to OSMoSE, conducted in collaboration with the broader space community, ESA MBSE Methodology helps shape the future of space mission design, promoting a unified approach that benefits all participants.

3 ESA Space System Semantic Modeling

OSMoSE at ESA enhances stakeholder information and knowledge exchange by capturing relevant semantics and ensuring optimal software design. Its primary goal is to enable efficient semantic interoperability among model-based infrastructures. OSMoSE introduces a top-level ontology called for Space System Ontology (SSO), considering each actor’s distinct roles and domain responsibilities. SSO uses ontology-based methods to extract SE-related semantics from key ECSS documents and various SE methodologies and tools used by stakeholders. Some of the well-known MBSE methodologies and tools mapped to SSO include MOFLT SECAM, ARCADIA Capella, ESA MBSE Methodology and other MBSE methodologies utilized by major space stakeholders involved in OSMoSE. These MBSE methodologies and tools are semantically modeled as ontologies and mapped to SSO, allowing local MBSE implementations to use their own adapters to communicate with the SSO. This integration enables them to be part of an interoperable MBSE eco-system in space community (Figure 1).

Figure 1

Figure 1. SSO MBSE for semantic interoperability between MBSE methods and tools.

Referring to ECSS-E-TM-10-23A (Space System Data Repository), information modeling within the OSMoSE initiative is organized into three layers: (Figure 2):⁵

• Conceptual Model: It defines meaningful concepts within a bounded domain, the Universe of Discourses (UoDs), using Object Types, Value Types, and Constrained Fact Types to express the “What” in engineering domains. Since the applied ontology tool is self-expressive, no higher-level meta-model or language is needed. It allows for modeling the entire “What” or subsets, facilitating stakeholder-specific mappings.

• Logical Models: These hierarchical or relational models represent how information is structured to meet system performance requirements during architecture engineering. They can transform the Conceptual Model into various hierarchies and relational tables while maintaining the same concepts and constraints.

• Physical Models: These models, implemented in corresponding languages and tools, translate architectural models into data definition languages. This process produces the data repositories required by the information system.

Figure 2

Figure 2. OSMoSE from conceptual to Logical and Physical data.

For the Conceptual layer, OSMoSE has chosen NORMA ORM (Object-Role Modeling) as the best technical solution to develop the SSO. ORM is a comprehensive approach for designing and querying database models at the conceptual level⁶. Thanks to automated verbalization in ORM, domain semantics can be easily extracted, modeled in terms of controlled natural language, and made accessible to non-technical users (Keet, 2023). This enhances semantic stability, making it more adaptable to changing business environments, facilitating communication between stakeholders, and supporting the modeling of large-scale industrial applications (Sportelli, 2016).

The main elements of ORM metamodel are as follows: (Figure 3):

• Entity Type: Tangible Objects (e.g., person, room) or abstract (e.g., access level)

• Fact Type: The role that Entity plays where the relationship may be unary (e.g., Person smokes), binary (e.g., Person was born on Date), ternary (e.g., Customer bought Product on Date), or longer.

• Value Type: A lexical object type (e.g., a character string or number)

• Constraints: To restrict the possible or permitted populations of the fact types

Figure 3

Figure 3. ORM metamodel elements.

One of the standout features of ORM is its ability to automatically generate a relational model from a conceptual ORM model, with NORMA providing tools for graphical expression of conceptual schemas. Compared to OWL, ORM boasts high expressive capabilities and implements the node-link paradigm, supported by a simplified meta-model (Litovkin et al., 2021). Since ORM is expressed in ORM itself, there is no need for any higher-level meta-model or language. In addition to modeling the complete ‘What,’ ORM allows for the selection of any subset of interests and mappings. Consequently, stakeholders with different interests can use a subset of the SSO, facilitating information mapping between them (Figure 4).

Figure 4

Figure 4. ESA OSMoSE ontology layers.

4 ESA MBSE methodology ontology

At ESA, a variety of MBSE methodologies and tools are utilized based on project or space mission requirements. In recent years, there were some efforts to customize the SysML for space projects, resulting in the “ESA SysML Profile”. This profile was implemented in SysML-based tools like Enterprise Architect and Cameo Systems Modeler, termed the “ESA SysML Toolbox”, facilitating MBSE implementation (Figure 5).

Figure 5

Figure 5. ESA SysML profile/toolbox.

However, a standardized methodology was lacking. A unified methodology for ESA MBSE is imperative to ensure consistency, reusability, and correctness. Additionally, shortcomings in the ESA SysML Profile highlight the need for its evolution to enhance reusability across projects. The missing components of the current MBSE approach and the need for an improved and unified ESA MBSE solution have ultimately led us to broaden our thinking for the next version of the ESA SysML Profile/Toolbox called ESA MBSE Methodology, which is a pragmatic MBSE solution, tailored to the needs of ESA Space Projects. This Methodology has been published under ESA Community License at https://essr.esa.int/project/esa-sysml-solution.

The process of creation of the ESA MBSE Methodology is envisioned as a “pipeline,” where space domain standards, documents, and processes are taken as inputs. This pipeline rigorously transforms these inputs into a cohesive meta-model and methodology as outputs. This structured approach ensures that all relevant standards and practices are systematically integrated, resulting in a comprehensive framework that aligns with the specific needs and requirements of the space domain (Figure 6).

Figure 6

Figure 6. Pipeline Definition inputs.

The creation process as a “pipeline” produces the main components of the ESA MBSE Methodology to allow answering the following needs:

• Ensuring “ECSS compliance” from project initiation is essential. This involves clearly defining each concept for consistency and adherence to standards, with ECSS-E-ST-10 (SE general requirements), serving as the benchmark. Since these standards require interpretation and lack clear semantics, it is vital to extract and process embedded semantics from these documents. This approach integrates digitalization and model-based practices without conflicting with core Systems Engineering processes.

• Expanding the modeling of SE concepts, or “ontology-lite,” simplifies remapping to various target languages. Outputs from OSMoSE enhance ECSS’s role within the SE ontology framework. Compatibility with languages like SysML V1, SysML V2, and Capella is essential. The ESA MBSE Methodology, rooted in SysML V1, aligns with its metamodel standards. SysML, standardized by the OMG using the Meta-Object Facility (MOF), serves as a meta-metamodel, defining essential constructs for creating other metamodels. MOF incorporates metamodeling constructs similar to those in SysML’s framework (Weilkiens et al., 2022). This alignment ensures effective use of SysML V1 within the ESA MBSE Methodology, supporting robust modeling practices and enhancing interoperability in systems engineering.

• A rigorous definition process is critical for future extensibility. Standardizing all inputs and outputs maintains clarity and facilitates integration across diverse applications and methodologies.

To achieve these objectives, ESA MBSE Methodology is composed of (Figure 7):

• an MBSE methodology and conceptual data model specification derived from ECSS.

• a target language mapping to SysML V1.

• a customized tool implementation in the system modeling tool Dassault Systèmes Cameo Systems Modeler (CSM) and Sparx Enterprise Architect (EA).

• a demonstration model (implemented in CSM and EA).

Figure 7

Figure 7. ESA MBSE Methodology is composition mapping.

During this phase, extracted semantics are formalized and mapped to the higher-level ontology provided by OSMoSE SSO to ensure cross-domain interoperability throughout the digital engineering lifecycle. This process involves justifying specific architectural and conceptual decisions, meticulously documented in the mapping report. Integration of expert knowledge is critical to ensuring clear and precise semantic representation. For instance, the concept of “interface” in ECSS is enriched to align with ESA’s SE requirements. ECSS-E-ST-10 lacks detailed concepts like Interface Nature or Interface End crucial for SE, and distinguishes between “internal and external interfaces” within the System of Interest (SoI) and external systems. Instead of categorizing interfaces as internal or external, the approach defines that an External System includes Interface End, encompassing L0Product representing the SOI, as documented in the mapping report.

ESA MBSE Solution comprises four primary layers along with the Requirements and Transversal layers which are the base of the core data model made of six interconnected ontologies (Figure 8):

• Mission specification (red color): Consisting of Mission objectives diagram (based on a SysML use case diagram), Mission context (based on a SysML block definition diagram), Mission phases and context states diagram (based on a SysML state machine diagram), Mission scenarios (based on a SysML activity or sequence diagram).

• SoI specification (orange color): Consisting of SoI capabilities diagram (based on a SysML use case diagram), SoI context (based on a SysML block definition diagram).

• Functional Design (green color): Consisting of Function tree (based on a SysML block definition diagram), Functional architecture (based on a SysML internal block diagram), Operational modes diagram (based on a SysML state machine diagram), Functional scenario (based on a SysML activity or sequence diagram).

• Physical Design (yellow color): Consisting of Product tree (based on a SysML block definition diagram), Physical architecture (based on a SysML internal block diagram), and Physical scenario (based on a SysML activity or sequence diagram).

• Transversal (grey color): Consisting of External systems diagram (based on a SysML block definition diagram), Exchange items diagram (based on a SysML block definition diagram).

• Requirements (purple color): Consisting of Specification tree (based on a SysML package diagram), and Requirements table (based on a standard Excel-like table).

Figure 8

Figure 8. ESA MBSE methodology ontologies.

For instance, the Requirement layer is semantically presented in ORM diagram consisting of User need, ESA Requirement, Specification and Justification (Figure 9):

Figure 9

Figure 9. Requirement ontology.

As the second example, the Functional design layer is detailed by four views which are semantically presented in one ORM diagram (Figure 10):

• Function tree view: graphical representation where the top-level function(s) is/are decomposed into lower-level functions.

• Functional architecture view: It shows the system functions and sub-functions, the flows or exchanges between them, and flows coming from/going towards the external systems.

• Operational Modes view: represents the operational modes of the system and the transitions between them.

• Functional scenario view: shows the sequence of flows between functions (dynamic view, in contrast to the static view shown in the functional architecture). The flows between the system functions and the external systems are also represented.

Figure 10

Figure 10. Functional Design ontology.

5 ESA MBSE methodology application for EagleEye mission functional design

The ESA MBSE Methodology is actively employed in several mission projects, such as Argonaut, Mars Sample Return-Earth Return Orbiter (MSR-ERO), GENESIS, Laser Interferometer Space Antenna (LISA), and Sentinel 3 Next-Generation Topography (S3NG-T) (Affentranger and Huesing, 2022; Gonzalez Fernandez et al., 2023). To illustrate the proposed approach within a space system context, we have chosen to simulate a demonstrated mission named EagleEye. EagleEye is an Earth Observation mission to provide measurement data of oceans, coastal areas, and larger lakes/rivers for monitoring purposes, and to support weather now-casting and forecasting (Figure 11).

Figure 11

Figure 11. EagleEye SoI.

The primary “mission objective” is to continuously acquire data from a Sun Synchronous Orbit and deliver it to the user community. The key measurement parameters of the mission are sea surface temperature, color for oceanic and coastal waters, and sea topography winds and waves for oceanic and coastal waters. This mission comprises the Space Segment as the SoI and various external systems (Ground Segment, Launcher Segment, Customer, and Environment). To fulfill the mission objective, EagleEye needs different capabilities. In this paper, we focus on the capability of maintaining solar array pointing which is presented as one of the system’s requirements (Figure 12).

Figure 12

Figure 12. Solar array deployment Requirement.

To illustrate the application of ESA MBSE ontology in a mission, the Functional Design layer (green color) has been chosen. In this case, the demonstrated function is ‘Deploy Solar Array’ (Figure 13). For optimal efficiency of the solar generator, it is necessary to maintain its plane facing the sun. This requires a deployment arm, and its related deployment mechanism, to maintain the proper angle between the rotation axis of the drive and the plane of the Solar Array. The baseline includes the deployment arm and the inclination of the panel concerning the rotation axis. Scientific observations are performed continuously after initialization and, therefore, the AOCS design and functioning should guarantee the pointing requirements during the entire orbit to reduce the period when scientific data are invalid.

Figure 13

Figure 13. Functional scenario.

In this paper, the solar array serves as the focal item, while the deployment process utilizes command and control data from the Ground Segment (requested interface) and provides control feedback (provided interface). From the SoI perspective (Space Segment), data on solar array rotation per day is provided, while from the external system perspective (Ground Segment), validation of solar array dynamics is presented. It is important to note that the perspectives presented for the SoI and external systems here do not encompass the entirety of each. Rather, they offer a specific viewpoint on the solar array deployment process, which is just one aspect among many within these systems (Figure 14).

Figure 14

Figure 14. Functional architecture.

This example demonstrates that each SoI has requirements that extend to multiple External Systems. Furthermore, it elucidates that the solar array encompasses a population of SoI, with the coating being a population of the External System. These delineations not only aid in modeling but also load the model with relevant semantics. Specifically, they ensure that semantics on each object and role are derived from the domain-specific population.

6 Discussion and future work

ESA is actively advancing its digitalization agenda through the adoption of the SBSE approach. Related to this initiative is the ESA MBSE Methodology, designed to standardize and enhance SE practices across ESA projects. Aligned with ECSS standards and the OSMoSE SSO, this approach facilitates interoperability through semantic modelling. The ESA MBSE methodology is currently operational in multiple ESA projects. Its objective is to furnish ESA and other European organizations with a robust MBSE methodology aligned with ECSS and ESA best practices, constraints, and lessons learned. Moreover, it provides practitioners with a guiding methodology and an implementation-ready solution for space mission projects. The application of the ESA MBSE Methodology, demonstrated in missions, underscores its pivotal role in ensuring a coherent and consistent representation of spacecraft systems throughout their entire engineering lifecycle.

Valuable insights have emerged from related completed and ongoing activities at ESA. In SE, establishing a ‘Common Language’ is essential beyond the creation of mere models. Ambiguous standards and insufficient contextualized knowledge pose significant challenges to digitalization and the effective application of semantic techniques. Addressing these issues requires a focus on interdependencies with standardization and knowledge management. The primary digital asset of the SE team is the semantic data structured as an ontology using a graph-based approach. A stable and comprehensive foundation, coupled with practical implementation and utilization in data/model exchange, proves more advantageous than striving for a ‘perfect’ semantic model initially. Leveraging established technology stacks that model transformation and software development simplifies further refinement and extension of the SSO. Creating ontologies remains a labor-intensive process heavily dependent on manual curation. To streamline this effort, an integrated approach where ontology development and AI (Artificial Intelligence) reinforce each other emerges as the optimal strategy to maximize SBSE benefits.

Standardizing ontologies to establish a common language supporting SE within the space domain presents a continuous imperative for future work. This standardization not only enhances interoperability but also fosters consistency and clarity across diverse engineering projects. Future efforts will focus on implementing a robust methodology and tool support framework for applying SysML within the ECSS context. Recognized for its pivotal role in digitalizing engineering workflows and advancing MBSE practices, SysML requires further tailoring to meet the specific needs of the space domain. Building upon the existing ESA MBSE Methodology, which includes profiles and prototype implementations in commercial tools, the next phase will prioritize standardization and closer integration with ECSS standards. The methodology development will refine elements identified in the MBSE best practices handbook, tailored and extended to meet ESA’s project requirements. This approach ensures a forward-looking solution that aligns with the evolving SysML v2 standard, ongoing ECSS developments and supported ESA MBSE tools. Expected outcomes include significant cost reduction through guided methodology adoption and standards enforcement via tool support, enhancing interoperability with non-SysML solutions and discipline-specific tools from the outset. Validation will occur through testing in a real ESA project. Although the rollout and practical adoption of this solution are not within the scope of this activity, the software will be accessible under an ESA Software Community License, supporting the implementation of MBSE practices across the space sector.

Data availability statement

Publicly available datasets were analyzed in this study. This data can be found here: https://essr.esa.int/project/esa-sysml-solution.

Author contributions

EM: Conceptualization, Investigation, Methodology, Software, Validation, Visualization, Writing–original draft, Writing–review and editing. AG: Conceptualization, Methodology, Software, Writing–original draft, Writing–review and editing. NF: Software, Methodology, Writing–review and editing. QW: Software, Methodology. NC: Validation, Writing–review and editing.

Funding

The author(s) declare that no financial support was received for the research, authorship, and/or publication of this article.

Conflict of interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

¹https://ecss.nl/

²https://oagi.org/pages/industrial-ontologies

³https://basic-formal-ontology.org/

⁴http://www.loa.istc.cnr.it/dolce/overview.html

⁵https://ecss.nl/hbstms/ecss-e-tm-10-23a-space-system-data-repository/

⁶http://www.orm.net/

References

Affentranger, L., and Huesing, J. (2022). A model based approach to budget management for the Earth Return Orbiter. Model Based Space Syst. Softw. Eng. (MBSE2022).

Google Scholar

Arista, R., Zheng, X., Lu, J., and Mas, F. (2023). An Ontology-based Engineering system to support aircraft manufacturing system design. J. Manuf. Syst. 68, 270–288. doi:10.1016/j.jmsy.2023.02.012

CrossRef Full Text | Google Scholar

Biggs, G., Juknevicius, T., Armonas, A., and Post, K. (2018). Integrating Safety and Reliability Analysis into MBSE: overview of the new proposed OMG standard. INCOSE Int. Symp. 28 (1), 1322–1336. doi:10.1002/j.2334-5837.2018.00551.x

CrossRef Full Text | Google Scholar

Drobnjakovic, M., Kulvatunyou, B., Ameri, F., Will, C., Smith, B., and Jones, A. (2022). The industrial ontologies Foundry (IOF) core ontology. Available at: http://ceur-ws.org.

Google Scholar

Evans, J. W., Cornford, S. L., Kotsifakis, D., Crumbley, T., and Feather, M. S. (2020). “Enabling assurance in the MBSE environment,” in Proceedings - annual reliability and maintainability symposium, 2020. doi:10.1109/RAMS48030.2020.9153727

CrossRef Full Text | Google Scholar

Gonzalez Fernandez, A., Maleki, E., Duvet, L., and Tarrade, M. (2023). “An MBSE approach for Argonaut,” in INCOSE EMEA workshop and systems engineering conference (WSEC) 2023.

Google Scholar

Gonzalez Fernandez, A., Maleki, E., Fischer, N., Honoré-Livermore, E., Christofi, N., and Verhoef, M. (2024). The European space agency MBSE methodology. INCOSE International Symposium (IS).

Google Scholar

Gorski, T. (2023). Integration flows modeling in the context of architectural views. IEEE Access 11, 35220–35231. doi:10.1109/ACCESS.2023.3265210

CrossRef Full Text | Google Scholar

Hu, Y. Q., Peng, Q., Ni, Q., Wu, X., and Ye, D. (2023). Event-based safety and reliability analysis integration in model-based space mission design. Reliab. Eng. and Syst. Saf. 229, 108866. doi:10.1016/j.ress.2022.108866

CrossRef Full Text | Google Scholar

INCOSE (2021). Systems engineering vision 2035: engineering solutions for a better world. Available at: https://www.incose.org/docs/default-source/se-vision/incose-se-vision-2035.pdf?sfvrsn=e32063c7_10.

Google Scholar

Keet, C. M. (2023). An analysis of positionalism’s roles in use. Front. Artif. Intell. Appl. 377, 77–91. doi:10.3233/FAIA231119

CrossRef Full Text | Google Scholar

Litovkin, D. V., Anikin, A. V., Sychev, O. A., and Petrova, T. (2021). ORM diagram as an intermediate model for OWL ontology engineering: protégé ORM plugin implementation. J. Phys. Conf. Ser. 1801 (1), 012009. doi:10.1088/1742-6596/1801/1/012009

CrossRef Full Text | Google Scholar

Lu, J., Ma, J., Zheng, X., Wang, G., Li, H., and Kiritsis, D. (2022). Design ontology supporting model-based systems engineering formalisms. IEEE Syst. J. 16 (4), 5465–5476. doi:10.1109/JSYST.2021.3106195

CrossRef Full Text | Google Scholar

McDermott, T., DeLaurentis, D., Beling, P., Blackburn, M., and Bone, M. (2020). AI4SE and SE4AI: a research roadmap. Insight 23(1), 8–14. doi:10.1002/inst.12278

CrossRef Full Text | Google Scholar

Nagowah, S. D., Ben Sta, H., and Gobin-Rahimbux, B. (2018). “An overview of semantic interoperability ontologies and frameworks for IoT,” in Proceedings - 2018 6th international conference on Enterprise systems, ES 2018, 82–89. doi:10.1109/ES.2018.00020

CrossRef Full Text | Google Scholar

Pierce, G. J., Heeren, J. D., and Hill, T. R. (2023). Orion SysML model, digital twin, and lessons learned for artemis I. INCOSE Int. Symp. 33 (1), 290–304. doi:10.1002/iis2.13022

CrossRef Full Text | Google Scholar

Polenghi, A., Roda, I., Macchi, M., Pozzetti, A., and Panetto, H. (2022). Knowledge reuse for ontology modelling in maintenance and industrial asset management. J. Industrial Inf. Integration 27, 100298. doi:10.1016/j.jii.2021.100298

CrossRef Full Text | Google Scholar

Sportelli, F. (2016). NORMA: a software for intelligent conceptual modeling. CEUR Workshop Proc. 1660.

Google Scholar

Terraillon, J.-L. (2022). Digital transformation in the European Space Industry. ERTS2022 (Embedded Real Time Systems), Toulouse, France. https://doi.org/https://hal.archives-ouvertes.fr/hal-03694417.

Google Scholar

Valera, S., and Wijnands, Q. (2022). Space System Ontology Workshop, in Model Based Space Systems and Software Engineering (MBSE). https://indico.esa.int/event/407/sessions/1545/attachments/5015/7828/Full Session Presentation - OSMoSE Workshop.pdf.

Google Scholar

Vorobiev, A., Tiensuu, K., Gerené, S., Jahnke, S., Bitetti, L., and Koning, H.De. (2022). Model based system engineering hub.

Google Scholar

Weilkiens, T., Lamm, J. G., Roth, S., and Walker, M. (2022). “OMG systems Modeling Language,” in Model-based system architecture, 349–379. doi:10.1002/9781119746683.app1

CrossRef Full Text | Google Scholar

Whitehouse, J., Gonzalez Fernandez, A., Long, A. T. B., and Maleki, E. (2022). ESA SysML solution. Model Based Space Syst. Softw. Eng. (MBSE2022). Available at: https://essr.esa.int/project/esa-sysml-solution.

Google Scholar

Yang, L., Cormican, K., and Yu, M. (2019). Ontology-based systems engineering: a state-of-the-art review. Comput. Industry 111, 148–171. doi:10.1016/j.compind.2019.05.003

CrossRef Full Text | Google Scholar

Zheng, X., Hu, X., Lu, J., Arista, R., Lentes, J., and Kiritsis, D. (2024). An aircraft assembly process formalism and verification method based on semantic modeling and MBSE. Adv. Eng. Inf. 60, 102412. doi:10.1016/j.aei.2024.102412

CrossRef Full Text | Google Scholar