From 246ad4b8fc968524e184d5b526d1c11f7b4d843e Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sun, 4 Sep 2011 09:36:19 +0100 Subject: [PATCH] started work on sw model --- Makefile | 4 +- sw_model/sw_model.tex | 147 +++++++++++++++++++++++++++++++++++++----- 2 files changed, 132 insertions(+), 19 deletions(-) diff --git a/Makefile b/Makefile index f6b3cd5..4b2f2cc 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/sw_model/sw_model.tex b/sw_model/sw_model.tex index 1364160..8411d3b 100644 --- a/sw_model/sw_model.tex +++ b/sw_model/sw_model.tex @@ -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.