From a64abda4ec147ad987eb7e5d07b1448019715704 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Thu, 26 Sep 2013 20:05:48 +0100 Subject: [PATCH] Got to look at appendix A its a bit ropey --- submission_thesis/CH2_FMEA/copy.tex | 2 +- .../CH6_Software_Examples/software.tex | 129 ++++++++++-------- .../appendixes/detailed_analysis.tex | 32 ++--- 3 files changed, 91 insertions(+), 72 deletions(-) diff --git a/submission_thesis/CH2_FMEA/copy.tex b/submission_thesis/CH2_FMEA/copy.tex index 140c553..2510e16 100644 --- a/submission_thesis/CH2_FMEA/copy.tex +++ b/submission_thesis/CH2_FMEA/copy.tex @@ -780,7 +780,7 @@ looking at a {\fm}'s effects on all other components in the system. % be necessa % In practise, a compromise is made between the amount of time/money that can be spent on analysis relative to the criticality of the project. -Metrics from measuring the amount of work to undertake for FMEA are examined in section~\ref{sec:xfmea}. +Metrics for measuring the amount of work to undertake for FMEA are examined in section~\ref{sec:xfmea}. \paragraph{Failure Modes and the signal path.} \fmmdglossSIGPATH diff --git a/submission_thesis/CH6_Software_Examples/software.tex b/submission_thesis/CH6_Software_Examples/software.tex index 294f04d..578d9e3 100644 --- a/submission_thesis/CH6_Software_Examples/software.tex +++ b/submission_thesis/CH6_Software_Examples/software.tex @@ -53,7 +53,7 @@ and the subsequent hierarchy. % With software already written, the hierarchies are given. % -To apply FMMD to software, the elements used by a software function are collected, 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 the failure mode behaviour of this software {\fg} has been analysed and its failure mode symptoms collected, a {\dc} can be created. @@ -105,8 +105,8 @@ enough to have the equivalent of known failure modes, most software is `bespoke'. % A different strategy is required to -describe the failure mode behaviour of software functions, %. -definitions from contract programming can be used to assist in this. % here. +describe the failure mode behaviour of software functions; %. +concepts from contract programming can be used to assist in this. % here. \subsection{Contract programming description} \fmmdglossCONTRACTPROG @@ -254,10 +254,9 @@ value from the external equipment is read. 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; plus an additional error indication flag. % -From figure~\ref{fig:ftcontext} the {\ft} detection is via a \ohms{220} resistor and the a voltage is read -from an ADC into the software. +From figure~\ref{fig:ftcontext} the {\ft} detection is via a \ohms{220} resistor and the voltage is read from an ADC into the software. % -Because the signal is {\ft} +Because the signal is specified as {\ft} any value outside the 4mA to 20mA range can be defined as an error condition. % As voltage (rather than current) is read by an ADC, Ohms law~\cite{aoe} is used to @@ -275,16 +274,17 @@ This voltage range forms an input requirement and can be considered as an invari i.e. both a pre-condition and a postcondition; for the system to be operating correctly the voltage should be within the above bounds. % -The software function that performs a conversion from the voltage read to -a per~mil representation of the {\ft} input 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 +In 'C' a function is declared with parenthesis to differentiate it from other type of variables (data types or pointers). % In this document this format is borrowed, hence the C~language function called `main' will be presented as \cf{main}. +% +The software function that performs a conversion from the voltage read to +a per~mil representation of the {\ft} input is now discussed. +% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % 26SEP2013 addition %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -298,7 +298,7 @@ value which it returns via a pointer. The source code is presented in figure~\re % % 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}). +value which represents the voltage read (see code sample in figure~\ref{fig:code_read_ADC}). %%{\vbox{ @@ -344,15 +344,15 @@ int read_4_20_input ( int * value ) { \label{fig:code_read_4_20_input} %\label{fig:420i} \end{figure} -\clearpage +%\clearpage 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 deals directly with the hardware in the micro-controller on which the software is running. %software on. % -The function \cf{read\_ADC}'s job is to select the correct channel (ADC multiplexer) and then to initiate a -conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}). +The function \cf{read\_ADC}s' job is to select the correct channel (ADC multiplexer) and then to initiate a +conversion by setting an ADC `go' bit (see code sample in figure~\ref{fig:code_read_ADC}). % It takes the raw ADC reading and converts it into a floating point\footnote{the type, `double' or `double precision', is a @@ -420,7 +420,7 @@ A very simple software structure, a call tree, shown in figure~\ref{fig:ct1} has This software is above the ADC hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the the software is reading values from the `lower~level' electronics. % -FMEA is always a bottom-up process and so we must begin with this hardware. +%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. @@ -433,7 +433,7 @@ FMMD is now applied, from the bottom-up, starting with the hardware. % \subsection{FMMD Process} % -\paragraph{Hardware only Functional Grouping - Convert mA to Voltage - CMATV} +\paragraph{Hardware only Functional Grouping - Convert mA to Voltage - CMATV.} % This {\fg}, $G_1$, contains the load resistor and the physical Analogue to Digital Converter (ADC). @@ -441,14 +441,14 @@ and the physical Analogue to Digital Converter (ADC). $G_1$ is thus a set of base components: $G_1 = \{R, ADC\}.$ It is a hardware only {\fg}. % - +% %We now determine the {\fms} of all the components in $G_1$. 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 the following failure modes are determined: @@ -539,10 +539,16 @@ This validates the supply voltage to the ADC. This is common practise for safety critical readings when using an 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, $\cf{Read\_ADC}$, +two failure modes. +%Any violations of postconditions for software functions in the {\fg} $G_2$ must be added to this set. +%This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */}, +%causes the symptom $VV\_ERR$, which happens to already be in the {\fm} set for this {\fg}. +It can also fail its post condition, which is given the symptom $VV\_ERR$. +% +Therefore it can be treated as a generic component, $\cf{Read\_ADC}$, by stating: % -$$ fm(\cf{Read\_ADC}) = \{ CHAN\_NO, VREF \} $$ +$$ fm(\cf{Read\_ADC}) = \{ CHAN\_NO, VREF, VV\_ERR \} $$ % 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 =\{ CMATV, \cf{Read\_ADC} \}$. @@ -580,9 +586,12 @@ This {\fg} is analysed in table~\ref{tbl:radc}. %{ hardware/software combined {\ % % The common symptoms of failure from table~\ref{tbl:radc} are collected giving -$\{ VV\_ERR, HIGH, LOW \}$. Any violations of postconditions for software functions in the {\fg} $G_2$ must be added to this set. -This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */}, -causes the symptom $VV\_ERR$, which happens to already be in the {\fm} set for this {\fg}. +$\{ VV\_ERR, HIGH, LOW \}$. +% +% Any violations of postconditions for software functions in the {\fg} $G_2$ must be added to this set. +% This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */}, +% causes the symptom $VV\_ERR$, which happens to already be in the {\fm} set for this {\fg}. +% % %We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following %{\fms}: @@ -595,7 +604,7 @@ This {\dc} is a hybrid of software and hardware, and is an example of a hardware % % % -\paragraph{Functional Group - Software - voltage to per mil - VTPM } +\paragraph{Functional Group - Software - voltage to per mil - VTPM.} % The next function higher in the call tree is \cf{read\_4\_20\_input}: This function calls the function \cf{Read\_ADC} which @@ -667,7 +676,8 @@ The $VAL\_ERR$ will simply mean that the value read is incorrect: an undetectabl and therefore undesirable condition. % Finally a {\dc} is created to represent a failure mode model for our -combined hardware and software {\ft} input failure mode model. +combined hardware and software {\ft} input. % failure mode model. +% This can be named $ R420I $, for {\em read {\ft} input}. %function $read\_4\_20\_input$. %thus: % @@ -739,14 +749,15 @@ 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, the analysis for the {\ft} input can be re-used. +%Not only have we integrated electronics and software in an FMEA, the analysis for the {\ft} input can be re-used. +This {\dc} could thus 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 errors, i.e. $VAL\_ERR$ could be addressed by another software function to read other known signals -via the MUX (i.e. voltage references). +via the multiplexer (MUX) (i.e. voltage references). % This strategy would detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. Where the integrity of @@ -755,8 +766,8 @@ the MUX is very demanding, separate pull down test lines may be implemented on t A software specification for a hardware interface will typically concentrate on data formats, how to interpret raw readings, or what digital signals to apply for actuators~\cite{sfmeainterface}. % -Using FMMD the process naturally determines a failure model for the hardware/software interface. % as well~\cite{sfmeainterface}. -\\ +%Using FMMD the process naturally determines a failure model for the hardware/software interface. % as well~\cite{sfmeainterface}. +The FMMD process naturally determines failure mode models for the hardware/software interface. \\ The {\ft} example above is based on the paper presented to System Safety in 2012~\cite{syssafe2012}. @@ -790,7 +801,7 @@ The {\ft} example above is based on the paper presented to System Safety in 2012 It is desirable to model a complete standalone system with FMMD, not only a standalone system, but ideally a hybrid software/hardware system. % -Temperature control is a first order differential problem, and is often +Temperature control is typically a first order differential problem, and is often addressed using the Proportional Integral Differential (PID) algorithm~\cite{dcods}[p.66]. % Traditionally this was performed in analogue electronics @@ -940,7 +951,7 @@ With the set point error value the \cf{PID} function will return an output contr 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. +The PID demand value will be applied via the pulse width modulation (PWM) module. % A rudimentary closed loop control system incorporating both hardware and software has been defined. % @@ -949,7 +960,7 @@ By using the Yourdon methodology a programmatic design frame-work i.e. a call tr All the components, i.e. hardware elements and software functions that will be used in the temperature controller are now defined. % -These are listed, and from the bottom-up, FMMD analysis is applied. +These are listed, and from the bottom-up, FMMD analysis is begun. % \clearpage \subsection{FMMD Analysis of PID temperature Controller} @@ -1046,18 +1057,19 @@ a hierarchy compatible with FMMD for analysis has been obtained. % However, it is only the top, i.e. the software, part of the hierarchy. % -FMMD is a bottom-up process thus start at the lowest level, i.e. the electronics. +FMMD is a bottom-up process, thus it starts with 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. +by definition the lowest levels in the system. % -The input, or afferent data flow can be followed to find the bottom levels for system inputs +The input, or origin of the afferent data flow can be followed to find 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, the lowest level in the hierarchy is found, the Pt100 sensor. %with the software, and consider the hardware elements @@ -1069,9 +1081,12 @@ This gives a {\dc}, %which we call `Read\_Pt100' (see appendix~\ref{sec:readPt100}). % % -% -The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} software function and the Pt100 -hardware, this has the following failure modes: +% +%The {\dc} Read\_Pt100 is obtained from analysis of a {\fg} comprising of the +%\cf{Read\_ADC} software function and the Pt100 hardware. +%The {\dc} Read\_Pt100 is a failure mode model of the \cf{Read\_ADC} software function and the Pt100 +%hardware, this +The {\dc} Read\_Pt100 has the following failure modes: % $$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$ % @@ -1093,14 +1108,12 @@ The pre-conditions for the function are that: \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 -failure. +Any violation of these pre-conditions is equivalent to a failure mode\footnote{An actual measured temperature outside the +pre-defined range would be detected as an unacceptable voltage range failure.}. % The post-condition is that it returns a temperature within a given tolerance to the temperature at the sensor. % -A failure of this post-condition can be termed temp\_incorrect. +A failure of this post-condition can be termed `temp\_incorrect'. % \clearpage Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}. @@ -1108,7 +1121,7 @@ gives the {\dc} {Get\_Temperature}. % This analysis is presented in table~\ref{tbl:gettemperature}. % -The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}. +%The analysis for the Pt100 circuit is presented in table~\ref{tbl:readPt100}. % % Failure symptoms are collected and the {\dc} created with the following failure modes: @@ -1128,16 +1141,21 @@ and the function \cf{determine\_set\_point\_error}. The pre-condition for \cf{determine\_set\_point\_error} is that the temperature read by it is accurate, and its post-condition is to return the correct control error value. % -All single failure modes from a four wire Pt100 sensor are detectable (see section~\ref{sec:singlePt100FMEA}). +%All single failure modes from a four wire Pt100 sensor are detectable (see section~\ref{sec:singlePt100FMEA}). % -For most practical purposes this would suffice, but for the purpose of example -a particular double failure scenario, potentially giving an undefined value is -considered (see section~\ref{sec:Pt100floating}). +%For most practical purposes this would suffice, but for the purpose of example +%a particular double failure scenario, potentially giving an undefined value is +%considered (see section~\ref{sec:Pt100floating}). % -The post-condition thus has two variants, an incorrect value that is detected, KnownIncorrectErrorValue +The post-condition can fail, or the temperature read could be incorrect. +% +This could be detectable (i.e. we detect a failure from the Pt100 $ Pt100\_out\_of\_range $) +or undetectable (i.e. the post condition for this function simply fails +or the failure mode $temp\_incorrect$ occurs). +%and so an incorrect value that is detected, KnownIncorrectErrorValue %where we can detect the Pt100 value is suspect, -and IncorrectErrorValue where there is simply -an incorrect value but this cannot be determined (i.e. its an undetectable failure). % 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}. % @@ -1277,7 +1295,7 @@ FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}. \end{figure} % % -Our {\dc} for the setLED function, GPIO and LEDs has the following failure modes: +The {\dc} for the setLED function, GPIO and LEDs has the following failure modes: $$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$ % % @@ -1306,6 +1324,7 @@ The final FMMD stage forms a {\fg} with the {\dcs} determined previously: % \begin{itemize} + \item the micro-controller, \item PID, \item HeaterOutput, \item LEDoutput, @@ -1340,7 +1359,7 @@ 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. +This 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 causes. \fmmdglossOBS % @@ -1363,8 +1382,8 @@ For instance, measures may included to validate the processor clocking with an e 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. +%Using FMMD in conjunction with extra safety measures it can be ensured that no single hardware failure could lead to a +%system failure, something difficult to prove with current FMEA techniques. diff --git a/submission_thesis/appendixes/detailed_analysis.tex b/submission_thesis/appendixes/detailed_analysis.tex index 853c9f3..cd7cbfa 100644 --- a/submission_thesis/appendixes/detailed_analysis.tex +++ b/submission_thesis/appendixes/detailed_analysis.tex @@ -766,10 +766,10 @@ FMMD analysis tables from chapter~\ref{sec:chap6}. \tiny \begin{table}[h+] \center -\caption{ standalone temperature controller: Failure Mode Effects Analysis} % title of Table +\caption{Standalone temperature controller: Failure Mode Effects Analysis} % title of Table \label{tbl:pid} -\begin{tabular}{|| l | c | l ||} \hline +\begin{tabular}{|| l | l | l ||} \hline % \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ % \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline \hline @@ -778,33 +778,33 @@ FMMD analysis tables from chapter~\ref{sec:chap6}. \hline - FC1: PID KnownControlValueError & As error is detectable/ & ControlFailureIndicated \\ - & observable error can be indicated & \\ \hline + FC1: PID KnownControlValueError & As error is detectable & ControlFailureIndicated \\ + & error can be indicated & \\ \hline - FC2: PID IncorrectControlerrorV & undetectable/unobservable & ControlFailure \\ - & failure PID will not control properly & \\ \hline + FC2: PID IncorrectControlerrorV & undetectable failure: & ControlFailure \\ + & PID will not control properly & \\ \hline FC3: HeaterOutput & Heater will constantly & ControlFailureIndicated \\ HeaterOnFULL & apply maximum power & \\ \hline - FC4: HeaterOutput & heater will supply & ControlFailureIndicated \\ \hline - HeaterOFF & no power & \\ + FC4: HeaterOutput & no power & ControlFailureIndicated \\ + HeaterOFF & supplied to heater & \\ \hline - FC5: HeaterOutput & with incorrect hower applied & ControlFailure \\ \hline - HeaterOutputIncorrect & control will not be effective & \\ + FC4: HeaterOutput & incorrect power levels & ControlFailure \\ + HeaterOutputIncorrect & applied to heater & \\\hline - FC6: LEDOutput & failure of LED system & KnownIndicationError \\ - FailureIndicated & where failure is observable & \\ \hline + FC5: LEDOutput & failure of LED system & KnownIndicationError \\ + FailureIndicated & where failure is detectable & \\ \hline - FC7: LEDOutput & failure of LED system & UnknownIndicationError \\ - IndicationError & where failure is unobservable & \\ \hline + FC6: LEDOutput & failure of LED system & UnknownIndicationError \\ + IndicationError & where failure is undetectable & \\ \hline %% PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED - FC8: micro-controller & un-defined behaviour & ControlFailure \\ + FC7: micro-controller & un-defined behaviour & ControlFailure \\ PROM\_FAULT & & \\ \hline FC9: micro-controller & un-defined behaviour & ControlFailure \\ @@ -819,7 +819,7 @@ FMMD analysis tables from chapter~\ref{sec:chap6}. FC12: micro-controller & processor will not run & ControlFailureIndicated \\ CLOCK\_STOPPED & indicator leds will not flash & \\ \hline - FC13: monitor: & postcondition fails & ControlFailure \\ + FC8: monitor: & postcondition fails & ControlFailure \\ software fails & & \\ \hline