get the grammar and speeling off mum this morning
This commit is contained in:
parent
770c27d88f
commit
0176ed4a81
@ -76,7 +76,7 @@ structure with its associated failure modes.
|
|||||||
|
|
||||||
From this diagram we see that each component must have at least one failure mode.
|
From this diagram we see that each component must have at least one failure mode.
|
||||||
Also to clearly show that the failure modes are unique events associated with one component,
|
Also to clearly show that the failure modes are unique events associated with one component,
|
||||||
each failure mode being referenced back to only one component.
|
each failure mode is referenced back to only one component.
|
||||||
This modelling constraint is due to the fact that even generic components with the same
|
This modelling constraint is due to the fact that even generic components with the same
|
||||||
failure mode types, may have different statistical MTTF properties within the same
|
failure mode types, may have different statistical MTTF properties within the same
|
||||||
circuitry\footnote{For example, consider resistors one of high resistance and one low.
|
circuitry\footnote{For example, consider resistors one of high resistance and one low.
|
||||||
@ -110,6 +110,10 @@ parts~numbers\footnote{It is common practise for sub assemblies, PCB's, mechanic
|
|||||||
software modules and some collections of components to have part numbers}, and will
|
software modules and some collections of components to have part numbers}, and will
|
||||||
not require a vendor reference, but must be named.
|
not require a vendor reference, but must be named.
|
||||||
|
|
||||||
|
We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis.
|
||||||
|
When modularising a system from the top~down, as in Fault Tree Analysis (FTA)
|
||||||
|
it is common to term the modules identified as sub-systems.
|
||||||
|
When building from the bottom up, it is more meaningful to term the `sub-systems' as `derived~components'.
|
||||||
|
|
||||||
|
|
||||||
%%
|
%%
|
||||||
@ -378,7 +382,7 @@ and S itself.
|
|||||||
In order to consider combinations for the set S where the number of elements in each sub-set of S is $N$ or less, a concept of the `cardinality constrained powerset'
|
In order to consider combinations for the set S where the number of elements in each sub-set of S is $N$ or less, a concept of the `cardinality constrained powerset'
|
||||||
is proposed and described in the next section.
|
is proposed and described in the next section.
|
||||||
|
|
||||||
\pagebreak[1]
|
%\pagebreak[1]
|
||||||
\subsection{Cardinality Constrained Powerset }
|
\subsection{Cardinality Constrained Powerset }
|
||||||
\label{ccp}
|
\label{ccp}
|
||||||
|
|
||||||
@ -486,6 +490,7 @@ $$
|
|||||||
$$
|
$$
|
||||||
|
|
||||||
|
|
||||||
|
\pagebreak[1]
|
||||||
\subsubsection{Establishing Formulae for unitary state failure mode \\
|
\subsubsection{Establishing Formulae for unitary state failure mode \\
|
||||||
cardinality calculation}
|
cardinality calculation}
|
||||||
|
|
||||||
@ -531,7 +536,7 @@ By knowing how many test cases should be covered, and checking the cardinality
|
|||||||
associated with the test cases, complete coverage would be verified.
|
associated with the test cases, complete coverage would be verified.
|
||||||
|
|
||||||
|
|
||||||
\pagebreak[4]
|
\pagebreak[1]
|
||||||
\section{Component Failure Modes and Statistical Sample Space}
|
\section{Component Failure Modes and Statistical Sample Space}
|
||||||
%\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
%\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||||
A sample space is defined as the set of all possible outcomes.
|
A sample space is defined as the set of all possible outcomes.
|
||||||
|
Loading…
Reference in New Issue
Block a user