functional group guidelines and reasoning
This commit is contained in:
parent
f45896b222
commit
6265054530
@ -321,7 +321,7 @@ In practise, this following to all components on the signal path, will not be do
|
||||
Typically simpler scenarios will be used where the effect of
|
||||
the component failure will be considered in isolation and then applied to the signal path.
|
||||
|
||||
\paragraph{Reasoning distance - complexity and reach-ability.}
|
||||
\paragraph{Concept of `reasoning distance' - complexity and reach-ability.}
|
||||
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
|
||||
working heuristically. A base component failure will typically
|
||||
be conceptually removed by several stages from a top level event.
|
||||
@ -1135,9 +1135,9 @@ failure modes and environmental factors.
|
||||
|
||||
|
||||
|
||||
\subsection{Justification of wishlist}
|
||||
\subsection{Justification of desirable requirements}
|
||||
|
||||
By applying the methodology in section \ref{fmmdproc}, the wishlist can
|
||||
By applying the methodology in section \ref{fmmdproc}, the desirable requirements can
|
||||
now be evaluated for the proposed FMMD methodology.
|
||||
|
||||
\subsubsection{All component failure modes must be considered in the model.}
|
||||
@ -1335,6 +1335,14 @@ The terms used in FMMD and the UML data model are further refined in
|
||||
chapter \ref{defs}.
|
||||
}
|
||||
|
||||
\section{The {\fg}: discussion and guidelines}
|
||||
|
||||
Talk about reasons why {\fgs} should be small but complete enough
|
||||
to perform a given function.
|
||||
If they become too big we have a state explosion problem.
|
||||
If too small they become meaningless. PD is a good example of this
|
||||
appropriate for most situations, but perhaps getting confusing if applied to a non inverting op-amp gain stage.
|
||||
|
||||
\section{Conclusion}
|
||||
|
||||
This
|
||||
|
Loading…
Reference in New Issue
Block a user