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

Software modelling: tackle head on

Browse Source
This commit is contained in:
Robin Clark 2010-10-18 13:42:29 +01:00
parent 891a29a836
commit 25dc1eb2e6
4 changed files with 273 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
sw_model/Makefile Normal file
View File

@ -0,0 +1,21 @@
#
# Make the propositional logic diagram a paper
#
paper: paper.tex sw_model_p.tex
pdflatex paper.tex
#dvipdf paper
mv paper.pdf sw_model_paper.pdf
okular sw_model_paper.pdf
# Remove the need for referncing graphics in subdirectories
#
sw_model_p.tex: sw_model.tex
cat sw_model.tex | sed 's/sw_model\///' > sw_model_p.tex
bib:
bibtex paper

35
sw_model/paper.tex Normal file
View File

@ -0,0 +1,35 @@
\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{tikz}
\usepackage{amsfonts,amsmath}
\usepackage{ifthen}
\newboolean{paper}
\setboolean{paper}{true} % boolvar=true or false
\input{../style}
\begin{document}
\pagestyle{fancy}
%\outerhead{{\small\bf Propositional Logic Diagram}}
%\innerfoot{{\small\bf R.P. Clark } }
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark}
\title{Failure Mode Modular de-Composition of Software}
\maketitle
%
% to make the stand alone paper the processed version is required.
\input{sw_model_p}
\bibliographystyle{plain}
\bibliography{../vmgbibliography,../mybib}
%\begin{verbatim}
%$Id: paper.tex,v 1.1 2009/06/05 18:35:31 robin Exp $
%\end{verbatim}
\end{document}

214
sw_model/sw_model.tex Normal file
View File

@ -0,0 +1,214 @@
% $Id: ons calling functionsin Exp $
%
\ifthenelse {\boolean{paper}}
{
\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.
\end{abstract}
}
{
\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.
}
\section{ Modern Devices }
From the automobile to the microwave oven, we increasingly rely on
embedded computing, controlling electro mechanical
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}
Essentially data flow modelling starts with a context diagram, where
the inputs and outputs to a process are identified.
These inputs and outputs connect to a process `bubble'
representing the computing, or data transformation.
EXAMPLE CONTEXT DIAGRAM
The data input to the system is afferent data flow, the data actually processed is
known as transform data and the data output is termed `efferent' flow.
The next stage in the process is to consider the transform, or computing bubble.
Each stream of input data is taken to transform `bubbles' that
process the data and pass it on to other bubles which process the data to be sent out.
This process can continue zooming into each `bubble' until the transformation processes they
represent are simple enough to implement as functions in a programming language.
The next stage, is to pick a transform bubble somewhere in the middle
of these diagrams and assign it as the `main' \\ref{kandr} or start
funtion.
As a design methodology, ignoring real time constraints, this is a very good way
of analysiing a problem and getting a good software structure.
What is interesting though is that this naturally determines a hierarchy
where the hardware, the sensors and actuators in an embedded system,
naturally fall to the lowest point in the software hierarchy.
n fact because we use electronics to measure mechanical devices,
we can establish a hierarchy of the three domians
in terms of software.
That is to say Software at the top of the hierarchy, Electronics below it, and mechanical
systems below electronics.
%%-s is the process of identifying, modeling and documenting how data moves around an information system.
%%- Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the
%%- holding areas for data), external entities (what sends data into a system or receives data from a system),
%%- and data flows (routes by which data can flow).
%%-Discuss afferent efferent flow, how h/w naturally goes at the bottem end
%%-of the software structure.
Establish this general structure
SW
ELEC
MECH
:'e,'f move .
\section{ Software structure}
All software has a natural hierarchy or call tree structure.
The first called function will call others and the hierarchy
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.
All the functions it calls are components
that are used to build it.
\section{Failure Modes and functions}
Describe functions, how pre conditions map to
input failure modes and post conditions to
failure mode symptoms.
Traditionally written as a form of guard.
Here we are interested in the ways the functions can fail.
\section{Basic Concepts Of FMMD}
\paragraph{Creating an fault hierarchy}
%%- bias this to software...
The main idea of the methodology is to build a hierarchy of fault modes from the part
level up to highest system levels.
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.
In terms of software, we can considered the functions 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}
Follow the natural call function hierarchy, model the
flow of failure modes and symptom collection as before.
\section{interfacing Software to Hardware}
Nature of this is sensors and actuators.
Describe.
Example of failure modes of a hardware element being
integrated into s/w
Use prev example of milli-volt amp with check resistor.

3
thesis.tex
View File

@ -105,6 +105,9 @@
\chapter{A Formal Description of FMMD}
\input{fmmdset/fmmdset}
\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}