.

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -727,10 +727,91 @@ such as Bayes theorem~\cite{probstat}.
 %%-
 \section{Complete UML Diagram}
 
+For a complete UML data model we need to consider the System
+as an object. This holds a parts list, and is the 
+key reference point in the data structure.
+
+A real life 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.
+A typical data sheet for an electrical component will give 
+a working temperature range for instance.
+Mechanical components will be specified for stress and loading limits.
+
+\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
+levels of electrical interference, high voltage contamination on supply
+lines, radiation levels etc.
+Environmental influences will affect specific components in specific ways.
+Environmental analysis is thus applicable to components.
+\paragraph{Operational states.}
+Within the field of safety critical engineering we often encounter 
+sub-system that include test facilities. We also encounter degraded performance
+(such as only performing functions in an emergency) and lockout conditions.
+These can be broadly termed operational states, and apply to the 
+functional groups.
+Consider for instance an electrical circuit that has a TEST line.
+When the TEST line is activated, it supplies a test signal
+which will validate the circuit. This circuit will have two operational states,
+NORMAL and TEST mode.
+
+It is natural to apply the operational states to functional groups.
+Functional groups by definition implement functionality, or purpose
+of particular sub-systems, and therefore are the best objects to model
+operational states.
+
+\paragraph{UML Diagram Additional Objects.}
+The additional objects System, Environment and Operational States
+are added to  UML diagram in figure \ref{fig:cfg} and represented in figure \ref{fig:cfg2}.
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,keepaspectratio=true]{./component_failure_modes_definition/cfg2.jpg}
+ % cfg2.jpg: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
+ \caption{Complete UML diagram}
+ \label{fig:cfg2}
+\end{figure}
+
+
+
 \section{From UML Model to Data Model}
+
+HERE should how the hierarchy is built, how the inheritance works etc
+
+HAVE an example. totally theoretical. HAVE Common mode failure detection AND Common dependency detection
+
 \subsection{Directed Acyclic Graph}
+
+Show how the hierarchy can be represented as a DAG
+
+draw a dag
+
 \subsection{Traversing the datamodel}
+
+Show how we can find multiple causes for a SYSTEM level error
+
 \subsubsection{Common mode failure detection}
+
+Describe what a common mode failure is.
+
+show how common mode failures can be detected by using the parts list (same components can all have their
+error modes turned on, and the effect can be seen on the system, automatically tracing
+common mode failures.
+
+
 \subsubsection{Common dependency detection}
 
-\vspace{40pt}
+The same component can be relied on by different functional groups within a system
+For instance a power supply spur (i.e. supplying a particular isolated voltage say)
+could have many functional groups depending or linked to its failure modes.
+
+Show how FMMD makes this tracable
+
+
+% clear the page if its a paper to keep the diagram out of the references
+\ifthenelse {\boolean{paper}}
+{
+\clearpage
+}
+{
+}