Adaptable MBSE Problem Definition with ARMADE: Perspectives from Firefighting and AAM SoS Environments ^†

Abstract

Model-based systems engineering (MBSE) offers significant advantages over traditional document-based approaches, particularly in improving the clarity, traceability, and efficiency of requirements engineering (RE). However, MBSE also introduces challenges, particularly in maintaining consistent semantics and handling evolving system models. This paper presents ARMADE, an agile requirements management and definition environment developed at DLR, which aims to address these challenges. ARMADE enables the flexible, user-friendly modeling of system requirements using a data model that incorporates natural language patterns. The tool supports the dynamic adaptation of metamodels and facilitates collaborative, project-wide requirements management. A case study based on two systems of systems (SoS) from the EU-funded HE COLOSSUS project—firefighting and advanced aerial mobility (AAM)—demonstrates ARMADE’s ability to manage complex, interdisciplinary requirements. The study highlights the tool’s potential to reduce data inconsistencies, improve adaptability, and enhance the overall efficiency of the RE process. By enabling seamless updates and changes to requirements, ARMADE shows promise as a versatile solution for dynamic metamodeling in complex systems, with potential applications extending beyond aeronautics to various industries reliant on intricate requirements management.

1. Introduction and SOTA

Requirements engineering is a foundational process in systems development, tasked with the critical responsibility of establishing complete, correct, unambiguous, testable, and understandable requirements for all stakeholders [1]. Its role in a project can be summarized into two main objectives: system specification and communication. The first objective is to guide systems engineers by constraining the design space and verifying the results obtained. The second is to facilitate communication between various domains within the engineering organization, including both business and technical domains. The ideal requirements must not only provide a technical specification detailed enough for engineers to develop the system design but also preserve essential information conveyed through informal natural language, such as the often ambiguous concerns and needs of business stakeholders. This dual nature makes requirements engineering one of the most challenging tasks in the systems engineering process, and it is often underdeveloped and overlooked [2]. However, when correctly specified, high-quality requirements can accelerate and improve the systems engineering process, enhancing engineers’ confidence in the design specification.

In today’s world, increasing complexity, inter-connectivity, and time constraints in systems engineering necessitate heightened accuracy, correctness, and efficiency in the requirements engineering process, making this already challenging task even more demanding. A clear example of this trend is seen in system of systems engineering (SoSE), where independent constituent systems (CS) must be integrated with precisely aligned requirements. Each CS exhibits operational and managerial independence, with varying contexts and stakeholders who may have different understandings of the problem and its associated concerns [3]. These business differences require system engineers to perform high-level analyses to capture mutual interests and resolve conflicts among collaborating enterprises [4]. Consequently, the defined requirements are often conflicting, cross multiple domains, and are continuously changing, complex, unknowable, and abstract. These characteristics shape SoSE requirements engineering, which must capture the overall qualitative and quantitative constraints of SoS design while enabling efficient management and exploration of gathered knowledge. Furthermore, because SoSE spans multiple domains, the requirements must remain understandable to non-experts, while conveying information without ambiguities.

As of today, the preferred approach for storing requirements involves informal language requirement statements, sometimes supplemented by graphical descriptions or formal language [1]. While informal language makes requirements flexible and easy to read, it also poses additional risks to a project, including reduced requirements quality, limited traceability, and increased difficulty in managing changes. For SoSE, informal language allows engineers to translate business requirements into technical specifications more easily, but the sheer size and complexity of SoSE design make this approach impractical [5]. A promising alternative is model-based systems engineering (MBSE) methods [6]. MBSE aims to replace document-based systems specifications with digital models that use standardized languages and data formats. With the rise of MBSE, industries have increasingly shifted toward digital, model-driven processes, offering improved product quality, enhanced clarity and traceability, and a more efficient requirements engineering process [7]. For SoSE, MBSE addresses complexity challenges by introducing common languages, unambiguous graphical representations, and cross-domain integration [8].

One of the most widely used MBSE modeling languages is SysML v1, which plays a pivotal role in defining and managing system models [9]. SysML typically represents requirements through graphical diagrams or tables, expressed as textual elements. While requirements can be linked to constraints using parametric diagrams to evaluate system design compliance, this process often requires manual effort. Moreover, the final documentation is not easily accessible to non-expert stakeholders, complicating communication of system expectations. The successor, SysML v2, aims to address these limitations by introducing a standardized API, simplifying the interface between models and other tools [10]. Requirements in SysML v2 can be directly linked to constraint types such as the interface, functionality, performance, and design constraints. This enables the more automated and consistent evaluation of system compliance. However, despite these advancements, the final output remains challenging for non-expert users to interpret, and the role of natural language statements is minimized, potentially reducing clarity in communication with stakeholders [11].

This paper introduces the agile requirements management and definition environment (ARMADE), developed by DLR. ARMADE’s core functionality is to capture and manage knowledge within a requirements database while retaining the advantages of natural language expressions alongside the technical rigor of formal languages. ARMADE provides flexibility by allowing the underlying metamodel to be adapted to project-specific needs. Other tools for requirements management are available in the literature, e.g., IBM Doors, which does not implement a metamodel for the unambiguous writing of requirements; and NASA’s FRET [12], which implements its own metamodel, named FRETISH [13]. The application case presented uses for ARMADE and focuses on modeling problem definitions and requirements for two aeronautical SoS from the EU-funded Horizon Europe COLOSSUS project [14]: firefighting and advanced aerial mobility (AAM). While this case centers on aeronautics, ARMADE is versatile and can be applied to any product or service driven by requirements. This study assesses ARMADE’s feasibility in a dynamic metamodel context, emphasizing its potential to enhance adaptability and clarity in product definition, reduce data inconsistencies, and improve efficiency in the requirements engineering process. The following sections provide an overview of the ARMADE methodology and its implementation, a description of the COLOSSUS project and application cases, and a summary of key findings.

2. Methodology and Implementation

ARMADE’s primary objective is to enable the modeling of system requirements in a flexible and user-friendly manner. At its core is a flexible data model that utilizes pattern-constrained natural language (NL) expressions that represent the semantics of user-defined element types. These aggregate together elements, such as generic objects, requirements, links, and requirement sets, exhibiting similarities of NL statements. The further introduction of attributes and attributes values enables data definition and perseveres the distinction between element types and elements definition, respectively. The relation between exemplary requrement type and requirement is presented in Figure 1. In order to interrelate defined datapoints, link, a triple-like entity is used, specifying the source, target, and type of relation between the points. Implementing ARMADE as a web application not only simplifies tool setup but also, through cloud-based storage, facilitates project-wide collaboration on the defined requirements. In this section, a deeper dive into the theoretical aspects and technical implementation is presented.

2.1. Methodology

The ARMADE requirements engineering process begins with the definition of element types attributes, allowing users to constrain the data types for attribute values. These values can include literals (e.g., real numbers or text), files (e.g., XHTML), enumerations, constraints, user-defined options, or references to specific element types. Attributes are also assigned roles to add semantics, with default roles such as part, function, parameter, and requirement condition, among others. Each element type may have an optional NL pattern that binds its attributes to a textual representation, enabling the automatic generation of descriptive text for type instances. Together, these attributes and types and their interrelations form a customizable meta-model, adaptable to the evolving needs of different projects. Once the meta-model is defined, users can create elements, including requirements, based on predefined categories. While the system includes default classes (e.g., stakeholders), it allows users to refine requirements through guided input based on attribute constraints. By referencing single objects for each requirement, ARMADE eliminates data duplication and ensures the seamless propagation of changes across linked elements. Finally, relationships between elements are established using five default link types aligned with OSLC relations: satisfies, specifies, validates, decomposes, and implements.

2.2. Implementation

As presented in the previous section, the ARMADE methodology enables flexible and user-friendly requirements engineering without constraining the underlying meta-model, which can be modified during the project. A further challenge related to ARMADE is a technical implementation, in order to test the feasibility of ARMADE for systems engineering’s requirements-engineering activities. For that purpose, a web application was developed, encapsulating the ARMADE foundation.

The main interface of ARMADE is a user-friendly table, the rendering of which depends on an underlying meta-model. Each table view can be displayed for a specific element type. Exemplary snapshots of table row of a requirement along with the related requirement type definition, stakeholder, and higher-level requirement is presented in the Figure 2. In the following example, a requirement statement has various attribute values, highlighted with different colors. To understand the meaning of different colors, the assigned requirement type was presented alongside. As it can be seen, each of the colors refers to a certain reference object type: orange—‘system’, purple—‘function’, blue—‘parameter’, etc. The only ‘colorless’ value is a numerical value of a 1000. In the column on the right, from statement definitions, numerous rounded chips can be seen, which represent the relation between the inline and another record. The exemplary requirement is ‘specifying’ higher-level functional requirements, while its source is a certain stakeholder to which it is of concern.

After creating a datum in a user interface, it is further processed, generating program-compiled values such as the textual representation of the object. Further compilation maps the project into a graph data-structure using an RDF (resource description framework). An RDF was chosen for structuring the requirement database to simplify the mapping of information to other data formats and to represent requirements along with related elements as a knowledge graph, accumulating and conveying knowledge of the engineered system. Furthermore, the usage of a graph aims toward a reduction in the amount of duplicated data, while attribute values are still unique for each of the requirements; each of them is referencing a single object, approaching the sheer definition of a single source of truth.

3. ARMADE Evaluation

The feasibility testing of ARMADE software (v.1.36.2) was conducted within the European project COLOSSUS. The COLOSSUS initiative aims to develop a multi-level systems engineering approach for integrating system-of-systems (SoS), constituent systems (CS), and business models [14]. A validation developed during the project engineering process is performed through two application cases, each focusing on a distinct operational domain and engineering paradigm [15]. These application cases are further named as EVE and ADAM.

In addition to employing different engineering paradigms, each application case represents a unique context for validating the systems engineering approach. The EVE application case focuses on the development of a firefighting SoS, while the ADAM application case centers on AAM and its integration within a multi-modal SoS. The latter includes long-distance train and aircraft travel, as well as urban public transportation. On the CS level, both application cases were considering two different types of aircraft, to provide required by SoS capabilities, namely, an electrical vertical take-off and landing vehicle (eVTOL) and a seaplane. Finally, for each of the application cases, two different scenarios were considered defined for inland and islands environments, resulting in varying success criteria.

Despite their differences, both application cases require a comprehensive dataset to successfully execute the development process. This dataset includes identified stakeholders and their needs for both SoS and CS, the definition of evaluation criteria such as life cycle assessment, life cycle cost, business models, and value functions, and the development of various requirements constraining the design space. These data were partly modeled in ARMADE for both ADAM and EVE application cases, enabling the identification of semantic objects necessary for developing feasible and correct designs. ARMADE structures the requirements, including the related context, functionalities and attributes, which were then refined for both application cases. Furthermore, traceability between defined stakeholders and defined requirements were analyzed, and context for each of the requirements datasets was extracted, which would simplify requirements integration with the developed systems model.

The collected data were later processed using Python scripts and the Neo4j desktop application. This allowed to perform feasibility studies of ARMADE, evaluating its capability to maintain requirements traceability and propagate changes within the database. Along the process, feedback about ARMADE usability was gathered, evaluating its ease of use, the amount of time needed to define new data, and the available functionality.

4. Results and Discussion

The following subsections outline the results obtained during the evaluation process, starting with the creation of the meta-model, followed by an overview of the data and concluding with the data analysis and feasibility evaluation of ARMADE for multi-level SoS and CS requirements.

4.1. Meta-Model

The meta-model developed in ARMADE serves as a common framework for structuring the requirements of both EVE and ADAM. It consists of nine attributes and eight object types, as shown in Figure 3, along with five requirement types, illustrated in Figure 4. During the data-modeling process, ARMADE’s native data types, such as stakeholders and link types, are also used.

This unified meta-model ensures the interoperability of the EVE and ADAM data sets. Ambiguous business goals are represented using the native data type stakeholder, relating them to the requirements of the type need. Unlike other requirement types, need lacks a template statement or assigned attributes. Subsequently, these needs are refined into success criteria, which describe the desired state of SoS scenarios, and environment elements. Furthermore, functional requirements define the required functionality for both SoS and CS, and these are further specified through performance requirements. Finally, non-functional requirements constrain system parameter values. To support the hierarchical traceability necessary for multi-level systems engineering, the native decomposes link is employed.

4.2. Data Overview

For both EVE and ADAM, the requirements database captures detailed information about stakeholders, their needs, and the scenarios with assigned success criteria. These inputs generate structured datasets for each application case, encompassing functional, performance, and non-functional requirements. During the creation of requirements, new generic objects are automatically generated with appropriate object types assigned. Additionally, links between these objects are defined to capture the complex interdependencies within the SoS and CS. At the time of writing, the EVE data-set includes 16 stakeholders, 143 requirements, 125 generic objects, and 173 links. Among these requirements, 82 constrain the CS, while 44 describe the SoS. The ADAM dataset consists of 17 stakeholders, 121 requirements, 128 generic objects, and 102 links, with 31 requirements assigned to the SoS and 67 to the CS.

Table 1. Overview of chosen data types and number of records defined in ARMADE. SC, success criteria; FR, functional requirement; PR, performance requirement; NR, non-functional requirement; Sys., system; Func., function; param., parameter.

Application Case	Stakeholders	Requirements					Objects			Links
		Needs	SC	FR	PR	NR	Sys.	Func.	Param.
AC1 (EVE)	16	30	14	17	50	45	4	18	59	173
AC2 (ADAM)	17	24	8	9	48	33	4	18	60	102
Common Data	13	22	4	9	48	33	2	18	59	102

summarizes the data records for each application case.

Interestingly, a high ratio of shared datapoints exists between the datasets, reflecting the benefits of using MBSE to minimize data duplication while engineering separate systems. This finding aligns with the overlapping domains of interest for both application cases.

4.3. Feasibility Results

A series of tests evaluate ARMADE’s feasibility for SoS requirements engineering. The first test focuses on traceability analysis, verifying the completeness of relationships between stakeholders and requirements. For each stakeholder in the database, information about its relationship to their needs is stored. Figure 5 illustrates the analysis results, confirming that relationship data are successfully exported from ARMADE and analyzed using Python scripts without data loss.

The second test evaluates ARMADE’s capability to link SoS and CS requirements. Data from ARMADE are imported into the Neo4j database, where they are queried to identify and visualize SoS and CS requirements referencing the same generic objects. For example, in ADAM (Figure 6), SoS and CS requirements reference the same noise and safety generic objects of type parameter. This demonstrates the creation of bindings across hierarchy levels through shared attributes. Additionally, the “SoS-Pollution” requirement illustrates traceability gaps, showcasing ARMADE’s potential to identify and resolve such issues.

Finally, ARMADE proves its feasibility in minimizing data duplication and propagating changes to system models. In the EVE dataset, a small change to the definition of a generic object is successfully propagated to all related requirements, eliminating the need for manual updates. Figure 7 showcases this process within the ARMADE interface, demonstrating how updates to a single object are automatically reflected in the associated requirements.

Overall, the feasibility evaluation of ARMADE was successful, demonstrating its capability to minimize data duplication, maintain consistency, and facilitate change propagation across system models. This was achieved easily due to the flexibility of RDF for integrating different models, as well as the ability to export data to Excel and JSON formats. Additionally, the simple and intuitive user interface made it easy to learn and operate, further enhancing the system’s usability.

5. Conclusions

The ARMADE methodology significantly enhances the requirements engineering process, particularly in the COLOSSUS project’s aeronautical SoS context. Requirements and the underlying meta-model are easily created for both application cases, while the use of RDF for data storage enables seamless integration with Python and Neo4j. ARMADE’s flexible meta-model supports project-specific needs, facilitating a clearer definition of stakeholder requirements and system functionalities. Case studies on firefighting and AAM systems highlight ARMADE’s ability to streamline collaborative efforts, identify data-model issues, and propagate changes across reference objects. The exploration of knowledge graphs reveals valuable commonalities between the two cases, underscoring ARMADE’s versatility. Future developments should refine the meta-model for broader industry applications, integrate AI for predictive analytics, and incorporate real-time data analysis to support dynamic project adjustments. These advancements will enhance ARMADE’s adaptability and efficacy, paving the way for its widespread adoption across domains driven by complex requirements.