diff --git a/papers/fmmd_software_hardware/software_fmmd.tex b/papers/fmmd_software_hardware/software_fmmd.tex index aaf91ec..c3141e7 100644 --- a/papers/fmmd_software_hardware/software_fmmd.tex +++ b/papers/fmmd_software_hardware/software_fmmd.tex @@ -121,7 +121,7 @@ failure mode of the component or sub-system}}} % {-\baslineskip} % {0.5\baselineskip} % {\normalfont\normalsize\itshape}}% -\linespread{0.95} +\linespread{0.953} \begin{document} %\pagestyle{fancy} @@ -290,7 +290,7 @@ In order to integrate software, %in a meaningful way we need to re-think the FMEA concept of simply mapping a base component failure to a system level event. % -One strategy would be to modularise FMEA. To break down the failure effect +One strategy would be to modularise FMEA; to break down the failure effect reasoning into small modules from the bottom-up. % If we pre-analyse modules, and they @@ -363,13 +363,14 @@ we can determine its symptoms of failure. %With these symptoms (a set of derived faults from the perspective of the {\fg}) %we can now state that the {\fg} % (as an entity in its own right) -can fail in a number of well defined ways. +%can fail in a number of well defined ways. % In other words we have taken a {\fg}, and analysed how %\textbf{it} it can fail according to the failure modes of its components, and then determine the {\fg} failure symptoms. -We then create a new {\dc} which has as its {\fms} the failure symptoms +% +We then create a new {\dc} which has as its {\fms}, the failure symptoms of the {\fg} from which it was derived. % \paragraph{Creating a derived component.} @@ -1061,7 +1062,7 @@ shows that by taking a modular approach for FMEA, i.e. FMMD, we can integrate software and electro-mechanical models. % With this analysis -we have stages along the `reasoning~path' linking the failures modes from the +we have stages along the `reasoning~path' linking the failure modes from the electronics to those in the software. Each {\fg} to {\dc} transition represents a reasoning stage.