More proof reading. Final FMEA table still to finish

and descriptions.

papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex

@@ -62,12 +62,18 @@ failure mode of the component or sub-system}}}
 \newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure 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{\bcfm}{base~component~failure~mode}
-\newcommand{\cf}[1]{\textbf{#1()}}
+\newcommand{\cf}[1]{{\footnotesize \textbf{#1()}}}
 \newcommand{\swhw}{software~hardware}
 \newcommand{\sw}{software}
 \newcommand{\hw}{hardware}
 \newcommand{\uP}{micro~processor}
-
+\usepackage{color, colortbl}
+\definecolor{Gray}{gray}{0.9}
+\definecolor{LightGray}{gray}{0.97}
+\definecolor{LightCyan}{rgb}{0.88,1,1}
+\definecolor{Blue}{rgb}{0.0,0.0,0.7}
+\definecolor{Red}{rgb}{0.9,0.0,0.0}
+\definecolor{Green}{rgb}{0.0,0.5,0.0}
 
 \def\layersep{1.8cm}
 
@@ -131,7 +137,10 @@ failure mode of the component or sub-system}}}
 %\small
 
 \abstract{ % \em 
-%\input{abs}
+%\input{abs}%
+The intention of this paper is to demonstrate an FMEA methodology that can 
+analyse integrated hardware/software systems and has test efficiency benefits.
+%
 The certification process of safety critical products for European and 
 other international standards often demand environmental stress, 
 endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
@@ -170,8 +179,7 @@ the ability to model integrated hardware and software systems.
 
 To demonstrate FMMD a small, but complete embedded system 
 (including both software and hardware)
-worked example is presented to show FMMD applied to an 
-integrated electronics/software system.
+is analysed for failure mode effects.
 %, the industry standard
 %{\ft} signalling loop.
 %
@@ -263,7 +271,9 @@ is implemented at the bottom, which prepares input/output (IO)
 signals for/from the micro controller.
 The micro controller will have software to read/send signals to the electronics
 and on top of that a functional software layer where the control algorithms will
-reside. On the top of this hierarchy are the \cf{main} and \cf{monitor} functions.
+reside. 
+%
+Typically at the top of this hierarchy are the \cf{main} and \cf{monitor} functions.
 This hierarchy is represented in figure~\ref{fig:sw_hw_hierarchy}.
 
 \begin{figure}[h]+
@@ -282,7 +292,7 @@ do not specify FMEA for software but instead essentially just specify good pract
 i.e. review processes and language feature constraints.
 %  
 That is to say FMEA has  no formal framework for following
-failure modes from low level hardware elements through into software models.
+failure modes from low level hardware elements through into software models~\cite{sfmeainterface}.
 %
 This is a weakness.
 %
@@ -482,10 +492,10 @@ within the system would have to be examined against all its other components.
 No current FMEA variant gives guidelines for the components that should 
 be included to analyse a {\fm} in a system.
 %
-Were a {\fm} examined against all the other components in a system
-this gives a maximum reasoning distance.
+Were each {\fm} examined against all the other components in a system
+this would a maximum reasoning distance --- for that particular {\fm}.
 %
-This is termed the exhaustive FMEA (XFMEA). % case for a single {\fm}.
+This is termed an exhaustive FMEA case (XFMEA). % case for a single {\fm}.
 %does not
 % The exhaustive~reasoning~distance would be
 % the sum of the number of failure modes, against all other components
@@ -511,8 +521,8 @@ methodologies).
 %
 %\fmmdglossSTATEEX
 %
-A high reasoning distance, because it is a manual process performed by experts, is both
-expensive in terms of time and money.
+A high reasoning distance, because it is a manual process performed by experts, is 
+expensive in both terms of time and money.
 %
 It is apparent also that the shorter the reasoning distance, the more precisely theoretical examination
 can determine failure symptoms. A shorter reasoning distance therefore implies a higher quality of safety analysis.
@@ -694,18 +704,21 @@ dominant  computer language FORTRAN~\cite{f77} became a limiting factor.
 %
 Programs written in FORTRAN became clumsy when they became large.
 %
-All variables were global.
+All variables were globally stored (even local function variables
+which were effectively `static').
 %
-A miss-spelled variable could cause chaos.
+Because of implicit typing  miss-spelled variables could cause chaos.
 %
 Also it was often difficult to pull a function
 out of one program and place it in another if it used some of the global variables.
 
 Newer computer languages were invented where modularity was encouraged.
 Instead of FORTRANs global scope for variables, individual functions in a newer languages like `C'
-started to have `local' variables. This meant that
+started to have `local' variables.
+%
+This meant that
 a programmer could take a function from a `C' program and 
-use it in another one without complication.
+use it in another one without undue complication.
 %
 Later languages implemented object orientation
 which grouped functions and data together into modules called classes, where
@@ -905,7 +918,7 @@ failed component will have to be traced through
 several sub-systems, gauging its effects with and on other components. 
 %
 With software at the higher levels of these sub-systems,
-there is yet another layer of complication.
+this introduces another layer of complication.
 %
 %In order to integrate software, %in a meaningful way 
 %we need to re-think the 
@@ -916,11 +929,11 @@ there is yet another layer of complication.
 % calculated incorrectly (due to a mistake by the programmer, or a fault in the micro-processor on which it is running), or
 % external influences such as
 % ionising radiation causing bits to be erroneously altered.
-It is desirable to trace failure modes effects through the hardware and software interfaces.
+However It is desirable to trace failure modes effects through the hardware and software interfaces.
 This is for two reasons. 
 %
 The first is to ensure that the software can detect  all possible
-hardware failures, and secondly that the software reacts appropriately.
+hardware failures, and secondly that the software actually reacts appropriately.
 
 
 
@@ -928,17 +941,17 @@ hardware failures, and secondly that the software reacts appropriately.
 \section{FMEA defeciences and `wishlist'}
 
 %\subsection{FMEA - General Criticism}
-A summary of deficiencies in current FMEA methodologies is listed below:
+A summary of deficiencies in current FMEA methodologies are listed below:
 \begin{itemize}
    %\item FMEA type methodologies were designed for simple electro-mechanical systems of the 1940's to 1960's,
    \item State explosion - %impossible 
    very difficult/time consuming to perform FMEA exhaustively, %rigorously
    \item Difficult to re-use previous analysis work~\cite{rudov2009language},
    \item Very difficult to model simultaneous/multiple failures,
-   \item Software and hardware models are separate (if the software is modelled at all) meaning the software interface may not be correctly modelled,
+   \item Software and hardware models are treated  separately (if the software is modelled at all) meaning the software interface may not be correctly modelled,
    %\item reasoning distance -- component failure to system level symptom process is undefined in regard 
    %to the components to check against each given component {\fm},
-   \item FMEA methodologies are undefined in regard to which components to check against given failure modes,
+   \item FMEA methodologies are undefined in regard to scope, i.e. which components to check against given failure modes,
    %
    \item Distributed real time systems are very difficult to analyse with FMEA because they typically involve many hardware/software interfaces.
 \end{itemize}
@@ -1020,15 +1033,15 @@ These modules can be brought together to form even larger modules.
 
 Eventually there is one large module which represents the entire system.
 
-Because the terms module and sub-system are quite general term, and possibly over-used,
+Because the terms module and sub-system are quite general terms, and possibly over-used,
 a new term has been used to take their place in FMMD.
 %
-This is the `functional~group'.
+This is the `{\fg}'.
 %
 Quite simply when identifying a group of components that perform a particular task
-the term `functional~group' describes it as a group that performs a function.
+the term `{\fgs}' describes it as a group that performs a function.
 %
-It also means that a function~group can contain other functional~groups without
+It also means that a function~group can contain other {\fgs} without
 dragging along the semantic baggage that comes with the terms `module' and 'sub-system'.
 
 
@@ -1053,6 +1066,13 @@ This means that failure modes can be traced through linking the
 the component {\fms} that can cause them.
 %
 This gives rigorous failure mode traceability through the model.
+This means:
+\begin{itemize}
+ \item All failure modes must be handled by the analyst,
+ \item All top or system level failure symptoms can be traced back to their potential causes.
+\end{itemize}
+
+
 
 
 %
@@ -1062,8 +1082,8 @@ starting with individual component failure modes.
 %
 That way, all component failure modes must be considered.
 %
-If you modularise from the top down, it is not naturally follow
-bottom-level component failure modes would be handled/used.
+If modularisation is performed from the top down, it does not naturally follow
+that all bottom-level component failure modes would be handled/used~\cite{faa}[Ch.9].
 %
 Starting at the bottom means having to deal with each component failure mode from the beginning.
 
@@ -1099,11 +1119,17 @@ system is included. The top level failure symptoms are the ways in which the sys
 An advantage of this, is that all component failure modes must be considered
 in terms of their effects as the system goes from the 
 lower levels through to more abstract system level failures.
-This can lead to surprises. Often when a system is evaluated
+%
+This can lead to surprises. 
+
+%
+Often when a system is evaluated
 by FMMD a list of system level failures can include ones
 that are not currently dealt with or even detectable
-without some re-design. Having surprises at the design
-and not in~the~field is a very good thing 
+without some re-design.
+%
+Having surprises at the design
+and not during beta~test (or even in~the~field) is a very good thing 
 when dealing with safety critical systems!
  
 
@@ -1112,9 +1138,9 @@ it too can be treated as an FMMD {\fg}.
 %Software functions are treated as components as well, and 
 %treat the hardware they interface to (if any) as components.
 A software functions `components' are the software functions it calls
-and the hardware elements it interfaces to (if any.
-but eventually
-all software hierarchies reach down to hardware, or they would not do anything in the real world).
+and the hardware elements it interfaces to (if any).
+Eventually
+all software hierarchies must reach down to hardware in order to react with the real world.
 
 An example of a hardware low level analysis is given in~\cite{syssafe2011} and a combined
 software hardware sub-system in~\cite{syssafe2012}. Examples of both, including analysis of performance 
@@ -1175,8 +1201,7 @@ access to frequency analysis of digital samples called the Fast Fourier Transfor
 This took the Discrete Fourier Transform (DFT), and applied de-composition to its 
 mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].}
 %
-By doing this it breaks the computing order of complexity  down from having a polynomial %n exponential
-%order 
+By modularising into a hierarchy, the computing order of complexity  is broken down from having a polynomial  
 to logarithmic order~\cite{ctw}[pp.401-3].
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%FFT%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 It also means that {\fgs} are re-usable (analogous to software classes).
@@ -1351,8 +1376,8 @@ The software then applies a PID~\cite{dcods} algorithm to determine the length/m
 
 \subsection{Closed Loop Control Hardware/Software Hybrid Example}
 
-It is desirable to model a complete standalone system with FMMD,
-not only a standalone system, but ideally a hybrid software/hardware system.
+%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 typically a first order differential problem, and is often 
 addressed using the Proportional Integral Differential (PID) algorithm~\cite{dcods}[p.66].
@@ -1380,6 +1405,7 @@ as a complete example of an electronic/hardware hybrid analysed using FMMD. %wou
 % % may be found in~\cite{dcods}[Ch.3.3].
 %
 \subsection{Design Stage: Implementation on a micro-controller.}
+%
 When designing  a computer program it is often useful to 
 start with a system overview.
 A structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MSA:62004} is presented below, see figure~\ref{fig:context_diagram_PID}.
@@ -1387,7 +1413,7 @@ A Yourdon context diagram shows an overview of a system, with the data inputs an
 The circle in the middle defines the processing applied to those inputs and outputs.
 The context diagram can be later refined by introducing more circles with data paths between them.
 Finally a {\swhw} hierarchy can be derived from a Yourdon diagram, which assists
-in the design of hybrid {\swhw} systems.
+in the design of the software (specifically the structure of the call tree and the hardware/software interfaces).
 
 %
 \begin{figure}[h]+
@@ -1401,16 +1427,17 @@ in the design of hybrid {\swhw} systems.
 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).
 %
-There are two voltage inputs (see section~\ref{clark}[5]) from the Pt100 temperature sensor.
+There are two voltage inputs (for a detailed analysis and discussion of a four wire Pt100 configuration see~\cite{clark}[5]) from the Pt100 temperature sensor.
 %
 For the Pt100 sensor,  the voltages it outputs  are read and %for 
-this requires an ADC and MUX. 
+this requires an Analogue to digital converter\footnote{An ADC reads a voltage and converts it to
+an integer made available in a readable register.} (ADC) and a multiplexer\footnote{A multiplexer takes several inputs and routes one selected input to the multiplexer output.} (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]). 
+For the output, a Pulse Width Modulator (PWM)\footnote{PWM provides a means to modulate an output i.e. vary power levels}
+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].
 %
@@ -1435,9 +1462,11 @@ channelled through a PWM module. %again built into the micro-controller,
 %
 This next stage of model refinement is shown in figure~\ref{fig:context_diagram2_PID}.
 %
-The controlling software is then further refined, by looking at or zooming into transform bubbles
+This is performed by looking at or zooming into transform bubbles
 and  adding more detail i.e. following the data streams through the process, additional transform bubbles are created as required.
-%
+%%%%%
+
+%%%%%
 The lines connecting the `transform~bubbles' define the data passed between them.
 %
 When the data flow analysis is finished, each transform bubble represents a software function.
@@ -1458,7 +1487,7 @@ software architectures, a rudimentary operating system is required, often referr
 %
 The `monitor' function calls the PID function at a regular and precise interval.
 %
-The PID function, because the algorithm depends heavily on integral calculus~\cite{dcods}[Ch.3.3] is time sensitive
+The PID function, because the algorithm implements 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}.
@@ -1479,10 +1508,11 @@ functions should be called to control a process, or in `C' terms be the main fun
 \end{figure}
 %
 Using figure~\ref{fig:contextsoftware} the transform bubble  
-to represent the `main' or controlling function in the software must be chosen.
+to represent the \cf{main}\footnote{All software functions will be written in bold with a pair of brackets
+to distingish them as such. The `C' main function is thus presented as \cf{main}.}
+or controlling function in the software must be chosen.
+%
 %
-All software functions will be written in bold with a pair of brackets
-to distingish them as such. The `C' main function is thus presented as \cf{main}.
 %
 This can be thought of as picking one bubble and holding it up. 
 %
@@ -1503,7 +1533,7 @@ this is clearly going to be the \cf{monitor} function.
 %
 \paragraph{Software Algorithm.}
 %
-The monitor function will orchestrate the control process.
+The \cf{monitor} function will orchestrate the control process.
 %
 Firstly it will examine the timer value, and when appropriate, call the \cf{PID} function.
 %
@@ -1511,20 +1541,28 @@ The \cf{PID} function calls \cf{determine\_set\_point\_error} which calls \cf{co
 which in turn calls \cf{Read\_ADC} (a function developed and analysed using FMMD in~\cite{syssafe2012})
 which reads from hardware.
 %
-With the set point error value the \cf{PID} function will return an output control value to its calling
+With the set point error value\footnote{In the field of control engineering~\cite{dcods} the setpoint error value is often simply referred to as the `error' term.
+In this context it is the difference between the target temperature and the temperature read. For instance were the target temperature
+to be $200^{\circ} C$ and the temperature read to be $150^{\circ} C$ the error value would be $-50^{\circ} C$}
+the \cf{PID} function will return an 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 pulse width modulation (PWM) module.
 %
-A rudimentary closed loop control system incorporating both hardware and software has been defined.
+%A rudimentary closed loop control system incorporating both hardware and software has been defined.
+With the hardware and software elements defined, and incorporated into a hierarchy, the 
+overall structure of the temperature controlled has now been designed.
 %
 By using the Yourdon methodology a programmatic design frame-work i.e. a call tree structure was obtained.
 %
 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 begun.
+As each of these elements can be analysed as components in FMMD
+analysis can begin.
+%
+%These are listed, and  from the bottom-up, FMMD analysis is begun.
 %
 \clearpage
 %\subsection{FMMD Analysis of PID temperature Controller}
@@ -1558,7 +1596,7 @@ Each electronic {\dc} will be described and cited in more detail below.
 
 \paragraph{ADCMUX and Read\_ADC.}
 The {\dc} from \cite{syssafe2012} is re-used for this analysis. %section~\ref{readADC}.
-This analysis was performed on a `C' function which
+This analysis was performed on a `C' function (\cf{Read\_ADC}) which
 read a value from an analogue to digital converter (ADC) hardware element.
 The analysis revealed that it could fail in three ways.
 $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
@@ -1566,10 +1604,10 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$
 %
 \paragraph{TIMER.}
 %
-The internal timer, from a programmer's perspective is a register, which when read 
+A hardware 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.
+Essentially its a free running, precisely clocked integer counter with an interfacing register.
 %
 Using two's complement mathematics, by subtracting
 the time last read value, we can calculate the interval
@@ -1620,7 +1658,10 @@ 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.
 %
 Consider the general~computing, CLOCK, PROM and RAM failure modes:
-$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
+\begin{eqnarray*}
+ fm (micro-controller) = \{ PROM\_FAULT, \\ RAM\_FAULT, \\ CPU\_FAULT, \\ ALU\_FAULT,  \\ CLOCK\_STOPPED  \}.
+\end{eqnarray*}
+%$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
 %
 \subsection{Temperature Controller Software Elements FMMD}
 Identified Software Components:
@@ -1629,7 +1670,7 @@ Identified Software Components:
  \item --- \cf{PID} (which calls \cf{determine\_set\_point\_error} ),
  \item --- \cf{determine\_set\_point\_error} (which calls \cf{convert\_ADC\_to\_T}),
  \item --- \cf{convert\_ADC\_to\_T} (which calls \cf{read\_ADC}), % which has been analysed as the {\dc} read\_ADC which can be re-used.} % from the last example),
- \item --- \cf{read\_ADC} (analysed in the previous section~\ref{sec:readadc}),
+ \item --- \cf{read\_ADC} (analysed in~\cite{syssafe2012}),
  \item --- \cf{output\_control} (which sets the PWM hardware according to the PID demand value).
 \end{itemize}
 %
@@ -1652,15 +1693,15 @@ 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
+Starting 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 
-Beginning at the bottom,  a {\fg} is formed  with
-the function \cf{read\_ADC} and the Pt100.
-This gives a {\dc}, %which we call 
-`Read\_Pt100'. % (see appendix~\ref{sec:readPt100}).
+
+
+
+
 %
 %
 %            
@@ -1668,9 +1709,9 @@ This gives a {\dc}, %which we call
 %\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:
+The {\dc} convert\_ADC\_to\_T has the following failure modes:
 %
-$$ fm (Read\_Pt100) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
+$$ fm (convert\_ADC\_to\_T) = \{ VOLTAGE\_HIGH, VAL\_ERR, VOLTAGE\_LOW \}. $$
 %
 %
 Moving along the afferent flow,   the \cf{convert\_ADC\_to\_T} function is next up the hierarchy.
@@ -1695,7 +1736,7 @@ 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 is that the wrong value would be returned: this {\fm} is named  $VAL\_ERR$.
 %
 \clearpage
 Applying FMMD to the {\fg} formed by \cf{Read\_Pt100} and the function \cf{convert\_ADC\_to\_T}.
@@ -1703,21 +1744,71 @@ gives the {\dc} {Get\_Temperature}.
 %
 This analysis is presented in table~\ref{tbl:gettemperature}.
 %
+Beginning at the bottom,  a {\fg} is formed  with
+the function \cf{read\_ADC} and the Pt100: this coresponds to the `C' function 
+\cf{convert\_ADC\_to\_T}.
+When FMMD analysis has been performed this gives a {\dc}, named 
+`convert\_ADC\_to\_T'. % (see appendix~\ref{sec:readPt100}).
+
+
+\begin{table}[h+]
+\center
+
+\caption{ convert\_ADC\_to\_T: Failure Mode Effects Analysis} % title of Table
+\label{tbl:gettemperature}
+
+\begin{tabular}{|| l | l  | c |   l ||} \hline
+% \textbf{Failure}   &  \textbf{failure}     & \textbf{Symptom}          \\ 
+% \textbf{Scenario}  &  \textbf{effect}      &     \textbf{RADC }                     \\ \hline 
+ \hline 
+ \rowcolor{LightCyan}
+ \textbf{Component} & \textbf{Failure} &  \textbf{Failure }         & \textbf{Symptom}            \\ 
+ \rowcolor{LightCyan}
+ \textbf{}          & \textbf{cause}   &   \textbf{Effect}          &                             \\
+  
+ 
+               \hline
+   Pt100   & FC1: out of range reading           &  Pt100 voltage         &      $VOLTAGE\_HIGH$        \\  
+           & from the Pt100 resistors.           & outside range          &          $VOLTAGE\_LOW$               \\ \hline 
+
+   RADC  & FC2: $RADC_{VV_ERR}$          &  voltage           &    $VAL\_ERR$      \\ 
+                   &  ADC failure         &                          \\    \hline  \hline 
+
+
+ 
+   RADC   & FC3: $RADC_{HIGH}$      &  voltage value     &     $VOLTAGE\_HIGH$         \\   
+                   &  ADC reads High          &                         \\ \hline 
+
+
+
+   RADC    & FC4: $RADC_{LOW}$        & voltage value           & $VOLTAGE\_LOW$     \\ 
+                   & ADC reads low                         & from ADC value low      &                    \\  \hline
+
+  RADC   & FC5: post condition fails       & software failure in    &      $VAL\_ERR$  \\ 
+                 & in function \cf{read\_ADC}      &   \cf{read\_ADC}     &                  \\ \hline
+                 
+ \cf{convert\_ADC\_to\_T}  & FC6: post condition fails                & software failure in    &      $VAL\_ERR$  \\ 
+                          & in function \cf{convert\_ADC\_to\_T}      &   \cf{convert\_ADC\_to\_T}     &                  \\ \hline
+
+\end{tabular}
+\end{table}
+
+
+
+%\fmmdglossADC
+Collecting symptoms from table~\ref{tbl:gettemperature}, the {\dc} $convert\_ADC\_to\_T$ is assigned the following failure modes:
+$$    
+    fm(convert\_ADC\_to\_T) = \{  VOLTAGE\_HIGH , VOLTAGE\_LOW, VAL\_ERR\} .
+$$
 %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:
-%
-%
-$$fm(Get\_Temperature) = \{  Pt100\_out\_of\_range, temp\_incorrect \} . $$
-%\clearpage
-%
 %
 Following the afferent flow further, the function to determine the control error value is examined.
 %
 This is simply the target temperature subtracted from that measured by the sensor.
 %
-A {\fg} is formed with the newly {\dc} Get\_Temperature
+A {\fg} is formed with the newly formed {\dc} convert\_ADC\_to\_T
 and the function \cf{determine\_set\_point\_error}.
 %
 The pre-condition for \cf{determine\_set\_point\_error} is that the temperature read by it
@@ -1731,9 +1822,9 @@ is accurate, and its post-condition is to return the correct control error value
 %
 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 $)
+This could be detectable (i.e.  the symptoms $\{  VOLTAGE\_HIGH , VOLTAGE\_LOW \} $
 or undetectable (i.e. the post condition for this function simply fails
-or the failure mode $temp\_incorrect$ occurs).
+or the failure mode $VAL\_ERR$ 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
@@ -1743,6 +1834,33 @@ This analysis is presented in table~\ref{tbl:geterror}.
 %
 %
 %
+\begin{table}[h+]
+\center
+\caption{ GetError: Failure Mode Effects Analysis} % title of Table
+\label{tbl:geterror}
+
+\begin{tabular}{|| l | l  | c |   l ||} \hline
+% \textbf{Failure}   &  \textbf{failure}     & \textbf{Symptom}          \\ 
+% \textbf{Scenario}  &  \textbf{effect}      &     \textbf{RADC }                     \\ \hline 
+ \hline 
+ \rowcolor{LightCyan}
+ \textbf{Component} & \textbf{Failure} &  \textbf{Failure }         & \textbf{Symptom}            \\ 
+ \rowcolor{LightCyan}
+ \textbf{}          & \textbf{cause}   &   \textbf{Effect}          &                             \\ \hline
+  
+ 
+               \hline
+  convert\_ADC\_to\_T        & FC1:  VOLTAGE\_HIGH          &  detectable failure         &      $KnownIncorrectErrorValue$        \\  \hline 
+     convert\_ADC\_to\_T     & FC2:  VOLTAGE\_LOW           & detectable failure        &       $KnownIncorrectErrorValue$          \\ \hline 
+         convert\_ADC\_to\_T & FC3:  VAL\_ERR           & detectable failure        &       $IncorrectErrorValue$          \\ \hline  
+
+                 
+ \cf{determine\_sp\_error}  & FC4: post condition fails           & software failure in                &      $IncorrectErrorValue$  \\ 
+                            & in function                         &                                    &                  \\ 
+                            &  \cf{determine\_sp\_error}          &   \cf{determine\_sp\_error}        &                  \\ \hline
+
+\end{tabular}
+\end{table}
 %
 Failure mode symptoms are collected and   a new {\dc} GetError created
 where:
@@ -1779,12 +1897,50 @@ it is the  calling function that sets the context for the \cf{PID} function (i.e
 %HARK THE HERALD ANGELS SING... HARK????
 %
 %
-%
+
+\begin{table}[h+]
+\center
+\center
+
+\label{tbl:geterror}
+\caption{ PID: Failure Mode Effects Analysis} % title of Table
+\begin{tabular}{|| l | l  | c |   l ||} \hline
+% \textbf{Failure}   &  \textbf{failure}     & \textbf{Symptom}          \\ 
+% \textbf{Scenario}  &  \textbf{effect}      &     \textbf{RADC }                     \\ \hline 
+ \hline 
+ \rowcolor{LightCyan}
+ \textbf{Component} & \textbf{Failure} &  \textbf{Failure }         & \textbf{Symptom}            \\ 
+ \rowcolor{LightCyan}
+ \textbf{}          & \textbf{cause}   &   \textbf{Effect}          &                             \\ \hline
+  
+ 
+               \hline
+ GetError       & FC1: $KnownIncorrectErrorValue$         &   safe heater control         &       KnownControlValueErrorV      \\  \hline 
+  GetError     & FC2: $KnownIncorrectErrorValue$          &    safe heater control           &       KnownControlValueErrorV          \\ \hline 
+   GetError        & FC3: $IncorrectErrorValue$           &  unsafe heater control          &      IncorrectControlErrorV        \\ \hline  
+
+                 
+ \cf{GetError}  & FC6: post condition fails           & software failure in    &     IncorrectControlErrorV  \\ 
+                & in function \cf{GetError}           &   \cf{GetError}        &                  \\ \hline
+
+\end{tabular}
+\end{table}
+%%
 The {\dc} PID is created, see table~\ref{tbl:pidfunction}, with the following failure modes:
 %
 $$ fm(PID) = \{  KnownControlValueErrorV, IncorrectControlErrorV \} .$$
 %
-%
+For perspective, if the failure mode is detectable i.e. $KnownControlValueErrorV$
+it is the responsibility of the calling function to act on this and attempt a safety measure (in this case to turn off the heater and indicate an error condition).
+Where the failure mode is not detectable the control will 
+in all likelihood apply an incorrect output.
+A feature  of the FMMD failure analysis process  is that it can reveal that a design may have
+undetectable errors: re-design of the areas affected --- determined by where they are first recognised in the call tree --- identifies their position in the hierarchy
+and thus solutions can be devised.
+
+
+
+
 \begin{figure}[h]
  \centering
  \includegraphics[width=400pt]{../../submission_thesis/CH5_Examples/euler_afferent_PID.png}
@@ -1797,11 +1953,16 @@ $$ fm(PID) = \{  KnownControlValueErrorV, IncorrectControlErrorV \} .$$
 %
 The software call tree for the afferent  flow has now been modelled using FMMD;
 this is represented as an Euler diagram in figure~\ref{fig:euler_afferent_PID}.
-Two call tree branches remain. The LED indication branch and the 
+Two smaller call tree branches remain. The LED indication branch and the 
 PWM/heater output.
 %
+
+
+
 \subsubsection{Efferent flow, PID demand value to PWM output}
 %
+The efferent dataflow, or outputs are now analysed.
+%
 The monitor function calls the \cf{output\_control} function with the PID demand.
 %
 The \cf{output\_control} function then sets the PWM hardware register, which causes the mark space output of the PWM module to
@@ -1820,9 +1981,35 @@ configured and working, and has the correct clock frequency.
 A second pre-condition is that the heating element is connected and working.
 %
 The post-condition is that it sets the correct value into the PWM register
-to implement the power output demand.
-%
+to implement the power output demand. The result of a failure in these pre or post conditions
+would be the heater output being incorrect $HeaterOutputIncorrect$.
+As the PWM controls a digital output, this could also fail by sticking HIGH or LOW
+resulting in the symptoms $HeaterOnFull$ and $HeaterOff$.
 %
+\begin{table}[h+]
+\center
+\label{tbl:heateroutput}
+\caption{ HeaterOutput: Failure Mode Effects Analysis} % title of Table
+\begin{tabular}{|| l | l  | c |   l ||} \hline
+% \textbf{Failure}   &  \textbf{failure}     & \textbf{Symptom}          \\ 
+% \textbf{Scenario}  &  \textbf{effect}      &     \textbf{RADC }                     \\ \hline 
+ \hline 
+ \rowcolor{LightCyan}
+ \textbf{Component} & \textbf{Failure} &  \textbf{Failure }         & \textbf{Symptom}            \\ 
+ \rowcolor{LightCyan}
+ \textbf{}          & \textbf{cause}   &   \textbf{Effect}          &                             \\ \hline
+  
+ 
+               \hline
+PWM       & FC1: Output sticks HIGH         &  heater always on         &      $HeaterOnFull$    \\  \hline 
+PWM       & FC2: Output sticks LOW          &  heater always off    &       $HeaterOff$          \\ \hline 
+HEATER    & FC3: SHORT         &  heater always off         &      $HeaterOff$     \\  \hline 
+HEATER    & FC4: OPEN          &  heater always off    &       $HeaterOff$          \\ \hline 
+ \cf{output\_control}  & FC5: post condition fails           & software failure in    &    $HeaterOutputIncorrect$  \\ 
+                & in function \cf{output\_control}           &   \cf{output\_control}        &                  \\ \hline
+
+\end{tabular}
+\end{table}
 %
 A {\dc} is created called HeaterOutput, see table~\ref{tbl:heateroutput},
 with the following failure modes:
@@ -1830,7 +2017,7 @@ $$fm(HeaterOutput) = \{ HeaterOnFull, HeaterOff, HeaterOutputIncorrect \} .$$
 %
 As an aside: the $HeaterOnFull$ failure should raise alarm bells for designers and
 upon its discovery, measures may be recommended to inhibit this (such as perhaps
-adding a safety relay to cut the power to the heater).
+adding a safety relay to cut the power to the heater if the $HeaterOnFull$ exceeds a given time limit).
 %
 %
 \begin{figure}[h]
@@ -1863,10 +2050,6 @@ The post-condition is that the function \cf{setLEDS} will supply correct indicat
 %
 A {\fg} is formed from the GPIO, the LEDs and the software function \cf{setLEDs}.
 %
-FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
-%
-%
-%
 %
 %
 \begin{figure}[h]
@@ -1879,7 +2062,7 @@ FMMD analysis is applied to this {\fg} in table~\ref{tbl:ledoutput}.
 \end{figure}
 %
 %
-The {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
+FMMD analysis is applied to this {\fg}  resulting in the {\dc} for the setLED function, GPIO and LEDs has the following failure modes:
 $$ fm(LEDoutput) = \{FailureIndicated, IndicationError \} $$
 %
 %
@@ -1903,7 +2086,10 @@ The common causes for software failing are:
 \end{itemize}
 Because the software is running on a medium, that of the processor or micro-controller,
 the FMMD analysis at the final or highest level (see table~\ref{tbl:pid}), must include all possible failure modes of this medium i.e.
-$$fm (micro-controller) =\{ PROM\_FAULT, RAM\_FAULT, CPU\_FAULT, ALU\_FAULT, CLOCK\_STOPPED \}.$$
+
+\begin{eqnarray*}
+ fm (micro-controller) = \{ PROM\_FAULT, \\ RAM\_FAULT, \\ CPU\_FAULT, \\ ALU\_FAULT,  \\ CLOCK\_STOPPED  \}.
+\end{eqnarray*}
 The final FMMD stage forms a {\fg} with the {\dcs}
 determined previously:
 %
@@ -1916,6 +2102,47 @@ determined previously:
 \end{itemize}
 %
 The post-condition for the monitor function is that it implements the PID control task correctly.
+\begin{table}[h+]
+\center
+\label{tbl:heateroutput}
+\caption{ TempController: Failure Mode Effects Analysis} % title of Table
+\begin{tabular}{|| l | l  | c |   l ||} \hline
+% \textbf{Failure}   &  \textbf{failure}     & \textbf{Symptom}          \\ 
+% \textbf{Scenario}  &  \textbf{effect}      &     \textbf{RADC }                     \\ \hline 
+ \hline 
+ \rowcolor{LightCyan}
+ \textbf{Component} & \textbf{Failure} &  \textbf{Failure }         & \textbf{Symptom}            \\ 
+ \rowcolor{LightCyan}
+ \textbf{}          & \textbf{cause}   &   \textbf{Effect}          &                             \\ \hline
+  
+ 
+               \hline
+micro-controller     & FC1:  $PROM\_FAULT$         &  heater always on         &     $ControlFailure$    \\  \hline 
+micro-controller    & FC2: $RAM\_FAULT$          &  heater always off    &      $ControlFailure$         \\ \hline 
+micro-controller    & FC3: $CPU\_FAULT$         &  heater always off         &    $ControlFailure$   \\  \hline 
+micro-controller    & FC4: $ALU\_FAULT$       &  heater always off    &      $ControlFailure$         \\ \hline 
+
+micro-controller    & FC5:  $CLOCK\_STOPPED$       &  heater always off    &      $ControlFailure$          \\ \hline 
+\hline 
+
+PID                 &                              &                       &                                \\ \hline   
+PID                 &                              &                       &                                \\ \hline 
+PID                 &                              &                       &                                \\ \hline 
+
+
+LEDOutput           &                              &                       &                                \\ \hline 
+LEDOutput           &                              &                       &                                \\ \hline 
+LEDOutput           &                              &                       &                                \\ \hline 
+
+
+
+ \cf{monitor}  & FC99: post condition fails           & software failure in    &    $ControlFailure$  \\ 
+                & in function \cf{monitor}           &   \cf{monitor}        &                  \\ \hline
+
+\end{tabular}
+\end{table}
+
+
 %\fmmdglossCONTRACTPROG
 A {\dc} for the standalone temperature controller is now created, and given  the name TempController.
 It will have the following failure modes:
@@ -2011,7 +2238,12 @@ can now no longer be missed or forgotten in the analysis process.
 The {\sw} faces no surprise {\hw} errors that it has no sensible 
 way of dealing with.
 
-Errors introduced by the {\uP} are unresolved in this example. But they are listed.
+Errors introduced by the {\uP} are unresolved in this example but  are listed.
+Some errors like RAM are in practical terms impossible to test with a 100\% coverage.
+For other errors self-checking methods linked to external watchdog processors
+can validate correct working of a micro-controller
+and provide a higher degree of statistical integrity.
+
 
 
  Re-useability  --- the electronics --- the Pt100 --- s/w functions to read ADC values

papers/fermat/fermat.tex

@@ -89,10 +89,14 @@ this can be re-written as:
 
 \begin{equation}
 \label{eqn:primesexpanded1}
-    \prod{cbpf(a,b)}^n   \big( \prod{ubpf(a)^n}  +    \prod{ubpf(b)^n}   \big)  = c^n \; .
+    \prod{cbpf(a,b)}^n   \big( \prod{ubpf(a)^n}  +    \prod{ubpf(b)^n}   \big)  = c^n \; ,
 \end{equation}
 
-
+That is to say the inner bracket on the left hand side is an addition of co-prime numbers,
+\begin{equation}
+\label{eqn:primesexpanded2}
+    \prod{ubpf(a)^n}  \perp   \prod{ubpf(b)^n}    \; .
+\end{equation}
 
 \section{Properties of numbers viewed as products of bags of prime factors}
 
@@ -132,7 +136,13 @@ are lost and the $\prod cbpf(a,b)$ preserved.
 Because of this property of addition of numbers in relation to preserved
 prime factors, it can be used to make inferences on the equation $a^n+b^n = c^n$.
 %
-\subsubsection{trivial example, single prime factor preserved}
+%%% NIEL HARDINGS BIT
+%
+For the classic right angle triangle $3^2+4^2=5^2$ the prime numbers in the 
+addition are not preserved. As products of bags of prime numbers this is 
+$\prod \{3,3\} + \prod\{2,2,2,2\} = \prod \{5,5\}$.
+%
+\subsubsection{Trivial example, single prime factor preserved}
 %
 Consider $bpf(182)=\{2,7,13\}$ and $bpf(2365)=\{5,11,43\}$ these have no common prime factors
 so adding them should result in a number which when factored contains none of the primes in $182$ and $2365$.
@@ -157,7 +167,7 @@ So, $ 322 + 49665 = 49987$: $bpf(49987) = \{7,37,193\}$.
 As expected the common prime factor,7, exists in the result of the addition
 but the uncommon prime factors have disappeared.
 
-\subsubsection{trivial example, multiple prime factor preserved}
+\subsubsection{Trivial example, multiple prime factor preserved}
 
 Consider a repeated prime factor (i.e. a prime $p$ to the power $t$ $p^t$). The same rules apply.
 %
@@ -313,17 +323,107 @@ again this means for the highest prime factor, $p^t$, $a+b$ must equal 1. In oth
 highest prime factor in $c$ must exist in $a$ and $b$ such that they add up to one.
 Thus where $a$ and $b$ are $ > 1$; $a^n + b^n \neq c^n$ for whole numbers.
 
-\subsection{trivial case}
+\subsection{trivial case: single prime number in $c^n$}
 
-Take the trivial case where $n=2$ and  $c$ has the prime number 7 as one of its prime~factors:
+Take the trivial case where $n=3$ and  $c$ has the prime number 7 as one of its prime~factors:
 %
-$$ a^n + b^n = 7^n = 49 \; . $$
+$$ a^n + b^n = 7^n = 343 \; . $$
 %
-In order to get the prime factor 7 in the result both a and b must have the prime number 7 in them.
-That is the numbers $a$ and $b$ must both have the number 7 as a common prime factor
-to get seven as a prime factor in the result.
-Any other number will not give a 7 in the bag of prime numbers representation of the result.
+In order to get the prime factor $7^3$ in the result both $a$ and $b$ must have some proportion of $7^3$ in them.
+That is the numbers $a$ and $b$ must both have the number $7^3$ as a common prime factor
+to get $7^3$ as a prime factor in the result.
+Any other number will not give a $7^3$ in the bag of prime numbers representation of the result.
+Thus to make $ a^n + b^n = 343 $ both a and b could contain fractional quantities of  $7^3$
+but not both.
+Thus for whole numbers, where $\prod bpf(c^n)$ contains a single prime  $ a^n + b^n \neq c^n  \; where \; n < 2$.
 
+\subsection{trivial case: multiple prime numbers in the bags}
+
+Take the trivial case where $n=3$ and  $c$ has the prime numbers 13 and 11 as its prime~factors:
+%
+say $ c = \prod \{ 13,13,13,11 \} = 24167$ cubing this gives $ \prod \{13,13,13,13,13,13,13,13,13,11,11,11\} $ or $ \prod \{13^9,11^3\} $ .
+A strategy of trying to preserve the prime factors under addition can now be attempted.
+To preserve the primes both $13^3$ and $11$ must be present in both a and b.
+So trying $a = \{13^3,11\}$ and  $b = \{13^3,11\}$ taking cubes gives $a^3 + b^3 = \prod \{13^9,11^3,2\}$
+Here both primes $13^3$ and $11$ have been preserved in the addition but there is an extra factor in the result, i.e. the $2$.
+Adding any other prime factors to either $a$ or $b$ makes the result too
+large. Adding the minimum quantity to both in order to preserve the prime factors
+gives a result with the prime factor $2$ in it as well.
+%
+% 
+\paragraph{Looking at just the highest prime factor}
+For numbers to be equal their highest prime factors must have the same index (or power).
+To get the result $c^n$ from the addition $13^3$ must be present in both $a$ and $b$, 
+if it is present singularly in $a$ and $b$, it will 
+be present twice in the result (i.e. adding the prime $2$) to the result product.
+\paragraph{thinking about preserving $13^3$ in the result $c^n$}
+So to preserve $13^3$ in the result; consider $a = \prod \{ 13,13,13\}$ and $b = \{ 13,13,13\}$.
+Adding them cubed; $a^3+b^3 = \prod \{ 13^9\} + \prod \{ 13^9\}$ which can be re-written as
+ $ \prod \{13^9\} (1 + 1) \}$ which gives $\prod \{ 13^9,2 \}$
+; the extra prime factor of 2 means that while $13^3$ was preserved a new prime factor popped up in the result.
+%; as $c$ is to the power of n
+%it should be $2^3$.
+In general this means $a$ and $b$ being whole numbers
+cannot  make the equation $a^n+b^n=c^n$ true.
+%
+Or in  other words it comes back to the addition $ a^n + b^n = c^n $ preserving the common prime factors in the result $c^n$,
+but not the uncommon factors. 
+%
+\paragraph{Case where $a^n$ and $b^n$ may have a large number of uncommon factors}
+A prime number may be produced by the addition
+that is larger than any found in $a$ or $b$.
+If this occurs, the new larger prime will not be present in $c^n$.
+Thus for whole numbers, where $\prod bpf(c^n)$ contains multiple primes  $ a^n + b^n \neq c^n  \; where \; n < 2$.
+
+% \subsection{Another way to look at it}
+% 
+% Take the highest prime factor in the result $c^n$.
+% Try to reproduce it using integers with $a^n$ and $b^n$.
+% 
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% IS it true that if there are any common factors a^n +b^n = c^n cannot exist
+% even for n >= 2 ????
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\subsection{Hole in the theory..... pythagorean squares.... and bollocks}
+
+Pythagorean squares all contain uncommon prime factors in their addition and create
+a large prime to the power of 2 as a result.
+Fermat's last theorem is for powers, the $n$ factor, of greater than 2.
+Consider where all the cubed prime factors in $a$ and $b$ are uncommon (the is $a$ and $b$ are co-prime).
+The result of the addition will create a number that is the product of prime
+numbers; why could some combination not produce a number with $n$ times the power of
+all its primes.
+Consider that although the numbers $a$ and $b$ are co-prime, there will
+be prime numbers `missing' from both $a$ and $b$. If both numbers
+added are odd, the prime factor 2 has to pop-up.
+If 2 is a common prime factor but 3 is not that will pop-up and so on.
+
+But I am stumped here. If all the numbers in $a$ and $b$ are co-prime, i.e $a \perp b$,  
+$a^n + b^n$ could, magically, produce a result where the result $n$ number of the same prime, 
+or even several prime factors, but all to the power of $n$, i.e. $c^n$ where $c$ 
+is the prime addition of $a^n + b^n$. I just cannot see why not, so all this has proved nothing. Arrrrghhhhh.
+Probably good for the soul to look at prime numbers a-lot.....
+
+Maybe you can take prime triplets say, and try to work back in some general way and show no $a^3 + b^3$ integer solution exists?
+Or a general way of showing $a^n + b^n \; where \; n > 2$ cannot produce a simple $n$ number of all prime factors shown in the result....
+That is the last thing........ that is the only way flt  can have an exception, where $a \perp b$, AND 
+it produces a $c^n$ where c is an integer.....
+
+BUT IS IT  A HOLE
+
+IT JUST MEANS THERE IS ONLY one special case for an flt 
+
+Common primes are disproved in this way,
+only where $a^n + b^n = \forall p \in c^n | p \perp a \wedge p \perp b$ can actually work and this
+means $a \perp b$.
+
+
+$ a \perp b \perp c $ this is actually how it works for Pythagorean triangles.
+Is there anyway to go back from $\forall p \in c^n | p \perp a \wedge p \perp b $
 
 \section{Further work}
 
@@ -357,8 +457,8 @@ $$\prod \{2,2\} + \prod \{3,3,5,5,13,13,17,17\} = \{10989229\};$$
 %$ans =  10989229
 gives a larger prime number 10989229 and so on.
 
-\subsection{fishing with cubic primes}
-Fishing with primes cubes reveals larger primes quicker: take
+\subsection{Fishing with cubic primes}
+Fishing with primes cubed reveals larger primes quicker: take
 $$ \prod \{2,2,2,5,5,5,11,11,11\} + \prod \{3,3,3,7,7,7,13,13,13\} = \prod \{ 383 ,  56599 \} \; ,$$
 Adding 56599 as a single uncommon factor;
 $$ \prod \{2,2,2,5,5,5,11,11,11\} + \prod \{3,3,3,7,7,7,13,13,13,56599\} = \prod \{ 151, 359, 1553, 13679 \} \; , $$

papers/fermat/p.py

@@ -0,0 +1,40 @@
+
+
+
+
+
+# find prime factors of a number
+def primefactors(x):
+  factorlist=[]
+  loop=2
+  while loop<=x:
+    if x%loop==0:
+       x/=loop
+       factorlist.append(loop)
+    else:
+       loop+=1
+  return factorlist
+
+
+
+
+
+def tree(a,b):
+  print "tree called with ",a,b;
+  pf = primefactors(a+b);
+  print "prime factors of adition" , pf;
+  if len(pf) > 1:
+    for p in pf:
+      p;
+      aa = a * p;
+      print "a side cfp added"
+      pf2 = tree(aa,b);
+      bb  = b * p;
+      print "b side cfp added"
+      pf2 = tree(a,bb);
+  else:
+    print " |>------------> single prime stopping tree branch iteration", pf
+
+
+tree(51,27);
+print "prime factors of 2468 are ", primefactors(2468);