2.1 Agile systems engineering

Systems engineering is an interdisciplinary activity that focuses more on system properties than on specific technologies and has the overall goal of producing optimised systems to meet potentially complex needs. Although there are many ways in which to define systems engineering, the following suffices:

• Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system. (Eisner, 2008(¹⁰); INCOSE, 2015(¹¹))

  Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect. (FAA⁽¹²⁾, 2006)

Systems engineering has a broad, more holistic view than what may be called “specialty engineering^{(Reference Eisner10)}”, that usually focus more on the specific development of a particular component or item or is involved with a specific discipline, for instance, aerodynamics or structures. The system engineering process is used when it is necessary to define and allocate requirements to specific engineering disciplines, and in general, it should specify the design or technologies only at a high level. Hence, one of the responsibilities of a system engineer is to define systems architecture by performing trade studies to evaluate alternative system architecture, in which system requirements are detailed from a black box perspective. In the aeronautical context, trade-studies should be quantified in terms of figures of merit (FoMs) or measures of effectiveness (MOEs).

Agile systems engineering has two main goals. The first is to improve the process of developing specifications that can provide technical orientation to specialty engineering in order to develop systems that satisfy requirements and meets customer’s needs. The second main goal of an agile project is to enable follow-on systems development^{(Reference Douglass9)}. In Agile methods, the system is constructed incrementally, and at the end of each iteration, the developing system is ready to be verified for some requirements^{(Reference Douglass9)}. Thus, validation and/or verification process is applied at the end of each iteration to guarantee that the evolving system meets the requirements. As mentioned in the introduction, to support the statements of the manifesto, the Agile alliance give a set of 12 principles. Douglass^{(Reference Douglass9)} restates the 12 Agile principles^{(Reference Alliance4)} for systems engineering in the following manner:

• Principle 1 Our highest priority is to satisfy the customer through early and continuous delivery of specifications and systems that demonstrably meet their needs.

  Principle 2 Welcome changing requirements even late in development. Agile processes harness change for the customer‘s competitive advantage.

  Principle 3 Deliver verified systems engineering work products frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale.

  Principle 4 Business people and systems engineers must work together daily throughout the project.

  Principle 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  Principle 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation or work products that execute (or simulate).

  Principle 7 Verified engineering data are the primary measure of progress.

  Principle 8 Agile processes promote sustainable development. The sponsors, engineers, and users should be able to maintain a constant pace indefinitely.

  Principle 9 Continuous attention to technical excellence and good design enhances agility.

  Principle 10 Simplicity – the art of maximizing the amount of work not done – is essential.

  Principle 11 The best architectures, requirements and designs emerge from self-organizing teams.

  Principle 12 At the regular intervals, the team reflects on how to become more effective, then tunes and adjust its behavior accordingly.

Differentiating between iterative development and Agile development is important. Iterative development works by dividing problems and tasks into smaller ones, but not in an incremental way^{(Reference Larman13)}. In this sense, iterative development essentially requires a perfectly elaborated idea and solution, as well as an accurate time estimate, in order to develop the right product according to plan. Like Agile, it acknowledges that rework is routinely required in projects, but manages it by merely making the project tasks cyclical to take into account the necessary improvements and changes. However, unlike iterative development, Agile emphasises responding to change due to the unpredictable nature of projects by being both iterative and incremental^{(Reference Douglass9)}. Hence, Agile not only repeats the cyclical aspects of a project but also continuously modifies them by the assumption that the learning done continuously throughout the process. In this way, it encourages a feedback loop to integrate new requirements, new design experience and information, even late into the process.

The incremental, spiral life cycle developed in this work is shown in Fig. 1. The project initiates by the capturing of stakeholder requirements and by decomposing the expected functionality. Following the functional analysis, requirement analysis is realised. Then, it is possible to define the logical architecture which is done by establishing a hierarchy within the system and by allocating requirements to its corresponding functions. Based on the logical architecture, initial architectures are proposed. These are analysed and new candidate architectures are synthesised in order to fit the desired functionality and its requirements. The candidate architectures are evaluated with Figures of Merit (FoMs) or against technical performance measures (TPMs), and the best one is selected. The proposed architecture is validated accordingly, and the overall system is verified. The cycle proceeds in spiral meaning that each subsystem and its components, if necessary, are developed in the same incremental way. The process is iterative, and at each cycle requirements, functionality and system elements are continually updated to reflect the newly available information. This incremental development is essentially the same that one typically follows when designing by first principles, see Section 3.1.

Figure 1. Agile system engineering process for aircraft conceptual design.

One common objection to the Agile development philosophy, in general, is that incremental development does not work very well with mechanical and electrical hardware, because of real-world physical constraints and associated long lead times to create physical parts. While this is certainly true for detail design, in conceptual design, this can be mitigated by the object-oriented^{(Reference Borutzky14)} use of modelling and simulation via bond graphs, see Section 3.2 and the Appendix. This characteristic makes bond graphs ideal for initial modelling and system architecting and complements the approach followed in AMBSE.

The methodology proposed here applies to conceptual design and to the same extend to preliminary design as defined by the Aerospace Recommended Practice (ARP), Guidelines For Development Of Civil Aircraft and Systems, ARP-4754A⁽¹⁵⁾ standard. As mentioned in the introduction, the fundamental insight that makes AMBSE possible is that verifiable executable models are necessary for Agile development. In this work, the top-level executable model is realised in Simulink by a six-degree-of-freedom non-linear model (see Appendix A) and the related systems (Section 4.5) in the corresponding model blocks embedded in the same model. The model dependency makes possible to validate performance requirements sequentially from top-level down to the lower levels.

2.2 Model-Based Systems Engineering (MBSE)

Blanchard^{(Reference Blanchard and Fabrycky16)} defines Model-Based Systems Engineering (MBSE) as the formalised application of graphical modelling to support system engineering activities beginning in the conceptual design and continuing throughout the entire life cycle. MBSE supports and enhances the ability to conduct system engineering tasks such as requirements capturing, design, analysis, validation and verification, resulting in the following benefits^{(Reference Blanchard and Fabrycky16)} among others:

• Improved communication among development stakeholders

• Increased ability to manage complexity

• Improved analysis of the impact of changes

• Enhanced knowledge capture and reuse of information

MBSE is often contrasted with a traditional textual-based approach to systems engineering (SE). In MBSE, the primary artefact of the system engineering process is the system model. On the other hand, in a textual-based system engineering approach, there is often considerable information generated about the system contained in textual documents. This information is often difficult to maintain and to assess in terms of its quality. In the MBSE paradigm, much of this information is captured in a system model as Fig. 2 shows.

Figure 2. Transition from SE to MBSE.

2.3 Object-oriented systems engineering method (OOSEM)

The Object-Oriented Systems Engineering Method (OOSEM) is a MBSE method that leverages object-oriented concepts and adopts SysML to facilitate the capture and analysis of requirements and design information to specify complex systems^{(Reference Friedenthal, Moore and Steiner17)}. OOSEM is usually applied recursively and interactively at each level of the system hierarchy, and it employs a top-down approach to specifying, analysing, verifying, design and development. In the Agile development philosophy, the system is incrementally constructed at each iteration, and OOSEM provides the flexibility to accommodate changing requirements and design evolution, making it an ideal method for this work, as long as it is tailored for Agile, as the INCOSE handbook^{(Reference Shortell11)} remarks.

2.4 Systems modelling language (SysML)

The Systems Modelling Language⁽¹⁸⁾ (SysML) from the Object Management Group (OMG) has emerged from the Unified Modeling Language⁽¹⁹⁾ (UML), the de facto standard for modelling in software engineering. Friedenthal^{(Reference Friedenthal, Moore and Steiner17)} defines SysML as a general-purpose modelling language for systems engineering applications that supports the specification, analysis, design, validation and verification of systems and systems-of-systems. Each diagram is designed to represent a single aspect of the system of interest. The usage of each SysML diagram is briefly described as follows:

• The behavioural aspect of the system is modelled using one or more of the following diagrams:

  • – Activity diagram (act) represents the workflow or a series of input to outputs relations of stepwise actions.

  • – Sequence diagrams (sd) describes interactions in terms of exchange messages between parts of the system in a time-wise fashion.

  • – State machine diagram (stm) describes the states of a system and its parts, and the events that trigger transitions between states.

  • – Use case diagrams (ucd) are used to describe the system functionalities and its relations to users and external agents.

• Requirement diagram (req) captures text-based requirements and provides ease traceability between requirements, supporting the design, analysis and verification of elements in the model.

• The system structure is modelled using block diagrams, which are divided into two types:

  • – Block definition diagram (bdd) shows how different elements are classified and describes the system hierarchy by decomposing the system in its elements.

  • – Internal block diagram (ibd) describes the relations between parts within the system and how they are interconnected.

• The model is organised in packages on a package diagram (pkg). Each package may contain other elements, facilitating reuse and model navigation.

• A parameter diagram (par) is used to impose constraints, such as mass, reliability and performance properties, among others, on the system, supporting engineering analysis.

SysML models systems aspects that may be classified into three groups: the behavioural aspect, its structure and its requirements, as shown in Fig. 3. The expression “SysML Taxonomy” in Fig. 3 denotes how the different types of diagrams are organised. Also, the reader is referred to Friedenthal^{(Reference Friedenthal, Moore and Steiner17)} and to the SysML formal specifications⁽¹⁸⁾ for a comprehensive reference on SysML.

Figure 3. Taxonomy of SysML.

3.1 The engineering design method

The engineering design method is characterised by its iterative nature, in which the processes of analysis and synthesis are alternated until a feasible solution is found. In general, a solution is found when the proposed solution satisfies the requirements that are usually laid down in advance and continuously updated during the development cycle, as more information becomes available. The term “analysis” means in Greek “decompose into parts”. It is used in system engineering when applying principles or methods, usually mathematical, to problems or systems. Synthesis literally means “union, junction of parts”. It designates the act of bringing together related information to fit a technical purpose. The design progresses by the creation of hypothesis and conjectures in a process that is not necessary and sufficiently logical. This apparent deviation from the Scientific Method is necessary to solve any problem of practical nature by the deliberately use of heuristics. The term heuristics was used by Koen^{(Reference Koen21)} in his studies on the Engineering Method to designate the way in which design engineers develop systems and products. Koen^{(Reference Koen22)}, defines heuristics in a very broad way as everything that helps to solve a problem, bringing it closer to its solution. In this sense, ansatz and ad hoc hypothesis are legitimate, as long as they are passive of validation, in the system engineering sense, specialty in the conceptual design, where data is often scarce. Among the most common heuristics, the following are particularly useful and formalised in System Engineering practice:

• At the appropriate time, freeze the design

• Allocate resources appropriate to the needs of each design phase

• Allocate the necessary resources to the weakest link, in most cases, this heuristic can be replaced simply by analysing the worst case

• Solve problems by successive approximations

In addition to that, one can infer that the sound practice of First Principles Design, using well-established theoretical results such as those found in Schlichting^{(Reference Schlichting and Truckenbrodt23)}, Ashley & Landhal^{(Reference Ashley and Landahl24)}, Kuethe^{(Reference Kuethe and Chow25)}, Kuchemann^{(Reference Kuchemann26)}, Hoerner^{(Reference Hoerner27, Reference Hoerner and Borst28)}, must be under consideration and fully integrated with the MBSE practice.

3.2 Unified mathematical modeling via bond graphs

Kypuros^{(Reference Kypuros29)} describes bond graphs (BGs) as a graphical approach for diagramming the distribution and flow of power and energy within a dynamic system. Diston^{(Reference Diston30)} made the first use of bond graphs in aircraft systems modelling. BGs were developed in 1959 by Dr Henry M. Paynter^{(Reference Paynter31)} at MIT are used for modelling the storage, dissipation, transferring and transformation of energy within a dynamic system. In this modelling formalism, power, the rate of energy transfer between components, is taken as a fundamental quantity of physical systems and treated in the generalised form of a flow (f) and an effort (e). Since power is the “universal currency” of physical systems^{(Reference Gawthrop and Bevan32)}, bond graphing is, in fact, a unified multi-domain modelling approach. The graphical nature of bond graphs separates the system structure from the equations, making bond graphs ideal for visualising the essential characteristics of a system. In BGs, components energy ports are connected by bonds that specify the transfer of energy between system components^{(Reference Gawthrop and Bevan32)}. Moreover, the structure itself of the bond graph is designed to facilitate the systematic derivation of differential equations governing the dynamic response of the system model. Thus, bond graphs may be used not only to perform straightforward numerical analysis but to gain qualitative insight^{(Reference Gawthrop and Bevan32)}. The Appendix contains an introduction to bond graph modelling.

3.3 Overview of ARP-4754A

The document ARP-4754A⁽¹⁵⁾ provides guidelines for the development cycle of aircraft systems, for the planning of the development process and guidelines for showing compliances with regulations. In general, aircraft systems show a high degree of interaction between systems. Thus, they have many modes of failure that affect the safety of the aircraft. ARP-4754A provides a methodology to mitigate development errors and provide a guideline for assigning the adequate assurance level that errors in the development cycle have been identified and corrected.

The typical system development progresses iteratively and concurrently using both top-down and bottom-up strategies. The top-down sequence prescribed in ARP 4754A for developing a system from intended function not only provides a conceptual model for system development but mirrors the AMBSE process tailored for aircraft design in this work. As part of this process, the system architecture evolves establishing the structure and boundaries within which specific item design is implemented to meet of the established safety and technical performance requirements⁽¹⁵⁾. Moreover, the development planning guideline recognises and highlights the iterative nature of the design activity and the presence of interrelationships such as feedback loops during the development process. In practice, system architecture development and the allocation of requirements are tightly-coupled, where many candidate architectures are then evaluated using functional and performance analyses that establish feasibility in meeting the function and top-level safety requirements assigned to the system. With each iteration cycle, the identification and understanding of the requirements increases and the allocation of the system-level requirements to hardware or software items become clearer.

According to ARP-4754A, safety requirements are functionally decomposed from aircraft level to the item level in a hierarchical structure. The ARP-4754A guideline provides a rationale for development assurance level assignments considering the system complexity, and safety criticality embed in the system architecture. The Development Assurance Level assignment process begins with the Functional Development Assurance level (FDAL) assignment to the functions involved in the aircraft’s and/or systems’ functional hazard assessment (FHA) top-level failure conditions. An FDAL is assigned to the top-level function, based on its most severe top-evel failure condition classification under Table 1. In summary, AMBSE can support the process described in ARP-4754A from aircraft to item level by aligning checkpoints and reviews with program phases.

Table 1 Top-level function FDAL assignment

^a SAE ARP-4754A⁽¹⁵⁾

3.4 Overview of ARP-4761

The document Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment (ARP-4761⁽³³⁾) provides guidelines and describes methods of performing the safety assessment of civil aircraft. These methods summarised in Table 2 are qualitative and can be qualitative⁽³³⁾ provide a systematic way to show compliance with FAR 25.1309. The ARP-4761 techniques presuppose that a functional analysis has been done and that associated hazards have been properly addressed. The safety assessment process begins with the concept design and derives the safety requirements for it. As the design evolves, changes are made, and the modified design must be reassessed. This reassessment may create new derived design requirements, which frequently necessitate further design changes. The safety assessment process ends with the verification that the design meets the safety requirements⁽³³⁾.

Table 2 Safety assessment techniques

^a SAE ARP-4761⁽³³⁾

At the beginning of the development cycle, according to ARP-4761, it is convenient to identify and classify the failure condition(s) associated with the aircraft functions and combinations of aircraft functions. This is done with a functional hazard assessment (FHA) technique at the beginning of the development cycle. These failure conditions establish the safety objectives. After aircraft functions have been allocated to systems by the design processes, each system which integrates multiple aircraft functions should be re-examined using the FHA processes. The starting point of the Preliminary System Safety Assessment (PSSA) is the output of FHA. The PSSA is a systematic examination of the proposed system architecture(s) that is conducted at multiple stages of the system to determine how failures can cause the functional hazards identified by the FHA. The PSSA should also establish protective strategies and architectural features necessary to meet safety objectives. The result of the PSSA is intended to identify hardware failure effects, development error effects or hardware and software, reliability budget, and development assurance levels.

AMBSE benefits from the use of ARP-4754A and ARP-4761 practices (see Fig. 1), since these technical standards imposes design discipline and development structure, ensuring that both operational and safety requirements are fully realized and substantiated. Also, AMBSE facilitates the use of these practices by providing a design environment where requirements and solutions evolve by small verifiable increments through collaboration between self-organizing cross-functional teams and end users.

4.1 Design methods & tools

The AMBSE process described in Section 2.1 and shown in Fig. 1 is represented as a SysML activity diagram in Fig. 4. The activity box inside the diagram describes the system engineering activities. After the specific system/subsystem architecture is analysed/synthesised, it is compared with alternative proposals. Once a candidate architecture is considered sufficient mature for the present purposes, it is passed to Integrated Product Development Teams (IPDTs) for preliminary design. The standards ARP-4754A and ARP-4761 are used to requirements generation during the entire process.

Figure 4. AMBSE delivery process during conceptual design phase.

AMBSE requires an integrated development environment (IDE). In this work, Eclipse⁽³⁵⁾ Papyrus⁽³⁶⁾ was chosen because it is open-source, offers UML/SysML modelling capabilities and it contains an extensible plug-in system for customising the environment. In particular, Papyrus was augmented with Massif⁽³⁷⁾ and Epsilon⁽³⁸⁾ plug-ins, allowing to transfer SysML activity diagrams to subsystem blocks in the Simulink environment. Engineering analysis necessitates the creation of dynamic models. As mentioned in Section 3.2, the use of the object-oriented paradigm with bond graph modelling can facilitate the process of deriving the necessary differential equations. The software 20-sim⁽³⁹⁾ was used in this work to model systems with the bond graph formalism and also to generate the respective s-functions, which can promptly be used in a Simulink model with great numerical computational performance.

Microsoft^© Excel^™ is used as a technical calculation and report creation tool, since it is nearly universally used across the world and because its negative aspects can be managed. All of the spreadsheets, conforming to the same format and layout. The traditional design approach as in Roskam^{(Reference Roskam40)}, Nicolai^{(Reference Nicolai and Carichner41)}, Datcom^{(Reference Hoak and Ellison42)}, Kuchemann^{(Reference Kuchemann26)}, Dubbel^{(Reference Dubbel and Davies43)} and Hoerner^{(Reference Hoerner27, Reference Hoerner and Borst28)} was implemented in a spreadsheet customised with XL-Viking⁽⁴⁴⁾ plug-in. Most of the spreadsheets use the XL-Viking Add-in to display and audit the calculations. The XL-Viking add-in contains easy to use functions that show all the numbers or variables in each Excel formula. This ensures accuracy and traceability of the calculations, allowing significant and valuable time is saved in checking and auditing of calculations while keeping all of the calculations live and writing and updating reports is much quicker and easier. This feature also facilitates the use of conceptual development and design-related analytical tools (such as risk assessment matrix and sensitivity analysis), described in Goldberg et al^{(Reference Goldberg, Everhart, Stevens, Babbitt III, Clemens and Stout45)}. This spreadsheet approach allows Python scripting through XL-Wings⁽⁴⁶⁾ plug-in to facilitate the data transferring to the Simulink environment and to generate input to the SUAVE conceptual level aircraft design environment. The design environment SUAVE^{(Reference MacDonald, Clarke, Botero, Vegh and Alonso47)} was used to both aerodynamic and performance analyses. The plug-in gendoc⁽⁴⁸⁾ is used in the Eclipse environment to generate word files containing the corresponding diagrams. Recurrent engineering calculations were also inserted in the generated documents.

Model Organisation

A fundamental step previous to initiating the modelling process is to establish modelling conventions and standards. The OOSEM method prescribes how to organise the model using a package structure. The package diagram in Fig. 5 describes the model organisation adopted. The model organisation is a hierarchical package structure that mirrors the system hierarchy in terms of system, element, and component levels. Each of the packages contains model elements for the next level of decomposition of the block, including its structure and behaviour that are created by applying OOSEM to the specification and design of the system. The model organisation also includes other packages that are not nested within the system hierarchy packages. These packages contain their own hierarchy consisting of nested packages, which may not correspond directly to the system hierarchy. However, both are linked in order to ease the navigation of the model by the use of hyperlinks a to the diagrams of interest. In this way, it is possible for a designer to keep the design, for instance, of the flight control system without losing sight of the overall hierarchical structure which numbered according to the Joint Aircraft System/Component^{(Reference Monroney49)} (JASC) code system.

Figure 5. Model organisation.

4.2 System requirements analysis

The AMBSE approach was applied in the design of a hypothetical aircraft designated as Kr-206 which is intended to provide ways to test and develop advanced design techniques and methodologies. In particular, supersonic transport (SST) aircraft design demands special attention to the flight control system, where many factors differ significantly from subsonic aircraft. Some of these factors are related to the following: Handling qualities, control surfaces layout, artificial stability augmentation, actuator technologies and sensitivity to engine placement. Most of the stakeholder requirements were inferred from technical literature^{(Reference Wolf50–Reference Smith52)}, except the range requirements, and are shown in Table 3. The reason for such a low range requirement for a SST is explained by two facts: first, it is known that the energy in the compression wave primary depends, among other things, on the speed of the aircraft, the physical size & the weight of the aircraft. It was then reasoned that a first prototype conceptual aircraft ideally should be the smallest as possible. A compromise between market, technical and research requirements was found to to be 2200 nautical miles. AMBSE supports requirement management through the use of SysML requirement diagrams. Since one of the desired outcomes of the AMBSE is to facilitate change of requirements, the aircraft will eventually be redesigned for 4200 nm with an improved set of market and stakeholder requirements. It is worthwhile to mention that the data contained in this work have illustrative purposes and therefore should not be used as a basis for other designs. The hypothetical aircraft is to be certified under FAR Part 25⁽¹²⁾/EASA CS-25⁽⁵³⁾ and is also subject to noise requirements.

Table 3 Request for proposal - supersonic Jet

The regulation FAA Part 25/EASA CS-25 does not establishes flying qualities criteria. However, the document flight control design best practices⁽⁵⁴⁾ recommends that the MIL-F-8785C^{(Reference Moorhouse and Woodcock55)} should be followed as a guide for the flying qualities criteria. The Table 4 shows a partial list of the requirements gathered from both Part 25/CS-25 and MIL-F-8785C.

Table 4 Partial list of longitudinal flying qualities requirements

4.3 Functional analysis

The purpose of this activity in the systems engineering process is to iteratively identify the functions that the system must perform. Functional analysis is essential to the application of ARP-4754A/ARP-4761 standards, because of that in the methodology followed in this work, it is given a specific phase in the process. This activity establishes basic aircraft level performance, and operational requirements, which is accomplished by arranging the functions into logical sequences, decomposing top-level functions into lower-level functions, and allocating performance requirements generated from the higher-level functions in the hierarchy to the lower-level ones. The output of this process is the functional architecture of the system, that is, a description of the system, regarding its functionality. According to ARP-4754A⁽¹⁵⁾, the output of this activity is a list of aircraft level functions and associated function requirements and interfaces for these functions. In AMBSE, it is a diagram as shown in Fig. 6.

Figure 6. Top-level functional analysis.

4.4 Logical architecture definition

The logical architecture establishes the structure and boundaries within which specific system design are implemented to meet all of the established safety and technical requirements. In practice, this the logical architecture definition phase, requirement and analysis functional and the allocation of requirements are tightly coupled iteratively processes. Since functional and performance requirements originate at the highest levels of the system hierarchy, these activities must be continuously repeated to define the logical architecture at ever greater levels of detail. This process generates many types of requirements which include: independence, probabilistic, qualitative, availability, integrity, monitoring, operational and maintenance requirements and in later iterations Function Development Assurance Level (FDAL). Moreover, ARP4754A⁽¹⁵⁾ states that the hierarchical safety requirements are generated by safety analyses by functionally decomposing from aircraft level function to the item level. In this process, it is convenient to add a SysML stereotype to each requirement marking its type.

At the aircraft level, the safety requirements are generated from the aircraft FHA based on top-level aircraft functions previously defined, as in 4.3. At the system level, the safety requirements are all those system level requirements generated from the system FHA which are decompositions of the aircraft level safety requirements. At the next level down the requirements are all those aspects of the system which allow the safety objectives associated with the system FHA classifications to be satisfied. The output of this process generates many elements which need to be organised via SysML packages. In addition to that, the present work adopted the JASC^{(Reference Monroney49)} code tables, as shown in Fig. 7. The JASC numbering provides a consistent framework for the aircraft technical documents. At the item (component and subcomponent) level, S1000D⁽⁵⁶⁾ were used. It is worth mentioning that each block in Fig. 7 contains a hyperlink to another block diagram describing its respective hierarchy.

Figure 7. Logical decomposition with JASC code.

The process of allocating requirement to functions is initially performed by use case diagrams (ucd) (see Figs. 8 and 9). The requirements were gathered in the requirement analysis activity and were decompose into smaller, more manageable requirements, using requirement diagrams (not shown). These requirements are then allocated to the top-level functions identified in the functional analysis (Section 4.3) activity.

Figure 8. Use case diagram allocating requirements to the function Provide Stability.

Figure 9. Use case diagram allocating requirements to the function Perform Flight Control.

The function “provide stability & control” in Fig. 8 is the most top-level aircraft function related to the stability and control of the aircraft. Each requirement element contains a hyperlink to the corresponding requirement packages, where requirements are organized in a hierarchy according to its type.

The function “Perform Flight Control”, in Fig. 9, is associated with the flight control system (FCS). The FCS contains interfaces to many systems, for instance, the hydraulic and the electric power system. Moreover, in this specific project, it was detected that the supersonic longitudinal stability depends greatly on the center of gravity. Therefore, it is necessary to include a interface to the fuel system, as well. In order to facilitate the design process while managing all the mentioned systems, it was necessary to create a System Breakdown Structure (SBS) diagram (not shown). Essentially, the SBS contains elements typically associated with different JASC numbers. In the AMBSE approach, the SBS is connected to the system logical architecture by hyperlinks, allowing the designer to focus on the particular system design of interest.

4.5 Architecture synthesis and analysis

The activity architecture synthesis and analysis comprises the allocation of functionality and corresponding different kinds of requirements to high-level physical elements. Ideally, more than one candidate system architecture should be considered in this activity. These candidate architectures are then iteratively evaluated using functional and performance analysis, which generate Figures of merit (FoMs) or technical performance measurements (TPMs) that are to be used in the architecture trade-off phase. In later iterations, when the candidate architecture contains sufficient detail, it is possible to apply preliminary phase ARP-4761⁽³³⁾ Preliminary Aircraft Safety Assessment (PASA)/Preliminary System Safety Assessment (PSSA) processes to establish the feasibility in meeting aircraft and functionality and top-level safety requirements assigned to the system.

System Level

In the conceptual design, it was decided that the aircraft shall not have a horizontal stabiliser in order to improve its aerodynamic performance. Thus it requires a fly-by-wire system to augment its longitudinal stability characteristics. Ideally, an optimal system architecture was developed that would meet regulatory compliance for system safety^{(15, 33)} given constraints such as cost, weight, envelope, and complexity. For the present purposes, the primary driver considered in the conceptual design phase of the fly-by-wire system is the system safety. The design options normally include duplex, triplex, quadruplex control channel redundancy and various combinations of electrical, mechanical, or hydraulic connections. The safety analysis tools used are those prescribed in the System engineering toolbox for design-oriented engineers ^{(Reference Goldberg, Everhart, Stevens, Babbitt III, Clemens and Stout45)} and in the ARP guidelines, namely, the Functional Hazard Assessment (FHA) and Fault Tree Analysis (FTA) (see Sections 3.3 and 3.4). It is worthwhile mentioning that the FHA is a living document throughout the design development cycle⁽³³⁾, which is also desirable for the AMBSE.

The design usually starts with the functional analysis described in Section 4.3. Then, the designer/analyst must begin with an undesired top level hazard event, classified according to Table 1, and systematically determines all faults and failure combinations of the system functional blocks up to the next lower level in the system hierarchy, which could lead to this event. In the conceptual design, often it is possible to omit some items or components which are considered non-essential for the analysis purposes. In this work, for instance, it was assumed that the reliability of mechanical components is high enough to be omitted in the first FTA analysis of the FCS. For illustrating purposes, the function “Control Pitch” in Fig. 4.3 is chosen for the FHA/FTA process and defined in Table 5.

Table 5 Definition of the Pitch attitude control function

For illustrating purposes, two different initial architectures are proposed for the FCS consisting of Flight Control Computer (FCC) electrical lanes that interface with Electro-Hydrostatic Actuators (EHA) located on the outer and inner sections of the wing. The system concept designs evaluated involved traditional and hybrid architectural schemes for functional redundancy and operation. Both architectures share the same philosophy in which all primary flight control surfaces are all electrically controlled and hydraulic activated – the FCS interfaces with hydraulic and electrical systems. The actuators are powered by the aircraft blue, green and yellow hydraulic lines. Four elevons control the nose up and down movement. The safety objective that both architectures are to be measured against is that the probability for a catastrophic event⁽¹⁵⁾ shall be less than $ 1\times10^{-9} $ (see Table 1). Table 6 contains an initial Functional hazard Analysis (FHA) for the pitch control function.

Table 6 partial list of FHA results for the function pitch rolling attitude control

The first architecture proposed is denominated Tri-Tri and consists of four electrohydrostatic actuators (EHA) and four electrically signaled hydraulic actuators fed by two of three independent hydraulic systems and controlled through three (tri) independent electrical systems that communicates through three (tri) electrical control lanes partitioned among four different FCCs. Each hydraulic system (Blue/Green/Yellow) is associated with three electrical lanes. In this architecture FCC #1 and FCC #2 are dedicated to the hydraulic system Blue, while FCC #3 and FCC #4 are dedicated to hydraulic system Green. This architecture has the disadvantage that if one FCC fails, the system only two faults away from a catastrophic hazard. In this scenario, the other FCC on the same hydraulic system may fail together with the backup hydraulic system.

The second architecture proposed is denominated Dual-Quad and consists of four electrohydrostatic actuators (EHA) and four electrically signaled hydraulic actuators also fed by two independent hydraulic systems. The flight control surfaces are powered by a combination of hydraulic and electro-hydrostatic actuators. For each elevon system there are two (dual) independent electrical systems communicating through four (quad) electrical lanes. It is assumed that the FCS possess by three primary computers and two secondary computers that process pilots and autopilots inputs according to normal, alternate or direct flight control laws.

The FHA is the input for the Fault Tree Analysis (FTA) (Fig. 10), along with the assumed probability of loss used in the FTA process are shown in Table 7. As mentioned in Section 3.4, both are required by ARP4754A⁽¹⁵⁾. Also, the probability of loss for mechanical and electrical components can be found in Dhillon^{(Reference Dhillon58)}, MIL-HDBK-217F⁽⁵⁹⁾, and Schafer^{(Reference Schafer, Angus, Finkelstein, Yerasi and Fulton60)}.

Figure 10. Initial fault tree analysis for the FCS.

Table 7 Assumed probability of loss

All failure rate probabilities are per flight hour

These figures are for illustrative purposes only

The results for the FTA realised for both architectures, Tri-Tri and Dual-Quad are in Table 8. Figure 10 shows the FTA diagram used to estimate the Loss of Function (LOF) and Failure to Dispatch (FTD) probability. Both candidate-architectures satisfy the ARP 4754A requirements for the probability of a catastrophic event to be be less than $ 1\times10^{-9} $. As Table 8 shows, the architecture Tri-Tri is taken as the baseline for the weight and cost criteria, which were estimated according to Roskam^{(Reference Roskam40)} and Nicolai^{(Reference Nicolai and Carichner41)}.

Table 8 Fault tree analysis for the FCS architectures

These figures are for illustrative purposes only

At this point, it is desirable to use a multicriteria analysis employing a pairwise comparison process, in that way, it is possible to compare options and factors in a relative manner. In this work, the Analytical Hierarchy Process^{(Reference Goldberg, Everhart, Stevens, Babbitt III, Clemens and Stout45)} (AHP) was chosen in the selection of the best architecture for the present conceptual purposes. The results are shown in Table 9 (see also Appendix C). This approach combines the subjective with the rationale assessment of each of the proposed alternatives. The architecture Dual-Quad scored higher than the Tri-Tri architecture and thus it was selected for further development.

Table 9 Trade-off for the FCS initial architecture

The selected architecture schematics shown in Fig. 11. From it, it is possible to consistently derive its corresponding bond graph by substituting each identified system by a word bond graph. A SysML block definition diagram is drawn to represent its structure and interfaces with associated functions and requirements. Each element, represented by an word bond graph, in the architecture is then modelled as a bond graph using the software 20-Sim⁽³⁹⁾. This software is capable of exporting the bond graph model and its sub-models as s-functions, which can readily be integrated into the Simulink model and runs faster than native Simulink blocks.

Figure 11. Proposed initial flight control system architecture.

The same safety process used in the conceptual development of the FCS was repeated for the fuel system. Figure 12 shows the selected architecture for the fuel system in the conceptual design. It was designed to provide data for the total fuel volume required, the size, location and number of fuel tanks needed and the number of fuel pumps, its location and the required capacity of fuel pumps and fuel lines. The engine fuel flow was obtained in this stage by multiplying the maximum required thrust by the associated fuel consumption. Although it is reasonable to assume that the number of tanks in order to keep the cost to a minimum and reduce weight, in this work, the size, location and number of tanks were driven by stability requirements concerning the desired location of Center of Gravity for different loading scenarios. The sizing of fuel lines and the determination of necessary fuel pump pressures were calculates using Marks’ Standard Handbook for Mechanical Engineers^{(Reference Avallone, Baumeister and Sadegh61)}. The simple schematics in Fig. 12 along with first principle calculations was sufficient to generate a bond graph representation, which was included in the Simulink model as an s-function.

Figure 12. Proposed initial fuel system architecture.

Component Level

As shown in Fig. 11, the selected FCS architecture employs four Electro-Hydrostatic Actuator (EHA) and three Electro-backup-Hydraulic Actuator (EBHA). The design of an EHA (see Fig. 13) requires multi-domain modelling capability since on it mechanical, hydraulic, thermal and electrical domains interact with each other. Therefore, bond graphs are an ideal tool for modelling such components. In this work, for conceptual design purposes, the following EHA components (or subcomponents) are considered: Electrical motor, hydraulic pump, accumulator, associated hydraulics (two valves and a bypass valve), hydraulic cylinder, the mechanical actuation (four-bar mechanism) and control surface.

Figure 13. EHA schematics.

Following Langlois et al^{(Reference Langlois, Roboam, Maré, Piquet and Gandanegara62)}, the EHA system comprises an electrical, a mechanical and a hydraulic part. The electrical part of the EHA is a servo-valve which controls the fluid dynamics inside the chambers. The spool valve is driven by the electrical input current of a torque motor. It is assumed that the EHA is supplied with a constant DC voltage source. In practice, the EHA is fed with a three-phase AC power that supplies power drive electronics, which in turn, drive a variable speed pump together with a constant displacement hydraulic pump^{(Reference Moir and Seabridge63)}.

Figure 14 shows the initial SysML diagram for the EHA schematics in the Fig. 13. It consists of a block definition diagram (bdd), where requirements are allocated to each block, representing physical components.

Figure 14. Initial SysML diagram of EHA.

As briefly mentioned in the Section 2.1, BGs may be used in an object-oriented^{(Reference Borutzky14)} way, which also provides a means for the straightforward conversion of the bdd (Fig. 14) into a word bond graph. Figure 15 shows the word bond graph, created in the software 20-sim⁽³⁹⁾, based on the schematics of the EHA shown in Fig. 13. Each word bond graph is further modelled separately and then integrated into one bond graph, which will be exported as an s-function.

Figure 15. word bond graph for the elevon-actuator assembly.

In this way, BGs facilitates the integration of components, for instance, the elevon. At this stage, the elevon can be modelled by a second-order mechanical equation, which corresponds in the Bond Graph formalism to a 1-junction connected to -R, -I and -C elements. Its physical connection with the EHA is modelled by a transformations element, in this case, a transformer (TF) element. The resulting bond graph with the integration of the control surface (elevon) is shown in Fig. 16.

Figure 16. Integration of the control surface with the EHA.

As mentioned above in this section, the solution for longitudinal instability in the supersonic regime involves both the FCS (through the use of a control law) and the fuel system (in order to transfer fuel to achieve the desired center of gravity). Both systems were modelled, and the corresponding s-functions were exported from 20-sim to be integrated into the Simulink “master-model”, depicted in a simplified way in Fig. 17.

Figure 17. Simulink master-model with fuel system and EHA.

The master-model is a six-degree-flight dynamics (see Appendix A) model describing the dynamics of the aircraft that contains every physical element previously modelled along with a control law and a manoeuvre generator. The manoeuvre generator is capable of prescribing a trajectory that the aircraft must follow. In this way, it is possible to analyse the aircraft dynamic behaviour in order to satisfy the requirements. A disadvantage of this approach is the time that is required to evaluate each requirement. However, this can be mitigated by the use of s-functions which tend to be run faster and are easily generated from BGs with the 20-sim software.

Table 10 Partial list servo-actuator specifications

Table 10 presents a partial list of servo-actuator specifications deduced from the AMBSE approach. They were generated from the complete bond graph model where its nominal parameters were calculated using standard mechanical engineering methods that were programmed into design spreadsheets. The complete list has 30 requirements, including performance and functional requirements and it is intended to complement and foster discussion with stakeholders and suppliers.

4.6 Validation and verification

Validation and verification comprise independent procedures that are used together for checking that the system meets its intended functions, its requirements and specifications. In the present work, both procedures are realised in MATLAB/Simulink in a six-degree-of-freedom flight dynamics model. A brief discussion of this model and control laws are contained in the Appendix. The requirements pilot-induced oscillations, short-period damping, short-period frequency and acceleration sensitivity (presented at Table 4) were validated and verified using the flight dynamics model in Simulink. Thus the system satisfies the short-period response. It is worthwhile to note that the terms “validation and verification” used in the conceptual design denotes a design strategy and it is not intended to mean that the system is ready for certification.

The longitudinal response to an elevon step command for the non-augmented aircraft is shown in Fig. 18. It must be noted that without augmentation the aircraft is inherently unstable in the longitudinal mode. The longitudinal behaviour of the aircraft using the dynamics inversion control law is shown in Fig. 19. Using flight control augmentation through the use of dynamic inversion control law, $ {{\omega }_{SP}} $ becomes 2.05 rad/s and the short-period damping ratio, $ {{\zeta }_{SP}} $, becomes 0.79.

Figure 18. Non-augmented longitudinal response.

Figure 19. Inversion dynamics.

The aircraft conceptual design specification at this stage is shown in Table 11 and the side and the top-view of the hypothetical aircraft Kr-206 are shown in Fig. 20. Subsequently, iterations are necessary to improve the conceptual design further. A related point to consider is the influence of the aircraft configuration on system architecting. The current AMBSE framework is not capable of determining the existing physical constrains associated with the Outer Mold Line (OML) of the aircraft under design.

Table 11 Kr-206-A specifications

^aThis values correspond to the first iterations and therefore should not be used as a basis in any design

Figure 20. Hypothetical aircraft designed using AMBSE (dimensions in feet).

4.7 Limitations of the current implementation

It should be noted that, the current AMBSE implementation has some limitations. First, there is no clearly defined baseline to compare the effectiveness of AMBSE versus the traditional approach. Because most of the advantages of Agile methods (over the more traditional approaches) rely upon the more efficient team management schemes, it is, currently, difficult to draw a satisfactory conclusion based solely on the current implementation of AMBSE. In addition to that, the design information is dispersed among different softwares, making it difficult for sharing in a more consistent way within a team. Ideally, all the design information and its requirements should be recorded in a database easily accessible by concurrent teams. Additionally, the tool-chain is not stable enough for more comprehensive design explorations.

Also, the current design work mostly relies on design data that is supplied by traditional weight estimation methods as in the conventional approaches. This adds a limiting factor to the current AMBSE framework that restricts its application to the design of conventional and more understood aircraft. During the conceptual design phase, many design interactions are performed in the OML of the given configuration under study. Another key limitation is the fact that some necessary design tools were incorporated into the AMBSE tool-chain, for instance, the computer aided design tool used to define the aircraft. Section 4.9 provides some ideas to improve future implementations of AMBSE in these aspects.

4.8 Discussion and Pros & Cons of AMBSE

The purpose of the safety assessment (SA) process is to identify and evaluate potential hazards related to the aircraft regardless of the details of its design and to establish the safety objectives for aircraft functions to achieve a safe design. AMBSE allow a smooth transition from conceptual to preliminary design because the design information captured by SysML diagrams are readily available for the SA process required by ARP-4754A and ARP-4761 during the preliminary design phase.

AMBSE facilitates advances for novel aircraft because they are characterised by the more integrated use of systems. The properties of bond graphs make possible to model multidisciplinary systems, not only EHA mentioned in the text, but also, fuel cells^{(Reference Saisset, Fontes, Turpin and Astier65, Reference Chan, Bouscayrol and Chen66)}, and jet turbine engines^{(Reference Shoureshi, Herrick and Brackney67)} in an integrated way. While standard modelling approaches have often been used in aerospace practice, bond graph modelling allows a better understanding of the interaction between the subsystems. Also, the nature of bond graphs facilitates the design exploration of the subsystem/component itself such as the EHA described in this work. In this manner, the rework that is necessary in order to satisfy requirements, especially safety requirements, usually realised in the preliminary design phase will be validated at in the conceptual design phase. In this case, the preliminary design phase will be mostly concerned with verification of safety requirements.

AMBSE has the advantage of generating better requirements. It also improves communication among development stakeholders. The design information may be captured with SysML diagrams, which increases the ability to manage the complexity within a project. These same models might be used again to enhanced knowledge capture and reuse of information. Therefore, care must be taken to ensure the consistency between models. However, as the project develops in complexity, the workload increases at each step. Also, there is the risk of focusing too early on detail and/or to exclude less understood concepts too soon. Nonetheless, this risk might be compensated by the ease with which models can be tested in AMBSE. In addition to that, the computational nature of AMBSE facilitates the creation of a model library containing validated models draw from the literature or derived through system identification^{(Reference Jategaonkar68)}.

4.9 Prospects for future research

Future research is concerned with the development of a AMBSE software tool in order to mitigate many issues pointed out in Section 4.7 and 4.8. In this tool, the design information is recorded in the Extensible Markup Language (XML), which allows many designers to access, edit and review the project in a similar way to existent software management tools such as GitHub⁽⁶⁹⁾. The fundamental idea underlying this design tool is to combine bond graph models and SysML models, leveraging the concept of object orientation. Each element in system hierarchy and its properties will be computationally represented by an object instantiated by a general class that can be manipulated through scripting at the designers will. It is a known fact, in computer science, that Category Theory^{(Reference Simmons70)} concepts are closely related to functional programming languages^{(Reference Michaelson71)}. Thus, future research will be dedicated to develop a bond graph based metamodel^{(Reference Gawthrop and Smith72)}, framed within the mathematical Category Theory^{(Reference Mabrok and Ryan73)} and coded in a functional programming language (e.g. Haskell^{(Reference Marlow74)}) in order to automate the cumbersome task of manually checking the consistency of SysML models. This metamodel suggests the possibility of the use of formal methods to each validation and verification cycle. Bond graphs possess some interesting extensions^{(Reference Margetts75, Reference Maia Neto and Goes76)}, allowing many different multidisciplinary systems to be not only modelled but tested and its global performance impact measured during the conceptual design phase. Also, it is worth mentioning that the BGs work well with optimisation^{(Reference Gawthrop77)} and sensitivity studies^{(Reference Gawthrop78)}. These characteristics possess obvious advantages to investigate novel concepts such as more-electric aircraft, more-electric engine, distributed (electric) propulsion and so on, that inherently depend on the integration of multidisciplinary systems. Therefore, future investigations will also focus on the integration of the recent advances in multidisciplinary robust optimisation into the AMBSE framework, which should also include BG optimisation, enabling the design of novel aircraft systems, where surrogate models will be used where required to provide the necessary information for the design space. It is worthwhile mentioning, in passing, that many system safety assessment techniques such as FTA used in the work are suited to be modelled by bi-graphs (directed graphs), allowing the possibility of combining modelling and simulation of components with its reliability aspects. It is expected that this technology will evolve into a new class of SoS analysis techniques suited for analysing the impact and feasibility of new technologies at the conceptual stage while enabling the system architect to navigate smoothly and continuously through the requirements, functional, logical and physical views of the evolving architecture. Lastly, future work will demonstrate the effectiveness of AMBSE by actually employing cross-functional teams interacting with customers in a realistic industrial design environment.