From f4ea17b78077f5d3697b25e785082e3c28ea7680 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 17 Aug 2013 09:53:33 +0100 Subject: [PATCH] going for a ride on the downs.... --- submission_thesis/CH3_FMEA_criticism/copy.tex | 20 ++--- submission_thesis/appendixes/algorithmic.tex | 74 +++++++++---------- 2 files changed, 46 insertions(+), 48 deletions(-) diff --git a/submission_thesis/CH3_FMEA_criticism/copy.tex b/submission_thesis/CH3_FMEA_criticism/copy.tex index 99b2f42..6d1bd29 100644 --- a/submission_thesis/CH3_FMEA_criticism/copy.tex +++ b/submission_thesis/CH3_FMEA_criticism/copy.tex @@ -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. diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex index d216533..efec50d 100644 --- a/submission_thesis/appendixes/algorithmic.tex +++ b/submission_thesis/appendixes/algorithmic.tex @@ -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