more glossary entries

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

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, 

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.

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.
@@ -307,6 +309,8 @@ conditions.
 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'
 %% or `Safety Relevant Validation Time' ref can book
@@ -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.
 

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{\fmmdglossHFMEA}{\glossary{name={HFMEA},description={
-\newcommand{\fmmdglossSFMEA}{\glossary{name={SFMEA},description={Software FMEA. FMEA techniques applied to software. }}}
+Hardware FMEA. FMEA applied to hardware i.e. mechanical or electrical equipment.}}}
-\newcommand{\fmmdglossXFMEA}{\glossary{name={XFMEA},description={Exhaustive FMEA. Each failure mode is checked for effects on all components in a given system. }}}
+
+\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 
+\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={
-failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the 
+Failure Mode Modular De-Composition (FMMD). A bottom-up methodology for incrementally building 
-derived components to create higher level functional groups, and so on, that are used to build a hierarchical failure mode model of a system}}}
+failure mode models, using a procedure taking functional groups of components and creating 
-\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 
+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}