diff --git a/papers/fmea_software_hardware/software_fmea.tex b/papers/fmea_software_hardware/software_fmea.tex index db30899..c55a66e 100644 --- a/papers/fmea_software_hardware/software_fmea.tex +++ b/papers/fmea_software_hardware/software_fmea.tex @@ -514,7 +514,7 @@ We now apply FMMD starting with the hardware. \section{Failure Mode effects Analysis} Four emerging and current techniques are now used to -alpply FMEA to the hardware, the software, the software medium and the software hardware insterface. +apply FMEA to the hardware, the software, the software medium and the software hardware insterface. \subsection{Hardware FMEA} diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 123bd2d..ec78c0e 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -550,6 +550,9 @@ This would mean the symptom of the failed potential divider would be voltage hig \vbox{ From table \ref{tbl:pdfmea} we can see that the resistor failures modes lead to some common symptoms. +These common symptoms are an important concept for FMMD. +It means that we can take multiple failure modes from a {\fg} and resolve them +to a a common symptom. This means that we simplify the FMEA analysis task for further stages. By drawing directed edges from the failure modes to the symptoms, we can show the relationships between the component failure modes and resultant symptoms. %The {\fg} can now be considered a derived component. @@ -605,7 +608,7 @@ This {\dc} will have two failure modes. We use the symbol $\derivec$ to represent the process of taking the analysed {\fg} and creating from it a {\dc}. The creation of the {\dc} \textbf{PD} is represented in figure~\ref{fig:dc1}. -We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}. +We represent the {\dc} \textbf{PD}, as a DAG in figure \ref{fig:dc1dag}. %We could represent it algebraically thus: $ \derivec(PotDiv) = @@ -853,7 +856,7 @@ and this is represented in table \ref{tbl:ampfmea1}. % %\path (s2) edge (DC); % % -% +% ` % % Connect every node in the hidden layer with the output layer % %\foreach \source in {1,...,5} % % \path (H-\source) edge (O); @@ -1001,11 +1004,12 @@ Failure Scenario & A single failure mode (or a combination), used to \subsection{Parts, Components and Base Components.} A component is anything we use to build a %a product or system. -It could be something %quite complicated +It could be something quite complicated like an %integrated -micro-controller, or quite simple like the resistor. +micro-controller/servo motor, or quite simple like the resistor. % -We can identify a +We %can +identify a component by its name, a manufacturer's part number and perhaps a vendor's reference number. @@ -1023,7 +1027,7 @@ We, in fact, need to go a little further than the above definition of a part, and say that we want to define an atomic entity. % used as a building block. %The term component, in American English, can mean a building block or a part. %In British-English a component generally is given to mean the definition for part above. -We define {\bc} to be the lowest level---or entities we begin with in our analysis---of component that we use as a building block. +We define {\bc} to be the lowest level---an entity with which we begin our analysis---of component that we use as a building block. This is a choice made by the analyst, often guided by the standards to which the analysis is being performed. % to. % Both op-amps and transistors have published statistical failure rates and yet an op-amp is constructed from transistors. @@ -1181,7 +1185,7 @@ structure with its associated failure modes. % From this diagram we see that each component must have at least one failure mode. To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component, -each failure mode is referenced back to only one component. This constraint is discussed in section~\ref{sec:unitarystate}. +each failure mode is referenced back to only one component. This constraint is discussed in detail in section~\ref{sec:unitarystate}. %%-%% MTTF STATS CHAPTER MAYBE ?? %%-%% @@ -1313,13 +1317,15 @@ Initial {\fgs} will consist of {\bcs}. % All the failure modes of all the components within a {\fg} are collected. % -As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes. +As each component %mode holds +has a set of failure modes associated with it, +the {\fg} represents a set of sets of failure modes. % We convert this into a flat set of failure modes for use in analysis. % -A flat set is a set containing just failure modes and not sets of failure modes~\cite{joyofsets}[p.8]. +A flat set is a set containing just the failure modes and not sets of failure modes~\cite{joyofsets}[p.8]. % %In practical term each component failure mode is considered as a `failure~scenario' or 'test~case' %for the {\fg}. @@ -1414,7 +1420,8 @@ with the op-amp. This {\fg} is now analysed and a {\dc} created to represent the failure mode behaviour of the {\em INVAMP}. An analysis report is generated for each {\fg} to {\dc} -process. +process\footnote{By having an analysis report report for each analysis stage, i.e. {fg} to {\dc}, +we increase the tracability in the reasoning applied to to the FMEA process.}. % We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}. @@ -1454,7 +1461,7 @@ Because {\fgs} may include components at varying levels of $\abslev$, having it quickly available as an attribute will be required in practical implementations to order the tree, and prevent recursion in the hierarchy. - +The abstraction level concept is formally defined in section~\ref{sec:abstractionlevel}. % \section{Set Theory Description} % @@ -1522,7 +1529,7 @@ make up and thus define the {\fg}) associated with the {\dc}. \begin{figure}[h] \centering - \includegraphics[width=400pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png} + \includegraphics[width=300pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png} % cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464 \caption{Complete UML diagram} \label{fig:cfg2} diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index 70462d1..4b81699 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -42,9 +42,11 @@ four op-amp stages with supporting components. Section~\ref{sec:sigmadelta} shows FMMD analysing the sigma delta analogue to digital converter---which operates on both analogue and digital signals. % -Finally section~\ref{sec:Pt100} demonstrates both statistical +Sections~\ref{sec:Pt100}~and~\ref{sec:Pt100d} demonstrate both statistical failure mode classification % analysis for top level events traced back to {\bc} failure modes and the analysis of double simultaneous failure modes. +% +Finally section~\ref{sec:elecsw} demonstrates FMMD analysis of a combined electronic and software system. % \section{Basic Concepts Of FMMD} % @@ -3014,7 +3016,7 @@ conditions. %\clearpage \section{ Pt100 Double Simultaneous Fault Analysis} - +\label{sec:Pt100d} In this section we examine the failure mode behaviour for all single faults and double simultaneous faults. This corresponds to the cardinality constrained powerset of one (see section~\ref{ccp}), of @@ -3375,7 +3377,7 @@ 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 failure modes, and later what a failure symptoms. +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 @@ -3396,7 +3398,7 @@ post-conditions (constraints on its outputs) and function wide invariants (rules 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'. @@ -3409,8 +3411,8 @@ Post conditions could be either actions performed (i.e. the state of hardware \paragraph{Mapping contract `invariant' violations to symptoms and failure modes.} -Invariants in contract programming may apply to inputs to the function (where they can be considered {\fms} in FMMD terminology), -and to outputs (where they can be considered {failure symptoms} in FMMD terminology). +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} @@ -3422,11 +3424,14 @@ 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 a an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20] +{\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 +%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 easy to detect as an error condition rather than an incorrect value. % @@ -3906,15 +3911,16 @@ 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. +reasoning stage. AEach 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. - +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 seperate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea} We now have a {\dc} for a {\ft} input in software. @@ -3929,7 +3935,7 @@ 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. +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. diff --git a/submission_thesis/CH7_Conclusion/copy.tex b/submission_thesis/CH7_Conclusion/copy.tex index 2f8dd2a..44cda5f 100644 --- a/submission_thesis/CH7_Conclusion/copy.tex +++ b/submission_thesis/CH7_Conclusion/copy.tex @@ -58,7 +58,7 @@ Functional groupings by definition implement functionality, or purpose, and ther operational states.% with. \paragraph{Inhibit Conditions.} -A third data class may be required if modelling of inhibit conditions~\cite{nasatfa}[p.40] is desired. +A third data class may be required if modelling of inhibit conditions~\cite{nasafta}[p.40] is desired. Some failure modes may only be active given specific environmental conditions or when other failures are already active. To model this, an `inhibit' class has been added. diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex index c59a3ee..c2ae1e4 100644 --- a/submission_thesis/appendixes/algorithmic.tex +++ b/submission_thesis/appendixes/algorithmic.tex @@ -645,6 +645,7 @@ as a component with a known set of failure modes. \paragraph{Enumerating abstraction levels} +\ref{sec:abstractionlevel} We can assign an attribute of abstraction level $\abslev$ to components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). For a base component, let the abstraction level be zero.