From d81ea97c01304ca3555ea6e5a08a10fb77f280bf Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 17 Jan 2011 11:23:05 +0000 Subject: [PATCH 1/5] Exponenial to polynomial complexity --- eulerg/eulerg.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/eulerg/eulerg.tex b/eulerg/eulerg.tex index 8425ac5..31d95df 100644 --- a/eulerg/eulerg.tex +++ b/eulerg/eulerg.tex @@ -330,5 +330,7 @@ The order of area operations is generally\footnote{In the case where the diagram reduced by requiring several $K.|P|.2^{|P|}$ instead of $N.2^N$ as $K < N$. +This has effectively reduced the order of the searching algorithm from exponential to polynomial order. + \vspace{40pt} From 554f584203fa63ba42352a6933aff36699d573ce Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 17 Jan 2011 14:09:59 +0000 Subject: [PATCH 2/5] lunch time proof read and edit --- fmmd_concept/fmmd_concept.tex | 38 +++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 8b9a2f5..f94e9dd 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -135,7 +135,8 @@ of components, {\fgs}, and then analysing how they can fail. \input{./shortfg} \paragraph{Micro Vs. Macro failure mode analysis.} -This analysis is performed using FMEA from a micro rather than a macro perspective. +The FMMD analysis is performed using failure mode effects analysis +from a micro rather than a macro perspective. Thus instead of looking at component failure modes and determining how they {\em may} cause a failure at SYSTEM level, we are looking at how they {\em will} affect the component's local {\fg}. @@ -198,7 +199,7 @@ and therefore human judgement must be used to decide which interactions could be important. Let N be the number of components in our system, and K be the average number of component failure modes -(ways in which the base~component can fail). The total number of base component failure modes +(ways in which a base~component can fail). The total number of base component failure modes is $N \times K$. To examine the effect that one failure mode has on all the other components\footnote{A base component failure will typically affect the sub-system it is part of, and create a failure effect at the SYSTEM level.} @@ -230,7 +231,8 @@ For instance looking at double simultaneous failure modes, where $\#C$ is the number of checks to perform the equation reads $\#C = (N-2) \times (N-1) \times N \times K \times E$. -The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them +The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes\footnote{Often component failures, rather than individual component +failure modes are used, making the analysis process less precise.} and link them to SYSTEM level failure modes. Because of the astronomical number of possible interactions, some valid ones are in danger of being missed, we can term this analysis as a `leap~of~faith' (i.e. leaping from from the @@ -273,9 +275,9 @@ Consequently it was not designed to guarantee to covering all component failure and has no rigorous in-built safeguards to ensure coverage of all possible system level outcomes. Also each system level error (or undesireable event) requires its own FTA tree. -This increase the amount of work to do, and in the case of updates to +This increases the amount of work to do, and in the case of updates to particular sub-systems, introduces the requirement to update every FTA -tree modelling that sub-system. +tree modelling that use the affected sub-system. \subsubsection{ FTA weaknesses } \begin{itemize} @@ -407,7 +409,8 @@ to succeeding to operate correctly on demand. } { FMEDA is a statistical analysis methodology and is used from one of two perspectives, -Probability of Failure on Demand (PFD) (see \ref{survey:pfd}), and Probability of Failure +Probability of Failure on Demand (PFD) (see \ref{survey:pfd}) +, and Probability of Failure in continuous Operation, or Failure in Time (FIT) (see \ref{survey:fit}). } @@ -420,7 +423,11 @@ Each component is analysed in terms of how its failure would affect the system. Failure rates of individual components in the SYSTEM are calculated based on component type and -environmental conditions. The SYSTEM errors are categorised as `safe' or `dangerous'. +environmental conditions. + +%The SYSTEM errors are categorised as `safe' or `dangerous'. + + % %Statistical data exists for most component types \cite{mil1992}. % @@ -457,7 +464,7 @@ based on heuristics or field data. \paragraph{Determine Detectable and Undetectable Failures.} Each safe and dangerous failure mode is now classified as detectable or un-detectable. -For the higher integrity levels, EN61508 assumes that products have a high proportion of +For the higher integrity levels, EN61508 requires that products have a high proportion of self checking features. % This gives us four level failure mode classifications: @@ -676,7 +683,7 @@ further into the way the system works and is built. \paragraph{Need for a `bottom-up' system de-composition.} -There is an apparent conflict here. The natural way to +There is an apparent conflict here as de-composition ormally implies a top-down approach. The natural way to de-compose a system is from the top down. % If we do this though, we do not naturally include @@ -716,8 +723,10 @@ The base components will typically have several failure modes each. Given a typical embedded system may have hundreds of components, this means that we would still have to tie base component failure modes to SYSTEM level errors. +% The problem with this is that the base component failure mode under investigation, -effects are not rigorously examined in relation to functionally adjacent components. +are not rigorously examined in relation to functionally adjacent components. +% Thus there is the `possibility to miss failure mode effects at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies. %%% @@ -798,6 +807,9 @@ In this way as we build the hierarchy, we naturally abstract the failure mode behaviour, but can check that all failure modes in the hierarchy have been considered and tied to causing symptoms. +\paragraph{Design Decision: Derived components can be determined from functional groups} +The symptoms obtained from analysing a {\fg} will be used as the `failure~modes' +of its corresponding {\dc}. \paragraph{Incremental Stages and \dcs .} We can use incremental stages to build the hierarchy. @@ -871,7 +883,7 @@ a SYSTEM level error this is usually considered a liability.}) can be used to calculate Mean Time to Failure (MTTF) or Probability of Failure on demand (PFD) figures. Contrast the analytical capability of FMMD with the -methodologies where the component failure modes are linked +methodologies where the component failure modes/components are linked directly to SYSTEM failure modes with no analysis stages in between. @@ -917,8 +929,8 @@ Functional groups are collections of components that work together to perform a simple function. % We can perform a failure mode effects analysis on each of the component failure -modes within a {\fg}. Because we can implement the process in software we can -thus ensure that all component failure modes +modes within a {\fg}. Because we can guide the process in software we can +ensure that all component failure modes are included in the model. % We can then treat the {\fg} as a `black box' or component in its own right. From 3d1bb83b25c1f8c71d76c0d2d68db2f67b7714a2 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 17 Jan 2011 18:37:31 +0000 Subject: [PATCH 3/5] Evening edit after work... --- fmmd_concept/fmmd_concept.tex | 54 +++++++++++++++++++---------------- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index f94e9dd..a31ef63 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -98,7 +98,7 @@ of analysis. The FMMD methodology provides a detailed, hierarchical, incremental and analytical modelling system which will create a failure mode model from which -the data models from FTA, FMEA, FMECA and FMEDA % (the statistical approach) +the data models for FTA, FMEA, FMECA and FMEDA % (the statistical approach) can be derived. % if required. An FMMD model is effectively a super set of all the four traditional models. @@ -106,10 +106,10 @@ It also focuses on component interaction within the model, something not formally considered in the four established methodologies. % In addition it applies rigorous checking in all the analysis stages -ensuring that all component failure modes must be considered in the model. +ensuring that \textbf{all} component failure modes must be considered in the model. % -\paragraph{FMMD Process outline.} +\paragraph{FMMD process outline.} This methodology has been named Failure Mode Modular De-composition (FMMD) because it decomposes a SYSTEM into a hierarchy of modules or {\dc}s. This @@ -123,7 +123,7 @@ chapter presents the design considerations that motivated and provided the specification for the FMMD methodology. % -It first reviews the four traditional +Firstly it briefly reviews the four traditional static failure mode analysis methodologies and lists their known weaknesses. A wish list is then drawn up addressing these weaknesses and adding some extra requirements. @@ -146,7 +146,8 @@ at higher levels of analysis, until we have a complete hierarchy representing the failure behaviour of the SYSTEM. % Because all the failure modes of all the components -are held in a computer program, we can determine if the model is complete +are held in a computer program, we can determine if the model has complete coverage +for component failure modes (i.e. all component failure modes have been included in the model). @@ -214,15 +215,16 @@ Or we may have a mechanical device that has a different failure mode behaviour for say, different ambient pressures or temperatures. If $E$ is the number of applied states or environmental conditions to consider -in a system, the job of the bottom-up analyst is presented with an +in a system, and $A$ the number of applied states, +the job of the bottom-up analyst is presented with two additional %cross product -factor, -$(N-1) \times N \times K \times E$. +factors, +$(N-1) \times N \times K \times E \times A$. If we put some typical very small embedded system numbers\footnote{these figures would be typical of a very simple temperature controller, with a micro-controller sensor -and heater circuit.} into this, say $N=100$, $K=2.5$ and $E=10$ -we have $99 \times 100 \times 2.5 \times 10 = 247500 $. -To look in detail at a quarter of a million test cases is obviously impractical. +and heater circuit.} into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$ +we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $. +To look in detail at a half of a million test cases is obviously impractical. If we were to consider multiple simultaneous failure modes, we have yet another cross product of checks to be performed. @@ -306,7 +308,7 @@ Consider an unused feature failing.}. Muliplying these together, gives a risk probability number (RPN), given by $RPN = S \times O \times D$. This gives in effect -a prioritised `todo list', with higher $RPN$ values being the most urgent. +a prioritised `to~do~list', with higher $RPN$ values being the most urgent. \subsubsection{ FMEA weaknesses } @@ -379,7 +381,7 @@ makes the factor less statistically reliable. Failure Modes, Effects, and Diagnostic Analysis (FMEDA) % This is a process that takes all the components in a system, -and using the failure modes of those components; the investigating engineer +and using the failure modes of those components, the investigating engineer ties them to possible SYSTEM level events/failure modes. % This technique @@ -727,8 +729,12 @@ to SYSTEM level errors. The problem with this is that the base component failure mode under investigation, are not rigorously examined in relation to functionally adjacent components. % -Thus there is the `possibility to miss failure mode effects -at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies. +If failures modes could be collected and simplified somehow +at each stage in a hierarchy of {\fgs}, the functionally adjacent +ideal would be met, and as we progress up the hierarchy the number +of failure modes should decrease. +%Thus there is the `possibility to miss failure mode effects +%at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies. %%% %%% OK Got up to here Lunchtime edit 06DEC2010............. @@ -807,7 +813,7 @@ In this way as we build the hierarchy, we naturally abstract the failure mode behaviour, but can check that all failure modes in the hierarchy have been considered and tied to causing symptoms. -\paragraph{Design Decision: Derived components can be determined from functional groups} +\paragraph{Design Decision: Derived components must be determined from functional groups.} The symptoms obtained from analysing a {\fg} will be used as the `failure~modes' of its corresponding {\dc}. @@ -839,7 +845,7 @@ With the results from the test cases we will now have the ways in which the We can refine this further, by grouping the common symptoms, or results that are the same failure {\wrt} the {\fg}. % -We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes. +We can now treat the {\fg} as a component, and create a corresponding {\dc}: in other words, a `sub-system' with a known set of failure modes. % We can now create a new/{\dc} and assign it these common symptoms as its failure modes. @@ -847,7 +853,7 @@ as its failure modes. This {\dc} can be used to build higher level {\fg}s, and this will naturally form a hierarchy. This hierarchy can be extended until it encompasses -an entire system. +an entire SYSTEM. % It can be considered complete when all failure modes from all components are included in the model @@ -902,7 +908,7 @@ A derived component when created must always have a greater $\alpha$ value than of the components included in the {\fg} from which it was derived. -\paragraph{Natural Reduction in number of failure modes with abstraction level} +\paragraph{Natural Reduction in number of failure modes with abstraction level.} % Because common symptoms are being collected, as we build the tree upward the number of failure modes decreases (or exceptionally stays the same) @@ -1128,11 +1134,6 @@ at each FMMD stage. Where appropriate, multiple simultaneous failures can be modelled by introducing test~cases where the conjunction of failure modes is considered. -\subsubsection {Inhibit Conditions} -Some failure modes only occur when another failure has occurred, or -due to an environmental condition reaching a critical value. This is specifically -dealt with using the FTA methodology~\cite{nucfta}[IV 9]. -An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}. \begin{figure} \centering @@ -1173,6 +1174,11 @@ An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}. \label{fig:inhibitconcept} \end{figure} +\subsubsection {Inhibit Conditions} +Some failure modes only occur when another failure has occurred, or +due to an environmental condition reaching a critical value. This is specifically +dealt with using the FTA methodology~\cite{nucfta}[IV 9]. +An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}. \paragraph{Static or Dynamic Modelling of Inhibit} If the model is static we can consider the conditional failure, at a lower probability of occurring (i.e. the probability From 64165962c604a19c209bd99b778209b7708ca4f2 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 17 Jan 2011 20:00:07 +0000 Subject: [PATCH 4/5] Evening edit... --- .../component_failure_modes_definition.tex | 2 +- fmmd_concept/fmmd_concept.tex | 2 +- symptom_ex_process/algorithm.tex | 19 +++++++++++-------- symptom_ex_process/process.tex | 18 +++++++++--------- symptom_ex_process/topbot.tex | 15 +++++++-------- 5 files changed, 29 insertions(+), 27 deletions(-) diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index 0abb49e..6800424 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -338,7 +338,7 @@ fm : \mathcal{FG} \rightarrow \mathcal{F} \section{Unitary State Component Failure Mode sets} - +\label{sec:unitarystate} \paragraph{Design Descision/Constraint} An important factor in defining a set of failure modes is that they should represent the failure modes as simply and minimally as possible. diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index a31ef63..36efd65 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -1215,7 +1215,7 @@ for a single base~component failure mode minimal cut set~\cite{nucfta}. \subsection{Aims of FMMD Methodology} - +\label{sec:aims} Taking the four current failure mode methodologies into consideration, and comparing them to the proposed FMMD methodology, the following wish list or aims can be stated. \begin{itemize} diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 4fccb48..716742d 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -6,8 +6,8 @@ The algorithm for {\em symptom extraction} is described in this section %describes the symptom abstraction process -using set theory. - +using set theory and procedural descriptions. +% The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ and converts it to a derived~component/sub-system $DC$. %The sub-system $SS$ is a collection @@ -15,7 +15,8 @@ and converts it to a derived~component/sub-system $DC$. Note that $DC$ is a derived component at a higher level of fault analysis abstraction than the functional~group from which it was derived. -Thus, it can be treated +%Thus, +$DC$ can be treated as a component with a known set of failure modes. @@ -55,7 +56,7 @@ naturally formed with the abstraction levels increasing with each tier. The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages. %These are described using the Algorithm environment in the next section \ref{algorithms}. -By defining the process and describing it using set theory, constraints and +By defining the process and describing it using set theory. Constraints and verification checks in the process are stated formally. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -82,7 +83,7 @@ $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$ \end{algorithmic} \end{algorithm} -The symptom abstraction methodology allows us to take a functional group of components, +The symptom abstraction process allows us to take a functional group of components, analyse the failure mode behaviour and create a new entity, a derived~component, that has its own set of failure modes. The checks and constraints applied in the algorithm ensure that all component failure @@ -179,7 +180,7 @@ given by $$ dtc(F) = TC $$ -The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by +In algorithm \ref{alg2}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes) The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component. \ifthenelse {\boolean{paper}} @@ -187,7 +188,7 @@ The function \textbf{unitarystate} means that all test cases can have no pairs o %% perhaps ref a paper here XXXXX } { -This is discussed in section \ref{unitarystate}. +This is discussed in section \ref{sec:unitarystate}. } %% %% Algorithm 2 @@ -337,9 +338,11 @@ The analysis is primarily a human activity. Each test case is examined in detail. % % -Ideally calculations or simulations +Calculations or simulations are performed to determine how the failure modes in each test case will affect the functional~group. +Ideally field and formal physical testing data should be used in addition +where possible. % When the all the test cases have been analysed we will have a `result' for each `test case'. diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index cbd0982..1e064f1 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -3,14 +3,14 @@ % TO DO: separate these two: -\paragraph{Symptom Extraction Objective} +\paragraph{Symptom Extraction Objective.} The objective of `symptom abstraction' is to analyse the functional~group and find how it can fail when specified components within it fail. Once we know how a functional~group can fail, we can treat it as a component or sub-system with its own set of failure modes. -\paragraph{FMEA applied to the Functional Group} +\paragraph{FMEA applied to the Functional Group.} As the functional~group contains a set of components, the failure~modes that we have to consider are all the failure modes of its components, as developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$. @@ -27,7 +27,7 @@ the test case conditions, for each test case. The goal of the process is to produce a set of failure modes from the perspective of the functional~group. % -\paragraph{Environmental Conditions or Applied States} +\paragraph{Environmental Conditions or Applied States.} Each test case must be considered for all applied/operational states and %in the for the case of each applied states or @@ -52,7 +52,7 @@ examine environmentally sourced common mode failure scenarios. %%- change due to enviromental factors. %%- -\paragraph{Symptom Identification} +\paragraph{Symptom Identification.} When all `test~cases' have been analysed, a second phase can be actioned. % applied. % This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. @@ -66,7 +66,7 @@ will both cause the same failure; $no\_sound$ ! -\paragraph{Collection of Symptoms} +\paragraph{Collection of Symptoms.} Looking at the functional group perspective failure modes, we can collect some of these into common `symptoms'. Some test cases may cause unique failure modes at the functional group level. These can be termed @@ -104,7 +104,7 @@ form `test cases'. % \item Where si,ultaneous failures are examined use overlapping contours % \item For each region on the diagram, make a test case \item Using the `test cases' as scenarios to examine the effects of component failures -we determine failure~mode behaviour of the functional group. +we determine the failure~mode behaviour of the functional group. This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}. Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined for each test case. @@ -260,8 +260,8 @@ We can thus apply the function $fm$ on this newly derived component thus: $$ fm(DC) = \{ SP1, SP2, SP3 \} $$ Note that $g_6$ has \textbf{not disappeared from the analysis process}. -Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component. -i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$. +Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component. +i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could have been $ \{ SP1, SP2, g_6 \}$. Because the process can be computerised, we can easily flag symptoms that have not been included as failure modes in a {\dc}. % Aw boring ! no jokes ? @@ -275,7 +275,7 @@ from base level components cannot be overlooked. { An advantage of a bottom-up process is that failure modes from base level components cannot be overlooked. -The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). +The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{sec:aims}). } % This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component diff --git a/symptom_ex_process/topbot.tex b/symptom_ex_process/topbot.tex index 01f45b4..c6d4f1e 100644 --- a/symptom_ex_process/topbot.tex +++ b/symptom_ex_process/topbot.tex @@ -20,8 +20,8 @@ However, FMMD also provides the mathematical framework to assist in the production of the three traditional methods of static analysis. From the model created by the FMMD methodology, statistical, FTA and FMEA models can be derived. -FMMD can model electrical, mechanical and software using a common notation, -and can thus model an entire electro-mechanical software controlled system. +FMMD can model electrical, mechanical and software failures using a common notation, +and can thus model an integrated electro-mechanical software controlled system. \subsection{Top Down or Natural Trouble Shooting} It is interesting here to look at the `natural' trouble shooting process. @@ -95,7 +95,7 @@ that could cause a particular mode of equipment failure. This means that at the design stage of a product all component failure modes must be considered. The aim here is for complete failure mode coverage. This also means that we can obtain statistical estimates based on the known reliabilities -of the components. +of components\cite{mil1992}. %It also means that every component failure mode must at the very least be considered. @@ -125,7 +125,7 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface. %Thinking like this is a top~down analysis approach %and is the way in which FTA\cite{nucfta} analyses a System %and breaks it down. -\paragraph{Sub-systems, {\fgs} and components} +\paragraph{Sub-systems, {\fgs} and components.} A sub-system will be composed of components, which may themselves be sub-systems. However each `component' will have a fault/failure behaviour and it should @@ -135,8 +135,7 @@ for each `component'. If we look at the sound system example, the CD~player could fail in several distinct ways, -and this could be due to a large number of -component failure modes. +and this could have been caused by a number of component failure modes. %no matter what has happened to it or has gone wrong inside it. @@ -152,7 +151,7 @@ These are termed `functional~groups'. For instance the circuitry that powers th to illuminate the CD might contain a handful of components, and as such would make a good candidate to be one of the base level functional~groups. -\paragraph{Functional group to {\dc} process outline} +\paragraph{Functional group to {\dc} process outline.} In choosing the lowest level (base component) sub-systems we would look for the smallest `functional~groups' of components within a system. We can define a functional~group as a set of components that interact @@ -162,7 +161,7 @@ When we have analysed the fault behaviour of a functional group, we can treat it The fault behaviour will consist of a set of `symptoms' caused by combinations of its component failure modes. We can thus make a new `component' derived from the functional~group. -The symptoms are the failure modes of this new `derived component'. +The symptoms of the {\fg} are the failure modes of this new `derived component'. %We can now call our functional~group a sub-system or a derived~component. %The goal here is to know how it will behave under fault conditions ! From 6023c6d5f3f113f44f93e2b41bf3f3c81b7ad005 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Fri, 21 Jan 2011 12:14:48 +0000 Subject: [PATCH 5/5] Ideas for the intro/abstract commented out at mo --- fmmd_concept/fmmd_concept.tex | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex index 36efd65..8aa8f84 100644 --- a/fmmd_concept/fmmd_concept.tex +++ b/fmmd_concept/fmmd_concept.tex @@ -7,6 +7,14 @@ creating failure mode models of safety critical systems, which has a common notation for mechanical, electronic and software domains and applies an incremental and rigorous approach. +%This paper describes how the proposed methodology +%functions, given requirements and constraints (such as number of combinations +%of failure causes for flat ). +%It describes the need for the new methodology to be bottom-up, and +%then the need for incremental modularisation +%to build a fault mode hierarchy, which leads to the conceopt of functional grouping, +%analysis of those groupings, and from that +%the creation of derived components. %% %% What I have done %% @@ -43,6 +51,15 @@ has a common notation for mechanical, electronic and software domains and applies an incremental and rigorous approach. %% +%This chapter describes how the proposed methodology functions +%given requirements and constraints such as the number of combinations +%of failure causes. +%It describes the need for the new methodology to be bottom-up, and +%then the need for incremental modularisation +%to build a fault mode hierarchy, which leads to the conceopt of functional grouping, +%analysis of those groupings, and from that +%the creation of derived components. + %% What I have done %% The four main static failure mode analysis methodologies were examined and @@ -1280,6 +1297,14 @@ This \ifthenelse {\boolean{paper}} { paper +describes how the FMMD methodology +functions, given requirements and constraints such as the number of combinations +of failure causes. +It describes the need for the new methodology to be bottom-up, and +then the need for incremental modularisation +to build a fault mode hierarchy, which leads to the conceopt of functional grouping, +analysis of those groupings, and from that +the creation of derived components. } { chapter