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

Morning edit

Browse Source
This commit is contained in:
Robin Clark 2010-08-25 07:38:33 +01:00
parent 6708d2cfbd
commit 5cdb0cfbb5
2 changed files with 40 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -80,7 +80,7 @@ The UML diagram in figure
structure with its associated failure modes. structure with its associated failure modes.
From this diagram we see that each component must have at least one failure mode. From this diagram we see that each component must have at least one failure mode.
To clearly show that the failure modes are unique events associated with one component, To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
each failure mode is referenced back to only one component. each failure mode is referenced back to only one component.
%%-%% MTTF STATS CHAPTER MAYBE ?? %%-%% MTTF STATS CHAPTER MAYBE ??
@ -95,11 +95,11 @@ each failure mode is referenced back to only one component.
A product naturally consists of many components and these are traditionally A product naturally consists of many components and these are traditionally
kept in a `parts list'. For a safety critical product this is usually a formal document kept in a `parts list'. For a safety critical product this is usually a formal document
and is used by quality inspectors to ensure the correct parts are being fitted. and is used by quality inspectors to ensure the correct parts are being fitted.
For our UML diagram the parts list is simply a collection of components The parts list is shown for
as shown in figure \ref{fig:componentpl}. The parts list is shown for
completeness here, as people involved with PCB and electronics production, verification completeness here, as people involved with PCB and electronics production, verification
and testing would want to know where it lies in the model. and testing would want to know where it lies in the model.
The parts list is not actively used in the FMMD method. The parts list is not actively used in the FMMD method.
For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
\begin{figure}[h] \begin{figure}[h]
\centering \centering
\includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{component_failure_modes_definition/componentpl.jpg} \includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{component_failure_modes_definition/componentpl.jpg}
@ -108,14 +108,18 @@ The parts list is not actively used in the FMMD method.
\label{fig:componentpl} \label{fig:componentpl}
\end{figure} \end{figure}
Components in the parts list (bought in parts) will be termed `base~components'. Components in the parts list % (bought in parts)
Components derived from base~components may not require will be termed `base~components'.
Components derived from base~components will not always require
parts~numbers\footnote{It is common practise for sub assemblies, PCB's, mechanical parts, parts~numbers\footnote{It is common practise for sub assemblies, PCB's, mechanical parts,
software modules and some collections of components to have part numbers.}, and will software modules and some collections of components to have part numbers.
not require a vendor reference, but must be named. This is a production/configuration~control issue and linked to Bill of Material (BOM)
database structures etc. Parts numbers for derived components are not directly related to the analysis process
we are concerned with here.}, and will
not require a vendor reference, but must be named locally in the FMMD model.
We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis. We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis.
When modularising a system from the top~down, as in Fault Tree Analysis (FTA) When modularising a system from the top~down, as in Fault Tree Analysis\cite{nasafta}\cite{nucfta} (FTA)
it is common to term the modules identified as sub-systems. it is common to term the modules identified as sub-systems.
When building from the bottom up, it is more meaningful to call them `derived~components'. When building from the bottom up, it is more meaningful to call them `derived~components'.
@ -140,36 +144,44 @@ starting, where possible with known base~component failure~modes.
An advantage of working from the bottom up is that we can ensure that An advantage of working from the bottom up is that we can ensure that
all component failure modes must be considered. A top down approach all component failure modes must be considered. A top down approach
could miss individual failure modes of components. can miss individual failure modes of components\cite{faa}[Ch.~9],
especially where they are non obvious top-level faults.
In order to analyse from the bottom-up, we need to take In order to analyse from the bottom-up, we need to take
small groups of components from the parts~list that naturally small groups of components from the parts~list that naturally
work together to perform a simple function. work together to perform a simple function;
The components to include in a functional group are chosen by a human, the analyst. the components to include in a {\fg} are chosen by a human, the analyst.
%We can represent the `Functional~Group' as a class. %We can represent the `Functional~Group' as a class.
When we have a When we have a
`Functional~Group' we can look at the components it contains, `{\fg}' we can look at the components it contains,
and from this determine the failure modes of all the components that belong to it. and from this determine the failure modes of all the components that belong to it.
% %
% and determine a failure mode model for that group. % and determine a failure mode model for that group.
The `Functional~Group' as used by the analyst is a collection of component failures modes. The `{\fg}' as used by the analyst is a collection of component failures modes.
Each of these failure modes, and optionally combinations of them, are Each of these failure modes, and optionally combinations of them, are
analysed for their effect on the failure mode behaviour of the `Functional~Group'. analysed for their effect on the failure mode behaviour of the `{\fg}'.
% %
From this we can determine a new set of failure modes, the failure modes of the From this we can determine a new set of failure modes, the failure modes of the
`Functional~Group'. `{\fg}'.
% %
Or in other words we can determine how the `Functional~Group' can fail. Or in other words we can determine how the `{\fg}' can fail.
We can now consider the functional group as a sort of super component We can now consider the {\fg} as a sort of super component
with a known set of failure modes. with a known set of failure modes.
\subsection{From functional group to newly derived component} \subsection{From functional group to newly derived component}
The process for taking a functional~group, considering The process for taking a {\fg}, considering
all the failure modes of all the components in the group, all the failure modes of all the components in the group,
and analysing it is called `symptom abstraction' and and analysing it is called `symptom abstraction' and
is dealt with in detail in chapter \ref{symptom_abstraction}. is dealt with in detail in chapter \ref{symptom_abstraction}.
% define difference between a \fg and a \dc
A {\fg} is a collection of components, a {\dc} is a new `theorectical'
component which has a set of failure modes, which
correspond to the failure modes of the {\fg} is was derived from.
We could consider a {\fg} as a black box, or component
to use, and in this case it would have a set of failure modes.
Looking at the {\fg} in this way is seeing it as a {\dc}.
In terms of our UML model, the symptom abstraction process takes a {\fg} In terms of our UML model, the symptom abstraction process takes a {\fg}
and creates a new {\dc} from it. and creates a new {\dc} from it.
@ -192,7 +204,8 @@ We can represent this using a UML diagram in figure \ref{fig:cfg}.
The symbol $\bowtie$ is used to indicate the analysis process that takes a The symbol $\bowtie$ is used to indicate the analysis process that takes a
functional group and converts it into a new component. functional group and converts it into a new component.
\[ \bowtie ( FG ) \mapsto DerivedComponent \] This can be expresed as
\[ \bowtie ( FG ) \mapsto DerivedComponent \].
\begin{figure}[h] \begin{figure}[h]

8
mybib.bib
View File

@ -65,6 +65,14 @@
} }
@BOOK{faa,
AUTHOR = "Federal Aviation Administration",
TITLE = "System Safety Handbook",
PUBLISHER = "http://www.faa.gov/library/manuals/aviation/risk\_management/ss\_handbook/",
YEAR = "2008"
}
@BOOK{sccs, @BOOK{sccs,
AUTHOR = "Neil~Storey", AUTHOR = "Neil~Storey",
TITLE = "Safety-Critical Computer Systems ISBN 0-201-42787-7", TITLE = "Safety-Critical Computer Systems ISBN 0-201-42787-7",