robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

more glossary entries

Browse Source
This commit is contained in:
Robin Clark 2013-08-18 12:52:00 +01:00
parent 1ab3bb4c6a
commit 9c09f45a1a
5 changed files with 76 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
submission_thesis/CH2_FMEA/copy.tex
View File

@ -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.
%

6
submission_thesis/CH3_FMEA_criticism/copy.tex
View File

@ -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,

51
submission_thesis/CH6_Software_Examples/software.tex
View File

@ -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.

13
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -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.

45
submission_thesis/style.tex
View File

@ -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}