From 4ca0a125199a7aac0779425d32dcfc080307c275 Mon Sep 17 00:00:00 2001 From: "Robin P. Clark" Date: Fri, 13 Sep 2013 14:46:13 +0100 Subject: [PATCH] CH6 1st personal pro-noun free --- submission_thesis/CH5_Examples/copy.tex | 2 + .../CH6_Software_Examples/software.tex | 294 ++++++++++-------- submission_thesis/style.tex | 6 + 3 files changed, 166 insertions(+), 136 deletions(-) diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index 22bfcd9..300f43d 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -1219,6 +1219,7 @@ These show that the finer grained models also benefit from lower reasoning dista \section{Sigma Delta Analogue to Digital Converter (\sd).} %($\Sigma \Delta ADC$)} \label{sec:sigmadelta} The following example is used to demonstrate FMMD analysis of a mixed analogue and digital circuit (see figure~\ref{fig:sigmadelta}). +\fmmdglossADC \begin{figure}[h] \centering \includegraphics[width=300pt]{./CH5_Examples/circuit4004.png} @@ -1264,6 +1265,7 @@ It is level converted to an analogue signal by IC3---i.e. a digital 0 becomes a and fed into the summing integrator completing the negative feedback loop. % In essence this implements an over-sampling one bit analogue to digital converter~\cite{ehb}[pp.729-730]. +\fmmdglossADC The output of the flip flop forms a bit pattern representing the value of the input voltage (i.e. the value of the sum of 1's and 0's is proportional to the voltage value at the input). diff --git a/submission_thesis/CH6_Software_Examples/software.tex b/submission_thesis/CH6_Software_Examples/software.tex index c8fd213..9d7f6a7 100644 --- a/submission_thesis/CH6_Software_Examples/software.tex +++ b/submission_thesis/CH6_Software_Examples/software.tex @@ -5,17 +5,19 @@ \section{Software and Hardware Failure Mode Concepts} \label{sec:elecsw} -In this chapter we show that FMMD can be applied to both software and electronics enabling us to build complete failure models +% +In this chapter it is shown that FMMD can be applied to both software and electronics enabling us to build complete failure models of typical modern safety critical systems. % With modular FMEA i.e. FMMD %(FMMD) -we have the concepts of failure~modes -of components, {\fgs} and symptoms of failure. % for a functional group. +the concepts of failure~modes +of components, {\fgs} and symptoms of failure have been defined. % for a functional group. % A programmatic function has similar attributes to an FMMD {\fg}. % with these concepts. %a {\fg} as defined by the FMMD process. % An FMMD {\fg} is placed into a hierarchy, likewise a software function is typically placed into the hierarchy of its call-tree. +% A software function calls other functions and uses data sources %via hardware interaction which could be viewed as its `components': it has outputs, i.e. it can perform actions on data or hardware. @@ -31,9 +33,9 @@ Its outputs are the data it changes, or the hardware actions it performs. %% will react and how to interpret readings---but they do not %% always cover the failure modes of the hardware being interfaced too. % -When we have analysed a -software function---using failure conditions of its inputs as a source of failure modes---we can -determine its symptoms of failure (i.e. how functions that call it will see its failure mode behaviour). +When a +software function has been analysed---using failure conditions of its inputs as a source of failure modes---its symptoms of failure +can be defined (i.e. how functions that call it will see its failure mode behaviour). % FMMD is applied to software functions by viewing them in terms of their failure mode behaviour. @@ -41,24 +43,26 @@ FMMD is applied to software functions by viewing them in terms of their failure That is to say, using FMMD, software functions are treated like {\fgs} of electronic components. % % -As software already fits into a hierarchy, we have one less analysis decision to make when compared +As software already fits into a hierarchy, there one less analysis decision to make when compared to analysing electronics. % -For electrical and mechanical systems, although we may be guided by the original designers -concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs} +For electrical and mechanical systems, original designers +concepts of modularity and sub-systems in design may provide guidance, +applying FMMD means deciding on the members for {\fgs} and the subsequent hierarchy. % With software already written, the hierarchies are given. % -To apply FMMD to software, we collect the elements used by a software function, along with the function itself +To apply FMMD to software, the elements used by a software function are collected, along with the function itself to form a {\fg}. % -When we have analysed the failure mode behaviour of this {\fg} -and have its failure mode symptoms, we can create a {\dc}. +When the failure mode behaviour of this {\fg} has been analysed and its failure mode symptoms collected, a {\dc} can be created. % That {\dc} can be -used by functions that call the function we have just analysed, until -we form a complete failure mode hierarchy of the system under investigation. +used by functions that call the function just analysed. +% +This software analysis can be applied from the bottom-up on the software call tree, +until a complete failure mode hierarchy of the system under investigation has been built. % map the FMMD concepts of {\fms}, {\fgs} and {\dcs} %to software functions. % @@ -82,7 +86,7 @@ we form a complete failure mode hierarchy of the system under investigation. Software written for safety critical systems is usually constrained to be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{iec61511}. % -Because of this we can assume direct call trees\footnote{A typical embedded system +Because of this direct call trees can be assumed\footnote{A typical embedded system will have a run time call tree, and (possibly multiple) interrupt sourced call trees.}. % Functions call functions @@ -93,17 +97,16 @@ What is potentially difficult with applying FMMD to a software function, is deci its component failure modes %(in electronics the failure modes of its components)---and and its symptoms of failure in a manner compatible with the FMMD process. %(the failure modes of a function taken as a {\dc}) are. % -With electronic components, we can use literature to point us to suitable sets of +With electronic components, the literature to points to suitable sets of {\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}. %~\cite{en61508}~\cite{en298}. +% With software only some library functions are well known and rigorously documented enough to have the equivalent of known failure modes, most software is `bespoke'. % -We need a different strategy to +A different strategy is required to describe the failure mode behaviour of software functions, %. -%We -and -can use definitions from contract programming to assist. % here. +definitions from contract programming can be used to assist in this. % here. \subsection{Contract programming description} \fmmdglossCONTRACTPROG @@ -121,7 +124,7 @@ to operate successfully. % C Garret said this was unclear so I have added the following two sentences. % %If we consider a software function to be a {\fg} in the FMMD sense, i.e. -We can consider a software function to be +A software function is considered to be a collection of code, functions called and %values/ variables used. % @@ -129,20 +132,20 @@ In this way it is similar to an electronic circuit, which is a collection of components connected in a specific way. % Using this analogy for software, the connections are the functions code, and the -called functions %and variables +called functions/variables/inputs %and variables are the components. % Erroneous behaviour from called functions and variables/inputs has the same effect as component failure modes on an electronic {\fg}. % % -If we consider the -called functions and variables/inputs to be components of a function, -we can build a modular and hierarchical failure mode model -from existing software. +If it is considered that %consider the +called functions and variables/inputs are the components of a function, +a modular and hierarchical failure mode model +from existing software can be built. % -Thus for FMMD applied to software, we consider a violation of a pre-condition to be -equivalent to failure mode of `one of its components'. +Thus for FMMD applied to software, a violation of a pre-condition is considered to be +equivalent a failure mode of `one of its components'. \paragraph{Mapping contract `post-condition' violations to symptoms.} @@ -174,7 +177,7 @@ incorrectly handled interrupt contention~\cite{concurrency_c_tool} which could cause side effects in software. % For the failure mode model of any software function, -we must consider that all failure modes defined by post-condition +it must be considered that all failure modes defined by post-condition violations could simply occur. %`components'. @@ -192,8 +195,8 @@ and to outputs (where violations can be considered symptoms, or derived {\fms}, \subsection{Combined Hardware/Software FMMD} -For the purpose of example, we chose a simple common safety critical industrial circuit -that is nearly always used in conjunction with a programmatic element. +For the purpose of example, a simple common safety critical industrial circuit +that is nearly always used in conjunction with a programmatic element has been chosen. % A common method for delivering a quantitative value in analogue electronics is to supply a current signal to represent the value to be sent~\cite{aoe}[p.934]. @@ -242,46 +245,48 @@ The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending signal to a micro-controller system. The signal is locally driven through a load resistor, and then read into the micro-controller via an ADC and its multiplexer. -With the voltage determined at the ADC, we read the intended quantitative -value from the external equipment. +% +With the voltage determined at the ADC, the intended quantitative +value from the external equipment is read. \section{Simple Software Example: Reading a \ft input into software} Consider a software function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) -representing the current detected with an additional error indication flag. +representing the current detected; plus an additional error indication flag. % -Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage +Let us assume the {\ft} detection is via a \ohms{220} resistor, and that a voltage is read from an ADC into the software. -Let us define any value outside the 4mA to 20mA range as an error condition. % -As we read a voltage, we use Ohms law~\cite{aoe} to determine the mA current detected: $V=IR$, $0.004A * \ohms{220} = 0.88V$ -and $0.020A * \ohms{220} = 4.4V$. +Any value outside the 4mA to 20mA range can be defined as an error condition. % -Our acceptable voltage -range\footnote{For the purpose of clarity we are ignoring resistor tolerance +As voltage (rather than current) is read by an ADC, Ohms law~\cite{aoe} is used to +determine the mA current detected: $V=IR$, $0.004A \times \ohms{220} = 0.88V$ +and $0.020A \times \ohms{220} = 4.4V$. +% +The acceptable voltage range\footnote{For the purpose of clarity we are ignoring resistor tolerance for this example. In a practical {\ft} reader we would factor in resistor tolerance to the limits, or allow `deadbands' of $\approx \half mA$ at either end of the range.} is therefore $$(V \ge 0.88) \wedge (V \le 4.4) \; .$$ -This voltage range forms our input requirement and can be considered as an invariant condition -(i.e. both a pre-condition and a postcondition; -for the system to be operating correctly the voltage should be within the above bounds). +This voltage range forms an input requirement and can be considered as an invariant condition +i.e. both a pre-condition and a postcondition; +for the system to be operating correctly the voltage should be within the above bounds. % -We can now examine a software function that performs a conversion from the voltage read to -a per~mil representation of the {\ft} input current. +The software function that performs a conversion from the voltage read to +a per~mil representation of the {\ft} input current is now discussed. % For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is used. % A 'C' function is declared with parenthesis to -differentiate from other type of variables (data types or pointers). +differentiate it from other type of variables (data types or pointers). % -In this document we borrow that format, hence the C~language +In this document this format is borrowed, hence the C~language function called `main' will be presented as \cf{main}. % -We initially assume a function \cf{read\_ADC} that returns a floating point %double precision +A function \cf{read\_ADC} is assumed that returns a floating point %double precision value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). @@ -329,7 +334,7 @@ int read_4_20_input ( int * value ) { %\label{fig:420i} \end{figure} \clearpage -We now look at the function called by \cf{read\_4\_20\_input}, \cf{read\_ADC}, which returns a +The function called by \cf{read\_4\_20\_input}, \cf{read\_ADC} is now examined; this returns a voltage for a given ADC channel. % This function @@ -391,7 +396,7 @@ double read_ADC( int channel ) { \end{figure} \clearpage % -We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. +A very simple software structure, a call tree, shown in figure~\ref{fig:ct1} has been obtained. % \begin{figure}[h] \centering @@ -409,10 +414,10 @@ FMEA is always a bottom-up process and so we must begin with this hardware. The hardware is simply a load resistor, connected across an ADC input pin on the micro-controller and ground. % -We can identify the resistor and the ADC module of the micro-controller as -the base components in this design. +The resistor and the ADC module of the micro-controller are identified as +the {\bcs} in this design. % -We now apply FMMD starting with the hardware. +FMMD is now applied, from the bottom-up, starting with the hardware. % % \subsection{FMMD Process} @@ -427,13 +432,15 @@ It is therefore a hardware only {\fg}. % %We now determine the {\fms} of all the components in $G_1$. -We now determine the {\fms} of all the components in the {\fg} $G_1$. -For the resistor we can use a failure mode set from the literature~\cite{en298}. +The {\fms} of all the components in the {\fg} $G_1$ are now determined. +% +For the resistor the failure mode set from the literature~\cite{en298} is used. +% Where the function $fm$ returns a set of failure modes for a given component: % we state: $$ fm(R) = \{OPEN,SHORT\}. $$ \vbox{ -For the ADC we can determine the following failure modes: +For the ADC the following failure modes are determined: \begin{itemize} \item STUCKAT --- The ADC outputs a constant value, @@ -443,7 +450,7 @@ For the ADC we can determine the following failure modes: \end{itemize} } We can use the function $fm$ to define the {\fms} of an ADC thus: -$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$ +$$ fm(ADC) = \{ STUCKAT, MUXFAIL, LOW, HIGH \}. $$ % With these failure modes defined, analysis can begin on the {\fg} $G_1$, see table~\ref{tbl:cmatv}. @@ -502,26 +509,28 @@ The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as in valid ADC range b) voltage ref is 0.1\% of 5V */}. % -From the above contractual programming requirements, we see that +From the above contractual programming requirements, it is seen 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 $. +which is termed $ CHAN\_NO $. % The reference voltage for the ADC has a 0.1\% accuracy requirement. % If the reference value is outside this, it is also a {\fm} -of this function, which we can call $V\_REF$ (nb: this failure mode is detectable %observable -only if we specifically use a test input to measure the reference). +of this function, +which is termed $V\_REF$ (nb: this failure mode is detectable %observable +only if a test input is used to measure a high precision voltage reference). % -Taken as a component for use in FMEA/FMMD our function has -two failure modes. We can therefore treat it as a generic component, $Read\_ADC$, +Taken as a component for use in FMEA/FMMD the function has +two failure modes. Therefore it can be treated as a generic component, $Read\_ADC$, by stating: % $$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $$ % -With the failure mode model for our function, we use it in conjunction +With the failure mode model for our function, it is used in conjunction with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$. % This analysis is performed in table~\ref{tbl:radc}. %{ hardware/software combined {\fg}. @@ -547,7 +556,7 @@ This analysis is performed in table~\ref{tbl:radc}. %{ hardware/software combine & wrong channel & \\ \hline 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline 6: post-condition fails & software fails & $VV\_ERR$ \\ - & C function: Read\_ADC & \\ \hline + & C function: Read\_ADC & \\ \hline \hline \end{tabular} @@ -563,7 +572,7 @@ corresponds to $VV\_ERR$, and happens to already be in the {\fm} set for this { % %We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following %{\fms}: -We can now create a {\dc} called $RADC$ with its failure modes thus: +A {\dc} called $RADC$ is created with failure modes of: $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ % % @@ -575,7 +584,7 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ % The next function higher in the call tree is \cf{read\_4\_20\_input}: This function calls the function \cf{Read\_ADC} which -is a member of the {\fg} from which we derived the {\dc} $RADC$. +is a member of the {\fg} from which the {\dc} $RADC$ was derived. % %and therefore sits on top of the {\dc} $RADC$ in the FMMD hierarchy. %determined above. @@ -689,8 +698,8 @@ software and electrical %electro-mechanical FMMD models. % With this analysis -we have a complete `reasoning~path' linking the failures modes from the -electronics to those in the software. +a complete `reasoning~path' linking the failures modes from the +electronics to those in the software has been created. % Each functional group to {\dc} transition represents a reasoning stage\footnote{Each of these reasoning stages, will have a reasoning distance @@ -707,22 +716,24 @@ it stretches from the component failure mode to the %top---or---system top or system level failure. For this reason applying traditional FMEA to software stretches the reasoning distance even further. This is exacerbated by the fact that traditional SFMEA is -performed separately from HFMEA~\cite{sfmea,sfmeaa}, additionally even the software/hardware +performed separately from Hardware FMEA (HFMEA)~\cite{sfmea,sfmeaa}, additionally even the software/hardware interfacing is usually treated as a separate FMEA task~\cite{sfmeainterface,embedsfmea,procsfmea} +\fmmdglossHFMEA - -We now have a {\dc} for a {\ft} input in software. +A {\dc} for a {\ft} input in software has now been defined. +% Typically, more than one such input could be present in a real-world system. -Not only have we integrated electronics and software in an FMEA, we can also -re-use the analysis for each {\ft} input. +% +Not only have we integrated electronics and software in an FMEA, the analysis for the {\ft} input can be re-used. %(i.e. in a typical system using this type of signalling %we would often have several {\ft} inputs). The unsolved symptoms, or undetectable -%unobservable errors, i.e. $VAL\_ERR$ could be addressed by another software function to read other known signals -via the MUX (i.e. voltage references). This strategy would +via the MUX (i.e. voltage references). +% +This strategy would detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. Where the integrity of the MUX is very demanding, separate pull down test lines may be implemented on the germane inputs as well. % @@ -801,19 +812,23 @@ A structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004} is \label{fig:context_diagram_PID} \end{figure} % -Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its data flow, starting +Using figure~\ref{fig:context_diagram_PID} the system in terms of its data flow is reviewed, starting with the data sources (the Pt100 temperature sensor inputs) and the data sinks (the heater output and the LED indicators). % -We have two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor. -For the Pt100 sensor, we will need to read the voltages it outputs and %for -this -will therefore require an ADC and MUX. +There are two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor. % -For the output, we can use a Pulse Width Modulator (PWM) (this is a common module found on micro-controllers -%allowing a +For the Pt100 sensor, the voltages it outputs are read and %for +this requires an ADC and MUX. +% +\fmmdglossADC +% +For the output, a Pulse Width Modulator (PWM) can be used (this is a common module found on micro-controllers facilitating -variable power output~\cite{aoe}[p.360]). PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}[Ch.15]. -We refine the Yourdon diagram, with the afferent data flow coming through the MUX and ADC on the micro-controller, and the efferent +variable power output~\cite{aoe}[p.360]). +% +PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}[Ch.15]. +% +The Yourdon diagram is refined, by adding detail to both the afferent data flow coming through the MUX and ADC on the micro-controller and the efferent channelled through a PWM module. %again built into the micro-controller, % %and add more detail, see figure~\ref{fig:context_diagram2_PID}. @@ -825,12 +840,13 @@ channelled through a PWM module. %again built into the micro-controller, \caption{Yourdon Context Diagram for PID Temperature Controller.} \label{fig:context_diagram2_PID} \end{figure} -The Yourdon methodology allows us to zoom into data transform bubbles, analyse them in more -depth and create more paths and transform bubbles which further define the data flow and processing. % required. +% +The Yourdon methodology provides model refinement, by zooming into data transform bubbles, analysing them in more +depth and creating more paths and transform bubbles which further define the data flow and processing. % required. % This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}. % -We define the controlling software, by looking at or zooming into transform bubbles +The controlling software is defined, by looking at or zooming into transform bubbles and refining them by adding detail. % Following the data streams through the process, additional transform bubbles are created as required. @@ -851,17 +867,18 @@ defining software functions in its final stage. In all `bare~metal'\footnote{`Bare~metal' is a term used to indicate a micro-processor controlled system that does not use a traditional operating system. These are generally coded in 'C' or assembly language and run immediately from power-up.} -software architectures, we need a rudimentary operating system, often referred to as the `monitor'. +software architectures, a rudimentary operating system is required, often referred to as the `monitor'. % -We bear in mind that PID, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive -and we therefore need to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients. +PID, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive +and it is necessary to execute it at precise intervals determined by its proportional, integral and differential (PID) coefficients. % Most micro-controllers feature several general purpose timers~\cite{pic18f2523}. -We can use an internal timer in conjunction with the monitor function +% +An internal timer can be used in conjunction with the monitor function to call the PID algorithm at a regular and precise time interval. % specified interval. % \paragraph{Data flow model to programmatic call tree.} -The Yourdon methodology also gives us a guide as to which software +The Yourdon methodology also gives guidance as to which software functions should be called to control the process, or in `C' terms be the main function. % \begin{figure}[h] @@ -872,8 +889,8 @@ functions should be called to control the process, or in `C' terms be the main f \label{fig:contextsoftware} \end{figure} % -Using figure~\ref{fig:contextsoftware} we can now pick the transform bubble we -want to be the `main' or controlling function in the software. +Using figure~\ref{fig:contextsoftware} the transform bubble +to represent the `main' or controlling function in the software must be chosen. % This can be thought of as picking one bubble and holding it up. % @@ -908,14 +925,14 @@ function (i.e. the PID demand which will be returned to the monitor function). %On returning to the monitor function, it will return the PID demand value. The PID demand value will be applied via the PWM. % -We now have a rudimentary closed loop control system incorporating both hardware and software. +A rudimentary closed loop control system incorporating both hardware and software has been defined. % -By using the Yourdon methodology we obtain a programmatic design frame-work i.e. a call tree structure. +By using the Yourdon methodology a programmatic design frame-work i.e. a call tree structure was obtained. % -We now have all the components, i.e. hardware elements and software functions -that will be used in the temperature controller. +All the components, i.e. hardware elements and software functions +that will be used in the temperature controller are now defined. % -We list these, and begin, from the bottom-up, to apply FMMD analysis. +These are listed, and from the bottom-up, FMMD analysis is applied. % \clearpage \subsection{FMMD Analysis of PID temperature Controller} @@ -941,19 +958,20 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ % % \paragraph{TIMER.} +% The internal timer, from a programmer's perspective is a register, which when read returns an incremented time value. % Essentially its a free running integer counter with an interfacing register. % Using two's complement mathematics, by subtracting -the time we last read it, we can calculate the interval +the time last read value, we can calculate the interval between readings (assuming the timer has not wrapped around more than once). % -We can say that a timer can fail by +A timer can fail by incrementing its value at an incorrect rate, or can stop incrementing. % -We define the failure modes of $TIMER$ thus: +The failure modes of $TIMER$ are defined thus: $$ fm(TIMER) = \{ STOPPED, INCORRECT\_INTERVAL \}.$$ % \paragraph{HEATER.} @@ -978,7 +996,7 @@ a means of varying the amount of power supplied. When the PWM action is halted, or fails, the digital output pin associated with it will typically be held in a high or low state. % -We therefore state: +The PWM has the following failure modes: $$ fm(PWM) = \{ HIGH, LOW \}.$$ \paragraph{Micro-Controller.} @@ -991,7 +1009,7 @@ Typically there are many other I/O modules incorporated (e.g. TIMERS, UARTS, PWM % In this project the ADCMUX, TIMER, PWM and general purpose computing facilities are used. % -We have to therefore consider the general~computing, CLOCK, PROM and RAM failure modes. +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} @@ -1007,28 +1025,28 @@ Identified Software Components: % % With the call tree structure defined (see figure~\ref{fig:context_calltree}), -we have a hierarchy compatible with FMMD for analysis. +hierarchy compatible with FMMD for analysis is obtained. However, it is only the top, the software, part of the hierarchy. % -FMMD is a bottom-up process and we must start at the lowest level, the electronics. +FMMD is a bottom-up process thus start at the lowest level, i.e. the electronics. % The Yourdon context diagram (see figure~\ref{fig:context_diagram_PID}) is useful here as its data sources and sinks are by definition the lowest levels in a system. % -We can follow the input, or afferent data flow to find the bottom levels for system inputs +The input, or afferent data flow can be followed to find the bottom levels for system inputs and the output, or efferent flow to find the bottom level for outputs/actuators etc. % Starting with the afferent flow, the reading of the temperature and its conversion to a PID calculated heater output demand is examined. % \subsubsection{Afferent flow FMMD analysis, Pt100, temperature, set point error, PID output demand.} -Staring with the afferent data flow for the temperature readings, we find the lowest -level in the hierarchy, the Pt100 sensor. +Staring with the afferent data flow for the temperature readings, the lowest +level in the hierarchy is found, the Pt100 sensor. %with the software, and consider the hardware elements %used (if any) by each software function. -Starting at the bottom, we form a {\fg} with +Starting at the bottom, a {\fg} is formed with the function \cf{read\_ADC} and the Pt100. -This gives us a {\dc}, %which we call +This gives a {\dc}, %which we call `Read\_Pt100'. % % @@ -1043,8 +1061,8 @@ Moving along the afferent flow, the \cf{convert\_ADC\_to\_T} function is next % This will call \cf{Read\_ADC} twice, once 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. +The resistance of the Pt100 element is then calculated, and with this---using a +polynomial or a lookup table~\cite{eurothermtables}---the temperature determined. % \fmmdglossCONTRACTPROG % @@ -1055,6 +1073,7 @@ The pre-conditions for the function are that: \item The higher Pt100 value is within an acceptable voltage range i.e. Pt100\_higher\_voltage, \item The lower and higher values agree to within a given tolerance i.e. Pt100\_high\_low\_mismatch. \end{itemize} +% Any violation of these pre-conditions is equivalent to a failure mode. % Note that a temperature outside the pre-defined range would be detected as an acceptable voltage @@ -1065,9 +1084,10 @@ The post-condition is that it returns a temperature within a given tolerance to A failure of this post-condition can be termed temp\_incorrect. % \clearpage -We apply FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}. +Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}. +gives the {\dc} {Get\_Temperature}. % -We can call the resulting {\dc} {Get\_Temperature}. This analysis is presented in table~\ref{tbl:gettemperature}. +This analysis is presented in table~\ref{tbl:gettemperature}. % The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}. % @@ -1097,8 +1117,8 @@ considered (see section~\ref{sec:Pt100floating}). % The post-condition thus has two variants, an incorrect value that is detected, KnownIncorrectErrorValue %where we can detect the Pt100 value is suspect, -and IncorrectErrorValue where we simply have -an incorrect value but cannot determine this. +and IncorrectErrorValue where there is simply +an incorrect value but this cannot be determined (i.e. its an undetectable failure). % this. % This analysis is presented in table~\ref{tbl:geterror}. % @@ -1207,7 +1227,7 @@ adding a safety relay to cut the power to the heater). % The status LEDS will be controlled by general purpose (GPIO) I/O pins. % -We could have three LEDS, one flashing with a human readable mark +Three LEDS could be used, one flashing with a human readable mark space ratio representing the heater output, one flashing at a regular interval to indicate the processor is alive and another flashing at an interval related to the temperature, (to indicate if the temperature readings are within expected ranges). @@ -1275,11 +1295,13 @@ determined previously: % 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. +A {\dc} for the standalone temperature controller is now created, and given the name TempController. It will have the following failure modes: % -$$fm ( TempController ) = \{ ControlFailureIndicated, ControlFailure, \\ -KnownIndicationError, UnknownIndicationError \}.$$ +\begin{equationarry} + fm ( TempController ) = \{ ControlFailureIndicated, \\ ControlFailure, \\ KnownIndicationError, \\ UnknownIndicationError \}. +\end{equationarry} + % % The failure mode analysis of the complete PID controller is represented @@ -1299,30 +1321,30 @@ as an Euler diagram in figure~\ref{fig:euler_temp_controller}. The PID temperature control example above, shows that complete hybrid software/electronic systems can be modelled using FMMD. % -The analysis has revealed system level failure modes that are un-handled and some that are undetectable, -but using the results from FMMD analysis we can trace down to the low level modules that are the cause of problematic -failure modes. +The analysis has revealed system level failure modes that are un-handled and some that are undetectable. +The FMMD model can be traversed from undesirable top level failures to the {\bc} {\fms} that are the cause. \fmmdglossOBS % -This means that by using FMMD, we can identify the sub-systems which require -re-design to eliminate or reduce the likelihood of undetectable failure modes. +This means that by using FMMD, the sub-systems which require +re-design to eliminate or reduce the likelihood of undetectable failure modes can be identified. % The demands of EN61508~\cite{en61508} for minimum safe failure fraction thresholds~\cite{scsh}[p.52] associated with SIL levels, make this a desirable feature of any FMEA based methodology. % For the failure modes caused -by electronics, we can apply reliability statistics and possibly use higher rated -components instead of expensive re-design. +by electronics, reliability statistics can be applied, and the possibilities of using higher rated +components instead of expensive re-design can be simulated/modelled. % -For software errors, we could, if necessary provide extra functions to provide self checking. -We could follow EN61508 high reliability software measures such as -duplication of functions with checking functions arbitrating them (diverse programming~\cite{en61508}[C.3.5]). +For software errors, it may be necessary to provide extra functions to provide self checking. % -We could for instance, validate the processor clocking with an external watchdog and a simple -communications protocol. For PROM and RAM faults we can implement measures such as run-time checksums -and ram complement checking. +EN61508 high reliability software measures such as +duplication of functions with checking functions arbitrating them (diverse programming~\cite{en61508}[C.3.5]) could be applied. % -Using FMMD in conjunction with extra safety measures we can ensure no single failure could lead to a +For instance, measures may included to validate the processor clocking with an external watchdog and a simple +communications protocol. For PROM and RAM faults measures such as run-time checksums +and ram complement checking can be applied. +% +Using FMMD in conjunction with extra safety measures it can be ensured that no single failure could lead to a system failure, something difficult to prove with current FMEA techniques. diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index 2176c7c..23ceb2b 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -80,6 +80,12 @@ % \newcommand{\fmmdname}{\glossary{name={FMMDNAME},description={ }} %\fmodegloss +\newcommand{\fmmdglossHFMEA}{\glossary{name={system}, description={ +Failure Mode Effect Analysis applied to hardware only (i.e. specifically not applied to software)}}} + +\newcommand{\fmmdglossADC}{\glossary{name={system}, description={ +Analogue to digital converter}}} + \newcommand{\fmmdglossSYS}{\glossary{name={system}, description={ A product designed to work as a coherent entity}}}