From 242dcb79bad1e7350a1e6d74bcf00e6fbd11ced2 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 18 Oct 2010 15:05:01 +0100 Subject: [PATCH] . --- sw_model/sw_model.tex | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/sw_model/sw_model.tex b/sw_model/sw_model.tex index 4248dff..fda66ff 100644 --- a/sw_model/sw_model.tex +++ b/sw_model/sw_model.tex @@ -30,7 +30,6 @@ 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 @@ -67,6 +66,12 @@ These inputs and outputs connect to a process `bubble' 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 @@ -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 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 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. +of these diagrams and assign it as the `main' \cite{kandr} or start +function. As a design methodology, ignoring real time constraints, this is a very good way 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... -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. -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. %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. +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). @@ -212,3 +225,8 @@ Example of failure modes of a hardware element being integrated into s/w Use prev example of milli-volt amp with check resistor. + + + +\section{Software Example Analysed using FMMD} +