From 1c483a8782462a21cad2d85fdb95ecd1413fa038 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Fri, 4 Feb 2011 16:51:57 +0000 Subject: [PATCH] JMC proof read --- fmmd_data_model/fmmd_data_model.tex | 2 +- fmmdset/fmmdset.tex | 24 +++++++++++----------- introduction/introduction.tex | 2 +- style.tex | 6 +++--- symptom_ex_process/symptom_ex_process.tex | 25 ++++++++++------------- 5 files changed, 28 insertions(+), 31 deletions(-) diff --git a/fmmd_data_model/fmmd_data_model.tex b/fmmd_data_model/fmmd_data_model.tex index 07509c0..0a3efea 100644 --- a/fmmd_data_model/fmmd_data_model.tex +++ b/fmmd_data_model/fmmd_data_model.tex @@ -1,5 +1,5 @@ - +\label{chap:dag} \ifthenelse {\boolean{paper}} diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index b3e125c..b689e18 100644 --- a/fmmdset/fmmdset.tex +++ b/fmmdset/fmmdset.tex @@ -7,7 +7,7 @@ \begin{abstract} This paper describes a methodology to analyse -safety critcal designs from a failure mode perspective. +safety critical designs from a failure mode perspective. This paper concentrates on the hierarchical model: the analysis phases (symtom abstraction) and {\fgs} are dealt with in \cite{symptom_ex}. @@ -32,7 +32,7 @@ EN298, EN61508, EN12067, EN230, UL1998. { This chapter describes the Failure Mode Modular De-Composition (FMMD) methodology to analyse -safety critcal designs from a failure mode perspective, with emphasis on building a hierarchical models, in an incremental and modular fashiion. +safety critical designs from a failure mode perspective, with emphasis on building a hierarchical model, in an incremental and modular fashion. %Failure Mode Modular De-Composition (FMMD) FMMD provides a rigorous method for creating a fault effects model of a system from the bottom up starting with {\bc} level fault modes. @@ -82,7 +82,7 @@ The second is to specify that any single or double part faults cannot lead to a dangerous fault in the system under consideration. This entails tracing the effects of all part failure modes and working out if they can lead to any dangerous faults in the system under consideration. -This is the deterministic approach, and looks for casual links from the {\bc} failure modes +This is the deterministic approach, and looks for causal links from the {\bc} failure modes to SYSTEM failures. %For instance, during WWII after operational research teams had analysed data it was determined that % an aircraft engine that can, through one part failure cause a catastrophic failure is an unacceptable design.\cite{boffin} . @@ -128,8 +128,8 @@ From the point of view of fault analysis, we are not interested in the component For this study a {\fg} will mean a collection of components. In order to determine the symptoms or failure modes of a {\fg}, we need to consider all failure modes of its components. -By analysing the fault behaviour of a `{\fg}' with respect these component failure modes -we can derive a new set of possible failure modes. In fact we can caal these +By analysing the fault behaviour of a `{\fg}' with respect to these component failure modes, +we can derive a new set of possible failure modes. In fact we can call these the symptoms of failure for the {\fg}. % This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of @@ -158,7 +158,7 @@ at a higher abstraction level. Reference the symptom abstraction paper here } { -This analysis and symptom collection process is described in detail in the Symptom extraction chapter (see section \ref{symptomex}). +This analysis and symptom collection process is described in detail in the Symptom Extraction chapter (see section \ref{symptomex}). } @@ -229,7 +229,7 @@ of all the components in the {\fg}. An analysis process defined by the symbol `$\bowtie$' is applied to the {\fg}. iThe $\bowtie$ function takes a {\fg} -as an argument and returns a newly cretaed {\dc}. +as an argument and returns a newly created {\dc}. The $\bowtie$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}. Using $\alpha$ to symbolise the fault abstraction level, we can now state: @@ -257,11 +257,11 @@ Consider a simple {\fg} $ FG^0_1 $ comprising of two base components $C^0_1,C^0 We can apply $\bowtie$ to the {\fg} $FG$ and it will return a {\dc} at abstraction level 1 (with an index of 1 represented a as sub-script) -$$ \bowtie \big( fm(( FG^0_1 )) \big)= C^1_1 $$ +$$ \bowtie \big( fm(( FG^0_1 )) \big)= C^1_1 .$$ -to look at this analysis process in more detail. +%to look at this analysis process in more detail. -By way of example applying ${fm}$ to obtain the failure modes $f_N$ +By way of example, applying ${fm}$ to obtain the failure modes $f_N$ $$ {fm}(C^0_1) = \{ f_1, f_2 \} $$ @@ -477,7 +477,7 @@ we might look at reporting any fault via the RS232 link. By doing this we have already used a modular approach. We have analysed each section of the circuitry, -and then considering possible faulures from each module, +and then considering possible failures from each module, can fit these into a picture of the fault~modes of the milli-volt monitor as a whole. However this type of analysis is not guaranteed @@ -585,7 +585,7 @@ microprocessors, custom test~rig software may be run on them to exercise active sections of the PCB (for instance to drive outputs, relays etc). The main purpose of a test rig is to prevent fault equipment from being shipped. -However, often a test rig, will reveal an easy to fix fault on a board (such as a part not soldered down completely +However, often a test rig will reveal an easy to fix fault on a board (such as a part not soldered down completely or missing parts). These boards can be mended and re-submitted to the test rig. It is often a problem, when a unit fails in a test rig, to quickly determine why it has failed. diff --git a/introduction/introduction.tex b/introduction/introduction.tex index 4809711..8b66343 100644 --- a/introduction/introduction.tex +++ b/introduction/introduction.tex @@ -17,10 +17,10 @@ both the deterministic\footnote{Deterministic failure mode analysis, traces fail can determine an overall failure rate, in terms of probability of failure on demand, or failure in time (or Mean Time to Failure (MTTF).}. \glossary{name={safety critical},description={A safety critical system is one in which its failure may result in death or serious injury to humans, an environmental catastrophe or severe loss or damage}} \fmodegloss +\pecgloss \paragraph{Safety Critical Controllers, knowledge and culture sub-disiplines} The maturing of the application of the programmable electronic controller (PEC) -\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actucators interfaced electronically, with some firmware/software component in overall control}} for a wide range safety critical applications, has led to a fragmentation of subdisiplines which speak imperfectly to one another. The main three sub-disiplines are Electrical, Software and Mechanical Engineering. diff --git a/style.tex b/style.tex index ffbc962..c187394 100644 --- a/style.tex +++ b/style.tex @@ -82,12 +82,12 @@ %\newcommand{\pic}{\em pure~intersection~chain} \newcommand{\pic}{\em pair-wise~intersection~chain} \newcommand{\wrt}{\em with~respect~to} -\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functioal groups of components and creating derived components representing them, and in turn using the derived components to crate higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}} +\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}} \newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a failure mode of the component or sub-system}}} -\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={Failure Mode and Effects analysis (FMEA) is a process where each potential failure mode within a SYSTEM, is analysed to determine SYSTEM level failure modes, and to then classify them {\wrt} percieved severity}}} +\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={Failure Mode and Effects analysis (FMEA) is a process where each potential failure mode within a SYSTEM, is analysed to determine SYSTEM level failure modes, and to then classify them {\wrt} perceived severity}}} \newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}} - +\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}} %----- Display example text (#1) in typewriter font diff --git a/symptom_ex_process/symptom_ex_process.tex b/symptom_ex_process/symptom_ex_process.tex index 2b111c2..0454444 100644 --- a/symptom_ex_process/symptom_ex_process.tex +++ b/symptom_ex_process/symptom_ex_process.tex @@ -20,25 +20,22 @@ } - - - { \section{Introduction} \label{chap:sympex} This chapter describes the process for taking a {\fg}, analysing its failure mode behaviour from the failure modes and interactions of its components, -and creating {\dc} that represent the failure mode behaviour of that {\fg}. +and creating a {\dc} that represent the failure mode behaviour of that {\fg}. This chapter uses algorithms and set theory to describe the process. % -In essense, we take a {\fg} ( a collection of components), +In essence, we take a {\fg} ( a collection of components), and apply FMEA analysis locally on this {\fg}. % -In this way we determine how that {\fg} can fail. -Iwe can then go further and consider these to -be symtoms of failures in the components of the {\fg}. +In this way, we determine how that {\fg} can fail. +We can then go further and consider these to +be symptoms of failures in the components of the {\fg}. We can collect common symptoms of failure for the {\fg}. % % @@ -163,8 +160,8 @@ examined, as to their effect on the functional group. The effects on the functional group can then be collected as common symptoms, and now we may treat the functional group as a component, as it has a known set of failure modes. % -By reusing the `components' derived from functional~groups an entire -hierarichal failure mode model of the system can be built. +By reusing the `components' derived from functional~groups, an entire +hierihical failure mode model of the system can be built. That is to say, using derived components in higher level functional groups, a hierarchy is naturally formed. % @@ -331,13 +328,13 @@ The goal of the process is to produce a set of failure modes from the perspectiv % In other words, if a designer is handed an piece of circuitry to use, he need not be concerned with the failure modes of its components. He is handed it as a derived component, which has -a set of failure mode symptoms. The designer can now treat this piece of circuioty as a black box, or {\dc}. +a set of failure mode symptoms. The designer can now treat this piece of circuitry as a black box, or {\dc}. \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 -environmental conditions that it may be exposed to. In this way all possible +environmental conditions to which it may be exposed. In this way, all possible failure mode behaviour due to the test case conditions will be examined. As part of this analysis process, records must be kept @@ -409,10 +406,10 @@ form `test cases'. % \item Draw these as contours on a diagram % \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 + \item Using the `test cases' as scenarios to examine the effects of component failures, we determine the failure~mode behaviour of the functional group. This is a human process, involving detailed analysis of the component failure modes in the test case on the {\fg}. -Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined +Where specific environment conditions, or applied states are germane to the {\fg}, these must be examined for each test case. \item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}. \item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.