Going thourgh data model UML to DAG

rough draft still
This commit is contained in:
Robin Clark 2010-11-25 20:55:26 +00:00
parent b6f483e323
commit aa91580e16
3 changed files with 41 additions and 39 deletions

View File

@ -8,10 +8,13 @@
%% What I have done
%%
This paper presents a simple two stage Failure Mode Modular De-Composition (FMMD)
This paper presents a simple two level Failure Mode Modular De-Composition (FMMD)
model of a theoretical System.
The Analysis model is then represented as a Directed Acyclic Graph (DAG), of the {\fg}s
components and failure modes represented in it.
Firstly a UML model is presented and the class relationships described.
Secondly the theoretical model is developed and analysed.
This model is then represented as a Directed Acyclic Graph (DAG),
showing the data relationships between the {\fg}s
components and failure modes.
% What I have found
%%
@ -22,12 +25,12 @@ can also be automatically determined.
%% Sell it
%%
By having a clear data model, we can not only produce results
for the traditional methodologies, we can trace common mode and
component dependency failures as well.
By having an FMMD data model, we can derive failure mode models
for the traditional methodologies (such as FMEA, FMECA, FMEDA and FTA).
Also, with statistical data, we can use the minimal cut set results
to determine the likelihood of particular system failures, even
if they have multiple causes.
%
} % abstract
} % ifthenelse
{
@ -49,9 +52,8 @@ can also be automatically determined.
%% Sell it
%%
By having a clear data model, we can not only produce results
for the traditional methodologies, we can trace common mode and
component dependency failures as well.
By having an FMMD data model, we can derive failure mode models
for the traditional methodologies (such as FMEA, FMECA, FMEDA and FTA).
Also, with statistical data, we can use the minimal cut set results
to determine the likelihood of particular system failures, even
if they have multiple causes.
@ -62,18 +64,23 @@ if they have multiple causes.
\section{From UML Model to Object Model}
Let us consider a theoretical FMMD model. For the sake of simplicity
consider that all components and functional groups have only two failure modes that
consider that all base~components have %only
two failure modes that
we will label $a$ and $b$.
We can start with some base components, of types C and K say, $\{ C_1, C_2, C_3, K_4, C_5, C_6, K_7 \}$.
\input{./shortfm}
\paragraph{Determing Failure Mode collections.}
Thus applying the function $fm$ to any of the components
gives error modes identified by a or b.
For the sake of example, let us say that each component has two failure
As each component has two failure
modes $a$ and $b$. So the function $fm$ applied to
$C_1$ yields $C_{1 a}$ and $C_{1 b}$:
i.e. $fm(C_1) = \{ C_{1 a}, C_{1 b} \}$.
HOW UML OBJECT MODEL OF COMPONENT AND ITS ERROR MODES
%HOW UML OBJECT MODEL OF COMPONENT AND ITS ERROR MODES
\ifthenelse {\boolean{paper}}
{
@ -89,17 +96,17 @@ $$ FG^0_1 = \{C_1, C_2\},$$
$$ FG^0_2 = \{C_1, C_3, K_4\},$$
$$ FG^0_3 = \{C_5, C_6, K_7\}.$$
Note that in this model the base~component $C_1$ has been used in
two separate functional groups. This could be a component that they
Note that in this model the base~component $C_1$ has been used in two separate functional groups.
This could be a component that they
both commonly use. A real world example of a component included in
more than one {\fg} could
be a powersupply or DCDC\footnote{A DCDC (direct current to direct current)
be a power-supply or DCDC\footnote{A DCDC (direct current to direct current)
converter, is a common feature in modern PCBs, used to provide isolation
and/or voltage supplies at a different EMF from the source of power.}
converter shared to power
the functional groups $FG^0_1$ and $FG^1_1$.
Also that the component type $K$ has been used by
Also note that the component type $K$ has been used by
two different functional groups.
For the sake of example let our temperature environment
@ -117,14 +124,15 @@ A processes of symptom extraction is now applied to the functional groups.
Again for the sake of example, let us say that each functional
group has one or two symptoms again subscripted by $a$ and $b$.
Applying symptom abstraction to $FG^0_1$ i.e. $\bowtie fm ( FG^0_1 ) = \{ FG^0_{1 a}, FG^0_{1 b} \} $
We can now create a new derived component, $DC^1_1$, whose failure
modes are the symptoms of $FG^0_1 $ thus $ fm ( {DC}^1_1 ) = \{ FG^0_{1 a}, FG^0_{1 b} \} $.
%Applying symptom abstraction to $FG^0_1$ i.e. $\bowtie fm ( FG^0_1 ) = \{ FG^0_{1 a}, FG^0_{1 b} \} $
%We can now create a new derived component, $DC^1_1$, whose failure
%modes are the symptoms of $FG^0_1 $ thus $ fm ( {DC}^1_1 ) = \{ FG^0_{1 a}, FG^0_{1 b} \} $.
\paragraph{Building the Object Model}
Using the UML model in figure \ref{fig:cfg2fmmd_data} we will apply FMMD analysis stages
to build a hierarchy representing the whole system, begining with the $FG^0$ level functional groups.
Using the UML model in figure \ref{fig:cfg2fmmd_data}, we apply FMMD analysis stages
to build a hierarchy representing the whole system.
We shall begin with the $FG^0$ level functional groups $ FG^0_1, FG^0_2 $ and $FG^0_3$ defined above.
\begin{figure}[h]
\centering
@ -147,22 +155,13 @@ to build a hierarchy representing the whole system, begining with the $FG^0$ lev
Consider the SYSTEM environment with its temperature range of ${{0}\oc}$ to ${{125}\oc}$.
We must check this against all components used.
For our example, we component `K' which has an extra
failure mode for degraded performance `d'.
\ifthenelse {\boolean{paper}}
{
We can definine a `failure modes' function $fm$ that has a functional group as its range
and returns a set of failure modes as its domain.
We now use this to determine the failure modes
in our functional groups.
}
{
Using the overloaded function $fm$ from chapter \ref{fmdef} we can determine the failure modes
in our functional groups.
}
failure mode for degraded performance `d'. Thus applying the function $fm$
to component type `K' under these temperature range conditions
give the foillowing failure modes, $fm{K} =\{ K_a, K_b, K_d \}$.
Were our system specified for a ${{0}\oc}$ to ${{80}\oc}$ range
we could say $fm{K} =\{ K_a, K_b \}$.
\paragraph{Get the failure modes from the functional groups.}
Applying the function $fm$ to our functional groups, with the SYSTEM environmental
constraint applied to component type `K', yields
@ -177,7 +176,9 @@ $$ fm(FG^0_3) = \{C_{5 a}, C_{5 b}, C_{6 a}, C_{6 b}, K_{7 a}, K_{7 b}, K_{7 d}\
The next stage is to look at the failure modes from the perspective of
the functional groups, rather than the components.
We can call these failures modes `symptoms'.
As this is a theoretical example, we shall have to skip this step.
As this is a theoretical example, we shall have to skip this step\footnote{
In a real analysis this would involve evaluating the effect of each components failure mode, (or combinations of)
on the performance of the {\fg}.}.
The next stage is to collect the common symptoms, or the symtoms that
are the same {\em from the perspective of a user of the {\fg}}.
We can define this stage as the function $\bowtie$ which has a set of failure modes as
@ -229,7 +230,7 @@ UML OBJECT MODEL OF DERIVED COMPONENT TOO
\pagebreak[4]
\subsection{Using Derived Components in Functional Groups}

View File

@ -1,5 +1,6 @@
\ifthenelse {\boolean{paper}}
{
\paragraph{Failure Mode function $fm$.}
We can definine a `failure modes' function $fm$ that has a functional group as its range
and returns a set of failure modes as its domain.
We now use this to determine the failure modes