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

mainly changing sub-system for derived component but keeping sub-system as a starter concept

Browse Source
This commit is contained in:
Robin 2010-06-05 10:32:14 +01:00
parent bb22f00c7b
commit 3776001738
3 changed files with 157 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -267,7 +267,7 @@ OPEN and SHORT are thus mutually exclusive.
Because of this the failure mode set $F=FM(R)$ is `unitary~state'.
Thus
Thus because both fault modes cannot be active at the same time, the intersection of $ R_{SHORTED} $ and $ R_{OPEN} $ cannot exist.
$$ R_{SHORTED} \cap R_{OPEN} = \emptyset $$
therefore
@ -396,7 +396,7 @@ For component R there is only one internal component fault that cannot exist
$R_o \wedge R_s$. As a combination ${2 \choose 2} = 1$ . For $T$ the component with
three fault modes ${2 \choose 3} = 3$.
Thus for $cc == 2$, under the conditions of unitary state failure modes in the components $R$ and $T$, we must subtract $(3+1)$.
The number of combinations to check is thus 11 for this example and this can be verified
The number of combinations to check is thus 11, $|\mathcal{P}_{2}(FG_cfg)| = 11$, for this example and this can be verified
by listing all the required combinations:
%
%\vbox{
@ -419,14 +419,21 @@ by listing all the required combinations:
%}
%
%$$ |\mathcal{P}_{2}(FG_cfg)| = 11 $$
$$ \mathcal{P}_{2}(FG_cfg) = \{
\{R_o T_o\}, \{R_o T_s\}, \{R_o T_h\}, \{R_s T_o\}, \{R_s T_s\}, \{R_s T_h\}, \{R_o \}, \{R_s \}, \{T_o \}, \{T_s \}, \{T_h \}
\}
$$
And by inspection
$$ |\mathcal{P}_{2}(FG_cfg)| = 11 $$
$$
|
\{
\{R_o T_o\}, \{R_o T_s\}, \{R_o T_h\}, \{R_s T_o\}, \{R_s T_s\}, \{R_s T_h\}, \{R_o \}, \{R_s \}, \{T_o \}, \{T_s \}, \{T_h \}
\}
| = 11 $$
\subsubsection{Establishing Formulae for unitary state failure mode \\

9
introduction/introduction.tex
View File

@ -141,7 +141,14 @@ a process of modularisation from the bottom~up.
\end{list}
\section{Safety Critical Systems}
%
%How safe is "safe"?
%The word "safety" is too general—it really doesn't mean anything definitive. Therefore, we use terms such as safety-related and safety-critical.
%
%A safety-related device provides or ensures safety. It is required for machines/vehicles, which cause bodily harm or death to human being when they fail. A safe state can be defined (in other words, safety-related). In case of a buzz saw, this could be a motor that seizes all movements immediately. The seizure of movement makes the machine safe at that moment. IEC 61508 defines the likelihood of failures of this mechanism, the Safety Integrity Levels (SIL). SIL 3 is defined as the likelihood of failing less than 10-7% per hour. This is a necessary level of safety integrity for products such as lifts, where several people's lives are endangered. The buzz saw is likely to require SIL 2 only, it endangers just one person.
%
%Safety-critical is a different matter. To understand safety-critical imagine a plane in flight: it is not "safe" to make all movement stop since that would make the plane crash. A safe state for a plane is in the hangar, but this is not an option when you're in flight. Other means of ensuring safety must be found. One method used in maritime applications is the "CANopen flying master" principle, which uses redundancy to prevent failure. For the above example an SIL 4, meaning likelihood of failing less than 10-8% per hour is necessary. This is also true for nuclear power station control systems, among other examples.
%
\subsection{General description of a Safety Critical System}
A safety critical system is one in which lives may depend upon it or

251
symptom_ex_process/symptom_ex_process.tex
View File

@ -1,22 +1,29 @@
\begin{abstract}
In modular systems design, it is often very useful to
know the failure modes of the sub-systems used.
In failure mode analysis, it is essential to
know the failure modes of the sub-systems and components used.
This paper outlines a technique for determining the failure modes of a sub-system given
its component parts.
%, and the failure modes of those parts.
This chapter describes a process for taking a functional group of components, applying FMEA analysis and then determining how that functional group can fail.
With this information, we can trat the functional group
as a component in its own right.
This new component is a derived component.
For a top down technique this would correspond to a sub-system.
%The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model.
Once the failure modes have been determined for a sub-system,
that sub-system may be treated as a `component' or `black box' and used
in conjunction with other such analysed sub-systems, to model
higher level sub-systems. In this way a hierarchy to represent the fault behaviour
of a system can be built.
Once the failure modes have been determined for a sub-system/derived~component,
This derived component can be combined with others to form functional groups
to model
higher level sub-systems/derived~components.
In this way a hierarchy to represent the fault behaviour
of a system can be built from the bottom~up. This process can continue
until there is a complete hierarchy representing the failure mode
behaviour of the entire system under analysis.
%FMMD hierarchy
The hierarchy is built from the bottom up.
Starting with component failure modes at the bottom.
Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage.
Because the process is bottom-up, syntax checking and tracking can ensure that
no component failure mode can be overlooked.
Once a hierarchy is in place it can be converted into a fault data model.
@ -34,21 +41,31 @@ This paper focuses on the process of building the blocks that are used in the hi
\section{Introduction}
\subsection{Top Down or natural trouble shooting}
It is interesting here to look at the `natural' trouble shooting process.
Fault finding is intinctively performed from the top-down.
A faulty piece of equipment is examined and will have a
symptom or specific fault. The area or sub-system within the
equipemnt will next be looked into. Secific measurements
symptom or specific fault. The suspected area or sub-system within the
equipment will next be looked into.
The trouble shooter will look for behaviour that is unusual or incorrect
to determine the next area or sub~system to look at, each time
moving to a more detailed lower level.
Specific measurements
and checks will be made, and finally a component or a low level sub-system
will be found to be faulty.
The technique here works the other way. It works from the bottom up.
Starting with a collection of compoents that form
A natural fault finding process is thus top~down.
\subsection{FMMD - Bottom~up Analysis}
The FMMD technique described here works the other way. It works from the bottom up.
Starting with a collection of components that form
a simple functional group, the effect of all component error modes are
examined, as to their effect on the functional group.
The effects on the functional group can then be collected as common symptoms,
and now we may treat the functional group as a component. It has a known set of failure modes.
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment failure.
This means that we can obtainm statistical estimates based on the known reliabilities
This means that at the design stage of a product all component failure
modes must be considered. The aim here is for complete failure mode coverage.
This also means that we can obtain statistical estimates based on the known reliabilities
of the components.
It also means that every component failure mode must at the very least be considered.
@ -65,6 +82,8 @@ Three main techniques are currenly used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The technique outlined here aims to provide a mathematical frame work
to assist in the production of these three results of static analysis.
From the model created by the FMMD technique, the three above failure mode
descriptions can be derived.
{
The aims are
@ -80,7 +99,8 @@ The aims are
\subsection{Systems, functional groups, sub-systems and failure modes}
It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `sub-system'.
It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `derived~component/sub-system'.
These are listed in table~\ref{tab:symexdef}.
A System, is really any coherent entity that would be sold as a safety critical product.
A sub-system is a system that is part of some larger system.
@ -125,15 +145,17 @@ We can now call our functional~group a sub-system. The goal here is to know how
%Imagine buying one such `sub~system' from a very honest vendor.
%One of those sir, yes but be warned it may fail in these distinct ways, here
%in the honest data sheet the set of failure modes is listed!
This type of thinking is starting to become more commonplace in product literature, with the emergence
of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
FIT (Failure in Time - expected number of failures per billion hours of operation) values
are published for some micro-controllers. A micro~controller
is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}
As electrical components have detailed datasheets a useful extension of this would
%This type of thinking is starting to become more commonplace in product literature, with the emergence
%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
%FIT (Failure in Time - expected number of failures per billion hours of operation) values
%are published for some micro-controllers. A micro~controller
%is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}
Electrical components have detailed datasheets associated with them. A useful extension of this would
be failure modes of the component, with environmental factors and MTTF statistics.
Currently this sort of information is generally only available for generic component types\cite{mil1991}.
@ -142,8 +164,8 @@ Currently this sort of information is generally only available for generic comp
%At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to
%erform a given function.
\vspace{0.3cm}
%\begin{table}[p]
%\vspace{0.3cm}
\begin{table}[h]
\begin{tabular}{||l|l||} \hline \hline
{\em Definition } & {\em Description} \\ \hline
System & A product designed to \\
@ -159,8 +181,10 @@ Base Component & Any bought in component, which \\
& hopefully has a known set of failure modes \\ \hline
\hline
\end{tabular}
%\end{table}
\vspace{0.3cm}
\caption{Symptom Extraction Definitions}
\label{tab:symexdef}
\end{table}
%\vspace{0.3cm}
\section{The Symptom abstraction Process}
@ -175,12 +199,14 @@ when specified components within it fail.
Once we know how functional~group can fail, we can treat it as a component or sub-system
with its own set of failure modes.
\paragraph{FMEA applied to the functional Group}
\paragraph{FMEA applied to the Functional Group}
As the functional~group is a set of components, the failure~modes
that we have to consider are all the failure modes of its components.
Each failure mode (or combination of) investigated is termed a `test case'.
Each `test case' is analysed.
Each `test case' is analysed.
The component failure modes are examined with respect to their effect on the functional~group.
The philosophy behind this analysis is, how will the functional~group react
to each of the test case conditions. The aim is to produce a set of failure modes from the perspective of the functional~group.
\paragraph{Symptom identification and collection}
When all `test~cases' have been analysed a second phase is applied.
%
@ -195,8 +221,7 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure and lone~component failure~modes are identified and collected.
we can now consider the functional~group as a component and the common symptoms as its failure modes.
We can now consider the functional~group as a component and the common symptoms as its failure modes.
Note that here because this is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
It is possible here for an automated system to flag unhandled failure modes.
@ -212,20 +237,20 @@ It is possible here for an automated system to flag unhandled failure modes.
% We can now try to simplfy by determining common symptoms. A common symptom, in this context, is defined as faults caused by different component failure modes that have the same effect from the perspective of a `user' of the sub-system. Test case results can now viewed as failure modes of the sub-sytem or `black box', and grouped together where there are common symptoms. These are grouped together by joining them with lines. These lines form collected groups (or `spiders'). See figure \ref{fig:gensubsys3}.
% It can be seen now that each {\em lone test case} and {\em spider} on the diagram is a distinct failure mode of the sub-system. This means that these failure modes represent the fault behaviour of the sub-system. We can now treat this sub-system as a component in its own right, or in other words, we have derived a failure mode model at a higher level of abstraction. We can now draw a new diagram to represent the failure modes of the sub-system. Each spider or lone test case, becomes a contour representing a failure mode of the sub-system in this new diagram (see figure \ref{fig:gensubsys4}.
\section{The Process : To analyse a base level sub-system}
\section{The Process : To analyse a base level Derived~Component/sub-system}
To sumarise:
\begin{itemize}
\item Determine a minimal functional group
\item Obtain list of components in the functional group
\item Obtain the list of components in the functional group
\item Collect the failure modes for each component
% \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case
\item Examine each failure mode of all the components in the functional~group, and determine its effect on the failure behaviour of the functional group
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a sub-system to use.
Determine which test cases produce the same fault symptoms.% Join common symptoms with lines connecting them (sometimes termed a `spider').
\item Examine each failure mode of all the components in the functional~group, and determine their effects on the failure~mode behaviour of the functional group
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use.
Determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.% Join common symptoms with lines connecting them (sometimes termed a `spider').
\item The lone test cases and the common~symptoms are now the fault mode behaviour of the sub-system/derived~component.
\item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component
\end{itemize}
@ -233,7 +258,7 @@ Determine which test cases produce the same fault symptoms.% Join common symptom
\section{A general Sub-System example}
\section{A general derived Component/Sub-System example}
Consider a functional group $FG$ with component parts $A$,$B$ and $C$.
Each part has a set of related fault modes (i.e. ways in which it can fail to operate correctly).
@ -264,102 +289,96 @@ thus
% The failure modes of the components can be represented as contours on on the diagram in \ref{fig:gensubsys1}. \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/synmptom_abstraction.jpg} % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys1} \caption{$FG_{cfm}$ Component Failure modes represented as contours} \end{figure} % % DIAGRAM WITH SPIDER % \begin{figure} % \centering % \includegraphics[scale=20]{./synmptom_abstraction.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{$SS_{cfm}$ Component Failure modes represented as contours} % \end{figure} We can now look at the effects that component failure modes have on the sub-system. This process involves examining `test cases'. Each `test case' represents the fault behaviour of the sub-system due to particular combinations of component fault modes. Each test case can be represented on the diagram as a labeled point. The labeled point will reside in a region on the diagram enclosed by the contours representing particular component fault modes. The label will indicate the fault symptom from the perspective of the sub-system. For the sake of example, only single component failure modes are considered. We can now assign a test~case to each contour, and mark it on the diagram. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction2.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys2} % \caption{Component Failure modes with analysed test cases} % \end{figure} \begin{figure} \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction2.jpg} % symptom_abstraction2.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys2} \caption{Component Failure modes with analysed test cases} \end{figure}
\par
\vspace{0.3cm}
\begin{tabular}{||l|l||} \hline \hline
{\em Component Failure Mode } & {\em test case} \\ \hline
$a\_1$ & $fs\_1$ \\ \hline
$a\_2$ & $fs\_2$ \\ \hline
$a\_3$ & $fs\_3$ \\ \hline
$b\_1$ & $fs\_4$ \\ \hline
$b\_2$ & $fs\_5$ \\ \hline
$c\_1$ & $fs\_6$ \\ \hline
$c\_2$ & $fs\_7$ \\ \hline
%\vspace{0.3cm}
\begin{table}[h]
\begin{tabular}{||c|c|c|c||} \hline \hline
{\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\
{\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline
$a\_1$ & $fs\_1$ & $fgfm_{1}$ & SP2 \\ \hline
$a\_2$ & $fs\_2$ & $fgfm_{2}$ & SP1 \\ \hline
$a\_3$ & $fs\_3$ & $fgfm_{3}$ & SP2\\ \hline
$b\_1$ & $fs\_4$ & $fgfm_{4}$ & SP1 \\ \hline
$b\_2$ & $fs\_5$ & $fgfm_{5}$ & SP1 \\ \hline
$c\_1$ & $fs\_6$ & $fgfm_{6}$ & \\ \hline
$c\_2$ & $fs\_7$ & $fgfm_{7}$ & SP2\\ \hline
\hline
\end{tabular}
\vspace{0.3cm}
\caption{Component to functional group to failure symptoms example}
\label{tab:fexsymptoms}
\end{table}
%\vspace{0.3cm}
Table~\ref{tab:fexsymptoms} shows the analysis process.
In this example we are only looking a single fault possibilities.
The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}.
The test cases are analysed w.r.t. the functional~group.
These become functional group failure modes ($fgfm$'s).
% The sub-system fault symptoms are now represented on the diagram as in figure \ref{fig:gensubsys2}. A second stage of analysis is now applied. Empirically, it is often noticed that a sub-system will fail in the same way due to a variety of reasons. To the `user' of the sub-system, it does not matter which component or combination of components has failed. The sub-system can thus be considered to have its own set of failure modes. This stage of the analysis is to determine these, to collect `like symptoms'. This is performed on the diagram by linking the test cases with lines to form `spiders'
For the sake of example let us consider the fault symptoms $SP1 = \{fs_2, fs_4, fs_5\}$ to be an identical
failure mode at the {\em sub-system} level. These can then be joined to form a spider. Likewise
let $SP2 = \{fs_1, fs_3, fs_7\}$ be an identical failure mode at the {\em sub-system} level.
Let $\{fs_6\}$ be a distinct failure mode at {\em sub-system} level.
For the sake of example let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ be
identical from the perspective of the functional~group.
That is to say, that the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes
occur, is going to be the same.
For example, in our CD player example, this could mean the common symptom `no\_sound'.
No matter which component failure modes, or combinations thereof cause the problem, the fault
the symptom is the same.
It may be of interest to the manufacturers and designers of the CD player why it failed but
as far as we the users are concerned, it has the one symptom,
`no\_sound'!
We can thus group these component failure modes into a common symptom, $SP1$, thus
$ SP1 = \{fgfm_2, fgfm_4, fgfm_5\}$.
% These can then be joined to form a spider.
Likewise
let $SP2 = \{fgfm_1, fgfm_3, fgfm_7\}$ be an identical failure mode {\em from the perspective of the functional~group}.
Let $\{fgfm_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}.
% The diagram can now be drawn as in figure \ref{fig:gensubsys3}. % \begin{figure}[h+] % \centering % \includegraphics[scale=20]{./symptom_abstraction3.jpg} % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 % \label{fig:gensubsys3} % \caption{Common failure modes collected as `Spiders'} % \end{figure} \begin{figure}[h+] \centering \includegraphics[width=3in,height=3in,bb=0 0 513 541]{symptom_abstraction/symptom_abstraction3.jpg} % symptom_abstraction3.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 \label{fig:gensubsys3} \caption{Common failure modes collected as `Spiders'} \end{figure}
We have now in $SP1$, $SP2$ and $fs_6$ the three ways in which this sub-system can fail.
In other words we have derived failure modes for this sub-system.
The third stage of the process could be applied automatically.
Each common symptom becomes a failure mode of
a newly created derived component.
The result of this will be, a set of failure modes for the sub-system, as though it were a {\em black box}
We have now in $SP1$, $SP2$ and $fgfm_6$ as the three ways in which this functional~group can fail.
In other words we have derived failure modes for this functional~group.
%
These three symptoms can be considered the set of failure modes for the functional~group, and
we can treat it as though it were a {\em black box}
or a {\em component} to be used in higher level designs.
%\section{The Process : To analyse a base level sub-system}
% \REQUIRE Obtain a list of components for the System $S$ under investigation. \ENSURE Decomposition of $S$ into atomic
% components where each component $c$ has a know set of $fm$ failure modes.
%
% \STATE Determine functional groups $fg_n \subset S$ of components, where n is an index number
% \COMMENT{ The functional groups should be chosen to be minimally sized collections of components that perform a specific function.}
% \REQUIRE{ Ensure that all components belong to at least one functinal group $\bigcup_i fg_i = S $
% %
% \FORALL { $fg_i \in S$}
%
% \STATE state something
%
% \ENDFOR
%
% \STATE Check for cut vertices \COMMENT{here we choose to decompose
% all nested components in one go}
% %
% \FORALL {vertices $v \in G$}
% \STATE Check if $v$ is a cut vertex. \COMMENT{so $d$ is nested and in
% $d$ there must be a 0-separating curve in the zone corresponding to $v$}
% \ENDFOR
%
%
%%%%%%%%%%%%
The next stage of the process could be applied automatically.
Each common symptom becomes a failure mode of
a newly created derived component. Let $DC$ be the newly derived component.
This has the failure modes that were derived from the functional~group.
We can thus apply the function $FM$ on this newly derived component thus:
$$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$
Note that $fgfm_6$, while being a failure mode has not been grouped as a common symptom
has {\textbf not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear in the derived component.
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner, my advice to all nine year olds is its best to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
The process must not allow failure modes to be ignored or forgotten.
% \begin{itemize}
% \item determine a minimal functional group
% \item obtain list of components in the functional group
% \item collect the failure modes for each component
% \item draw these as contours on a diagram
% \item where multiple failures are examined use overlapping contours to represent this
% \item for each region on the diagram, make a test case
% \item examine each test case and determine the effect of the component failure modes on the behaviour of the functional group
% \item collect common symptoms. imagine you are handed this functional group as a `black box', a sub system to use.
% which test cases produce the same fault symptoms. Join common symptoms with `spiders', lines connecting them
% \item The lone test cases and the spiders are now the fault mode behaviour of the sub-system
% \item A new diagram can now be drawn where each spider, or lone test case from the original diagram
% is represented as a contour. These contours represent the failure modes of the sub-system.
% \end{itemize}
This sub-system or derived~component may now therefore, be represented as three separate failure modes.
We may now treat this sub-system as we would a component with a known set of failure modes.
The failure modes of the Sub-system $SS$ are now the set $SS_{fm} = \{ SP1, Sp2, fs_6 \}$.
\subsection{Defining the analysis process as a function}
It is useful to define this analysis process as a function.
Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now
write
$$
\bowtie : SubSystemComponentFaultModes \mapsto SubSystemFaultModes
\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent
$$
\begin{equation}
\bowtie(FG_{cfm}) = SS_{fm}
\bowtie(FG_{cfm}) = DC
\end{equation}
The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}
or applying the function $FM$ to obtain the $FG_{cfm}$ set
\begin{equation}
\bowtie(FM(FG)) = DC
\end{equation}
%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}
% \begin{figure}[h+]
% \centering
@ -369,8 +388,14 @@ The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' sym
% \caption{Deriving a new diagram}
This sub-system or derived~component, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes.
This sub-system or derived~component $DC$ , with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes.
This process can be repeated using derived~components to build a
hierarchical
fault~mode
model.