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

starting on software failure mode model

Browse Source
This commit is contained in:
Robin Clark 2011-09-03 16:05:10 +01:00
parent 90dfff4700
commit 30171d16aa
2 changed files with 88 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
style.tex
View File

@ -31,6 +31,7 @@
%\newcommand{\pic}{\em pure~intersection~chain}
\newcommand{\pic}{\em pair-wise~intersection~chain}
\newcommand{\wrt}{\em with~respect~to}
\newcommand{\swf}{software~function}
\newcommand{\abslevel}{\ensuremath{\Psi}}
\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}}
\newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a

123
sw_model/sw_model.tex
View File

@ -3,6 +3,7 @@
% strucure
%
% introduce concept, mapping s/w to FMMD
% how can we represent a software function in terms of failure modes
%
% yourdon data flow. Show transform bubbles and process for converting to a hierarchy of functiona calls
% show h/w at the bottom, and s/w on top.
@ -25,22 +26,22 @@
\begin{abstract}
This paper
%
describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
models failure mode behaviour in software, electronic and mechanical
domains. The methodology therefore can model integrated
software/electrical/mechanical systems. This paper concentrates
on the software modelling, begining with
a discussion on general software stucture, afferent. transform and effenet
data flow, and then the hierarchical call tree nature of software.
Software functions are then described from a failure mode perspective
integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
The paper then shows how FMMD models from electrical and mechanical
domains can be seamlessly integrated with the software failure mode models.
With a methodology that provides a common notation for these three domians
complete and connected failure mode modelling can be applied to
real time systems, such as safety critical smart devices and
embedded industrial control machinery.
% describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
% models failure mode behaviour in software, electronic and mechanical
% domains. The methodology therefore can model integrated
% software/electrical/mechanical systems. This paper concentrates
% on the software modelling, begining with
% a discussion on general software stucture, afferent. transform and effenet
% data flow, and then the hierarchical call tree nature of software.
% Software functions are then described from a failure mode perspective
% integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
% The paper then shows how FMMD models from electrical and mechanical
% domains can be seamlessly integrated with the software failure mode models.
%
% With a methodology that provides a common notation for these three domians
% complete and connected failure mode modelling can be applied to
% real time systems, such as safety critical smart devices and
% embedded industrial control machinery.
\end{abstract}
}
@ -48,22 +49,22 @@ embedded industrial control machinery.
\section{Introduction}
This chapter
%
describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
models failure mode behaviour in software, electronic and mechanical
domains. The methodology therefore can model integrated
software/electrical/mechanical systems. This paper concentrates
on the software modelling, begining with
a discussion on general software stucture, afferent. transform and effenet
data flow, and then the hierarchical call tree nature of software.
Software functions are then described from a failure mode perspective
integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
The paper then shows how FMMD models from electrical and mechanical
domains can be seamlessly integrated with the software failure mode models.
With a methodology that provides a common notation for these three domians
complete and connected failure mode modelling can be applied to
real time systems, such as safety critical smart devices and
embedded industrial control machinery.
% describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
% models failure mode behaviour in software, electronic and mechanical
% domains. The methodology therefore can model integrated
% software/electrical/mechanical systems. This paper concentrates
% on the software modelling, begining with
% a discussion on general software stucture, afferent. transform and effenet
% data flow, and then the hierarchical call tree nature of software.
% Software functions are then described from a failure mode perspective
% integrating concepts from FMEA analysis, and the concepts of pre and post conditions.
% The paper then shows how FMMD models from electrical and mechanical
% domains can be seamlessly integrated with the software failure mode models.
%
% With a methodology that provides a common notation for these three domians
% complete and connected failure mode modelling can be applied to
% real time systems, such as safety critical smart devices and
% embedded industrial control machinery.
}
@ -77,17 +78,49 @@ embedded industrial control machinery.
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.
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}.
Software functions (apart from some standard library procedures) generally are custom written
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
we need to integrate them into a hierarchical failure mode model.
In order to perform FMMD analysis, which is a bottom up ethodology, the first stage is to choose
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.
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.
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.
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
electronics. Where mechanical components are present, they are generally
controlled by electronic actuators, and measured via electronic transducers~\cite{elecsys}[pp194-273]
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).
The functions called will have known failure modes (i.e. they could fail their post conditions).
In FMMD terms these are the failure modes of the derived component.
We can view the {\swf} as a {\fg}, with components being I/O modules used
and/or functions called.
In the case of I/O modules, these will be derived components with their own sets of failure modes.
If a function calls a function, the failure modes would be failed post-conditions of the called function.
The failure modes of a functions components
For this study a {\fg} will mean a collection of components.
@ -113,6 +146,24 @@ level than the {\bcs}.
{
}
\subsection{ An example function analysed in terms of failure modes }
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
\subsection{ A more detailed function with ADC checking features }
OK here an example reading an ADC, but testing the MUX
and a mid range voltage ref + span and zero.
The values could still be out of range (a pre-condition)
The post condition is sending back a voltage, with an error condition
\subsection{ Higher level failure mode analysis }
\ifthenelse {\boolean{paper}}