added to introduction. Ill (bronchitis ~ off work ~ temperature)

but still need to finish the last example circuit for C Garret
This commit is contained in:
Robin Clark 2012-01-26 19:36:08 +00:00
parent 3ae3a4ca63
commit abb122a1a8

View File

@ -28,6 +28,7 @@
\begin{document}
\begin{abstract}
\pagenumbering{roman}
Circuits from email conversation.
Not a document to be proof read.
@ -37,24 +38,53 @@ Proof of analysis concept.
Function $fm$ applied to a component returns its failure modes.
The circuits specified are not typical saftey critical circuitry which usually
The circuits specified are not typical safety critical circuitry which usually
has both redundancy and self~checking and/or diagnostic features build in.
These are examples of the FMMD methodology being applied to some standard electronic circuits.
\end{abstract}
\maketitle
\tableofcontents
\listoffigures
\listoftables
\clearpage
\clearpage \pagenumbering{arabic}
\section{Basic Concepts Of FMMD}
The idea behind FMMD is to modularise, from the bottom-up, traditional FMEA techniques.
Traditional FMEA takes part failure modes and then determines what effect each of these
failure modes could have on the system under investigation.
It is worth defining clearly the term part here.
Geoffry Hall writing in space Craft Systems Engineering~\cite{scse}[p.619], defines it thus:
``{Part(definition)}---The Lowest level of assembly, beyond which further disassembly irrevocably destroys the item''.
In the field of electronics a resistor, capacitor and op-amp would fit this definition of a `part'.
Failure modes for part types can be found in the literature~\cite{fmd91}\cite{mil1991}.
Traditional FMEA, by looking at `part' level failure modes
involves what we could term a large `reasoning~distance'; that is to say
in a complex system, taking a particular failure mode, of a particular part
and then trying to predict the outcome in the context of an entire system, is
a leap~of~faith. There will be numerous possibilities of effects and side effects on
other components in the system; more than is practically possible to rigorously examine.
To simply trace a simple route from a particular part failure mode to a top level system error/symptom
oversimplifies the task of failure mode analysis, and makes the process arbitrary and error prone.
Fortunately most real-world designs take a modular approach. In Electronics
for instance, commonly used configurations of parts are used to create
amplifiers, filters, potential dividers etc.
It is therefore natural to collect parts to form functional groups.
These commonly used configurations of parts, or {\fgs}, will
also have failure mode behaviour. We can take a {\fg} and determine its symptoms of failure.
When we have done this we can treat this as a component in its own right.
If we terms `parts' as base~components and components we have determined
from functional groups as derived components, we can modularise the FMEA task.
If we start building {\fgs} from derived components we can start to build a modular
hierarchical failure mode model.
\paragraph {Definitions}
\begin{itemize}
\item {\bc} - a component with a known set of unitary state failure modes. Base here mean a starting or `bought~in' component.
\item {\bc} - is taken to mean a `part' as defined above~\cite{scse}[p.619]. We should be able to define a set of failure modes for every {\bc}.
\item {\fg} - a collection of components chosen to perform a particular task
\item {\em symptom} - a failure mode of a functional group caused by one or more of its component failure modes.
\item {\dc} - a new component derived from an analysed {\fg}
@ -66,7 +96,6 @@ level up to the top, or system level, with analysis stages between each
transition to a higher level in the hierarchy.
The first stage is to choose
{\bcs} that interact and naturally form {\fgs}. The initial {\fgs} are collections of base components.
%These parts all have associated fault modes. A module is a set fault~modes.