diff --git a/submission_thesis/CH5_Examples/eulerswhw.dia b/submission_thesis/CH5_Examples/eulerswhw.dia index 6a9f771..f1c634a 100644 Binary files a/submission_thesis/CH5_Examples/eulerswhw.dia and b/submission_thesis/CH5_Examples/eulerswhw.dia differ diff --git a/submission_thesis/CH5_Examples/software.tex b/submission_thesis/CH5_Examples/software.tex index 273b871..f74866c 100644 --- a/submission_thesis/CH5_Examples/software.tex +++ b/submission_thesis/CH5_Examples/software.tex @@ -30,8 +30,8 @@ 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 failure modes---we can +When we have analysed a +software function---using failure conditions of its inputs as failure modes---we can determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). % @@ -47,8 +47,12 @@ 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 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}. That {\dc} can be +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}. +% +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. % map the FMMD concepts of {\fms}, {\fgs} and {\dcs} @@ -83,12 +87,14 @@ its failure modes and symptoms are. With electronic components, we can use literature to point us 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'. +enough to have the equivalent of known failure modes, +most software is `bespoke'. % We need a different strategy to -describe the failure mode behaviour of software functions. -We can use definitions from contract programming to assist here. +describe the failure mode behaviour of software functions, %. +%We +and +can use definitions from contract programming to assist. % here. \subsection{Contract programming description} @@ -162,9 +168,14 @@ violations could simply occur. \paragraph{Mapping contract `invariant' violations to symptoms and failure modes.} - +Invariants are conditions that are considered to be relied on throughout the execution of +a program. +% +Here they are taken to mean invariants applying to data +or conditions that the function under analysis deals with or could be affected by. +% 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 {failure modes} in FMMD terminology). +and to outputs (where violations can be considered {\fms} in FMMD terminology). \subsection{Combined Hardware/Software FMMD} @@ -207,7 +218,7 @@ and this is referred to as {\ft} signalling which has intrinsic electrical saf The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} signal to a micro-controller system. -The signal is locally driven over a load resistor, and then read into the micro-controller via +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. @@ -370,7 +381,7 @@ We now have a very simple software structure, a call tree, shown in figure~\ref{ \label{fig:ct1} \end{figure} -This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the +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. @@ -447,7 +458,10 @@ With these failure modes, we can analyse our first functional group, see table~\ 5: $ADC_{LOW}$ & output low & $LOW$ \\ 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline - 7: post condition fails & software fails & $V\_ERR$ \\ \hline + % + % As Chris Garrett points out there is no software involved at this stage! + %7: post condition fails & software fails & $V\_ERR$ \\ + % & \hline \hline @@ -490,7 +504,7 @@ which we can call $ 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$ (this failure mode is observable +of this function, which we can call $V\_REF$ (this failure mode is detectable %observable only if we specifically use a test input to measure the reference). Taken as a component for use in FMEA/FMMD our function has @@ -540,7 +554,8 @@ We analyse this hardware/software combined {\fg}. 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline - 6: post condition fails & software fails & $VV\_ERR$ \\ \hline + 6: post condition fails & software fails & $VV\_ERR$ \\ + & C function: Read\_ADC & \\ \hline \hline @@ -675,7 +690,9 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig The {\dc} representing the {\ft} reader in software shows that by FMMD, we can integrate -software and electro-mechanical FMMD models. +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. @@ -698,7 +715,9 @@ 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 in the system. -The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed +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 detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. @@ -773,7 +792,7 @@ start with a structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MS \end{figure} Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its data flow, starting -with the data sources ( the Pt100 inputs) and the data syncs (the heater output and the LED indicators). +with the data sources ( the Pt100 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 @@ -812,7 +831,7 @@ and we therefore need to execute it at precise intervals determined by its propo % Most micro-controllers feature several general purpose timers~\cite{pic18f2523}. We can use an internal timer in conjunction with the monitor function -to call the PID algorithm at a specified interval. +to call the PID algorithm at a regular time interval. % specified interval. % \paragraph{Data flow model to programmatic call tree.} The Yourdon methodology also gives us a guide as to which software @@ -874,7 +893,7 @@ Identified electronic components: \item HEATER --- Heating element, essentially a resistor. \item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}. \item PWM --- Internal micro controller pulse width modulation module - \item General Purpose I/O (GPIO) --- I/O used to source LED current + \item General Purpose I/O (GPIO) --- I/O used to drive LEDS %. %source LED current \item LEDs --- Indication LEDs via GPIO \item micro-controller --- the medium for running the software \end{itemize} @@ -985,7 +1004,7 @@ This gives us a {\dc} which we call ReadPt100. FC4: $RADC_{LOW}$ & ADC may read & $VOLTAGE\_LOW$ \\ \hline FC5: post condition fails & software failure & $VAL\_ERR$ \\ - in function read\_ADC & & \\ \hline + in function read\_ADC & read\_ADC & \\ \hline \end{tabular} \end{table} @@ -1060,7 +1079,7 @@ We can call the resulting {\dc} Get\_Temperature. & incorrect temperature & \\ \hline FC5: post condition fails & software failure & temp\_incorrect \\ - in function convert\_ADC\_to\_T & & \\ \hline + in function convert\_ADC\_to\_T & convert\_ADC\_to\_T & \\ \hline \hline @@ -1111,8 +1130,8 @@ an incorrect error value. & unobservable & \\ & undetectable failure mode & \\ \hline - FC3: post condition fails & software failure & IncorrectErrorValue \\ - in function determine\_set\_point\_error & & \\ \hline + FC3: post condition fails & software failure & IncorrectErrorValue \\ + in function determine\_set\_point\_error & determine\_set\_point\_error & \\ \hline \end{tabular} @@ -1177,7 +1196,7 @@ being the logic and process of the failure mode analysis. FC3: post condition fails & software failure & IncorrectControlErrorV \\ - in function PID & & \\ \hline + in function PID & PID & \\ \hline \end{tabular}