=Paper=
{{Paper
|id=Vol-1728/paper7
|storemode=property
|title=A Model Based Approach to Design for Reliability and Safety of Critical Aeronautic Systems
|pdfUrl=https://ceur-ws.org/Vol-1728/paper7.pdf
|volume=Vol-1728
|authors=Candida Stigliani,Davide Ferretto,Claudio Pessa,Eugenio Brusa
|dblpUrl=https://dblp.org/rec/conf/ciise/StiglianiFPB16
}}
==A Model Based Approach to Design for Reliability and Safety of Critical Aeronautic Systems==
https://ceur-ws.org/Vol-1728/paper7.pdf
A model based approach to design for reliability and
safety of critical aeronautic systems
Eugenio Brusa Candida Stigliani
Politecnico di Torino, Dept. Mech. and Aer. Eng. Politecnico di Torino, Dept. Mech. and Aer. Eng.
Torino, Italy Torino, Italy
eugenio.brusa@polito.it
Davide Ferretto Claudio Pessa
Politecnico di Torino, Dept. Mech. and Aer. Eng. Leonardo Company, Finmeccanica Aircraft Division
Torino, Italy
Torino, Italy
claudio.pessa@leonardocompany.com
davide.ferretto@polito.it
Copyright © held by the authors.
Abstract—This paper explores how the safety engineering slightly different implementations, depending on the
practices applied to the aircraft design can be effectively manufacturer [5] or even upon the technical domain [6]. Clear
associated to the MBSE. Requirements and procedures of the statements about functions, interfaces, hierarchy of control
ARP4754/ED-79 and ARP4761 were considered. As an example functions and safety based trade–off of the proposed layouts
the fuel system of a civil aircraft was used. Some key issues were are needed. As it looks evident the Systems Engineering can
found relevant, whilst modeling the system through the MBSE greatly support that activity as it is discussed in this paper. In
tools. The management of both the functional and dysfunctional particular, the aim is that of assessing a procedure to perform
analysis, leading to the Functional Hazard Analysis (FHA) of the the safety analysis of the system, through the tools of the
whole aircraft, within the same modeling environment was tested.
MBSE [7,8], suitable for homologation according to the
The elicitation of safety requirements with a direct link to the
standards of civil aircrafts [2]. The development of this
FTA and FMEA used to quantify the risk of failure was
performed. The software tools which can be interoperated for analysis basically deals with an integration between the usual
those tasks were tested. As a result, the integration between the functional analysis performed in SE and the dysfunctional
two above mentioned analyses looks fairly easy. In fact, further analysis used in safety engineering to quantify and prevent the
efforts are required to make fully interoperable the tools risk of failure [10]. As an example the fuel system of a civil
currently available to perform this activity and to include the aircraft with two engines for 90 passengers equipped with an
human interaction with the analyzed system. Auxiliary Power Unit (APU) will be described. As it is known
the fuel system is required to be highly reliable, to suitably
Keywords—Model Based Systems Engineering, Machine perform in all of operating conditions foreseen by the aircraft
Design, Numerical methods, Functional Analysis, Risk analysis, design [11,12,13]. In addition its configuration must fit some
System reliability and safety. requirements about the weight, cost and performance in
service, as well as those of maintainability and availability.
I. INTRODUCTION
A main goal of the Model Based Systems Engineering II. SAFETY ANALYSIS AND DESIGN
(MBSE) is the safety assurance in critical systems. To be The aim of safety analysis in design is that of defining
assumed as a main reference for the design, the MBSE needs suitable requirements to be fitted to comply with the needs of
to be fully integrated with the tools of the Safety engineering. conformity to the manufacturer’s practice, technical standards
Aeronautics is a typical application of safety critical systems and directives, homologation items and tests. The whole
with an increasing complexity, associated to the number of process to perform the safety analysis is described by the
subsystems connected, of functions exploited and of interfaces ARP4761. In practice, the aircraft functions and those of its
[1]. A bright integration among subsystems and components is systems should assure a risk degree compatible with the
strictly required to assure a suitable level of safety and to norms. The main activities are described in Fig.1. The safety
comply with the homologation of the aircraft product [2]. It is analysis can be integrated within the MBSE approach, for
known that the high level of complexity generally might instance by associating the above mentioned activities to the
increase the risk of failure, without a suitable prevention and a steps defined by the V–model, as the ARP4754A states
careful reliability assessment. Those motivations led to the (Fig.2).
requirements expressed by the Recommended Practices
ARP4754/ED-79 [3] and ARP4761 [4]. They define a process A key issue of this analysis is the so–called FHA
to provide all the relevant information to certify the safety of (Functional Hazard Analysis), which was performed in the test
complex and highly integrated aeronautic systems. case first at the aircraft level, then applied to the fuel system.
Nevertheless, daily practice demonstrated that processes and According to the FHA, for each system function, failure
definitions of those standards led to several interpretations and modes, severity and risk associated are explored [14].
Obviously the safety targets are defined by fixing the degree
of severity and risk compatible with a safe operation as in III. FUNCTIONAL HAZARD ANALYSIS
other similar safety critical systems [15,16]. Once that all the As the FHA is performed, all the failure modes of the
requirements could be allocated to the system functions, and system functions are identified. Failure conditions are
these are associated to subsystems and components, the FHA evaluated for both single and multiple events, in normal and
has to be performed for all of those. If the MBSE is applied degraded environment. Effects of failures are then defined and
this activity looks fairly easy. A preliminary functional classified. Some requirements to be associated to the failure
analysis is performed thus identifying use cases, stakeholders, conditions are then defined and their coverage in allocation is
functions and architecture of the designed system. Then a finally checked. In the test case, the FHA at the aircraft level
dysfunctional analysis can be run, thus allowing a critical was provided as an input of the modeling of the fuel system.
review of all the eventual failure modes. It might be noticed Functions included were mainly referenced to the ARP 4754.
that this approach provides a clear outline to proceed Many of those may affect the behavior of the fuel system.
straightforward, particularly during the concept design Among all, for instance, the thrust, self-piloting, data
activity. Safety analysis is performed fairly fast through the monitoring and recording, electric power, internal and external
FHA and is easily documented. connections and energy conversion were analyzed. For each
function, four states were considered in failure condition. A
severe failure occurs in case of total or partial loss of the
function, while less dangerous is considered an error signal.
Moreover, a function might be performed too early or too late.
In addition, failure might be either detected or not.
Once that the failure modes are defined, a relevant task is
investigating the severity of effects. This activity might be
very difficult, since associating a too severe consequence to a
dysfunction might turn out into a stringent requirement, as
well as under evaluating the severity of a failure might affect
the overall safety of the system. This difficulty could be
overcome through the System Engineering. It provides the
functional analysis, puts in evidence the stakeholders and the
use cases and allows tracing the effect of a failure through the
product development from the constructed part to the
corresponding function and requirement.
The FHA was formalized in the test case to be integrated
with the MBSE approach. Some degrees of severity of the
failure modes were set up. They were evaluated by
considering in sequence the absolute safety of system, its
operational capability, effects on the crew, effects on
passengers. Catastrophic is the dysfunction preventing
continued safe flight and landing, thus leading to the death of
Fig. 1. Main contents and tools of the safety analysis performed in humans, inhibiting some important operational capability or
aeronautical engineering (from ARP 4761)[4]. causing even injuries to crew to be urgently treated.
Hazardous is each event decreasing significantly the safety
margins, increasing the amount of work produced by the
system or affecting a number of other functions, or even
strongly tiring the crew or causing injuries not requiring an
immediate treatment for the occupants. A major dysfunction
for the aircraft allows it cruising and landing safely and
significantly increases the work of crew. Less relevant
dysfunctions might be classified either as minor or irrelevant,
depending on the appreciable reduction of safety margins.
TABLE I. SAFETY TARGETS AND REQUIREMENTS
Degree Probability per flight hour
Catastrophic < 10-9
Hazardous 10-9< x < 10-7
Major 10-7< x < 10-5
Fig. 2. Integration of the tasks of safety analysis within the V-diagram of the
Systems Engineering (from ARP 4754A) [3]. Minor 10-5< x < 10-3
Irrelevant (no effect) 10-3 <
To complete the FHA the probability of occurrence was suitable to be compatible with the tradition of the aeronautical
associated to each degree of severity of failure (Tab.1). This domain and to describe the dysfunctions, since it was
action immediately allowed writing the corresponding safety sufficient negating the operations defined in the sequence
requirements. diagrams to create several dysfunctional behaviors.
Some critical issues in the proposed architecture were
IV. REQUIREMENT ANALYSIS detected thanks to the dysfunctional analysis, which helped in
The elicitation of requirements for the fuel system in the updating the Functional Breakdown Analysis of the fuel
test case was driven by two parallel set of needs. Safety system.
requirements were directly derived from the results of the
FHA applied to the aircraft first, then on the system. A. Use cases
Functional requirements were found by means of the When a safety analysis is integrated with the functional
functional analysis performed in IBM Rhapsody®. It is analysis of the system, a more general interpretation of the use
worthy noticing that some goals were assumed as needs: case is applied. Instead of only a goal to be achieved by the
redundancy of critical functions, automatic monitoring with system, which usually involves as a stakeholder more the
warning capabilities, location of commands preventing any users than other subsystems, a use case might be even
accidental activation, double signal transmission. The considered an action performed by the stakeholder, without a
requirement analysis was performed by following the standard specific request. As an example, the engines feeding (Fig. 3)
IEEE 1220 [17]. Therefore, their attributes are specific, might be seen a logic action operated simply by changing
measurable, suitable, feasible and traceable, as is required by some parameters in the FCU (Fuel Control Unit) [21].
that standard. Additional requirements were written to fit the However, this interpretation makes the engine a sort of a
standard ASD S 1000 D (former ATA 100) [18]. To digitalize shadow stakeholder, poorly considered in the dysfunctional
those requirements the IBM Rational DOORS® tool was used. analysis. If the engine is considered as a regular stakeholder,
all of functions, connections, errors are activated and
V. FUNCTIONAL ANALYSIS dysfunctional paths can be easily defined. In the test case, for
Typical diagrams of the System Modeling Language instance, the fuel storage performed by the tank, according to
(SysML) were drawn to perform the functional and the SE literature, cannot be assumed as function since the tank
operational analysis of the system [19]. As a matter of fact, in does not require to the system to be filled nor the system
the test case which includes several material components to be requires to store the fuel. Therefore, the tank is a sort of
either assembled or connected to constitute the system, some service, poorly compatible with the role of stakeholder.
questionable issues were found in the MBSE as is known in However, if it is assumed to be a component of the fuel
the literature. For instance, the sequence of diagrams and their system, whose use case is store the fuel, in case of
topology might have an impact on a straight implementation permeability of the tank structure dysfunction of fuel loss can
of the approach. According to the Harmony© approach be foreseen and analyzed.
proposed by IBM [20] and widely used to run the Rhapsody®
tool, functional analysis can be performed by following some Fuel System Boundary Box
Physical
subsystem
alternate paths. Person
Feed LH
Provided that a preliminary definition of requirement engine
diagrams is performed and behavioral diagrams (use cases,
activity, sequence, state machine) are drawn before the FCU
architectural diagrams, including block (BBD) and internal Cockpit Feed LH engine
with RH fuel
Store fuel
crew
black diagrams (IBD), respectively, to perform the functional
analysis, after the use cases, sequences, activities and IBD
together with the state machine diagrams can be used. Shut-off LH
engine feed
Alternatively, activities can be drawn before the sequences or
even the state machine diagram can be used to derive the other
ones. This choice is up to the user, but effectiveness of the
software implementation changes as it might change the
impact of the proposed MBSE approach on the existing
practices of the technical domain. Fig. 3. Use case diagram, with special operational use case highlighted.
In the test case, the fuel system was easily described by As it could be remarked in the test case, safety analysis
resorting to the use cases and the sequences of actions affects the definition of the use cases. This happened for the
performed in operation, thus allowing a natural derivation of heating control. It was found after a preliminary elicitation of
activities and states. Some use cases were dedicated to a requirements that a control of the temperature of the stored
dysfunctional behavior, according to the FHA, by fuel is required and temperature cannot be below a define
implementing the approach described in Fig.2. It was threshold in operation, to assure a prompt use. The hydraulic
remarked that many requirements could be assessed and system plays the role of stakeholder in the heat exchange,
refined and others added by completing this task. Moreover, since it provides the required amount of heat to the fuel tank.
the path followed in drawing the diagrams looked the most This refinement was added after identifying a critical issue in
the dysfunctional analysis of the fuel system. As usual, the they can be used for both the functional and dysfunctional
functional analysis was performed in IBM Rhapsody® by analyses. An example of negation of a function is shown in
resorting to the connection between IBM DOORS® and Fig.4. Moreover, in the test case it was demonstrated that a
Rhapsody® through the existing gateway, which assures a preliminary set-up of functional sequence diagrams allows
synchronization of contents. identifying all the critical issues for an eventual dysfunction,
thus driving the dysfunctional analysis. A difference between
B. Use cases realization a functional and dysfunctional sequence diagram is that to
The realization of use cases is aimed at investigating the describe a dysfunction often it is required to resort to several
system behavior case by case and at identifying the functions additional details or links and some more functions. They
exploited. This task is usually based on the sequence increase the nodes of possible failure in the related
diagrams, which highlight the functions performed and the architecture of the system, which have to be enclosed inside
stakeholders involved in each one. It is worthy noticing that the FHA.
«Person» «F unction,Block » «Block ,Function» «Function,Block » «Function,Block » «Exter nal,Function,Block »
Groundcrew ENV Fuel quantity Sensing detection Fuel storage Tanks venting ENV Refuel flow
indication supplier
opt [Refuel_flow_supplier_connected_to_tanks_filler_points]
Start_refuel_flow()
Refuel_flow
Fuel_level
No_fuel_level_measure
Nominal gravity
refuel flow-
pressure
characteristic.
Stop_refuel_flow()
Refuel_flow
Gravity refuel flow = 0
Fig. 4. Dysfunctional scenario related to a lack of measurement of the fuel level during a feed by gravity
Sys tem_command Information_noti fication Sensing_detection Fuel_quantity_indication Fuel_storage Tanks_venti ng Tanks_refuelling
Groundc rew
Reques t
refuel
Groundc rew
Refuel Notify refuel is not
allowed
[R efuel==A LLOWED] [R efuel==NOT A LLOWED]
A llow refuel
flow Detec t if fuel flow is
allowed
Groundc rew
Notify if refuel flow is
allowed
Rec eive refuel
flow
S tore refuel
flow
Meas ure fuel
level
Groundc rew
[available]
FUE L LE VE L Notify fuel
[not available] level
[NO]
Fuel leakages
[YES]
ENV
P rovide air
venting
[els e]
FUE L LE VE L
[FUEL LEV EL==T A R GET FUEL LEV EL/FUEL LEV EL==M AX FUEL LEV EL]
Groundc rew ENV
[failed] [groundcrew not aware of failure]
Reques t s top refuel High level detection Protec t tanks from
flow spillage
[els e]
Not allow refuel
flow
Detec t if fuel flow is
not allowed
Notify if refuel flow is
not allowed
Groundc rew
Fig. 5. Activity diagram used for the dysfunctional analysis of the system.
B. Logical architecture
C. Activities and swimlanes
The system operation can be preliminarily described by
Activity diagrams were then drawn to complete the the logical architecture of the system. It allows the transition
description of the system behavior. Action flows are there between the functional and the physical modeling of the
shown, thus allowing immediately to identify a dysfunction system. Usually physical blocks are there not yet
wherever the flow is stopped (Fig.5). The role of each represented, while the allocation of system functions to
function or capability can be easily highlighted and further logical blocks, which will be then allocated to subsystems,
analyzed in this diagram by resorting to the columns, thus components and parts in a next step (Fig.7), is described. A
describing the so–called “swimlanes”. The connection with logical block is used to identify the relation between a
stakeholders can be represented as well. certain operational task and the components of the system
1
«Function,Block»
Fuel storage
1
1
1
involved. Each logical block is already an active entity like
1
1
1
1 a device, no more a pure function, not yet a real component.
«Block,Function»
Fuel supply to engines
«Block,Function»
Cross-feed
In practice a preliminary layout of the system architecture is
1 1
1
1
drawn, without forcing the designer to select the
«Block,Function»
corresponding components. The logical architecture can be
1
Fue l supply t o APU
1
also helpful to provide a preliminary system breakdown
1
suitable for the first allocation of the reliability of the
system, whilst the real prediction will be performed thanks
«Function,Block»
Tanks refuel ling
1
1
1
to the Product Breakdown Structure (PBS), as described in
«Block,Function»
Fuel Sys tem Functions
1
1
«Function,Block»
Tanks defuel ling Section VI.C.
1
«Function,Block»
Tanks drainage
1
1
«Function,Block» «Function,Block»
Tanks venting Tanks pressurisation
1
1
«Block,Function» «Block,Function»
1 1
Sys tem control, monitoring, actuation Sys tem actuation
1
1
1
1 1
1 «Function,Block»
Fuel quantity indi cation
«Block,Function»
Sensing detection
«Block,Function» 1
Heat exchange
1 1
1
1
«Function,Block»
«Block,Function» Fuel low level warning
Inf ormation notif icati on
1
1
1
1
«Block,Function» «Block,Function»
Sys tem command Fuel temperature indication
1
1
«Block,Function»
Prognos tic
1
Fig. 6. Functional breakdown structure of the system.
Fig. 7. Logical blocks of the system.
VI. PRODUCT DESIGN
A. Functional breakdown structure C. Product breakdown structure
According to the MBSE to avoid a pure repetition of the Once that the FBS and the logical blocks could be
layouts already applied in a previous version of the product, enriched according to results of the dysfunctional analysis, a
a good practice consists of dividing the architecture preliminary Product Breakdown Structure (PBS) can be
definition into three steps. Functions to be required to the drawn as in Fig.8. It includes some new components
system can be suitably defined by a breakdown structure introduced into the FBS and fits the requirements of
and then instantiated into a logical architecture, being allocation of the logical blocks description. Each physical
different from the real architecture since for each function block might allocate several logical blocks, while a logical
only a generic device or subsystem capable to perform it is block must be allocated uniquely on a physical one. This
included instead of the real and material component, which criterion allows reducing the number of components used,
will contribute to compose the system assembly. In the test the failure modes and the system complexity. It is worthy
case it was realized that the Functional Breakdown Structure noticing that this approach fails in case of required
(FBS) might be enriched if the functional analysis is redundancy of the system. From this point of view if the
performed in parallel with the dysfunctional one. In safety analysis drives towards the application of a
particular, control functions were detailed, as is shown in redundancy, the allocation between function, logical block
Fig.6. and physical blocks might be affected. In the test case it was
found that, according to the standards ATA some
components were necessarily added (Fig.8). Moreover,
some safety requirements might suggest to introduce maximum level in each tank is reached, then the refueling
additional components, like in test case it was the heat valve automatically is closed. A backup system was added,
exchanger for the heat transfer between the hydraulic and in case the main control of fuel level does not suitably work.
the fuel system. It consists of a sensor, being applied to the roof of each
tank. It assures that a warning is sent to the operators and
the pilot when the tank is full and that refueling is stopped.
It might be remarked that a panel is applied close to the
refueling connector to allow the ground operator monitoring
the state of each valve, even in case of feeding by gravity. If
an emergency landing is decided, refueling system is used to
control to open the valves through a dedicated
depressurizing device operating at 0,77 bar.
A venting circuit assures that pressure be always
positive during the whole mission profile. Each tank is
pressurized through a venting valve connected to another
one located at the end of the corresponding wing. This one
is connected to the external environment through an air
intake NACA, designed against the risk of ice accretion.
The venting circuit is used even to prevent any risk
associated to an accidental spill-out of fuel during the
refueling operation. The upper part of the fuselage includes
an empty and pressurized room, connected to the cross-
feeding circuit of the fuel system which allows controlling
the steam present inside the system.
Fig. 8. Portion of the Product breakdown structure of the system with
additional blocks. A control system manages the fuel stored on the aircraft.
A set of six sensors in each tank allows monitoring the fuel
level in each tank. Their measurements are elaborated and
D. System architecture displayed to the pilots. Additional magnetic sensors assure
The above mentioned rationale led in the test case to monitoring the fuel level even on ground. Temperature of
define the overall architecture of the fuel system. According the fuel system is always monitored and shown to the crew.
to the ATA standards three subsystems were introduced. A A typical warning is activated when pressure in jet pumps is
fuel storage, a fuel feeding, a fuel monitoring and lower than 300 mbar, to indicate the lack of fuel or a failure
management. occurring to the pumps.
A preliminary system layout was proposed, including
two tanks, located inside the wings, each one capable of VII. FUNCTIONAL HAZARD ANALYSIS (FHA)
storing 3185 l (approximately 2500 kg) and accessible from Previous definition of the fuel system layout was
the upper surface of each wing through two gates. In regular performed through a functional analysis based on the MBSE
service each engine shall receive the fuel from the nearest approach. However, as is clearly remarked by the number of
tank. To prevent any problem in case lack of gravity, each redundant devices foreseen in the proposed architecture,
tank is equipped with a small fuel reservoir of about 200 l especially sensors, this system looks highly safety critical. It
(feeder compartment), always full and connected to an means that functional analysis might be incomplete and
electric pump and to a jet pump. The first one is used during somehow unsuitable to detect all the risks associated to its
the engine start-up operation, then the jet pumps are operation and to refine both the list of requirements and the
automatically activated. The electric pumps automatically system layout. As it was previously described a
are switched on when pressure of fuel goes below 350 mbar, dysfunctional analysis is associated to the functional one to
thus assuring the fuel feeding. A cross-feed valve, being perform a deeper investigation and to complete the trade-off
controlled by an electromechanical actuator, allows feeding of the system layout.
the fuel to both the engines, through the same pump, in case
of emergency, or to connect the right engine to the left The so-called Functional Hazard Analysis already
pump and vice versa. A second valve is applied to each performed at aircraft level (as in section 2.1) was developed
tank, to stop the fuel feeding and to prevent the risk of fire. for the fuel system. This action needs some preliminary
If the minimum amount of fuel of 160 kg is detected in one activities:
tank, the related electric pump automatically starts. Some • system functions should be clearly defined as in the
heat exchangers allow keeping the temperature of fuel under Functional Breakdown Structure (FBS);
control and transferring the heat to the hydraulic system.
• interfaces with the operational environment should be
Re-fueling on ground is operated through a main known, as in the Use Case diagram;
connector, located just close to a landing gear. A piping
system distributes the fuel through the aircraft, until that the
• functions of the super-system should be evenly known, The FHA allows deriving the safety requirements for the
i.e. in this case those of the whole aircraft; system. Failure modes simultaneously are the high level
failure condition to start the derivation of the Fault Tree
• related failure modes and conditions of the super-system Analysis (FTA) [10,22], as in Fig. 10.
should be already explored and detected through the
FHA of the whole system, i.e. the aircraft;
VIII. SYSTEM SAFETY ASSESSMENT (SSA)
• system requirements should be defined and listed as in Once that the dysfunctional analysis is ready, as it happens
requirements list and diagrams, respectively. in case of the heterogeneous simulation for the prediction of
the dynamic behavior of system after the functional, for
instance, an interoperation with the System Safety
Assessment (SSA) is performed, to enable a verification of
the safety requirements.
The SSA consists of a systematic analysis of the
architecture to link all the dysfunctions previously identified
by the FHA to safety requirements. This activity needs a
preliminary verification plan, based on the severity of each
failure as the ARP4761 describes. In particular, in this work
it was done by following some criteria as: the function type,
its severity, the flight step in which the failure occurs and
the complexity of the subsystem or component analyzed.
According to that approach, it is relevant resorting to the
classification of degrees described in Table 1. Dangerous
and catastrophic events are usually more deeply analyzed.
A. FTA
Each failure condition detected by the FHA leads to
Fig. 9. Sketch of a typical layout of a fuel system similar to that forseen in
verify the corresponding safety requirements. To perform
the test case for a civil aircraft for regional connections. this activity, the FTA is used. Starting from a main failure
event, all the related failures are detected through the
connections present inside the system and the interfaces
according to a sort of "top-down" screening as in Fig.10.
This analysis resorts to the hierarchic structure of the
system. Therefore, the functional and dysfunctional analyses
performed through the BBD and IBD immediately support
this action. In case of the explosion of a tank, for instance, it
could be possible detecting the tree of faults easily by
considering the use cases and the proposed system
architecture.
B. FMECA
A quantitative evaluation of risk is possible when the
Fig. 10. Example of FTA for a failure event of tank esplosion.
cause and effects analysis is performed, by creating the
homonymous FMEA (Failure Mode and Effect Analysis)
A main benefit of the MBSE applied to the test case was [10]. To introduce some metrics inside the FTA, failure
that FHA naturally flows if one looks at the FBS as well as rates have to be identified, component by component, as
at the other SysML diagrams previously drawn, especially well as their reliability. If one assumes that those values are
to identify the system functions and interfaces. Practically, it constant over time, at least in this step of the analysis, a
was sufficient negating the actions foreseen in sequence and FMEA report can be linked to the functional model and then
activity diagrams. Moreover, safety engineering procedures used to fit requirements of the ARP4761. Relevant inputs
can be easily performed by all of involved operators since are the component identification number and name, the
the models are shared through a platform among all. From failure modes foreseen, a description of effects, tools to
the point of view of scenarios and missions starting from the detect the failure, to measure their severity and to repair,
use cases, linking each failure condition to a specific and when possible.
known flight phase helps a lot. Designer should avoid Once that the FMEA is completed, failure rates can be
detailing too much in this activity the contents of the FHA, easily derived by looking at the FTA. Moreover, there is a
as it could be easily the case, because of the availability of time of exposure to the detected risk. In the test case, for
those functional diagrams. many components it simply corresponds to the time of
flight, since this subsystem is highly critical, the failures
severe and the consequences mainly dangerous or even mistakes in operation, i.e., upon including humans in the
catastrophic. In some cases other values were set up, model, or even of multiple failures simultaneously
according to the literature herein indicated. The occurring.
interoperability in this case is played with the software used
to define the above mentioned values, i.e. the RAM-
COMMANDER®. Each FTA allows computing the Acknowledgment
probability of failure associated to the main event at the top, This work was funded by the ARTEMIS Joint
through the Boolean algebraic function described by the Undertaking under Grant Agreement N° 332830.
tree.
It might be considered that those approaches can benefit References
of other currently developed within the frame of computer
[1] E. Brusa, A. Calà, S. Chiesa, F. De Vita, D. Ferretto, “Towards an
science and information technology. Even in this field a full effective interoperability of models within the 'Systems Engineering'
interoperability of tools is looked for. Some examples of applied to aeronautics”, in Proc. INCOSE Conf. on Systems
reliability analysis linked to a system dynamic behavior was Engineering (CIISE 2014), Rome, Italy, November 24-25, 2014,
already proposed by resorting to Modelica® as a tool for a pp.38–47, CEUR Workshop Proceedings, ISSN–1613–0073.
full safety analysis [24]. Moreover, structured reliability [2] Federal Aviation Admnistration (FAA), Advisory Circular, System
analysis and safety assurance processes are currently Safety Analysis and Assessment for Part 23 Airplanes, AC 23.1309-
1E (11/17/2011), ACE-100
developed and tested to be used in connection with the
[3] SAE Aerospace , ARP4754: Certification Considerations for Highly-
MBSE and related tools. They could be integrated with the Integrated or Complex Aircraft Systems, SAE Systems Integration
process above described, to enrich and complete the tool Requirements Task Group AS-1C, ASD., REV. A, Society of
chain and create a suitable platform to support the overall Automotive Engineers, Inc., 2010
system development [25]. [4] SAE Aerospace, ARP4761: Guidelines and methods for conducting
the safety assessment process on civil airborne systems and
equipment, U.S.A.,SAE Committee S-18, Society of Automotive
IX. CONCLUSION AND FUTURE WORK Engineers, Inc., 1996
A challenging issue to demonstrate the effectiveness of [5] A. Mitschke, E. Brusa, A. Calà, D. Ferretto, C. Pessa, G. Bachelor,
the Model Based Systems Engineering in developing and “Heterogeneous simulation based on standards: deepening
interoperability in trade-off analysis approach for aeronautical
integrating mechanical and aeronautical systems is using its application”, Proc. 23rd Conf. Italian Ass. of Aeronautics and
tools to enhance the elicitation and the verification of safety Astronautics, AIDAA 2015, 17-19 November 2015, Torino.
requirements. Actually the analyzed test case of the fuel [6] E. Brusa, A. Calà “Identifying the Smartness of a Mechatronic Coiler
system for a civil aircraft demonstrated that coverage and through the 'Systems Engineering'”, Proc. INCOSE Conf. on Systems
traceability of requirements can be greatly improved by Engineering (CIISE 2014), Rome, Italy, November 24-25, 2014,
using the MBSE. Safety engineering basically needs a clear pp.116–125, CEUR Workshop Proceedings, ISSN–1613–0073.
definition of functions, interfaces and hierarchies in the [7] D. Walden, G.J. Roedler, K. Forsberg, R. D. Hamelin, T. Shortell,
INCOSE Systems Engineering Handbook v.4, INCOSE-TP-2003-
system layout to proceed with a straight evaluation of failure 002-04, 2015.
modes and their propagation in terms of effects upon the
[8] NASA, NASA System Safety Handbook, 2 vv., Washington D.C.,
whole system. Functional modeling allows developing a National Aeronautics and Space Administration, 2014
dysfunctional analysis, which helps in detecting the failure [9] E. Brusa, A. Calà, D. Ferretto, “Integration of heterogeneous
modes and defining the corresponding safety requirements. functional-vs-physical simulation within the industrial system design
A key activity is the Functional Hazard Analysis, which activity”, IEEE Int. Symposium on Systems Engineering, Rome,
might easily be performed by following the information September 29–30, 2015, ISBN: 978-1-4799-1919-2, pp.303-310.
described by the behavioral and architectural diagrams of [10] S. Chiesa, Affidabilità, sicurezza e manutenzione nel progetto dei
the MBSE. Moreover, safety analysis requires a quantitative sistemi, Torino: CLUT Editrice, 2008.
prediction of risk and of the related probability of [11] S. Chiesa, Impianti di bordo per aeromobili: impianto combustibile,
Torino: CLUT Editrice, 1994.
occurrence. In this second step of the activity it might be
noticed that FTA and FMEA are supported by the MBSE, [12] I.G.Medvešek, T. Perić, J. Šoda, Fault Tree Analysis in the Reliability
of Heavy Fuel Oil Supply, 2014.
never substituted, although functional modeling allows
[13] S. Quilty, Overview of Airport Fueling Operations, Washington, D.
deriving fairly easily the contents of those analyses. A better C., Transportation Reserach Board, 2015.
correlation between the FHA of the whole aircraft and of the [14] T.P. Kelly, P.J. Wilkinson, “Functional Hazard Analysis for highly
fuel system was even found. Critical issues at the interface integrated aerospace sytems”, in Certification of ground/air Systems
between those two systems could be even detected. As a seminars, IEE, 255, 1998.
matter of facts, the designed fuel system demonstrated to be [15] K.J. Hayhurst, J.M. Maddalon, P.S. Miner, G.N. Szatkowski, M.L.
capable of feeding the required amount of fuel along a Ulrey, M.P. DeWalt, C.R. Spitzer, Preliminary Considerations for
complete flight mission, for given pressure, temperature, Classifying Hazards of Unmanned Aircraft Systems, Hampton,
Virginia, NASA TM-2007-214539, L-19299, 2007.
altitude and scenario. Fuel level is continuously monitored
[16] TEC-DOC, IAEA, Component reliability data for use in probabilistic
[23] and fuel heating suitably controlled by heat exchangers. safety assessment, Vienna: International Atomic Energy Agency,
Interoperation between functional models, FMEA and FTA October 1988.
looks possible and effective, although a corresponding [17] T. Doran, “IEEE 1220 for practical Systems Engineering”, Computer,
interoperation of related software has to be further tested. A 39:5,2006.
future work could be focused on the effect of human
[18] ASD – AIA – ATA, International specification for technical
publications using a common source database, S1000D, 2007.
[19] J. Holt, S. Perry, SysML for Systems Engineering, London: The
Institution of Engineering and Technology, 2008.
[20] H. Hoffmann, Systems Engineering Best Practices with the Rational
Solution for Systems and Software Engineering Deskbook, Release
4.1, U.S.A, IBM Corporation, 2011
[21] Wang XiaoYang, “Aircraft Fuel System Prognostics and Health
Management”, Master thesis, University of Cranfield, 2012.
[22] U.S. Nuclear Regulatory Commission, Fault Tree Handbook,
Washington, D.C., 1981.
[23] C. Pessa, M. Cifaldi, E. Brusa, D. Ferretto, K. Malgieri, N. Viola,
“Integration of different MBSE approaches within the design of a
control maintenance system applied to the aircraft fuel system”, in
Proc. IEEE Int. Symposium on Systems Engineering, Edinburgh,
October 4–5, 2016.
[24] L. Rogovchenko-Buffoni, A. Tundis, M.Z. Hossain, M. Nyberg, P.
Fritzson, “An integrated toolchain for model based functional safety
analysis”, J. Computational Science, Vol. 5, Issue 3, May 2014,
pp.408–414.
[25] A. Garro and A. Tundis, “On the Reliability Analysis of Systems and
SoS: The RAMSAS Method and Related Extensions”, IEEE Systems
Journal, Vol. 9, issue 1, pp.232-241, March 2015; doi:
10.1109/JSYST.2014.2321617.