diff --git a/papers/fmmd_software_hardware/software_fmmd.tex b/papers/fmmd_software_hardware/software_fmmd.tex index 8a5b4e9..7ce6011 100644 --- a/papers/fmmd_software_hardware/software_fmmd.tex +++ b/papers/fmmd_software_hardware/software_fmmd.tex @@ -121,7 +121,7 @@ failure mode of the component or sub-system}}} % {-\baslineskip} % {0.5\baselineskip} % {\normalfont\normalsize\itshape}}% -\linespread{0.94} +\linespread{0.95} \begin{document} %\pagestyle{fancy} @@ -301,23 +301,23 @@ of failure mode behaviour for the entire system. With higher level modules, we can reach the level in which the software resides. % For instance, to read a voltage into software via an Analogue to Digital Converter (ADC) we rely on an electronic sub-system -that conditions the input signal and then routes it through a multiplexer to the ADC. +that conditions the input signal and then routes it through a multiplexer (MUX) to the ADC. % % up to here committed AF comments 12JUL2012 % -We could easily consider this electronics a `module', and with a -failure mode model for it, modelling the software to hardware interface -becomes far simpler. +We could easily consider this conditioning and MUX circuit `module'; with a +failure mode model defined for it modelling the software to hardware interface +becomes possible. % -The failure mode model, would give us the ways in which the signal conditioning +This failure mode model, would give us the ways in which the signal conditioning and multiplexer could fail. % We can use this to work out how our software -could fail, and with this create a modular FMEA model of the software. +could fail, and with this develop a modular FMEA model of the software. -\section{Modularising FMEA: The FMMD process in more detail.} +\section{Modularising FMEA} %: The FMMD process in more detail.} In outline, in order to modularise FMEA, we must create small modules from the bottom-up. We can do this by taking collections of base~components that @@ -326,10 +326,12 @@ perform (ideally) a simple and well defined task called {\fgs}. We can then analyse the failure mode behaviour of a {\fg} using all the failure modes of all its components. % -When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg}, -we now treat the {\fg} as a {\dc}, where the failure modes of the {\dc} are the symptoms of failure of the {\fg}. +When we have its failure mode behaviour, +called the symptoms of failure from the perspective of the {\fg}, +we treat the {\fg} as a {\dc}, +where the failure modes of the {\dc} are the symptoms of failure of the {\fg}. % -We can now use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model +We can then use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model of the failure mode behaviour of a system. An example of this process, applied to an inverting op-amp configuration is given in~\cite{syssafe2011}. %This methodology is called Failure Mode Modular De-Composition (FMMD). @@ -338,7 +340,7 @@ is given in~\cite{syssafe2011}. The main aim of %Failure Mode Modular Discrimination (FMMD) FMMD is to build a hierarchy of failure behaviour from the {\bc} -level up to the top, or system level, with analysis stages ({\fgs}) %and corresponding {\dcs} +level up to the top, or system level, with analysis stages % ({\fgs}) %and corresponding {\dcs} between each transition to a higher level in the hierarchy. % @@ -358,8 +360,8 @@ we can determine its symptoms of failure. %In fact we can call these %the symptoms of failure for the {\fg}. % -With these symptoms (a set of derived faults from the perspective of the {\fg}) -we can now state that the {\fg} +%With these symptoms (a set of derived faults from the perspective of the {\fg}) +%we can now state that the {\fg} % (as an entity in its own right) can fail in a number of well defined ways. % @@ -395,10 +397,11 @@ We use the symbol `$\derivec$' to represent the creation of a derived component from a {\fg}. This symbol is convenient for drawn hierarchy diagrams. % % (see figure~\ref{fmmdh}). We define the $\derivec$ function, where $\FG$ is the set of all {\fgs} and $\DC$ is the set of all {\dcs}, -$ \derivec ( {\FG} ) \mapsto {\DC} .$ +$ \derivec ( {\FG} ) \rightarrow {\DC} .$ We show an FMMD hierarchy in figure~\ref{fig:fmmdh}. -Using this diagram, we can follow the creation of the hierarchy in -a theoretical system. +% +%Using this diagram, we can follow the creation of the hierarchy in +%a theoretical system. % There are three functional groups comprised of {\bcs}. These are analysed individually using FMEA. @@ -408,7 +411,7 @@ the ways in which the {\fgs} can fail. The ways in which a % The `$\derivec$' function is now applied to create {\dcs}. These are shown in figure~\ref{fig:fmmdh} above the {\fgs}. -Now that we have {\dcs}, we can use them to form a higher level functional group. +Now that we have {\dcs}, we can use them to form a higher level {\fg}. We apply the same FMEA process to this and can derive a top level derived component (which has the system---or top---level failure modes). @@ -439,7 +442,7 @@ derived component (which has the system---or top---level failure modes). Note the diagram of the FMMD hierarchy is very similar to a simple non-recursive programmatic function call tree. -\section{Software: How can we apply FMEA} +\section{FMEA applied to Software} % : How can we apply FMEA} %If FMEA can be applied to software we can build complete failure models %of typical modern safety critical systems. @@ -453,7 +456,9 @@ 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'. +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 upon it. @@ -462,19 +467,20 @@ 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.% from. +and the hardware from which it reads values. % from. % Its outputs are the data it changes, or the hardware actions it performs. When we have analysed a software function---treating failure conditions -of its inputs as `{\fms}'---we can +of its inputs as {\fms}---we can determine its symptoms of failure. % (i.e. how calling functions will see its failure mode behaviour). % We can thus apply the $\derivec$ function to software functions, by viewing them in terms of their failure mode behaviour. To simplify things, software already fits into a hierarchy. % For electronic 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} +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/given. % map the FMMD concepts of {\fms}, {\fgs} and {\dcs} @@ -495,8 +501,8 @@ 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 -are its `failure~modes', and later what are its `failure~symptoms'. +What is potentially difficult with a software function is deciding what +are its failure~modes, and later what are its failure~symptoms. % With electronic components, we can use literature to point us to suitable sets of {\fms}~\cite{fmd91,mil1991,en298}.%,en61508}.%~\cite{en298}. @@ -522,8 +528,7 @@ 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} +%\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 of a function. @@ -544,7 +549,7 @@ 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} has an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20]. +{\ft} has an electrical advantage as well because the current in a loop is constant~\cite{aoe}[p.20]. Thus resistance in the wires between the source and the receiving end is not an issue that can alter the accuracy of the signal. % @@ -555,7 +560,7 @@ and is therefore easy to detect as an error 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, making an error condition easy to detect. % -At the receiving end, need a resistor to convert the +At the receiving end, one needs a resistor to convert the current signal into a voltage that we can read with an ADC.% %we only require one simple component to convert the %current signal into a voltage that we can read with an ADC: the humble resistor! @@ -572,7 +577,7 @@ current signal into a voltage that we can read with an ADC.% \end{figure} -The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} +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. @@ -583,7 +588,7 @@ value from the external equipment. 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 . +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. @@ -604,7 +609,7 @@ 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\footnote{ C coding examples use the Misra~\cite{misra} and SIL-3 recommended language constraints~\cite{en61508}.}. We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision -value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). +value representing the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). %%{\vbox{ @@ -656,7 +661,7 @@ Its job is to select the correct channel (ADC multiplexer) and then to initiate 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 +floating point\footnote{the type `double' or `double precision' is a standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.} voltage value. @@ -752,13 +757,13 @@ We start with the hardware, and then add each of the software functions. This forms the fault mode hierarchy represented in figure~\ref{fig:hd}. -\paragraph{Functional Group - Convert mA to Voltage - CMATV} +\paragraph{Functional Grouping - Convert mA to Voltage - (CMATV)} -This functional group contains the load resistor +This {\fg} 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\}$. +Our {\fg}, $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}. @@ -829,7 +834,7 @@ As its failure modes are the symptoms of failure from the functional group we ca $fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$ -\paragraph{Functional Group - Software - Read\_ADC - RADC} +\paragraph{Functional Group - Software - Read\_ADC - (RADC)} The software function $Read\_ADC$ uses the ADC hardware analysed as the {\dc} CMATV above. @@ -919,12 +924,13 @@ $ 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$ +% +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 */}. +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, +we can state % $ fm(read\_4\_20\_input) = \{ VRNGE \} .$ % @@ -982,7 +988,7 @@ $fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$ % 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:hd}. +as a hierarchical diagram; see figure~\ref{fig:hd}. % \begin{figure}[h] % \centering @@ -1047,7 +1053,7 @@ as a hierarchical diagram, see figure~\ref{fig:hd}. %\clearpage \section{Conclusion} % -The FMMD method has been demonstrated, using an the industry standard {\ft} +The FMMD method has been demonstrated using an the industry standard {\ft} input circuit and software. % The {\dc} representing the {\ft} reader