robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

OK another night at work...after work

Browse Source
This commit is contained in:
Robin Clark 2011-05-31 20:35:31 +01:00
parent 5a67a48ef5
commit 3607ac6c65
6 changed files with 389 additions and 155 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
fmmd_concept/System_safety_2011/Makefile Normal file
View File

@ -0,0 +1,14 @@
DIAPNG=component.png fmmd_env_op_uml.png master_uml.png
%.png:%.dia
dia -t png $<
all: $(DIAPNG)
pdflatex submission
acroread submission.pdf
bib:
bibtex submission

BIN
fmmd_concept/System_safety_2011/component.dia Normal file
View File

Binary file not shown.

BIN
fmmd_concept/System_safety_2011/fmmd_env_op_uml.dia Normal file
View File

Binary file not shown.

BIN
fmmd_concept/System_safety_2011/master_uml.dia Normal file
View File

Binary file not shown.

410
fmmd_concept/System_safety_2011/submission.tex
View File

@ -37,25 +37,19 @@ failure mode of the component or sub-system}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
%\newtheorem{definition}{Definition:}
\begin{document}
\pagestyle{fancy}
\fancyhf{}
%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
\fancyhead[LO]{}
\fancyhead[RE]{\leftmark}
%\fancyfoot[LE,RO]{\thepage}
\cfoot{Page \thepage\ of \pageref{LastPage}}
\rfoot{\today}
\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
%\outerhead{{\small\bf Developing a rigorous bottom-up modular static failure mode modelling methodology}}
%\innerfoot{{\small\bf R.P. Clark } }
% numbers at outer edges
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\
$^\star${\em Energy Technology Control, Lewes,UK} \and $^\dagger${\em University of Brighton, UK}
\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\
$^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK}
}
\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
@ -71,34 +65,6 @@ improve the product safety, or identify theoretical weaknesses in the design.
This paper proposes a new theoretical methodology for creating failure mode models of safety critical systems.
It has a common notation for mechanical, electronic and software domains and is modular and hierarchical.
These properties provide advantages in rigour and efficiency when compared to current methodologies.
% This paper proposes a methodology for
% creating failure mode models of safety critical systems, which
% has a common notation
% for mechanical, electronic and software domains and applies an
% incremental and rigorous approach.
%
% The four main static failure mode analysis methodologies were examined and
% in the context of newer European safety standards, assessed.
% Some of the deficiencies identified in these methodologies led to
% a wish list for a more rigorous methodology.
% %%
%% What I have found
%%
% From the wish list
% %and considering some constraints determined from
% %the evaluation of the four established methodologies,
% a new
% methodology is developed and proposed.
% This has been named Failure Mode Modular De-Composition (FMMD).
%
% %% Sell it
% %%
% In addition to addressing the traditional weaknesses of
% Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticality Analysis (FMECA)
% and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios
% as specified in newer European Safety Standards \cite{en298}.
% The proposed methodology is bottom-up and can guarantee to leave no component failure mode un-handled.
% It is also modular, meaning that the results of analysed components may be re-used in other projects.
}
\section{Introduction}
@ -139,7 +105,7 @@ analyse how particular components may fail.
FMECA is a refinement of FMEA, using
two extra variables: the probability of a component failure mode occurring
and the probability that this will cause a top level failure, and the perceived
criticality. It gives better estimations of product reliability/safety and the
criticallity. It gives better estimations of product reliability/safety and the
occurrence of particular system failure modes than FMEA but has similar deficiencies.
@ -156,20 +122,23 @@ via self checking statistical mitigation.
\subsection{Summary of Defeciencies in Current Methods}
\paragraph{Top Down approach} The top down technique FTA, introduces the possibility of missing base component
level failure modes~\cite{faa}[Ch.9]. Also one FTA treee is drawn for each top level
event, leading to repreated work, with limitied ability for cross checking/model validation.
\subsubsection{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
level failure modes~\cite{faa}[Ch.9]. Also one FTA tree is drawn for each top level
event, leading to repeated work, with limited ability for cross checking/model validation.
\subsubsection{Bottom-up approach: FMEA, FMECA, FMEDA}
\paragraph{State Explosion problem}
The bottom -up techniques all suffer from a problem of state explosion.
To perform the analysis rigorously, we need to consider the effect
of a component failure agiaist all other components. Adding environmental
of a component failure against all other components. Adding environmental
and operational states further increases this effect.
Let N be the number of components in our system, and K be the average number of component failure modes
(ways in which a base~component can fail). The total number of base component failure modes
Let N be the number of components in our system, and K be the average number of component failure modes
(ways in which a component can fail). The total number of base component failure modes
is $N \times K$. To examine the effect that one failure mode has on all
the other components\footnote{A base component failure will typically affect the sub-system
the other components\footnote{A %base
component failure will typically affect the sub-system
it is part of, and create a failure effect at the SYSTEM level.}
will be $(N-1) \times N \times K$, in effect a very large set cross product.
If $E$ is the number of environmental conditions to consider
@ -186,96 +155,347 @@ To look in detail at a half of a million test cases is obviously impractical.
% Requirements for an improved methodology The deficiencies identified in the
% current methodologies are used to establish criteria for an improved methodology.
\paragraph{Reasoning distance - complexity and reachability}
\paragraph{Reasoning distance - complexity and reach-ability.}
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
working heuristically. A base component failure will typically
be conceptually removed by several stages from a top level event.
The `reasoning~distance' $R_D$ can be calculated by summing the number of components
involved, multiplied by the number of failure modes in each component,
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
that must interact to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
$c_i$ represents a component in $C$ and
the function $fm$ returns the failure modes for a given component, equation
\ref{eqn:complexity}, returns a value representing the complexity
from the base component failure to the SYSTEM level event.
\ref{eqn:complexity}, returns the `reasoning~distance'.
\begin{equation}
R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
\label{eqn:complexity}
\end{equation}
The reasoning distance is a value representing the number of failure modes
to consider to rigorously determine the causation chain
from the base component failure to the SYSTEM level event.
The reasoning distance serves to show that when the causes of a top level
event are completely determined, a large amount of work not
typical of heuristic or intuitive interpretation is required.
% could have a chapter on this.
% take a circuit or system and follow all the interactions
% to the components that cause the system level event.
\paragraph{Multiple Events from one base component failure mode}
A base component failure may mpotentially cause more than one
A base component failure may potentially cause more than one
SYSTEM level failure mode.
It could be possible to identify one top level event asssociated with
It could be possible to identify one top level event associated with
a {\bcfm} and not investigate other possibilities.
\section{Requirements for a new static failure mode Analysis methodology}
%\section{Requirements for a new static failure mode Analysis methodology}
A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up,
starting with individual component failure modes.
In order to control the state explosion problem, the process must be modular
and deal with small groups of components. The design process follows this
rationale, sub-systems are build to perform often basic functions from base components.
We can term these small groups {\fgs}.
Components should be collected
into small functional groups to enable the examination of the effect of a
component failure mode on the other components in the group.
Once we have the failure modes, or symptoms of failure of a {\fg}
it can now be considered as `derived component' with a known set
of failure symptoms. We can use this `derived component' to build higher level
functional groups.
This helps with the reasoning distance problem,
because we can trace failure modes back through complex interactions and have a structure to
base our reasoning on, at each stage.
\section{A wish list for a failure mode methodology}
From the deficiencies outlined above, we can form a wish list for a better methodology.
{ \small
\begin{itemize}
\item It must address the state explosion problem.
\item It must ensure that all component failure modes be considered in the model.
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
\item It should have a formal basis, that is to say, be able to produce mathematical traceability
for its results, such as error causation trees.%, reliability and safety statistics.
\item It should be easy to use, ideally using a
graphical syntax (as opposed to a formal symbolic/mathematical text based language).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional groupings \cite{maikowski}.
\item It must be possible for multiple (simultaneous) failure modes to be modelled.% from the base component level up.
\end{itemize}
}
% A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up,
% starting with individual component failure modes.
%
% In order to control the state explosion problem, the process must be modular
% and deal with small groups of components. The design process follows this
% rationale, sub-systems are build to perform often basic functions from base components.
% We can term these small groups {\fgs}.
%
% Components should be collected
% into small functional groups to enable the examination of the effect of a
% component failure mode on the other components in the group.
% Once we have the failure modes, or symptoms of failure of a {\fg}
% it can now be considered as `derived component' with a known set
% of failure symptoms. We can use this `derived component' to build higher level
% functional groups.
%
% This helps with the reasoning distance problem,
% because we can trace failure modes back through complex interactions and have a structure to
% base our reasoning on, at each stage.
%
%Development of the new methodology
\section{An ontology of failure modes}
An ontology is developed of
An ontology is now developed of
failure modes and their relationship to environmental factors,
operational states and the hierarchical nature inherent in product design,
applied/operational states and the hierarchical nature inherent in product design,
defining the relationships between the system as a whole, components,
failure modes, operational and environmental states.
DEVELOP UML MODELS
Components have sets of failure modes associated with them.
Failure modes for common components may be found in
the literature~\cite{fmd91},~\cite{mil1991}.
We can associate a component with its failure modes.
This is represented in UML in figure \ref{fig:component_concept}.
\begin{figure}[h]
\centering
\includegraphics[width=200pt,keepaspectratio=true]{./component.png}
% component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
\caption{Component with failure modes UML diagram}
\label{fig:component_concept}
\end{figure}
\subsection{Modular Design}
When designing a system from the bottom-up, small groups of components are selected to perform
simple functions. These can be termed {\fgs}.
When the failure mode behaviour, or symptoms of failure
of a {\fg} are determined, it can be treated as a component in its own right.
% Functional groups
% are then brought together to form more complex and higher level {\fgs}.
Used in this way the {\fg} has become a {\dc}. The symptoms of failure
of the {\fg} can be considered the failure modes of its {\dc}.
Derived~Components can be used to create higher level {\fgs}.
Repeating this process will lead to identify-able higher level
groups, often referred to as sub-systems. We can call the entire collection/hierarchy
of sub-systems the SYSTEM.
\subsection{Environmental Conditions, Operational States}
Any real world sub-system will exist in a variable environment
and may have several modes of operation.
In order to find all possible failures, a sub-system
must be analysed for each operational state
and environmental condition that could affect it.
%
A question is raised here: which objects should we
associate the environmental and the operational states with ?
There are three objects in our model to which these considerations could be applied.
We could apply these conditions
to {\fgs}, components, or {\dcs}.
\paragraph {Environmental Conditions.}
Environmental conditions are external to the
{\fg} and are often things over which the system has no direct control.
Consider ambient temperature, pressure or even electrical interference levels.
%
Environmental conditions may affect different components in a {\fg}
in different ways.
For instance, a system may be specified for
$0\oc$ to $85\oc$ operation, but some components
may show failure behaviour between $60\oc$ and $85\oc$
\footnote{Opto-isolators typically show marked performance decrease after
$60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
Other components may operate comfortably within that whole temperature range specified.
Environmental conditions will have an effect on the {\fg} and the {\dc},
but they will have specific effects on individual components.
It seems obvious that
environmental conditions should apply to components.
%A component will hold a set of environmental states that
%affect it.
\paragraph {Operational States}
Sub-systems may have specific operational states.
These could be a general health level, such as
normal operation, graceful degradation or lockout.
Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
Operational states are conditions that apply to some functional groups, not individual components.
%% Andrew says that that does no make sense But I think it does
%
%\paragraph{Design Decision.}
%Operational state will be applied to {\fg}s.
%
%\paragraph{UML Model of FMMD Analysis}
%
The UML diagram in figure \ref{fig:env_op_uml}, shows the data
relationships between {\fgs} and operational states, and component
failure modes and environmental factors.
% \begin{figure}[h]
% \centering
% \includegraphics[width=200pt,bb=0 0 818 249,keepaspectratio=true]{./fmmd_env_op_uml.png}
% % fmmd_env_op_uml.jpg: 818x249 pixel, 72dpi, 28.86x8.78 cm, bb=0 0 818 249
% \caption{UML model of Environmental and Operational states w.r.t FMMD}
% \label{fig:env_op_uml}
% \end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=200pt]{./fmmd_env_op_uml.png}
% fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
\caption{UML model of failure mode ontology}
\label{fig:env_op_uml}
\end{figure}
%This is because environmental conditions will apply SYSTEM wide,
%but may only affect specific components.
%DEVELOP UML MODELS
The ontology is used
to determine the nature of a hierarchy modelling the system, and to which
entities, various conditions/procedures are germane. From the ontology,
we determine that environmental effects relate to components, and
operational states to functional groups. A functional group can be
analysed with respect to its component failure modes, operational
states and environmental conditions and from this a set of failures
modes, or symptoms for the functional group can be determined. A functional group
can be treated as a derived component. Derived components can be
used to build functional groups at a higher level. In this manner we
\section{The proposed Methodology}
\label{fmmdproc}
The proposed methodology is a bottom-up process
starting with base~components.
These are collected into functional groups
and each component failure mode (and optionally combinations) are considered in the
context of the {\fg}. These are termed `test~cases'. For each test~case
there will be a corresponding failure mode, from the perspective of the {\fg}.
A symptom collection stage will now be applied. Here common symptoms are collected
from the results of the test~cases.
With a collection of the {\fg} failure symptoms, we can now create a {\dc}.
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
the failure mode behaviour of a SYSTEM.
\subsection{Re-Factoring the UML Model}
The UML models thus far % in this
have been used to develop the ontology. % data relationships required to perform FMMD analysis.
We can now re-organise and rationalise the UML model.
We want to be able to use {\dcs} in functional groups.
It therefore makes sense for {\dc} to inherit {\em component}.
% \begin{figure}[h]
% \centering
% \includegraphics[width=200pt,bb=0 0 702 464]{./master_uml.png}
% % master_uml.jpg: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
% \caption{Re-factored UML Diagram}
% \label{fig:refactored_uml}
% \end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=200pt]{./master_uml.png}
% master_uml.png: 700x462 pixel, 72dpi, 24.69x16.30 cm, bb=0 0 700 462
\caption{Re-factored UML Diagram }
\label{fig:refactored_uml}
\end{figure}
The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}; with this structure
{\dcs} can be
used to build {\fgs} at a higher level. In this manner we
can build a hierarchical model with each layer consisting of
components derived from the functional groups of derived components.
From the ontology, a set of rules for simplifying the failure
modes (collecting them into common symptoms) as we traverse up the
hierarchy is developed. The hierarchical model can have layers added
until it converges to a top level single functional group. On collecting
symptoms from this, we are left with the top level, or system level, failure modes.
components derived from the functional groups of derived components,
until we arrive at a SYSTEM level.
The symptoms of the {\fg} at the top represent the SYSTEM failure modes.
%From the ontology, a set of rules for converting the {\fgs}
%(collecting common symptoms) to {\dcs} as we traverse up the
%hierarchy is developed. The hierarchical model can have layers added
%until it converges to a top level single functional group.
%On collecting
%symptoms from this, we are left with the top level, or system level, failure modes.
\paragraph{Diagramatic Notation based on Euler Diagrams}
The model is presented in a diagrammatic notation that has been
designed to be intuitive and understandable. It uses well tested
designed to be intuitive and understandable.
%
It uses well tested
visual techniques to represent the elements of the model and their
relationships. Software support for the development of models in this
relationships.
%
Software support for the development of models in this
notation has been designed and proof-of-concept tools have been implemented.
\subsection{Justification of wishlist}
By applying the methodology in section \ref{fmmdproc}, the wishlist can
now be evaluated for the proposed FMMD methodology.
{ \small
\begin{itemize}
\item{State Explosion must be reduced.}
Because small collections of components are dealt with in functional groups
the state explosion problem is effectively dealt with.
\item{All component failure modes must be considered in the model.}
The proposed methodology will be bottom-up.
This ensures that all component failure modes are handled.
\item{ It should be easy to integrate mechanical, electronic and software models.}
Because component failure modes are considered, we have a generic entity to model.
We can describe a mechanical, electrical or software component in terms of its failure modes.
%
Because of this
we can model and analyse integrated electromechanical systems, controlled by computers,
using a common notation.
\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
The hierarchical nature, taking {\fg}s and deriving components from them, means that
commonly used {\dcs} can be re-used in a design (for instance self checking digital inputs)
or even in other projects where the same {\dc} is used.
\item{ It should have a formal basis, data should be available to produce mathematical proofs
for its results}
Because the failure mode of a SYSTEM is a hierarchy of {\fg}s and derived components
SYSTEM level failure modes are traceable back down the fault tree to
component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets
for all SYSTEM failure modes.
\item{ It should be capable of producing reliability and danger evaluation statistics.}
The minimal cuts sets for the SYSTEM level failures can have computed MTTF
and danger evaluation statistics sourced from the component failure mode statistics \cite {mil1991}.
\item{ It should be easy to use, ideally
using a graphical syntax (as opposed to a formal mathematical one).}
A modified form of constraint diagram (an extension of Euler diagrams) has
been developed to support the FMMD methodology.
This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
advance a {\fg} to a {\dc}.
\item{ From the top down the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional modules \cite{maikowski}.}
The bottom-up approach fulfils the logical de-composition requirement, because the {\fg}s
are built from components performing a given task.
\item{ Multiple failure modes may be modelled from the base component level up.}
By breaking the problem of failure mode analysis into small stages
and building a hierarchy, the problems associated with the cross products of
all failure modes within a system are reduced by an exponential order.
This is because the multiple failure modes are considered
within {\fgs} which have fewer failure modes to consider
at each FMMD stage.
Where appropriate, multiple simultaneous failures can be modelled by
introducing test~cases where the conjunction of failure modes is considered.
\end{itemize}
}
%\clearpage
\section{Conclusion}
This new approach is called
@ -291,7 +511,7 @@ particular field. It can be applied to mechanical, electrical or software domain
It can therefore be used to analyse systems comprised of electrical,
mechanical and software elements in one integrated model.
\today
%
{ \tiny
\bibliographystyle{plain}

120
fmmd_concept/fmmd_concept.tex
View File

@ -684,7 +684,66 @@ to smaller and smaller functional groupings \cite{maikowski}.
\section{Design of a new static failure mode based methodology}
\paragraph{New methodology must be bottom-up.}
%
By taking {\dcs} to form higher level functional groups
we can build a bottom-up model incrementally.
In this way as we build the hierarchy, we naturally abstract the
failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms.
\paragraph{Design Decision: Derived components must be determined from functional groups.}
The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
of its corresponding {\dc}.
\paragraph{Incremental Stages and \dcs .}
We can use incremental stages to build the hierarchy.
We can take small {\fg}s of components, where the {\fg}
is a small set of components that perform a simple
task.
%
%The functional group should perform a clearly defined task.
The design engineer must choose the components that form a {\fg}.
It should be possible to consider the {\fg} as a component or
black box, performing a given function.
The {\fg} should be chosen to be as small
(in terms of the number of components) as possible.
%
This should be small enough to be able %Another advantage of the functional group being small
to comfortably analyse all the failure
modes of its components.
%
We can consider these failure modes from the perspective
of the {\fg}. In other words, for each component failure mode in the {\fg},
we create a `test case' and decide how each failure affects the functional group.
%
With the results from the test cases we will now have the ways in which the
{\fg} can fail.
%
%
We can refine this further, by grouping the common symptoms, or results that
are the same failure {\wrt} the {\fg}.
%
We can now treat the {\fg} as a component, and create a corresponding {\dc}: in other words, a `sub-system' with a known set of failure modes.
%
We can now create a new/{\dc} and assign it these common symptoms
as its failure modes.
%
This {\dc} can be used to build higher level
{\fg}s, and this will naturally form a hierarchy.
This hierarchy can be extended until it encompasses
an entire SYSTEM.
%
It can be considered complete when
all failure modes from all components are included in the model
and all base component failure modes can be traced
through the fault tree to SYSTEM level failure modes.
\paragraph{Directed Acyclic Graph (DAG).}
If we ensure that
derived components cannot be included in {\fg}s
of a lower abstraction level\paragraph{New methodology must be bottom-up.}
In order to ensure that all component failure modes have been covered
the methodology will have to work from the bottom-up
and start with the component failure modes.
@ -826,65 +885,6 @@ When we have the symptoms, we can start thinking of the {\fg} as a component in
%
We can now create a new {\dc}, where its failure modes
are the failure symptoms of the {\fg}.
%
By taking {\dcs} to form higher level functional groups
we can build a bottom-up model incrementally.
In this way as we build the hierarchy, we naturally abstract the
failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms.
\paragraph{Design Decision: Derived components must be determined from functional groups.}
The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
of its corresponding {\dc}.
\paragraph{Incremental Stages and \dcs .}
We can use incremental stages to build the hierarchy.
We can take small {\fg}s of components, where the {\fg}
is a small set of components that perform a simple
task.
%
%The functional group should perform a clearly defined task.
The design engineer must choose the components that form a {\fg}.
It should be possible to consider the {\fg} as a component or
black box, performing a given function.
The {\fg} should be chosen to be as small
(in terms of the number of components) as possible.
%
This should be small enough to be able %Another advantage of the functional group being small
to comfortably analyse all the failure
modes of its components.
%
We can consider these failure modes from the perspective
of the {\fg}. In other words, for each component failure mode in the {\fg},
we create a `test case' and decide how each failure affects the functional group.
%
With the results from the test cases we will now have the ways in which the
{\fg} can fail.
%
%
We can refine this further, by grouping the common symptoms, or results that
are the same failure {\wrt} the {\fg}.
%
We can now treat the {\fg} as a component, and create a corresponding {\dc}: in other words, a `sub-system' with a known set of failure modes.
%
We can now create a new/{\dc} and assign it these common symptoms
as its failure modes.
%
This {\dc} can be used to build higher level
{\fg}s, and this will naturally form a hierarchy.
This hierarchy can be extended until it encompasses
an entire SYSTEM.
%
It can be considered complete when
all failure modes from all components are included in the model
and all base component failure modes can be traced
through the fault tree to SYSTEM level failure modes.
\paragraph{Directed Acyclic Graph (DAG).}
If we ensure that
derived components cannot be included in {\fg}s
of a lower abstraction level
the data structure produced from collecting functional groups
and deriving components will naturally form a DAG.
In other words we can say that we cannot allow a {\fg}