From 8c0cc0e46db7bdc516eed4d820b3d714836a1e8c Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 11 Sep 2010 13:16:57 +0100 Subject: [PATCH 1/4] Saturday Morning edit --- fmmdset/fmmdset.tex | 13 +++-- symptom_ex_process/algorithm.tex | 34 ++++++++----- symptom_ex_process/process.tex | 82 ++++++++++++++++++++------------ 3 files changed, 83 insertions(+), 46 deletions(-) diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 41c004a..1d5bd9a 100644 --- a/fmmdset/fmmdset.tex +++ b/fmmdset/fmmdset.tex @@ -219,20 +219,25 @@ Consider a simple {\fg} $ FG^0_1 $ derived from 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 for completeness) -$$ \bowtie( FG^0_1 ) = C^1_1 $$ +$$ \bowtie fm(( FG^0_1 )) = C^1_1 $$ to look at this analysis process in more detail. -By way of exqample 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 \} $$ $$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \} $$ +And overloading $fm$ to find the flat set of failure modes from a {\fg} -The analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}. + $$ {fm}{FG^0_1} = \{ s_6, s_7, s_8 \} $$ + +The symptom extraction process is now applied +i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\fg} +and determines the failure modes of the {\fg}.. The result of this process will be a set of derived failure modes. -Let these be $ \{ s_6, s_7, s_8 \} $. +For this example, let these be $ \{ s_6, s_7, s_8 \} $. We can now create a {\dc} $C^1_1$ with this set of failure modes. Thus: diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index 9dd780a..f04e4af 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -15,11 +15,16 @@ 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 it was derived from. -However, it can still be treated +Thus, it can be treated as a component with a known set of failure modes. + + + + + \paragraph{Enumerating abstraction levels} -We can assign an attribute of abstraction level to -components $\alpha$, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$). +We can assign an attribute of abstraction level $\alpha$ to +components, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$). For a base component let the abstraction level be zero. If we apply the symptom abstraction process $\bowtie$ the resulting derived~component will have an $\alpha$ value @@ -65,7 +70,7 @@ From the earlier definition of the function `fm': The function $fm$ applied to a component returns the failure modes for that component. -The function $fm$ takes a flat set components $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$. +The function $fm$ takes a functional group $\mathcal{FG}$ and returns a set of failure modes $\mathcal{F}$. $$ fm: \mathcal{FG} \rightarrow \mathcal{F}$$ @@ -86,11 +91,13 @@ $$fm(FG) = F$$ \STATE { Let $FG$ be a set of components } \COMMENT{The functional group should be chosen to be minimally sized collections of components that perform a specific function} +\STATE { $ F := \emptyset $} \COMMENT{Clear the set of failure modes} \FORALL { $c \in FG $ } \REQUIRE{ Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; such \; that\; fm(c) \neq \emptyset$ } +\STATE{ $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ } \ENDFOR -\STATE {let $F=fm(FG)$ be a set of all failure modes to consider for the functional~group $FG$} +\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$} \RETURN { $F$ } @@ -116,7 +123,7 @@ From the failure modes associated with the functional~group we now need to determine test cases. The test cases are collections of failure modes. These could be formed from single failure modes or failure modes in combination. -Let $TC$ be the set of test cases associated with the functional group $FG$. +Let $TC$ be the set of test cases, which hold combinations of failure modes $F$ (associated with the functional group $FG$). $$ dtc: \mathcal{F} \rightarrow \mathcal{TC} $$ @@ -128,6 +135,11 @@ $$ dtc(F) = TC $$ %% Algorithm 2 %% + +%% +%% Maybe need to iterate through each failure mode, adding a new test case +%% this would build up all single fault test cases. +%% \begin{algorithm}[h+] ~\label{alg2} @@ -136,18 +148,18 @@ $$ dtc(F) = TC $$ \REQUIRE {F is a flat set of failure modes } - \STATE { All test cases are now chosen by the investigating engineer(s). Typically all single + \STATE { All test cases are chosen by the investigating engineer(s). Typically all single component failures are investigated with some specially selected combination faults} - \STATE { Let $TC$ be a set of test cases } + \STATE { Let $TC$ be the set of test cases } \STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$} \COMMENT { Each set $tc_j$ is a `test case' } %\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique} \FORALL { $tc_j \in TC$ } %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} - \ENSURE {$ tc_j \in \mathcal{P}(F))$} + \ENSURE {$ tc_j \in \mathcal{P}(F)$} \COMMENT { require that the test case is a member of the powerset of $F$ } %\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $} @@ -211,7 +223,7 @@ $$ atc(TC) = R $$ \caption{Analyse Test Cases: atc(TC) } \label{alg33} \begin{algorithmic}[1] \STATE { let r be a `test case result'} - \STATE { Let the function $Analyse : tc \mapsto r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} + \STATE { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions} \STATE { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$} \FORALL { $tc_j \in TC$ } \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group} @@ -392,7 +404,7 @@ to form functional~groups at higher levels of failure~mode~abstraction. \section{Linking all five stages} -$$ \bowtie: \mathcal{FG} \mapsto \mathcal{DC} $$ +$$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$ \begin{algorithm}[h+] diff --git a/symptom_ex_process/process.tex b/symptom_ex_process/process.tex index 4c87c4a..d75a04c 100644 --- a/symptom_ex_process/process.tex +++ b/symptom_ex_process/process.tex @@ -11,23 +11,26 @@ Once we know how a functional~group can fail, we can treat it as a component or with its own set of failure modes. \paragraph{FMEA applied to the Functional Group} -As the functional~group is a set of components, the failure~modes -that we have to consider are all the failure modes of its components. -Each failure mode (or combination of) investigated is termed a `test case'. -Each `test case' is analysed. +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}$. +The aim here is to build `test cases', combinations of failure~modes +to use as failure~mode analysis scenarios. +%Each failure mode (or combination of) investigated is termed a `test case'. +%Each `test case' is analysed. % The component failure modes in each test case are examined with respect to their effect on the functional~group. % -The aim of this analysis is to find out how the functional~group reacts -to each of the test case conditions. +The aim of this analysis is to find out how the functional~group fails given +the test case conditions, defined in each test case. The goal of the process is to produce a set of failure modes from the perspective of the functional~group. - +% \paragraph{Symptom Identification} -When all `test~cases' have been analysed, a second phase is applied. +When all `test~cases' have been analysed, a second phase can be actioned. % applied. % This looks at the results of the `test~cases' as symptoms of the sub-system. @@ -42,10 +45,16 @@ will both cause the same failure; $no\_sound$ ! \paragraph{Collection of Symptoms} -The common symptoms of failure and lone~component failure~modes are identified and collected. -We can now consider the functional~group as a component and the common symptoms as its failure modes. +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 +lone symptoms. +The common symptoms of failure and lone~symptoms are identified and collected. +We can now consider the functional~group as a component and the symptoms as its failure modes. Note that here, because the process is bottom up, we can ensure that all failure modes -associated with a functional~group have been handled. +from the components in a functional~group have been handled\footnote{Software can check that all +failure modes have been included in at least one test case, and modelled individually. For Double +Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}. Were failure~modes missed, any failure mode model could be dangerously incomplete. It is possible here for an automated system to flag unhandled failure modes. \ref{requirement at the start} @@ -70,10 +79,12 @@ 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' determine their effects on the failure~mode behaviour of the functional group. This is a human process involving detailed analysis of the failure modes oin the test case on the operation of the {\fg}. - \item Collect common~symptoms. i.e. determine which test cases produce the same fault symptoms {\em from the perspective of the functional~group}. + \item Using the `test cases' as scenarios to examine the effects of component failures +we determine 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}. + \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. - \item A new `derived component' can now be created where each common~symptom, or lone test case is a failure~mode of this new component. + \item A new `derived component' can now be created where each common~symptom, or lone symptom is a failure~mode of this new component. \end{itemize} @@ -107,7 +118,7 @@ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $fm$ \begin{equation} -{fm} : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +{fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} \end{equation} defined by (where $C$ is a component and $F$ is a set of failure modes): @@ -122,26 +133,27 @@ $$ fm(C_1) = \{ a_1, a_2, a_3 \} $$ $$ fm(C_2) = \{ b_1, b_2 \} $$ $$ fm(C_3) = \{ c_1, c_2 \} $$ +where $a_n,b_n,c_n$ are component failure modes. \paragraph{Finding all failure modes within the functional group} For fmMD failure mode analysis, we need to consider the failure modes from all the components in the functional group as a flat set. This can be found by applying function $fm$ to all the components -in the functional~group and taking the union of them thus: +in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus: -$$ FunctionalGroupAllFailureModes = \bigcup_{j \in \{1...n\}} fm(C_j) $$ +$$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$ -We can actually overload the notation for the function fm +We overload the notation for the function $fm$ and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: \begin{equation} -fm : FG \mapsto \mathcal{F} +fm : FG \rightarrow \mathcal{F} \end{equation} Applied to the functional~group $FG$ in the example above: \begin{equation} - fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \} + fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}. \end{equation} This can be seen as all the failure modes that can affect the failure mode group $FG$. @@ -178,12 +190,13 @@ $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline Table~\ref{tab:fexsymptoms} shows the analysis process. As we are only looking at single fault possibilities for this example each failure mode is represented by a test~case. -The Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. +Chosen combinations of Component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes}. The test cases are analysed w.r.t. the functional~group. These become functional~group~failure~modes ($g$'s). The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. -For the sake of example, let us consider the fault symptoms of $\{g_2, g_4, g_5\}$ to be +For the sake of example, let us consider the fault symptoms of the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$ +As failure modes, these identical from the perspective of the functional~group. That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes occur, is going to be the same. @@ -191,7 +204,7 @@ For example, in our CD player example, this could mean the common symptom `no\_s No matter which component failure modes, or combinations thereof cause the problem, the failure symptom is the same. It may be of interest to the manufacturers and designers of the CD player why it failed, but -as far as we the users are concerned, it has only one symptom, +as far as we, the users, are concerned it has only one symptom, `no\_sound'! We can thus group these component failure modes into a common symptom, $SP1$, thus $ SP1 = \{g_2, g_4, g_5\}$. @@ -203,13 +216,13 @@ but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$. We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail. In other words we have derived failure modes for this functional~group. -We can place these in a set of symptoms, $SP$. +We can place these in a set of symptoms. % -$$ SP = \{ SP1, SP2, SP3 \} $$ +$$ SP = \{ SP1, SP2, SP3 \}. $$ % % -These three symptoms can be considered the set of failure modes for the functional~group, and -we can treat it as though it were a {\em black box} +These three symptoms can be considered the set of failure modes for the functional~group, if +we treat it as though it were a {\em black box} or a {\em component} to be used in higher level designs. % The next stage of the process could be applied automatically. @@ -223,7 +236,10 @@ $$ fm(DC) = \{ SP1, SP2, SP3 \} $$ Note that $g_6$ has \textbf{not dissappeared 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 \}$. -This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! +Because the process can be computerised, we can easily flag symptoms that have not been +included a derived component. +% Aw boring ! no jokes ? +% This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! % \ifthenelse {\boolean{paper}} { @@ -244,11 +260,13 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ \subsection{Defining the analysis process \\ as a function} It is useful to define this analysis process as a function. -Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, we may now +Defining the function `$\bowtie$' to represent the {\em symptom abstraction} process, +and DCFM to represent derived component failure modes, we may now write $$ -\bowtie : SubSystemComponentFaultModes \mapsto DerivedComponent +%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent +\bowtie : DCFM \rightarrow DerivedComponent $$ % %\begin{equation} @@ -257,7 +275,9 @@ $$ % %or applying the function $fm$ to obtain the $FG_{cfm}$ set % -Where DC is a derived component, and FG is a functional group: +To put this in context, where DC is a derived component, and FG is a functional group, +we may state the process of extracting a set of failure modes from a functional +group thus: \begin{equation} \bowtie(fm(FG)) = DC From 5722c41c683c35a33347482cbd32880219dfebea Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Sat, 11 Sep 2010 17:52:39 +0100 Subject: [PATCH 2/4] DTC determine test cases algorithm re-written --- symptom_ex_process/algorithm.tex | 83 +++++++++++++++++++++++--------- 1 file changed, 60 insertions(+), 23 deletions(-) diff --git a/symptom_ex_process/algorithm.tex b/symptom_ex_process/algorithm.tex index f04e4af..a06c74b 100644 --- a/symptom_ex_process/algorithm.tex +++ b/symptom_ex_process/algorithm.tex @@ -157,36 +157,73 @@ $$ dtc(F) = TC $$ \COMMENT { Each set $tc_j$ is a `test case' } %\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique} + \STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases} + \STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases} + + \FORALL { $ f \in F $ } + \STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode } + \STATE{ $ j := j + 1 $} + \ENDFOR + + \STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes } + + \IF{DoubleFaultChecking} + + \STATE { Let $ptc$ be a provisional test case } + \FORALL { $ f1,f2 \in F $ } + \STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make a provisional test case} + %\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING} + %% OK maybe you can't have comments after IF: half an hour wasted... + \IF { $ \mathcal{ISUNITARYSTATE}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant} + \STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2 + \STATE { $ tc_j := ptc $} + \STATE { $ TC := TC \cup tc_j $ } + \ENDIF + \ENDFOR + \ENDIF + + + + + + \FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ } + %%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case} + \IF { $\mathcal{CHOSEN}(ptc) \wedge ptc \not\in TC \wedge \mathcal{ISUNITARYSTATE}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC} + \STATE{ $ j := j + 1 $} % latex bug hunt game #1 + \STATE { $ tc_j := ptc $} + \STATE { $ TC := TC \cup tc_j $ } + \ENDIF + \ENDFOR + \FORALL { $tc_j \in TC$ } %\ENSURE {$ tc_j \in \bigcap FG_{cfm} $} - \ENSURE {$ tc_j \in \mathcal{P}(F)$} + \ENSURE {$ tc_j \in \mathcal{P}(F) $ } % \mathcal{P}(F)$} \COMMENT { require that the test case is a member of the powerset of $F$ } %\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $} \ENSURE { $\forall j1,j2 \in J \; such\; that\; tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 $} \COMMENT { Test cases must be unique } \ENDFOR - - - \IF{Single fault checking} - \STATE { let $f$ represent a component failure mode } - %\ENSURE { That all failure modes are represented in at least one test case } - \ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ } - \COMMENT { This corresponds to checking that at least each failure mode is considered at - least once in the analysis; more rigorous cardinality constraint - checks may be required for some safety standards} - \ENDIF - - \IF{Double fault checking} - \STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group } - %\ENSURE { That all failure modes are represented in at least one test case } - \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ } - \COMMENT { This corresponds to checking that each possible double failure mode is considered - as a test case; more rigorous cardinality constraint - checks may be required for some safety standards. Note if both failure modes - in the check are sourced from the same component $c$, the test case is impossible - under unitary state failure mode conditions} - \ENDIF - +% +% \IF{Single fault checking} +% \STATE { let $f$ represent a component failure mode } +% %\ENSURE { That all failure modes are represented in at least one test case } +% \ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ } +% \COMMENT { This corresponds to checking that at least each failure mode is considered at +% least once in the analysis; more rigorous cardinality constraint +% checks may be required for some safety standards} +% \ENDIF +% +% \IF{Double fault checking} +% \STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group } +% %\ENSURE { That all failure modes are represented in at least one test case } +% \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ } +% \COMMENT { This corresponds to checking that each possible double failure mode is considered +% as a test case; more rigorous cardinality constraint +% checks may be required for some safety standards. Note if both failure modes +% in the check are sourced from the same component $c$, the test case is impossible +% under unitary state failure mode conditions} +% \ENDIF +% \RETURN $TC$ % some european standards % imply checking all double fault combinations\cite{en298} } From c7599d4092355cdfaeb89697361b74380d55be78 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 13 Sep 2010 07:31:10 +0100 Subject: [PATCH 3/4] Added SRDO and SROVT concepts from caninauto --- statistics/statistics.tex | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/statistics/statistics.tex b/statistics/statistics.tex index ec77f0d..de84ff2 100644 --- a/statistics/statistics.tex +++ b/statistics/statistics.tex @@ -47,6 +47,28 @@ Impact of boiler going down, no CO2 primary coolant available, possible reactor For the Brewery, safety is of the highest importance. For the Nuclear power station + +\section{Terms and Concepts in // Safety Critical Engineering} + +\subsection{Safety Relevant Data Object} +A Safety Relevant Data Object (SRDO)\cite{caninauto}, is a data structure describing the status of +a particular feature or attribute of a safety critical system. +For instance, in a burner this could be a flame signal value, or in a nuclear powerstation +the measure neutron flux. +\subsection{Safety relevant Object Validation Time} +Safety times can be given for SRDO's; these are termed Safety Related Object Validation Times (SROVT's)\cite{caninauto}. For instance were +a flame to fail in operation in a gas burner +standards state that the gas may not continue to be fed into the +furnace for more than three seconds \cite{en298}. +We can say that the SROVT for a flame signal in a gas burner is 3 seconds. +\subsection{Single and Double Failure Modes} +A Safety critical system must self check within the relevant SROVT's. +On detecting a failure mode it must react appropriately. +Consider the case though where two failures occurr within the +time windows of their SROVT's. We can term this a double simultaneous failure mode. +To take an extreme example, were the checking function/mechanism and the object under supervision +to fail within the SROVT, it may be impossible to detect the failure. + \section{Interfacing} Mech - elec - sw From 5628f58daf8834d8e219f33c571aeb2d266418ee Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Mon, 13 Sep 2010 07:41:16 +0100 Subject: [PATCH 4/4] Morning edit --- fmmdset/fmmdset.tex | 2 +- mybib.bib | 6 ++++++ statistics/statistics.tex | 6 +++--- 3 files changed, 10 insertions(+), 4 deletions(-) diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 1d5bd9a..04f62f9 100644 --- a/fmmdset/fmmdset.tex +++ b/fmmdset/fmmdset.tex @@ -163,7 +163,7 @@ and let the set of all possible failure modes be $\mathcal{F}$. We can define a function $fm$ \begin{equation} -fm : \mathcal{C} \mapsto \mathcal{P}\mathcal{F} +fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} \end{equation} defined by, where C is a component and F is a set of failure modes. diff --git a/mybib.bib b/mybib.bib index 31627cd..401fda7 100644 --- a/mybib.bib +++ b/mybib.bib @@ -5,6 +5,12 @@ % $Id: mybib.bib,v 1.3 2009/11/28 20:05:52 robin Exp $ +@ARTICLE{caninauto, + AUTHOR = "H. Zeltwanger", + TITLE = "Single Processor implementation of the CANopen Safety Protocol", + JOURNAL = "CAN in Automation (CiA)", + YEAR = "2008" +} @ARTICLE{valueoflife, AUTHOR = "W.K. Viscusi", diff --git a/statistics/statistics.tex b/statistics/statistics.tex index de84ff2..c62f6ed 100644 --- a/statistics/statistics.tex +++ b/statistics/statistics.tex @@ -48,7 +48,7 @@ For the Brewery, safety is of the highest importance. For the Nuclear power station -\section{Terms and Concepts in // Safety Critical Engineering} +\section{Terms and Concepts in \\ Safety Critical Engineering} \subsection{Safety Relevant Data Object} A Safety Relevant Data Object (SRDO)\cite{caninauto}, is a data structure describing the status of @@ -58,8 +58,8 @@ the measure neutron flux. \subsection{Safety relevant Object Validation Time} Safety times can be given for SRDO's; these are termed Safety Related Object Validation Times (SROVT's)\cite{caninauto}. For instance were a flame to fail in operation in a gas burner -standards state that the gas may not continue to be fed into the -furnace for more than three seconds \cite{en298}. +standards state \cite{en298} that the gas may not continue to be fed into the +furnace for more than three seconds. We can say that the SROVT for a flame signal in a gas burner is 3 seconds. \subsection{Single and Double Failure Modes} A Safety critical system must self check within the relevant SROVT's.