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

going for a ride on the downs....

Browse Source
This commit is contained in:
Robin Clark 2013-08-17 09:53:33 +01:00
parent 1f193a9242
commit f4ea17b780
2 changed files with 46 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
submission_thesis/CH3_FMEA_criticism/copy.tex
View File

@ -200,24 +200,25 @@ to be performed on the same system to provide insight into the
software hardware/interface~\cite{embedsfmea}. software hardware/interface~\cite{embedsfmea}.
% %
Subtle problems in embedded software are often due to interrupt contention causing unintended 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}. are becoming available~\cite{concurrency_c_tool}.
% %
Although these 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 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. 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 for most new designs of electronic product, the poor software integration capabilities of FMEA
are now being seen as deficiencies. are now being seen as deficiencies.
This is becoming apparent in a dilemma now faced This is becoming apparent in a dilemma now faced
by organisations dealing with highly safety critical systems, and having to rely on `smart~instruments' by organisations dealing with highly safety critical systems and having to rely on `smart~instruments'~\cite{justifysmartnuke}
that they can no longer validate using FMEA. that can no longer be validated using FMEA.
% %
Smart instruments are dealt with in the section below. Smart instruments are dealt with in the section below.
Distributed real time systems, which rely on micro-controllers connected in a network 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} \subsection{The rise of the smart instrument}
\label{sec:smart} \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 For quality control, many safety critical processes require regular inspections
and measurements of physical characteristics of materials and machinery. 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 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. 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 with FMEDA for hardware: for software it recommends language constraints and quality procedures
but no inductive fault finding technique. 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). (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. However, it is still based on the concept of single component failures mapped to top~level/system~failures.

74
submission_thesis/appendixes/algorithmic.tex
View File

@ -350,9 +350,16 @@ $$ dtc(F) = TC. $$
In algorithm \ref{alg22}, the function \textbf{chosen} means that In algorithm \ref{alg22}, the function \textbf{chosen} means that
the failure modes for a particular test case have been chosen by 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 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). special 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}. 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} \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$ be the set of test cases }
\State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$} \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 { $ TC := \emptyset $ } \Comment{Initialise set of test cases}
\State { $ j := 1 $ } \Comment{Initialise index 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 \EndFor
\EndIf \EndIf
% %
% \ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of F} %%\mathcal{P} F $ } \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} % \State { $ ptc \in \mathcal{P} F $ } \Comment{Make $ptc$ 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} \If { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ }
% \State{ $ j := j + 1 $} % latex bug hunt game #1 \State{ $ j := j + 1 $} % latex bug hunt game #1
% \State { $ tc_j := ptc $} \State { $ tc_j := ptc $}
% \State { $ TC := TC \cup tc_j $ } \State { $ TC := TC \cup tc_j $ }
% \ENDIF \EndIf
% \EndFor \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
%
%\algstore %\algstore
%\algrestore %\algrestore
% %
% \algstore{myalg} \algstore{myalg}
% \end{algorithmic} \end{algorithmic}
% \end{algorithm} \end{algorithm}
% \clearpage
% \begin{algorithm}
% \begin{algorithmic} [1] %
% \algrestore{myalg} %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 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} \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 \Comment { Check that at each single failure mode is
included as a test case.} included as a test case.}
%\EndIf %\EndIf
%\If{Double fault checking} %\If{Double fault checking}
\State { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group } \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 { 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)$ } \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 \Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes (see section~\ref{sec:unitarystate}) are included
as a test cases.} as a test cases.}
%\EndIf
\State \textbf{return} $TC$ \State \textbf{return} $TC$
% some european standards
% imply checking all double fault combinations\cite{en298} }
%\hline
\end{algorithmic} \end{algorithmic}
\end{algorithm} \end{algorithm}
%} % end footnotesize %} % end footnotesize
%
Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$. 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}. 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 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} \subsection{ Analyse Test Cases}
%% %%
%% Algorithm 3 %% Algorithm 3