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

started work on sw model

Browse Source
This commit is contained in:
Robin Clark 2011-09-04 09:36:19 +01:00
parent 30171d16aa
commit 246ad4b8fc
2 changed files with 132 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile
View File

@ -4,7 +4,7 @@
pdf:
pdflatex thesis
okular thesis.pdf
acroread thesis.pdf &
bib:
@ -15,4 +15,4 @@ bib:
puzzle:
pdflatex puzzle.tex
pdflatex puzzle.tex
okular puzzle.pdf
acroread puzzle.pdf

147
sw_model/sw_model.tex
View File

@ -68,17 +68,18 @@ This chapter
}
\ifthenelse {\boolean{paper}}
{
\section{Basic Concepts Of FMMD}
\paragraph{Creating an fault hierarchy}
%%- bias this to software...
The main idea of the FMMD methodology is to build a hierarchy of fault behaviour
component models from the part
level up to highest system levels. This means that we model
The main core concept of the FMMD methodology is to build a hierarchy of fault behaviour
from the part
level up to highest system levels.
This means that we model
components of a system with respect to their failure modes.
Electrical and mechanical components have known and
well understood failure modes~\cite{mill1991}~\cite{fmd91}.
@ -86,26 +87,113 @@ Software functions (apart from some standard library procedures) generally are c
for a given application.
In order to model system which include mechanical and electronic
parts with software, we need some way of represent software functions
in terms of their failure mode behaviour. More than this
in terms of their failure mode behaviour. Also
we need to integrate them into a hierarchical failure mode model.
In order to perform FMMD analysis, which is a bottom up methodology, the first stage is to choose
components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts.
%These parts all have associated fault modes. A module is a set fault~modes.
From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail.
From the point of view of fault analysis, we are not interested in
the components themselves, but in the ways in which they can fail.
Contract programming defines software functions in terms of
pre-conditions, post conditions and invariants.
Breaking any of these is a failure mode, but our gaol is fitting these into the FMMD
failure mode model.
Breaking any of these is a failure mode, and contract
programming defines software failure modes useful for FMMD modelling.
For software we already have the hierarchy, thanks to the nature of the `call tree'
\subsection{Software in terms of failure modes}
For software we already have the hierarchy, thanks to the nature of the `call~tree'
in procedural languages.
This we cannot change. Software functions, call other `lower level' functions.
A function can fail when its post-conditions are not obeyed/completed/kept.
In terms of a treating a function as a component, post condition
violations are its failure modes.
Let us consider two functions $f1()$ and $f(2)$ which have
post condition violation conditions.
$$ PostCondVoliations(f1) = \{ {pcf1}_1, {pcf1}_2 \} $$
$$ PostCondVoliations(f2) = \{ {pcf2}_1, {pcf2}_2 \} $$
A function which calls other functions can thus be treated as a functional group.
Let us consider a function $f()$ which calls $f1(),f2()$.
\vbox{
\begin{verbatim}
function f() {
f1();
f2();
}
\end{verbatim}
} % vbox
Its input failure modes
are its pre-condition violations, let us define these as
$$ PreCondVoliations f() = \{ {prf}_1, {prf}_2 \} $$
For an FMMD model we need to extend the concepts of contract programming slightly.
Contract programming deals with functions in isolation.
We need the failure modes to propagate up a hierarchy
(as they do in real software systems).
We need to consider the failure effects of the called functions
failing their post-conditions as well as the pre-condition failures
defined for $f()$.
Considering the function $f()$ as an FMMD {\fg}, the failure modes
we must consider to analyse its failure mode behaviour are
its pre-condition violations and the failed post conditions of
the functions its calls.
$$ fm(f()) = \{ {prf}_1, {prf}_2, {pcf1}_1, {pcf1}_2, {pcf2}_1, {pcf2}_2 \} $$
We can now use these failure modes to help analyse how the
function $f()$ can fail. We can analyse how these
pre-condition violations will affect the $f()$
and treat these as failure symptoms of the function $f()$.
We can also add new post conditions to $f()$
(as in contract programming) to define the correct behaviour
of $f()$.
Together these become the symptoms of failure of function $f()$.
We can now treat $f()$ as a component and use its
symptoms as failure modes.
A function calling $f()$, using FMMD would have to
consider these failure modes, when calling $f()$.
In this way a software hierarchy, in terms of failure
modes can be built up.
This is an extension of contract programming in that it
provides a formal basis for linking functions together
into a software hierarchy.
It also means that any failed post conditions
of a function called, must be considered in the failure model,
something that can be checked and controlled by a software tool.
%This we cannot change.
\subsection{Interfacing Software to Electronic {\wrt} failure modes}
Software functions, call other `lower level' functions.
The lowest level functions generally either provide some
for of data transformation (i.e. a mathematical function such as {\em sin(x)})
or interact with I/O. I/O is generally an interface to
or interact with inputs and outputs (I/O).
Software interaction with I/O is generally via to
electronics. Where mechanical components are present, they are generally
controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273]
controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273].
Obviously in order to integrate software with electronic components we need
to define this interface.
A typical and common function is being able to read a voltage into
a computer program. This example is discussed in section \ref{sec:adc}.
In terms of software, we can consider the data transformations and functions used/called by a function to be the components.
The functions called will have known failure modes (i.e. they could fail their post conditions).
@ -117,8 +205,20 @@ In the case of I/O modules, these will be derived components with their own sets
If a function calls a function, the failure modes would be failed post-conditions of the called function.
\subsection{FMMD Process}
Diagram showing components with failure modes,
the functional group; the collection of failure modes;
the analysis stage; the symptoms, and finally the derived component.
Now diagram showing software function,
with pre-conditions, invariants and post conditions.
Now an integrated diagram, showing the
pre-condition violations as failure modes
The failure modes of a functions components
@ -142,9 +242,7 @@ the failure symptoms of the {\fg} as its set of failure modes.
We thus consider that our software function can fail in a number of given ways.
This new {\dc} is at a higher failure mode abstraction
level than the {\bcs}.
} % ifdef papaer
{
}
\subsection{ An example function analysed in terms of failure modes }
@ -152,8 +250,23 @@ OK here an example reading an ADC
The values could be out of range (a pre-condition)
The post condition is sending back a voltage, with an error condition
This simple ADC read function contains no self checking
we cannot be sure the multiplexer switching a selection
of inputs to it is functioning, and we do not know
the ADC reference voltage is accurate.
What this means is the fundamental aspects of safely reading a voltage, i.e.
we are reading the right input, and the accuracy or the reading cannot be detected.
What we have here are effectively undetectable failure modes.
\section{example of Software to Electronics Interfacing}
\label{sec:adc}
\subsection{ A more detailed function with ADC checking features }
For safety critical product
OK here an example reading an ADC, but testing the MUX
and a mid range voltage ref + span and zero.