CEAS Aeronaut J (2016) 7:315331
DOI 10.1007/s13272-016-0189-0
ORIGINAL PAPER
SPYDER: a software package for system diagnosis engineering
C. Modest1 F. Thielecke1
Received: 12 December 2014 / Revised: 28 September 2015 / Accepted: 1 March 2016 / Published online: 28 March 2016
 Deutsches Zentrum fur Luft- und Raumfahrt e.V. 2016
Abstract Modern aircraft systems comprise hardware
and software with high complexity. In order to assure an
operation at high availability and low maintenance cost,
diagnosis functions become essential. These functions
detect faults and failures, identify sources of faults and
failures and assess the current state of health. A reduction
in operating cost, better planning of maintenance actions,
and new business cases for operator and equipment man-
ufactures are gained as a result. A systematic approach for
the design and test of diagnosis functions supported by an
integrated model-based tool chain is introduced in this
paper. That is the SPYDER concept, a Software Package
for sYstem Diagnosis EngineeRing. Embedded into the
general system development process, a stepwise design and
test of diagnosis functions is performed. It focuses on
failures and starts with failureeffect analysis, continues
with sensor placement and proceeds further to configura-
tion and testing. The method has been applied to multi-
functional fuel cell systems that are used as illustrative
examples.
Keywords Failure diagnosis  Fuel cells  Model-based
systems engineering  Expert systems
This paper is based on a presentation at the German Aerospace
Congress, September1618, 2014, Augsburg, Germany.
& C. Modest
christian.modest@tuhh.de
1
Hamburg University of Technology, Institute of Aircraft
Systems Engineering, Nesspriel 5, 21129 Hamburg, Germany
1 Introduction
In the year 2050, all European flights should arrive within
1 min of the planned arrival time [1]. This is a very
ambitious aim considering the current status. In 2012,
16.7 % of all European flights had a delay of more than
15 min [2]. That was mainly due to technical issues [3]
which caused maintenance actions, high cost and incon-
veniences for passengers.
To close the gap, efficient diagnosis functions are seen
as key contributors. These detect faults and failures, iden-
tify root causes, and assess the health status of systems and
components. Therewith, a system operation at higher
availability and reduced maintenance cost is gained. Long
aircraft on ground (AOG) times induced by high rates of
false alarms and no-fault-founds (NFF) [4] indicate that
current diagnosis functions and development strategies
possess weaknesses. Instead of supporting the system
operation they often lead to hindrances. This motivates the
use of more efficient diagnosis functions that are developed
in a systematic and model-based process. These functions
can be split into two main areas of application. This con-
cerns fault diagnosis and failure diagnosis. The latter is in
the focus of the paper at hand. A novel development
framework for failure diagnosis is introduced. This consists
of an interwoven process, an implementation strategy and a
tool. The overall goal is to increase the efficiency and ease
the implementation of failure diagnosis for complex air-
craft systems.
The paper is organized as follows. Section 2 gives a
general overview about failure diagnosis. Related work in
the field of software tools, development processes and
implementation strategies is presented in Sect. 3. A concept
for more efficient diagnosis functions is illustrated in Sect. 4.
Section 5 depicts an embedded framework for the design and
123
316 C. Modest and F. Thielecke

test. This is supported by the model-based tool chain SPY-
DER which is introduced in Sect. 6. The software package
consists of four modules that are demonstrated by means of a
case study in Sect. 7. The content of the paper is summarized
in Sect. 8 and an outlook on open topics is given in the end.
Extensions to include fault diagnosis functions are discussed.
2 Diagnosis functions
There are various definitions of failure diagnosis for tech-
nical processes. In a generalization, according to Isermann
[5], it is the task of determining type, size, location and
time of detection of a failure. Blanke [6] and Ding [7]
define diagnosis to be not only the localization and iden-
tification but also the detection of failures. There are fur-
ther definitions like [8] and all have in common that they
differ slightly in what to include and what to perform in
failure diagnosis. The ISO 13374 [9] on condition moni-
toring and diagnostics of machines makes an attempt to
standardize fault and failure diagnosis. It defines six
functional blocks by means of interfaces. Four of the
blocks are related to failure diagnosis as are depicted in
Fig. 1. The functions themselves are not defined in [9]. The
blocks are explained in the following by means of imple-
menting diagnosis functions. The latter are seen as methods
to fill the blocks with life.
Data acquisition is performed on the lowest level. This
is about filtering and conversion of sensor signals into
digital quantities. Preprocessed data is gained. Data
manipulation is carried out in the next step. Signal analysis
and the combination of different signals is done to extract
features. The latter indicate abnormal behavior and the
occurrence of failures. The assessment of the behavior,
either normal or persistent faulty, is done by state detec-
tion. Threshold checking and pattern recognition tech-
niques are possible activities for evaluation of features.
Discrete failure indicators and specific feature character-
istics are derived. These are input to the health assessment
module where potential sources of failures, failure modes
(FM), and certainty factors for each FM are determined.
This definition of failure diagnosis is referred to in the
following.
3 Related work
The ISO 13374 standard defines a framework for fault and
failure diagnosis. However, the development and imple-
mentation of the specific functions is left to the user.
Therefore, the content of the paper affects three aspects of
current research. These are strategies for design and test,
software tools that assist the development, and measures
for the implementation of diagnosis functions.

3.1 Development processes

There are various publications on the design of diagnosis

FM3
Certainty

FM4
FM2

and general health management functions. A generic

FM1

FM6

FMN
FM5

approach for health management systems engineering is

Health proposed by Wilmering [10]. This shows different steps of
Assessment development, but focuses thereby on general aspects and
Indicator

the distribution of work between company and supplier.

Charact.

1 Different tasks that have to be done during development

are mentioned, but it is not depicted how to do it. The
State Detection importance of designing diagnosis and health management
t t
functions into the system and using systems engineering
Raw data Prepr. data Feature

Threshold
principles is emphasized by Scandura [11]. However, no
guidelines are provided. Further approaches exist that
Data Manipulation mostly deal with the development of advanced models for
t
direct online integration and the operation parallel to the
supervised system [12, 13].

Data Acquisition 3.2 Software tools

t
Commercial software packages can give assistance in
developing diagnosis functions. The tool made by PHM
Sensors
t technology provides a functional modeling framework
[14]. System behavior is reduced to causal relationships
Fig. 1 Diagnosis functions according to ISO 13374. that can be influenced by failures. A failure effect analysis

123
SPYDER: a software package 317

can be carried out but bidirectional failure propagation 3. What will efficient diagnosis functions look like which
cannot be taken into account directly. The software can support a variety of aircraft systems?
RODON by Combitech AB uses a physical modeling
approach based on a Modelica like language [15]. Failure
modes are modeled phenomenologically. It enables the
4 Diagnosis engine
study of failure effect relations using bidirectional failure
propagation. However, it is limited to static system
The SPYDER concept is a novel development framework
behavior. Although, both the packages can give support in
for failure diagnosis. It aims to provide efficient diagnosis
early design phases of diagnosis functions they are limited
functions that support a variety of aircraft systems. A
in their application areas. Extensions of models to deal
central element is the separation between the model-based
with dynamic behavior, deeper failure analysis for deter-
development of failure diagnosis functions in an offline
mining quantitative failure characteristics, the analysis of
process and their online execution. No model is used dur-
faults and the configuration of diagnosis functions are not
ing run-time, but only a flexible and compact diagnosis
possible.
engine. The latter works with condensed and structured
knowledge in the form of diagnosis rules. These are of the
3.3 Implementation strategies
generic form if..then.. and are executed by software agents,
which are depicted in Fig. 2. These agents perform state
To cope with increased system complexity and system
detection and health assessment in a distributed and hier-
interdependency, distributed and hierarchical approaches
archical manner.
for the implementation of diagnosis functions are in the
The lowest layer of the diagnosis engine consists of
focus of current research. A three step approach is pro-
monitoring agents. These instances evaluate features by
posed by Hess [16]. This goes from measurements and
means of threshold checking. By that, indicators are
control data on a component level to a health status on a
derived. The latter indicate the occurrence of abnormal
system and aircraft level. It is a general approach that
behavior in terms of failures. An example is the indication
provides no means for handling and combining data and
of effects of a breakdown of a compressor. Indicators
specific algorithms to use. Felke [17] proposes a four step
possess discrete values in the range f1; 0; 1g. Depending
approach. Compared to Hess, further instances are intro-
on the context this is translated by low, nominal and high
duced for specific components. All instances of this
approach work on the ISO 13374 standard which is repe-
ated on every level. However, no measures are provided to
rated suspects
implement the functions. There are further publications
Aircraft Diagnostic
like [18], but none does actually show how to stepwise Agent
concentrate data and come to a final conclusion about a
certainty
suspects

Assessment
current health status and existing failures.

Health
3.4 Summary and discussion
characteristics

A survey of current literature showed, that there is a deficit

symptoms

in approaches that fully enable the integrated development Certainty Agent

and actual implementation of efficient diagnosis functions Fusion Agent
for a variety of aircraft systems. No methods exist right
indicators

now that combine processes for the design and test,

Detection

implementation strategies and appropriate software tools.

Detection Agent Shape Agent
State

However, only the combined consideration will lead to a

reduction in cost for development and operation, and an
increase in efficiency. Therefore, three key questions have
been formulated, that will be dealt with in the following Monitoring Agents
parts of the paper:
1. How can the design and test of diagnosis functions be features
standardized? (Data Manipulation)
2. How can knowledge of failures be encoded for the
specific target system? Fig. 2 Hierarchical and distributed diagnosis engine

123
318
as well as false and true. An example for the first case is the
indicator m_ Air 1 which denotes that an air mass flow
m_ Air is low in the specific state. It thus falls below a lower
threshold. The air mass flow m_ Air is directly used as a
feature. A further example is m_ Failure 1 which is derived
from m_ Failure m_ cmd  m_ act [ 0:3  m_ cmd . In this case, the
indicator color, which is 1, is translated with true and the
difference between commanded and actual mass flow is
used as a feature. This means that features are generally
defined as quantifying parameters. A detection agent
combines indicators and operating conditions to reveal
symptoms. These have discrete values in the range f0; 1g
which is translated by the terms false and true. The com-
bination of the indicator m_ Air 1 and the operating
conditions Ops Active gives the exemplary symptom 1 =
1 (true). All symptoms are correlated by a fusion agent.
This agent infers from symptoms to failures by means of
generating and testing hypotheses. The latter are called
suspects. In a continuation of the example, an initial
list of suspects would be fair-compressor-defective;
. . .; air-valve-jammedg. All the elements of the list can
explain the occurrence of symptom 1 = 1. To isolate the
actual failure all suspects are tested on basis of further
symptoms. An example for the latter is symptom 2 = 1.
This is defined as the combination of Ops = Active and an
indicator for air mass flow in another branch of the
exemplary system. If the indicator possesses a value of 0
which equals nominal in this case the air-compressor could
be tested failure free by means of this falsification
approach. A final set of suspects is gained in the end which
is reduced to those failures that can fully explain all the
detected symptoms. All the tasks mentioned are performed
individually for each system. A system-wide health
assessment is done by an aircraft diagnostic agent. That
agent takes into account functional inter-dependencies
between systems and failure propagation over system
interfaces. The technology used is again a resolution
strategy as in the case of the fusion agent. The left branch
of the diagnosis engine provides a list of suspects, which
are equally possible sources of the detected abnormal
system behavior. This result is gained in a transparent and
documented way which will be shown later in more detail.
To have a further possibility to pinpoint the exact failure
and making an estimate of the most likely suspect, cer-
tainty factors are calculated. This is done by means of the
right branch of the diagnosis engine and fuzzy logic and
fuzzy inference techniques. A shape agent is awakened
when symptoms are detected. It provides characteristics of
each feature. This is defined as the actual difference
between feature and threshold as shown in Fig. 1. The
characteristics are processed by a certainty agent which is
in charge of calculating a certainty factor for each
123
C. Modest and F. Thielecke
hypothesis. The certainty factor itself is defined as the ratio
of matching degrees of fuzzy diagnosis rules with specific
conclusion FM, e.g., air-valve-jammed, to the sum of all
matching degrees irrespectively of the actual conclusion.
By that, the certainty is in the continuous range [0, 1] and a
list of rated suspects is gained in the end.
The key aspect of the proposed diagnosis engine is the
utilization of diagnosis rules and diagnosis agents. The
latter are used to reveal symptoms, infer suspects, deter-
mine certainty factors and combine results from different
systems on the overall aircraft level. These tasks are per-
formed by pattern recognition techniques, resolution
strategies for generating and testing suspects as well as
fuzzy logic and fuzzy inference for the provision of cer-
tainty factors. All these techniques are implemented and
executed using rule-based expert systems [19]. This means
that the core of each diagnosis agent is based on a rule-
based expert system.
Expert systems consist of a knowledge base and an
inference procedure to infer from facts from the system
about symptoms, suspects and certainties in the current
case. A fix core has been developed that comprises algo-
rithms on pattern recognition techniques, resolution
strategies and fuzzy inference. These algorithms are inde-
pendent from the target system. An adjustment takes place
by means of specific diagnosis rules. Therewith, a flexible
implementation of failure diagnosis functions is gained that
supports a variety of aircraft systems. The failure diagnosis
functions are separated into dedicated sub-functions to
handle system complexity and make the overall failure
diagnosis more efficient.
In general, the formalization of knowledge and the
transfer into the knowledge base of an expert system is
exhaustive. It is called the knowledge acquisition bottle-
neck in literature [19]. To overcome this drawback, a
systematic design and test procedure supported by a model-
based tool chain is introduced in the following. Diagnosis
rules are thereby deduced from models and required
symptoms, indicators and features are identified.
5 Embedded development process for diagnosis
functions
The development of diagnosis functions can be standard-
ized by an embedded model-based system engineering
(MBSE) approach. This follows the common V-model [20]
as shown in Fig. 3.
The general system design process is divided into two
main phases. These are the definition phase on the left
branch and the integration phase on the right branch. In the
definition phase, an architecture of the physical system is
SPYDER: a software package
1. Analysis and definition of diagnosis 7. Virtual
requirements integration test
2. Design of diagnosis
6. Model-based test
concepts of all diagnosis
3. Detailing of diagnosis elements
concepts
4. Elaboration of final
diagnosis concept
Require- A/C
Level
ments 5. Coding
System System
Architecture test
Component Component
design test
Hardware realization
System development
Embedded development of diagnosis functions
Fig. 3 Framework of an embedded development process for diag-
nosis functions
developed on basis of requirements for system operation.
In following steps, the system functions to be performed
are divided into sub-functions and respective suitable so-
lution approaches are identified. These solutions are
designed in detail and realized by appropriate components.
In the integration phase, a test of components is initially
pursued. This is followed by system integration and system
test and final verification. This classical V-model is
enhanced by a model-based approach for design and test of
diagnosis functions. A double V-model results in the con-
sequence with prior virtual tests before actual hardware
realization. In the first step of the model-based design of
diagnosis functions, all requirements affecting the diag-
nosis functions are gathered. This concerns the
detectability of failures, the level of detail for the isolation
of failures and temporal aspects of failure detection. A
maximal sensor-feature architecture is defined by experi-
ence in the second step. This provides feature candidates
that are analyzed in later steps to identify an optimal sen-
sor-feature subset. A quasi static model propagates failure
behavior and identifies relations between failure and fea-
tures. The latter are evaluated to gain indicators. The
results are summarized in failure indicator matrices.
A detailing takes place in the third step. A dynamic
model allows deeper failure analysis by taking into account
temporal properties of failure propagation. Complex indi-
cators are gained from the temporal appearance of indi-
cators. Minimal sets of indicators are then identified that
enable the detection and isolation of failures according to
the required level of detail. An assessment of the indicator
319
sets is performed and a Pareto optimal solution is identi-
fied. The maximal sensor-feature architecture is reduced to
the most valuable pairs therewith. A sensor recommenda-
tion is given as a result.
The chosen solution is enhanced in the fourth step.
Characteristics of features are taken into account, which
enables the assignment of certainty factors to failures and
the assessment of a health status for system and compo-
nents. Fuzzy diagnosis rules are trained to perform fuzzy
inference for both the tasks. Failure indicator matrices are
transferred into exact diagnosis rules. Both types of rules
are saved in a xml data format and stored in a database.
Coding is performed in the fifth step and executable soft-
ware code is gained. A model-based test is carried out in
the sixth step. This is performed separately for each ele-
ment and level of the diagnosis engine. That means that
each agent is tested separately. The final verification is
done in the seventh step by means of the interaction of the
complete diagnosis engine and a system simulation
extended by noise and disturbances. Therewith, faults in
the design phase can be identified that become only visible
by means of the complex interaction.
Although cost and effort has to be spend on developing
models, it is assumed that this is compensated by an
increase in diagnostic efficiency and a drastic reduction in
life cycle cost of the system by utilizing the proposed
approach. Key issues like completeness with respect to
failure modes, divergence of indicators, and unambigu-
ousness in the isolation of failures can be handled and
documented systematically.
6 Software package for system diagnosis
engineering
The model-based tool chain SPYDER supports the devel-
opment of diagnosis functions. SPYDER consists of four
modules as depicted in Fig. 4. An overview is given in the
following. A detailed description follows in Sect. 7 by
means of a case study.
Fig. 4 Module concept of SPYDER
123
320
The failureeffect modeling module is about the mod-
eling and simulation of failures on the component level as
well as the derivation of indicators. In the first step, failure
models of all components are developed. This is done by
means of an extension of the basic nominal behavior with a
phenomenological failure description. The failure models
are developed according to a SPYDER grammar. This
means that each model comprises a mask where a failure
mode variable fm, a failure mode description fm_str as
well as the time of failure occurrence fm_time are defined.
A deep model analysis is performed in the next step. This
means that all implemented failures are identified and a
respective name and failure model path are stored in an
array. Afterwards, the array is used to subsequently simu-
late all failures and save failure effects in terms of features.
The user has to define at which features to look at. All the
features are then assessed automatically by means of
threshold checking. It is taken into account either user
defined thresholds or nominal behavior as a reference.
Indicators are gained by that. The results in terms of failure
indicator relations are stored as failure indicator tables for
documentation purposes. This module supports the steps 2,
3 and 4 of the development process according to Fig. 3.
Failure indicator tables are transferred into failure indicator
matrices in the indicator and sensor selection module. The
matrices are evaluated stepwise with respect to diagnosis
requirements and optimization criteria. The latter concern
unambiguity, effort and cost, amongst others. Valid solu-
tions are highlighted by means of a radial visualization
method according to [21]. The method is used to display all
optimal solutions in a circle with n axes where n equals the
number of criteria. Each solution is normalized and the
influence of each criteria is illustrated by means of a spring
model. The most optimal solution would thus be in the
middle of the circle where each criteria would have the
most optimal value. This visualization method supports the
diagnosis designer in the identification of the final solution.
This consists of an optimal set of indicators and sensors.
This module supports the steps 3 and 4 of the development
process according to Fig. 3.
The transformation of failure indicator matrices into
exact diagnosis rules takes place in the rule generation
module. For the purpose of deeper failure analysis and the
assignment of certainty factors to suspects, fuzzy diagnosis
rules are deduced from failure characteristics and an
inference training procedure according to [22]. Both types
of rules are saved in xml data files. Therewith, the rules are
human readable and transparent. This module supports the
steps 4 and 5 of the development process according to
Fig. 3. The management of exact and fuzzy diagnosis rules
is done in the configuration of diagnosis engine module.
The xml data files are transferred into diagnosis modules
that define the specific behavior of detection agent, fusion
123
C. Modest and F. Thielecke
agent, certainty agent and aircraft diagnostic agent. The
diagnosis modules are directly readable by the cores of
each generic diagnosis agent. C-code is generated for
monitoring agents and the shape agent. Executable diag-
nosis functions are gained in the end. Therewith, this
module supports the steps 5, 6 and 7 of the development
process according to Fig. 3.
7 Case study
Current research deals with the integration of fuel cells
(FC) on board of future aircraft [23]. FC enable the gen-
eration of electrical power without the emission of green-
house gases and noise. A concept for the utilization of
these benefits consists of the replacement of the auxiliary
power unit (APU). The APU is a combustion engine that is
mainly used to deliver electrical power during ground
phase. However, the provision of the same amount of
power using FC results in an increased system weight.
Hence, to make sure, that the use of FC is not only eco-
logically beneficial, but also economically feasible, the
integration has to be done in a multifunctional approach.
This means that besides the electrical power all other
products of the FC have to be used and further systems be
replaced to overcome the weight penalty. Figure 5 illus-
trates the architecture of an exemplary multifunctional fuel
cell system.
Main elements are two fuel cell systems that each
comprise two fuel cell stacks, an air supply with com-
pressor, a hydrogen recirculation and a cooling circle. The
supply with reactants takes place with pure hydrogen and
air from the aircraft cabin. As a product of the electro-
chemical processes exhaust gas in form of oxygen depleted
Avionics Control + Failure Diagnosis
Interfaces
Fuel cell system 1 Kerosine tank 1
Cargo bay 1
Air
Air
Cabin H2 dryer
Exhaust air
H2 tank Cooling Kerosine tank 2
Cargo bay 2
Fuel cell system 2 Kerosine tank 3
Environment
Fig. 5 Illustrative architecture of a multifunctional fuel cell system
SPYDER: a software package 321

Exhaust Air approach is thus promising. It is demonstrated in the fol-

Check valve lowing by means of the SPYDER tool.

Cooling 7.1 Failureeffect modeling

fluid
To cooling From cooling The Failureeffect modeling module deals with all aspects
-+ -+
of modeling, simulating and assessing faulty system
= + = Fuel Cell
DC-DC Stack behavior. A model is used to comprise:
Converter
= - = Environ. Knowledge about functionality,
H2 Knowledge about failures,
Recirculation
Sensor Knowledge about topology,
Knowledge about interfaces and sensors.
Purge
Modul Nominal system and component behavior, functions to be
Valve performed and operating conditions to be considered are
H2-Pump
based on knowledge about functionality. This basis is
extended with failures on the component level. Electrical
loads and physical quantities are shared with external
Compr. systems and the environment bidirectionally via interfaces.
This includes failure behavior that is originating from
outside the multifunctional fuel cell system (MFFCS), as
Pipe
H2 well as failure behavior which is originating from the
MFFCS. This behavior is propagated by means of the
Air From tank topology and can be observed through sensors. In total, the
From cabin model comprises knowledge from different domains which
allows the deep analysis of failures and their effects. The
Fig. 6 Excerpt of fuel cell system 1 comprising components from
Matlab toolbox Simscape has been used to derive a model
multiple physical domains
of the exemplary MFFCS [24]. This toolbox allows an
a-causal and component based modeling of physical
air is gained. This is used for kerosine tank inerting and behavior by means of equations. It starts with modeling of
cargo bay fire suppression. Water as product of the air quasi-static behavior and continuous with dynamic prop-
drying process is fed to the on-board water system. A more erties if sufficient information are available from system
detailed look into one of the redundant fuel cell systems is development. It is therewith suitable for the application of
depicted in Fig. 6. The system comprises two fuel cell the steps 2, 3 and 4 of the development process according
stacks that are supplied with pressurized air by a com- to Fig. 3. The model validation is an important aspect to
pressor. The latter takes the air from the cabin. Pressurized assure the significance of the gained results. However, the
hydrogen is taken directly from the H2 tank. Several pipes multifunctional fuel cell system is a project of ongoing
and valves are used for transportation and control of the research. Real test-rig data is not fully available at the
fluids. Via interfaces and DC-DC converters, electrical current point of time. The data that was available has been
loads are applied to the fuel cell stacks. Cooling is per- used to validate the model to some extent. For other aspects
formed in a series connection. Sensors exist to a certain assumptions have been made. It is important to note that
extent to control the system. this specific case study has not the aim to make statements
In total consequence, a highly complex system results that directly lead to the purchase of sensors and other
that poses high demands on failure diagnosis. Without avionic hardware. The method is the focus of this paper. If
proving that failures can be detected, isolated and identified changes occur during the system development or current
efficiently there will be no chance to bring such a system assumptions prove to be wrong, the development steps for
on board of future aircraft. Challenges that arise in this the failure diagnosis functions can iteratively and easily be
context are the handling of system complexity, the run through further times. Due to its conception the SPY-
derivation of diagnostic knowledge, the placement of DER approach is very flexible. Hence, the aim is to provide
sensors, and the integration of all diagnosis functions into a method that is ready and powerful, when it comes to the
the avionic environment. Dealing with these issues in a real integration of a MFFCS on board of future aircraft.
manual way is laborious, cost intensive and prone to human Failures of the multifunctional fuel cell system are modeled
errors. The application of the model-based SPYDER phenomenologically on the component level. Figure 7

123
322 C. Modest and F. Thielecke

Capacity
Pipe failure mode port
physical El. Motor
port
Env. Mech.
Leakage Shaft
kv
failure mode
port
Compr.
failure signal

Fig. 7 Failure model of an air pipe

Compressor
Map
shows a an illustrative example of a failure model of a pipe
of the air supply.
The model comprises a block representing the pipes Fig. 8 Failure model of an air compressor
capacity and a valve representing a controllable leakage.
The integration into the overall model is done via three
ports. Two of them are physical conserving and bidirec-
tional. The failure mode port is unidirectional. By means of Jam
a failure signal, the valve can be opened and a leakage be Mech. A B
simulated. This is achieved by an adaption of the specific Shaft Ground
flow coefficient kv , which influences the mass flow m_ Air
Rupture Inertia
through the valve. In detail, m_ Air is a function of flow
d
coefficient kv , density q, temperature T, and pressure p
J
[25]:
r
qair;in  pair;out c
m_ Air kv   pair;in  pair;out : 1 (c,d)=f(FM)
Tair;in
A failure signal activates the failure mode FM in the model Fig. 9 Failure model of a mechanical shaft
by means of an ifelse clause. The kv factor is changed
thereby from zero to a specific kv;leak: value:
 The Jam block is linked to two physical ports. At port B
kv;leak:; if FM leakage failure;
kv 2 there is a solid ground attached where the rotational
0; otherwise: velocity x is set to zero and the torque t is undefined. The
The current focus of the SPYDER approach is on failures. Jam block itself comprises two physical equations. The first
Therefore, the kv;leak: factor has to be set to a value that equation defines the difference in rotational velocity:
represents a failure of the pipe and not a fault. Hence, the Dx Ax  Bx : 3
factor has been set to value where a direct effect on the
system operation is achieved. This will be shown in detail The second equation defines the torque to be equal at both
in the following. Thereby, the detection of small leakages the ports:
is not an aim of the current approach. A failure model of an t tA tB : 4
air compressor is depicted in Fig. 8.
It comprises an electrical motor, a mechanical shaft, the Both the equations are influenced by the failure of a jam. In
compressor itself as well as a compressor map. For details that case, Dx is set to zero and the torque t is set to be
about modeling of the nominal behavior please see [26] undefined. In case of the nominal behavior, the torque is set
and [27]. The electrical motor, the mechanical shaft as well to zero and Dx is undefined:
as the compressor are assumed to be influenced by failures. if FM == Jam Dx 0 else t 0: 5
Relevant failures have been chosen based on [28]. An
example of a failure model of the mechanical shaft is According to the phenomenological approach several fail-
shown in Fig. 9. It includes a mechanical jam and a rupture. ures have been modeled. This covers high leakages of pipes
The first one is modeled as a simplified clutch whereas the and valves, jamming of valves, mechanical failures of the
last one is represented by adapting damping factor d and compressor, as well as increased activation losses and
spring constant c. reduced efficiency of the fuel cells, amongst others. A

123
SPYDER: a software package
reuse of the failure models is achieved by a failure model
library and the object oriented modeling approach. This
eases iterative development loops, design changes and
further applications. The failureeffect modeling module
identifies all failure modes FM that are currently imple-
mented in the components of the MFFCS. All FM are then
simulated consecutively for different operating conditions.
In the case study two operating conditions are considered.
These are depicted in Fig. 10 by means of the electrical
load that has to be provided by all the fuel cell stacks. In
operating condition one there is no load acting on the
system whereas in the second operating condition a load of
30 kW has been applied. A drop in electrical voltage U can
be observed as an effect. An increase in current I happens
likewise and a new operating point on the fuel cells U-I
curve is reached.
All effects of failures are observed by means of a
maximal sensor-feature architecture. This has been imple-
mented in the model using engineering judgment. Sensor
types and positions have been chosen that can provide
valuable information for failure diagnosis. The analysis in
SubSect. 7.2 will show which sensors, features and indi-
cators are actually needed in an optimal case. It will give
sensor recommendations. Figure 11 depicts exemplary
effects of the failure of a high leakage of the air pipe. The
factor kv;leak: from Eq. 2 has been assigned a value in a
magnitude such that a persistent deviation in voltage can be
observed. At time tF the failure has been activated in the
model. Two features are shown, which are mass flow of air
at the inlet of fuel cell stack A, and the voltage at the
electrical interface to the DCDC converter. For the eval-
uation of the features, threshold checking has been chosen
as a simple and robust technique [5].
The threshold checking is realized with state charts.
These comprise an initial state, a counter state and a failure
state. The features fi are checked for exceeding or falling
below an upper or lower threshold thresh for a persistence
time tp . The counter state is reached from the initial state, if
a deviation between fi and thresh occurs. A transition to the
failure state is triggered after the deviation persisted for
time tp . This time includes a check of the deviation every
electrical load P [kW] voltage U [v]
30
180
Operating
condition 1
Operating
15 condition 2
120
tP tP
t t
Fig. 10 Operating conditions of the illustrative example.
323
voltage U [v] mass flow m [kg/s]
Lower 0.05
180
threshold
120
0.01
tF tF
t t
indicator U*
indicator m*
0 0
-1 -1
tD,1 t tD,2 t
Fig. 11 Effects of a leakage of an air pipe
y seconds for x cycles. Values for y and x are chosen by
engineering judgment. As a result of the threshold check-
ing, indicators with values in the range f1; 0; 1g are
gained. These discrete values are then transferred into more
descriptive values of the range fLow, Nom, Highg. Hence,
the indicators of the previous example are assigned the
value Low at times td;1 and td;2 respectively. Therewith, the
general procedure of assigning values to indicators looks
like follows:
8
< Low;
> if f \ threshlow & t [ tp ;
Indicator X High; if f [ threshhigh & t [ tp ; 6
>
:
Nom; otherwise:
The failureeffect modeling module allows an automatic
evaluation of features and determination of indicators. This
is based on a function library, where state charts are
deposited. The designer of the diagnosis functions has to
choose the features of interest. State charts are then loaded
and configured automatically. The relation between failures
and indicators is summarized in failure indicator tables.
Different classes of indicators are considered thereby and
each class defines its own table. The classes are related to
the system function to be performed, the detection of
potentially latent failures, sensor failures, and further
information needed only for failure isolation. Sub-sets of
the maximal sensor-feature architecture are allocated to
each class of indicators. A persistent deviation between
expected and observed voltage output occurred in the
previous example. Voltage is directly linked to the system
function of providing electrical power. Hence, it has been
chosen as one of the features for the first class of indicators.
Further features are measurements of current at both the
fuel cell stacks, mass flow of oxygen depleted air and mass
flow of water at the outlet of the MFFCS. The relation
123
324 C. Modest and F. Thielecke

Table 1 Effects of failures with relevance to functions to be fulfilled Table 2 Effects of failures that can support failure isolation
Component Failure mode Effect-func. Det. Component Failure mode Effect-maint. Det.

Compressor Jam Ind. U  = Low 8 Compressor ... ... ...

... ... ... ... ... ...
Air pipe ... ... ... Air pipe ... ... ...
 
Highly increas. leakage Ind. U = Low 8 Highly increas. leakage Ind. m_ = Low 8
... ... ... ...
FC stack A ... ... ... FC stack A ... ... ...
Mass transp. Ind. U  = Low 8 Mass transp. losses Ind. TH2 = Low 8
losses ... ... ... ...

between failure and indicator is shown in Table 1 by means

Table 3 Effects of failures that can help in detecting latent failures.
of three examples.
The failure indicator table has four columns which Component Failure mode Effect-early Det.
represent a component, a failure mode, effects and the
Compressor Increased friction Ind. PC = High 1
operational interval of detecting the indicators. This inter-
... 1
val is related to operating conditions and control states.
Pipe ... ... ...
Using indicators from this table, failures can be detected 
Highly increas. leakage Ind. I H2 ;valve = 8
during operation of the system. The isolation of failures
can be started in the next step. However, as there are High
generally more failures that lead to the same effect, in the Ind. p = Low 7
current case a decreased voltage, assigning a specific fail- ... ...
ure might not always be possible. Leakage of the air pipe FC stack A ... ... ...

and mass transportation losses of fuel cell stack A are Mass transp. losses Ind. I H2 ;valve = 8
illustrative examples. To be able to localize the failure, High
further indicators are taken into account. These are related ... ...
only to the failure isolation. Table 2 shows an exemplary Purge module Breakdown Ind. m_ H2 = Low 1
summary. Chosen features are measurements of mass flow ... ... 1
and temperature amongst others.
It has been shown, that a high leakage of the air pipe make these specific failures detectable, further indicators
does not only cause a drop in voltage but also a decrease in are taken into account. In this case study, these indicators
air mass flow m_ provided to the fuel cell stacks. This are based on measurements of pressure and valve control
indicator is not needed to detect the system function rele- current amongst others. The relation between failures and
vant failure, but can help in the isolation of the origin of the indicators is summarized in Table 3
decreased voltage. The same applies for the indicator of a Increased friction in the compressor has no direct effect
low temperature T of hydrogen H2 at the outlet of fuel cell on any of the system functions. Electrical power can be
stack A. By means of these indicators, the two failures of delivered at the same quality as well as exhaust gas and
the example could be isolated explicitly. That is the reason water. However, a direct effect can result if the failure
why these indicators are declared as having a maintenance progresses further or the system reaches a certain opera-
effect. Not all failures have a direct effect on any of the tional state. That is a reason why the failure should be
system functions. This is due to redundancy and time made detectable. This can be done by means of the indi-
dependent propagation of failure effects. By that, these cator PC = High, which represents higher power con-
failures potentially remain hidden in the system. An sumption in the compressor compared to the nominal state.
example of the case study is a breakdown of the purge In general, indicators of the class of potentially latent
module from Fig. 6. In the specific case, the fuel cell stacks failures may also relate to failures that have an actual effect
are still operational for a period of time and no effect on on the system functions. The high leakage of the air pipe
system function is observed. The same applies for an has an effect on system pressure and on the valve control
increased friction of the compressor. However, reaching a current of the hydrogen supply which is part of a control
certain operational state, a loss of system function can loop. Therewith, these indicators can provide further
occur. An example would be a hydrogen clogging in the information for failure isolation. If they also enable the
fuel cells due to a breakdown of the purge module. To detection of the potentially latent failures, they may be

123
SPYDER: a software package
optimal choices as the synergies are high. An answer on the
selection of optimal indicators will be given in Sub-
sect. 7.2. All indicators of the three classes are related to
features, which are based on measurements from sensors.
Sensors are prone to failures as well. To offer specific
means to detect such failures and isolate them to be root
cause of the effects introduced previously, a fourth class of
indicators with respective table is taken into account. The
structure of the table is similar to the previous ones. For
further information please refer to [29]. All tables are
stored as Excel data sheets, which are input to the indicator
and sensor selection module.
7.2 Indicator and sensor selection
A maximal sensor-feature architecture has been defined by
engineering judgment. This leads to multiple indicators
where each failure that has been simulated is linked to at
least one indicator. The indicator and sensor selection
module deals with the identification of an optimal minimal
set of all indicators and their related sensors. This is based
on requirements that determine the detectability of relevant
failures and the isolation of root causes to a specific level of
detail. The Data from the first SPYDER module is con-
tained in Excel data sheets, which are now analyzed in
detail. The last column of the data sheets provides infor-
mation about the interval and specific points of time, where
indicators are detected. This information is used to analyze
specific traces of failures by taking into account the tem-
poral occurrence of the related indicators. This can provide
further means for pinpointing sources of failures. It defines
the concept of complex indicators. An example is given by
means of Eq. 7:
followedby
High leakage of air pipe : p Low !
7
IH 2 ;valve high
declares
! Compl. Ind.16.
It has been shown, that a high leakage from the air pipe
leads to a decreased mass flow of air at the inlet of fuel
stack A. A drop in pressure follows likewise. Analyzing the
temporal occurrence of all respective indicators, it can be
shown, that for this particular failure the drop in pressure is
always followed by an increase of valve control current
influencing the mass flow of hydrogen provided to the fuel
cell stack. In the example, a trace of two indicators was
taken into account. However, the indicator and sensor
selection module provides means to the user to set the
maximal length of existing traces to be considered. The
relation between failures and simple as well as complex
indicators is transferred into failure indicator matrices. An
illustrative example is depicted in Fig. 12. There are 20
matrices, which are related to four classes of failures and
five classes of indicators. The total amount of failures is
325
separated into sub-sets of failures, which have an effect on
the system functions to be performed, which have no direct
effect on system functions, and those failures related to
sensors and interfaces. According to the failure indicator
tables and the previous analysis, the indicators are sepa-
rated into sub-sets of indicators, which are related to the
system function, to latent failures, to failure localization,
sensor failure and the temporal occurrence. The leakage of
an air pipe highlights the link between failure and indica-
tors in Fig. 12.
The relations between failures and indicators are trans-
ferred into indicator sets. These are specific patterns, which
are f2; 3g, f5; 6g, f7g for the example of the high leakage
of the air pipe. The relation between indicator and sensor is
stored in a directed graph as shown in Fig. 13. Furthermore,
the graph comprises the link between simple and complex
indicators by means of the logical and. The sets and the
graph are evaluated stepwise to identify an optimal com-
bination of indicators and sensors which enable the
detection of all relevant failures and the localization
according to a required level of detail.
The basic approach for evaluation is presented in [30]. It
is based on the theory of minimal hitting sets 31]. The
focus is on failures and indicators with respect to the sys-
tem functions. Further indicators, which are needed for a
required level of failure isolation are identified. Optimality
is defined in terms of maximal divergence of indicators and
the amount of sensors. A sensor recommendation for
failure diagnosis is given. An extension of this approach
considering failures with no direct effect on system func-
tions, complex indicators and multiple criteria of optimal-
ity is introduced in [32]. In relation to the example this
means, if the indicators f5g and f6g which are Ind. IH2 ;valve
= High, and p = Low, are part of an optimal minimal set for
the detection of all relevant failures, the complex indicator
f16g would be activated by means of the directed graph for
failure localization. It thus comes for free without raising
the effort. Apart from hard facts, like amount of sensors
and indicators, as well as weight of wiring for sensors,
diagnostic performance is taken into account in determin-
ing optimality. This concerns ambiguity groups of failures
that all point to the same indicators. Nevertheless, the basis
of diagnostic performance is mainly influenced by the
requirements. There, it is explicitly defined, which level of
failure isolation should be achieved during operation.
Sensors are prone to failures as well. This has to be con-
sidered during the design of diagnosis functions. Sensor
failures can lead to false alarms, NFF or latent failures of
other system components. An approach for handling of
sensor failures is introduced in [29]. Based on the directed
graph and a specific set of indicators, dedicated sensor
failures of the respective matrix are activated and consid-
ered during the evaluation of all the matrices. In case of the
123
326 C. Modest and F. Thielecke

Ind. U* = Low Ind. p* = Low Ind. m* = Low Ind. U*M.Sens. = Low complex Indicator

Ind.10

Ind.12
Ind.13

Ind.14
Ind.15
Ind.16
Ind.11
Ind.1
Ind.2
Ind.3

Ind.4
Ind.5
Ind.6

Ind.7
Ind.8
Ind.9
{
FM 1
: : 1.Failures that effect
Highly increased FM D system functions
leakage of air pipe FM F

FM G

Increased friction
of compressor
:
FM I
:
{ 2.Failures without direct effect
on system functions

{
FM J
: : 3.Sensor failures
Loss of mass flow FM R
sensor lane

{
Interface failure FM S
ATA24 : : 4.Interface failures
FM Z
{
{
{
{
{
1.Indicators related 3.Indicators related 5.Complex indicators
to system functions to failure localization
2.Indicators related 4.Indicators related
to latent failures to sensor failures

Fig. 12 Failure indicator matrices showing the relation between failures and indicators.

sensor 2 7.3 Rule generation

sensor 3 voltmeter
sensor 1
feature
indicator
& An optimal set of indicators has been identified using the
complex indicator
Fig. 13 Directed graph that contains the relation between sensors,
indicators and complex indicators.
example, specific failures of the voltmeter would be taken
into account amongst others. Interface failures are listed as
a fourth group, but do not need to be dealt with by an
extended analysis. They are important when it comes to the
configuration phase of diagnosis functions. Summarizing
the result of the indicator and sensor selection module, an
optimal set of indicators and sensors, as well as failure
indicator matrices are gained. For the case study, 12 indi-
cators are required for failure detection, two indicators are
required to assure the root cause isolation under all cir-
cumstances, and 20 complex indicators are accompanying
all relevant simple indicators.
The rule generation module deals with the transformation
of failure indicator matrices and complex indicators into a
set of exact diagnosis rules. For deeper analysis of failure
characteristics fuzzy diagnosis rules are trained in the end.
previous module. Therewith, the failure indicator matrices
can be reduced to the valid columns. These columns are
now combined and transferred into four sets of exact
diagnosis rules. These are deduce rules, detect rules, sus-
pect rules and clear rules. All the rules consist of a premise
and a conclusion. The activation of the premise will lead to
a firing of the rule and new facts are gained that are based
on the rules conclusion. The detection agent utilizes
deduce rules for the deduction of complex indicators from
the temporal occurrence of simple indicators:
if p Low followed by IH 2 ;valve High
8
then deduce complex indicator 16 = true:
Different indicators are combined by the detection agent to
reveal symptoms. This is done by means of detect rules.
Four cases are distinguished. The first case is illustrated in
Eq. 9. It deals with symptoms related to the system

123
SPYDER: a software package
functions. Indicators of class one according to Fig. 12 are
combined with the operational condition Ops to detect
primary symptoms:
if U  Low and I  High and ... and Ops Load
then detect primary Symptom 1:
9 if secondary Symptom 1 = true then clear
Equation 10 depicts the second case. It is about symptoms
without direct relation to any of the system functions.
Indicators of the classes one and two are combined and
indicators of class one possess nominal values:
if U  Nom and I  Nom and ... and p Low
and Ops Load
then detect primary Symptom 2:
10
Sensor failures can lead to the detection of primary symp-
toms of the previous two cases. If there is no link, indicators
of class four are used for the detection of symptoms, so that
these sensor failures do not remain hidden in the system.
Indicators of the classes one and four are combined and
indicators of class one possess nominal values:
if U  Nom and I  Nom and ... and

UM:Sens Low and Ops Load 11
then detect primary Symptom 3:
All previous indicators are used to detect symptoms of
abnormal behavior and trigger the failure localization in the
fusion agent. Hence, they are called primary indicators.
Extensions of the specific patterns in the rules premises are
done by means of secondary indicators. These belong to the
classes two, three, four and five and are used for the
detection of secondary symptoms. These are symptoms,
which are accompanying primary symptoms and help
failure localization:
if primary Symptom 1 true and m
_ Low
12
then detect secondary Symptom 1:
The fusion agent combines all symptoms to generate and
test hypotheses about sources of failures. These tasks are
performed by means of two rules that are gained from the
columns of the failure indicator matrices. Suspect rules
mark the starting point for the reasoning procedure about
failures and symptoms:
if primary Symptom 1 = true then suspect
FM 1; . . .; Leakage of Air pipe, Mass transp. 13
Losses of FC Stack A:
The conclusion of a suspect rule constitutes a list of
hypotheses, which are potential sources of failures. Each
327
element of the list can fully explain the detected primary
symptom. However, the list of suspects can be long so that
secondary symptoms are taken into account to test the
necessary condition for the particular hypothesis. This is
done by means of clear rules:
14
FM 1, Mass transp. Losses of FC Stack A:
Failures that cannot explain the secondary symptoms are
cleared from the list of suspects and tested to be failure
free. The list of suspects is reduced therewith. Hence, the
final diagnosis is inferred by means of several clear rules. A
list of potential sources of failure is gained in the end which
can explain all observed symptoms. All elements of this list
are hypotheses that could equally have caused the abnor-
mal behavior. In a continuation of the previous example,
the high leakage of the air pipe can be localized explicitly.
This is done by one suspect rule and one clear rule.
Another example is given in Fig. 14. There, a failure
occurred in the system and the respective effects can be
detected by means of two primary indicators. The primary
symptom four is assigned and a list of suspects is gained.
This list is already a small part of the overall system that
could have caused the symptom. By means of one sec-
ondary indicator, the secondary symptom 23 is detected. A
clear rule leads to the final diagnosis of three suspects of
the hydrogen supply. The way this result is gained is
transparent and well documented which marks a major
aspect of the SPYDER approach. The diagnostic result is
based on a chosen requirement for the design of the diag-
nosis functions. This requirement said, that air supply,
hydrogen supply and fuel cell stacks should always be fully
separable. This is the case for the current example. A finer
granularity is not possible and could only be achieved
when relying on exact diagnosis rules by further sensors
and indicators. However, the characteristics of the failure
have not been taken into account yet. This offers the pos-
sibility for a deeper failure analysis. The characteristics of
all final suspects of the previous example are depicted in
Fig. 15. It shows the deviation between the observed fea-
ture IH2 ;valve and the threshold, related to the threshold.
It is obvious that the failure mode three of the hydrogen
valve has a much higher effect on the observed deviation
than the failure modes four and five of the hydrogen pump.
Hence, this specific feature offers means for a detailed root
cause identification. This is carried out with fuzzy logic
and fuzzy inference as is indicated in the right part of
Fig. 15. There, the range of the deviations is divided into
three parts, which are low, medium and high deviation.
These parts are each characterized by fuzzy membership
functions which allow the determination of a matching
degree l which lies within the continuous range [0, 1]. The
123
328 C. Modest and F. Thielecke

Failure Ops if IH2 ;valve has characteristic high

Effects Prim.Symptom 4 Suspect 15
Rule then assign H2 Valve - FM 3:

Suspected Candidates The specific fuzzy diagnosis rule says that in the case that
Prim.Indicators
Air Valve B - FM 2 the failure characteristic is high the failure mode three of
I_fc1_nom
Air Valve B - FM 3 the H2 valve is assigned. The significance of this rule is
I_fc2_low
FC Stack B - FM 4 transformed to a certainty factor for the failure mode. This
FC Stack B - FM 5
Sec.Indicator
H2 Pump B - FM 4 is done by means of the ratio of the matching degree ln ci
IH2,valve = High of the specific rule n with conclusion FMn and character-
H2 Pump B - FM 5
Effects

H2 Valve B - FM 3 istics c related to the matching degrees of all other fuzzy

diagnosis rules. The generalized scheme is shown in
Eq. 16.
Sec.Symptom 23 P
Ops

c;FMFMn ln c
Clear Rule FM P ; ln c [ 0: 16
c ln c
Clear Candidates Resolution
Air Valve B - FM 2 By applying Eq. 16 a certainty factor H2ValveFM3 of 90%
Air Valve B - FM 3 - can be determined in the current example. To always come
FC Stack B - FM 4 to a correct certainty degree by means of the fuzzy infer-
FC Stack B - FM 5 ence, some challenges arise. On the one hand, the width of
the membership functions has to be determined. On the
MFFCS with Final Diagnosis other hand, the amount of functions has to be defined,
Failure H2 Pump B - FM 4 either low, medium, high like in the example, or very low,
H2 Pump B - FM 5
H2 Valve B - FM 3 low,...,high, very high, or further increments. Finally, it has
to be evaluated which indicator characteristics have to be
Air Valve B - FM 2 : half opened FC Stack B - FM 5 : cell failures
Air Valve B - FM 3 : stuck closed H2 Pump B - FM 4 : blockage combined using the fuzzy inference. An approach to cope
FC Stack B - FM 4 : reduced efficiency H2 Pump B - FM 5 : high leakage
H2 Valve B - FM 3 : stuck closed
with all the challenges is presented in [22]. There, a genetic
optimization procedure is used to derive the optimal shape
Fig. 14 Utilizing suspect and clear rules to infer root causes of a of membership functions, the required amount, as well as
detected failure. the required patterns in the specific rules premise. Hence,
finally a diagnostic result is gained, that consists of a list of
rated suspects. It is achieved in a documented way and
characteristic IH2,valve [-]

characteristic IH2,valve [-]

H2 Valve B - enables the planning of maintenance actions.

FM 3 high
Fuzzy
membership 7.4 Configuration of diagnosis engine
function med.
The configuration of the diagnosis engine deals with the
H2 PUMP B -
FM 4 / FM 5 utilization of diagnosis rules. Executable diagnosis func-
low tions are gained. In the consequence the step 5 of the
proposed development approach according to Fig. 3 is
0 0 supported. This enables the steps 6 and 7 which covers the
t t
integration phase. However, that is not in the focus of this
Fig. 15 Taking into account the failure characteristics for root cause paper. At this point several exact and Fuzzy diagnosis rules
localization. exist. The configuration of diagnosis engine module deals
with the management of these rules and the configuration
of the diagnosis engine. This is depicted in Fig. 16.
combination of matching degrees for several indicator All diagnosis rules are saved in a xml data format and
characteristics enables the assignment of a certainty degree stored in a xml database. Python scripts, templates to be
to each suspect of the final diagnosis. This task is per- filled and xslt techniques are used to automatically inter-
formed by means of fuzzy diagnosis rules and fuzzy rogate the database and transfer required data into different
inference. An example of a fuzzy diagnosis rule is illus- diagnosis modules. The latter adapt the core of all diag-
trated in Eq. 15. nosis agents to the specific target system. This means that

123
SPYDER: a software package
exact diagnosis rules
.xml
Fuzzy diagnosis rules
Database
.xml
Configuration scripts & templates
Diagnosis modules
exact
behavior
behavior
Diagnosis engine
Fix core Fix core
Exact part Fuzzy part
Fig. 16 Overview of the configuration of diagnosis engine module.
the diagnosis modules are related to the detection of
symptoms, the execution of logical resolution and fuzzy
inference as well as the provisioning of outputs to the user.
An example of a part of one of the modules of the detection
agent looks like follows:
The code highlights one detect rule. The primary symptom
4 is detected if the premise is fulfilled. This is the case if
the operational condition equals Load and the indicators
possess values of Nom and Low. All diagnosis modules are
loaded by the diagnosis engine. The latter consists of
several diagnosis agents. These agents are assigned to an
exact and a fuzzy part of the engine. Both parts are
implemented by adapting the rule-based expert system
CLIPS [19]. By that, executable diagnosis functions are
gained in the end. The gap between defining diagnosis
requirements and implementing and executing diagnosis
functions is finally closed.
329
8 Conclusion
Current statistics indicate that there are deficits in the
implementation and development of diagnosis functions
for aircraft systems. High rates of NFF and long times of
AOG demonstrate ongoing weaknesses. In the consequence
and with respect to ambitious goals for the future of
European air traffic, more powerful diagnosis functions are
required. This is addressed in the paper at hand by means
of the SPYDER concept. The latter is a systematic
approach for the design, test and implementation of diag-
nosis functions for aircraft systems supported by a model-
based tool chain Three key questions concerning the
development of diagnosis functions have been formulated
in Sect. 3. These are repeated in the following and
Fuzzy
answered according to the content of the paper.
1. How can the design and test of diagnosis functions be
standardized?
The design and test of diagnosis functions is standardized
according to systems engineering principles. Integrated
into the common V-model, seven steps are run through.
This starts with the definition of requirements, proceeds
further to coding and ends with a virtual integration test.
Main issues like completeness with respect to failure
modes, diverge of indicators, and groups of unambiguous
failures are handled and documented systematically.
2. How can knowledge of failures be encoded for the
specific target system?
The knowledge of failures and effects is encoded system-
atically in failure-indicator matrices. These are gained from
simulation studies performed on basis of physical models.
The matrices are transformed into diagnosis rules. The
latter are used to configure a diagnosis engine. Hence, in
form of diagnosis rules, a human readable and transparent
format has been chosen that enables a good traceability and
documentation.
3. What will efficient diagnosis functions look like which
can support a variety of aircraft systems?
A multi-agent concept in terms of a diagnosis engine has
been introduced. This consists of several generic comput-
ing instances with clear functions and interfaces. An
example is the detection agent, which performs a detection
of symptoms by means of indicator patterns. All the agents
are based on a rule-based expert-system. The latter com-
prises a generic core that is adapted to the specific function
and aircraft system by means of the diagnosis rules. A
flexible support of a variety of aircraft systems is achieved
thereby. The configuration of each agent is performed
efficiently by means of standardized xml techniques and
123
330
templates In a case study, the SPYDER concept has been
applied to a multifunctional fuel cell system. Valuable
results were gained which demonstrate that a good benefit
in the support of the development and implementation of
diagnosis functions for complex aircraft systems is
achieved. The focus of this paper was on a method for the
development of diagnosis functions for failure detection,
isolation and identification. A point of current research is
the extension of the method to also deal with faults. This
can be achieved in two ways. The first one consists of an
extension of the class of failures that do not have any direct
effect on the system functions. This class can also hold
faults which by definition have no direct effect on system
functions. However, it has to be analyzed if discrete indi-
cators are appropriate also for fault diagnosis. Therefore,
the second way consists of an extension of the right branch
of the diagnosis engine. The fuzzy part is extended so that
not only certainties for failures are provided but at specific
operational states the system behavior is evaluated to infer
faults. This has the advantage that feature values are ana-
lyzed quantitatively rather than condensed to discrete
indicators. A better analysis of the actual system behavior
seems achievable by that. Apart from faults, interface
failures have to be considered in more detail. A new class
of diagnosis rules is under development for that.
References
1. European Commission: Flightpath 2050 - Europes vision for
aviation. Report of the high level group on aviation research (2011)
2. European Organisation for the Safety of Air Navigation: Perfor-
mance review report: an assessment of air traffic management in
Europe during the calendar year 2012. Eurocontrol-Performance
Review Commission, Brussels (2013)
3. European Organisation for the Safety of Air Navigation: Coda
digestdelays to air transport in Europeannual 2012. Euro-
control-Central Office for Delay Analysis, Brussels (2013)
4. Pecht, M., Dube M., Natishand M., Williams R., Banner J.:
Evaluation of built-in test. IEEE Trans. Aerosp. Electron. Syst.
37, 266271
5. Isermann, R.: Fault-diagnosis systems: an introduction from fault
detection to fault tolerance. Springer, Berlin (2006) (ISBN
9783540303688)
6. Blanke, M., Schroder, J.: Diagnosis and fault-tolerant control,
2nd edn. Springer, Berlin (2006) (ISBN 9783540356530)
7. Ding, S.:Model-based fault diagnosis techniques: design
schemes, algorithms, and tools. Adv Ind Control. Springer,
London (2013) (ISBN 9781447147992)
8. Vachtsevanos, G.:Intelligent fault diagnosis and prognosis for
engineering systems. Wiley, Hoboken (2006) (ISBN
9780471729990)
9. International Organization for Standardization (ISO):Condition
monitoring and diagnostics of machinesdata processing, com-
munication and presentationpart 1: general guidelines (2003)
10. Wilmering, T.J., Davies, P.: Health management systems engi-
neering. In: Jennions, I.K. (ed.) Integrated vehicle health
123
C. Modest and F. Thielecke
managementperspectives of an emerging field, pp 4154. SAE
International, Warrendale (2011)
11. Scandura, P.A: Integrated vehicle health management as a system
engineering discipline. The 24th digital avionics systems con-
ference (DASC) (2005)
12. Kurtoglu, T., Stephen, B. J., Barszcz E., Johnson, R. J., Robinson,
P. I.: Integrating system health management into the early design
of aerospace systems using functional fault analysis. IEEE
international conference on prognostics and health management
(2008) (ISBN 9778-1-4244-1936-4)
13. Kacprzynski, G.J., Roemer, M.J., Hess, A.J., Bladen, K.R.:
Extending FMECA-health management design optimization for
aerospace applications. IEEE aerospace conference 2001, 6,
31053112 (2001)
14. Niculita, O., Jennions, I.K.:Use of COTS functional analysis
software as an IVHM design tool for detection and isolation of
UAV fuel system faults. In: Roychoudhury, I., Celaya, J.R.,
Saxena, A., (eds) Proceedings of the annual conference of the
prognostics and health management society 2012, PHM society,
2845. (2012) (ISBN 978-1-936263-05-9)
15. Bunus, P., Isaksson, O., Frey, B., Munker, B.: Model-based
diagnostics techniques for avionics applications with Rodon. In:
von Estorff, O., Thielecke, F. (eds) Proceedings of the 2nd
international workshop on aircraft system technologies. Shaker
(2009) (ISBN 978-3-8322-8071-0)
16. Hess, A., Fila, L.: The joint strike fighter (JSF) PHM concept:
potential impact on aging aircraft problems. IEEE aerospace
conference proceedings, 6, 30213026 (2002)
17. Felke, T., Hadden, G.D., Miller, D., Mylaraswamy, D.:Archi-
tectures for integrated vehicle health management. AIAA pro-
ceedings, 2010. AIAA infotech aerospace conference (2010)
18. Keller, K., Wiegand, D., Swearingen, K., Reisig, C., Black, S.,
Gillis, A., Vandernoot, M.: An architecture to implement inte-
grated vehicle health management systems. AUTOTESTCON
proceedings, 2001. IEEE systems readiness technology confer-
ence, pp. 215 (2001)
19. Giarratano, Joseph C.: Expert systems: principles and program-
ming. The PWS series in computer science. PWS Publ. Co.,
Boston (1994). (ISBN 0-534-93744-6)
20. Haskins, C. (ed): Systems engineering handbooka guide for
system life cycle processes and activities. INCOSEinterna-
tional council on systems enginnering, 3rd ed (2006)
21. Raksch, C.: Eine Methode zur optimalen Redundanzallokation im
Vorentwurf fehlertoleranter Flugzeugsysteme. Ph.D. Hamburg
University of Technology (2013)
22. Modest, C., Thielecke, F.: Derivation of fuzzy diagnosis rules for
multifunctional fuel cell systems. In: Bregon, A., Daigle, M.J.
(eds.) Proceedings of the European conference of the prognostics
and health management society 2014, PHM society, pp 643653.
(2014) (ISBN 978-1-936263-16-5)
23. Law, B.: Airbus multifunctional fuel cell integration. Deutscher
Luft- und Raumfahrtkongress (DLRK) 2012, Berlin. (2012)
24. Grymlas, J., Thielecke, F.:Modellbasierter Entwurfsprozess fnr
Brennstoffzellensysteme unter Verwendung eines mehrstufigen
Bibliothekskonzepts. Deutscher Luft- und Raumfahrtkongress
(DLRK) 2012, Berlin, Deutsche Gesellschaft fur Luft- und
Raumfahrt (2013)
25. Herwig, H.:Stromungsmechanik: Eine Einfuhrung in die Physik
und die mathematische Modellierung von Stromungen. Springer,
Berlin (2006) (ISBN 3540324410)
26. Pukrushpan, J.T.: Modeling and control of fuel cell systems and
fuel processors. Dissertation, The University of Michigan (2003)
27. Neumann, U.:Methoden zur signal- und modellbasierten Last-
begrenzung in verzweigten mechanischen Landeklappen-An-
triebssystemen von Transportflugzeugen, volumeBd. 2009, 2 of
SPYDER: a software package
Schriftenreihe Flugzeug-Systemtechnik. Shaker, Aachen (2009)
(ISBN 978-3-8322-8314-8)
28. (U.S.), Reliability Analysis Center: Failure mode/mechanism
distributions, Reliability Analysis Center (1997)
29. Modest, C., Thielecke, F.: Methodik zum integrierten Entwurf
optimierter Diagnosefunktionen fur Hochauftriebssysteme.
Deutscher Luft- und Raumfahrtkongress (DLRK) 2013, Stuttgart.
Deutsche Gesellschaft fur Luft- und Raumfahrt (2013)
30. Modest, C., Thielecke, F.:A design methodology of optimized
diagnosis functions for high lift actuation systems. In: Roy-
choudhury, I., Celaya, J.R., Saxena, A. (eds.) Proceedings of the
331
annual conference of the prognostics and health management
society 2012, PHM Society, pp 233248. (2012) (ISBN 978-1-
936263-05-9)
31. Reiter, R.: A theory of diagnosis from first principles. In: Elsevier
(ed.) Artificial intelligence, 32, 5795. Elsevier, Essex (1987)
32. Modest, C., Thielecke, F.: Multi-objective design of optimized
diagnosis functions for high lift actuation systems. SAE aerotech
congress and exhibition 2013, Montreal. SAE international
(2013)
123