Adding glossary entries
This commit is contained in:
parent
48a4eeccdd
commit
6da60ba705
@ -492,6 +492,11 @@ and the probablistic failure rate of each classification
|
|||||||
is represented by lambda variables
|
is represented by lambda variables
|
||||||
(i.e. $\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
|
(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
|
Because it is recognised that some failure modes may not be discovered theoretically during the static
|
||||||
analysis, the
|
analysis, the
|
||||||
% admission of how daft it is to take a component failure mode on its own
|
% 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
|
SIL ratings for individual components or
|
||||||
sub-systems are meaningless, and the nearest equivalent would be the
|
sub-systems are meaningless, and the nearest equivalent would be the
|
||||||
FIT/PFD and SFF and diagnostic coverage figures.}.
|
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.}}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -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
|
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
|
\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).}.
|
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}
|
\paragraph{Safety Critical Controllers, knowledge and culture sub-disiplines}
|
||||||
The maturing of the application of the programmable electronic controller (PEC)
|
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
|
for a wide range safety critical applications, has led to a fragmentation of subdisiplines
|
||||||
which speak imperfectly to one another.
|
which speak imperfectly to one another.
|
||||||
The main three sub-disiplines are Electrical, Software and Mechanical Engineering.
|
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.
|
tool.
|
||||||
|
|
||||||
\paragraph{Safety Assessment/analysis of PEC's}
|
\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
|
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
|
to understand the process being controlled, the mechanical and electrical
|
||||||
sensors and actuators and the software. Not only must the
|
sensors and actuators and the software. Not only must the
|
||||||
@ -238,6 +242,7 @@ a process of modularisation from the bottom~up.
|
|||||||
\end{list}
|
\end{list}
|
||||||
|
|
||||||
\section{Safety Critical Systems}
|
\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"?
|
%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.
|
%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.
|
a given statistical failure on demand.
|
||||||
This is the probablistic approach and is embodied in the European Standard
|
This is the probablistic approach and is embodied in the European Standard
|
||||||
EN61508 \cite{en61508} (international standard IOC1508).
|
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}
|
\paragraph{Deterministic safety Measures}
|
||||||
The second philosophy, applied to application specific standards, is to investigate
|
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.
|
%designed correctly no `undetected faults' should be present here.
|
||||||
%
|
%
|
||||||
\section{An Outline of the FMMD Technique}
|
\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 FMMD methodology takes a bottom up approach to
|
||||||
the design of an integrated system.
|
the design of an integrated system.
|
||||||
%
|
%
|
||||||
|
@ -839,3 +839,6 @@ from an FMEA perspective as a component itself, with a set of known failure mode
|
|||||||
%\vspace{20pt}
|
%\vspace{20pt}
|
||||||
%
|
%
|
||||||
%%typeset in {\Huge \LaTeX} \today
|
%%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.}}
|
||||||
|
|
||||||
|
|
||||||
|
@ -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
|
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
|
is reproduced in equation \ref{resistorfit}. The meanings
|
||||||
and values assigned to its co-efficients are described in table \ref{tab:resistor}.
|
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}
|
\begin{equation}
|
||||||
% fixed comp resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E
|
% 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}),
|
Using the RIAC finding we can draw up the following table (table \ref{tab:stat_single}),
|
||||||
showing the FIT values for all faults considered.
|
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
|
level. This means that should we wish to cope with
|
||||||
this fault, we need to devise a way of detecting this
|
this fault, we need to devise a way of detecting this
|
||||||
condition in higher levels of the system.
|
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.}}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
BIN
related_papers_books/AIAA2010.pdf
Normal file
BIN
related_papers_books/AIAA2010.pdf
Normal file
Binary file not shown.
Binary file not shown.
@ -81,7 +81,9 @@
|
|||||||
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
|
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
|
||||||
%\newcommand{\pic}{\em pure~intersection~chain}
|
%\newcommand{\pic}{\em pure~intersection~chain}
|
||||||
\newcommand{\pic}{\em pair-wise~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
|
%----- Display example text (#1) in typewriter font
|
||||||
|
|
||||||
|
@ -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
|
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
|
particular sub-systems, introduces the requirement to update every FTA
|
||||||
tree modelling that sub-system.
|
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 }
|
\subsubsection{ FTA weaknesses }
|
||||||
\begin{itemize}
|
\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,
|
FMEDA is a statistical analysis methodology and is used from one of two perspectives,
|
||||||
Probability of Failure on Demand (PFD), and Probability of Failure
|
Probability of Failure on Demand (PFD), and Probability of Failure
|
||||||
in continuous Operation, or Failure in Time (FIT).
|
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}
|
\label{survey:fit}
|
||||||
\paragraph{Failure in Time (FIT).} Continuous operation is measured in failures per billion ($10^9$) hours of operation.
|
\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
|
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
|
The decision for this may be
|
||||||
based on heuristics or field data.
|
based on heuristics or field data.
|
||||||
EN61508 uses the $\lambda$ symbol to represent probabilities.
|
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,
|
Because we have statistics for each component failure mode,
|
||||||
we can now now classify these in terms of safe and dangerous lambda values.
|
we can now now classify these in terms of safe and dangerous lambda values.
|
||||||
Detectable failure probabilities are labelled `$\lambda_D$' (for
|
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.
|
These new failures are added to the model.
|
||||||
%SD, SU, DD, DU.
|
%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
|
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)
|
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
|
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
|
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
|
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.}.
|
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}
|
\subsection{Diagnostic interval}
|
||||||
|
|
||||||
Reducing FIT with detecting a fraction of the faults within an interval. Give formulas etc
|
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}
|
\subsection{Redundancy - Models}
|
||||||
|
@ -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
|
level of fault abstraction of components in an FMMD hierarchy. Because base and derived components
|
||||||
are collected to form functional groups, a hierarchy is
|
are collected to form functional groups, a hierarchy is
|
||||||
naturally formed with the abstraction levels increasing with each tier.
|
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}
|
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
|
||||||
|
@ -5,6 +5,7 @@
|
|||||||
\section{Background:\\ FMMD outline}
|
\section{Background:\\ FMMD outline}
|
||||||
The symptom abstraction process described here, is a core process in the
|
The symptom abstraction process described here, is a core process in the
|
||||||
%Failure Mode Modular De-Composition
|
%Failure Mode Modular De-Composition
|
||||||
|
\fmmdgloss
|
||||||
FMMD modelling methodology. FMMD builds a hierarchy of failure mode behaviours from the bottom up.
|
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
|
To start with collections of base components are chosen to form functional~groups, which are analysed
|
||||||
w.r.t. its failure mode behaviour.
|
w.r.t. its failure mode behaviour.
|
||||||
|
@ -24,6 +24,7 @@ ensure complete failure mode coverage.
|
|||||||
Because the process is bottom-up, syntax checking and tracking can ensure that
|
Because the process is bottom-up, syntax checking and tracking can ensure that
|
||||||
no component failure mode can be overlooked.
|
no component failure mode can be overlooked.
|
||||||
Once a hierarchy is in place, it can be converted into a fault data model.
|
Once a hierarchy is in place, it can be converted into a fault data model.
|
||||||
|
\fmmdgloss
|
||||||
%
|
%
|
||||||
From the fault data model, automatic generation
|
From the fault data model, automatic generation
|
||||||
of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} are possible.
|
of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} are possible.
|
||||||
|
@ -209,3 +209,14 @@ Base Component & Any bought in component, or \\
|
|||||||
\caption{Symptom Extraction Definitions}
|
\caption{Symptom Extraction Definitions}
|
||||||
\label{tab:symexdef}
|
\label{tab:symexdef}
|
||||||
\end{table}
|
\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}}
|
||||||
|
Loading…
Reference in New Issue
Block a user