diff --git a/mybib.bib b/mybib.bib index 695ed42..1ebe4da 100644 --- a/mybib.bib +++ b/mybib.bib @@ -358,6 +358,14 @@ keywords={Aerospace engineering;Aerospace industry;Aerospace safety;Automotive e doi={10.1109/HASE.2004.1281774}, ISSN={1530-2059},} +@book{stranks2007human, + title={Human Factors and Behavioural Safety}, + author={Stranks, J.}, + isbn={978-0-7506-6542-1}, + url={http://books.google.co.uk/books?id=7RXYN2CIphMC}, + year={2007}, + publisher={Butterworth-Heinmann} +} @INPROCEEDINGS{1372150, author={Hartkopf, S.}, diff --git a/submission_thesis/CH2_FMEA/copy.tex b/submission_thesis/CH2_FMEA/copy.tex index c472260..b136023 100644 --- a/submission_thesis/CH2_FMEA/copy.tex +++ b/submission_thesis/CH2_FMEA/copy.tex @@ -817,7 +817,21 @@ be subject to management and/or political pressure. % The two most recent variants of FMEA, FMEDA and FMECA have dipped a metaphorical toe into the subjective realm, FMECA with itself `criticality~factor' and -FMEDA with its definition of `dangerous'. +FMEDA with its definition of `dangerous'. +% +However, while starting to address the subjective side +of failure analysis, +these methodologies +do not separate the final subjective stage from the objective. % stage of analysis. +% +A subjective assessment is made during the analysis of each {\bc} {\fm} +regardless of the fact that most {\bc} {\fms} cause shared +system level failures. +% +This means that work at the subjective +level is repeated. +% +Detailed work on subjective analysis is beyond the scope of this study. \paragraph{Multiple Simultaneous Failure Modes.} diff --git a/submission_thesis/CH8_Conclusion/copy.tex b/submission_thesis/CH8_Conclusion/copy.tex index 59570d1..a84a54f 100644 --- a/submission_thesis/CH8_Conclusion/copy.tex +++ b/submission_thesis/CH8_Conclusion/copy.tex @@ -1,103 +1,64 @@ \label{sec:chap8} + +In this study we have examined the processes and state of the art of the four main FMEA variants. +% +We have exposed shortcomings in these methodologies; which can be summed up as an inability to +model hybrid software and hardware systems in a satisfactory manner, a problem with state explosion +and difficulty of re-use of analysis because there is no support for modularity. +% +The FMECA and FMEDA variants also suffer from embedding subjective and objective assessments of failure modes. +% +A modularised FMEA---Failure Mode Modular De-composition (FMMD)---was proposed. +% +This modularised version was supported by the work already established in the +{\fms} of {\bc} in the literature~\cite{fmd91,mil1991,en298,en230}. +% +A selection of electronic examples were analysed using FMMD +which deliberately introduced varying circuit +topologies with conventional and circular signal paths +and mixed digital and analogue designs. +% +For all these examples, the state explosion related performance was compared with that of +traditional FMEA. +% +In all cases there was a performance gain, +that is to say that for all but trivial cases, +the number of manual analysis operations to perform +was reduced. +% +Not only this but the analysis naturally provided modules which could be re-used, +re-used not only in the circuit under analysis but potentially in different and future projects as well. + +Traditional FMEA methods have been applied to software, but analysis has always be separate from +the electronic FMEA~\cite{sfmeaa,sfmea}. %, and while modular kept strictly to a bottom-up approach. +% +Using established concepts from contract programming~\cite{dbcbe} we extended FMMD to analyse software, +which allows us to neatly solve the software hardware interfacing problem~\cite{sfmeainterface}. +% +Two examples of software and hardware hybrids were analysed as integrated FMMD models +as a proof of concept. The first example in chapter~\ref{sec:chap6}, was +presented to the System Safety IET conference in 2012~\cite{syssafe2012}. +% +Chapter~\ref{sec:chap7} viewed FMMD from a formal perspective and looked at problems and constraints +necessary to perform FMEA and FMMD. +% +Theoretical performance models were developed which showed that with increasing modularisation +the number of manual checks to perform for analysis fell, which was validated by examining the +electronic examples in this regard. +% +A unitary state failure mode constraint was developed for the failure modes of a component, and it was shown that +the FMMD process strictly enforced this throughout the hierarchy of a model. +% +Finally the FMMD process was described algorithmically using set theory in appendix~\ref{sec:algorithmfmmd}.%{app:alg}. + + + \section{Further Work} - -\subsection{Environment, operational states and inhibit gates: additions to the UML model.} - -FTA~\cite{nasafta,nucfta} models environmental, operational state and inhibit gates, and these can be incorporated into -the FMMD model. - -A system will be expected to perform in a given environment. -% -Environment in the context of this study -means external influences under which 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 could be specified for stress and loading limits. -It is unusual to have failure modes described in product literature, although -for complicated components with firmware errata documents are sometimes produced. - -Systems may have distinct operational states. For instance, a safety critical controller -may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until -authorised human intervention takes place. -A safety critical circuit may have a self test mode which could be operated externally: -a micro-processor may have a SLEEP mode etc. -% -Operational states and environmental conditions can %must -be factored into the UML model. - -\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.\footnote{A good example of a part -affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181} -which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}. -Environmental analysis is thus applicable to components. -Environmental influences, such as over stress due to voltage -can be eliminated by down-rating components as discussed in section~\ref{sec:determine_fms}. -With given environmental constraints, we can therefore eliminate some failure modes from the model. - - -\paragraph{Operational states.} -Within the field of safety critical engineering, we often encounter -elements that include test or self-test facilities. -% -We also encounter degraded performance -(such as only performing functions in an emergency) and lockout/emergency conditions. -These can be broadly termed operational states. %, and apply to the -%functional groups. -% -We need to determine which UML class is most appropriate to hold a relationship -to operational states. -% -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 seems more appropriate to apply the operational states to {\fgs} -which % -%Functional groupings -by definition implement functionality, or purpose. -On this basis we associate operational states with {\fgs}. -%therefore are the best objects to model -%operational states.% with. - -\paragraph{Inhibit Conditions.} -A third data class may be required if modelling inhibit conditions~\cite{nasafta}[p.40] is required. %desired. -Some failure modes may only be active given specific environmental conditions -or when other failures are already active. -To model this, an `inhibit' class has been added. -This is an optional attribute of -a failure mode. This inhibit class can be triggered -on a combination of environmental or failure modes. - - - - - - -\paragraph{UML Diagram Additional Objects.} -The additional objects System, Environment and Operational States -are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}. - -\label{completeumlfurtherwork} - -\begin{figure}[h] - \centering - \includegraphics[width=400pt,keepaspectratio=true]{./CH8_Conclusion/master_uml_further_work.png} - % cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464 - \caption{FMMD UML diagram, incorporating Environmental, Operational State and Inhibit gates} - \label{fig:cfg2} -\end{figure} - - - - -%% 31JAN2012 +This section describes areas that the study has revealed where the FMMD methodology may be extended or improved. + \section{Statistics: From base component failure modes to System level events/failures.} - +\label{sec:bcstats} Knowing the statistical likelihood of a component failing can give a good indication of the reliability of a system, or in the case of dangerous failures, the Safety Integrity Level of a system. @@ -289,13 +250,20 @@ we can also apply failure rate statistics to double failures. %% % If we consider the failure modes to be statistically independent we can calculate -the FIT values for all the combinations failures in table~\ref{tab:ptfmea2}. +the FIT values for all the combinations failures in the the electronic examples chapter~\ref{sec:chap5} table~\ref{tab:ptfmea2}. +% The failure mode of concern, the undetectable {\textbf{FLOATING}} condition -requires that resistors $R_1$ and $R_2$ fail. We can multiply the MTTF -together and find an MTTF for both failing. The FIT value of 12.42 corresponds to +requires that resistors $R_1$ and $R_2$ fail. +% +We can multiply the MTTF +together and find an MTTF for both failing. +% +The FIT value of 12.42 corresponds to $12.42 \times {10}^{-9}$ failures per hour. Squaring this gives $ 154.3 \times {10}^{-18} $. +% This is an astronomically small MTTF, and so small that it would probably fall below a threshold to sensibly consider. +% However, it is very interesting from a failure analysis perspective, because here we have found a fault that we cannot detect at this level. This means that should we wish to cope with @@ -303,6 +271,133 @@ this fault, we need to devise a way of detecting this condition in higher levels of the system. \glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period. Associated with continuous demand systems under EN61508~\cite{en61508}}} + +\subsection{Deriving FTA diagrams from FMMD models} +\label{sec:fta} + +Fault Tree Analysis (FTA)~\cite{ftahistory} is a top down methodology that +draws a fault tree---or top down fault causation diagram---for each given top-level +failure. With an FMMD model, we can trace all the causes of system failures +down to the base component level. +% +This would be enough to create a fault causation tree, but FTA introduces +concepts of operational and environmental states, and inhibit gates. +% +The FMEA philosophy in relation to these three concepts are to assume that they are worst cases, that they +{\em may} occur, +and determine what system failures may arise. +% +The FTA perspective is that some safety can be built in +by preventing certain things happening (inhibit gates), and by considering +different behaviour due to environmental or operational states~\cite{nucfta,nasafta}. +% +If we require FMMD to produce full FTA diagrams, we need to add these attributes to the FMMD UML model. + +\paragraph{Environment, operational states and inhibit gates: additions to the UML model.} + +FTA%~\cite{nasafta,nucfta} +models environmental, operational state and inhibit gates, and these can be incorporated into +the FMMD model. + +A system will be expected to perform in a given environment. +% +Environment in the context of this study +means external influences under which 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 could be specified for stress and loading limits. +It is unusual to have failure modes described in product literature, although +for complicated components with firmware errata documents are sometimes produced. + +Systems may have distinct operational states. For instance, a safety critical controller +may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until +authorised human intervention takes place. +A safety critical circuit may have a self test mode which could be operated externally: +a micro-processor may have a SLEEP mode etc. +% +Operational states and environmental conditions can %must +be factored into the UML model. +% +We may encounter a condition where we would want to inhibit some action of the system. +This is rather like a logical guard criterion. For instance in the gas burner standard EN298 +states that a flame detector must confirm that a pilot flame has been established before the main burner fuel can be applied. +In FTA terms this would be an inhibit condition on the main fuel, i.e. PILOT\_NOT\_CONFIRMED. + +\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\footnote{A good example of a part +affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181} +which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}. +Environmental analysis is thus applicable to components. +Environmental influences, such as over stress due to voltage +can be eliminated by down-rating components as discussed in section~\ref{sec:determine_fms}. +With given environmental constraints, we can therefore eliminate some failure modes from the model. + + +\paragraph{Operational states.} +Within the field of safety critical engineering, we often encounter +elements that include test or self-test facilities. +% +We also encounter degraded performance +(such as only performing functions in an emergency) and lockout/emergency conditions. +These can be broadly termed operational states. %, and apply to the +%functional groups. +% +We need to determine which UML class is most appropriate to hold a relationship +to operational states. +% +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 seems more appropriate to apply the operational states to {\fgs} +which % +%Functional groupings +by definition implement functionality, or purpose. +On this basis we associate operational states with {\fgs}. +%therefore are the best objects to model +%operational states.% with. + +\paragraph{Inhibit Conditions.} +Inhibit conditions and the symbols used for them are described in~\cite{nasafta}[p.40]. % is required. %desired. +% +Some failure modes may only be active given specific environmental conditions +or when other failures are already active. +% +To model this, an `inhibit' class has been added. +% +This is an optional attribute of +a failure mode. +% +This inhibit class can be triggered +on a combination of environmental or failure modes. +% +In the UML diagram, we therefore link this with +both environmental conditions and failure modes. + + + + + +\paragraph{UML Diagram Additional Objects.} +The additional objects System, Environment, Inhibit and Operational States +are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}. + +\label{completeumlfurtherwork} + +\begin{figure}[h] + \centering + \includegraphics[width=400pt,keepaspectratio=true]{./CH8_Conclusion/master_uml_further_work.png} + % cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464 + \caption{FMMD UML diagram, incorporating Environmental, Operational State and Inhibit gates} + \label{fig:cfg2} +\end{figure} + +\clearpage + \section{Retrospective Failure Mode analysis and FMMD} The reasons for applying retrospective failure mode analysis could be approving previously un-assessed @@ -310,46 +405,93 @@ systems to a safety standard, or to determine the failure mode behaviour of an safety critical verification. % verification. % FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with -its work flow it -can reveal undetected failure modes. +its `bottom-up~work~flow' it +can reveal previously undetected system failure modes. +% +This is because the analyst +is forced to deal with a component failure modes by the FMMD process. % FMMD requires that all failure modes of components in a {\fg} are resolved to a symptom in the resulting {\dc}. % -% FMMD can find failure modes that are not -dealt with as a symptom, i.e. were unintentionally ignored +dealt with as a symptom, i.e. were ignored or forgotten. This means that FMMD will route out un-handled failure modes. %come to light. % We can apply retrospective FMMD to electronic and software hybrid systems as well. -Each function in the software will have to be assigned a `design~contract'~\cite{dbcbe} (where violations of +% +The electronic components {\fms} are established in the literature~\cite{fmd91,mil1991,en298,en230}. +% +Each function in the software would have to be assigned a `design~contract'~\cite{dbcbe} (where violations of contract clauses will be treated as failure modes in FMMD). % -By %doing -applying contracts and seeing how calling functions deal with -the failures in the functions they call, we reveal un-handled the error conditions in -the software. -By treating hardware interfaces to software as {\dcs}, we automatically have a list of the failure modes -of the electronics. +% By %doing +% applying contracts and seeing how calling functions deal with +% the failures in the functions they call, we reveal un-handled the error conditions in +% the software. +% By treating hardware interfaces to software as {\dcs}, we automatically have a list of the failure modes +% of the electronics. +%% +With the contracts in place for the software, we can then integrate them into the FMMD model. % FMMD models both software and hardware; we can thus verify that all failure modes from the electronics module, have been dealt -by the controlling software. If not they are an un-handled error condition. -That is the hardware interfaces to software in FMMD is a {\dc}, -the failure modes of this {\dc} are the list of all known failure modes -of the electronics. +by the controlling software. +% +If not they are an un-handled error condition relating to the software hardware interface. +% +% That is the hardware interfaces to software in FMMD is a {\dc}, +% the failure modes of this {\dc} are the list of all known failure modes +% of the electronics. % By performing FMMD on a software electronic hybrid system, -we thus reveal design deficiencies. +we thus reveal design deficiencies inboth the software and the software/electronics interface. %in the hardware/software interface. + FMEDA does not handle software ---or---the software hardware interface. +It thus potentially misses many undetected failures (in EN61508 terms undetected-dangerous and undetected safe failures). In Safety Integrity Level (SIL)~\cite{en61508} terms, by identifying undetectable faults and fixing them, we raise the safe failure fraction (SFF). +\section{How traditional FMEA reports can be derived from an FMMD model.} +% +An FMMD model has a data structure (described by UML diagrams, see figure~\ref{fig:cfg}), and by traversing this +we can map system level failures back to {\bc} {\fms} (or combinations thereof). +% +Because we can determine these mappings we can produce reports in the traditional FMEA format ({\bc}~{\fm}~$\mapsto$~{system failure}). +% +With the addition of {\bc} {\fm} statistics~\cite{mil1991} we can provide reliability predictions for system level failures. +The Pt100 example is revisited for this purpose and analysed for single and double failures, with statistics for {\bcs} +taken from MIL1991 %~\cite{mil1991}, +in section~\ref{sec:bcstats}. +% +With an FMMD failure mode model a top down perspective is possible. +We could for instance take each system level failure and produce a causation tree for it, tracing back +to all {\bc} {\fms}. +This is very closely related to the structure of FTA (top down) failure causation graphs. +The possibility of automatically producing FTA diagrams from FMMD models +is examined in section~\ref{sec:fta}. +% + \section{Objective and Subjective Reasoning stages} -Opportunity for formal definitions and perhaps an interface or process for achieving it.... +%Opportunity for formal definitions and perhaps an interface or process for achieving it.... +The act of applying failure mode effects analysis, is in terms of cause and effect viewed from +and engineering perspective. This is the realm of the objective. +The executive decisions about deploying systems are in the domain of management and politics. +% +The dangers, or potential negative effects of a safety critical system depend not only on the system its self, +but on the environment they are used in +and other human factors such as the training level of operatives~\cite{stranks2007human}. +% +We could term this subjective reasoning. With the system level failure +we have to determine its level of criticality, or how serious the risk posed is. +% +Two methodologies have started to consider this aspect, FMECA with its criticality and probability factors, and +EN61508 with its classification of dangerous and safe failures. +% +It is the authors opinion that more work is required to clarify this area. FMMD stops at the objective level. \section{Conclusion}