starting to work on sw fmmd modelling

pre conditions failure modes of software components

post conditions FMMD symptoms

standards/standards.tex

@@ -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
+\begin{itemize}
-
+\item * To protect life and limb
-* To protect the environment
+\item * To protect the environment
+\end{itemize}
 
 We can express this as 
 $$ \forall S_{req} \longrightarrow S_{goal}. $$

sw_model/sw_model.tex

@@ -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.
+Failure Mode Effects analysis can be applied to software.
-We can treat a software function as a funtional group.
+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

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 Using PLD}
-
-\typeout{ ---------------- Symptom Extraction }
 \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}