Keywords

1 Introduction

The current trend for technological innovation, combined with a global market increasingly demanding, push production requirements and the need for new competitive products towards the adoption of innovative and integrated design processes. The Systems Engineering (SE) for systems development is spreading within this context since it promotes robust design for complex systems [1]. On another hand, SE as an approach still has potential improvement widely studied in scientific literature [2]. Especially, the concept of V-Model [3] is adopted as the basis for designing process compliant to SE. Special attention is given to design in the last stage of V-Model where a transition from conceptual representation to modelling is a critical aspect with potential loss of information and rising of non-compliant models.

However, since the top-down design process intrinsically included in SE positions the design phase after the architecture definition, the complexity management through a structured system decomposition [4] allows increasing the system preserving control and supervision. Indeed, the design definition process looks at technical solutions for abstract elements stated in logical architecture and defines their characteristics at different levels of detail. Therefore, system analysis supports the decision-making process at each level of design through the adoption of modelling as stated by MBSE. Furthermore, as Pahl and Beitz [5] divide the design process into three steps which are still relevant today i.e., conceptual design, embodiment design and detailed design, physical modelling should be better detailed to consider the increase of information during the modelling. Considering that the first stage of design is “sizing”, it involves the setting of parameters, constraints, and their relations to produce systems performances that will meet requirements. However, since very often design models appear before the architectures are defined, it occurs the bridge between the two stages of the system development process is not established. This gap could lead to errors, loss of time due to redesigns and a lack of tracking requirements that need to be verified and validated continuously.

In [6], the authors fill the gap between representative tools and simulation tools by means of Parametric Diagrams of SysML (System Modeling Language). SysML, as a general-purpose graphical modelling language, is widely adopted by MBSE practitioners. It is made up of graphical notations with specific meanings that allow the construction of several diagrams with different modelling purposes. In particular, SysML supports system analysis through a Parametric Diagram, where “constraint block” represents a set of equations, with parameters to be analysed [7]. The resolution of these equations is exploited for both dimensioning and trade-off. On the same trend, Yvars et al. [8] characterize the sizing task in the design process by translating it into a constraint satisfaction problem. Given the logical decomposition of a system, the needs are modelled as equations relating design variables, behaviour variables and performance indicators associated with system components. However, traceability between logical architecture and sizing elements is not established. On the other hand, Bagdatli et al. [9] pursue the goal of traceability by using constraint blocks of SysML language. Bijam et al. [10] adopt SysML parametric diagram for the formalization of requirements and constraints enabling their verification during the system development process. Leserf et al. [11] also adopt the SysML parametric diagram to set model variants and to prepare the trade-off analysis by means of objective functions.

The present work aims to contextualize the aspects highlighted in the related works through a development process as a bridge between the generation of architectures and system design. We want to make the sizing process the natural continuation of system architecture development, giving value to the latter as a starting point for the design process together with the requirements. The proposal pushes toward an innovative approach for (i) rapid development of new models focusing on the connection between requirements and parameters, (ii) tracking of the designing process and choices alongside RFLP (Requirements, Functional, Logical, Physical) and (iii) the evaluation of performance requirements connected to the System of Interest (SoI). Indeed, anchoring global parameters from a System of Systems (SoS) to requirements and external constraints of SoI by means of Validation Criteria, enables parametric modelling not only about physical models but also about symbolic representations on a high-level, before implementing technical solutions on design.

Fig. 1.
figure 1

Multi-level V-Model for Preliminary Design, Detailed Design and Implementation of Physical Modelling.

Full size image

2 MBSE Design Framework According to V-Model

The proposed approach relies on V-Model for Systems Engineering with the descending branch of system decomposition performed through the RFLP modelling method. The current proposal distinguishes the design phase into a preliminary design (PD) and a detailed design (DD) (see Fig. 1). Both phases embed the set of modelling activities that support the design at different levels of detail. Since the sizing model is commonly used during the preliminary design phase, its parametric nature allows for pursuing the goal of better integration with the logical architecture model. For this reason, the proposed framework introduces the parametric analysis besides the logical one with the aim to (i) prepare the basis for numerical sizing (in preliminary design), (ii) enable the connection with requirements and elements of logical architecture at the same level of system decomposition and (iii) pose the basis for stakeholder requirements definition at the next lower level. Parametric Analysis aims to define a sizing frame for functions. To this purpose, a set of items is introduced to define the frame and trace the sizing process. The output of this analysis is exploited for verification and validation according to the Preliminary Design stage. At higher levels, system elements are still black boxes that become new systems of interest if they cannot be immediately implemented and need to be deepened at lower levels. The sizing modelling and parametric analysis at a higher level support the derivation of new stakeholder requirements at a lower level allowing systems decoupling. Consequently, three cycles of Verification and Validation are proposed. The first one relies on preliminary design results or sizing, the second one follows the detailed design or performance design, and the last one comes after the hardware/software implementation.

The designing process that executes the proposal follows six stages alongside descending and ascending branches of V-model, expanding the common version by means of intermediate steps and recursive cycles. In the following, the main stages are introduced and argued:

  1. 1.

    Context: analysis of the SoI goals and interaction. It is composed of:

    1. (a)

      Requirements Analysis: elicitation of needs, constraints and requirements, from Stakeholders Requirements to System Requirements.

      1. i.

        Stakeholders Requirements: problem-oriented issues about stakeholder needs connecting to validation criteria.

      2. ii.

        System Requirements: solution-oriented issues about “how the system shall work”.

    2. (b)

      Validation criteria are specifications needed to instantly verify Stakeholder Requirements and assure system performance compliance.

  2. 2.

    Behaviour: analysis about all actions the SoI shall carry out, given the requirements analysis. It can be executed by means of:

    1. (a)

      Operational Analysis to define actions and sequence of operations the SoI shall perform.

    2. (b)

      Functional Analysis to define the functions the SoI shall implement to achieve the required purpose.

  3. 3.

    Architecture: logical representation of elements belonging to the SoI, with ports, interfaces, properties and flows. It is composed of two stages:

    1. (a)

      Logical Analysis and decomposition of the System to define the sub-systems and components that implement the functions.

    2. (b)

      Logical Architecture to define relations among subsystems and components and their interactions (i.e., ports, interfaces, connections).

  4. 4.

    Parametric: preliminary analysis about the sizing of the SoI (inputs, outputs and parameters) where functions are intended as a black box. It is composed of:

    1. (a)

      Parametric Analysis to identify functions as a black box and global and local parameters to contextualize the sizing frame.

    2. (b)

      Attributes definition to relate parameters to Stakeholder Requirements and Validation Criteria.

  5. 5.

    Design: Physical Modelling for preliminary and detailed design, as well as implementation.

    1. (a)

      Preliminary and Sizing Design to estimate values for features and parameters as internal parameters and outputs towards other systems.

    2. (b)

      Detail and Performance Design to perform advanced modelling for dynamics simulations to evaluate how the system performs.

  6. 6.

    Post-processing: Verification and Validation process connected to Stakeholder Requirements:

    1. (a)

      Verification process is related to post-processing and assures that SoI executes what is established respecting system requirements.

    2. (b)

      Validation process poses attention to stakeholder requirements, assuring the SoI executes what stakeholders request.

3 Use Case: Thermal Management System of Electrical Motor on a Hybrid Aircraft

This section presents a case study of a system dedicated to the disposal of heat and control of the temperature of a heat source (i.e. Electrical Motor) installed on a hybrid aircraft. The SoI is a Thermal Management System (TMS) that keeps the temperature of the heat source within a certain range, by giving heat to a heat sink (i.e. external air) by means of a coolant mass flow. The coolant (fluid used as heat transfer) passes through the heat source, increases temperature, and releases heat to a secondary fluid towards a heat sink. Therefore, since the thermal power passes from the heat source to the heat sink, the context has a fundamental role in the design and defines possible design choices that lead to the development of the final architecture. According to the purpose of the paper, the case study is used for the definition of the problem and context, as well as for tracking of validation criteria. However, the modelling and sizing stage of SoI is out of the topic of this work. Therefore, only a few stages of the proposed workflow (Sect. 2) are highlighted: Logical and Parametric Analysis of the SoS where SoI is inserted and Requirement Analysis of the SoI during the step into the lower level. The development process starts with the analysis of the context where the TMS works. Figure 2a and Fig. 2b illustrate the logical architecture and the parametric network of the SoS. Logical Architecture defines ports and flows of the SoI, whereas Parametric Diagram specifies inputs and outputs for sizing. Given the low Technology Readiness Level adopted, and since this system interacts only with the heat source and heat sink, a simplified architecture is reported. Logical Architecture and Parametric Diagram provide the context; Stakeholder Requirements and Validation Criteria are used by the designer to develop and validate the SoI.

Fig. 2.
figure 2

(a) Simplified Logical Architecture of Aircraft (SoS) and (b) Parametric Diagram at Aircraft level

Full size image

TMS takes as inputs a coolant flow mass rate with a certain temperature and shall provide the same mass flow rate with updated thermodynamics conditions. In this application, TMS collects air mass flow rate from the external environment as a heat sink. Once considering the design of a specific system, all information is not needed, but just the context it belongs, and information exchanged, such as heat power produced and air mass flow from the external environment. In this way, it is possible to obtain a decoupling of the system from all the other systems. The problem is presented in a parametric and agnostic way. The parameters and values are reported as referenced variables. As “Global Mission”, the TMS shall provide a variable flow rate (\(\dot{m}\)) of a specific fluid (\(c_{p}\),viscosity) within precise thermal conditions (\(T_{in}\), \(T_{out}\)) to the propulsion system in order to remove a certain quantity of heat power (\(\dot{Q}\)), respecting space (V) and weight (W) limits. The heat power produced follows a certain function or law that depends on the mission profile, atmosphere and power source. Since the attention is on sizing, only the design point (\(\dot{Q}_{max}\)) is considered. Consequently, the system estimates the air mass flow given the external conditions (\(T_{air}\), \(P_{air}\)). The sizing process needs to perform a recursive process where the heat source, thermal management system and external interface are mutually influenced, as shown in Fig. 2b. Therefore, the designing process of TMS, intended as a “black box” starts by deriving System Requirements and Constraints from Stakeholder Requirements. Then, inputs and outputs are defined and included as attributes within the block representing the SoI. A set of constraints (from outside) and estimated parameters (towards the outside) are defined and connected to requirements and validation criteria. Finally, in Fig. 3, the relationship that connects the sizing block and logical block by means of connectors between attributes and parameters is reported. As seen, the global values of the logical block, are connected to the global parameters of the corresponding sizing function.

Given the Global Mission of the system, and known the context, a set of Stakeholder Requirements is given and associated to Validation Criteria to prove the SoI meets the stakeholder needs. In Fig. 4a, three Stakeholder Requirements are reported as main needs to be satisfied in combination with assigned validation criteria:

  1. 1.

    The SoI shall keep the coolant within a precise thermal range (\(T_{it}\), \(T_{out}\))

    • \(T_{in} > T > T_{out}\)

  2. 2.

    The SoI shall provide a variable mass flow rate (\(\dot{m}\)) of a specific fluid (water) in a specific phase (liquid)

    • Heat capacity of coolant falls within \(c_{p,max}\) and \(c_{p,min}\)

    • Coolant Mass Flow Rate = \(\dot{m}\)

  3. 3.

    The SoI shall respect weight (W) and space (V) limits imposed by context and surrounding environment

    • Total Weight \(< W \)

    • Heat Exchanger Volume \( < V \)

Fig. 3.
figure 3

Correlations between System Attributes and Global Variable of Sizing Functions.

Full size image
Fig. 4.
figure 4

(a) Stakeholder Requirements of SoI (b) System Requirements of SoI

Full size image

Afterwards, the designer team derives a first level of System Requirements that aim to “satisfy” Stakeholder Requirements. In the Requirements Diagram (Fig. 4b), requirements are reported and managed as a tree using different kinds of items and connections. In particular, “containment” is used to decompose plural requirements, whereas “satisfy” and “derivereq” trace connections among the requirements chain. Main System Requirements verify Stakeholder Requirements whereas Validation Criteria are allocated as SysML constraints. Furthermore, three different kinds of System Requirements are adopted: Functional Requirements, Constraints and Design Choices. The last one traces technical solutions implemented and removes degrees of freedom from the system.

Once the context for the TMS has been defined thanks to the parametric analysis at the aircraft level, the functional and logical analysis will be developed in the following phases according to the approach proposed in Sect. 2. The outcomes of this analysis lead to the identification of sub-systems and parts as the basis for detailed design, clarifying the SoI architecture. Consequently, each element belonging to TMS shall be sized and analyzed by re-applying the proposed process.

4 Conclusions

The present paper reports a possible innovative approach to support the designing process alongside context, definition, analysis, and development of a complex system, taking into account the System Engineering approach and SysML as representing language. A particular focus is given to Parametric Analysis as a frame for sizing functions development and Validation Criteria connected to Stakeholder Requirements for designing process support. Indeed, Parametric Analysis and Validation criteria represent the starting point for the implementation of a system during the designing stage and certificate that the system meets the requirements at the upper level. The advantages of this approach are the management of requirements and traceability for a quick and precise implementation whenever a change occurs.