starting to work on sw fmmd modelling
pre conditions failure modes of software components post conditions FMMD symptoms
This commit is contained in:
parent
392a7551cb
commit
9d04ecb820
@ -45,6 +45,16 @@ NEW A PRODUCT LIFE CYCLE IMAGE WITH AN EULER DIAGRMA FOR THE DIFFERENT STANDARDS
|
||||
Different agencies - approval is testing of new product
|
||||
and verification to standard - manufacturing overwatch / supervision
|
||||
word on tip of tounge -
|
||||
\section{Legislation and Safety Standards}
|
||||
|
||||
European Directives - generalised goals for society -
|
||||
|
||||
\begin{itemize}
|
||||
\item Environmental protection
|
||||
\item Human Rights - safety in the workplace
|
||||
\end{itemize}
|
||||
|
||||
Directives become safety goals, leading to Generic standards, for some equipemnt, specific standards are written
|
||||
|
||||
\section{ Safety Goals and safety Requirements}
|
||||
Safety goals can be seen as general principles of safety.
|
||||
@ -58,9 +68,10 @@ $S_{goal}$ for the requirments to be meaningful.
|
||||
|
||||
FIND LIST
|
||||
|
||||
* To protect life and limb
|
||||
|
||||
* To protect the environment
|
||||
\begin{itemize}
|
||||
\item * To protect life and limb
|
||||
\item * To protect the environment
|
||||
\end{itemize}
|
||||
|
||||
We can express this as
|
||||
$$ \forall S_{req} \longrightarrow S_{goal}. $$
|
||||
|
||||
@ -49,6 +49,64 @@ embedded industrial control machinery.
|
||||
|
||||
}
|
||||
|
||||
\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.
|
||||
|
||||
|
||||
In order to perform FMMD analysis, which is a bottom up ethodology, 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.
|
||||
For software we already have the hierarchy, thanks to the nature of the `call tree'
|
||||
in procedural languages.
|
||||
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 can fail their post conditions).
|
||||
|
||||
|
||||
For this study a {\fg} will mean a collection of components.
|
||||
In order to determine the symptoms or failure modes of a {\fg},
|
||||
we need to consider all failure modes of its components.
|
||||
By analysing the fault behaviour of a `{\fg}' with respect these failure modes
|
||||
we can derive a new set of possible failure modes.
|
||||
Thus we can consider how a software function will react to the failure modes of the functions it calls.
|
||||
%
|
||||
This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of
|
||||
fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.
|
||||
|
||||
In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts.
|
||||
These new failure~modes are derived failure modes.
|
||||
%The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
|
||||
%being derived from the {\fg}.
|
||||
We can now create a new `{\dc}' which has
|
||||
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
|
||||
{
|
||||
}
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
Reference the symptom abstraction paper here
|
||||
}
|
||||
{
|
||||
This analysis and symptom collection process is described in detail in the Symptom extraction (see chapter \ref{symptomex}).
|
||||
}
|
||||
|
||||
|
||||
|
||||
\section{ Modern Devices }
|
||||
|
||||
From the automobile to the microwave oven, we increasingly rely on
|
||||
@ -58,7 +116,7 @@ devices etc etc etc
|
||||
\section{ Data Flow Modelling }
|
||||
|
||||
A computer system can be considered to simply process data, and data flow modelling
|
||||
exists in various forms. \cite{yourdon} \cite{sommerville}
|
||||
exists in various forms.~\cite{yourdon}~\cite{sommerville}
|
||||
|
||||
Essentially data flow modelling starts with a context diagram, where
|
||||
the inputs and outputs to a process are identified.
|
||||
@ -124,7 +182,6 @@ ELEC
|
||||
|
||||
MECH
|
||||
|
||||
:'e,'f move .
|
||||
|
||||
|
||||
\section{ Software structure}
|
||||
@ -136,8 +193,38 @@ will be controlled by a call stack.
|
||||
\section{FMEA applied to s/w}
|
||||
|
||||
%tref navy Msc
|
||||
Failure MOde Effects analysis can be applied to software.
|
||||
We can treat a software function as a funtional group.
|
||||
Failure Mode Effects analysis can be applied to software.
|
||||
We can treat a software function as a component.
|
||||
It has a set of failure modes, or outputs that
|
||||
can be incorrect. In contract programming these correspond to the post-conditions for the function.
|
||||
The parameters passed to the function, or return values from functions it calls,
|
||||
can be considered the pre-conditions.
|
||||
|
||||
Because of the hierichical nature of software functions
|
||||
we can consider functions from the FMMD perspective as
|
||||
{\dcs}.
|
||||
The failure modes of the {\dc} are where failures
|
||||
in post conditions occur.
|
||||
The failure modes to consider for a function, or pre-condition
|
||||
failures, are the parameters passed to it and any values
|
||||
it uses (external data or values from function calls that it makes).
|
||||
Recursion potentially complicates this, however
|
||||
functions are banned for high integrity levels
|
||||
of most standards in the field of embedded computing.
|
||||
EN61508\cite{en61508} specifically bans recursive
|
||||
calls for SIL 2 on higher. Some microcontroller families~\cite{PIC18}
|
||||
make classic recursion impossible, by using memory mapping for
|
||||
parameters as opposed to a general purpose stack.
|
||||
\paragraph{Design Constraint: FMMD and recursive function calls}
|
||||
FMMD will not support recursion in its modelling of software.
|
||||
|
||||
|
||||
Now need a simple example C program, where I have functions
|
||||
with pre and post conditions and show these as an fmmd hierarchy
|
||||
really nice touch would be to have the pre and post conditions
|
||||
as comments and then to automatically process them into an FMMD analysis tool
|
||||
|
||||
|
||||
All the functions it calls are components
|
||||
that are used to build it.
|
||||
|
||||
@ -150,65 +237,10 @@ failure mode symptoms.
|
||||
Traditionally written as a form of guard.
|
||||
|
||||
Here we are interested in the ways the functions can fail.
|
||||
They can fail if given the wrong data, or there can be a mistake in the code
|
||||
which causes an incorrect output.
|
||||
|
||||
|
||||
\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.
|
||||
|
||||
|
||||
In order to perform FMMD analysis, which is a bottom up ethodology, 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.
|
||||
For software we already have the hierarchy, thanks to the nature of the `call tree'
|
||||
in procedural languages.
|
||||
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 can fail their post conditions).
|
||||
|
||||
|
||||
For this study a {\fg} will mean a collection of components.
|
||||
In order to determine the symptoms or failure modes of a {\fg},
|
||||
we need to consider all failure modes of its components.
|
||||
By analysing the fault behaviour of a `{\fg}' with respect these failure modes
|
||||
we can derive a new set of possible failure modes.
|
||||
Thus we can consider how a software function will react to the failure modes of the functions it calls.
|
||||
%
|
||||
This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of
|
||||
fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.
|
||||
|
||||
In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts.
|
||||
These new failure~modes are derived failure modes.
|
||||
%The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
|
||||
%being derived from the {\fg}.
|
||||
We can now create a new `{\dc}' which has
|
||||
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}.
|
||||
%What this means is the `fault~symptoms' of the module have been derived.
|
||||
%
|
||||
%When we have determined the fault~modes at the module level these can become a set of derived faults.
|
||||
%By taking sets of derived faults (module level faults) we can combine these to form modules
|
||||
%at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
|
||||
%to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
|
||||
%as parts, parts which may now be combined to create new functional groups,
|
||||
%but as parts at a higher level of fault abstraction.
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
Reference the symptom abstraction paper here
|
||||
}
|
||||
{
|
||||
This analysis and symptom collection process is described in detail in the Symptom extraction (see chapter \ref{symptomex}).
|
||||
}
|
||||
|
||||
|
||||
\section{ Applying Software to the FMMD Hierarchy}
|
||||
|
||||
@ -219,6 +251,47 @@ flow of failure modes and symptom collection as before.
|
||||
|
||||
\section{interfacing Software to Hardware}
|
||||
|
||||
\subsection{The medium on which software executes}
|
||||
Software, is an abstract formal representation of the procedures
|
||||
and mathematical processing to achieve a goal. For it to run
|
||||
in the `real~world', it has to run on some form of
|
||||
processor. Typically this will, in the case of embedded safety critical
|
||||
applications, be on some form of micro-controller.
|
||||
|
||||
Modern micro controllers are highly intgerated devices.
|
||||
A typical low cost micro-controller will
|
||||
have at least the following functional modiules intgrated into it:
|
||||
|
||||
\begin{itemize}
|
||||
\item Analogue to Digital Converter (ADC),
|
||||
\item Universal Asynchronous Receiver Transmitter (UART),
|
||||
\item Serial Peripheral Interface (SPI), a synchronous serial data link used to transfer data between chips on a PCB ,
|
||||
\item Controller Area Network (CAN) an industrailly hardened shhort messaging serial bus,
|
||||
\item Capture Compare PWM CCP (counters, timers and pulse width modulation output),
|
||||
\item interrupt triggering facilities
|
||||
\item digital I/O.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
%% Super bbc micro all on one 28 pin chip
|
||||
|
||||
Obviously were a microcontroller to fail internally,
|
||||
it could fail and not affect any of its other modules.
|
||||
Should a failure occur in an unused module, the
|
||||
application would never detect it.
|
||||
This means that we could easily have more than one
|
||||
failure at any given time.
|
||||
This means that were we to try to place a microcontroller into a failure model,
|
||||
apart from being unwieldingly large, it would
|
||||
disobey the unintary state failure mode constraint of FMMD (see section \ref{unitarystate}).
|
||||
|
||||
\paragraph{The need to de-compose highly integrated components}
|
||||
|
||||
|
||||
\paragraph{Consider module activation within highly integrated component as a soource of failure}
|
||||
|
||||
\subsection{Context of firmware in a small System}
|
||||
|
||||
Nature of this is sensors and actuators.
|
||||
Describe.
|
||||
Example of failure modes of a hardware element being
|
||||
|
||||
20
thesis.tex
20
thesis.tex
@ -71,10 +71,10 @@
|
||||
\chapter{Safety Critical systems Analysis}
|
||||
\input{statistics/statistics}
|
||||
|
||||
\chapter{Survey of Safety Critical \\ Analysis Methodologies \\ and Tools Available}
|
||||
\typeout{ ---------------- Survey of Safety Critical Analysis Methodologies and Tools Available}
|
||||
\chapter{Survey of Safety Critical Analysis Methodologies and Tools Available}
|
||||
\input{survey/survey}
|
||||
|
||||
|
||||
\chapter{An overview of European and North Americans Standards}
|
||||
\input{standards/standards}
|
||||
|
||||
@ -87,6 +87,7 @@
|
||||
|
||||
|
||||
|
||||
\typeout{ ---------------- FMMD formal MODEL }
|
||||
\chapter{A Formal Description of FMMD}
|
||||
\input{fmmdset/fmmdset}
|
||||
|
||||
@ -101,10 +102,6 @@
|
||||
\chapter {Symptom Extraction Process }
|
||||
\input{symptom_ex_process/symptom_ex_process}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\typeout{ ---------------- Propositional Logic Diagrams}
|
||||
\chapter {Propositional Logic Diagrams}
|
||||
\input{logic_diagram/logic_diagram}
|
||||
@ -113,6 +110,10 @@
|
||||
\chapter {Common Electronic Components as PLDs}
|
||||
\input {components_as_plds/components_as_plds}
|
||||
|
||||
\typeout{ ---------------- Modelling Software With FMMD}
|
||||
\chapter{Modelling Software With FMMD}
|
||||
\input{sw_model/sw_model}
|
||||
|
||||
\typeout{ ---------------- Software as PLDs}
|
||||
\chapter {Software as PLDs}
|
||||
\input{sw_as_plds/sw_as_plds}
|
||||
@ -123,15 +124,10 @@
|
||||
%\input{mech_as_plds/mech_as_plds}
|
||||
|
||||
|
||||
|
||||
|
||||
\typeout{ ---------------- Symptom Extraction }
|
||||
\typeout{ ---------------- Symptom Extraction Using PLD}
|
||||
\chapter {Symptom Extraction using PLD Diagrams }
|
||||
\input{symptom_abstraction/symptom_abstraction}
|
||||
|
||||
\chapter{Modelling Software With FMMD}
|
||||
\input{sw_model/sw_model}
|
||||
|
||||
|
||||
\chapter{FMMD functional~group to \\derived component example : PT100 4 wire Temperature Sensor}
|
||||
\typeout{ ---------------- pt100}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user