1 Introduction

Societal and environmental demands with respect to the aerospace industry, as formulated in the ‘Flightpath 2050’ position paper of the European Commission [1], point out the necessity for fast adoption of novel aircraft technologies and vehicle concepts. Conceptual aircraft and system design studies play an important role in the early identification of potentially beneficial approaches [2]. It is therefore highly important to be able to represent and consider unconventional system designs in conceptual aircraft design and to be able to find safe and light architecture designs for these systems. However, as being concluded in the State of the art section of this publication, current methods for system analysis in the conceptual design stage are either very detailed but inflexible, so that the investigation of an architecture design space becomes difficult, or they lack the ability to perform automated analysis, which is important for conceptual aircraft design and an early assessment of design options. The SystemXF modeling approach presented here is designed to close this gap. The modeling approach is coupled to the SysML modeling standard and is based on a central XML-file. The model is capable of integrating different analysis disciplines.

In the following, the terminology used within this publication is presented in Sect. 2. In Sect. 3, the need for a novel and holistic system modeling approach in conceptual aircraft design is pointed out. The SystemXF concept is presented and the modeling process using a SysML profile is explained in Sect. 4. In Sect. 5 and 6, two analysis tools for safety and mass are briefly presented which are based on the SystemXF file. These are applied to an example system (Sect. 7) to show the applicability of the approach. Finally, some challenges and future work are outlined in Sect. 8.

2 Terminology

In the following, the term system describes an entity which is part of the aircraft and provides one or more functions to the aircraft (e.g., the flight control system provides the function “attitude control” to the aircraft) and/or to other systems (e.g., energy supply systems). A component, on the other hand, is the smallest system element considered. It is not further decomposed into its parts and owns a certain behavior and performs functions for the system. Subsystems represent intermediate levels of abstraction, being part of a system and being aggregations of components and/or other subsystems. Systems and subsystems do not have proper behavior, instead, their behavior results from the interaction of their components.

When the term system architecture is used, this refers to the physical architecture (or topology), if not stated otherwise. This encompasses the components and their interactions.

3 State of the art

In the classical system modeling approach of the conceptual design phase, aircraft systems are represented only by their masses and energy consumption [3]. Masses are typically estimated by historical regressions on system level (e.g., in [3, 4]). This is however only possible for conventional systems, i.e., systems very similar to a large group of already-built and certified systems. As the system architecture is not explicitly used in the methods, safety and maintenance considerations do not have to and can not be addressed. With the need for the integration of novel technologies, this approach is no longer sufficient: a more and more electrified on-board systems architecture as well as new propulsion concepts (especially hydrogen-powered) demand radically new aircraft and system architectures. The design of these new system architectures requires a detailed system modeling, taking into account the detailed system architecture. To determine this architecture, mass and energy consumption, but also safety and maintainability aspects should be taken into account.

There exist many approaches which try to overcome the deficiencies of this classical approach and which are also able to represent unconventional systems and architectures. In the following, these are differentiated according to their model of the system architecture. We call an architecture model in the following the way an analysis tool stores the components of which a system is composed and their relations. We further differentiate between implicit and explicit architecture models. In implicit models, this information is only contained implicitly in the code, there exists no graphical or textual representation of the system architecture to be seen for the user. The architecture is therefore mostly fixed. Explicit models, on contrary, do have such an architecture representation, through which the architecture can also be modified. There exist also tools with a semi-explicit system model lying between the two extremes: the system architecture is contained in the program code, but some degrees of freedom can be accessed by the user (e.g., the number of actuators per control surface).

In the following, some examples for the three categories are named. It has to be stated, however, that the landscape of aircraft system analysis is very heterogeneous and the tools do not all have the same scope or same area of application. E.g., some concentrate only on the system level (or even only on one system) without being part of a conceptual aircraft design environment. Some provide extensive analysis tools, some put their focus on architecture modeling without directly providing analysis tools.

An example of an implicit tool is the SystemsDesign tool in MICADO (Multidisciplinary Integrated Conceptual Aircraft Design and Optimisation) developed at the Institute of Aerospace Systems, RWTH Aachen [5]. Some major aircraft systems are modeled on component level, with the architecture being fixed as defined in the code. Energy flows and successively, system energy demands are modeled via a source-sink model. Additionally, mass equations are implemented on component level, so that the system masses and centers of gravity can be determined. This approach is useful when only one predefined system architecture is to be studied in many aircraft designs. However, architecture modification and new technology integration require major redesign of the tool. An example of a semi-explicit architecture model is the ASTRID-Tool of the Politecnico di Torino [6]. The Matlab-tool basically has a fixed, hard-coded architecture. However, some parameters influencing the final architecture can be modified using an input file.

One example of an explicit architecture model is presented by Jeyaraj [7]. Capella is used as system modeling environment. Based on a functional representation of the flight control system, components and their interfaces can be defined and aggregated to system architectures. Component models are made reusable via a library. The function-oriented modeling makes the approach open for the integration of novel technologies, but automatic analysis tools, as required for conceptual aircraft design, are lacking. Armstrong [8] follows a similar approach.

The method to model aircraft electric systems proposed by Schallert [9] can also be classified as explicit. The modeling language Modelica is used to model electric components including their differential equations. Failure modes can be edited for every component, which influence the component behavior (e.g., by setting an output voltage signal to 0 to account for an internal defect). A mass model is also integrated. The components can be graphically connected to form a system. However, Schallert states that modeling effort is high and only justified if such a detailed physical model is available or necessary, which is definitely not the case in aircraft conceptual design.

The ISSAAC Tool [10] combines both semi-explicit and explicit model properties. For certain functions (e.g., surface actuation, wheel braking) different implementations are defined (Electromechanical Actuator (EMA), hydraulic actuator, etc.). Thus, a large overall system architecture space is obtained. The detailed system architecture for the single systems (e.g., electric system network topology) is then done automatically and internally using a special heuristic based on the analysis of conventional systems. The rules obtained from these conventional systems are applied to unconventional systems too. The level of detail of the system model is rather low.

In summary, it can be said that implicit and semi-explicit architecture models allow detailed analysis of systems on component level, but are inflexible and typically do not allow to internally address safety or maintenance aspects. Tools using explicit architecture models have this flexibility, however, the integration in an conceptual aircraft design environment is difficult: either the model complexity is too high for conceptual design [9] or no analysis tools exist [7]. We therefore conclude, that there is a need for a systems modeling methodology with an explicit architecture model that can directly be integrated into an aircraft conceptual design environment. Thus, system architectures could be studied also for new aircraft designs (e.g., a Blended wing Body (BWB) aircraft). The system model should be graphically editable, open for the fast integration of new components and technologies and should support trade studies to find optimized architectures. Additionally, to obtain realistic architectures, it should be possible to address safety and maintainability aspects.

4 SystemXF model

Since 2020, the SystemXF (System eXchange File) method is developed. The method is designed to meet the needs outlined above. Its goal is not to provide design and analysis methods for specific technologies or systems, but to provide a framework to model very different systems and technologies without extensive effort (i.e., without reprogramming of the entire tool). The method aims at the conceptual aircraft design level primarily, but may also be helpful for studies and trade-offs on system level. An interface to the aircraft design software MICADO is planned. For conceptual design, very detailed analyses and component design tasks are not addressed. The focus lies on architecture design and analysis on aircraft level. The SystemXF method comprises a model generation process, the conversion into a central model file and a set of tools to analyze this file with respect to different disciplines. The core of SystemXF is a flexible, explicit system representation by an XML-file, the SystemXF-XML. This XML does not only contain architecture information, but also component models concerning mass, safety, etc. This can be done as for conceptual design purposes, analysis models are not too complex and can be integrated in one representation. In contrast to a model synchronization approach [11], this avoids the problem to track architecture changes through heterogenous models of different analysis disciplines during architecture trade-offs. The complexity of such a synchronization process seems unnecessary for conceptual design purposes. The central XML-file can be edited e.g., through a SysML interface and serves as input file for various analysis tools. These analysis tools read the necessary information, but do not change the model itself. The idea of a central data exchange file is similar to the role of the CPACS file for aircraft design [12].

Inspired by SysML, the system elements are described as blocks. SystemXF differentiates between SystemBlocks and ComponentBlocks. ComponentBlocks describe physical elements of the system, e.g., pumps, actuators, etc. The level of granularity depends on the choice of the system designer. ComponentBlocks represent the smallest unit and are not further broken down. Most physical properties (mass, energy consumption, failure propagation) are modeled on component level. SystemBlocks, on contrary, are abstract system elements, which group components and other SystemBlocks to larger hierarchy entities (like subsystems, systems, the entire aircraft).

Fig. 1
figure 1

SystemXF elements and different architecture dimensions

Full size image

The SystemXF method operates with four different dimensions of system architecture (see Fig. 1):

  • The physical architecture describes the components present in a system (with ComponentBlocks) and their physical relations.

  • The logical architecture describes the hierarchical decomposition of the aircraft into systems and subsystems. It is mainly used for a structuring of the system and consists of SystemBlocks and ComponentBlocks.

  • The functional architecture describes functions as well as their allocation to System- or ComponentBlocks. Functions can be structured hierarchically. Matter, energy and information flows between functions can also be modeled.

  • The zonal architecture describes the division of the aircraft into spatial areas, which are modeled by ZonalBlocks. They can also be ordered hierarchically and components can be allocated to zones. The zonal information is mainly important for maintainability analysis, but also for mass estimation (calculation of piping/ cable length) and safety analysis (zonal safety analysis).

As was pointed out in the chapter above, the SystemXF concepts are close to the SysML concepts. SysML diagrams are therefore used as graphical frontend to edit and modify the SystemXF model. SysML is an extension of the Unified Modeling Language (UML) specifically designed for use in Model Based Systems Engineering (see e.g., [13]). SysML models are represented by nine diagrams, from which only five are used within this context:

  • The block definition diagram (BDD) is used to define blocks and their hierarchy

  • The internal block diagram (IBD) shows the inner structure of SystemBlocks and connections between blocks

  • The parametric diagram (PAR) is used to model equation systems

  • The state machine diagram (STM) shows state machines

  • The activity diagram (ACT) is used to model functions

Although editing the SystemXF model in SysML is feasible, SystemXF is not bound to SysML. Other modeling tools or standards could also be investigated (e.g., Matlab Simulink and SystemComposer). Also, it is not the goal to convert every possible “standard” SysML model to a SystemXF-model, but instead the SysML concepts are specialized and modeling rules are established to edit the SystemXF model through SysML diagrams.

To better match the terminology of SystemXF, a profile is defined containing stereotypes for the SystemXF elements. Stereotypes extend the SysML concepts by further specializing SysML elements. They can thus add additional meaning to a diagram element (e.g., to point out the difference between components and systems by specializing the block element from SysML with two different stereotypes) and allow for the definition of additional values (tagged values, e.g., the type of a systemBlock). In Fig. 2, an example block definition diagram is shown:

Fig. 2
figure 2

Example of a SystemXF block definition diagram

Full size image

A SystemBlock representing the entire aircraft is always the top block. Its SystemBlock type is therefore “aircraft”. Blocks and their subblocks are connected via part-associations, shown as a connection with a black diamond on the upper block (or whole) end and a normal arrow on the subblock (or part) end. The generalization association is used to connect ComponentBlocks with their respective ComponentClass. It is shown with a triangular arrow pointing to the class. ComponentClasses are only used if several ComponentBlocks with similar behavior and equations are to be modeled, as shown here for class Actuator and ComponentBlock ACT_L1. Every ComponentClass instance has to be shown as ComponentBlock on the BDD. This convention is due to the zonal architecture, as two ComponentBlocks of the same class can be placed in different aircraft zones. ZonalBlocks are also modeled on the BDD.

Internal block diagrams (IBD) can be created for SystemBlocks. Their goal is to show connections between the subblocks of the respective SystemBlock, as well as with the SystemBlock itself. Figure 3 shows the “interior” FCS SystemBlock from the BDD from Fig. 2 (the GreenHydraulic ComponentBlock is omitted on the BDD). In SystemXF models, blocks are always encapsuled, i.e., connections can not access a part (e.g., a subblock) of a block, but only its ports.

Fig. 3
figure 3

Example of a SystemXF internal block diagram

Full size image

Component behavior is described with equations and state machines. These can be edited in SysML using parametric diagrams and state machine diagrams of a ComponentBlock, respectively.

Parametric diagrams in SysML represent equation systems in form of a block diagram. Equations are shown as constraint blocks. The parameters of these equations can then be connected (i.e., set equal) by BindingConnectors. They can also be connected to block properties or to port values. In the SystemXF context, the equation systems represented by parametric diagrams have a certain type, e.g., massEstimation or performanceCalculation. For each type, a different diagram is used and a different equation system is created in the SystemXF-XML. The corresponding diagram and model elements are further described in Sects. 5 and 6.

State machine diagrams (STM) describe component behavior by means of states and transitions, which are triggered by events. State machines are especially useful in modeling safety behavior. A simple example is shown in Fig. 4.

Fig. 4
figure 4

Example of a SystemXF state machine diagram

Full size image

Starting with a so-called initial pseudo state (filled circle), state changes are shown by transitions represented by arrows. For these transitions, trigger events and/ or guard expressions can be specified. These are explained in more detail in Sect. 5.

The behavior of some components can not be modeled using only one state space. Instead, orthogonal state spaces (state spaces which are independent of each other) must be used e.g., to model the position of a switch and its failure state (working/ failed). This is implemented in SysML using regions, as shown in Fig. 5. There is one single upper state State with two regions SwitchPosition and FailState. In each region, only one state is active at a time. The transition between POS1 and POS2 owns a guard expression which must be true before the transition is allowed to take place. The transition from WORK to FAILED, on contrary, is triggered by an event named Failure.

Fig. 5
figure 5

State machine diagram with two regions

Full size image

Functions are modeled as activities on an activity diagram. In Enterprise Architect, a link to these activities can then be generated on the BDD, where the allocation-relationship can be used to allocate the functions to ComponentBlocks or SystemBlocks.

Once the SysML model is defined in an editor program (here: Enterprise Architect by Sparx Systems), it can be exported in the XML Metadata Interchange (XMI) format, an XML format defined for the exchange of UML (Unified Modeling Language) and SysML models [14]. This can be converted into a SystemXF-XML file. Although the information is already present in the XMI format, it is useful to convert the file, as the SystemXF-file is better readable, smaller, and the relevant information is better accessible by other programs.

Similar to the XMI format, all blocks are shown on one XML hierarchy level. References between blocks (and other elements as well) are implemented using IDs. Although there is no restriction on the ID format and any string might be used, in practice Universally Unique Identifiers (UUID) are used. Below, parts of an example file are shown:

figure a

The part-associations are converted to the ownedSystemBlock / ownedComponentBlock children of the respective upper SystemBlock. A reference to a ComponentClass is simply implemented by the classID attribute. The connections specified on a SystemBlock’s IBD are written as ownedConnector.

A ComponentBlock or ComponentClass element contains the following subelements:

  • Owned ports (similar to a SystemBlock)

  • Fixed properties, e.g., mass, position

  • Variable performance properties (performance parameters, see below Sect. 6)

  • A state machine divided into regions

  • Trigger events for the state machine (e.g., failure events)

  • Equation systems, containing the equation expressions and the connections between equation parameters and e.g., port values or other properties

An example XML for a ComponentBlock is shown in Appendix 1. Methods to convert the SysML-model to the SystemXF-XML and to process this file are implemented in a library, the SystemXF-library. This library is used within the different analysis tools.

5 Model-based safety assessment with SystemXF

When conventional system architectures are to be modeled, safety considerations are less important, as certified and therefore safe architecture designs are available. For unconventional systems, this is not the case, as new architectures have to be designed. Safety can then be addressed using heuristic architecture rules derived from conventional system architectures (e.g., [15]), or by explicitly modeling and analyzing safety properties. Heuristic rules may be helpful in some cases, but do not generally lead to optimal solutions in every constellation. This could e.g., be shown by the authors in a prior publication, when a safety model could reveal weaknesses in an existing study [16]. As manual safety analysis requires too much effort when trade studies are to be performed, model-based safety assessment (MBSA) can be a solution. MBSA describes methods to formalize safety properties of a system in a model and to automate the generation of safety analyses. There already exists a large variety of MBSA-methods. With respect to aircraft conceptual systems design studies, these methods can be divided into three groups:

  • Standalone model: A model solely for safety analysis is generated by hand, which can then be designed close to traditional manual safety methods. One example are the variable reliability block diagrams (RBD) proposed by Raksch [17]. The diagram contains different alternative branches, offering the possibility to optimize the architecture

  • Integration in physical model/ Failure injection: A physical model of a system is augmented with failure information (e.g., a failure switch setting output values to 0). The system behavior can then be observed when different combinations of failures are triggered. This requires a detailed model in order to capture all failure effects correctly. Schallert [9] implements such a model using the modeling language Modelica.

  • Dedicated safety modeling languages: Dedicated safety modeling languages try to capture system behavior with a certain level of abstraction. The model generation is therefore simplified but the model is still very expressive. Many of the languages are based on state machines for the components. Prominent examples are AltaRica 3.0 [18] or smartIflow [19].

In the SystemXF safety analysis tool, the third approach, the integration of a dedicated modeling language on component level, is employed. This has three main reasons:

  • The expressivity of such a model is higher than that of e.g., a variable RBD

  • Modeling languages can be used to assess different failure conditions from a single model (e.g., loss of function vs. unintended execution of function), which is especially interesting for software-intensive systems

  • The modeling effort is lower compared to a physical model, which is not justified in the context of conceptual aircraft design

Also, the integration in a central model eases the task to perform trade studies on the architecture, if not only safety, but also mass etc. have to be considered.

In the current implementation of the SystemXF safety analysis tool, AltaRica is used as modeling language. Its origin lies in 1999 [20] and it has been updated several times. The latest version, AltaRica 3.0 is based on Guarded Transition Systems (GTS) [21]. The mathematical details are not discussed here, instead, a few features of the language are outlined in the following. The interested reader might refer to the language specification [22] and the very well-designed tutorial of the language [23].

An AltaRica model is structured by blocks and classes, thus combining ad-hoc definition of elements and object orientation. Within a block or class, flow variables, state variables and events can be defined:

  • Flow variables can be used for communication between blocks/ instances of classes. They are updated using assertions

  • State variables describe internal states of a block and are updated by transitions

  • Events can not be triggered by variables, instead, they are associated with a stochastic or deterministic delay. Transitions are always triggered by events

Variables can be defined as Boolean, but there is also the possibility to define a domain, a sort of enumeration of several discrete values. The following code is an example of a simple component implementation:

figure b
Fig. 6
figure 6

Schematic representation of the example assertion

Full size image

Figure 6 depicts schematically the component behavior from the code above as implemented by the assertion expression.

Variables have to be declared with an initial value (state variables) or reset value (flow variables), respectively. In and Out are two flow variables of type Boolean, State is a state variable of domain type ComponentState with the two possible values WORKING and FAILED. The assertion writes a value to Out depending on State and In: if the component is in state WORKING, then the value of in is propagated to Out, otherwise Out is always false. The value of State, which is initially WORKING, can be changed through a transition. A transition consists of three parts: a trigger event, in this case Failure. The transition can only happen if this event occurs. When this is the case, the guard expression is checked (here: State==WORKING). If it is true, then the action is performed. Here, the state variable State receives the value FAILED.

Nguyen et al. [24] propose a mapping between certain SysML elements and AltaRica 3.0 model elements, so that parts of an AltaRica model can be edited via SysML. This approach is also employed and extended for the SystemXF safety analysis tool. SystemBlocks can be represented by blocks in AltaRica 3.0. Ports are modeled via flow variables and connections via assertions. Components, on the other hand, are converted into AltaRica classes and are instantiated in the respective blocks. As was already mentioned, component behavior can be described using state machines. These are then converted into state variables. The single states are written as domain values, transitions are transcribed straightforward to AltaRica 3.0 transitions. An example is the state machine from the previous section in Fig. 4, which corresponds to the state variable from the example code above.

Assertions for ComponentBlocks are modeled in SysML using parametric diagrams, as shown in Fig. 7.

Fig. 7
figure 7

Example of a SystemXF parametric diagram containing an AltaRica assertion

Full size image

The expression has to follow the AltaRica 3.0 semantics. The equation is later directly converted to an AltaRica assertion. Two features are noteworthy here: the port HydrPressureOut is of type Hydraulic, which is a nested port type, containing two subports: Safety (type: Boolean) and VolumeFlow. Nested ports are used to different aspects of a connection, e.g., volume flow and pressure of a hydraulic connection. As safety model variables are either enumerations (conversion to domain) or Booleans, they are typically modeled as subports. The other remarkable point is the RegionValueProperty stereotype of property FailState. Assertions can contain state variables. In the parametric diagram, they are displayed as RegionValueProperty, which represents a state machine or a region of a state machine from the state machine diagram.

With the mapping explained above, the SystemXF-model can be automatically transformed to an AltaRica 3.0 code model. An observer variable of type Boolean is then added to the AltaRica model which is true if a certain failure condition is met. Using the AltaRica 3.0 project tools, the model can be processed, checked and analyzed automatically. The analysis details are defined in a control file. Analysis methods include:

  • Fault tree generation, assessment, and visualization

  • Sequence generation

  • Stochastic simulation

Examples for results of a sequence generation and stochastic simulation can be found within the application example in Sect. 7.

6 Mass estimation in SystemXF

The estimation of a system’s mass is, along with the energy consumption, most important for the aircraft conceptual design process [25]. As indicated in Sect. 3, traditional methods use historical regressions to determine the mass of an entire system based on key parameters of the aircraft design (e.g., MTOM, No. of Passengers). These methods therefore do not consider the components or the system architecture. Jünemann et al. [26] classify these methods as Level 0 fidelity. Level 1 methods, on contrary, estimate the mass on component level, using e.g., empirical equations for the component masses. This approach is required when unconventional systems are studied, or when architecture trades are intended.

Koeppen [25] proposes a component-oriented approach, in which key performance parameters are identified for system components, e.g., hinge moments for an actuator. Consequently, relations to other components’ parameters are identified (e.g., a volume flow for a hydraulic system). The masses of the main components are then estimated based on these key performance parameters. Similar approaches are proposed e.g., by Lammering [5] and Liscouët-Hanke [27]. The mass estimation approach proposed within this publication is similar to the already named approaches. The following prerequisites must be met by the mass model:

  1. 1.

    The mass of a single system is the sum of its components’ masses. If necessary, a scaling factor to account for additional, smaller components can be used

  2. 2.

    For the main components, a mass model can be found based on a set of key performance parameters

  3. 3.

    The performance parameters are either available from the aircraft design or can be calculated from others component’s parameters

Empirical mass models for entire systems are only available for conventional architectures. On component level, however, simple mass models (e.g., power-to-weight ratios) are available also for many unconventional or new components. These can be used in the SystemXF-model. As this approach is widely used for conceptual design tools, it can also be used for SystemXF. We further make the following assumptions or restrictions:

  1. 1.

    It is sufficient to propagate the performance parameters along the specified connections from the SystemXF model, which represent physical connections between the components

  2. 2.

    The resulting equation system must be in triangular form, i.e., there must exist an order in which the equations can be subsequently calculated

The methodology of the mass estimation is shown in Fig. 8.

Fig. 8
figure 8

Mass estimation methodology

Full size image

As the mass equations of the components are based on performance parameters, these must be obtained first by solving the performance equations. These equations of the ComponentBlocks form an equation system. Its possible input values are performance parameters of the component itself or performance parameters from other components which are propagated via ports and connections. Performance parameters can be calculated or directly specified in the mass estimation tool input file. Mass equations do not have input values from other components, but are calculated based on performance parameters. Alternatively, a fix component mass can be directly specified. Global parameters are inputs for every calculation and can be used to define constants, e.g., pi.

The mass estimation tool is implemented in C++ using the SystemXF-library. As the performance and mass equations are specified within the SystemXF model for each system, the mass estimation tool is basically an equation interpreting algorithm. Inputs are specified via XML-file. These include:

  1. 1.

    Values of performance parameters

  2. 2.

    Global Variables (e.g., pi, g)

  3. 3.

    Scaling factors to account for non-modeled additional components

First, the SystemXF-file and the input file are imported. Then, the performance equations are calculated iteratively. The algorithm loops over all performance equations of all ComponentBlocks. When all equation inputs are specified, the equation is calculated and the result is propagated to connected other equations. This procedure is repeated until all equations are calculated or no equation can be calculated anymore.

When the performance parameters of all components are calculated, the mass equations of each component are used to calculate the respective component’s mass based on its performance parameters. In a last step, the masses of a SystemBlock’s ownedComponentBlocks (including those of a subsystem block) are summed up and optionally scaled using a scaling factor.

Figure 9 shows the mass equation of a HydraulicSystem. The mass of the component is represented by the property mass with stereotype blockParameter and is calculated using the two performance parameters maxHydrPower and specPumpMass. The first one is calculated by the performanc equations, the latter is an input parameter specified in the input file. BlockParameter properties refer to fix properties of every ComponentBlock, e.g., mass or position, whereas performance parameters are added to components as required by their equation systems.

Fig. 9
figure 9

Parametric diagram of the mass equation system of ComponentClass HydraulicSystem

Full size image

The corresponding performance equation is shown in Fig. 10.

Fig. 10
figure 10

Parametric diagram of the performance equation system of ComponentClass HydraulicSystem

Full size image

The parameter deltaP is specified via input file. MaxVolumeFlow, on contrary, is connected to the VolumeFlow subport of the HydraulicPressureOut port. As was specified in the FCS IBD (see Fig. 3), this port is connected to the Hydraulic port of an actuator, in which this value is calculated (performance equations not shown here), as the hydraulic system sizing depends on the hydraulic power demand of the consumers (here: the connected actuator).

The method outlined in this section is expected to be applicable to most conventional and unconventional system architectures. The authors also believe that the modeling effort is moderate once the equations are known. However, there are some limitations in the current implementation:

  • Piping and cables can not be sized solely based on performance parameters. Their length is the main parameter and therefore, routing considerations have to be included (as has done e.g., Lammering [5]). This has not been done yet, but will be addressed in future research. In principle, the information from the zonal architecture can be used for this purpose

  • Currently, the performance parameters are calculated with fixed equations. These have to be adapted eventually if the component is used in a different context, e.g., when a hydraulic pump does supply two instead of one actuator. This, on the other hand, requires to take into account different degradation levels: Can both actuators be active at the same time or not? Liscouët-Hanke [27] and Armstrong [28] have already done research on this topic. This aspect should also be included in future developments. To do so, information from the safety model could, for example, be used.

7 Application example

Fig. 11
figure 11

Block definition diagram of the example pitch control system

Full size image

In the following, an example system is modeled in SystemXF to show that the concept is applicable to realistic system designs from conceptual aircraft design studies. The system is a simplified version of the A320 pitch control system [29], showing only the actuators of one elevator side. The examples above are mainly taken also from this system design. Figure 11 shows the BDD of the entire system. The main SystemBlock FCS owns two control computers (ELAC_1 and ELAC_2) of the ControlComputer class. These provide a command signal to the SignalSwitch component (which is not shown directly in [29]). Depending on integrity information from the computers, the actuators and the hydraulic systems, the SignalSwitch either activates the actuator ACT_L1 or ACT_L2 while inactivating the other. Those two are of class Actuator. Hydraulic pressure is supplied to them via GreenHydraulic and BlueHydraulic components of class HydraulicSystem.

These connections are shown on the IBD of FCS (Fig. 12).

Fig. 12
figure 12

Internal block diagram of systemBlock FCS

Full size image

7.1 Mass model

The mass model considers only the actuator components ACT_L1 and ACT_L2 and the two hydraulic systems, which are here simply modeled as hydraulic pumps. The control computers and the SignalSwitch are considered to be massless and only accounted for by a scaling factor for the entire FCS. These assumptions are similar to those which Lammering proposes [5].

The mass equations for component class Actuator are the same as used in MICADO and are originally taken from [30]. The respective diagrams are not shown here. Its performance parameters are geometric values or performance specifications (dive speed), hence they should be available from the aircraft design. Therefore, they are specified via input file and the equation system can directly be evaluated. The performance equation system of Actuator uses a semi-empirical equation for the hinge moment estimation to calculate the maximum required volume flow, which is needed for the HydraulicSystem sizing. The performance equation is not shown here. The mass and performance equation of HydraulicSystem were already explained in Sect. 6. An empirical scaling factor of 1.33 for the FCS is used to account for the component masses without detailed model [5]. Input values were taken from the Central Reference Aircraft data System (CeRAS) CSR-01 reference aircraft [31].

7.2 Safety model

To model the system’s safety properties, simple two-state state machines comparable to the one shown in Fig. 4 are implemented for every component, except for the SignalSwitch, which is treated as a perfect component without internal failures. The HydraulicSystem assertion was already shown in Fig. 7. The other components are comparable, only the STM of SignalSwitch differs, which is shown in Fig. 13. The component operates in two modes, Mode1 and Mode2. Starting in Mode1, the guard expression permits a state transition when ACT_L1 is defective, its hydraulic supply is defective, or the corresponding control computer provides an invalid signal. A transition back to Mode1 is not permitted. The real A320 pitch control system is more complicated and possesses more operational modes for a degraded system integrity. The failure rate for the ELAC’s are taken from Bennett et al. [32], the other components’ failure rates are taken from the Nonelectric Parts Reliability Data [33]. As failure condition, “Loss of pitch control” is defined as the flow variable values of the two FCS output ports El_L_1 and El_L_2 being simultaneously false.

Fig. 13
figure 13

State machine diagram of component SignalSwitch

Full size image

7.3 Results

When the SysML model is completed, it can be exported to the XMI format by Enterprise Architect. The resulting file is then read in by the safety analysis tool and the mass estimation tool, along with the respective tool input files. The rest of the analysis workflows is completely automated.

Table 1 contains the generated event sequences. Each sequence represents a chain of failure event, which leads to the fulfillment of the failure condition (i.e., both actuators do not move when a movement is commanded). In the second column, it is indicated if the sequence is order-sensitive. For most sequences, the reverse order of events also leads to the failure condition. These sequences contain the same information as minimum cut sets from a fault tree. The last sequence, on contrary, is order-sensitive. Due to the switching behavior of the SignalSwitch, the reverse order does not lead to the failure condition. Only two-event sequences are shown here, as the higher-order sequences always contain one of the two-event sequences. They therefore do not represent a new system failure mechanism, but display only one of the two-event sequences combined with another event. Second order sequences can be expected within a simple redundant system.

Table 1 Generated failure sequences for the failure condition “Loss of pitch control”
Full size table

The sequences represent the different mechanisms that can cause the failure condition to occur. Therefore, they can be a starting point for architecture improvement.

Using stochastic simulation, the probability for the failure condition can be calculated. A mission time of 1 FH was defined. With \(10^9\) iterations, a probability of \(7.4\cdot 10^{-8}\) 1/FH is obtained.

Table 2 shows the results of the mass estimation tool.

Table 2 Results of the mass estimation
Full size table

The values for the actuators correspond to the authors’ experiences with hydraulic servo-actuator masses. The hydraulic system masses are not comparable to realistic aircraft system masses, as the model used here contains not all components of a hydraulic circuit and the real system has a higher power due to additional consumers.

The small example already reveals challenges of the SystemXF method which will be addressed in future work: while the graphical modeling approach provides an intuitive architecture representation, the edition of large equation systems causes more effort than coding a textual representation. Also, architectural changes (e.g., adding a redundant component) causing a change in the port numbers of a component lead to changes in the equations. This makes the modeling approach more inflexible and increases workload during trade studies.

Also, model validation presents an intrinsic difficulty due to the flexible nature of the method, especially for unconventional systems, for which reference data is not available. In this case, a validity argument can be constructed from three parts:

  1. 1.

    The equations of the different disciplines are valid for the given case

  2. 2.

    The equations and are correctly implemented and the model represents the system correctly (components and relations are correct)

  3. 3.

    The model is correctly processed and analyzed by the analysis tools

The first point can be shown by choosing trustworthy and valid sources. The third point can be assured by extensive debugging and testing. With increasing experience, the presence of bugs that compromise the results becomes more and more unlikely. The second part therefore poses the main problem for a validation argument. One possible approach is a test environment for single component models. But also an increased reusability of the component models can reduce the probability of errors, as it is more likely to find errors when using the component in different models over a longer period of time.

8 Conclusion and outlook

A modeling methodology for systems in conceptual aircraft design is presented, that fills the gap between implicit architecture models with detailed analysis methods and explicit models without them. It allows for the integration of different analysis disciplines. This was shown for the mass and safety discipline, but the modeling methodology has also the potential for other disciplines (e.g., energy consumption, maintainability analysis) to be integrated and thus has the potential to enable a holistic assessment of systems in conceptual aircraft design studies. The central XML-file is used to store and exchange the system model between different analysis tools. This file can be edited using a SysML-interface with a special profile. Two analysis tools are presented to analyze safety and mass based on the SystemXF-model. The method meets the requirements outlined in Sect. 3: through the interface to SysML and by using a profile, the model is completely graphically editable. It is also not technology-specific, but provides only a framework in which any type of component (and system) can be modeled. As the graphical model can be easily manipulated, SystemXF enables trade studies. The applicability of the approach could be shown by an example using a simplified pitch control system of the A320.

Some limitations of the current implementations of the analysis tool and several future work areas were already discussed in the mass estimation tool section: the inability to include cable and piping mass and the limitation to a static model which does not include different redundancy strategies. In the following, problems and possible developments for the overall methodology are discussed.

The current way to edit a system model via SysML provides some benefits: Users already accustomed to this modeling standard will have few difficulties with the model edition. The graphical representations of the system (BDD and IBD, especially) provide an overview of the architecture intuitive to understand. The same holds for the state machines, at least in the personal experience of the authors. On the other hand, the edition of the equations using parametric diagrams causes in many cases more effort than simple textual code edition. Currently, a hybrid modeling approach is under study combining both forms to increase modeling efficiency.

The ability to perform trade studies remains to be shown and evaluated in detail in a future publication. Also, a more general evaluation of the modeling approach and a comparison with existing approaches for (especially unconventional) systems modeling in conceptual design will be addressed in future research. Key questions are whether the modeling effort is justified and to what extent the safety model is useful for generating “good” architectures. As the answer depends on the modeled system type and the degree of detail required for the specific application case, a final evaluation can only be done after multiple experiments with different systems.

As was already pointed out in a previous publication [16], the reusability of component models in different contexts is a key factor for minimizing workload in architecture trade studies and therefore a crucial point for the applicability and validity of the approach. If, for example, a redundant component is added to the system, the connected components have to be changed as well: additional ports have to be added, hence a modification of the equations is also needed. This increases the workload in trade studies and therefore decreases the feasibility of these studies. This should definitely be addressed in future research. A potential solution is the definition of meta-component classes, which describe a component with a variable number of ports. During instantiation, the port numbers are fixed and the general equations with parameters are simplified accordingly.

The direct integration of the system analysis discipline in the conceptual aircraft design process is beneficial when new system architectures are studied within novel aircraft concepts. For aircraft design, mass and energy consumption modeling of the systems are most important [25]. A first version of a mass estimation tool is presented here and a concept for energy consumption modeling is currently under development. Additional analysis disciplines can be added in the future, e.g., cost analysis and maintainability analysis. Also, for the safety analysis tool, the use of a different safety modeling language could be investigated, e.g., smartIflow [19]. Until now, the SystemXF tools are standalone analysis tools. However, an interface to the MICADO aircraft design environment which was developed at the Institute of Aerospace Systems [34] is planned, so that single systems are not defined internally in MICADO, but analyzed within the SystemXF toolchain.