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}
|
%\lhead{Developing a rigorous bottom-up modular static failure modelling methodology}
|
||||||
% numbers at outer edges
|
% numbers at outer edges
|
||||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
\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}
|
$^\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
|
\maketitle
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Keywords:} static failure mode modelling safety-critical software fmea
|
\paragraph{Keywords:} static failure mode modelling; safety-critical; software fmea
|
||||||
%\small
|
%\small
|
||||||
|
|
||||||
\abstract{ % \em
|
\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.
|
and defines its most important system wide behaviour and communications.
|
||||||
%
|
%
|
||||||
Currently standards that demand FMEA for hardware (e.g. EN298, EN61508),
|
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.
|
review processes and language feature constraints.
|
||||||
%
|
%
|
||||||
This is a weakness.
|
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.
|
limbo of best practises and constraints.
|
||||||
% %
|
% %
|
||||||
If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could
|
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
|
Presently FMEA, stops at the glass ceiling of the computer program: FMMD seeks to address
|
||||||
this, and offers additional test efficiency benefits.
|
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
|
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,
|
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}
|
\section{FMEA Background}
|
||||||
@ -224,7 +224,8 @@ and unstructured non-functional languages}.
|
|||||||
%What FMEA is, briefly variants...
|
%What FMEA is, briefly variants...
|
||||||
|
|
||||||
Failure Mode Effects Analysis is the process of taking
|
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.
|
and determining what system level failure modes could be caused.
|
||||||
%
|
%
|
||||||
FMEA dates from the 1940s where simple electro-mechanical systems were the norm.
|
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
|
%FMMD is a modularisation of FMEA and can produce failure~mode models that can be used in
|
||||||
%all the above variants of FMEA.
|
%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
|
SFMEA usually does not seek to integrate
|
||||||
hardware and software models, but to perform
|
hardware and software models, but to perform
|
||||||
@ -261,7 +262,7 @@ Work has been performed using databases
|
|||||||
to track the relationships between variables
|
to track the relationships between variables
|
||||||
and system failure modes~\cite{procsfmeadb}, to %work has been performed to
|
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
|
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)
|
some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive)
|
||||||
and FMEA (bottom-up inductive)
|
and FMEA (bottom-up inductive)
|
||||||
to be performed on the same system to provide insight into the
|
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.
|
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.
|
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
|
We could easily consider this electronics a `module', and with a
|
||||||
failure mode model for it, modelling the software to hardware interface
|
failure mode model for it, modelling the software to hardware interface
|
||||||
becomes far simpler.
|
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.
|
a per~mil representation of the {\ft} input current.
|
||||||
%
|
%
|
||||||
For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is
|
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
|
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}).
|
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
|
\textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline
|
||||||
\hline
|
\hline
|
||||||
1: $R_{OPEN}$ & resistor open, & $HIGH$ \\
|
1: $R_{OPEN}$ & resistor open, & $HIGH$ \\
|
||||||
& voltage on pin high & \\ \hline
|
& voltage on pin high & \\ \hline
|
||||||
|
|
||||||
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
|
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
|
||||||
& voltage on pin low & \\ \hline
|
& voltage on pin low & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\
|
3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\
|
||||||
& fixed value & \\ \hline
|
& fixed value & \\ \hline
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
|
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
|
||||||
& wrong channel & \\ \hline
|
& wrong channel & \\ \hline
|
||||||
|
|
||||||
5: $ADC_{LOW}$ & output low & $LOW$ \\
|
5: $ADC_{LOW}$ & output low & $LOW$ \\
|
||||||
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
|
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
|
||||||
|
|
||||||
|
|
||||||
\hline
|
\hline
|
||||||
@ -853,7 +856,7 @@ by stating:
|
|||||||
$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $
|
$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $
|
||||||
|
|
||||||
As we have a failure mode model for our function, we can now use it in conjunction with
|
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}.
|
We now analyse this hardware/software combined {\fg}.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user