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

Abstract for FMMD software paper

Browse Source 
send to supervisors just now.
This commit is contained in:
Robin P. Clark 2012-04-30 19:34:00 +01:00
parent 1ad8b99cf9
commit 244b6685b0
5 changed files with 280 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
papers/fmmd_software_hardware/Makefile
View File

@ -12,3 +12,12 @@ all: ${PNG} bib
bib:
bibtex software_fmmd
abs: # bib
cat abs_pre.tex > abstract.tex
cat abs.tex >> abstract.tex
cat abs_end.tex >> abstract.tex
pdflatex abstract
acroread abstract.pdf

139
papers/fmmd_software_hardware/abs.tex Normal file
View File

@ -0,0 +1,139 @@
%% INTRO
% the problem
% the solution
% why you would want to read the paper
%
The certification process of safety critical products for European and
other international standards often demand environmental stress,
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or `static~testing',
is often also required.
%
Failure Mode effects Analysis (FMEA) is a tool used
for static testing. Its use is traditionally applied to hardware (electrical and mechanical) systems.
%
With the increasing use of micro-controllers in smart~instruments and control~systems,
software is increasingly being seen as the `missing~factor' in FMEA analysis.
%
This paper presents a new modular variant of FMEA, Failure Mode Modular De-Composition (FMMD).
%
Because FMMD is modular and hierarchical, and deals with all its objects in terms of their failure mode behaviour,
it is ideally suited to creating integrated software and hardware models.
%
This paper takes a simple example of a hardware/software hybrid (an industry standard {\ft} input), analyses
the hardware and software using FMMD, and then discusses the effectiveness of the
failure modelling from the perspective of the hybrid hardware/software sub-system.
%% MIDDLE
% some background
% how important software is today, how there is no FMEA to encompass both software and hardware
% NEED for seamless integrated software hardware failure mode modelling
%
FMEA is a bottom-up technique that aims to assess the effects of all
component failure modes on a system.
It is used both as a design tool (to determine weaknesses), and is a requirement of certification of safety critical products.
FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
%
Work on software FMEA (SFMEA) is beginning, but at present no technique for SFMEA that
integrates hardware and software models exists.
%
Software in current embedded systems practise sits on top of most modern safety critical control systems [and inside many
data collection/actuator modules (smart~instruments)], and defines their most important system wide behaviour, interfaces and communications.
%
Currently standards that demand FMEA for hardware (e.g. EN298, EN61508),
do not specify it for software, but instead specify, computer architecture, good software practise,
review processes and language feature constraints.
%
Where FMEA traces component {\fms} to resultant system failures, software has been left in a non-analytical
limbo of best practises and constraints.
%
Where SFMEA has been applied---for some automotive and highly safety critical systems---it has always been
performed separately from hardware FMEA (HFMEA).
%
At present the hardware/software interface is a source for confusion and misunderstanding, and in many organisations,
the actual design teams for software and hardware work in separate departments.
%
Subtle errors of electronic sub-systems for instance, may not be picked up by
software specialists, and vice versa.
%
It would be desirable to have a methodology that provides seamless software and hardware integration in its failure modelling. % methodology.
%
FMMD has been designed to integrate mechanical/electronic and software failure models, by treating all modular components
in terms of their failure modes.
%
For instance, a software function, or an electronic or a mechanical component can be assigned a known set of failure modes.
%
Because of this, they (software or hardware elements) may be treated as compatible modules under FMMD.
%
Also, FMMD has a modular incremental analysis strategy which offers efficiency gains (reduction of state explosion in terms
of number of checks to make, and the re-use of pre-analysed modules)
over traditional FMEA.
%% CONCLUSIONS.
%
%
This paper presents an overview of the FMMD methodology and then an FMMD analysis of a simple software/hardware hybrid sub-system.
%
The example sub-system chosen is a {\ft} input circuit consisting of
a resistive element, multiplexer (MUX), Analogue to Digital Converter (ADC) and two software functions.
%
The purpose of this sub-system is to convert an electrical current signal into a value for use in software.
%
FMMD is applied to the hardware (resistive element, MUX and ADC) and
to the software components (two `C' functions), producing one integrated
failure mode model.
%
The {\ft} input circuitry used in the example and its related software, are accepted practise and in common use, and therefore its failure mode
behaviour is well known and understood.
%
For this reason it is a good example to use for comparing the results from FMMD analysis
with known failure mode behaviour from the field/direct experience of engineers.
The failure model is then discussed and compared with heuristic
knowledge of {\ft} inputs, circuitry and software.
%
Conclusions are then presented listing the benefits and draw-backs
of analysing the hardware/software hybrid system using FMMD.
\clearpage
Authors:
\begin{table}[h]
%\center
\begin{tabular}{||p{3cm}|p{6cm}|p{5cm}||}
\hline \hline
{\em Author } & {\em Email} & {\em Institution} \\ \hline
& & \\ \hline
R.P. Clark & r.clark@energytechnologycontrol.com & Energy Technology Control Ltd. \\ \hline
%R.P.Clark@brighton.ac.uk & Energy Technology Control Ltd \\ \hline
A. Fish & Andrew.Fish@brighton.ac.uk & Brighton University, UK \\ \hline
C. Garrett & C.Garrett@brighton.ac.uk & Brighton University, UK \\ \hline
J. Howse & John.Howse@brighton.ac.uk & Brighton University, UK \\ \hline
& & \\ \hline
\hline
\end{tabular}
%\caption{Authors}
\label{tbl:authors}
\end{table}
Presenting Author is R.P. Clark.
\begin{table}[h]
%\center
\begin{tabular}{||p{1cm}|p{12cm}|p{1cm}||}
\hline \hline
& Short Biography & \\ \hline \hline
& R.P. Clark is an embedded software Engineer, working with
safety critical industrial burner controllers, and the design of safety critical sensors. He is currently
working for a part-time PhD at Brighton University.
& \\ \hline
& & \\ \hline
\end{tabular}
%\caption{Authors}
\label{tbl:bio}
\end{table}

6
papers/fmmd_software_hardware/abs_end.tex Normal file
View File

@ -0,0 +1,6 @@
%%%
%%%
%%%
%%%
\end{document}

63
papers/fmmd_software_hardware/abs_pre.tex Normal file
View File

@ -0,0 +1,63 @@
\documentclass{article}
%\documentclass[twocolumn,10pt]{report}
\usepackage{graphicx}
\usepackage{fancyhdr}
%\usepackage{wassysym}
\usepackage{tikz}
\usepackage{amsfonts,amsmath,amsthm}
\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows}
%\input{../style}
\usepackage{ifthen}
\usepackage{lastpage}
\usetikzlibrary{shapes,snakes}
\newcommand{\tickYES}{\checkmark}
\newcommand{\fc}{fault~scenario}
\newcommand{\fcs}{fault~scenarios}
\date{}
%\renewcommand{\encodingdefault}{T1}
%\renewcommand{\rmdefault}{tnr}
%\newboolean{paper}
%\setboolean{paper}{true} % boolvar=true or false
\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
\newcommand{\permil}{\ensuremath{{ }^0/_{00}}}
\newcommand{\oc}{\ensuremath{^{o}{C}}}
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
\newcommand{\fm}{failure~mode}
\newcommand{\fms}{failure~modes}
\newcommand{\fg}{functional~group}
\newcommand{\FG}{\mathcal{G}}
\newcommand{\DC}{\mathcal{DC}}
\newcommand{\fgs}{functional~groups}
\newcommand{\dc}{derived~component}
\newcommand{\dcs}{derived~components}
\newcommand{\bc}{base~component}
\newcommand{\FMMD}{ModularFMEA}
\newcommand{\bcs}{base~components}
\newcommand{\irl}{in real life}
\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}}
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
%\newcommand{\pic}{\em pure~intersection~chain}
\newcommand{\pic}{\em pair-wise~intersection~chain}
\newcommand{\wrt}{\em with~respect~to}
\newcommand{\abslevel}{\ensuremath{\Psi}}
\setlength{\topmargin}{0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{0in}
\setlength{\textheight}{22cm}
\setlength{\textwidth}{16cm}
\setlength{\oddsidemargin}{.2in}
\setlength{\evensidemargin}{.2in}
\setlength{\parindent}{0.0in}
\setlength{\parskip}{6pt}
\begin{document}
\section*{Failure Mode Modular De-composition applied to a hybrid software/hardware system}

94
papers/fmmd_software_hardware/software_fmmd.tex
View File

@ -132,42 +132,43 @@ failure mode of the component or sub-system}}}
%\small
\abstract{ \em
\input{abs}
%The certification process of safety critical products for European and
%other international standards often demand environmental stress,
%endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
%is often also required.
%
Failure Mode Effects Analysis (FMEA), is a bottom-up technique that aims to assess the effect all
component failure modes on a system.
It is used both as a design tool (to determine weaknesses), and is a requirement of certification of safety critical products.
FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
Work on software FMEA (SFMEA) is beginning, but
at present no technique for SFMEA that
integrates hardware and software models % known to the authors
exists.
%
Software generally sits on top of most modern safety critical control systems
and defines its most important system wide behaviour and communications.
Currently standards that demand FMEA for hardware (e.g. EN298, EN61508),
do not specify it for software, but instead specify, good practise,
review processes and language feature constraints.
%This is a weakness; w
Where FMEA % scientifically
traces component {\fms}
to resultant system failures, software has been left in a non-analytical
limbo of best practises and constraints.
%
If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could
be modelled; and could thus be `complete' failure mode models.
%Failure modes in components in say a sensor, could be traced
%up through the electronics and then through the controlling software.
Presently FMEA, stops at the glass ceiling of the computer program.
This paper presents a modular variant of FMEA, Failure Mode Modular De-Composition (FMMD), a methodology which
can be applied to software, and is compatible
and integrate-able with FMMD performed on mechanical and electronic systems.
% Failure Mode Effects Analysis (FMEA), is a bottom-up technique that aims to assess the effect all
% component failure modes on a system.
% It is used both as a design tool (to determine weaknesses), and is a requirement of certification of safety critical products.
% FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
%
% Work on software FMEA (SFMEA) is beginning, but
% at present no technique for SFMEA that
% integrates hardware and software models % known to the authors
% exists.
% %
% Software generally sits on top of most modern safety critical control systems
% and defines its most important system wide behaviour and communications.
% Currently standards that demand FMEA for hardware (e.g. EN298, EN61508),
% do not specify it for software, but instead specify, good practise,
% review processes and language feature constraints.
%
% %This is a weakness; w
% Where FMEA % scientifically
% traces component {\fms}
% to resultant system failures, software has been left in a non-analytical
% limbo of best practises and constraints.
% %
% If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could
% be modelled; and could thus be `complete' failure mode models.
% %Failure modes in components in say a sensor, could be traced
% %up through the electronics and then through the controlling software.
% Presently FMEA, stops at the glass ceiling of the computer program.
%
% This paper presents a modular variant of FMEA, Failure Mode Modular De-Composition (FMMD), a methodology which
% can be applied to software, and is compatible
% and integrate-able with FMMD performed on mechanical and electronic systems.
}
\today
@ -962,6 +963,37 @@ This nested structure means that we have multiple traceable
stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage
of reasoning for each component failure mode.
\section{Heuristic Comments on {\ft} Input Circuit}
Part of the design philosophy of a {\ft} loop, is that
if anything goes wrong, we should be able to detect it.
In fact unless all electrical elements in the loop
are in working order we will detect a failure in
the majority of cases.
\subsection{Sending side of a {\ft} loop}
A current loop has to be actively maintained. If the sending side looses power,
the current will drop to zero, and thus be detectable as an error because it is below 4mA.
Should the sending circuitry fail, it is far more likely to drive too high or too low, rather than supply
an erroneous but in bounds ($4mA \ge \wedge \le 20mA$) value.
\subsection{Receiving side of a {\ft} loop}
The most common fault is disconnection, and this is easily detected ($0mA\; \le \; 4mA$--out of bounds).
Other failure modes, such as the resistor going open or shorted
also immediately push the voltage signal out of bounds.
The software side of the interface, is easy to test, either as software modules
or as an integrated system (hand-held precision current sources are cheaply available).
\subsection{What could go wrong---Production}
PCB construction contractors are well known for random polarity placement of diodes.
Less likely is that the resistor fitted will be an incorrect value, which could
lead to the range being incorrect. Were this the case, we would have to be very unlucky
and get a value very close to our chosen \ohms{220} for this to be a problem, and
in safety critical equipment, a production test rig would pick this up.
Worse perhaps, a resistor with poor temperature coefficient could be
erroneously chosen (this would be a cheaper component), and could contribute small errors.
%\clearpage
\section{Conclusion}