going for a ride on the downs....
This commit is contained in:
Robin Clark
parent
1f193a9242
commit
f4ea17b780
@ -200,24 +200,25 @@ to be performed on the same system to provide insight into the
|
||||
software hardware/interface~\cite{embedsfmea}.
|
||||
%
|
||||
Subtle problems in embedded software are often due to interrupt contention causing unintended
|
||||
corruption of variables: automated tools to aid in the detection of these
|
||||
corruption of variables: automated tools to aid the detection of this
|
||||
are becoming available~\cite{concurrency_c_tool}.
|
||||
%
|
||||
Although these
|
||||
should give a better picture of the failure mode behaviour, they are by no means a rigorous approach to tracing errors that may occur in hardware
|
||||
Although current software FMEA techniques
|
||||
should give a better picture of the failure mode behaviour,
|
||||
they are by no means a rigorous approach to tracing errors that may occur in hardware being followed
|
||||
through to the top (and therefore ultimately controlling) layer of software.
|
||||
%
|
||||
With the increasing use of micro-controllers in place of analogue electronics
|
||||
With the increasing use of micro-controllers in place of much analogue electronics
|
||||
for most new designs of electronic product, the poor software integration capabilities of FMEA
|
||||
are now being seen as deficiencies.
|
||||
|
||||
This is becoming apparent in a dilemma now faced
|
||||
by organisations dealing with highly safety critical systems, and having to rely on `smart~instruments'
|
||||
that they can no longer validate using FMEA.
|
||||
by organisations dealing with highly safety critical systems and having to rely on `smart~instruments'~\cite{justifysmartnuke}
|
||||
that can no longer be validated using FMEA.
|
||||
%
|
||||
Smart instruments are dealt with in the section below.
|
||||
Distributed real time systems, which rely on micro-controllers connected in a network
|
||||
using a communications protocol, are also impossible to be meaningfully analysed by FMEA.
|
||||
using a communications protocol, similarly are difficult to meaningfully analyse using FMEA (see section~\ref{sec:distributed}).
|
||||
|
||||
\subsection{The rise of the smart instrument}
|
||||
\label{sec:smart}
|
||||
@ -237,7 +238,7 @@ with firmware to read the user controls, and display results on an LCD.
|
||||
For quality control, many safety critical processes require regular inspections
|
||||
and measurements of physical characteristics of materials and machinery.
|
||||
%
|
||||
For highly critical systems e.g. the nuclear industry~\cite{justifysmartnuke,parnas1991assessment},
|
||||
For highly critical systems e.g. the nuclear industry~\cite{parnas1991assessment},
|
||||
the instruments used to perform these measurements, must be analysed using traditional assessment (which entails
|
||||
FMEA), to ensure that failure modes within the instrument cannot lead to invalid measurements.
|
||||
%
|
||||
@ -441,7 +442,8 @@ on a modern variant of FMEA, recommends hardware redundancy architectures in con
|
||||
with FMEDA for hardware: for software it recommends language constraints and quality procedures
|
||||
but no inductive fault finding technique.
|
||||
%
|
||||
FMEA has adapted from a cost saving exercise for mass produced items~\cite{bfmea,generic_automotive_fmea_6034891}, to incorporating statistical techniques
|
||||
FMEA has adapted from a cost saving exercise for mass produced
|
||||
items~\cite{bfmea,generic_automotive_fmea_6034891}, to incorporating statistical techniques
|
||||
(FMECA) to allowing for self diagnostic mitigation (FMEDA).
|
||||
%
|
||||
However, it is still based on the concept of single component failures mapped to top~level/system~failures.
|
||||
|
||||
@ -350,9 +350,16 @@ $$ dtc(F) = TC. $$
|
||||
In algorithm \ref{alg22}, the function \textbf{chosen} means that
|
||||
the failure modes for a particular test case have been chosen by
|
||||
a human operator and are additional to those chosen by the automated process (i.e they are
|
||||
special case test cases involving multiple failure modes).
|
||||
The function \textbf{unitary state} means that all test
|
||||
cases can have no pairs of failure modes sourced from the same component, see section~\ref{sec:unitarystate}.
|
||||
special test~cases involving multiple failure modes).
|
||||
%
|
||||
The function \textbf{isunitarystate}
|
||||
takes as its argument a test~case
|
||||
and returns true if no pairs of that test~case's
|
||||
failure modes are sourced from the same component (see section~\ref{sec:unitarystate}).
|
||||
%
|
||||
In other words, this function tests
|
||||
that {\fms} in test~cases
|
||||
only use {\fms} that are mutually exclusive within components.
|
||||
%
|
||||
\label{sec:completetest}
|
||||
%
|
||||
@ -375,7 +382,7 @@ all failure modes in components in the {\fg} are included in at least one test~c
|
||||
|
||||
\State { Let $TC$ be the set of test cases }
|
||||
\State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$}
|
||||
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \in \mathbb{N}_{+}$}
|
||||
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \in \mathbb{N}_{+}$ }
|
||||
|
||||
\State { $ TC := \emptyset $ } \Comment{Initialise set of test cases}
|
||||
\State { $ j := 1 $ } \Comment{Initialise index of test cases}
|
||||
@ -402,34 +409,29 @@ all failure modes in components in the {\fg} are included in at least one test~c
|
||||
\EndFor
|
||||
\EndIf
|
||||
%
|
||||
% \ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of F} %%\mathcal{P} F $ }
|
||||
% \State { $ ptc \in \mathcal{P} F $ } \Comment{Make a provisional test case}
|
||||
% \If { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ } %%% \Comment{IF this combination of faults is chosen as an additional Test case include it in TC}
|
||||
% \State{ $ j := j + 1 $} % latex bug hunt game #1
|
||||
% \State { $ tc_j := ptc $}
|
||||
% \State { $ TC := TC \cup tc_j $ }
|
||||
% \ENDIF
|
||||
% \EndFor
|
||||
|
||||
%\ForAll { $tc_j \in TC$ }
|
||||
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
|
||||
%
|
||||
% Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
|
||||
%\Comment { require that the test case is a member of the powerset of $F$ }
|
||||
%\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
|
||||
%\Comment { Test cases must be unique }
|
||||
%\EndFor
|
||||
%
|
||||
\ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of F} %%\mathcal{P} F $ }
|
||||
% \State { $ ptc \in \mathcal{P} F $ } \Comment{Make $ptc$ a provisional test case}
|
||||
\If { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ }
|
||||
\State{ $ j := j + 1 $} % latex bug hunt game #1
|
||||
\State { $ tc_j := ptc $}
|
||||
\State { $ TC := TC \cup tc_j $ }
|
||||
\EndIf
|
||||
\EndFor
|
||||
%
|
||||
%\algstore
|
||||
%\algrestore
|
||||
%
|
||||
% \algstore{myalg}
|
||||
% \end{algorithmic}
|
||||
% \end{algorithm}
|
||||
%
|
||||
% \begin{algorithm}
|
||||
% \begin{algorithmic} [1]
|
||||
% \algrestore{myalg}
|
||||
\algstore{myalg}
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
\clearpage
|
||||
|
||||
%
|
||||
%Algorithm~\ref{alg22} continued below.
|
||||
%
|
||||
\begin{algorithm}
|
||||
\begin{algorithmic} [1]
|
||||
\algrestore{myalg}
|
||||
\Ensure { $ \forall j_1,j_2 \in J \; such\; that\; j_1 \neq j_2 \big( tc_{j_1} \neq tc_{j_2} \big) $} \Comment{Ensure test cases are distinct}
|
||||
\Ensure { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } \Comment{Ensure each test case is a subset of F}
|
||||
|
||||
@ -440,33 +442,27 @@ all failure modes in components in the {\fg} are included in at least one test~c
|
||||
\Comment { Check that at each single failure mode is
|
||||
included as a test case.}
|
||||
%\EndIf
|
||||
|
||||
%\If{Double fault checking}
|
||||
\State { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
|
||||
%\ENSURE { That all failure modes are represented in at least one test case }
|
||||
\Ensure { $ \forall f1,f2 \;where\; (f1 \wedge f2) \not\in (\forall c) \;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) \wedge ({DoubleFaultChecking} = TRUE)$ }
|
||||
\Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes (see section~\ref{sec:unitarystate}) are included
|
||||
as a test cases.}
|
||||
%\EndIf
|
||||
\State \textbf{return} $TC$
|
||||
% some european standards
|
||||
% imply checking all double fault combinations\cite{en298} }
|
||||
|
||||
%\hline
|
||||
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
%} % end footnotesize
|
||||
|
||||
%
|
||||
Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$.
|
||||
The next stage is to analyse the effect of each test case on the {\fg}.
|
||||
%
|
||||
Double failure mode checking has been included in this algorithm specifically because of the
|
||||
implied double failure mode implications of European standard EN298~\cite{en298}.
|
||||
double failure mode implications of European standard EN298~\cite{en298}.
|
||||
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\clearpage
|
||||
%\clearpage
|
||||
\subsection{ Analyse Test Cases}
|
||||
%%
|
||||
%% Algorithm 3
|
||||
|
||||
Loading…
Reference in New Issue
Block a user