Introduction text added to
This commit is contained in:
parent
e3a27047ea
commit
b6e2f8bcd4
@ -4,18 +4,44 @@
|
||||
|
||||
%% $$ \int_{0\-}^{\infty} f(t).e^{-s.t}.dt \; | \; s \in \mathcal{C}$$
|
||||
|
||||
This thesis describes the application of, mathematical (formal) techniques to
|
||||
the design of safety critical systems.
|
||||
The initial motivation for this study was to create a system
|
||||
applicable to industrial burner controllers.
|
||||
The methodology developed was designed to cope with
|
||||
both the
|
||||
deterministic
|
||||
and
|
||||
probablistic approaches.
|
||||
\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.
|
||||
|
||||
The visual notation developed was initially designed for electronic fault modelling.
|
||||
However, it was realised that it could be applied to mechanical and software domains as well.
|
||||
\paragraph{Scope of thesis}
|
||||
This thesis describes the application of, a common notation mathematical notation to
|
||||
describe the design of safety critical systems/PEC's.
|
||||
The initial motivation for this study was to create a system
|
||||
applicable to industrial burner controllers\footnote{Burner Controllers cover the disiplines of
|
||||
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}.
|
||||
|
||||
\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
|
||||
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.
|
||||
|
||||
\section{Background}
|
||||
|
Loading…
Reference in New Issue
Block a user