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

.

Browse Source
This commit is contained in:
Robin Clark 2010-10-18 15:05:01 +01:00
parent 25dc1eb2e6
commit 242dcb79ba
1 changed files with 24 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
sw_model/sw_model.tex
View File

@ -30,7 +30,6 @@ embedded industrial control machinery.
\section{Introduction} \section{Introduction}
This chapter This chapter
% %
describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation describes a methodology (Failure Mode Modular De-Composition - FMMD) that using a common notation
models failure mode behaviour in software, electronic and mechanical models failure mode behaviour in software, electronic and mechanical
domains. The methodology therefore can model integrated domains. The methodology therefore can model integrated
@ -67,6 +66,12 @@ These inputs and outputs connect to a process `bubble'
representing the computing, or data transformation. representing the computing, or data transformation.
Data flow diagrams (DFDs) are directed graphs.
The arcs represent data flow, and the bubbles
represent procedures that transform data.
A `bubble' can be further
decomposed, or zoomed into, to a more detailed
DFD which shows the subprocedures and data flows within it.
EXAMPLE CONTEXT DIAGRAM EXAMPLE CONTEXT DIAGRAM
@ -78,13 +83,17 @@ 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 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. process the data and pass it on to other bubles which process the data to be sent out.
%%- Hereby the Data flow diagrams (DFDs) are directed graphs.
%%- The arcs represent data, and the nodes (circles or bubbles)
%%- represent processes that transform the data. A process can be further
%%- decomposed to a more detailed DFD which shows the subprocesses and data flows within it.
This process can continue zooming into each `bubble' until the transformation processes they 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. 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 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 of these diagrams and assign it as the `main' \cite{kandr} or start
funtion. function.
As a design methodology, ignoring real time constraints, this is a very good way As a design methodology, ignoring real time constraints, this is a very good way
of analysiing a problem and getting a good software structure. of analysiing a problem and getting a good software structure.
@ -150,14 +159,18 @@ Here we are interested in the ways the functions can fail.
%%- bias this to software... %%- bias this to software...
The main idea of the methodology is to build a hierarchy of fault modes from the part 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.
The first stage is to choose
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. 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. %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.
In terms of software, we can considered the functions called by a function to be the components. 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). The functions called will have known failure modes (i.e. they can fail their post conditions).
@ -212,3 +225,8 @@ Example of failure modes of a hardware element being
integrated into s/w integrated into s/w
Use prev example of milli-volt amp with check resistor. Use prev example of milli-volt amp with check resistor.
\section{Software Example Analysed using FMMD}