diff --git a/submission_thesis/CH2_FMEA/copy.tex b/submission_thesis/CH2_FMEA/copy.tex index 7f23e56..804137d 100644 --- a/submission_thesis/CH2_FMEA/copy.tex +++ b/submission_thesis/CH2_FMEA/copy.tex @@ -157,6 +157,8 @@ for unearthing potential failure scenarios. %The core of Cartesianism is that you have a mind: a separate function of your'self'. If you have an invisible self called a mind - you are in the subject/object dichotomy. Non-dualism is mostly learned in Eastern philosophies and will refer to the mind as an integer of the self - not separate from it. %You can not jump from one to the other. And, they both must be learned as referential contexts to who 'you' are in the world you live in. % +\paragraph{Subjective and Objective thinking in relation to FMEA.} +\label{sec:subjectiveobjective} FMEA is always performed in the context of the use of the equipment. In terms of philosophy this is in the domain of the subjective and the objective. We can using objective reasoning trace a component level failure to a system level event, diff --git a/submission_thesis/CH5_Examples/Makefile b/submission_thesis/CH5_Examples/Makefile index 3466f2a..9d7ef40 100644 --- a/submission_thesis/CH5_Examples/Makefile +++ b/submission_thesis/CH5_Examples/Makefile @@ -7,7 +7,7 @@ PNG_DIA = blockdiagramcircuit2.png bubba_oscillator_block_diagram.png circuit1 tree_abstraction_levels.png vrange.png sigma_delta_block.png ftcontext.png ct1.png hd.png \ sigdel1.png sdadc.png bubba_euler_1.png bubba_euler_2.png eulersd.png eulersdfinal.png \ eulerfivepole.png eulerswhw.png context_diagram_PID.png context_diagram2_PID.png context_software.png \ - context_calltree.png + context_calltree.png euler_afferent_PID.png diff --git a/submission_thesis/CH5_Examples/software.tex b/submission_thesis/CH5_Examples/software.tex index 11db417..e3ff6c7 100644 --- a/submission_thesis/CH5_Examples/software.tex +++ b/submission_thesis/CH5_Examples/software.tex @@ -5,22 +5,21 @@ \section{Software and Hardware Failure Mode Concepts} \label{sec:elecsw} -FMMD can be applied to software, and thus we can build complete failure models +In this chapter we show that FMMD can be applied to software enabling us to build 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. - +% A programmatic function has similarities with a {\fg} as defined by the FMMD process. % An FMMD {\fg} is placed into a hierarchy. -A software function is placed into a hierarchy, that of its call-tree. -A software function typically 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 -which will be used by functions that may call it. +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. +%which will be used by other functions that may call it. % -We can map a software function to a {\fg} in FMMD. Its failure modes +We show that we can map a software function to a {\fg} in FMMD: its failure modes are the failure modes of the software components (other functions it calls) and the hardware from which it reads values. Its outputs are the data it changes, or the hardware actions it performs. @@ -28,18 +27,28 @@ Its outputs are the data it changes, or the hardware actions it performs. %% Talk about how software specification will often say how hardware %% 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 determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). -We can thus apply the FMMD % $\derivec$ -process to software functions, by viewing them in terms of their failure -mode behaviour. To simplify things as well, software already fits into a hierarchy. +% +We apply the FMMD process to software functions by viewing them in terms of their failure mode behaviour. +% +As software already fits into a hierarchy we have one less analysis decision to make, compared +to analysing electronics. +% For Electronics 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} -and the subsequent hierarchy. With software already written, that hierarchy is fixed. - +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 its-self +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} %to software functions. % @@ -73,7 +82,9 @@ With electronic components, we can use literature to point us to suitable sets o {\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 +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. @@ -97,26 +108,28 @@ We can consider a software function to be a collection of code, functions called and values/variables used. In this way it is similar to an electronic circuit, which is a collection of components connected in a specific way. -In this analogy the connections are the code, and the functions and variables are the components. +Using this analogy for software, the connections are the functions code, and the +called functions and variables are the components. % -%EHHRHHHUH -%EERRGHHH COUGH COUGH +Erroneous behaviour from called functions and variables/inputs has the same effect as component failure modes +on an electronic {\fg}. % % If we consider the -calls and variables/inputs to be components of a function, +called functions and variables/inputs to be components of a function, +we can build a modular and hierarchical failure mode model +from existing software. % -any erroneous behaviour from them has the same effect as component failure modes -on an electronic {\fg}. %HHmmm HHHHMMMM XXXXXX gora den har nar dets finns into nagon some harker hela tiden -% -For a software function, we consider a violation of a pre-condition to be +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'. \paragraph{Mapping contract `post-condition' violations to symptoms.} -A post condition is a definition of correct behaviour by a function. -A violated post condition is a symptom of failure, or derived failure mode, of a function. +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. +% Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function. In pure contract programming, a violation of a pre-condition would not cause the function to be executed. @@ -723,7 +736,7 @@ we will need an ADC and MUX. % For the output, we can use a Pulse Width Modulator (PWM) (this is a common module found on micro-controllers allowing a variable power output~\cite{pwm}). PWM's ADC's and MUX's are commonly built into cheap micro-controllers~\cite{pic18f2523}. -We can now build more detail into the Yourdon diagram, with the afferent data flow coming through the MUX and ADC on the micro-controller, and the afferent +We can now build more detail into the Yourdon diagram, with 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, see figure~\ref{fig:context_diagram2_PID}. \begin{figure}[h]+ @@ -736,7 +749,7 @@ see figure~\ref{fig:context_diagram2_PID}. The Yourdon methodology allows us to zoom into data transform bubbles and analyse them in more detail. % -We define the controlling software, by looking at or zooming into its trafnsform bubble. +We define the controlling software, by looking at or zooming into its transform bubble. We have the inputs and outputs from the software. We refine the data flow within the software and thus define software functions. %, and @@ -744,11 +757,14 @@ We refine the data flow within the software and thus define software functions. % We follow the data streams through the process, creating transform bubbles as required. In all `bare~metal' software architectures, we need a rudimentary operating system, often referred to as the monitor. -PID, because the algorithm depends heavily on integration, is time sensitive -and we therefore need to invoke at specific intervals. +% +We bare in mind that PID, because the algorithm depends heavily on integral calculus, is time sensitive +and we therefore need to call at precise intervals specific to its integration and differential coefficients. +% 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. +% \paragraph{Data flow model to programmatic call tree.} The Yourdon methodology also gives us a guide as to which software functions should be called to control the process, or in `C' terms be the main function. @@ -764,6 +780,7 @@ Using figure~\ref{fig:contextsoftware} we can now pick the transform bubble we want to be the `main' or controlling function in the software. This can be thought of as picking one bubble and holding it up. The other bubbles hang underneath forming the software call tree hierarchy, see figure~\ref{fig:context_calltree}. +From is clearly going to be the monitor function. \begin{figure}[h]+ \centering \includegraphics[width=300pt]{./CH5_Examples/context_calltree.png} @@ -771,23 +788,26 @@ forming the software call tree hierarchy, see figure~\ref{fig:context_calltree}. \caption{Software yourdon diagram converted to programatic call tree.} \label{fig:context_calltree} \end{figure} +% -This is clearly going to be the monitor function. \paragraph{Software Algorithm.} The monitor function will orchestrate the control process. Firstly it will examine the timer value, and when appropriate, call the PID function, which will call first the determine\_set\_point\_error function with that calling convert\_ADC\_to\_T which calls Read\_ADC (the function developed in the earlier example). -With the set point error value the PID function will call the output control function with its PID -demand. +% +With the set point error value the PID function will return + output control value to its calling +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. % -Using the Yourdon methodology we have the system design: we have all the components, hardware elements and software functions +Using the Yourdon methodology we have the system design: we have all the components, i.e. hardware elements and software functions that will be used in the temperature controller. -We list these and begin, from the bottom-up, -to apply FMMD analysis. +We list these, and begin, from the bottom-up, to apply FMMD analysis. \clearpage \subsection{FMMD Analysis of PID temperature Controller} @@ -859,7 +879,7 @@ Identified Software Components: \item --- determine\_set\_point\_error (which calls convert\_ADC\_to\_T) \item --- convert\_ADC\_to\_T (which calls read\_ADC which we can re-use from the last example) \item --- read\_ADC - \item --- output\_Control (which sets the PWM hardware according to the PID demand value) + \item --- output\_control (which sets the PWM hardware according to the PID demand value) \end{itemize} With the call tree structure defined (see figure~\ref{fig:context_calltree}), we can now analyse these components from the bottom-up, starting with the electronics. @@ -1047,6 +1067,9 @@ However this problem is a failure mode for the function calling it. The calling function sets the context for the PID algorithm (i.e. what it is used for). If this PID were to be used, say as some form of low pass filter, we could consider jitter for instance. In a control environment with PID jitter would not be a significant factor. +This harks back to the context of use (see section~\ref{sec:subjectiveobjective}) discussion, the subjective +being the context the {\dc} is used for/in, and the objective +being the logic and process of the failure mode analysis. { \tiny @@ -1067,7 +1090,7 @@ for instance. In a control environment with PID jitter would not be a significan & observable/detectable & \\ & failure mode & \\ \hline - FC2: $, IncorrectErrorValue $ & pre-condition violated & IncorrectControlErrorV \\ + FC2: $ IncorrectErrorValue $ & pre-condition violated & IncorrectControlErrorV \\ & unobservable & \\ & undetectable failure mode & \\ \hline @@ -1080,6 +1103,22 @@ for instance. In a control environment with PID jitter would not be a significan We now create a PID {\dc}, with the following failure modes: $$ fm(PID) = \{ KnownControlValueErrorV, IncorrectControlErrorV \} .$$ + +\begin{figure}[h] + \centering + \includegraphics[width=400pt]{./CH5_Examples/euler_afferent_PID.png} + % euler_afferent_PID.png: 1002x342 pixel, 72dpi, 35.35x12.06 cm, bb=0 0 1002 342 + \caption{Euler diagram representing the hierarchy of FMMD analysis applied to the afferent branch of call tree for the PID temperature controller example.} + \label{fig:euler_afferent_PID} +\end{figure} + + + +We have now modelled the the software call tree for the afferent flow, we represent this as an Euler diagram in figure~\ref{fig:euler_afferent_PID}. +Two call tree branches remain. The LED indication branch and the +PWM/heater output. + + %OK STOP AT PID and follow the other data flows until we are ready to bring them to the top: i.e. % %the monitor program.......