diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 696f031..b1e42d7 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -170,7 +170,7 @@ decide which interactions are important. Let N be the number of components in our system, and K be the average number of component failure modes (ways in which the component can fail). The total number of base component failure modes -is $N \times K$. To examine the affect that one failure mode has on all the other components +is $N \times K$. To examine the effect that one failure mode has on all the other components will be $(N-1) \times N \times K$, in effect a set cross product. @@ -189,7 +189,7 @@ be typical of a very simple temperature controller, with a micro-controller sens we have $99 \times 100 \times 2.5 \times 10 = 247500 $. To look in detail at a quarter of a million test cases is obviously impractical. -If we were to consider multiple simultaneous failure modes +If we were to consider multiple simultaneous failure modes, we have yet another complication cross product. For instance for looking at double simultaneous failure modes, @@ -495,7 +495,7 @@ and its international analog standard IOC5108. \item It should be re-usable, in that commonly used modules can be re-used in other designs/projects. \item It should have a formal basis, that is to say, it should be able to produce mathematical proofs for its results, such as system level error causation trees, reliability and safety statistics. -\item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one). +\item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one). \item From the top down, the failure mode model should follow a logical de-composition of the functionality to smaller and smaller functional modules \cite{maikowski}. \item Multiple failure modes may be modelled from the base component level up. @@ -523,18 +523,19 @@ in \cite{maikowski}. This top down technique de-composes by functionality. Simpler and simpler functional blocks are discovered as we delve further into the way the system works and is built. -\paragraph{Design Decision: Methodology must be bottom-up.} -In order to ensure that all component failure modes are handled, -this methodology must start at the bottom, with base component failure modes. -In this way automated checking can be applied to all component failure modes -to ensure none have been inadvertently excluded from the process. \paragraph{Need for a `bottom-up' system de-composition} There is an apparent conflict here. The natural way to de-compose a system is from the top down. % +If we do this though, we do not naturally include +all failure modes in the modules determined as we +de-compose downwards. +% What is required here is to mimic this top-down de-composition with a bottom up technique. +By doing that, we can take all base component failure modes +and ensure they are included in the model. By taking components that form {\fg}s from the bottom up and then taking those to form higher level @@ -547,6 +548,11 @@ A second justification for this is that the design process for a product require thinking. To analyse a system from the bottom-up is a useful design validatio process in itself \cite{sommerville}. +\paragraph{Design Decision: Methodology must be bottom-up.} +In order to ensure that all component failure modes are handled, +this methodology must start at the bottom, with base component failure modes. +In this way automated checking can be applied to all component failure modes +to ensure none have been inadvertently excluded from the process. \paragraph{Problem with functional group hierarchy} A hierarchy of functional grouping, leading to a system model @@ -568,10 +574,16 @@ For instance a failed resistor in a sensor at a base component level is a specif failure mode. % For example it could be called `RESISTOR 1 OPEN'. -Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract -or in other words describe the effect more generally. % -We might call it `READING~HIGH' perhaps. At a higher level still +Now consider the symptom in a functional group comprising the sensor channel that +RESISTOR 1 is part of of `RESISTOR 1 OPEN'. +% +We might call it `READING~HIGH' failure perhaps. +The Fault has become less detailed and more general. There may be other +causes for a `READING~HIGH'. We can say that the failure +mode `READING~HIGH' is more abstract in terms of the STSEM, than `RESISTOR 1 OPEN'. +% +At a higher level still this may be called `SENSOR CHANNEL 1' fault. At a system level it may simply be a `SENSOR FAILURE'. As we traverse up the fault tree the failure modes @@ -613,7 +625,7 @@ failure mode behaviour, but can check that all failure modes in the hierarchy have been considered and tied to causing symptoms. -\paragraph{Incremental Stages and \dcs}. +\paragraph{Incremental Stages and \dcs .} We can use incremental stages to build the hierarchy. We can take small {\fg}s of components, where the {\fg} is a small set of components that perform a simple @@ -635,7 +647,7 @@ are the same failure w.r.t. the {\fg}. % We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes. % -We can now create a new {\dc} and assign it these common symptoms +We can now create a new/{\dc} and assign it these common symptoms as its failure modes. % This {\dc} can be used to build higher level @@ -645,12 +657,38 @@ an entire system. It can be considered complete when all failure modes from all components are handled and connectable to a SYSTEM level failure mode. -\paragraph{Directed Acyclic Graph.} This will naturally form a DAG -meaning that for all SYSTEM failure modes, we will be able to trace -back through the DAG to possible component failure mode causes. +\paragraph{Directed Acyclic Graph (DAG).} +The data structure produced from collecting functional groups +and deriving components will naturally form a DAG. +To ensure this we will have to ensure that +derived components cannot be included in {\fg}s +of a lower abstraction level. +% +% +By representing the failure mode model as a DAG, we +now have the capability to take SYSTEM level failure modes +and determine the possible combinations of component failure modes that +could have caused it. +In FTA terminology, a list of possible +causes for a SYSTEM level failure is known as a minimal cut set \cite{nasafta}. +% +% If statistical models exist for the component failure modes these failure causation trees (or minimal cut sets \cite{nucfta}) can be used to calculate Mean Time to Failure (MTTF) or Probability of Failure on demand (PFD) figures. +Constract the analytical capability of this with the +methodologies where the component failure modes are linked +directly to SYSTEM failure modes with no analysis stages in between. + + + +\paragraph{Design Decision: A functional group cannot contain {\dc}s at a higher abstraction level than its self} + +We can implement this rule in two ways, firstly, by saying that any functional group +will take the `abstraction level + 1' of all components it includes. +Secondly we can say that no component may be derived from itself. + +\paragraph{Natural Reduction in number of failure modes with abstraction level} % Because common symptoms are being collected, as we build the tree up-ward the number of failure modes decreases (or exceptionally stays the same) at each level.