From 9d04ecb82029361a66b740de81e49591fa0dd4e9 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 5 Feb 2011 15:11:54 +0000 Subject: [PATCH] starting to work on sw fmmd modelling pre conditions failure modes of software components post conditions FMMD symptoms --- standards/standards.tex | 17 +++- sw_model/sw_model.tex | 195 +++++++++++++++++++++++++++------------- thesis.tex | 20 ++--- 3 files changed, 156 insertions(+), 76 deletions(-) diff --git a/standards/standards.tex b/standards/standards.tex index fe18465..6e4d75b 100644 --- a/standards/standards.tex +++ b/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 - -* 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}. $$ diff --git a/sw_model/sw_model.tex b/sw_model/sw_model.tex index fda66ff..042613f 100644 --- a/sw_model/sw_model.tex +++ b/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. -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 diff --git a/thesis.tex b/thesis.tex index f43ddf9..ea03be4 100644 --- a/thesis.tex +++ b/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}