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

english read through by JMC - up to PLD

Browse Source
This commit is contained in:
Robin 2010-06-20 16:34:24 +01:00
parent 0176ed4a81
commit 9a16ce9906
2 changed files with 31 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -104,16 +104,16 @@ as shown in figure \ref{fig:componentpl}.
\label{fig:componentpl} \label{fig:componentpl}
\end{figure} \end{figure}
Components in the parts list (bought in parts) will be termed `base~comonents'. Components in the parts list (bought in parts) will be termed `base~components'.
Components derived from base~components may not require Components derived from base~components may not 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.}, and will
not require a vendor reference, but must be named. not require a vendor reference, but must be named.
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 (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 term the `sub-systems' as `derived~components'. When building from the bottom up, it is more meaningful to call them `derived~components'.
%% %%
@ -235,7 +235,7 @@ would have a level of 1.
% $$ \bowtie ( FG ) \mapsto DerivedComponent $$ % $$ \bowtie ( FG ) \mapsto DerivedComponent $$
% %
\subsection{relationships between functional~groups and failure modes} \subsection{Relationships between functional~groups and failure modes}
@ -387,7 +387,7 @@ is proposed and described in the next section.
\label{ccp} \label{ccp}
A Cardinality Constrained powerset is one where sub-sets of a cardinality greater than a threshold A Cardinality Constrained powerset is one where sub-sets of a cardinality greater than a threshold
are not included. This theshold is called the cardinality constraint. are not included. This threshold is called the cardinality constraint.
To indicate this the cardinality constraint $cc$, is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$. To indicate this the cardinality constraint $cc$, is subscripted to the powerset symbol thus $\mathcal{P}_{cc}$.
Consider the set $S = \{a,b,c\}$. Consider the set $S = \{a,b,c\}$.

51
symptom_ex_process/symptom_ex_process.tex
View File

@ -84,7 +84,7 @@ software~inspections and project~management quality reviews are applied\cite{scc
Static testing is also applied. This is theoretical analysis of the design of the product from the safety Static testing is also applied. This is theoretical analysis of the design of the product from the safety
perspective. perspective.
Three main techniques are currenly used, Three main techniques are currently used,
Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis). Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
The technique outlined here aims to provide a mathematical frame work The technique outlined here aims to provide a mathematical frame work
to assist in the production of these three results of static analysis. to assist in the production of these three results of static analysis.
@ -124,9 +124,8 @@ will have a fault/failure behaviour and it should
always be possible to obtain a set of failure modes always be possible to obtain a set of failure modes
for each `component'. In FMMD terms a sub-system is a derived component. for each `component'. In FMMD terms a sub-system is a derived component.
If we look at the sound system again as an If we look at the sound system again as an example,
example; the CD~player could fail in serveral distinct ways, no matter the CD~player could fail in several distinct ways, no matter what has happened to it or has gone wrong inside it.
what has happened to it or has gone wrong inside it.
Using the reasoning that working from the bottom up forces the consideration of all possible Using the reasoning that working from the bottom up forces the consideration of all possible
@ -134,8 +133,8 @@ component failures (which can be missed in a top~down approach)
we are presented with a problem. Which initial collections of base components should we choose ? we are presented with a problem. Which initial collections of base components should we choose ?
For instance in the CD~player example; to start at the bottom; we are presented with For instance in the CD~player example; to start at the bottom; we are presented with
a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts ! a massive list of base~components, resistors, motors, user~switches, laser~diodes, all sorts !
Clearly, working from the bottom~up we need to pick small Clearly, working from the bottom~up, we need to pick small
collections of components that work together in some way. collections of components that work together in some way.
These are termed `functional~groups'. For instance the circuitry that powers the laser diode These are termed `functional~groups'. For instance the circuitry that powers the laser diode
to illuminate the CD might contain a handful of components, and as such would make a good candidate to illuminate the CD might contain a handful of components, and as such would make a good candidate
@ -147,7 +146,7 @@ for the smallest `functional~groups' of components within a system. A functional
to perform a specific function. to perform a specific function.
When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'. When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'.
We can now call our functional~group a sub-system. The goal here is to know how will behave under fault conditions ! We can now call our functional~group a sub-system. The goal here is to know how it will behave under fault conditions !
%Imagine buying one such `sub~system' from a very honest vendor. %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 %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! %in the honest data sheet the set of failure modes is listed!
@ -178,7 +177,9 @@ Currently this sort of information is generally only available for generic comp
System & A product designed to \\ System & A product designed to \\
& work as a coherent entity \\ \hline & work as a coherent entity \\ \hline
Sub-system & A part of a system, \\ Sub-system & A part of a system, \\
-or- derived component & sub-systems may contain sub-systems \\ \hline -or- derived component & sub-systems may contain sub-systems. \\
& derived~components may by derived \\
& from derived components \\ \hline
Failure mode & A way in which a System, \\ Failure mode & A way in which a System, \\
& Sub-system or component can fail \\ \hline & Sub-system or component can fail \\ \hline
Functional Group & A collection of sub-systems and/or \\ Functional Group & A collection of sub-systems and/or \\
@ -212,11 +213,11 @@ 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 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 component failure modes are examined with respect to their effect on the functional~group.
The aim of this analysis is to find out how the functional~group react The aim of this analysis is to find out how the functional~group reacts
to each of the test case conditions. to each of the test case conditions.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group. The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
\paragraph{Symptom Identification} \paragraph{Symptom Identification}
When all `test~cases' have been analysed a second phase is applied. When all `test~cases' have been analysed, a second phase is applied.
% %
This looks at the results of the `test~cases' as symptoms This looks at the results of the `test~cases' as symptoms
of the sub-system. of the sub-system.
@ -232,7 +233,7 @@ The common symptoms of failure and lone~component failure~modes are identified a
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 the process is bottom up, we can ensure that all failure modes Note that here because the process is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled. associated with a functional~group have been handled.
Were failure~modes missed any failure mode model could be dangerously incomplete. Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes. It is possible here for an automated system to flag unhandled failure modes.
\ref{requirement at the start} \ref{requirement at the start}
@ -252,7 +253,7 @@ To sumarise:
\item Collect common symptoms. Imagine you are handed this functional group as a `black box', a `sub-system' to use. \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'). 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 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 \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} \end{itemize}
@ -297,7 +298,7 @@ $$ FM(C_3) = \{ c_1, c_2 \} $$
\paragraph{Finding all failure modes within the functional group} \paragraph{Finding all failure modes within the functional group}
For FMMD failure mode analysis we need to consider the failure modes For FMMD failure mode analysis, we need to consider the failure modes
from all the components in the functional group as a flat set. from all the components in the functional group as a flat set.
This can be found by applying function $FM$ to all the components This can be found by applying function $FM$ to all the components
in the functional~group and taking the union of them thus: in the functional~group and taking the union of them thus:
@ -355,14 +356,14 @@ The test cases are analysed w.r.t. the functional~group.
These become functional~group~failure~modes ($fgfm$'s). These become functional~group~failure~modes ($fgfm$'s).
The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed.
For the sake of example let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ be For the sake of example, let us consider the fault symptoms of $\{fgfm_2, fgfm_4, fgfm_5\}$ to be
identical from the perspective of the functional~group. 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 That is to say, the way in which functional~group fails if $fgfm_2$, $fgfm_4$ or $fgfm_5$ % failure modes
occur, is going to be the same. occur, is going to be the same.
For example, in our CD player example, this could mean the common symptom `no\_sound'. 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, No matter which component failure modes, or combinations thereof cause the problem,
the failure symptom is the same. the failure symptom is the same.
It may be of interest to the manufacturers and designers of the CD player why it failed but 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 only one symptom, as far as we the users are concerned, it has only one symptom,
`no\_sound'! `no\_sound'!
We can thus group these component failure modes into a common symptom, $SP1$, thus We can thus group these component failure modes into a common symptom, $SP1$, thus
@ -396,7 +397,7 @@ Note that $fgfm_6$, while %being a failure mode has
not being grouped as a common symptom not being grouped as a common symptom
has \textbf{not dissappeared from the analysis process}. has \textbf{not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear in the derived component. 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 faced with this dilema, is its best, to throw the brussell sprouts out of the dining~room window while the adults are not watching!}! 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 once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel 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 (see project aims in section \ref{requirements}). The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
@ -460,12 +461,12 @@ $DC$ is a derived component at a higher level of fault analysis abstraction,
than the functional~group it was derived from. than the functional~group it was derived from.
However, it can still be treated However, it can still be treated
as a component with a known set of failure modes. as a component with a known set of failure modes.
\paragraph{enumerating abstraction levels} \paragraph{Enumerating abstraction levels}
If $DC$ is included in a functional~group If $DC$ were to be included in a functional~group,
that functional~group must be considered to be a a higher level of that functional~group must be considered to be at a higher level of
abstraction than a base level functional~group. abstraction than a base level functional~group.
% %
In fact if the abstraction level is enumerated In fact, if the abstraction level is enumerated,
the functional~group must take the abstraction level the functional~group must take the abstraction level
of the highest assigned to any of its components. of the highest assigned to any of its components.
% %
@ -696,15 +697,15 @@ A Sound system might have, for instance only four faults at its highest or Syste
\small \small
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$ $$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
\normalsize \normalsize
The number of causes for any of these faults is very large ! The number of causes for any of these faults is very large.
It does not matter which combination of causes caused the fault to the user. It does not matter to the user, which combination of causes caused the fault.
But as the hierarchy goes up in abstraction level the number of faults goes down. But as the hierarchy goes up in abstraction level, the number of faults goes down.
\subsection{Tracable Fault Modes} \subsection{Tracable Fault Modes}
Because the fault modes are determined from the bottom-up, the causes Because the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees. for all high level faults naturally form trees.
Minimal cut sets \cite{nasafta} can be determined from these, and by Minimal cut sets \cite{nasafta} can be determined from these, and by
analysing the statistical likely hood of the component failures analysing the statistical likelyhood of the component failures,
the MTTF and SIL\cite{en61508} levels can be automatically calculated. the MTTF and SIL\cite{en61508} levels can be automatically calculated.