Adding glossary entries

This commit is contained in:
Robin Clark 2011-01-24 18:00:10 +00:00
parent 48a4eeccdd
commit 6da60ba705
12 changed files with 64 additions and 2 deletions

View File

@ -492,6 +492,11 @@ and the probablistic failure rate of each classification
is represented by lambda variables
(i.e. $\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
\glossary{name={SD},description={Safe Detected; a SYSTEM level failure mode that is considered safe, and is detected by self checking mechanisms}}
\glossary{name={SU},description={Safe Undetected; a SYSTEM level failure mode that is considered safe, and is not detected by self checking mechanisms}}
\glossary{name={DD},description={Dangerous Detected; a SYSTEM level failure mode that is considered dangerous, and is detected by self checking mechanisms}}
\glossary{name={DU},description={Dangerous Undetected; a SYSTEM level failure mode that is considered dangerous, and is not detected by self checking mechanisms}}
Because it is recognised that some failure modes may not be discovered theoretically during the static
analysis, the
% admission of how daft it is to take a component failure mode on its own
@ -601,6 +606,7 @@ apply to an installed plant, i.e. a complete installed and working SYSTEM.
SIL ratings for individual components or
sub-systems are meaningless, and the nearest equivalent would be the
FIT/PFD and SFF and diagnostic coverage figures.}.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}

View File

@ -15,9 +15,12 @@ The methodology developed was designed to cope with
both the deterministic\footnote{Deterministic failure mode analysis traces failure mode effects} and probablistic approaches
\footnote{Probablistic failure mode analysis tries to determine the probability of given SYSTEM failure modes, and pfrom these
can determine an overall failure rate, in terms of probability of failure on demand, or failure in time (or Mean Time to Failure (MTTF).}.
\glossary{name={safety critical},description={A safety critical system is one in which its failure may result in death or serious injury to humans, an environemntal catastophy or severe loss or damage}}
\paragraph{Safety Critical Controllers, knowledge and culture sub-disiplines}
The maturing of the application of the programmable electronic controller (PEC)
\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actucators interfaced electronically, with some firmware/software component in overall control}}
for a wide range safety critical applications, has led to a fragmentation of subdisiplines
which speak imperfectly to one another.
The main three sub-disiplines are Electrical, Software and Mechanical Engineering.
@ -31,6 +34,7 @@ For failure mode analysis a common notation, across disiplines is a very desirab
tool.
\paragraph{Safety Assessment/analysis of PEC's}
\glossary{name={safety assessment},description={A critical appraisal, typically following legal or formal guidelines, which will encompass design, and failure effects analysis}}
For a anyone responsible for ensuring or proving the safety of a PEC must be able
to understand the process being controlled, the mechanical and electrical
sensors and actuators and the software. Not only must the
@ -238,6 +242,7 @@ a process of modularisation from the bottom~up.
\end{list}
\section{Safety Critical Systems}
\glossary{name={safety critical},description={A safety critical system is one in which its failure may result in death or serious injury to humans, an environemntal catastophy or severe loss or damage}}
%
%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.
@ -266,6 +271,8 @@ hours of operation} of operation or
a given statistical failure on demand.
This is the probablistic approach and is embodied in the European Standard
EN61508 \cite{en61508} (international standard IOC1508).
\glossary{name={deterministic},description={Deterministic in the context of failure mode analysis, traces the causes of SYSTEM level events to base level component failure modes}}
\glossary{name={probablistic},description={Probablistic in the context of failure mode analysis, traces the probability of base level failure modes causing of SYSTEM level events/failure modes}}
\paragraph{Deterministic safety Measures}
The second philosophy, applied to application specific standards, is to investigate
@ -332,7 +339,8 @@ unhandled failures could create dangerous faults.
%designed correctly no `undetected faults' should be present here.
%
\section{An Outline of the FMMD Technique}
{\fmmdgloss}
%\glossary{name={FMMD},description={Failure Mode Modular De-Composition}}
The FMMD methodology takes a bottom up approach to
the design of an integrated system.
%

View File

@ -839,3 +839,6 @@ from an FMEA perspective as a component itself, with a set of known failure mode
%\vspace{20pt}
%
%%typeset in {\Huge \LaTeX} \today
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}

View File

@ -426,6 +426,9 @@ failure statistics we calculate the reliability of this circuit.
The formula for given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor
is reproduced in equation \ref{resistorfit}. The meanings
and values assigned to its co-efficients are described in table \ref{tab:resistor}.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
\begin{equation}
% fixed comp resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E
@ -510,6 +513,8 @@ Thus thermistor, bead type, non military spec is given a FIT of 315.0
Using the RIAC finding we can draw up the following table (table \ref{tab:stat_single}),
showing the FIT values for all faults considered.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
@ -840,6 +845,8 @@ because here we have found a fault that we cannot detect at this
level. This means that should we wish to cope with
this fault, we need to devise a way of detecting this
condition in higher levels of the system.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}

Binary file not shown.

View File

@ -81,7 +81,9 @@
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
%\newcommand{\pic}{\em pure~intersection~chain}
\newcommand{\pic}{\em pair-wise~intersection~chain}
\newcommand{\wrt}{\em with-respect~to}
\newcommand{\wrt}{\em with~respect~to}
\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functioal groups of components and creating derived components representing them, and in turn using the derived components to crate higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}}
%----- Display example text (#1) in typewriter font

View File

@ -79,6 +79,12 @@ This means that each system level error (or undesireable event) requires its own
This increases the amount of work to do, and in the case of updates to
particular sub-systems, introduces the requirement to update every FTA
tree modelling that sub-system.
From an FTA tree sets of base level events can be traced to SYSTEM level failures.
Thes are termed `cut sets'. A further refinement of this is the minimal cut set,
a reduced from of the `cut set' that contains the minimum number of base level
events to cause a particular SYSTEM failure.
\glossary{name={cut set}, description={A cut set in a fault tree is a set of base component failure modes, whose occurrence ensures that a TOP (or SYSTEM) event occurs} }
\glossary{name={minimal cut set}, description={A cut set in a fault tree that cannot be reduced (i.e. \textbf{all} the base component failure modes are required to cause the SYSTEM level event) } }
\subsubsection{ FTA weaknesses }
\begin{itemize}
@ -285,6 +291,9 @@ The following gives an outline of the procedure.
FMEDA is a statistical analysis methodology and is used from one of two perspectives,
Probability of Failure on Demand (PFD), and Probability of Failure
in continuous Operation, or Failure in Time (FIT).
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
\label{survey:fit}
\paragraph{Failure in Time (FIT).} Continuous operation is measured in failures per billion ($10^9$) hours of operation.
For a continuously running nuclear powerstation, industrial burner or aircraft engine
@ -333,6 +342,9 @@ if the SYSTEM error it is tied to is dangerous or safe.
The decision for this may be
based on heuristics or field data.
EN61508 uses the $\lambda$ symbol to represent probabilities.
\glossary{name={Lambda $\lambda$},description={Failure rate is often denoted as Lambda ($\lambda$) }}
Because we have statistics for each component failure mode,
we can now now classify these in terms of safe and dangerous lambda values.
Detectable failure probabilities are labelled `$\lambda_D$' (for
@ -366,6 +378,11 @@ $\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
These new failures are added to the model.
%SD, SU, DD, DU.
\glossary{name={SD},description={Safe Detected; a SYSTEM level failure mode that is considered safe, and is detected by self checking mechanisms}}
\glossary{name={SU},description={Safe Undetected; a SYSTEM level failure mode that is considered safe, and is not detected by self checking mechanisms}}
\glossary{name={DD},description={Dangerous Detected; a SYSTEM level failure mode that is considered dangerous, and is detected by self checking mechanisms}}
\glossary{name={DU},description={Dangerous Undetected; a SYSTEM level failure mode that is considered dangerous, and is not detected by self checking mechanisms}}
With these classifications, and statistics for each component
we can now calculate statistics for the diagnostic coverage (how good at `self checking' the system is)
and its safe failure fraction (how many of its failures are self detected or safe compared to
@ -456,6 +473,8 @@ With one component failure mode per row,
all the statistical factors for SIL rating can be produced\footnote{A SIL rating will apply
to an installed plant, i.e. a complete installed and working SYSTEM. SIL ratings for individual components or
sub-systems are meaningless, and the nearest equivalent would be the FIT/PFD and SFF and diagnostic coverage figures.}.
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
@ -555,6 +574,9 @@ We can perform some tests that give us 60\% coverage etc
\subsection{Diagnostic interval}
Reducing FIT with detecting a fraction of the faults within an interval. Give formulas etc
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
\subsection{Redundancy - Models}

View File

@ -44,6 +44,7 @@ The attribute $\alpha$ can be used to track the
level of fault abstraction of components in an FMMD hierarchy. Because base and derived components
are collected to form functional groups, a hierarchy is
naturally formed with the abstraction levels increasing with each tier.
\fmmdgloss
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}

View File

@ -5,6 +5,7 @@
\section{Background:\\ FMMD outline}
The symptom abstraction process described here, is a core process in the
%Failure Mode Modular De-Composition
\fmmdgloss
FMMD modelling methodology. FMMD builds a hierarchy of failure mode behaviours from the bottom up.
To start with collections of base components are chosen to form functional~groups, which are analysed
w.r.t. its failure mode behaviour.

View File

@ -24,6 +24,7 @@ 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.
\fmmdgloss
%
From the fault data model, automatic generation
of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} are possible.

View File

@ -209,3 +209,14 @@ Base Component & Any bought in component, or \\
\caption{Symptom Extraction Definitions}
\label{tab:symexdef}
\end{table}
\glossary{name={system}, description={A product designed to work as a coherent entity}}
\glossary{name={sub-system}, description={A part of a system, sub-systems may contain sub-systems and so-on}}
\glossary{name={derived component}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}}
\glossary{name={functional group}, description={A collection of sub-systems and/or components that interact to perform a specific function}}
\glossary{name={symptom}, description={A failure mode of a functional group (of components), caused by a combination of its component failure modes}}
\glossary{name={base component}, description={Any bought in component, or lowest level module/or part}}
%\glossary{name={entry name}, description={entry description}}