AF comments first two pages
This commit is contained in:
parent
37aa92fb41
commit
46c0c9980a
@ -135,7 +135,7 @@ failure mode of the component or sub-system}}}
|
||||
%\lhead{Developing a rigorous bottom-up modular static failure modelling methodology}
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.Clark$^\star$,A.~Fish$^\dagger$ , C.~Garrett$^\dagger$, J.~Howse$^\dagger$ \\
|
||||
\author{R.Clark$^\star$, A.~Fish$^\dagger$ , C.~Garrett$^\dagger$, J.~Howse$^\dagger$ \\
|
||||
$^\star${\em Energy Technology Control, UK. r.clark@energytechnologycontrol.com} \and $^\dagger${\em University of Brighton, UK}
|
||||
}
|
||||
|
||||
@ -145,7 +145,7 @@ failure mode of the component or sub-system}}}
|
||||
\maketitle
|
||||
|
||||
|
||||
\paragraph{Keywords:} static failure mode modelling safety-critical software fmea
|
||||
\paragraph{Keywords:} static failure mode modelling; safety-critical; software fmea
|
||||
%\small
|
||||
|
||||
\abstract{ % \em
|
||||
@ -181,7 +181,7 @@ 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,
|
||||
do not specify it for software, but instead specify good practise,
|
||||
review processes and language feature constraints.
|
||||
%
|
||||
This is a weakness.
|
||||
@ -192,7 +192,7 @@ 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.
|
||||
be modelled, and so we could consider `complete' failure mode models.
|
||||
%
|
||||
Presently FMEA, stops at the glass ceiling of the computer program: FMMD seeks to address
|
||||
this, and offers additional test efficiency benefits.
|
||||
@ -216,7 +216,7 @@ software functions.
|
||||
%
|
||||
With these definitions we can apply the FMMD modular form of FMEA
|
||||
to existing software\footnote{Existing software excluding recursive~\cite{misra}[16.2] code,
|
||||
and unstructured non-functional languages}.
|
||||
and unstructured non-functional language.}.
|
||||
}
|
||||
|
||||
\section{FMEA Background}
|
||||
@ -224,7 +224,8 @@ and unstructured non-functional languages}.
|
||||
%What FMEA is, briefly variants...
|
||||
|
||||
Failure Mode Effects Analysis is the process of taking
|
||||
component failure modes, and by reasoning, tracing their effects through a system
|
||||
component failure modes, %and by reasoning,
|
||||
tracing their effects through a system
|
||||
and determining what system level failure modes could be caused.
|
||||
%
|
||||
FMEA dates from the 1940s where simple electro-mechanical systems were the norm.
|
||||
@ -251,7 +252,7 @@ is a cause for criticism~\cite{safeware}[Ch.12].
|
||||
%FMMD is a modularisation of FMEA and can produce failure~mode models that can be used in
|
||||
%all the above variants of FMEA.
|
||||
|
||||
\subsection{Current work on Software FMEA}
|
||||
\paragraph{Current work on Software FMEA}
|
||||
|
||||
SFMEA usually does not seek to integrate
|
||||
hardware and software models, but to perform
|
||||
@ -261,7 +262,7 @@ Work has been performed using databases
|
||||
to track the relationships between variables
|
||||
and system failure modes~\cite{procsfmeadb}, to %work has been performed to
|
||||
introduce automation into the FMEA process~\cite{appswfmea} and to provide code analysis
|
||||
automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately
|
||||
automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately,
|
||||
some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive)
|
||||
and FMEA (bottom-up inductive)
|
||||
to be performed on the same system to provide insight into the
|
||||
@ -299,9 +300,11 @@ of failure mode behaviour for the entire system.
|
||||
%
|
||||
With higher level modules, we can reach the level in which the software resides.
|
||||
%
|
||||
For instance, to read a voltage into software via an ADC we rely on an electronic sub-system
|
||||
For instance, to read a voltage into software via an Analogue to Digital Converter (ADC) we rely on an electronic sub-system
|
||||
that conditions the input signal and then routes it through a multiplexer to the ADC.
|
||||
%
|
||||
% up to here committed AF comments 12JUL2012
|
||||
%
|
||||
We could easily consider this electronics a `module', and with a
|
||||
failure mode model for it, modelling the software to hardware interface
|
||||
becomes far simpler.
|
||||
@ -599,7 +602,7 @@ We can now examine a software function that performs a conversion from the volta
|
||||
a per~mil representation of the {\ft} input current.
|
||||
%
|
||||
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is
|
||||
used\footnote{ C coding examples use the Misra~\cite{misra} and SIL 3 recommended language constraints~\cite{en61508}.}.
|
||||
used\footnote{ C coding examples use the Misra~\cite{misra} and SIL-3 recommended language constraints~\cite{en61508}.}.
|
||||
We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision
|
||||
value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}).
|
||||
|
||||
@ -788,22 +791,22 @@ With these failure modes, we can analyse our first functional group, see table~\
|
||||
\textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline
|
||||
\hline
|
||||
1: $R_{OPEN}$ & resistor open, & $HIGH$ \\
|
||||
& voltage on pin high & \\ \hline
|
||||
& voltage on pin high & \\ \hline
|
||||
|
||||
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
|
||||
& voltage on pin low & \\ \hline
|
||||
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
|
||||
& voltage on pin low & \\ \hline
|
||||
|
||||
|
||||
3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\
|
||||
& fixed value & \\ \hline
|
||||
& fixed value & \\ \hline
|
||||
|
||||
|
||||
|
||||
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
|
||||
& wrong channel & \\ \hline
|
||||
& wrong channel & \\ \hline
|
||||
|
||||
5: $ADC_{LOW}$ & output low & $LOW$ \\
|
||||
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
|
||||
5: $ADC_{LOW}$ & output low & $LOW$ \\
|
||||
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
|
||||
|
||||
|
||||
\hline
|
||||
@ -853,7 +856,7 @@ by stating:
|
||||
$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $
|
||||
|
||||
As we have a failure mode model for our function, we can now use it in conjunction with
|
||||
with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$.
|
||||
the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$.
|
||||
%
|
||||
We now analyse this hardware/software combined {\fg}.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user