APPLICATION OF AGILE MODEL-BASED SYSTEMSENGINEERING IN AIRCRAFT CONCEPTUAL DESIGN

Gustavo P. KrupaFederal University of Itajubá

Keywords: Model-based systems engineering, agile, systems architecting, aircraft design

Abstract

One of the challenges of modern engineeringdesign is the amount of data that designersmust keep track while performing system anal-ysis and synthesis. This is particularly impor-tant in the design process of complex systemssuch as novel aerospace systems where Modelingand Simulation play an essential role. The Ag-ile Philosophy stems from the field of SoftwareEngineering and describes an approach to de-velopment in which requirements and solutionsgradually develop through collaboration betweenself-organizing cross-functional teams and endusers. Agile Model-Based System Engineering(AMBSE) is the application of the Agile Philos-ophy to Model-Based System Engineering. Inthis paper, AMBSE is accomplished through theapplication of the Object-Oriented System En-gineering Method (OOSEM). OOSEM employsa top-down scenario-driven process that adoptsSystem Modeling Language (SysML) and lever-ages the object-oriented paradigm to support theanalysis, specification, design, and verification ofsystems. AMBSE assisted by mathematical mod-eling and safety assessment techniques, is ap-plied to the first design iterations of the main air-craft systems, allowing a comprehensive designexploration. The flight control system was cho-sen to illustrate the procedure in detail, empha-sizing the synthesis of a six degrees-of-freedommodel augmented by dynamic inversion controlfor a hypothetical supersonic transport aircraftsatisfying class II MIL-F-8785C handling qual-ities. It is concluded that Agile Model-Based En-

gineering improves the early aircraft design pro-cess, enabling a smoothly transition from con-ceptual to preliminary design and system integra-tion.

1 INTRODUCTION

Since the past century, the aerospace industry hasbeen developing and refining the conventional"tube-and-wing" airplane configuration, which isreaching the point of incremental, diminishingreturns. As a result, there is a renewed inter-est in novel/unconventional aircraft systems thatmust be designed in a cost effective and timelymanner, subjected to stringent regulations. Yet,new aircraft systems must be designed to oper-ate in a complex, evolving and broadly-definedworld [1], in which requirements and capabili-ties often change during the aircraft life cycle. Itis widely recognized that over 70% of the designfeatures that drive life cycle cost are selected dur-ing conceptual design [2]. Under these circum-stances, it is generally difficult to define adequaterequirements that capture desired system perfor-mance and functionality without constraining thedesign into a sub-optimal design space. Sys-tems Integration is widely accepted as the basisfor improving the overall design, the efficiencyand the performance of many engineering sys-tems [3]. By adopting a unified mathematicalmodelling framework that allows efficient perfor-mance calculations throughout the system hierar-chy, it is possible to bring typically preliminarydesign activities to the conceptual phase, allow-ing a much more comprehensive design explo-

1

G P KRUPA

ration. This shifts the philosophy of engineeringdesign enabling a systematic development froman integrated system concept to an integrated sys-tem product. Ideally, this method should be sup-ported by an underling development philosophythat provides complete coverage of system func-tionality and requirements tracing. Also, an ac-curate mathematical description of a system pro-vides the design engineer with the flexibility toperform trade studies quickly and accurately, im-proving the early design process. Thus, con-tinuous change-friendly holistic approaches sup-ported by mathematical modelling are desirableinstead of specifying plain design requirementsin the pre-design phase, as usually practiced inthe 20th century.

The Agile Philosophy originates from thefield of Software Engineering and describes anapproach to development in which requirementsand solutions gradually develop through collab-oration between self-organizing cross-functionalteams and end users. This philosophy prescribesadaptive planning, early delivery, incrementalchanges and continuous improvement, while en-dorsing rapid and flexible response to change.In a sense, it resembles the ethos of the SkunkWorks approach. The original form of the Ag-ile philosophy is given in the Agile Manifesto, apublic declaration of intent released by the Ag-ile Alliance [4]. The Agile approach is given bysixteen guiding principles derived from four fun-damental statements:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

The manifesto states an emphasis, not an exclu-sion of required deliverables, i.e., the items on theleft are valued more than the items on the right.It is different from other development philoso-phies because of its emphasis on the conceptsof incremental work, dynamic planning, activeproject risk reduction, constant validation, con-tinuous integration and frequent verification. Itis interesting to note that the Agile mindset hassome parallels with the legendary Skunk works

approach, as alluded above. In Johnson’s [5]view the success of Skunk works was the con-sistent program management approach and cul-ture, which emphasizes the ability to make im-mediate decisions and put them into rapid effect,by delegating strong authority to the manager andby employing a small team of strong generalistswith system-level thinking. In his book, Johnson[5] gives the early definition of the Skunk worksapproach:

The Skunk Works is a concentration of afew good people solving problems far in ad-vance - and at a fraction of the cost - of othergroups in the aircraft industry by apply-ing the simplest, most straightforward meth-ods possible to develop and produce newprojects. All it is really is the applicationof common sense to some pretty tough prob-lems.

Johnson developed revolutionary aircraft as theP-80, F-104, U-2, C-130, and SR-71, using "14Rules & Practices [6]" that defines the SkunkWorks approach, as described in his autobiogra-phy [5]. This management approach fosters cre-ativity and innovation, and has enabled prototyp-ing and development of highly complex aircraftin relatively short time spans and at relatively lowcost. The emphasis on Individuals and interac-tions is denoted by points 2 and 3 of his rules,addressing the need to "the use of strong, butsmall project offices with 10% to 25% the sizeof the so-called normal systems". Point 5 callsfor a minimum number of reports required andpoints 8-9 calls for early and continuous verifica-tion (working software1 over comprehensive doc-umentation). Points 7, 10, 12 state the necessityof mutual trust, close cooperation and liaison on aday-to-day basis between involved parties, whichparallels the emphasis on customer collaborationby the Agile approach. While, points 1 to 4 and14 refer to the adoption of a flat organization,where lines of communication are short, makingthe responsiveness to change rapidly. Point 11 al-lude to practical earned value management and,

1mutatis mutandis, verifiable executable models, as ex-plained in section 2.1

2

Application of Agile Model-Based Systems Engineering in Aircraft Conceptual Design

lastly but not least, responding to change is al-luded by point 6.

2 AGILE MODEL-BASED SYSTEMS EN-GINEERING

The methodology used in this work relies on sev-eral disciplines and concepts namely: the Ag-ile Philosophy, Model-based system engineer-ing (MBSE, the object-oriented system engineer-ing method (OOSEM) and the System ModellingLanguage (SysML). The method in MBSE iswhat defines how the language (SysML) will beused in the context of MBSE. In order to avoidunnecessary confusion it is important to note that:

Agile is a development philosophy;MBSE is a paradigm; OOSEM is amethod and SysML is a modellinglanguage.

2.1 Agile Systems Engineering

Systems Engineering is an interdisciplinary ac-tivity that focuses more on system properties thanon specific technologies and has the overall goalof producing optimized systems to meet poten-tially complex needs. Although, there are manyways in which to define systems engineering, thefollowing suffices. Systems Engineering is an in-terdisciplinary activity that focuses more on sys-tem properties than on specific technologies andhas the overall goal of producing optimized sys-tems to meet potentially complex needs. Al-though, there are many ways in which to definesystems engineering, the following suffices.

Systems engineering is an iterative processof top-down synthesis, development, andoperation of a real-world system that sat-isfies, in a near optimal manner, the fullrange of requirements for the system. (Eis-ner, 2008 [7]; INCOSE, 2015 [8])

Systems engineering has a broad, more holis-tic view than what may be called "specialtyengineering[7]", that usually focus more on thespecific development of a particular componentor item or is involved with a specific discipline,for instance, aerodynamics or structures. The

System engineering process is used when it isnecessary to define and allocate requirements tospecific engineering disciplines, and in general itshould specify the design or technologies onlyat a high level. Hence, one of the responsi-bilities of a system engineer is to define sys-tems architecture by performing trade studies toevaluate alternative system architecture, in whichsystem requirements are detailed from a blackbox perspective. In the aeronautical context,trade-studies should be quantified in terms of fig-ures of merit (FoM) or measures of effectiveness(MOEs).

Agile systems engineering has two maingoals. The first is to improve the process of de-veloping specifications that can provide technicalorientation to specialty engineering in order todevelop systems that satisfies requirements andmeets customer’s needs. The second main goalof an agile project is to enable follow-on sys-tems development [9]. In agile methods, the sys-tem is constructed incrementally and at the endof each iteration, the developing system is readyto be verified for some requirements [9]. Thus,a validation and/or verification process is appliedat the end of each iteration to guarantee that theevolving system meets the requirements. To sup-port the statements of the manifesto, the AgileAlliance give a set of 12 principles. In his book,Douglass [9] restates the 12 agile principles [4]for systems engineering. Here only some princi-ples are presented:

Principle 1 Our highest priority is to satisfy the cus-tomer through early and continuous delivery of spec-ifications and systems that demonstrably meet theirneeds.Principle 2 Welcome changing requirements even latein development. Agile processes harness change forthe customer’s competitive advantage.Principle 4 Business people and systems engineersmust work together daily throughout the project.Principle 6 The most efficient and effective methodof conveying information to and within a developmentteam is face-to-face conversation or work productsthat execute (or simulate).Principle 11 The best architectures, requirements anddesigns emerge from self-organizing teams.

3

G P KRUPA

Principle 12 At the regular intervals, the team reflectson how to become more effective, then tunes and ad-just its behavior accordingly.

The incremental, spiral life-cycle developed inthis work is shown in figure 1. The project initiatesby the capturing of stakeholder requirements and bydecomposing the expected functionality. Followingthe functional analysis, a requirement analysis is re-alized. Then, it is possible to define the logical ar-chitecture which is done by establishing a hierarchywithin the system and by allocating requirements toits corresponding functions. Based on the logical ar-chitecture, initial architectures are proposed. Theseare analyzed and new candidate architectures are syn-thesized in order to fit the desired functionality and itsrequirements. The proposed architecture is validatedaccordingly and the overall system is verified. Thecycle proceeds in spiral meaning that each subsystemand its components, if necessary, are developed in thesame incremental way. The process is iterative andat each cycle requirements, functionality and systemelements are continuous updated to reflect the newavailable information. This incremental developmentis essentially the same that one typically follows whendesigning by first principles.

Stakeholder Requirements

Analysis

Functional Analysis

Requirement Analysis

ith Subsystem Agile Cycle

Architecture Analysis

SystemVerification

System Validation

Architecture Trade-off

Conceptualdesignphase

Projectinitiation

Preliminarydesign phase

Safety Assessment Process Guidelines & Methods (ARP 4761)

Program Management

Aircraft & System Development Processes (ARP 4754A/ED-79)

Define Logical

Architecture

Architecture Synthesis

Fig. 1 Agile System Engineering process for air-craft conceptual design

2.2 Model-Based Systems Engineering (MBSE)

Blanchard [10] defines Model Based Systems En-gineering (MBSE) as the formalized application ofgraphical modelling to support system engineering ac-tivities beginning in the conceptual design and con-tinuing throughout the entire life cycle. MBSE sup-ports and enhances the ability to conduct system engi-neering tasks such as requirements capturing, design,analysis, validation and verification. MBSE is oftencontrasted with a traditional textual-based approachto Systems Engineering. In MBSE, the primary arti-fact of the system engineering process is the systemmodel. On the other hand, in a textual-based sys-tem engineering approach, there is often considerableinformation generated about the system contained intextual documents. This information is often difficultto maintain and to assess in terms of its quality. In aMBSE approach, much of this information is capturedin a system model.

Stakeholder requirements analysis

Functional Analysis

Requirement Analysis

Architectural Synthesis

Architectural Trade-off

Validation & Verification

OOSEM (method)

SysML (language)

Textual based Model based

SysML diagrams

Fig. 2 Transition from SE to MBSE

2.3 Object oriented systems engineering method(OOSEM)

The Object-oriented Systems Engineering Method(OOSEM) is a MBSE approach that leverages object-oriented concepts and adopts SysML to facilitate thecapture and analysis of requirements and design in-formation to specify complex systems [11]. OOSEMis usually applied recursively and interactively at eachlevel of the system hierarchy and it employs a top-down approach to specifying, analyzing, verifying,design and development. In agile methods, the sys-tem is incrementally constructed at each iterationand OOSEM provides the flexibility to accommodatechanging requirements and design evolution, makingit an ideal method for the purposes of this work, aslong as it is tailored for agile, as the INCOSE hand-book [8] remarks.

4

Application of Agile Model-Based Systems Engineering in Aircraft Conceptual Design

2.4 Systems Modelling Language (SysML)

The Systems Modelling Language (SysML) from theObject Management Group (OMG) has emerged fromthe Unified Modeling Language [12] (UML), the defacto standard for modelling in software engineering.Friedenthal [11] defines SysML as a general-purposemodelling language for systems engineering applica-tions that supports the specification, analysis, design,validation and verification of systems and systems-of-systems. SysML models systems aspects that may beclassified into three groups: the behavioral aspect, itsstructure and its requirements.The reader is referred toFriedenthal [11] and the SysML formal specifications[13] for a comprehensive reference on SysML.

3 SYSTEMS DEVELOPMENT WITH AMBSE

The last section presents AMBSE in general terms,not particularly focusing on its application in aircraftdesign and development. This section shows thatnot only AMBSE can enhance the conceptual designprocess, but is also consistent with ARP-4754A andARP-4761 guidelines.

3.1 Overview of ARP-4754A

The document ARP4754A [14] provides guidelinesfor the development cycle of aircraft systems, for theplanning of the development process and guidelinesfor showing compliances with regulations. In general,aircraft systems show a high degree of interaction be-tween systems. Thus, they have many modes of fail-ure that affect the safety of the aircraft. ARP 4754Aprovides a methodology to mitigate development er-rors and provide a guideline for the assigning the ad-equate assurance level that errors in the developmentcycle have been identified and corrected. This is re-alized by assigning a Functional Development Assur-ance Level (FDAL) to the top-level Function, basedon its most severe Top-Level Failure Condition Clas-sification in accordance with Table 1.

Table 1 Top-Level Function FDAL assignmentSeverity FDAL Assignment

Catastrophic AHazardous/Severe Major B

Major CMinor D

No Safety E

AMBSE benefits from the use of ARP 4754A andARP 4761 practices, since these technical standardsimposes design discipline and development structure,ensuring that both operational and safety requirementsare fully realized and substantiated. Also, AMBSE fa-cilitates the use of these practices by providing a de-sign environment where requirements and solutionsevolve by small verifiable increments through col-laboration between self-organizing cross-functionalteams and end users.

4 APPLICATION OF AMBSE IN CONCEP-TUAL DESIGN

This section presents the application of AMBSE tothe first design iterations during the conceptual designphase. AMBSE is applied to both the aircraft, system,and component level following the process describedin figure 1. The component level is used to illustratehow AMBSE may support the so-called Post-Tier 1[15] supply chain trend, which involves more verticalintegration and restructured responsibilities betweenOEM and its suppliers. AMBSE supports an approachin which the aircraft designer is aware of the inter-actions and implications between systems and differ-ent disciplines. This is especially important in con-ceptual design, which is an intense exploratory phasedue to its iterative process structure, involving feed-back loops and successive refinements. In addition,the emphasis on the practice of first principles de-sign within AMBSE results in rapid design-responses,allowing requirements and solutions to gradually de-velop through collaboration between cross-functionalteams and end users, as prescribed by the Agile Phi-losophy.

4.1 Design Methods & Tools

The AMBSE process described in section 2.1 andshown in figure 1 is represented as a SysML activitydiagram in figure 3. The activity box inside the dia-gram describe the system engineering activities. Af-ter the specific system/subsystem architecture, it iscompared with alternative proposals. Once a candi-date architecture is considered ready, it is passed toIntegrated Product Development Teams (IPDTs) forpreliminary design. The standards ARP-4754A andARP-4761 are used to requirements generation duringthe entire process.

AMBSE requires an integrated development en-vironment (IDE). In this work, Eclipse [16] Papyrus

5

G P KRUPA

Integral Processes (ARP 4754A)

Program Management

Safety Assessment Process (ARP 4761)

Hand-off Validated requirements

to IPDTs

Initiate Project

act Conceptual Design System Level AMBSE process

ArchitectureTrade-off analysis

ArchitectureSynthesis

ArchitectureAnalysis

Requirement

Analysis

Functional Analysis

System/subsystem

requirement Analysis

[more reqs]

[else]

Architecture

Model Validation

[done]

[ready?]

Fig. 3 AMBSE Delivery Process During Conceptual Design Phase

[17] was chosen because it is open-source, offersUML/SysML modelling capabilities and it containsan extensible plug-in system for customizing the en-vironment. In particular, Papyrus was augmentedwith Massif [18] and Epsilon [19] plug-ins, allow-ing to transfer SysML activity diagrams to subsys-tem blocks in the Simulink environment. Engineeringanalysis necessitate the creation of dynamic models.The use of the object-oriented paradigm with bondgraph modelling facilitates the process of deriving thenecessary differential equations. The software 20-sim[20] was used in this work to model systems with thebond graph formalism and also to generate the re-spective s-functions, which can promptly be used ina Simulink model with great numerical computationalperformance.

Microsoft c© ExcelTM

is used as a technical calcu-lation and report creation tool, since it is nearly uni-versally used across the world and because it nega-tive aspects can be managed. All of the spreadsheets,conforming to the same format and layout. The tra-ditional design approach as in Roskam [21], Nicolai[22], Datcom [23], Kuchemann [24], Dubbel [25] andHoerner [26, 27] was implemented in a spreadsheetcustomized with XL-Viking[28] plug-in. Most of thespreadsheets use the XL-Viking Add-in to display andaudit the calculations. The XL-Viking add-in con-tains easy to use functions that show all the numbersor variables in each Excel formula. This ensures ac-

curacy and traceability of the calculations, allowingsignificant and valuable time is saved in checking andauditing of calculations while keeping all of the calcu-lations live and writing and updating reports is muchquicker and easier. This feature also facilitate the useof conceptual development and design-related analyt-ical tools (such as risk assessment matrix and sensitiv-ity analysis), described in Goldberg et all [29]. Thisspreadsheet approach allows Python scripting throughXL-Wings [30] plug-in to facilitate the data transfer-ring to the Simulink environment and to generate in-put to the SUAVE conceptual level aircraft design en-vironment. The design environment SUAVE [31] wasused to both aerodynamic and performance analyses.The plug-in gendoc [32] is used in the Eclipse envi-ronment to generate word files containing the corre-sponding diagrams. Recurrent engineering calcula-tions were also inserted in the generated documents.

4.2 System Requirements Analysis

The AMBSE approach was applied in the design ofa hypothetical airplane designated as Kr-206 which isintended to provide ways to test and develop advanceddesign techniques and methodologies. In particular,SST aircraft design demands special attention to theflight control system, where many factors differ sig-nificantly from subsonic aircraft. Most of the stake-holder requirements were inferred from technical lit-

6

Application of Agile Model-Based Systems Engineering in Aircraft Conceptual Design

erature [33, 34, 35], except the range requirements.The regulation FAA Part 25 [36] does not establishesflying qualities criteria. However, the document flightcontrol design best practices [37] recommends that theMIL-F-8785C [38] be followed as a guide for flyingqualities criteria. The table 2 shows a partial list of therequirements gathered from both Part 25 and MIL-F-8785C.

4.3 Functional Analysis

The purpose of this activity in the systems engineer-ing process is to iteratively identity the functions thatthe system must perform. Functional analysis is es-sential to the application of ARP-4754A/ARP-4761standards, because of that in the methodology fol-lowed in this work it is given a specific phase in theprocess. This activity establishes basic aircraft levelperformance, and operational requirements, which isaccomplished by arranging the functions into logi-cal sequences, decomposing top-level functions intolower-level functions, and allocating performance re-quirements generated from the higher-level functionsin the hierarchy to the lower-level ones. The output ofthis process is the functional architecture of the sys-tem, that is, a description of the system, in terms ofits functionality. According to ARP-4754A [14], theoutput of this activity is a list of aircraft level func-tions and associated function requirements and inter-faces for these functions.

4.4 Logical Architecture Definition

The logical architecture establishes the structure andboundaries within which specific system design areimplemented to meet all of the established safety andtechnical requirements. In practice, this the logicalarchitecture definition phase, requirement and analy-sis functional and the allocation of requirements aretightly-coupled iteratively processes. Since functionaland performance requirements originate at the highestlevels of the system hierarchy, these activities mustbe continuously repeated to define the logical archi-tecture at ever greater levels of detail. This processgenerates many types of requirements which include:independence, probabilistic, qualitative, availability,integrity, monitoring, operational and maintenance re-quirements and in latter iterations Function Develop-ment Assurance Level (FDAL). At aircraft level thesafety requirements are generated from the aircraftFHA based on top-level aircraft functions previously

defined. At system level, the safety requirements areall those system level requirements generated from thesystem FHA which are decompositions of the aircraftlevel safety requirements. At the next level down therequirements are all those aspects of the system whichallow the safety objectives associated with the sys-tem FHA classifications to be satisfied. The outputof this process generates many elements which needto be organized via SysML packages. In addition tothat, the preset work adopted the Joint Aircraft Sys-tem/Component (JASC [39]) code tables. The JASCnumbering provides a consistent framework for theaircraft technical documents. At the item (componentand subcomponent) level, S1000D [40] were used.

4.5 Architecture Synthesis and Analysis

The activity architecture synthesis and analysis com-prises the allocation of functionality and correspond-ing different kinds of requirements to high-level phys-ical elements. Ideally, more than one candidate sys-tem architecture should be considered in this activ-ity. These candidate architectures are then iterativelyevaluated using functional and performance analysis.In latter iterations, when the candidate architecturecontains sufficient detail, it is possible to to applypreliminary phase ARP-4761 [41] Preliminary Air-craft Safety Assessment (PASA)/Preliminary SystemSafety Assessment (PSSA) processes to establish thefeasibility in meeting aircraft and functionality andtop level safety requirements assigned to the system.

Aircraft Level The hypothetical aircraft develop-ment in this work features a double cranked-arrowwing. A feature of this wing is that its aerodynamiccenter shifts as the Mach number increases, movingtowards the tail cone of the aircraft [42]. A majorpenalty of this type of wing is that the drag increasesdue to the required deflection of the control surfacesneeded to compensate an aircraft, in transonic regime.In supersonic regime, this penalty is even greater andthe stability of the phugoid mode is often reduced.In such cases, it is desired to move the C.G duringflight, which can be accomplished by integrating thefuel system with the flight control system. By trans-ferring fuel, it is possible to maintain the static marginduring transonic and supersonic regime to only 3% ofthe mean aerodynamic chord. This feature highlightsthe benefit of early systems integration in conceptualdesign that AMBSE makes possible and manageable.The aircraft level AMBSE is discussed in section 4.2to 4.4.

7

G P KRUPA

Table 2 Partial list of longitudinal flying qualities requirementsIdentification Name Type Specification

R-ST-02 Longitudinal staticstability

There shall be no tendency for airspeed to divergeaperiodically when the airplane is disturbed from trimwith the cockpit controls fixed and with them free.

R-FCS-FQ-04-02-01-B Short-perioddamping

The equivalent short-period damping ratio, ζSP, shallbe within the limits 0.30 < ζSP < 2.0.

R-FQ-05-03 Pilot-inducedoscillations

There shall be no tendency for sustained or uncon-trollable oscillations resulting from the efforts of thepilot to control the airplane.

System Level In the conceptual design, it was de-cided that the aircraft shall not have a horizontal sta-bilizer in order to improve its aerodynamic perfor-mance, thus it requires a fly-by-wire system to aug-ment its longitudinal stability characteristics. in fig-ure 4, an initial flight control system architecture isproposed, in which all primary flight control surfacesare all electrically-controlled and hydraulic activated.The FCS interfaces with hydraulic and electrical sys-tems. The actuators are powered by the aircraft blue,green and yellow hydraulic lines. The flight controlsurfaces are powered by a combination of hydraulicand electro-hydrostatic actuators. It is assumed thatthe FCS possess by three primary computers and twosecondary computers that process pilots and autopi-lots inputs according to normal, alternate or directflight control laws, as shown in figure 4. The noseup and down movement are controlled by 4 elevons.

B Y

H H E

G Y

H H E

Engine 1

BY

HHE

GY

HHE

Engine 2

H H E

EBHA

EBHA

EBHA

G

Y

BG

Y

2

Full FBW mode

Direct Electrical Link

Direct Electrical Link Mode

Mechanical Reversion

1

Flight Control

Primary Computer #1

Flight Control

Primary Computer #2

Flight Control

Primary Computer #3

Flight Control

Secondary

Computer #1

Flight Control

Secondary

Computer #2

Roll

Pitch Pitch

Roll

Fig. 4 Proposed Initial FCS Architecture

From the simple candidate architecture schemat-ics shown in figure 4, it is possible to consistently de-rive its corresponding bond graph by substituting eachidentified system by a word bond graph. A SysMLblock definition diagram is draw to represent its struc-ture and interfaces with associated functions and re-quirements. Each element is the proposed architec-ture is then modeled as a bond graph using the soft-

ware 20-Sim [20]. This software is capable of ex-porting the bond graph model and its sub-models ass-functions, which can readily be integrated in theSimulink model.

An initial candidate architecture were proposedfor the fuel system, see figure 5. It was designed toprovide data for the total fuel volume required, thesize, location and number of fuel tanks needed andthe number of fuel pumps, its location and the re-quired capacity of fuel pumps and fuel lines. Theengine fuel flow was obtained in this stage by mul-tiplying the maximum required thrust by the associ-ated fuel consumption. Although it is reasonable toassume that the number of tanks in order to keep thecost to a minimum and reduce weight, in this work,the size, location and number of tanks were drivenby stability requirements in terms of the desired loca-tion of C.G for different loading scenarios. The sizingof fuel lines and the determination of necessary fuelpump pressures were calculates using [43]. The sim-ple schematics in figure 5 along with first principlecalculations was sufficient to generate a bond graphrepresentation, which was included in the Simulinkmodel as a s-function.

P

Fuel feed

P

P

P

Engine 1

APU

Engine 2

P

P

P

Jet-pump

Non-return valve

Pump boost

Fig. 5 Proposed Initial Fuel System Architecture

8

Application of Agile Model-Based Systems Engineering in Aircraft Conceptual Design

Component Level As shown in figure 4, the initialFCS architecture employs Electro-Hydrostatic Actu-ator (EHA) and Electro-backup-Hydraulic Actuator(EBHA). The design of an EHA (see figure 6) re-quires multi-domain modelling capability, since on itmechanical, hydraulic, thermal and electrical domainsinteract with each other. Therefore, bond graphs arean ideal tool for modelling such components. Follow-ing Langlois et all [44], the following EHA compo-nents are modeled by the Bond Graph shown in figure7: Electrical motor, hydraulic pump, accumulator, as-sociated hydraulics (two valves and a bypass valve),hydraulic cylinder, the mechanical actuation (four-barmechanism) and control surface. it is assumed that theEHA is supplied with a constant DC voltage source.In practice, the EHA is fed with a three-phase ACpower that supplies power drive electronics, which inturn, drive a variable speed pump together with a con-stant displacement hydraulic pump [45].

ACE

LVDT

Power DriveElectronics

DCMotor

FBWDirect Link

Feedback

Tri-phasic ACElectrical

Power

Feedback

Control Surface

Electro-hydraulic Actuator

Fig. 6 EHA schematics

Table 3 presents a partial list of servo-actuatorspecifications deduced from the AMBSE approach.They were generated from the complete bond graphmodel. It’s nominal parameters were calculated usingstandard mechanical engineering methods that wereprogrammed into design spreadsheets. The completelist has 30 requirements, including performance andfunctional requirements and it is intended to comple-ment and foster discussion with stakeholders and sup-pliers.

4.6 Validation and Verification

Validation and Verification comprise independent pro-cedures that are used together for checking that thesystem meets its intended functions, its requirementsand specifications. In the present work, both pro-cedures are realized in MATLAB/Simulink in a six-degree-of-freedom flight dynamics model. A brieflydiscussion of this model and control laws are con-

tained in the appendix. The following require-ments (presented at table 2) were validated and ver-ified: pilot-induced oscillations, short-period damp-ing, short-Period frequency and acceleration sensi-tivity, thus the system satisfies the short-period Re-sponse. The longitudinal response to a elevon stepcommand for the non-augmented aircraft is shown infigure and the longitudinal behavior of the aircraft us-ing the dynamics inversion control law is shown infigure 9.

The system was verified in low subsonic cruiseconditions (M = 0.70 and FL340) for two differentcontrol laws for: Gain scheduling and dynamic inver-sion. They were compared using the Control Antic-ipation Parameters (CAP). The CAP associated withGain scheduling is 3.435, while dynamic inversion re-sults in a CAP of 2.10. The aircraft conceptual de-sign specification is shown in table 4. A side and atop view of the hypothetical aircraft Kr-206 designedwith AMBSE are shown in figure 10.

5 CONCLUSIONS

This paper demonstrated the use of the Agile Philos-ophy in the aircraft conceptual design. The designof the flight control system is selected to illustratethe procedure in detail and it is concluded that AgileModel-Based Engineering greatly improves the earlyaircraft design process, allowing a smoothly transitionfrom conceptual to preliminary design. It is shownthat verifiable models are required for agile systemsengineering to enable design studies across all dis-ciplines and constraints. OOSEM and SysML pro-vide the flexibility to accommodate changing require-ments and design evolution, making them good can-didates for modelling within the Agile Philosophy.This not only ensures that at the end of each itera-tion, the maturing system design meets the require-ments from early on, but guaranties later a smoothlytransition from conceptual to preliminary design. Themathematical models necessary to develop the verifi-able models in Simulink can be easily derived with theBond Graph approach. Moreover, bond graph mod-els used in a objected-oriented way harmonizes withthe methodology described and can be used by en-gineers to perform straightforward numerical analy-sis in addition to gain qualitative insight, aiding thedesigner especially in the early stages of design andintegration. The common spreadsheet approach en-hanced with add-ins is capable of ensuring accuracy

9

G P KRUPA

Fig. 7 Bond Graph representation of the EHA

Table 3 Partial list Servo-actuator SpecificationsIdentification Name Type Specification

Req-EHA-F-01 Operating Pressure The required operating pressure, Ps, is 26 MPa.

Req-EHA-F-10 Maximum operatingpressure

The actuator should be designed for a maximum oper-ating pressure, PmaxA , of 23.6 MPa.

Req-EHA-F-11 Maximum acting force The actuator should be designed for a max-imum force, FmaxA , of 14430 N.

Req-EHA-F-15 Extended Actuator Length The actuator should be designed for an ex-tended length of 560 mm.

0 2 4 6 8 10 12 14 16 18 20

Time (seconds)

0

0.2

0.4

0.6

0.8

1

1.2

Pit

ch

an

gle

(d

eg

)

Fig. 8 Non-augmented longitudinal response

0 2 4 6 8 10 12 14 16 18 20

Time (sec)

-0.4

-0.3

-0.2

-0.1

0

0.1

0.2

0.3

0.4

Pit

ch

an

gle

(d

eg

)

Fig. 9 Augmented longitudinal response

and traceability of the initial parameters calculations.The combination of mathematical modelling, SafetyAssessment and system design techniques providesvaluable insights in the conceptual design process, es-pecially when applied to lower level aircraft systems.Within the Agile Philosophy, the engineering experi-ence and creativity still remains the essential keys tothe successful development of the system.

Fig. 10 Hypothetical SST designed using AMBSE

Table 4 Kr-206-A Partial list of specificationsWing Area 127.18 m2

Aspect Ratio 1.58Wing Loading 3112 N/m2

Number of Passengers 37Maximum Take-off Weight 40361.5 kgFuel Maximum Weight 13935.3 kg (34% MTOW)Empty Weight 21597.8 kgCruise Altitude 10058.4 m (33000 ft)

14325.6 m (47000 ft)Cruise Mach M = 0.93 and 1.4

10

Application of Agile Model-Based Systems Engineering in Aircraft Conceptual Design

References

[1] German B and Daskilewicz M. An MDO-Inspired Systems Engineering Perspective forthe" Wicked" Problem of Aircraft ConceptualDesign. In: 9th AIAA Aviation Technology, In-tegration, and Operations Conference (ATIO)and Aircraft Noise and Emissions ReductionSymposium (ANERS). 2009. p. 7115.

[2] Nicolai L M. Lessons Learned: A Guide to Im-proved Aircraft Design. AIAA American Insti-tute of Aeronautics & Ast. (June 15, 2016)

[3] Moir I. and Seabridge A. Design and develop-ment of aircraft systems, John Wiley & Sons,Hoboken, New Jersey, USA, 2012.

[4] Agile Alliance. Agile manifesto. Available athttp://www.agilemanifesto.org, v.6, n. 1, 2001.

[5] Johnson C L. Kelly: more than my share of it all.Smithsonian Institution. 2012.

[6] Kelly’s 14 Rules & Practices available athttps://lockheedmartin.com/us/aeronautics/skunkworks/14rules.html

[7] Eisner H. Essentials of Project and Systems En-gineering Management, John Wiley & Sons, Inc,2002.

[8] International Council on Systems Engineering.Systems Engineering Handbook âAS A Guidefor System Life Cycle Processes and Activities,2015.

[9] Douglass B P. AGILE systems engineering,Morgan Kaufmann, Burlington, Massachusetts,USA, 2015.

[10] Blanchard B S and Fabrycky, W J. Systems en-gineering and analysis, Pearson, USA, 1998.

[11] Friedenthal S., MOORE, A., and STEINER, R.A practical guide to SysML: the systems model-ing Language, Morgan Kaufmann, Burlington,Massachusetts, USA, 2014.

[12] Object Management Group R©. Information tech-nology - Object Management Group Uni-fied Modeling Language (OMG UML), ver-sion 2.5.1, 2017. Available at https://www.omg.org/spec/UML/2.5.1/PDF.

[13] Object Management Group R©. Information tech-nology - Object Management Group SystemsModeling Language (OMG SysML), version

1.4, 2015. Available at https://www.omg.org/spec/SysML/1.4/PDF.

[14] SAE. ARP-4754A: Aerospace RecommendedPractice: Guidelines For Development Of CivilAircraft and Systems. December, 2010.

[15] Michaels K. Post-Tier 1: The next era inaerospace supply chain evolution? AviationWeek & Space Technology, 18 May 2017.

[16] Eclipse Foundation. The Eclipse Founda-tion open source community website. (2018).https://www.eclipse.org/

[17] Eclipse Foundation. Papyrus open sourcecommunity website. (2018). https://www.eclipse.org/papyrus/

[18] Massif: MATLAB Simulink Integration Frame-work for Eclipse. https://github.com/viatra/massif

[19] Eclipse Epsilon team. Epsilon https://www.eclipse.org/epsilon/

[20] Controllab Products B.V. 20-sim. , Drienerlolaan5 HO-8266, 7522 NB Enschede, The Nether-lands., www.20sim.com.

[21] Roskam, J. Airplane design, DARcorporation,Lawrence, Kansas, USA, 1985.

[22] Nicolai L M and Carichner G. Fundamentals ofaircraft and airship design. American Instituteof Aeronautics and Astronautics, 2001.

[23] Hoak E. and Ellison D. USAF Stability &Control DATCOM, AFFDL-TR-79-3032, FlightControl Division, Air Force Flight DynamicsLaboratory, Wright-Patterson Air Force Base,Ohio, USA, 1972.

[24] Kuchemann D. The aerodynamic design of air-craft. Progress in aeronautical sciences, Perga-mon, London, 1978.

[25] Dubbel H and Davies B J. Handbook of mechan-ical engineering. Springer Science & BusinessMedia, 2013.

[26] Hoerner S F. Fluid-dynamic drag: practical in-formation on aerodynamic drag and hydrody-namic resistance. Published by the Author, Bak-ersfield, California, USA, 1965.

[27] Hoerner S F and Henry V Borst H V. Fluid-Dynamic Lift, Practical Information on Aerody-namic and Hydrodynamic Lift. 1975.

[28] XL-Viking. Excel Mathematics VisualisationAdd-in (c) 2015-2018 Abbott Aerospace SEZC

11

G P KRUPA

Ltd and Knut Gjelsvik.[29] GOLDBERG, B.E., EVERHART, K., STEVENS,

R., BABBITT III, N., CLEMENS, P., STOUT, L.System engineering toolbox for design-orientedengineers, NASA Reference Publication 1358,1994.

[30] ZOOMER ANALYTICS LLC.. XL-Wings:Python for Excel. V0.11.7, Feb 5, 2018.

[31] MacDonald T, Clarke M, Botero E, Vegh J M,Alonso J J. "SUAVE: An Open-Source Environ-ment Enabling Multi-fidelity Vehicle Optimiza-tion", 16th AIAA Multidisciplinary Analysisand Optimization Conference, Denver, CO, June2017.

[32] Eclipse Gendoc team Gendoc https://www.eclipse.org/gendoc/

[33] Wolf R. A summary of recent supersonic vehi-cle studies at Gulfstream Aerospace. In: 41stAerospace Sciences Meeting and Exhibit, 2003.

[34] Henne P. A Case for small supersonic civil air-craft. Journal of Aircraft, v.42, n.3, p. 765-774,2005.

[35] Smith H. A review of supersonic business jetdesign issues. The Aeronautical Journal, v.111,n.1126, p. 761-776, 2007.

[36] FAA. Systems Engineering Manual, Version3.1. Federal Aviation Administration. (2006)

[37] NATO, RTO. Flight Control Design - Best Prac-tices, RTO-TR-029, December, 2003.

[38] Moorhouse D., Woodcock, R. US Military Spec-ification MIL-F-8785C. US Department of De-fense, 1980.

[39] Air Transport Association of America. JointAircraft System/Component Code Table andDefinitions

[40] ASD/AIA. S1000D, "International specifica-tion for technical publications using a commonsource database".

[41] SAE. ARP-4761: Aerospace RecommendedPractice: Guidelines & Methods for Conductingthe Safety Assessment on Civil Airborne Systemsand Equipment, December, 1996.

[42] Stengel, R. F. Altitude stability in supersoniccruising flight. Journal of Aircraft, 7(5), 464-473, 1970.

[43] Avallone, E. A., Baumeister, I. T., & Sadegh, A.Marks’ Standard Handbook for Mechanical En-

gineers. New York, McGraw-Hill, 2006.[44] Langlois, O. et al. Bond Graph Modeling of an

Electro-Hydrostatic Actuator for Aeronautic Ap-plications. In: IMACS World Congress. 2005.

[45] Moir I and Seabridge A. Aircraft systems: me-chanical, electrical and avionics subsystems in-tegration, John Wiley & Sons, Hoboken, NewJersey, USA, 2011.

6 Contact Author Email Address

mailto:gustavokrupa@gmail.com

Copyright Statement

The authors confirm that they, and/or their companyor organization, hold copyright on all of the origi-nal material included in this paper. The authors alsoconfirm that they have obtained permission, from thecopyright holder of any third party material includedin this paper, to publish it as part of their paper. Theauthors confirm that they give permission, or have ob-tained permission from the copyright holder of thispaper, for the publication and distribution of this pa-per as part of the ICAS proceedings or as individualoff-prints from the proceedings.

12