\label{sec:chap8} \fmeagloss This study has examined the processes and state of the art of the four main FMEA variants. % \fmmdglossSTATEEX It has 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)---had been proposed. % This modularised version had been supported by the work already established by the definition of {\fms} for {\bcs} in the literature~\cite{fmd91,mil1991,en298,en230}. % A selection of electronic examples was analysed using FMMD which deliberately introduced varying circuit topologies with conventional and circular signal paths and mixed digital and analogue designs. % \fmmdglossSTATEEX 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 significantly reduced. \fmmdglossRD % 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 been performed separately 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} FMMD was extended to analyse software, which facilitated a solution to the software/hardware interfacing problem~\cite{sfmeainterface}. % Two examples of mixed software and hardware systems were analysed as integrated FMMD models as 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 (see section~\ref{sec:theoreticalperfmodel}) which showed that with increasing modularisation the number of manual checks to perform for analysis fell, which was validated by examining the reasoning distance performance of the examples from chapter~\ref{sec:chap5}. % in this regard. % A unitary state failure mode concept was developed (see section~\ref{sec:unitarystate}), and it was shown that the FMMD process naturally enforced this throughout the hierarchy of a model. \fmmdglossMUTEX % Finally the FMMD process was described algorithmically % using set theory in appendix~\ref{sec:algorithmfmmd}.%{app:alg}. In conclusion then, a new method of failure analysis has been devised which improves on established techniques in the following ways: % \begin{itemize} % \item Must be able to analyse hybrid software/hardware systems, % \item no state explosion (which has rendered exhaustive analysis impractical), % \item exhaustive checking at a modular level, %(total failure coverage within {\fgs} all interacting component and failure modes checked), % \item traceable reasoning system models,% to aid repeatability and checking, % \item re-usable i.e. it should be possible to re-use analysis, % \item possibility to analyse simultaneous/multiple failures, % \item modular --- i.e. usable in a distributed system. % % \item % \end{itemize} \fmmdglossSTATEEX \begin{itemize} \item FMMD provides the means to determine failure models that integrate software and hardware, \item the state explosion related to exhaustive FMEA reduced from a polynomial to logarithmic order, \item a modular approach to FMEA means that analysis work is re-usable, %\item FMMD encourages \item distributed systems, and smart instruments, can now be analysed and assessed, \item multiple failures can be analysed (without an undue state explosion cost). \end{itemize} These benefits fall under the following assumptions and constraints: \begin{itemize} \item Failure modes are available for all {\bcs}, \item Analysts are capable of finding suitable {\fgs} from electronic schematics, \item Functional software and its elements (hardware interfaces, data and functions) can be modelled using contract programming. %\item \end{itemize} \fmmdglossRD Whilst investigating FMMD a number of further areas for research revealed themselves. These are presented below. % %\section{Conclusion} % % It is the authors belief that the practise of FMEA would be improved by taking a modular approach % and that it is necessary that software and hardware should be included in the same failure mode models. % % % The proposed methodology, FMMD, provides the means to do this, and it is the authors hope that this % or a variant thereof is taken up and used to improve system safety. % \section{Further Work} %This section describes areas that the study has revealed where the FMMD methodology may be extended or improved. \subsection{How traditional FMEA reports can be derived from an FMMD model.} % \fmmdgloss \fmeagloss An FMMD model has a data structure (described by UML diagrams, see figure~\ref{fig:cfg}), and by traversing an FMMD hierarchy system level failures can be mapped back to {\bc} {\fms} (or combinations thereof). % Because these mappings can be determined reports in the traditional FMEA format ({\bc}~{\fm}~$\mapsto$~{system failure}) can be produced. % With the addition of {\bc} {\fm} statistics~\cite{mil1991} reliability predictions for system level failures can be provided. % 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. % Each system level failure can have a causation tree produced 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}. % \fmmdglossRD \subsection{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. % EN61508~\cite{en61508} requires that statistical data is available and used for all component failure modes analysed by FMEDA. % FMMD, as a bottom up methodology can use component failure mode statistical data, and incorporate it into its hierarchical model. %By way of example, the Pt100 analysis %example %from section~\{sec:pt100} has been used to demonstrate this. Because an FMMD model can be used to generate an FMEA report, with additional {\bc} failure mode statistics an FMEDA report can be produced. %we can %therefore %use FMMD to produce an FMEDA report. \paragraph{Pt100 Example: Single Failures and statistical data.} %Mean Time to Failure} \frategloss From an earlier example, the model for the failure mode behaviour of the Pt100 circuit, {\bc} {\fm} statistics are added to determine the probability of symptoms of failure. % The DOD electronic reliability of components document MIL-HDBK-217F~\cite{mil1991} gives formulae for calculating the %$\frac{failures}{{10}^6}$ ${failures}/{{10}^6}$ % looks better in hours for a wide range of generic components \footnote{These figures are based on components from the 1980's and MIL-HDBK-217F can give conservative reliability figures when applied to modern components}. % Using the MIL-HDBK-217F %~\cite{mil1991} specifications for resistor and thermistor failure statistics, the reliability for the Pt100 example (see section~\ref{sec:Pt100}) is calculated below. % % \paragraph{Resistor FIT Calculations.} % The formula given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor is reproduced in equation \ref{resistorfit}. The meanings and values assigned to its co-efficients are described in table \ref{tab:resistor}. \fmmdglossFIT \fmodegloss % \begin{equation} % fixed comp resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E \label{resistorfit} \end{equation} \begin{table}[ht] \caption{Fixed film resistor Failure In Time (FIT) assessment.} % title of Table \centering % used for centering table \begin{tabular}{||c|c|l||} \hline \hline \em{Parameter} & \em{Value} & \em{Comments} \\ & & \\ \hline \hline ${\lambda}_{b}$ & 0.00092 & stress/temp base failure rate $60^o$ C \\ \hline %${\pi}_T$ & 4.2 & max temp of $60^o$ C\\ \hline ${\pi}_R$ & 1.0 & Resistance range $< 0.1M\Omega$\\ \hline ${\pi}_Q$ & 15.0 & Non-Mil spec component\\ \hline ${\pi}_E$ & 1.0 & benign ground environment\\ \hline \hline \hline \end{tabular} \label{tab:resistor} \end{table} \frategloss Applying equation \ref{resistorfit} with the parameters from table \ref{tab:resistor} give the following failures in ${10}^6$ hours: \begin{equation} 0.00092 \times 1.0 \times 15.0 \times 1.0 = 0.0138 \;{failures}/{{10}^{6} Hours} \label{eqn:resistor} \end{equation} While MIL-HDBK-217F gives MTTF for a wide range of common components, it does not specify how the components will fail (in this case OPEN or SHORT). % Some standards, notably EN298 only consider most types of resistor as failing in OPEN mode. %FMD-97 gives 27\% OPEN and 3\% SHORTED, for resistors under certain electrical and environmental stresses. % FMD-91 gives parameter change as a third failure mode, luvvverly 08FEB2011 This example compromises and uses a 9:1 OPEN:SHORT ratio, for resistor failure. % Thus for this example resistors are expected to fail OPEN in 90\% of cases and SHORTED in the other 10\%. A standard fixed film resistor, for use in a benign environment, non military specification at temperatures up to {60\oc} is given a probability of 13.8 failures per billion ($10^9$) hours of operation (see equation \ref{eqn:resistor}). In EN61508 terminology, this figure is referred to as a Failure in Time FIT\footnote{FIT values are measured as the number of failures per Billion (${10}^9$) hours of operation, (roughly 114,000 years). The smaller the FIT number the more reliable the component.}. % The formula given for a thermistor in MIL-HDBK-217F\cite{mil1991}[9.8] is reproduced in equation \ref{thermistorfit}. The variable meanings and values are described in table \ref{tab:thermistor}. % \begin{equation} % fixed comp resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E resistor{\lambda}_p = {\lambda}_{b}{\pi}_Q{\pi}_E \label{thermistorfit} \end{equation} % \begin{table}[ht] \caption{Bead type Thermistor Failure in time assessment} % title of Table \centering % used for centering table \begin{tabular}{||c|c|l||} \hline \hline \em{Parameter} & \em{Value} & \em{Comments} \\ & & \\ \hline \hline ${\lambda}_{b}$ & 0.021 & stress/temp base failure rate bead thermistor \\ \hline %${\pi}_T$ & 4.2 & max temp of $60^o$ C\\ \hline %${\pi}_R$ & 1.0 & Resistance range $< 0.1M\Omega$\\ \hline ${\pi}_Q$ & 15.0 & Non-Mil spec component\\ \hline ${\pi}_E$ & 1.0 & benign ground environment\\ \hline \hline \hline \end{tabular} \label{tab:thermistor} \end{table} % \begin{equation} 0.021 \times 1.0 \times 15.0 \times 1.0 = 0.315 \; {failures}/{{10}^{6} Hours} \label{eqn:thermistor} \end{equation} % Thus thermistor, bead type, `non~military~spec' is given a FIT of 315.0. % \frategloss Using the RIAC finding the following table (table \ref{tab:stat_single}) can be created, showing the FIT values for all single failure modes. %\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.}} \fmmdglossFIT % \begin{table}[h+] \caption{Pt100 FMEA Single // Fault Statistics} % title of Table \centering % used for centering table \begin{tabular}{||l|c|c|l|l||} \hline \hline \textbf{Test} & \textbf{Result} & \textbf{Result } & \textbf{MTTF} \\ \textbf{Case} & \textbf{sense +} & \textbf{sense -} & \textbf{per $10^9$ hours of operation} \\ % R & wire & res + & res - & description \hline \hline TC:1 $R_1$ SHORT & High Fault & - & 1.38 \\ \hline TC:2 $R_1$ OPEN & Low Fault & Low Fault & 12.42\\ \hline \hline TC:3 $R_3$ SHORT & Low Fault & High Fault & 31.5 \\ \hline TC:4 $R_3$ OPEN & High Fault & Low Fault & 283.5 \\ \hline \hline TC:5 $R_2$ SHORT & - & Low Fault & 1.38 \\ TC:6 $R_2$ OPEN & High Fault & High Fault & 12.42 \\ \hline \hline \end{tabular} \label{tab:stat_single} \end{table} % \frategloss % The FIT for the circuit as a whole is the sum of MTTF values for all the test cases. The Pt100 circuit here has a FIT of 342.6. This is a MTTF of about $\approx 360$ years per circuit. % A probabilistic tree can now be drawn, with a FIT value for the Pt100 circuit and FIT values for all the component fault modes from which it was calculated. % From this it can be seen that the most likely fault is the thermistor going OPEN. % This circuit is around 10 times more likely to fail in this way than in any other. % If a more reliable temperature sensor was required, this would probably be the fault~mode scrutinised first. % \frategloss % \begin{figure}[h+] \centering \includegraphics[width=400pt,bb=0 0 856 327,keepaspectratio=true]{./CH5_Examples/stat_single.png} % stat_single.jpg: 856x327 pixel, 72dpi, 30.20x11.54 cm, bb=0 0 856 327 \caption{Probablistic Fault Tree : Pt100 Single Faults} \label{fig:stat_single} \end{figure} % The Pt100 analysis presents a simple result for single faults. The next analysis phase looks at how the circuit will behave under double simultaneous failure conditions. % % \paragraph{Pt100 Example: Double Failures and statistical data} Because double simultaneous failure analysis can be performed under FMMD failure rate statistics to double failures can also be determined. % \frategloss % %% %% Need to talk abou the `detection time' %% or `Safety Relevant Validation Time' ref can book %% EN61508 gives detection calculations to reduce %% statistical impacts of failures. %% % Considering the failure modes to be statistically independent the FIT values for all the combinations failures in the electronic examples from chapter~\ref{sec:chap5} in table~\ref{tab:ptfmea2} can be calculated. % The failure mode of most concern, the undetectable {\textbf{FLOATING}} condition, requires that resistors $R_1$ and $R_2$ both fail. % Multiplying the MTTF probabilities for these types of resistor failing gives the 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 an undetectable fault (at least at this level in the FMMD hierarchy) has been revealed. % This means that should it be required to cope with this fault, a new way of detecting this condition must be engineered, perhaps in higher levels of the system/FMMD hierarchy. % \paragraph{MTTF statistics and FMMD hierarchies.} % In a large FMMD model, system/top level failures can be traced down to {\bc} {\fms}. % To determine the MTTF probability for a system level failure, the MTTF statistics are added for all its possible causes. % Thus even for large FMMD models accurate statistics for electronic sourced failures can be calculated. % %\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}}} % \frategloss \fmmdglossFIT % \subsection{Deriving FTA diagrams from FMMD models} \label{sec:fta} \fmmdglossFTA % 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, all the causes of system failures down can be traced 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 FMMD is required to produce full FTA diagrams, these attributes must be added to the FMMD UML model\footnote{Top down failure mode models, such as FTA, are additionally useful in guiding diagnostic analysis.}. % \fmmdglossINHIBIT \fmmdglossFTA % %% %% Here could describe how XOR not OR is implemented and how AND %% only works due to failure symptoms being derived from multiple failures. %% This is a tangent and probably detracts from the main flow. %% 02SEP2013 %% \paragraph{Environment, operational states and inhibit gates: additions to the UML model.} % FTA, in addition to using symbols borrowed from digital logic introduces three new symbols to model environmental, operational state and inhibit gates; % we discuss here how these can be incorporated into the FMMD model is discussed below. % 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~\cite{pic18f25k80erratta} 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. % To make FMMD compatible with FTA operational states and environmental conditions should %can %must be factored into the UML model. % An undesired condition may occur where it could be necessary to inhibit some action of the system. This is rather like a logical guard criterion. For instance in the gas burner standard EN298 it 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. \fmmdglossFTA The nature of these three attributes is examined and decisions are made as how they should fit into the UML model for FMMD developed in section~\ref{sec:fmmd_uml}. \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 typically starts having performance problems at {60 \oc} and above. Most electrical components are robust to temperature variations and would not normally require special environmental attributes.}. 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, it is therefore possible to eliminate some failure modes from the model. \fmmdglossFTA \paragraph{Operational states.} % Within the field of safety critical engineering, elements are often encountered that include test or self-test facilities. % Degraded performance (such as only performing certain functions in an emergency) and lockout/emergency conditions are also common conditions that are considered. % These can be broadly termed operational states. %, and apply to the %functional groups. % The UML class is most appropriate to hold a relationship to operational states must be chosen. % 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 operational states are associated with {\fgs}. %therefore are the best objects to model %operational states.% with. \paragraph{Inhibit Conditions.} \fmmdglossINHIBIT 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, this is therefore, linked with both environmental conditions and failure modes. % % % \fmmdglossFTA \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 extended for potential compatibility with FTA: incorporating Environmental, Operational State and Inhibit gates} \label{fig:cfg2} \end{figure} \clearpage \subsection{Retrospective failure mode analysis and FMMD} \fmmdgloss The reasons for applying retrospective failure mode analysis could be: \begin{itemize} %\item approving previously un-assessed systems to a safety standard, \item to re-visit a safety analysis after a small hardware or software change, \item upon discovery of a new {\bc} {\fm}---or in software---a new contract programming requirement, \item or to determine the failure mode behaviour of an previously un-assessed sub-system/instrument used in safety critical verification. \end{itemize} % verification. % FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with its `bottom-up~work~flow' it can reveal previously undetected system failure modes. % This is because the analyst is forced to deal with all component failure modes when applying the FMMD process, and all failure modes of the resultant {\dcs} as the hierarchy is built. % FMMD requires that all failure modes of components in a {\fg} are resolved to a symptom in the resulting {\dc}. % As `complete' analysis can be enforced, FMMD can find failure modes which were missed by other FMEA processes; meaning that the FMMD process can expose un-handled failure modes. %come to light. % % \paragraph{Retrospective failure mode analysis and software.} % Retrospective FMMD can be applied to electronic and software hybrid systems. %as well. % 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). \fmmdgloss \paragraph{Effect of newly discovered failure modes in components.} % Using traditional FMEA when discovering a new failure mode in a component or sub-system it could be difficult to know which parts of the FMEA analysis to re-visit. % For instance, which components in the system should newly discovered failure mode be checked against? % This is linked to the concepts behind the need for failure mode coverage against all components in the system, that provoked discussions leading to idealised XFMEA requirements (see section~\ref{sec:reasoningdistance}). % \fmmdgloss \fmmdglossSFMEA % Using FMMD only those modules in the hierarchy above the component with the new failure mode need be re-visited. % The failure mode DAGs (see section~\ref{sec:chap4}) can be traced to determine exactly which {\fgs} exist in the hierarchy above the affected {\bcs}. % This means that with FMMD the re-work task can be precisely defined. % Also where a new {\bc} {\fm} is merged with an existing symptom in the analysis the re-work need not continue above it in the hierarchy. % That is a new {\bc} {\fm} may cause a symptom already found in the analysis hierarchy. % Finding these could be automated in a software tool that can traverse the failure mode trees. % % 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 functions, they can be integrated into the FMMD model. % FMMD models both software and hardware; thus it can be verified that all failure modes from the electronics module have been dealt with by the controlling software. % If not, they would be an un-handled error condition relating to the software hardware interface. % This again can be flagged using an automated tool. % % 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, design deficiencies are revealed in both the software, the electronics and the software/electronics interface. %in the hardware/software interface. % \fmmdglossFMEDA \fmmdgloss 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, the safe failure fraction (SFF) is raised. % % % % \section{Objective and Subjective Reasoning stages} %Opportunity for formal definitions and perhaps an interface or process for achieving it.... The act of applying failure mode effects analysis, is commonly performed from an `engineering' oriented cause and effect 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 itself, but on the environment in which they are used and other human factors such as the training level of operatives, psychological and logical factors in the Human Machine Interface~(HMI)~\cite{stranks2007human}. % \paragraph{Objective and Subjective Reasoning in FMEA: Three Mile Island nuclear accident example.} An example of objective and subjective factors is demonstrated in the accident report on the 1979 Three Mile Island nuclear accident~\cite{safeware}[App.D]. Here, a vent valve for the primary reactor coolant (pressurised water) became stuck open. This condition causes an objectively derived failure mode --- `leakage~of~coolant' --- due to a stuck valve. % This, if recognised correctly by the operators, would have lead quickly to a reactor shut-down and a maintenance procedure to replace the valve. % The failure was not recognised in time however, and coolant was lost until a partial meltdown of the reactor fuel occurred, with a resulting leak of radioactive material into the environment. % For the objective failure mode determined by FMEA, that of leakage of coolant, it would not be reasonable to expect this to go unchecked and unresolved for an extended period and cause such a critical failure. % The criticality level of that accident was therefore subjective. % It was not known how the operators would have reacted, and deficiencies in the Human Machine Interface (HMI) were not a factor in the failure analysis. \paragraph{Further Work: Objective and Subjective Reasoning in FMEA.} % Criticality prediction can be said to be in the domain of subjective reasoning. % With an objectively defined system level failure it is often required to next determine its level of criticality, or how serious the risk posed would be. % Two methodologies have started to consider this aspect, FMECA~\cite{fmeca} with its criticality and probability factors, and FMEDA~\cite{en61508,fmeda} with its classification of dangerous and safe failures. \fmmdglossFMEDA \fmmdglossFMECA % It is the author's opinion that more work is required to clarify this area. % Accurate models of objective failure modes, are seen by the author to be a pre-requisite for subjective assessment. % The scope of FMMD is the objective level only, but offers significant benefits in terms of accuracy and work savings. % It also offers integrated modelling of software and hardware. % Its failure mode model can also be used to assist in producing traditional FMEA formats. % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %\today%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%