Merge branch 'master' of dev:/home/robin/git/thesis
Conflicts: logic_diagram/logic_diagram.tex
This commit is contained in:
commit
72741febda
@ -207,7 +207,7 @@ Unlike a top~down analysis, we cannot miss a top level fault condition.
|
||||
In all safety critical real time systems the author has worked with
|
||||
all have repeated sections of hardware.
|
||||
for instance self checking digital inputs, analog inputs, sections of circuitry to
|
||||
generate {\ft} loops, micro-processors with watchdog secondary
|
||||
generate {\ft} loops, micro-processors with watchdog~\cite{embupsys}[pp.81] secondary
|
||||
circuity.
|
||||
In other words spending time on analysing these lower level sub-systems
|
||||
seems worthwhile, since they will be used in many designs, and are often
|
||||
@ -699,7 +699,7 @@ can also exist.
|
||||
These can be checked for periodically.
|
||||
Software bugs are unpredictable.
|
||||
However there are techniques to validate software.
|
||||
These include monitoring the program timings (with watchdogs and internal checking)
|
||||
These include monitoring the program timings (with watchdogs~\cite{embupsys}[pp.81] and internal checking)
|
||||
applying validation checks (such as independent functions to validate correct operation).
|
||||
|
||||
|
||||
|
@ -85,6 +85,7 @@ for the analysis of safety critical software and hardware systems.
|
||||
{
|
||||
|
||||
}
|
||||
|
||||
Propositional Logic Diagrams (PLDs) have been created
|
||||
to collect and simplify fault~modes in safety critical systems undergoing
|
||||
static analysis.%\cite{sccs}\cite{en61508}.
|
||||
@ -113,7 +114,7 @@ in a text editor or spreadsheet, a visual method is perceived as being more intu
|
||||
%in a PLD it means that the logical conditions represent disjuction; a boolean OR condition.
|
||||
%these points may be joined.
|
||||
|
||||
PLDs use three visual features that
|
||||
PLDs use three visual features that
|
||||
can be combined to represent logic equations. Closed contours, test cases, and lines that
|
||||
link test cases.
|
||||
All features may be labelled, and the labels must be unique within a diagram, however contours may be repeated.
|
||||
@ -446,6 +447,15 @@ Note that $P$ is considered to be an $SMG$ with one element, $ (a \wedge b) $
|
||||
In failure analysis, this could be considered to be a functional~group with two failure states $a$ and $b$.
|
||||
The proposition $P$ considers the scenario where both failure~modes are active.
|
||||
|
||||
For base component level analysis, this would be considering two base component failures
|
||||
simultaneously. At higher levels of failure mode abstraction, this could represent
|
||||
sub-system failures, for instance two fuel shutdown safety valves failing to close.
|
||||
% if paper
|
||||
% more detail
|
||||
% if chapter
|
||||
% reference gas shutoff valve closure example
|
||||
%
|
||||
|
||||
\clearpage
|
||||
\subsection { Logical XOR example }
|
||||
\begin{figure}[h]
|
||||
@ -844,9 +854,19 @@ Some deterministic based safety standards are specifying
|
||||
that not only single component failure modes must be considered in
|
||||
analysis, but that the possibility of two component failing
|
||||
simultaneously must be considered.
|
||||
EN298 states that if a burner controller is in `lock out' (i.e. has detected a fault
|
||||
and has ordered a shutdown) a secondary fault cannot be allowed to put the equipment under control (the burner) into a dangerous state.
|
||||
To cover this rigorously, we are bound to consider more than one fault being active at a time.
|
||||
%<<<<<<< HEAD
|
||||
%EN298 states that if a burner controller is in `lock out' (i.e. has detected a fault
|
||||
%and has ordered a shutdown) a secondary fault cannot be allowed to put the equipment under control (the burner) into a dangerous state.
|
||||
%To cover this rigorously, we are bound to consider more than one fault being active at a time.
|
||||
%=======
|
||||
European Norm EN298~\cite{en298}[Sn.9] states that if a burner controller is in `lock out' (i.e. has detected a fault
|
||||
and has ordered a shutdown) a secondary fault cannot be allowed to put the equipement under control (the burner) into a dangerous state.
|
||||
To cover this rigorously, we must consider all faults that can lead to a LOCKOUT condition
|
||||
and then look for others that could put the system into a dangerous state after the LOCKOUT.
|
||||
In practise, this would be a gigantic (as probably impossible task).
|
||||
iWhat we can consider though, are all faults being double simultaneous in the FMMD
|
||||
methodology, because we need only look for the double faults within each functional group.
|
||||
%>>>>>>> c066ba127e610f62789d083a0be3eaa9f6b7a427
|
||||
\paragraph{Covering Double faults in a PLD Diagram}
|
||||
Because we are allowed to repeat contours in a PLD diagram,
|
||||
we can arrange them in a matrix like configuration as in figure \ref{fig:doublesim}.
|
||||
|
12
mybib.bib
12
mybib.bib
@ -2,6 +2,12 @@
|
||||
|
||||
% my bib file.
|
||||
|
||||
@ARTICLE{fmd91,
|
||||
AUTHOR = "Reliability Analysis Center",
|
||||
TITLE = "Failure Mode/Mechanisms Distributions 1991",
|
||||
JOURNAL = "United States Department of Commerce",
|
||||
YEAR = "1991"
|
||||
}
|
||||
|
||||
% $Id: mybib.bib,v 1.3 2009/11/28 20:05:52 robin Exp $
|
||||
@article{Clark200519,
|
||||
@ -89,6 +95,12 @@
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
@BOOK{embupsys,
|
||||
TITLE = "Embedded Microprocessor Systems 3rd Edition ISBN 0-7506-75434-9",
|
||||
AUTHOR = "Stuart R Ball",
|
||||
PUBLISHER = "Newnes",
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
@BOOK{alggraph,
|
||||
AUTHOR = "Alan Gibbons",
|
||||
|
@ -156,7 +156,7 @@ for the effects of component failures.
|
||||
All components have a set of known `failure modes'.
|
||||
In other words we know that a given component can fail in several distinct ways.
|
||||
Studies have been published which list common component types
|
||||
and their sets of failure modes, often with MTTF statistics \cite{mil1991}.
|
||||
and their sets of failure modes~\cite{fmd91}, often with MTTF statistics~\cite{mil1991}.
|
||||
Thus for each component, an analysis is made for each of its failure modes,
|
||||
with respect to its effect on the
|
||||
circuit. Each one of these scenarios is termed a `test case'.
|
||||
@ -170,9 +170,11 @@ Where this occurs a circuit re-design is probably the only sensible course of ac
|
||||
\subsection{Single Fault FMEA Analysis \\ of PT100 Four wire circuit}
|
||||
|
||||
\label{fmea}
|
||||
This circuit simply consists of three resistors.
|
||||
Resistors according to the DOD Electronic component fault handbook
|
||||
1991, fail by either going OPEN or SHORT circuit \cite{mil1991}.
|
||||
The PT100 circuit consists of three resistors, two `current~supply'
|
||||
wires and two `sensor' wires.
|
||||
Resistors according to the European Standard EN298:2003~\cite{en298}[App.A]
|
||||
, are considered to fail by either going OPEN or SHORT circuit\footnote{EN298:2003~\cite{en298} also requires that components are downrated,
|
||||
and so in the case of resistors the parameter change failure mode~\cite{fmd-91}[2-23] can be ommitted.}.
|
||||
%Should wires become disconnected these will have the same effect as
|
||||
%given resistors going open.
|
||||
For the purpose of this analyis;
|
||||
|
@ -104,10 +104,10 @@ failsafes meant that the objective was to iron out common failures
|
||||
not to rigorously detect all possible failures.
|
||||
Consequently it was not designed to guarantee to covering all component failure modes,
|
||||
and has no rigorous in-built safeguards to ensure coverage of all possible
|
||||
system level outcomes.
|
||||
system level outcomes~\cite{nasafta}[Section 1.2].
|
||||
|
||||
FTA, like all top~down methodologies introduces the very serious problem
|
||||
of missing component failure modes \cite{faa}[Ch.9].
|
||||
of missing component failure modes~\cite{faa}[Ch.9].
|
||||
|
||||
\paragraph{Outline of FTA Methodology}
|
||||
FTA works by taking an undesireable event
|
||||
@ -277,7 +277,7 @@ FMEA described in this section (\ref{pfmea}) is sometimes called `production FME
|
||||
|
||||
\subsection{FMECA}
|
||||
|
||||
Failure mode, effects, and criticality analysis (FMECA)~\cite{FMD-91} extends FMEA
|
||||
Failure mode, effects, and criticality analysis (FMECA)~\cite{fmd91} extends FMEA
|
||||
by associaing failure probabilities with component failure modes.
|
||||
Essentially this adds a failure outcome criticallity factor to FMEA.
|
||||
This is a bottom up methodology, which builds on an existing FMEA
|
||||
@ -326,7 +326,7 @@ this can be the number of operating cycles or demands expected.
|
||||
|
||||
\paragraph{Severity `s' value}
|
||||
Component failure modes can cause failures that have levels of severity or seriousness.
|
||||
Typical classifications are as follows:~\cite{FMD-91}
|
||||
Typical classifications are as follows:~\cite{fmd91}
|
||||
\begin{itemize}
|
||||
\item Category I - Catastrophic
|
||||
\item Category II - Critical
|
||||
@ -364,7 +364,7 @@ $s$ thus:
|
||||
%%-WIKI- FMECA tends to be preferred over FMEA in space and North Atlantic Treaty Organization (NATO) military applications,
|
||||
%%-WIKI- while various forms of FMEA predominate in other industries.
|
||||
|
||||
A second result, representing the overall reliability and safety of a component or item\cite{FMD-91}[2-17] $C$,
|
||||
A second result, representing the overall reliability and safety of a component or item~\cite{fmd91}[2-17] $C$,
|
||||
termed a criticallity number $C_r$ for the component.
|
||||
We can consider $C$ to be a flat set of component failure modes, using $cfm$ as a variable to represent them.
|
||||
% where $f \in F$)
|
||||
|
@ -142,7 +142,7 @@ These inputs and outputs connect to a process `bubble'
|
||||
representing the computing, or data transformation.
|
||||
|
||||
|
||||
Data flow diagrams (DFDs) are directed graphs.
|
||||
Data flow diagrams (DFDs) are directed graphs~\cite{embupsys}[pp.120].
|
||||
The arcs represent data flow, and the bubbles
|
||||
represent procedures that transform data.
|
||||
A `bubble' can be further
|
||||
|
Loading…
Reference in New Issue
Block a user