diff --git a/submission_thesis/CH2_FMEA/copy.tex b/submission_thesis/CH2_FMEA/copy.tex index 91c4098..7ae73ca 100644 --- a/submission_thesis/CH2_FMEA/copy.tex +++ b/submission_thesis/CH2_FMEA/copy.tex @@ -882,6 +882,7 @@ failure modes as an intrinsic part of its process, which can be considered a wea \paragraph{Failure modes and their observability criterion: detectable and undetectable.} \label{sec:detectable} +\fmmdglossOBS Often the effects of a failure mode may be easy to detect, and our equipment can react by raising an alarm or compensating for the resulting fault. % diff --git a/submission_thesis/CH3_FMEA_criticism/copy.tex b/submission_thesis/CH3_FMEA_criticism/copy.tex index 5b66e26..f6618c8 100644 --- a/submission_thesis/CH3_FMEA_criticism/copy.tex +++ b/submission_thesis/CH3_FMEA_criticism/copy.tex @@ -143,6 +143,7 @@ which components to check the effect of a component failure mode. % on. Typically FMEA will be performed by following the signal path of the component failure mode to its system level effect, echoing fault finding reasoning. +\fmmdglossSIGPATH % This is less than ideal and it can easily miss interactions with adjacent components, that could cause @@ -291,8 +292,9 @@ In terms of FMEA, see figure~\ref{fig:distcon}, our reasoning path spans (at lea Traditional FMEA does not cater for the software hardware interface, and here we have the additional complications %with the additional complications of the communications protocol used to transmit data and the failure mode characteristics -of the communications physical layer. - +of the communications physical layer. This means the signal path will +cross several hardware/software interfaces. +\fmmdglossSIGPATH %(figure~\ref{fig:distcon} The failure reasoning paths for a distributed real time system, with its multiple passes of the hardware/software interface, mean traditional FMEA, for these systems, diff --git a/submission_thesis/CH6_Software_Examples/software.tex b/submission_thesis/CH6_Software_Examples/software.tex index aa0eb31..2ea4fe8 100644 --- a/submission_thesis/CH6_Software_Examples/software.tex +++ b/submission_thesis/CH6_Software_Examples/software.tex @@ -98,14 +98,14 @@ and can use definitions from contract programming to assist. % here. \subsection{Contract programming description} - +\fmmdglossCONTRACTPROG Contract programming~\cite{dbcbe} is a discipline for building software functions in a controlled and traceable way. Each function is subject to pre-conditions (constraints on its inputs), post-conditions (constraints on its outputs) and function wide invariants (rules). \paragraph{Mapping contract `pre-condition' violations to component failure modes.} - +\fmmdglossCONTRACTPROG A precondition, or requirement for a contract software function defines the correct ranges of input conditions for the function to operate successfully. @@ -138,7 +138,7 @@ equivalent to failure mode of `one of its components'. \paragraph{Mapping contract `post-condition' violations to symptoms.} - +\fmmdglossCONTRACTPROG A post condition is a definition of correct behaviour of a function. % A violated post condition is a symptom of failure, or derived failure mode, from a function. @@ -177,7 +177,7 @@ or conditions that the function under analysis deals with or could be affected b % Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology), and to outputs (where violations can be considered {\fms} in FMMD terminology). - +\fmmdglossCONTRACTPROG \subsection{Combined Hardware/Software FMMD} @@ -514,6 +514,7 @@ The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as % From the above contractual programming requirements, we see that the function must be sent the correct channel number. +\fmmdglossCONTRACTPROG % A violation of this can be considered a {\fm} of the function, which we can call $ CHAN\_NO $. @@ -608,14 +609,12 @@ to determine its {\fms}. Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}. We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition we can state, - +% $$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$ - +\fmmdglossCONTRACTPROG We can now form a functional group with the {\dc} $RADC$ and the software component \cf{read\_4\_20\_input}, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $. - - - +% { \tiny \begin{table}[h+] @@ -629,32 +628,32 @@ software component \cf{read\_4\_20\_input}, i.e. $G_3 = \{read\_4\_20\_input, RA \hline \textbf{Failure} & \textbf{Failure } & \textbf{Derived Component} \\ \textbf{cause} & \textbf{Effect} & \textbf{Failure Mode} \\ - - + % + % \hline 1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\ & outside range & $RANGE$ \\ \hline - +% 2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ & incorrect & \\ \hline \hline - - - +% +% + % 3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\ & incorrect & \\ \hline - - - +% +% +% 4: $RADC_{LOW}$ & ADC low voltage & $OUT\_OF\_$ \\ & so out of range & $RANGE$ \\ & i.e. < 0.88V & \\ \hline - + % 5: post condition fails & software fails & $VAL\_ERR$ \\ \hline - +% \hline \hline - +% \end{tabular} \end{table} } @@ -962,7 +961,7 @@ $$ fm(PWM) = \{ HIGH, LOW \}.$$ \paragraph{Micro-Controller.} The Micro controller is a complex piece of highly integrated electronics. - +% At a minimum it would include a micro-processor with PROM and RAM general I/O and external interrupt lines. % @@ -970,7 +969,7 @@ Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM In this project we are using the ADCMUX, TIMER, PWM and general purpose computing facilities. We have to therefore consider the general~computing, CLOCK, PROM and RAM failure modes. $$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$ - +% \subsection{Temperature Controller Software Elements FMMD} Identified Software Components: \begin{itemize} @@ -994,7 +993,7 @@ the function \cf{read\_ADC} and the Pt100. This gives us a {\dc} which we call ReadPt100. % - +% % The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} function and the Pt100 hardware, and has the following failure modes: @@ -1006,6 +1005,7 @@ We move along the afferent flow, and we come to the \cf{convert\_ADC\_to\_T} fun This will call \cf{Read\_ADC} twice, one for the high Pt100 value, again for the lower. % and once for to read a current sense. We then, calculate the resistance of the Pt100 element, and with this---using a polynomial or a lookup table~\cite{eurothermtables}---calculate the temperature. +\fmmdglossCONTRACTPROG The pre-conditions for the function are that: \begin{itemize} % \item The current calculated is within pre-defined bounds i.e. Pt100\_current, @@ -1194,7 +1194,7 @@ determined previously: \end{itemize} The post condition for the monitor function is that it implements the PID control task correctly. - +\fmmdglossCONTRACTPROG We can now create a {\dc} for the standalone temperature controller, and give it the name TempController. It will have the following failure modes: @@ -1221,6 +1221,7 @@ modelled using FMMD. The analysis has revealed system level failure modes that are un-handled and some that are unobservable, but using the FMMD analysis we can trace to the low level modules that are the cause of unobservable failure modes. +\fmmdglossOBS % This means that by using FMMD, we can identify the sub-systems which require re-design to eliminate unobservable failure modes. diff --git a/submission_thesis/CH8_Conclusion/copy.tex b/submission_thesis/CH8_Conclusion/copy.tex index c1bbc97..6012be8 100644 --- a/submission_thesis/CH8_Conclusion/copy.tex +++ b/submission_thesis/CH8_Conclusion/copy.tex @@ -277,7 +277,9 @@ TC:6 $R_2$ OPEN & High Fault & High Fault & 12.42 \\ \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 360 years per circuit. @@ -306,6 +308,8 @@ conditions. \paragraph{Pt100 Example: Double Failures and statistical data} Because we can perform double simultaneous failure analysis under FMMD we can also apply failure rate statistics to double failures. +% +\frategloss % %% %% Need to talk abou the `detection time' @@ -343,6 +347,7 @@ condition, perhaps in higher levels of the system/FMMD hierarchy. % \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 @@ -363,7 +368,7 @@ different behaviour due to environmental or operational states~\cite{nucfta,nasa If we require FMMD to produce full FTA diagrams, we need to add these attributes to the FMMD UML model\footnote{Top down failure mode models, such as FTA, are additionally useful in guiding diagnostic analysis.}. - +\fmmdglossINHIBIT \paragraph{Environment, operational states and inhibit gates: additions to the UML model.} @@ -437,6 +442,7 @@ On this basis we associate operational states with {\fgs}. %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 @@ -526,6 +532,7 @@ By performing FMMD on a software electronic hybrid system, we thus reveal design deficiencies in both the software, the electronics and the software/electronics interface. %in the hardware/software interface. % +\fmmdglossFMEDA 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 @@ -574,6 +581,8 @@ we often are next required to determine its level of criticality, or how serious % 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. The scope of FMMD is the objective level only. diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index ddcb9bc..d7926c1 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -91,9 +91,16 @@ \newcommand{\fmmdglossFIT}{\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur within a $10^{9}$ hour time period.}}} -\newcommand{\fmmdglossHFMEA}{\glossary{name={HFMEA},description={Hardware FMEA. FMEA applied to hardware i.e. mechanical or electrical equipment.}}} -\newcommand{\fmmdglossSFMEA}{\glossary{name={SFMEA},description={Software FMEA. FMEA techniques applied to software. }}} -\newcommand{\fmmdglossXFMEA}{\glossary{name={XFMEA},description={Exhaustive FMEA. Each failure mode is checked for effects on all components in a given system. }}} +\newcommand{\fmmdglossHFMEA}{\glossary{name={HFMEA},description={ +Hardware FMEA. FMEA applied to hardware i.e. mechanical or electrical equipment.}}} + +\newcommand{\fmmdglossSFMEA}{\glossary{name={SFMEA},description={ +Software FMEA. FMEA techniques applied to software. }}} + +\newcommand{\fmmdglossXFMEA}{\glossary{name={XFMEA},description={ +Exhaustive FMEA. Applying FMEA exhaustively means checking each failure mode +for effects on all components in a given system. }}} + \newcommand{\fmmdglossDFMEA}{\glossary{name={DFMEA},description={Design FMEA. FMEA applied in design stages of a product. Used as a discussion method to reveal safety weakness and improve built in safety.}}} \newcommand{\fmmdglossPFMEA}{\glossary{name={PFMEA},description={Production FMEA. FMEA applied applied for cost benefit analysis typically used in mass production.}}} \newcommand{\fmmdglossSFTA}{\glossary{name={SFTA},description={Software Fault Tree Analysis (SFTA): top down failure investigation applied to software.}}} @@ -108,21 +115,37 @@ failure is expected to occur within a $10^{9}$ hour time period.}}} \newcommand{\fmmdglossOBS}{\glossary{name={observability}, description={If it cannot be detected that a failure has occurred it is termed unobservable or undetectable.}}} \newcommand{\fmmdglossSMARTINSTRUMENT}{\glossary{name={smart~instrument}, description={ -A smart instrument is defined as one that uses software +A smart instrument is one that uses software in conjunction with its sensing electronics, rather than analogue electronics only~\cite{smart_instruments_1514209}.}}} + +\newcommand{\fmmdglossCONTRACTPROG}{\glossary{name={contract~programming}, description={ +A software discipline whereby each function is assigned strict pre and post conditions +which define a formalised `contract' for how the function should behave.}}} + % %\newcommand{\fmmdglossRD}{\glossary{name={reasoning~distance}{yahda yahda ya}}} % -\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition (FMMD). a bottom-up methodology 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 hierarchical 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 +\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={ +Failure Mode Modular De-Composition (FMMD). A bottom-up methodology 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 hierarchical 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 failure mode of components in a given system, + +\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={ +Failure Mode and Effects analysis (FMEA) is a process where each failure mode of components in a given system, is analysed to determine system level failures/symptoms.}}} -\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failures 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}}} + +\newcommand{\frategloss}{\glossary{name={failure rate}, description={ +The number of failures 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}}} \usepackage{amsthm}