Download Report

DEVELOPMENT OF CORE FUNCTIONS FOR AIRCRAFT
CONCEPTUAL DESIGN: METHODOLOGY AND RESULTS
G. Esdras and S. Liscouët-Hanke
Bombardier Product Development Engineering, Aerospace, Montréal QC,
[email protected], (514) 855-5001
Abstract
The functional analysis is one of the essential activities during the development of an aircraft, as required
by applicable standards, such as the ARP4754A, and the Systems Engineering approach. In an effort to
anticipate the system definition at aircraft level, this work proposes the early analysis of functions,
starting at the conceptual design phase. In order to harmonize between the appropriate flexibility that
allows for innovations and suitable starting directions that will enable efficient end results, the initial set
of functions must be meticulously conceived.
In contrast with existing methodologies and attempts to establish a definitive compendium of aircraft
functions, a collection of aircraft core functions is expected to be limited to a manageable size and not be
technology-specific, architecture-specific or implementation-specific.
This work describes the methodology proposed and applied for the elicitation of Core Functions within
the Advanced Design Department of Product Development Engineering, Aerospace, the group
responsible for the conceptual design of future commercial and business aircraft in Bombardier. Two
main streams are used for that: functional decomposition and identification of functions as implied by
requirements.
The results achieved and herein presented are a set of aircraft-level functions that intend to serve as the
root point for the functional analysis in the conceptual development of future platforms by Bombardier,
allowing for an open design space and driving innovation in terms of solutions, technologies and
architectures.
I.
Introduction
This article presents a compilation of the work performed and the results obtained for the development of
Core Functions, that may be used to support the conceptual design of the next aircraft platforms and the
development of its implementation-level functions.
The main goal was to establish a proper and solid collection of Core Functions that will be appropriate in
quantity and level of details to support the systems architecture activities at the aircraft conceptual design
level. Additionally, the resulting set of functions is used to support functional analyses and the safety
assessment at aircraft level.
The Aircraft Conceptual Design
The conceptual design of civil aeronautical products entails the challenge of proposing a sound
engineering project ahead of the competition under the limitations of a strong set of certification
requirements and the need for a quick response to market needs. At the same time, the amount of
1
engineering information on the product available upfront is very limited, given its precocity in a much
longer project timeframe of at least a few years.
The aircraft is a complex product and, as such, requires a well-organized development process. In order to
mitigate the risks in terms of safety, budget, schedule and certification, a standardized approach is
expected and the SAE ARP4754A standard has been widely used to guide the engineering development
process of civil aircraft and systems [1].
The Need for Functional Development
The proper identification of functions is a needed step as part of the development of complex systems,
including aerospace vehicles, in order to structure the development activities and mitigate certification
risks. Functional analysis is endorsed by:




The APR4754A [1];
The Systems Engineering discipline (as per standards and handbooks by NASA[2], INCOSE[3]
and others);
The Requirements Management standards (including the FAA Requirements Engineering
Management Handbook [4]);
The RFLP approach as endorsed by technology companies (Siemens[5], IBM[6], Dassault
Systèmes[7]) (The RFLP approach is later described in section V).
Ultimately, the identification of the functions of a system provides a better understanding of the system
itself and its capabilities, and a more efficient definition of interfaces. Functions are also used for safety
assessment activities (both at aircraft level and systems level). The possibility of a safety assessment at
conceptual level would improve product maturity and minimize risk at later development phases.
In this context, the functional analysis is required to assure back and forth traceability in terms of
verification and validation (V&V) items and performance decomposition, respectively. According to
INCOSE [2]: “Functional Analysis/Allocation is an examination of a defined function to identify all the
sub-functions necessary to the accomplishment of that function. The sub-functions are arrayed in a
functional architecture to show their relationships and interfaces (internal and external). Upper-level
performance requirements are flowed down and allocated to lower-level sub-functions”.
These functions, once at implementation level, are expected to be the input to Aircraft- and System-Level
Functional Hazard Assessments (AFHA and SFHA, respectively). These activities have the objective of
identifying failure conditions, their effects, classification and assumptions, as part of a broader and
comprehensive safety assessment process, as specified by the SAE ARP4761 [8].
Definitions
Aircraft-level functions: According to the ARP4754A standard, aircraft-level functions are high level
activities and are not necessarily associated with a single, physical system implementation.
Functional Analysis: According to NASA[2], functional analysis is the process of identifying, describing,
and relating the functions a system must perform in order to fulfill its goals and objectives. Functional
analysis is logically structured as a top-down hierarchical decomposition of those functions.
2
Functional Architecture: A functional architecture is a set of functions and their sub-functions that
defines the transformations of input flows into output flows performed by the system to achieve its
mission [9].
Definition of the system being developed: The first step for developing system functions is the
definition of the scope of the system under development, or System Of Interest (SOI). In this case, the
SOI is a generic aircraft, which fits the proper scope for the type of system envisioned for development by
Bombardier. For this use, the generally accepted definition of aircraft is limited to “a machine that is able
to fly by gaining support from the air”, in order to expand the design space of potential solutions that
fulfill the requirements established by an elicitation of customer needs.
It is imperative at this point to clarify that the systems that comprise the aircraft (commonly identified by
Air Transport Association (ATA) chapter numbers) are sub-systems of the major system “aircraft”. The
attribution of functions to the AFHA and SFHAs will follow this approach and is better described in
Figure 1.
System Of
Interest
Sub-systems or
aircraft systems
Aircraft Functions
Aircraft
System
21
System
22
...
System
xx
Systems Functions
AFHA
SFHA
SFHA
SFHA
SFHA
Figure 1. Scope of the SOI and sub-systems, adapted from the SAE ARP4754A [1].
II.
Current Functions Development and the Rationale for Improvements
Contrary to the development of non-aircraft products where the customer is in charge of describing what
is needed from the system, the development of an aircraft requires the enterprise, called the OEM
(Original Equipment Manufacturer), to identify requirements, capabilities, needs and functions expected
to be performed by the system.
A research performed on existing functional definitions, both in proprietary and publicized [10] work,
shows that the reusability of the functions achieved was deficient, for the following reasons:



Some listed functions are implementation-specific, which limits the design space of solutions;
No proper traceability between different levels of functions;
Some listed functions being actually design solutions or design requirements.
In addition, a need was found at Bombardier to improve the current set of functions mainly due to:




Poor harmonization of functions levels;
Incomplete functions;
Functions that are not possible to implement or even to further decompose;
Functions that are not well defined or understood.
Furthermore, at the conceptual design level, there is a need for a set of functions in order to allow a better
understanding of the aircraft systems, the development of a wider design space including innovative
3
solutions, and the identification of the most critical systems, so that appropriate efforts are applied on
detailing implementation aspects aiming for future risk mitigation.
In response to these needs, a set of Core Functions is herein proposed. Among the improvements expected
from a more generic and harmonized collection of aircraft-level functions, there are:




The harmonization of level of detail and importance between aircraft-level functions;
An unambiguous identification of system level functions, leading to a proper identification of
functions to be considered by either the AFHA or the SFHAs;
The optimization of the functions set and their traceability;
The understanding of each function, so to allow innovations (new technologies, novel
architectures, different implementations).
The resulting collection of Core Functions is presented in sections V and VI.
III.
Identification of Aircraft-Level Functions
As per the SAE ARP4754A, the activity “Identification of Aircraft-Level Functions, Function
Requirements and Function Interfaces” establishes basic aircraft-level performance and operational
requirements. From these basic requirements, aircraft-level functions and their requirements can be
derived and the function interfaces with the external physical and operational environment identified. The
output of this activity is a list of aircraft-level functions and the associated function requirements and
interfaces for these functions.
The methodology herein proposed reinforces the importance of the functional analysis as part of the
development of an aircraft and may be considered as a new philosophy for aircraft functional
development.
According to the ARP4754A, the aircraft function development is expected to happen after the concept
generation. One of the innovations proposed here is to bring forward the functional analysis to the
conceptual design phase in order to allow an earlier definition of the system, at aircraft level, and
therefore improve product maturity and earlier assessment of an optimized design space.
Overall, a proper identification of aircraft-level functions will strongly support the optimal definition of
interfaces between its sub-systems and with the external environment. Other benefits include the
anticipation of integration and test issues and consequently an easier and more rapid integration and tests
to be performed later. Nonetheless, the development of functions is essential for documenting,
understanding, communicating elements of the design and making use of proven and structured systems
engineering methodologies to improve the robustness of the development process.
IV.
Methodology
Two complimentary methods are proposed and applied for the identification of functions:
A. Functional decomposition
B. Functional derivation from requirements
4
Functional decomposition
Functional decomposition in systems engineering refers to the process of defining a system in functional
terms, then defining lower level functions and sequencing relationships from these higher level systems
functions [11]. Figure 2 shows the functional decomposition approach by means of an IDEF0 [12]
representation. It starts with a top-level function, which is further decomposed into sub-functions until a
proper level of detail is achieved. A good rule-of-thumb is to decompose each function to a manageable
size of 6 sub-functions.
Controls
Inputs
Function
Outputs
Mechanisms
Figure 2. Functional decomposition making use of the IDEF0 representation methodology [12].
According to the IDEF0 representation methodology, a function is represented by a rectangle, which has
its connections following the ICOM definition: Inputs on the left, Controls on the top, Outputs on the
right and Mechanisms on the bottom. Inputs are all the entities transformed by the function, including
entities being consumed, utilized or affected by it. Controls are all the entities that perform some type of
decision on the process, like when to be started or how to be performed. Outputs are the final status of the
inputs or what is provided by the function after it is executed. Mechanisms are the entities employed but
not necessarily changed during the function execution.
Functional derivation from requirements
Functions may also originate from requirements, which are not necessarily associated with the
decomposition of the top-level function. Some examples of functions that are not tracked in the functional
decomposition are functions that implement certification requirements, such as the Part 25 of the FAR
requirements [13].
The way requirements and functions are related to each other differs depending on the standard employed.
The SAE ARP4754A, as illustrated in Figure 2, considers the requirements as part of the integral process
and, as such, no clear order of precedence is established between requirements and functions, except that
the functional definition is expected to be completed first. The FAA Requirements Handbook [4] follows
a similar approach.
Other innovative approaches propose a different relationship, towards a more “systems engineering”
methodology, like the RFLP [5, 6, 7], which stands for Requirements, Functional, Logical, and Physical
5
approach. It considers the functional structures (together with logical structures) as parts inserted between
the requirements and the physical structures.
As part of the proposal herein presented, this interaction will happen in different levels and loopbacks
may also exist. This yields in a multi-level RFLP relationship that is aligned with the ubiquitous V-model
of the Systems Engineering Process. At the highest level (context level) requirements are more abstractly
defined as customer needs, marketing and program requirements and objectives, and are then decomposed
to lower level requirements like the aircraft-level, system-level, and so on. The same happens with
functions, which begin with the top-level function as defined in the previous subsection, and continue
their decomposition towards implementation-level functions. A similar trend is followed by logical and
physical views of the product. Figure 3 illustrates this proposal, where the green horizontal arrows
represent the conventional RFLP interactions between its elements of the same level, the orange diagonal
arrows represent decompositions of elements of the same nature into the next level, and the blue vertical
arrows represent implications to lower level elements of a different nature (e.g. functions that drive
requirements at a lower level).
Requirements
Functional
Logical
Physical
R
F
L
P
Requirements
Functional
Logical
Physical
R
F
L
P
Requirements
Functional
Logical
Physical
R
F
L
P
Requirements
Functional
Logical
Physical
R
F
L
P
Context Level
Aircraft Level (SOI)
Sub-systems Level
Components Level
Figure 3. Proposed RFLP model in alignment with the Systems Engineering V-model.
Therefore, it may be expected that functions will be also originated from requirements and not only from
the functional decomposition. One example of such type of function is the Autoflight function: although
of utmost importance, it is not really a necessary function for the aircraft to perform its mission, unless
clearly identified as a requirement due to stability and control constraints or as a marketing requirement.
V.
Results of the Functional Decomposition
The functional decomposition was performed and consolidated at different levels, and consented by the
involvement of experts from different specialties. The results are presented below and set the standard to
be used in future projects.
Level 0 Function
The top-level function (or Level 0 function) is the most abstract function that describes what the system is
created for. This is expected to be a one-only function that describes in a very top-level manner what is
expected from the system under development. For a Bombardier aircraft, the agreed function is
represented in Figure 4 by means of an IDEF0 diagram.
6
ATC
Crew
Regulations
Passangers
Transport
Airborne Payload
Cargo
Resources (fuel,
fluids, water, air/
oxigen etc.)
Payload Safely
Transported
A0
Vehicle
Infrastructure
Figure 4. Level 0 function (A0) of a BA product: “What is this system created for?”.
The most concise description of the mission of an aircraft is to “transport airborne payload”. In regards to
the ICOM representation, the Inputs are the passengers and cargo, which in the end will have a different
location, and the resources consumed during flight. The Controls are the flight crew, the Air Traffic
Control (ATC) and applicable regulations. In order to perform this function, the employed Mechanisms
are the vehicle and interfacing infrastructure (e.g. runways, etc.). Note that, at this level (Context Level),
the aircraft is not yet defined as the SOI. The Output of the process is the payload safely delivered to the
destination.
Level 1 Functions
The first round of decomposition is obtained by breaking down the Level 0 function into its sub-functions,
and connecting the resulting functions between themselves and to other entities according to the ICOM
representation. The resulting Level 1 functions diagram is presented in Figure 5.
Flight
environment
data
Provide Flight
Information
Aircraft data
Flight
information
A6
Crew
Sensors & communication
systems
Acc.
Passangers
Cargo
Resources
(fuel, fluids,
water, air/
oxigen etc.)
Accommodate Crew
payload &
Resources
resources
ATC
A1
Provide power
Aircraft structure &
systems
Power
Control aircraft
in flight
A2
A5
ATC
Provide lift
Powerplant &
Aircraft systems
A4
Move aircraft
on ground
Aircraft structure,
wings & systems
Aircraft
structure &
systems
A3
Aircraft structure &
systems
Payload
Safely
Transported
Figure 5. Level-1 functional architecture depicting the decomposition of the Level 0 function of an
aircraft.
7
The representation of these functions by an IDEF0 diagram highlights many important aspects of the
initial architecture, in terms of precedence, propagation, interfaces, parallelism and type of interactions
(e.g., the Output of a function may perform a Control role in another function). This improves the
functional analysis quality and anticipates the identification of design decisions that could otherwise
increase project risks later on.
Level 2 Functions
The same decomposition process is then applied to every Level 1 function, resulting in the Level 2
functions represented in Table1.
Table 1: Level 2 functions obtained from functional decomposition.
At this level, even though it is possible to represent the achieved functions in a functional architecture by
means of IDEF0 diagrams, the results would already be imposing some sort of implementation, which is
not the purpose of the Core Functions.
VI.
Results of the Functions Derived from Requirements
In addition to the results obtained from a functional decomposition, functions may also be derived from
requirements. Requirements are specific to each project and therefore the functions to be derived from
them are specific to the project as well. As an example application of the proposed methodology, a list of
requirements and derived functions, together with their appropriate levels, is presented below and may be
used in future as a starting point for new projects. This list is expected to grow considerably for each
particular application.
8
Level 0 Requirements
Level 0 requirements are obtained from top level requirements documents like the MR&O (Marketing
Requirements and Objectives) and PR&O (Program Requirements and Objectives) and are specific to
each aircraft development project.
Level 1 Requirements
At this level, five main areas of requirements are identified, as described below. Other areas may be
included if deemed appropriate for each project.
B1 - Safety Requirements: requirements originated from safety aspects, meaning that the aircraft must
be able to perform its mission and prevent accidents, sustaining the safety of the occupants, vehicle and
other external entities.
B2 - Security Requirements: requirements originated from security aspects, meaning measures to
prevent crime, unintended external access to aircraft information, and intentional or unintentional
interference in aircraft internal data and control networks.
B3 - Operational Requirements: requirements originated from all aspects related to the operation of the
aircraft during all phases of its lifecycle.
B4 - Passenger Services Requirements: requirements related to the infrastructure to provide services to
the passengers, including physiological needs, entertaining and comfort.
B5 - Marketing Requirements: requirements originated from needs identified to better position the
aircraft in the competition market, including features to provide specific technologies, to reduce costs, and
to improve the performance of the aircraft.
Level 2 Requirements
All the Level 1 requirements are further decomposed to Level 2 requirements, from which functions are
derived. Some examples are provided in Table 2.
Table 2: Level 2 functions obtained from requirements derivation.
Finally, the two sets of functions obtained are combined to form the Core Functions and serve as the root
point for the development of implementation functions – both at aircraft and systems levels. The two
methods afore mentioned can be consecutively applied to achieve the final list of functions, specific to
each project, to be used in development and safety activities. The utilization of the results and methods
9
here presented enables the forward and backward traceability coveted for allocation and justification of
design decisions, as well as the proper consistency and coherency expected for the development of
complex systems.
Conclusion
A systematic approach was applied to develop a collection of aircraft Core Functions. The results and
methodology employed were presented here and will be used for further development of functions for
specific aircraft development projects.
The standardized functional definition achieved is essential to promote a well-understood, coherent and
balanced functional analysis. These results lead to a more efficient conceptual development process and
to more mature design deliverables to be further developed at later design phases. Additionally, the
established functional baseline empowers Bombardier when managing suppliers, particularly by enabling
consistent forward and backward traceability. Ultimately, a better harmonization and unambiguous
identification of functions allows for the required project mastery and authority that opens the doors for
innovation.
From this point on, the Core Functions will be used to support systems architecture definition during the
conceptual design phase by guiding the definition of systems interfaces, supporting the safety assessment,
and providing an additional means to represent and understand the aircraft as a system.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
SAE ARP4754A - Guidelines for Development of Civil Aircraft and Systems, 12/2010.
National Aeronautics and Space Administration (NASA), Systems Engineering Handbook,
NASA/SP-2007-6105 Rev1, 2007.
International Council on Systems Engineering (INCOSE), Systems Engineering Handbook,
INCOSE-TP-2003-016-02, Version 2a, 1 June 2004.
Federal Aviation Administration (FAA), Requirements Engineering Management Handbook
DOT/FAA/AR-08/32, June 2009.
Siemens PLM, Systems Engineering und PLM, ISSN 2193-8415.
IBM Product Lifecycle Management, Collaborative Systems Engineering, PLS03029-USEN-01.
Thierry Ambroisine, Dassault Systèmes, Mastering increasing product complexity with
Collaborative Systems Engineering and PLM, Embedded World Conference 2013.
SAE ARP4761 - Guidelines and Methods for Conducting the Safety Assessment, Process on Civil
Airborne Systems and Equipment, 12/1996.
Guide to the Systems Engineering Body of Knowledge (SEBoK), version 1.3, May 30, 2014.
Fairuz I. Romli, "Functional Analysis for Conceptual Aircraft Design," Journal of Advanced
Management Science, Vol. 1, No. 4, pp. 349-353, December 2013. doi: 10.12720/joams.1.4.349-353.
Systems Engineering Fundamentals, Defense Acquisition University Press, Fort Belvoir, VA, Jan.
2001, p45.
Knowledge Based Systems, Inc. (KBSI), IDEFØ Method Report, 1993.
Title 14, Code of Federal Regulations (14 CFR) part 25 (commonly referred to as part 25 of the FAR
- Federal Aviation Regulations).
10