diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 168021e..6ee7e2e 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -176,8 +176,8 @@ Tracing a component level failure up to a top level event, without the rigour ac working heuristically. A base component failure will typically be conceptually removed by several stages from a top level event. %In electronics terms, all components on the signal path from the component that failed. -The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components -that must interact to reach the top level event. +The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components +that must interact along the signal path to reach the top level event. Where $C$ represents the set of components in a failure mode causation chain, $c_i$ represents a component in $C$ and the function $fm$ returns the failure modes for a given component, equation @@ -192,8 +192,8 @@ to consider to rigorously determine the causation chain from the base component failure to the system level event. % The reasoning distance serves to show that when the causes of a top level -event are completely determined, a large amount of work not -typical of heuristic or intuitive interpretation is required. +event are completely determined, a large amount of work, not +typical of heuristic or intuitive interpretation, is required. Reasoning distances will be large for complicated systems, and this is therefore a weakness in both FMEA and FTA type analyses. This concept is developed further to create a metric for comparing @@ -223,7 +223,7 @@ introduce automation into the FMEA process~\cite{appswfmea} and code analysis automation~\cite{modelsfmea}. Performing these analyses separately breaks the reasoning chain for tracing failure causation through the software hardware interfaces. -Although the SFMEA and hardware FMEAs are performed separately +Although the SFMEA and hardware FMEAs are performed separately, some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive) to be performed on the same system to provide insight into the software hardware/interface~\cite{embedsfmea}. @@ -371,7 +371,7 @@ from the results of the {\fcs}. Because it is possible to model combinations of criterion 6 is satisfied. % With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}. -The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from. +The failure modes of this new {\dc} are the symptoms of the {\fg} from which it was derived.% from. This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed modules available for re-use. @@ -520,7 +520,7 @@ and determine how they affect the operation of the potential divider. For this example we look at single failure modes only. -For each failure mode in our {\fg} `potential~divider' +For each failure mode in our {\fg} `potential~divider', we can assign a {\fc} number (see table \ref{tbl:pdfmea}). Each {\fc} is analysed to determine the `symptom' of the potential dividers' operation. For instance @@ -553,7 +553,7 @@ gives a high voltage output.%We can now consider the {\fg} \vbox{ -From table \ref{pdfmea} we can see that the resistor +From table \ref{tbl:pdfmea} we can see that the resistor failures modes lead to some common symptoms. By drawing directed edges, from the failure modes to the symptoms we can show the relationships between the component failure modes and resultant symptoms. @@ -607,7 +607,7 @@ This is represented in the DAG in figure \ref{fig:fg1adag}. We can now make a `derived component' to represent this potential divider. This can be named \textbf{PD}. This {\dc} will have two failure modes. -We can use the symbol $\derivec$ to represent taking the analysed +We can 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}. @@ -885,8 +885,9 @@ This model now has two stages of analysis hierarchy, as represented in figure~\r We can now expand the $PD$ {\dc} and have a full FMMD failure %mode model -drawn as a DAG, which we can use to traverse to determine the possible causes to +drawn as a DAG, which we can use traverse, and thus determine all possible causes to the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier. +% Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies. @@ -947,7 +948,7 @@ defines a `part' thus This definition of a `part' is useful, but consider combinatorial parts, such as quad packaged op-amps. Here we have four op-amps on one chip. For FMEA we would consider each op-amp in the package as a separate building block for a circuit. -We in fact need to go a little further than the above definition of a part, +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. @@ -1240,7 +1241,7 @@ and from this determine the failure modes of all the components that belong to i %The analysts interest is in the ways in which the components within the {\fg} %can fail. % -All the failure modes of all the components within an {\fg} are collected. +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. We convert this into a flat set @@ -1269,13 +1270,13 @@ and collecting symptoms of failure, is termed `symptom abstraction'. } { This -is dealt with in detail using an algorithmic description, in section \ref{sec:symptom_abstraction}. +is dealt with in detail using an algorithmic description, in section \ref{sec:algorithmfmmd}. } % define difference between a \fg and a \dc A {\fg} is a collection of components, a {\dc} is a new `theoretical' -component which has a set of failure modes, which -corresponds to the failure symptoms from the {\fg} from which it was derived. +component which has a set of failure modes, +corresponding to the failure symptoms from the {\fg} from which it was derived. % We consider a {\dc} as a black box, or component for use. @@ -1329,13 +1330,13 @@ The lowest level in this hierarchy are the {\bcs}, the resistors and the op-amp. % The resistors are collected into a {\fg}, and the ${PD}$ derived component is created above them. % -As this derived component inherits the properties of a component we may use +As this derived component inherits the properties of a component, we may use it in {\fg} higher in the hierarchy. % The $PD$ derived component is now placed into a functional group with the op-amp. % -This {\fg} is now analysed and the a {\dc} created to +This {\fg} is now analysed and a {\dc} created to represent the failure mode behaviour of the $INVAMP$. % We may now use the $INVAMP$ {\dc} in even higher level {\fgs}. @@ -1404,20 +1405,22 @@ as a data structure. The `parts~list' is the key reference point and starting point. % in the data structure. Our base components are kept here. -From these the initial {\fgs} are formed, and from the first {\fgs} +From these the initial {\fgs} are formed, and from the first {\fgs}, the first {\dcs}. Two other data types/entities are required however: we need to model environmental and operational states and where they fit into the data structure. A system will be expected to perform in a given environment. +% Environment in the context of this study -means external influences the System could be expected to work under. +means external influences under which the System could be expected to work.% under. +% A typical data sheet for an electrical component will give -a working temperature range for instance. +a working temperature range, for instance. Mechanical components could be specified for stress and loading limits. -Systems or sub-systems may have distinct operational states. For instance a safety critical controller +Systems or sub-systems may have distinct operational states. For instance, a safety critical controller may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until authorised human intervention takes place. A safety critical circuit may have a self test mode. @@ -1438,7 +1441,7 @@ With given environmental constraints, we can therefore eliminate some failure mo \paragraph{Operational states.} Within the field of safety critical engineering, we often encounter -sub-system that include test or self-test facilities. +sub-systems that include test or self-test facilities. % We also encounter degraded performance (such as only performing functions in an emergency) and lockout conditions. @@ -1536,10 +1539,13 @@ The symptom abstraction process must always raise the abstraction level for the newly created {\dc}. Using $\abslev$ (as described in~\ref{sec:alpha}) to symbolise the fault abstraction level, we can now state: -$$ \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. $$ +\begin{equation} + \label{eqn:abslevinc} + \derivec({\FG}^{\abslev}) \rightarrow c^{{\abslev}+N} | N \ge 1. +\end{equation} \paragraph{Functional Groups may be indexed.} -We will typically have more than one {\fg} on each level of FMMD hierarchy (expect the top level where there will only be one). +We will typically have more than one {\fg} on each level of FMMD hierarchy (except the top level, where there will only be one). We index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index. For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy. @@ -1566,11 +1572,12 @@ failure modes being the failure symptoms of the {\fg} from which it was derived. %A new {\dc} is created %where its failure modes, are the symptoms from {\fg}. % -Note that the component must have a higher abstraction level than the {\fg} -it was derived from. +Note that the {\dc} must have a higher abstraction level than the {\fg} +from which it was derived---or---in other words, the symptom abstraction process `$\derivedc$' increments +the abstraction level $abslev$, as stated in equation~\ref{eqn:abslevinc}. The symptom abstraction process is described formally and algorithmically -in sections~\ref{sec:formalfmmd} and \ref{algotithmfmmd} respectively. +in sections~\ref{sec:formalfmmd} and \ref{sec:algorithmfmmd} respectively. \paragraph{Surjective constraint applied to symptom collection.} @@ -1591,7 +1598,7 @@ the number of symptoms is guaranteed to be less than or equal to the number of component failure modes. This means the top level {\dc} in a hierarchy should have a number of {\fms} less than or equal to the sum of {\fms} in its base components. -In practise however, the number of symptoms greatly reduces as we traverse +In practise, however, the number of symptoms greatly reduces as we traverse up the hierarchy. This is echoed in real life systems, where the top level events/failures are always orders of magnitude smaller than sum of {\fms} in its base components. @@ -1726,8 +1733,8 @@ with failure mode $b$. We can express this as $c_2 a \cup c_1 b$. From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined. How do we model the double failures that occur across the {\fgs}, for instance -$c_4 a \cup c_1 a$. -It could be argued that because functional groups are chosen for their functionality, and re-usability +$c_4 a \cup c_1 a$ where $c_4 a$ is a failure mode in FG1 and $c_1 a$ from FG2. +It could be argued that because functional groups are chosen for their functionality, and re-usability, that component failures in one should not affect a different {\fg}, but this is a weak argument. Merely double checking within {\fgs} would be marginally better than only applying it to the most obvious critical elements of a system. @@ -1747,7 +1754,7 @@ double simultaneous combinations have not been resolved. % By applying double simultaneous checking until no single failures can lead to a top level event, we -double failure move coverage. +implement traceable and provable, complete double failure mode coverage. To extend the example in figure~\ref{fig:dubsim1} we can map the failure scenarios. @@ -1778,7 +1785,7 @@ Thus a derived component, DC2, has the failure modes defined by $fm(DC2) = \{ S4 and these are the result of considering double simultaneous failures of its components. A commonly used temperature measuring circuit, the $Pt100$, is analysed -for double simultaneous failure analysis in section~\ref{sec:pt100}. +for double simultaneous failure analysis in section~\ref{sec:Pt100}. A software tool tracking the analysis process could check that all possible single and double @@ -1837,7 +1844,10 @@ component level failure modes. % This allows cut sets~\cite{nasafta}[Ch.1p3] to be determined by traversing the DAG from top level events down to their causes. - +% +This has the added advantage of each {\fg} to {\dc} stage being a documented +failure mode reasoning entity. Compare this to traditional FMEA where +we only have one stage, base component failure mode to top level event. % \item{ It should be capable of producing reliability and danger evaluation statistics.} % The minimal cuts sets for the system level failures can have computed MTTF diff --git a/submission_thesis/appendixes/formal.tex b/submission_thesis/appendixes/formal.tex index 8ef453e..83436ec 100644 --- a/submission_thesis/appendixes/formal.tex +++ b/submission_thesis/appendixes/formal.tex @@ -3,7 +3,7 @@ \chapter{Formal Definitions} -\label{formalfmmd} +\label{sec:formalfmmd} \section{An algebraic notation for identifying FMMD enitities} Consider all `components' to exist as members of a set $\mathcal{C}$.