diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index d8f2f9f..ee478d8 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -1953,54 +1953,8 @@ This can be our first {\fg} and we analyse it in table~\ref{tbl:sumjint}. % $$FG = \{R1, R2, IC1, C1 \}$$ -\begin{table}[h+] -\center -\caption{Summing Junction Integrator($SUMJINT$): Failure Mode Effects Analysis} % title of Table -\label{tbl:sumjint} - -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\ - % & & & & \\ - \textbf{Failure} & & \textbf{$SUMJINT$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - - - \hline\hline - FS1: $R1$ $OPEN$ & & $V_{in}$ dominates input & & $V_{in} DOM$ \\ - FS2: $R1$ $SHORT$ & & $V_{fb}$ dominates input & & $V_{fb} DOM$ \\ \hline - FS3: $R2$ $OPEN$ & & $V_{fb}$ dominates input & & $V_{fb} DOM$ \\ - FS4: $R2$ $SHORT$ & & $V_{in}$ dominates input & & $V_{in} DOM$ \\ \hline - FS5: $IC1$ $HIGH$ & & output perm. high & & HIGH \\ - FS6: $IC1$ $LOW$ & & output perm. low & & LOW \\ \hline - FS7: $IC1$ $NOOP$ & & no current to drive C1 & & NO\_INTEGRATION \\ - FS8: $IC1$ $LOW\_SLEW$ & & signal delay to C1 & & NO\_INTEGRATION \\ \hline - - FS9: $C1$ $OPEN$ & & no capacitance & & NO\_INTEGRATION \\ - FS10: $C1$ $SHORT$ & & no capacitance & & NO\_INTEGRATION \\ \hline - -% \hline -% FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\ -% FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\ \hline -% FS3: $IC2$ $NOOP$ & & no current drive & & LOW \\ -% FS4: $IC2$ $LOW\_SLEW$ & & delayed signal & & LOW\_SLEW \\ \hline -% \hline -\hline -\end{tabular} -\end{table} -% -% -% \end{tabular} -% \end{table} - - -From the analysis in table~\ref{tbl:sumjint} we collect symptoms. -We create the derived component -$SUMJINT$ and assign it the failure modes collected above.% which has the failure modes from collecting its symptoms. -We now state: - -$$ fm(SUMJUINT) = \{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ - -That is the failure modes of our new {\dc} $SUMJINT$ are $$\{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ +That is the failure modes (see FMMD analysis at ~\ref{detal:SUMJINT})of our new {\dc} +$SUMJINT$ are $$\{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ \clearpage @@ -2013,31 +1967,15 @@ This is simply an op-amp with the input connected to the +ve input and the -ve input grounded. It therefore has the failure modes of an Op-amp. -\begin{table}[h+] -\center -% \center -\caption{ High Impedance Signal Buffer : Failure Mode Effects Analysis} % title of Table -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$HISB$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - \hline\hline - FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\ - FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\ - FS3: $IC2$ $NOOP$ & & no current to output & & $NOOP$ \\ - FS4: $IC2$ $LOW\_SLEW$ & & delay signal & & $LOW\_{SLEW}$ \\ \hline -\end{tabular} -\end{table} -% \hline % % \end{tabular} % \end{table} This is an OpAmp in a signal buffer configuration. As it is performing one particular function we my consider it as a derived component, that of a High Impedance Signal Buffer (HISB). +This is analysed using FMMD in section~\ref{detail:HISB}. % -We create the {\dc} $HISB$ and its failure mode may be stated as $$fm(HISB) = \{HIGH, LOW, NOOP, LOW_{SLEW} \}.$$ +We create the {\dc} $HISB$ and its failure modes may be stated as $$fm(HISB) = \{HIGH, LOW, NOOP, LOW_{SLEW} \}.$$ \subsubsection{Digital level to analogue level conversion ($DL2AL$).} The integrator is implemented in digital electronics, but the output from the D type flip flop is a digital signal. @@ -2065,43 +2003,11 @@ We now form a {\fg} from $PD $ and $IC3$. % $$ FG = \{ PD , IC3 \} $$ % -We now analyse the {\fg} $G $ in table~\ref{tbl:DS2AS}. +We now analyse this {\fg} (see section~\ref{detail:DS2AS}). - -\begin{table}[h+] -\center -\caption{$PD , IC3$ Digital level to analogue level converter: Failure Mode Effects Analysis} % title of Table -\label{tbl:DS2AS} - -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ - % & & & & \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$DS2AL$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - - \hline \hline - FS1: $PD $ $HIGH$ & & output perm. low & & LOW \\ - FS2: $PD $ $LOW$ & & output perm. low & & HIGH \\ \hline - -\hline - FS3: $IC3$ $HIGH$ & & output perm. high & & HIGH \\ - FS4: $IC3$ $LOW$ & & output perm. low & & LOW \\ - FS5: $IC3$ $NOOP$ & & no current drive & & LOW \\ - FS6: $IC3$ $LOW\_{SLEW}$ & & delayed signal & & $LOW\_{SLEW}$ \\ \hline -\hline - -\end{tabular} -\end{table} - -We collect the symptoms of failure $\{ LOW, HIGH, LOW\_{SLEW} \}$. -We can now derive a new component to represent the level conversion and call it $DL2AL$. - -$$ DL2AL = D(FG = \{ PD , IC3 \}) $$ - $$ fm (DL2AL) = \{ LOW, HIGH, LOW\_{SLEW} \} $$ -\clearpage +%\clearpage \subsubsection{$DIGBUF$ --- digital clocked memory (flip-flop).} @@ -2118,34 +2024,10 @@ $$FG = \{ IC4, CLOCK \}$$ %% DIGBUF --- Digital Buffer -We now analyse this {\fg} in table~\ref{tbl:digbuf}. +We now analyse this {\fg} (see section~\ref{detail:DIGBUF}). +%in table~\ref{tbl:digbuf}. -\begin{table}[h+] -\center -\caption{$ IC4, CLOCK $ Digital Buffer: Failure Mode Effects Analysis} % title of Table -\label{tbl:digbuf} - -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ - % & & & & \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$DIGBUF$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - %$$ fm ( CD4013B) = \{ HIGH, LOW, NOOP \} $$ - \hline \hline - FS1: $CLOCK$ $STOPPED$ & & buffer stopped & & STOPPED \\ \hline - - FS2: $IC4$ $HIGH$ & & buffer stopped & & STOPPED \\ - FS3: $IC4$ $LOW$ & & buffer stopped & & STOPPED \\ - FS4: $IC4$ $NOOP$ & & no current drive & & LOW \\ \hline - \hline -\hline - -\end{tabular} -\end{table} - -We collect the symptoms of failure $\{ LOW, STOPPED \}$. We can now derive a new component to represent the digital buffer and call it $DIGBUF$. @@ -2203,46 +2085,17 @@ and make a complete failure mode for the {\sd}. \subsubsection{{\fg} $HISB$ and $SUMJINT$} We now form a {\fg} with the two derived components $HISB$ and $SUMJINT$. -This forms a buffered integrating summing junction which we analyse in table~\ref{tbl:BISJ}. +This forms a buffered integrating summing junction. We analyse this using FMMD +(see section~\ref{detail:BISJ}). +%which we analyse in table~\ref{tbl:BISJ}. $$ FG = \{ HISB, SUMJINT \} $$ -\begin{table}[h+] -\caption{ $HISB , SUMJINT$ buffered integrating summing junction($BISJ$): Failure Mode Effects Analysis} % title of Table -\label{tbl:BISJ} - -\begin{tabular}{|| l | l | c | c | l ||} \hline -% \textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ - % & & & & \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$BISJ$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - - - \hline \hline - FS1: $SUMJINT$ $V_{in} DOM$ & & output integral of $V_{in}$ & & $OUTPUT STUCK$ \\ - FS2: $SUMJINT$ $V_{fb} DOM$ & & output integral of $V_{fb}$ & & $OUTPUT STUCK$ \\ - % $$ fm(SUMJUINT^1_0) = \{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ - FS3: $SUMJINT$ $NO\_INTEGRATION$ & & output stuck high or low & & $OUTPUT STUCK$ \\ - FS4: $SUMJINT$ $HIGH$ & & output stuck high & & $OUTPUT STUCK$ \\ - FS5: $SUMJINT$ $LOW$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline -%\hline - FS6: $HISB$ $HIGH$ & & output perm. high & & $OUTPUT STUCK$ \\ - FS7: $HISB$ $LOW$ & & output perm. low & & $OUTPUT STUCK$ \\ - FS8: $HISB$ $ NO\_INTEGRATION$ & & no current drive & & $OUTPUT STUCK$ \\ - FS9: $HISB$ $LOW\_SLEW$ & & delayed signal & & $REDUCED\_INTEGRATION$ \\ \hline -\hline - -\end{tabular} -\end{table} - - - -We now collect the symptoms of failure $\{ OUTPUT STUCK , REDUCED\_INTEGRATION \}$, and create a {\dc} -called $BISJ$. +Our derived component BISJ has the failure mode defined by the $fm$ function thus: +$$ fm(BISJ) = \{ OUTPUT STUCK , REDUCED\_INTEGRATION \} . $$ @@ -2261,39 +2114,10 @@ value, and outputs it at analogue voltage levels for the summing junction. $ FG = \{ DIGBUF, DL2AL \} $ -We analyse the buffered flip flop circuitry in table~\ref{tbl:digbuf}. - -\begin{table}[h+] -\caption{ $DIGBUF,DL2AL$ flip flop buffered($FFB$): Failure Mode Effects Analysis} % title of Table -\label{tbl:digbuf} - -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ - % & & & & \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$DIGBUF$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - - - \hline \hline - FS1: $DIGBUF$ $STOPPED$ & & output stuck & & $OUTPUT STUCK$ \\ - FS2: $DIGBUF$ $LOW$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline -%\hline - FS3: $DL2AL$ $LOW$ & & output perm. high & & $OUTPUT STUCK$ \\ - FS4: $DL2AL$ $HIGH$ & & output perm. low & & $OUTPUT STUCK$ \\ - FS5: $DL2AL$ $LOW\_SLEW$ & & no current drive & & $LOW\_SLEW$ \\ \hline - - -\hline -\hline -\end{tabular} -\end{table} - -We now collect symptoms $\{OUTPUT STUCK, LOW\_SLEW\}$ and create a {\dc} %at the third level of symptom abstraction -called $FFB$. - - -\clearpage +We analyse the buffered flip flop circuitry +and create a {\dc} $FFB$, +where $$fm (FFB) = \{OUTPUT STUCK, LOW\_SLEW\}$$. +%\clearpage \subsection{Final, top level {\fg} for sigma delta Converter} @@ -2301,39 +2125,13 @@ We now have two {\dcs}, $FFB$ and $BISJ$. These together represent all base components within this circuit. We form a final functional group with these: $$ FG = \{ FFB , BISJ \} .$$ -We analyse the buffered {\sd} circuit in table~\ref{tbl:sdadc}. +We analyse the buffered {\sd} circuit using FMMD (see section~\ref{detail:SDADC}). +%in table~\ref{tbl:sdadc}. % % FFB^3 $\{OUTPUT STUCK, LOW\_SLEW\}$ % BISJ^2 $\{ OUTPUT STUCK , REDUCED\_INTEGRATION \}$ % -\begin{table}[h+] -\caption{ $FFB , BISJ $ \sd ($SDADC$): Failure Mode Effects Analysis} % title of Table -\label{tbl:sdadc} - -\begin{tabular}{|| l | l | c | c | l ||} \hline - %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ - % & & & & \\ - % & & & & \\ -\textbf{Failure} & & \textbf{$FFB$ } & & \textbf{Derived Component} \\ - \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ - - \hline \hline - FS1: $FFB$ $OUTPUT STUCK$ & & value max high or low & & $OUTPUT\_OUT\_OF\_RANGE$ \\ - FS2: $FFB$ $LOW\_SLEW$ & & values will appear larger & & $OUTPUT\_INCORRECT$ \\ -% FS3: $IC4^0$ $NOOP$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline -%\hline - FS3: $BISJ$ $OUTPUT STUCK$ & & value max high or low & & $OUTPUT\_OUT\_OF\_RANGE$ \\ - FS4: $BISJ$ $REDUCED\_INTEGRATION$ & & values will appear larger & & $OUTPUT\_INCORRECT$ \\ \hline - - -\hline - -\end{tabular} -\end{table} -%\clearpage -We now collect the symptoms for the \sd -$$ \; \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}.$$ -We can now create a {\dc} to represent the analogue to digital converter, $SADC^4$. +We now have a {\dc} $SDADC$ which provides a failure mode model for the \sd. $$fm(SSDADC) = \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}$$ We now show the final {\dc} hierarchy in figure~\ref{fig:eulersdfinal}. @@ -2371,7 +2169,8 @@ We now show the final {\dc} hierarchy in figure~\ref{fig:eulersdfinal}. % The output from the DQ is sent to the digital comparator formed by R3,R4 % and IC3. % The output from this is sent to the summing integrator as the signal summed with the input. - +\subsection{conclusion} +The \sd example, shows that FMMD can be applied to mixed digital and analogue circuitry. @@ -2434,672 +2233,3 @@ We now show the final {\dc} hierarchy in figure~\ref{fig:eulersdfinal}. - -\section{Applying FMMD to Software} -\label{sec:elecsw} -FMMD can be applied to software, and thus we can build complete failure models -of typical modern safety critical systems. -With modular FMEA i.e. FMMD %(FMMD) -we have the concepts of failure~modes -of components, {\fgs} and symptoms of failure for a functional group. - -A programmatic function has similarities with a {\fg} as defined by the FMMD process. -% -An FMMD {\fg} is placed into a hierarchy. -A software function is placed into a hierarchy, that of its call-tree. -A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'. -It has outputs, i.e. it can perform actions -on data or hardware -which will be used by functions that may call it. -% -We can map a software function to a {\fg} in FMMD. Its failure modes -are the failure modes of the software components (other functions it calls) -and the hardware from which it reads values. -Its outputs are the data it changes, or the hardware actions it performs. -%% -%% Talk about how software specification will often say how hardware -%% will react and how to interpret readings---but they do not -%% always cover the failure modes of the hardware being interfaced too. - -When we have analysed a software function---using failure conditions -of its inputs as failure modes---we can -determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). - -We can thus apply the $\derivec$ process to software functions, by viewing them in terms of their failure -mode behaviour. To simplify things as well, software already fits into a hierarchy. -For Electronics and Mechanical systems, although we may be guided by the original designers -concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs} -and the subsequent hierarchy. With software already written, that hierarchy is fixed. - -% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} -%to software functions. -% -%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} -%to software functions. -% failure modes of a function in order to -%map FMMD to software. - - - -% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} -%to software functions. -% -%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} -%to software functions. -% failure modes of a function in order to -%map FMMD to software. - -\subsection{Software, a natural hierarchy} - -Software written for safety critical systems is usually constrained to -be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}. -Because of this we can assume direct call trees~\footnote{A typical embedded system -will have a run time call tree, and (possibly multiple) interrupt sourced call tress.}. Functions call functions -from the top down and eventually call the lowest level library or IO -functions that interact with hardware/electronics. - -What is potentially difficult with a software function, is deciding what -its failure modes and symptoms are. -With electronic components, we can use literature to point us to suitable sets of -{\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}. %~\cite{en61508}~\cite{en298}. -With software, only some library functions are well known and rigorously documented -enough to have the equivalent of known failure modes. -Most software is `bespoke'. We need a different strategy to -describe the failure mode behaviour of software functions. -We can use definitions from contract programming to assist here. - -\subsection{Contract programming description} - -Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled -and traceable way. Each function is subject to pre-conditions (constraints on its inputs), -post-conditions (constraints on its outputs) and function wide invariants (rules). - - -\paragraph{Mapping contract `pre-condition' violations to failure modes.} - -A precondition, or requirement for a contract software function -defines the correct ranges of input conditions for the function -to operate successfully. -% -For a software function, a violation of a pre-condition is -in effect a failure mode of `one of its components'. - - -\paragraph{Mapping contract `post-condition' violations to symptoms.} - -A post condition is a definition of correct behaviour by a function. -A violated post condition is a symptom of failure, or derived failure mode, of a function. -Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function. - -\paragraph{Mapping contract `invariant' violations to symptoms and failure modes.} - -Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology), -and to outputs (where violations can be considered {failure symptoms} in FMMD terminology). - - -\subsection{Combined Hardware/Software FMMD} - -For the purpose of example, we chose a simple common safety critical industrial circuit -that is nearly always used in conjunction with a programmatic element. -A common method for delivering a quantitative value in analogue electronics is -to supply a current signal to represent the value to be sent~\cite{aoe}[p.934]. -Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale, -and this is referred to as {\ft} signalling. -% -{\ft} signalling has intrinsic electrical safety advantages. -% -Because the current in a loop is constant~\cite{aoe}[p.20] -resistance in the wires between the source and receiving end is not an issue -that can alter the accuracy of the signal. -% -%This circuit has many advantages for safety. -If the signal becomes disconnected -it reads $0mA$ at the receiving end: as this is outside the {\ft} range, -it is easily detectable as an error condition rather than an incorrect value. -% -Should the driving electronics go wrong at the source end, it will usually -supply far too little or far too much current, also making error conditions easy to detect. -% -At the receiving end, we only require one simple component to convert the -current signal into a voltage that we can read with an AD---a resistor---given -its properties defined by Ohms law. % the humble resistor! - - -%BLOCK DIAGRAM HERE WITH FT CIRCUIT LOOP - -\begin{figure}[h] - \centering - \includegraphics[width=230pt]{./CH5_Examples/ftcontext.png} - % ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385 - \caption{Context Diagram for {\ft} loop} - \label{fig:ftcontext} -\end{figure} - - -The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} -signal to a micro-controller system. -The signal is locally driven over a load resistor, and then read into the micro-controller via -an ADC and its multiplexer. -With the voltage determined at the ADC we read the intended quantitative -value from the external equipment. - -\subsection{Simple Software Example} - - -Consider a software function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) -representing the current detected with an additional error indication flag . -% -Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage -from an ADC into the software. -Let us define any value outside the 4mA to 20mA range as an error condition. -% -As we read a voltage voltage, we use Ohms law~\cite{aoe} to determine the mA current detected: $V=IR$, $0.004A * \ohms{220} = 0.88V$ -and $0.020A * \ohms{220} = 4.4V$. -% -Our acceptable voltage range is therefore - -$$(V \ge 0.88) \wedge (V \le 4.4) \; .$$ - -This voltage range forms our input requirement and can be considered as an invariant condition. -% -We can now examine a software function that performs a conversion from the voltage read to -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. -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}). - - -%%{\vbox{ -\begin{figure}[h+] - -\footnotesize -\begin{verbatim} -/***********************************************/ -/* read_4_20_input() */ -/***********************************************/ -/* Software function to read 4mA to 20mA input */ -/* returns a value from 0-999 proportional */ -/* to the current input. */ -/***********************************************/ -int read_4_20_input ( int * value ) { - double input_volts; - int error_flag; - - /* require: input from ADC to be - between 0.88 and 4.4 volts */ - - - input_volts = read_ADC(INPUT_4_20_mA); - - if ( input_volts < 0.88 || input_volts > 4.4 ) { - error_flag = 1; /* Error flag set to TRUE */ - } - else { - *value = (input_volts - 0.88) * ( 4.4 - 0.88 ) * 999.0; - error_flag = 0; /* indicate current input in range */ - } - - /* ensure: value is proportional (0-999) to the - 4 to 20mA input */ - - return error_flag; -} -\end{verbatim} -%} -%}\clearpage - -\caption{Software Function: \textbf{read\_4\_20\_input}} -\label{fig:code_read_4_20_input} -%\label{fig:420i} -\end{figure} -\clearpage -We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a -voltage for a given ADC channel. -% -This function -deals directly with the hardware in the micro-controller on which the software is running. %software on. -% -The software's job is to select the correct channel (ADC multiplexer) and then to initiate a -conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}). -% -It takes the raw ADC reading and converts it into a -floating point\footnote{the type, `double' or `double precision', is a -standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.} -voltage value. - - - - - -%{\vbox{ -\begin{figure}[h+] - -\footnotesize -\begin{verbatim} -/***********************************************/ -/* read_ADC() */ -/***********************************************/ -/* Software function to read voltage from a */ -/* specified ADC MUX channel */ -/* Assume 10 ADC MUX channels 0..9 */ -/* ADC_CHAN_RANGE = 9 */ -/* Assume ADC is 12 bit and ADCRANGE = 4096 */ -/* returns voltage read as double precision */ -/***********************************************/ -double read_ADC( int channel ) { - int timeout = 0; - /* require: a) input channel from ADC to be - in valid ADC range - b) voltage ref is 0.1% of 5V */ - - /* return out of range result */ - /* if invalid channel selected */ - if ( channnel > ADC_CHAN_RANGE ) - return -2.0; - - /* set the multiplexer to the desired channel */ - ADCMUX = channel; - - ADCGO = 1; /* initiate ADC conversion hardware */ - - /* wait for ADC conversion with timeout */ - while ( ADCGO == 1 || timeout < 100 ) - timeout++; - - if ( timeout < 100 ) - dval = (double) ADCOUT * 5.0 / ADCRANGE; - else - dval = -1.0; /* indicate invalid reading */ - - /* return voltage as a floating point value */ - - /* ensure: value is voltage input to within 0.1% */ - - return dval; -} -\end{verbatim} -\caption{Software Function: \textbf{read\_ADC}} -\label{fig:code_read_ADC} -\end{figure} -%} -%} -\clearpage - -We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. - -\begin{figure}[h] - \centering - \includegraphics[width=100pt]{./CH5_Examples/ct1.png} - % ct1.png: 151x224 pixel, 72dpi, 5.33x7.90 cm, bb=0 0 151 224 - \caption{Call tree for software example} - \label{fig:ct1} -\end{figure} - -This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the -the software is reading values from the `lower~level' electronics. -% -FMEA is always a bottom-up process and so we must begin with this hardware. -% -The hardware is simply a load resistor, connected across an ADC input -pin on the micro-controller and ground. -% -We can identify the resistor and the ADC module of the micro-controller as -the base components in this design. -% -We now apply FMMD starting with the hardware. - - -\subsection{FMMD Process} - -\paragraph{Functional Group - Convert mA to Voltage - CMATV} - -This functional group contains the load resistor -and the physical Analogue to Digital Converter (ADC). -Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$. -We now determine the {\fms} of all the components in $G_1$. -For the resistor we can use a failure mode set from the literature~\cite{en298}. -Where the function $fm$ returns a set of failure modes for a given component we can state: - -$$ fm(R) = \{OPEN,SHORT\}. $$ -\vbox{ -For the ADC we can determine the following failure modes: - -\begin{itemize} - \item STUCKAT --- The ADC outputs a constant value, - \item MUXFAIL --- The ADC cannot select its input channel correctly, - \item LOW --- The ADC output is always LOW, or zero ADC counts, - \item HIGH --- The ADC output is always HIGH, or max ADC counts. -\end{itemize} -} -We can use the function $fm$ to define the {\fms} of an ADC thus: -$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$ - -With these failure modes, we can analyse our first functional group, see table~\ref{tbl:cmatv}. - -{ -\tiny -\begin{table}[h+] -\center -\caption{$G_1$: Failure Mode Effects Analysis} % title of Table -\label{tbl:cmatv} - -\begin{tabular}{|| l | c | l ||} \hline - %\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ - %\textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline - % & & & & \\ - - \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ - \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ - - - \hline \hline - 1: $R_{OPEN}$ & resistor open, & $HIGH$ \\ - & voltage on pin high & \\ \hline - - 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ - & voltage on pin low & \\ \hline \hline - - - - 3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\ - & fixed value & \\ \hline - - - - 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ - & wrong channel & \\ \hline - - 5: $ADC_{LOW}$ & output low & $LOW$ \\ - 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline - - -\hline - - -\hline - -\end{tabular} -\end{table} -} - - -We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. -We now create a {\dc} to represent this called $CMATV$. - -We can express this using the `$\derivec$' function thus: -$$ CMATV = \; \derivec (G_1) .$$ - -As its failure modes, are the symptoms of failure from the functional group we can now state: -$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$ - - -\paragraph{Functional Group - Software - Read\_ADC - RADC} - -The software function $Read\_ADC$ uses the ADC hardware analysed -as the {\dc} CMATV above. - - -The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as -{\em/* require: a) input channel from ADC to be - in valid ADC range - b) voltage ref is 0.1\% of 5V */}. -% -From the above contractual programming requirements, we see that -the function must be sent the correct channel number. -% -A violation of this can be considered a {\fm} of the function, -which we can call $ CHAN\_NO $. -% -The reference voltage for the ADC has a 0.1\% accuracy requirement. -% -If the reference value is outside of this, it is also a {\fm} -of this function, which we can call $V\_REF$. - -Taken as a component for use in FMEA/FMMD our function has -two failure modes. We can therefore treat it as a generic component, $Read\_ADC$, -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 \}$. - -We now analyse this hardware/software combined {\fg}. - - - -{ -\tiny -\begin{table}[h+] -\caption{$G_2$: Failure Mode Effects Analysis} % title of Table -\label{tbl:radc} - -\begin{tabular}{|| l | c | l ||} \hline -% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ -% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline - - \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ - \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ - - - \hline - 1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ - & read & \\ \hline - - 2: ${VREF}$ & ADC volt-ref & $VV\_ERR$ \\ - & incorrect & \\ \hline \hline - - - - 3: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\ - & incorrect & \\ \hline - - - - 4: $CMATV_{HIGH}$ & ADC may read & $HIGH$ \\ - & wrong channel & \\ \hline - - 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline - -\hline - - -\hline - -\end{tabular} -\end{table} -} - - - -We now collect the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc}) -as $\{ VV\_ERR, HIGH, LOW \}$. We can add as well the violation of the postcondition -for the function. -This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */ }, -corresponds to $VV\_ERR$, and is already in the {\fm} set for this {\fg}. - -We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following -{\fms}: - -$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ - - - - - -\paragraph{Functional Group - Software - voltage to per mil - VTPM } - -This function sits on top of the $RADC$ {\dc} determined above. -We look at the pre-conditions for the function $read\_4\_20\_input$ , % which we can call $RI$ -to determine its {\fms}. -Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}. -We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition -we can state, - -$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$ - -We can now form a functional group with the {\dc} $RADC$ and the -software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $. - - - -{ -\tiny -\begin{table}[h+] -\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table -\label{tbl:r420i} - -\begin{tabular}{|| l | c | l ||} \hline -% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ -% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline - \hline - \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ - \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ - - - \hline - 1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\ - & outside range & $RANGE$ \\ \hline - - 2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ - & incorrect & \\ \hline \hline - - - - 3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\ - & incorrect & \\ \hline - - - - 4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\ - & wrong channel & $RANGE$ \\ \hline - -\hline - - -\hline - -\end{tabular} -\end{table} -} - -The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$. -The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the - 4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes. -% \paragraph{Final Functional Group} -For single failures these are the two ways in which this function -can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable. -The $VAL\_ERR$ will simply mean that the value read is incorrect. - -We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus: - -$$ R420I = \; \derivec(G_3) .$$ - -This new {\dc} has the following {\fms}: -$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$ - -% -% Using the derived components, CMATV and VTPM we create -% a new functional group. This -% integrates FMEA's from software and eletronics -% into the same failure mode model. - - - -We can now represent the software/hardware FMMD analysis -as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig:hd}. - -% HTR 27OCT2012 % \begin{figure}[h] -% HTR 27OCT2012 % \centering -% HTR 27OCT2012 % \includegraphics[width=200pt]{./CH5_Examples/hd.png} -% HTR 27OCT2012 % % hd.png: 363x520 pixel, 72dpi, 12.81x18.34 cm, bb=0 0 363 520 -% HTR 27OCT2012 % \caption{FMMD hierarchy with hardware and software elements} -% HTR 27OCT2012 % \label{fig:hd} -% HTR 27OCT2012 % \end{figure} - -\begin{figure}[h] - \centering - \includegraphics[width=300pt]{./CH5_Examples/eulerswhw.png} - % eulerswhw.png: 510x344 pixel, 72dpi, 17.99x12.14 cm, bb=0 0 510 344 - \caption{Euler diagram showing relationship between {\dcs} determined from electronics and software.} - \label{fig:eulerswhw} -\end{figure} - - - -We can represent %the hierarchy in figure~\ref{fig:hd} algebraically, -the analysis hierarchy algebraically using the `$\derivec$' function: -%using the groups as intermediate stages: -\begin{eqnarray*} -G_1 &=& \{R,ADC\} \\ -CMATV &=& \;\derivec (G_1) \\ -G_2 &=& \{CMATV, read\_ADC \} \\ -RADC &=& \; \derivec (G_2) \\ -G_3 &=& \{ RADC, read\_4\_20\_input \} \\ -R420I &=& \; \derivec (G_3) \\ -\end{eqnarray*} -or, a nested definition, -$$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ - - - - - -This nested structure means that we have multiple traceable -stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage -of reasoning for each component failure mode. - -%\clearpage -\subsection{Conclusion: Software/Hardware FMMD Model} - -The {\dc} representing the {\ft} reader -in software shows that by FMMD, we can integrate -software and electro-mechanical FMMD models. -With this analysis -we have a complete `reasoning~path' linking the failures modes from the -electronics to those in the software. -Each functional group to {\dc} transition represents a -reasoning stage. -% -Each reasoning stage will have an associated analysis report. -% - - -With traditional FMEA methods the reasoning~distance is large, because -it stretches from the component failure mode to the top---or---system level failure. -For this reason applying traditional FMEA to software stretches -the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is -performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware -interfacing is treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea} - - -We now have a {\dc} for a {\ft} input in software. -Typically, more than one such input could be present in a real-world system. -Not only have we integrated electronics and software in an FMEA, we can also -re-use the analysis for each {\ft} input in the system. - -The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed -by another software function to read other known signals -via the MUX (i.e. voltage references). This strategy would -detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. - -A software specification for a hardware interface will concentrate on -how to interpret raw readings, or what signals to apply for actuators. -Using FMMD we can determine an accurate failure model for the interface as well~\cite{sfmeainterface}. -% -%Detailing this however, is beyond the scope %and page-count -%of this paper. - - - -%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! - - - - - - -\vspace{20pt} - -%typeset in {\Huge \LaTeX} \today diff --git a/submission_thesis/CH5_Examples/software.tex b/submission_thesis/CH5_Examples/software.tex new file mode 100644 index 0000000..cea8e96 --- /dev/null +++ b/submission_thesis/CH5_Examples/software.tex @@ -0,0 +1,673 @@ + + + +\section{Software and Hardware Failure Mode Concepts} +\label{sec:elecsw} +FMMD can be applied to software, and thus we can build complete failure models +of typical modern safety critical systems. +With modular FMEA i.e. FMMD %(FMMD) +we have the concepts of failure~modes +of components, {\fgs} and symptoms of failure for a functional group. + +A programmatic function has similarities with a {\fg} as defined by the FMMD process. +% +An FMMD {\fg} is placed into a hierarchy. +A software function is placed into a hierarchy, that of its call-tree. +A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'. +It has outputs, i.e. it can perform actions +on data or hardware +which will be used by functions that may call it. +% +We can map a software function to a {\fg} in FMMD. Its failure modes +are the failure modes of the software components (other functions it calls) +and the hardware from which it reads values. +Its outputs are the data it changes, or the hardware actions it performs. +%% +%% Talk about how software specification will often say how hardware +%% will react and how to interpret readings---but they do not +%% always cover the failure modes of the hardware being interfaced too. + +When we have analysed a software function---using failure conditions +of its inputs as failure modes---we can +determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). + +We can thus apply the $\derivec$ process to software functions, by viewing them in terms of their failure +mode behaviour. To simplify things as well, software already fits into a hierarchy. +For Electronics and Mechanical systems, although we may be guided by the original designers +concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs} +and the subsequent hierarchy. With software already written, that hierarchy is fixed. + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + + + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + +\subsection{Software, a natural hierarchy} + +Software written for safety critical systems is usually constrained to +be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}. +Because of this we can assume direct call trees~\footnote{A typical embedded system +will have a run time call tree, and (possibly multiple) interrupt sourced call tress.}. Functions call functions +from the top down and eventually call the lowest level library or IO +functions that interact with hardware/electronics. + +What is potentially difficult with a software function, is deciding what +its failure modes and symptoms are. +With electronic components, we can use literature to point us to suitable sets of +{\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}. %~\cite{en61508}~\cite{en298}. +With software, only some library functions are well known and rigorously documented +enough to have the equivalent of known failure modes. +Most software is `bespoke'. We need a different strategy to +describe the failure mode behaviour of software functions. +We can use definitions from contract programming to assist here. + +\subsection{Contract programming description} + +Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled +and traceable way. Each function is subject to pre-conditions (constraints on its inputs), +post-conditions (constraints on its outputs) and function wide invariants (rules). + + +\paragraph{Mapping contract `pre-condition' violations to failure modes.} + +A precondition, or requirement for a contract software function +defines the correct ranges of input conditions for the function +to operate successfully. +% +For a software function, a violation of a pre-condition is +in effect a failure mode of `one of its components'. + + +\paragraph{Mapping contract `post-condition' violations to symptoms.} + +A post condition is a definition of correct behaviour by a function. +A violated post condition is a symptom of failure, or derived failure mode, of a function. +Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function. + +\paragraph{Mapping contract `invariant' violations to symptoms and failure modes.} + +Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology), +and to outputs (where violations can be considered {failure symptoms} in FMMD terminology). + + +\subsection{Combined Hardware/Software FMMD} + +For the purpose of example, we chose a simple common safety critical industrial circuit +that is nearly always used in conjunction with a programmatic element. +A common method for delivering a quantitative value in analogue electronics is +to supply a current signal to represent the value to be sent~\cite{aoe}[p.934]. +Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale, +and this is referred to as {\ft} signalling. +% +{\ft} signalling has intrinsic electrical safety advantages. +% +Because the current in a loop is constant~\cite{aoe}[p.20] +resistance in the wires between the source and receiving end is not an issue +that can alter the accuracy of the signal. +% +%This circuit has many advantages for safety. +If the signal becomes disconnected +it reads $0mA$ at the receiving end: as this is outside the {\ft} range, +it is easily detectable as an error condition rather than an incorrect value. +% +Should the driving electronics go wrong at the source end, it will usually +supply far too little or far too much current, also making error conditions easy to detect. +% +At the receiving end, we only require one simple component to convert the +current signal into a voltage that we can read with an AD---a resistor---given +its properties defined by Ohms law. % the humble resistor! + + +%BLOCK DIAGRAM HERE WITH FT CIRCUIT LOOP + +\begin{figure}[h] + \centering + \includegraphics[width=230pt]{./CH5_Examples/ftcontext.png} + % ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385 + \caption{Context Diagram for {\ft} loop} + \label{fig:ftcontext} +\end{figure} + + +The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} +signal to a micro-controller system. +The signal is locally driven over a load resistor, and then read into the micro-controller via +an ADC and its multiplexer. +With the voltage determined at the ADC we read the intended quantitative +value from the external equipment. + +\subsection{Simple Software Example} + + +Consider a software function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) +representing the current detected with an additional error indication flag . +% +Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage +from an ADC into the software. +Let us define any value outside the 4mA to 20mA range as an error condition. +% +As we read a voltage voltage, we use Ohms law~\cite{aoe} to determine the mA current detected: $V=IR$, $0.004A * \ohms{220} = 0.88V$ +and $0.020A * \ohms{220} = 4.4V$. +% +Our acceptable voltage range is therefore + +$$(V \ge 0.88) \wedge (V \le 4.4) \; .$$ + +This voltage range forms our input requirement and can be considered as an invariant condition. +% +We can now examine a software function that performs a conversion from the voltage read to +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. +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}). + + +%%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_4_20_input() */ +/***********************************************/ +/* Software function to read 4mA to 20mA input */ +/* returns a value from 0-999 proportional */ +/* to the current input. */ +/***********************************************/ +int read_4_20_input ( int * value ) { + double input_volts; + int error_flag; + + /* require: input from ADC to be + between 0.88 and 4.4 volts */ + + + input_volts = read_ADC(INPUT_4_20_mA); + + if ( input_volts < 0.88 || input_volts > 4.4 ) { + error_flag = 1; /* Error flag set to TRUE */ + } + else { + *value = (input_volts - 0.88) * ( 4.4 - 0.88 ) * 999.0; + error_flag = 0; /* indicate current input in range */ + } + + /* ensure: value is proportional (0-999) to the + 4 to 20mA input */ + + return error_flag; +} +\end{verbatim} +%} +%}\clearpage + +\caption{Software Function: \textbf{read\_4\_20\_input}} +\label{fig:code_read_4_20_input} +%\label{fig:420i} +\end{figure} +\clearpage +We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a +voltage for a given ADC channel. +% +This function +deals directly with the hardware in the micro-controller on which the software is running. %software on. +% +The software's job is to select the correct channel (ADC multiplexer) and then to initiate a +conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}). +% +It takes the raw ADC reading and converts it into a +floating point\footnote{the type, `double' or `double precision', is a +standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.} +voltage value. + + + + + +%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_ADC() */ +/***********************************************/ +/* Software function to read voltage from a */ +/* specified ADC MUX channel */ +/* Assume 10 ADC MUX channels 0..9 */ +/* ADC_CHAN_RANGE = 9 */ +/* Assume ADC is 12 bit and ADCRANGE = 4096 */ +/* returns voltage read as double precision */ +/***********************************************/ +double read_ADC( int channel ) { + int timeout = 0; + /* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1% of 5V */ + + /* return out of range result */ + /* if invalid channel selected */ + if ( channnel > ADC_CHAN_RANGE ) + return -2.0; + + /* set the multiplexer to the desired channel */ + ADCMUX = channel; + + ADCGO = 1; /* initiate ADC conversion hardware */ + + /* wait for ADC conversion with timeout */ + while ( ADCGO == 1 || timeout < 100 ) + timeout++; + + if ( timeout < 100 ) + dval = (double) ADCOUT * 5.0 / ADCRANGE; + else + dval = -1.0; /* indicate invalid reading */ + + /* return voltage as a floating point value */ + + /* ensure: value is voltage input to within 0.1% */ + + return dval; +} +\end{verbatim} +\caption{Software Function: \textbf{read\_ADC}} +\label{fig:code_read_ADC} +\end{figure} +%} +%} +\clearpage + +We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. + +\begin{figure}[h] + \centering + \includegraphics[width=100pt]{./CH5_Examples/ct1.png} + % ct1.png: 151x224 pixel, 72dpi, 5.33x7.90 cm, bb=0 0 151 224 + \caption{Call tree for software example} + \label{fig:ct1} +\end{figure} + +This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the +the software is reading values from the `lower~level' electronics. +% +FMEA is always a bottom-up process and so we must begin with this hardware. +% +The hardware is simply a load resistor, connected across an ADC input +pin on the micro-controller and ground. +% +We can identify the resistor and the ADC module of the micro-controller as +the base components in this design. +% +We now apply FMMD starting with the hardware. + + +\subsection{FMMD Process} + +\paragraph{Functional Group - Convert mA to Voltage - CMATV} + +This functional group contains the load resistor +and the physical Analogue to Digital Converter (ADC). +Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$. +We now determine the {\fms} of all the components in $G_1$. +For the resistor we can use a failure mode set from the literature~\cite{en298}. +Where the function $fm$ returns a set of failure modes for a given component we can state: + +$$ fm(R) = \{OPEN,SHORT\}. $$ +\vbox{ +For the ADC we can determine the following failure modes: + +\begin{itemize} + \item STUCKAT --- The ADC outputs a constant value, + \item MUXFAIL --- The ADC cannot select its input channel correctly, + \item LOW --- The ADC output is always LOW, or zero ADC counts, + \item HIGH --- The ADC output is always HIGH, or max ADC counts. +\end{itemize} +} +We can use the function $fm$ to define the {\fms} of an ADC thus: +$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$ + +With these failure modes, we can analyse our first functional group, see table~\ref{tbl:cmatv}. + +{ +\tiny +\begin{table}[h+] +\center +\caption{$G_1$: Failure Mode Effects Analysis} % title of Table +\label{tbl:cmatv} + +\begin{tabular}{|| l | c | l ||} \hline + %\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + %\textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline + % & & & & \\ + + \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ + \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ + + + \hline \hline + 1: $R_{OPEN}$ & resistor open, & $HIGH$ \\ + & voltage on pin high & \\ \hline + + 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ + & voltage on pin low & \\ \hline \hline + + + + 3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\ + & fixed value & \\ \hline + + + + 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ + & wrong channel & \\ \hline + + 5: $ADC_{LOW}$ & output low & $LOW$ \\ + 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline + + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + +We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. +We now create a {\dc} to represent this called $CMATV$. + +We can express this using the `$\derivec$' function thus: +$$ CMATV = \; \derivec (G_1) .$$ + +As its failure modes, are the symptoms of failure from the functional group we can now state: +$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$ + + +\paragraph{Functional Group - Software - Read\_ADC - RADC} + +The software function $Read\_ADC$ uses the ADC hardware analysed +as the {\dc} CMATV above. + + +The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as +{\em/* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1\% of 5V */}. +% +From the above contractual programming requirements, we see that +the function must be sent the correct channel number. +% +A violation of this can be considered a {\fm} of the function, +which we can call $ CHAN\_NO $. +% +The reference voltage for the ADC has a 0.1\% accuracy requirement. +% +If the reference value is outside of this, it is also a {\fm} +of this function, which we can call $V\_REF$. + +Taken as a component for use in FMEA/FMMD our function has +two failure modes. We can therefore treat it as a generic component, $Read\_ADC$, +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 \}$. + +We now analyse this hardware/software combined {\fg}. + + + +{ +\tiny +\begin{table}[h+] +\caption{$G_2$: Failure Mode Effects Analysis} % title of Table +\label{tbl:radc} + +\begin{tabular}{|| l | c | l ||} \hline +% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ +% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline + + \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ + \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ + + + \hline + 1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ + & read & \\ \hline + + 2: ${VREF}$ & ADC volt-ref & $VV\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $CMATV_{HIGH}$ & ADC may read & $HIGH$ \\ + & wrong channel & \\ \hline + + 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + + +We now collect the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc}) +as $\{ VV\_ERR, HIGH, LOW \}$. We can add as well the violation of the postcondition +for the function. +This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */ }, +corresponds to $VV\_ERR$, and is already in the {\fm} set for this {\fg}. + +We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following +{\fms}: + +$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ + + + + + +\paragraph{Functional Group - Software - voltage to per mil - VTPM } + +This function sits on top of the $RADC$ {\dc} determined above. +We look at the pre-conditions for the function $read\_4\_20\_input$ , % which we can call $RI$ +to determine its {\fms}. +Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}. +We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition +we can state, + +$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$ + +We can now form a functional group with the {\dc} $RADC$ and the +software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $. + + + +{ +\tiny +\begin{table}[h+] +\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table +\label{tbl:r420i} + +\begin{tabular}{|| l | c | l ||} \hline +% \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ +% \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline + \hline + \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ + \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ + + + \hline + 1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\ + & outside range & $RANGE$ \\ \hline + + 2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\ + & wrong channel & $RANGE$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + +The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$. +The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the + 4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes. +% \paragraph{Final Functional Group} +For single failures these are the two ways in which this function +can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable. +The $VAL\_ERR$ will simply mean that the value read is incorrect. + +We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus: + +$$ R420I = \; \derivec(G_3) .$$ + +This new {\dc} has the following {\fms}: +$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$ + +% +% Using the derived components, CMATV and VTPM we create +% a new functional group. This +% integrates FMEA's from software and eletronics +% into the same failure mode model. + + + +We can now represent the software/hardware FMMD analysis +as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig:hd}. + +% HTR 27OCT2012 % \begin{figure}[h] +% HTR 27OCT2012 % \centering +% HTR 27OCT2012 % \includegraphics[width=200pt]{./CH5_Examples/hd.png} +% HTR 27OCT2012 % % hd.png: 363x520 pixel, 72dpi, 12.81x18.34 cm, bb=0 0 363 520 +% HTR 27OCT2012 % \caption{FMMD hierarchy with hardware and software elements} +% HTR 27OCT2012 % \label{fig:hd} +% HTR 27OCT2012 % \end{figure} + +\begin{figure}[h] + \centering + \includegraphics[width=300pt]{./CH5_Examples/eulerswhw.png} + % eulerswhw.png: 510x344 pixel, 72dpi, 17.99x12.14 cm, bb=0 0 510 344 + \caption{Electronics and Software shown in an integrated failure mode + model---an Euler diagram showing relationship between {\dcs} determined from electronics and software---the two outermost contours are software functions, + and the inner two are electronic {\dcs}.} + \label{fig:eulerswhw} +\end{figure} + + + +We can represent %the hierarchy in figure~\ref{fig:hd} algebraically, +the analysis hierarchy algebraically using the `$\derivec$' function: +%using the groups as intermediate stages: +\begin{eqnarray*} +G_1 &=& \{R,ADC\} \\ +CMATV &=& \;\derivec (G_1) \\ +G_2 &=& \{CMATV, read\_ADC \} \\ +RADC &=& \; \derivec (G_2) \\ +G_3 &=& \{ RADC, read\_4\_20\_input \} \\ +R420I &=& \; \derivec (G_3) \\ +\end{eqnarray*} +or, a nested definition, +$$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ + + + + + +This nested structure means that we have multiple traceable +stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage +of reasoning for each component failure mode. + +%\clearpage +\subsection{Conclusion: Software/Hardware FMMD Model} + +The {\dc} representing the {\ft} reader +in software shows that by FMMD, we can integrate +software and electro-mechanical FMMD models. +With this analysis +we have a complete `reasoning~path' linking the failures modes from the +electronics to those in the software. +Each functional group to {\dc} transition represents a +reasoning stage. +% +Each reasoning stage will have an associated analysis report. +% + + +With traditional FMEA methods the reasoning~distance is large, because +it stretches from the component failure mode to the top---or---system level failure. +For this reason applying traditional FMEA to software stretches +the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is +performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware +interfacing is treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea} + + +We now have a {\dc} for a {\ft} input in software. +Typically, more than one such input could be present in a real-world system. +Not only have we integrated electronics and software in an FMEA, we can also +re-use the analysis for each {\ft} input in the system. + +The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed +by another software function to read other known signals +via the MUX (i.e. voltage references). This strategy would +detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. + +A software specification for a hardware interface will concentrate on +how to interpret raw readings, or what signals to apply for actuators. +Using FMMD we can determine an accurate failure model for the interface as well~\cite{sfmeainterface}. +% +%Detailing this however, is beyond the scope %and page-count +%of this paper. + + + +%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! + + + + + + +\vspace{20pt} + +%typeset in {\Huge \LaTeX} \today diff --git a/submission_thesis/appendixes/detailed_analysis.tex b/submission_thesis/appendixes/detailed_analysis.tex index 781d137..85ea47a 100644 --- a/submission_thesis/appendixes/detailed_analysis.tex +++ b/submission_thesis/appendixes/detailed_analysis.tex @@ -258,5 +258,225 @@ $$ \clearpage \section{Sigma Delta Detailed FMMD Analyses} +\subsection{FMMD Analysis of Summing Junction Integrator: SUMJINT} +\label{detail:SUMJINT} +\begin{table}[h+] +\center +\caption{Summing Junction Integrator($SUMJINT$): Failure Mode Effects Analysis} % title of Table +\label{tbl:sumjint} + +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\ + % & & & & \\ + \textbf{Failure} & & \textbf{$SUMJINT$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + + + \hline\hline + FS1: $R1$ $OPEN$ & & $V_{in}$ dominates input & & $V_{in} DOM$ \\ + FS2: $R1$ $SHORT$ & & $V_{fb}$ dominates input & & $V_{fb} DOM$ \\ \hline + FS3: $R2$ $OPEN$ & & $V_{fb}$ dominates input & & $V_{fb} DOM$ \\ + FS4: $R2$ $SHORT$ & & $V_{in}$ dominates input & & $V_{in} DOM$ \\ \hline + FS5: $IC1$ $HIGH$ & & output perm. high & & HIGH \\ + FS6: $IC1$ $LOW$ & & output perm. low & & LOW \\ \hline + FS7: $IC1$ $NOOP$ & & no current to drive C1 & & NO\_INTEGRATION \\ + FS8: $IC1$ $LOW\_SLEW$ & & signal delay to C1 & & NO\_INTEGRATION \\ \hline + + FS9: $C1$ $OPEN$ & & no capacitance & & NO\_INTEGRATION \\ + FS10: $C1$ $SHORT$ & & no capacitance & & NO\_INTEGRATION \\ \hline + +% \hline +% FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\ +% FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\ \hline +% FS3: $IC2$ $NOOP$ & & no current drive & & LOW \\ +% FS4: $IC2$ $LOW\_SLEW$ & & delayed signal & & LOW\_SLEW \\ \hline +% \hline +\hline +\end{tabular} +\end{table} +Collecting the {\dc} failure modes of +$SUMJINT$ we obtain $$\{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ + +\subsection{FMMD Analysis of High Impedance Signal Buffer : HISB} +\label{detail:HISB} +\begin{table}[h+] +\center +% \center +\caption{ High Impedance Signal Buffer : Failure Mode Effects Analysis} % title of Table +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result} & & \textbf{Symptom} \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$HISB$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + \hline\hline + FS1: $IC2$ $HIGH$ & & output perm. high & & HIGH \\ + FS2: $IC2$ $LOW$ & & output perm. low & & LOW \\ + FS3: $IC2$ $NOOP$ & & no current to output & & $NOOP$ \\ + FS4: $IC2$ $LOW\_SLEW$ & & delay signal & & $LOW\_{SLEW}$ \\ \hline +\end{tabular} +\end{table} +% \hline + +\subsection{FMMD Analysis of Digital level to analogue level converter : DL2AL} +\label{detail:DL2AL} + + +\begin{table}[h+] +\center +\caption{$PD , IC3$ Digital level to analogue level converter: Failure Mode Effects Analysis} % title of Table +\label{tbl:DS2AS} + +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ + % & & & & \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$DS2AL$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + + \hline \hline + FS1: $PD $ $HIGH$ & & output perm. low & & LOW \\ + FS2: $PD $ $LOW$ & & output perm. low & & HIGH \\ \hline + +\hline + FS3: $IC3$ $HIGH$ & & output perm. high & & HIGH \\ + FS4: $IC3$ $LOW$ & & output perm. low & & LOW \\ + FS5: $IC3$ $NOOP$ & & no current drive & & LOW \\ + FS6: $IC3$ $LOW\_{SLEW}$ & & delayed signal & & $LOW\_{SLEW}$ \\ \hline +\hline + +\end{tabular} +\end{table} + +We collect the symptoms of failure $\{ LOW, HIGH, LOW\_{SLEW} \}$. + + +\subsection{FMMD Analysis of Digital level to analogue level converter : DL2AL} +\label{detail:DIGBUF} + +\begin{table}[h+] +\center +\caption{$ IC4, CLOCK $ Digital Buffer: Failure Mode Effects Analysis} % title of Table +\label{tbl:digbuf} + +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ + % & & & & \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$DIGBUF$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + %$$ fm ( CD4013B) = \{ HIGH, LOW, NOOP \} $$ + \hline \hline + FS1: $CLOCK$ $STOPPED$ & & buffer stopped & & STOPPED \\ \hline + + FS2: $IC4$ $HIGH$ & & buffer stopped & & STOPPED \\ + FS3: $IC4$ $LOW$ & & buffer stopped & & STOPPED \\ + FS4: $IC4$ $NOOP$ & & no current drive & & LOW \\ \hline + \hline +\hline + +\end{tabular} +\end{table} +We collect the symptoms of failure $\{ LOW, STOPPED \}$. + + + +\subsection{FMMD Analysis of buffered integrating summing junction : BISJ} +\label{detail:BISJ} +\begin{table}[h+] +\caption{ $HISB , SUMJINT$ buffered integrating summing junction($BISJ$): Failure Mode Effects Analysis} % title of Table +\label{tbl:BISJ} +\begin{tabular}{|| l | l | c | c | l ||} \hline +% \textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ + % & & & & \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$BISJ$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + + + \hline \hline + FS1: $SUMJINT$ $V_{in} DOM$ & & output integral of $V_{in}$ & & $OUTPUT STUCK$ \\ + FS2: $SUMJINT$ $V_{fb} DOM$ & & output integral of $V_{fb}$ & & $OUTPUT STUCK$ \\ + % $$ fm(SUMJUINT^1_0) = \{ V_{in} DOM, V_{fb} DOM, NO\_INTEGRATION, HIGH, LOW \} .$$ + FS3: $SUMJINT$ $NO\_INTEGRATION$ & & output stuck high or low & & $OUTPUT STUCK$ \\ + FS4: $SUMJINT$ $HIGH$ & & output stuck high & & $OUTPUT STUCK$ \\ + FS5: $SUMJINT$ $LOW$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline +%\hline + FS6: $HISB$ $HIGH$ & & output perm. high & & $OUTPUT STUCK$ \\ + FS7: $HISB$ $LOW$ & & output perm. low & & $OUTPUT STUCK$ \\ + FS8: $HISB$ $ NO\_INTEGRATION$ & & no current drive & & $OUTPUT STUCK$ \\ + FS9: $HISB$ $LOW\_SLEW$ & & delayed signal & & $REDUCED\_INTEGRATION$ \\ \hline +\hline +\end{tabular} +\end{table} + +We now collect the symptoms of failure $\{ OUTPUT STUCK , REDUCED\_INTEGRATION \}$, and create a {\dc} +called $BISJ$. + + + + +\subsection{FMMD Analysis of flip flop buffered : FFB} +\label{detail:FFB} +\begin{table}[h+] +\caption{ $DIGBUF,DL2AL$ flip flop buffered($FFB$): Failure Mode Effects Analysis} % title of Table +\label{tbl:digbuf} + +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ + % & & & & \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$DIGBUF$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + + + \hline \hline + FS1: $DIGBUF$ $STOPPED$ & & output stuck & & $OUTPUT STUCK$ \\ + FS2: $DIGBUF$ $LOW$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline +%\hline + FS3: $DL2AL$ $LOW$ & & output perm. high & & $OUTPUT STUCK$ \\ + FS4: $DL2AL$ $HIGH$ & & output perm. low & & $OUTPUT STUCK$ \\ + FS5: $DL2AL$ $LOW\_SLEW$ & & no current drive & & $LOW\_SLEW$ \\ \hline + + +\hline +\hline +\end{tabular} +\end{table} + +We now collect symptoms $\{OUTPUT STUCK, LOW\_SLEW\}$ and create a {\dc} %at the third level of symptom abstraction +called $FFB$. + +\subsection{FMMD Analysis of \sd : SDADC} +\label{detail:SDADC} +\begin{table}[h+] +\caption{ $FFB , BISJ $ \sd ($SDADC$): Failure Mode Effects Analysis} % title of Table +\label{tbl:sdadc} + +\begin{tabular}{|| l | l | c | c | l ||} \hline + %\textbf{Failure Scenario} & & \textbf{failure result } & & \textbf{Symptom} \\ + % & & & & \\ + % & & & & \\ +\textbf{Failure} & & \textbf{$FFB$ } & & \textbf{Derived Component} \\ + \textbf{cause} & & \textbf{Effect} & & \textbf{Failure Mode} \\ + + \hline \hline + FS1: $FFB$ $OUTPUT STUCK$ & & value max high or low & & $OUTPUT\_OUT\_OF\_RANGE$ \\ + FS2: $FFB$ $LOW\_SLEW$ & & values will appear larger & & $OUTPUT\_INCORRECT$ \\ +% FS3: $IC4^0$ $NOOP$ & & output stuck low & & $OUTPUT STUCK$ \\ \hline +%\hline + FS3: $BISJ$ $OUTPUT STUCK$ & & value max high or low & & $OUTPUT\_OUT\_OF\_RANGE$ \\ + FS4: $BISJ$ $REDUCED\_INTEGRATION$ & & values will appear larger & & $OUTPUT\_INCORRECT$ \\ \hline + + +\hline + +\end{tabular} +\end{table} +%\clearpage +We now collect the symptoms for the \sd +$$ \; \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}.$$ +We can now create a {\dc} to represent the analogue to digital converter, $SDADC$. +$$fm(SSDADC) = \{OUTPUT\_OUT\_OF\_RANGE, OUTPUT\_INCORRECT\}$$ + diff --git a/submission_thesis/thesis.tex b/submission_thesis/thesis.tex index 4e2bd94..7db99dd 100644 --- a/submission_thesis/thesis.tex +++ b/submission_thesis/thesis.tex @@ -85,6 +85,9 @@ \chapter{FMMD Examples} % {Examples of FMMD applied to electronic circuits} \input{CH5_Examples/copy} +\chapter{Applying FMMD to Software} +\input{CH5_Examples/software} + \chapter {FMMD Metrics Critiques Exceptions and Evaluation} \input{CH6_Evaluation/copy}