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

General edits

Browse Source
This commit is contained in:
Robin Clark 2011-01-22 13:34:55 +00:00
parent e3ddd1194d
commit 776d1049d7
3 changed files with 57 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
introduction/introduction.tex
View File

@ -4,28 +4,6 @@
%% $$ \int_{0\-}^{\infty} f(t).e^{-s.t}.dt \; | \; s \in \mathcal{C}$$
\paragraph{Safety Critical Controllers, knowledge and culture sub-disiplines}
The maturing of the application of the programmable electronic controller (PEC)
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.
Additional disiplines are defined by application area of the PEC. These sub-displines
are in turn split into even finer units.
The practicioners of these fields tend to view a PEC in different ways.
Discoveries and culture in one field diffuse only slowly into the conciousness of a specialist in another.
Too often, one disipline's unproven assumptions or working methods, are treated as firm boundary conditions
for an overlapping field.
\paragraph{Safety Assessment/analysis of PEC's}
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
safety engineer understand more than four potential disiplines, he/she
must be able to trace failure modes of components to SYSTEM levels failure modes,
and classify these according to their criticallity.
\paragraph{Desirability of a common failure mode notation}
Having a common failure mode notation accross all disciplines in a project
would allow all the specialists to prepare failure mode
analysis and then bring them together to model the PEC.
\paragraph{Scope of thesis}
This thesis describes the application of, a common notation mathematical notation to
@ -35,15 +13,57 @@ applicable to industrial burner controllers\footnote{Burner Controllers cover th
combustion, high pressure steam and hot water, mechanical control, electronics and embedded software.}.
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}.
\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).}.
\paragraph{Safety Critical Controllers, knowledge and culture sub-disiplines}
The maturing of the application of the programmable electronic controller (PEC)
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.
Additional disiplines are defined by application area of the PEC. All of these sub-displines
are in turn split into even finer units.
The practicioners of these fields tend to view a PEC in different ways.
Discoveries and culture in one field diffuse only slowly into the conciousness of a specialist in another.
Too often, one disipline's unproven assumptions or working methods, are treated as firm boundary conditions
for an overlapping field.
For failure mode analysis a common notation, across disiplines is a very desirable and potentially useful
tool.
\paragraph{Safety Assessment/analysis of PEC's}
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
safety engineer understand more than four potential disiplines, he/she
must be able to trace failure modes of components to SYSTEM levels failure modes,
and classify these according to their criticallity.
\paragraph{Desirability of a common failure mode notation}
Having a common failure mode notation accross all disciplines in a project
would allow all the specialists to prepare failure mode
analysis and then bring them together to model the PEC.
\paragraph{Visual form of the notation}
The visual notation developed was initially designed for electronic fault modelling.
The notation deals with failure modes of components using a diagram derived from
This notation deals with failure modes of components using concepts derived from
Euler and Spider diagrams.
However, as the notation dealt with generic failure modes, it was realised that it could be applied to mechanical and software domains as well.
This changed the target for the study slightly to encompass these three domains in a common notation.
\paragraph{PEC's: Legal and Insurance Issues}
In most safety critical industries the operators of plant have to demonstrate a through consideration of safety.
There is also usually a differentiation between the manufacturers
and the the plant operators.
The manufacturers have to ensure
that the device is adaquately safe for use in its operational context.
This usually means conforming to device specific standards~\footnote{in Europe, conformance to European Norms (EN) are legal requirements
for specific types of controllers, and in the USA conformance to Underwriters Laboratories (UL) standards
are usually a mimimum requirement to take out insurance}, and offering training
of operators.
Operators of safety critical plant are concerned with maintenance and legal obligations for
periodic safety checks (both legal and insurance driven).
\section{Background}
I completed an MSc in Software engineering in 2004 at Brighton University while working for
@ -65,7 +85,7 @@ of this process however, is `static testing'. This involves looking at the desig
from the perspective of environmental stresses, natural input fault conditions\footnote{For instance in a burner controller, the gas supply pressure reducing},
components failing, and the effects on safety this could have.
Some static testing involves checking that the germane `EN' standards have
been complied with\footnote{for instance protection levels of enclosure, or down rating of electrical components}.
been complied with\footnote{for instance protection levels of an enclosure for the device, or down rating of electrical components}.
Failure Mode Effects Analysis (FMEA) was also applied. This involved
looking in detail at selected critical sections of the product and proposing
component failure scenarios.

7
mybib.bib
View File

@ -5,6 +5,13 @@
% $Id: mybib.bib,v 1.3 2009/11/28 20:05:52 robin Exp $
@ARTICLE{ftahistory,
AUTHOR = "Clifton Ericsson",
TITLE = "Fault Tree Analysis a History",
JOURNAL = "Proceedings of the 17th international safety conference",
YEAR = "1999"
}
@ARTICLE{fafmea,
AUTHOR = "Zigmund Bluvband, Pavel Grabov",
TITLE = "Failure Analysis of FMEA",

9
survey/survey.tex
View File

@ -43,13 +43,11 @@ describe briefly what a base component failure mode is and what a system level f
\subsection { FTA }
This, like all top~down methodologies introduces the very serious problem
of missing component failure modes \cite{faa}[Ch.9].
%, or modelling at
%a too high level of failure mode abstraction.
FTA was invented for use on the minuteman nuclear defence missile
systems in the early 1960s and was not designed as a rigorous
fault/failure mode methodology.
systems in the early 1960s~\cite{ftahistory} and was not designed as a rigorous
fault/failure mode methodology.
It was designed to look for disastrous top level hazards and
determine how they could be caused.
It is more like a procedure to
@ -64,6 +62,9 @@ Consequently it was not designed to guarantee to covering all component failure
and has no rigorous in-built safeguards to ensure coverage of all possible
system level outcomes.
FTA, like all top~down methodologies introduces the very serious problem
of missing component failure modes \cite{faa}[Ch.9].
\paragraph{Outline of FTA Methodology}
FTA works by taking an undesireable event
(or SYSTEM level failure mode or TOP level failure)