typos and a rough draft of the conclusion

papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex

@@ -1490,59 +1490,22 @@ and ram complement checking can be applied.
 
 \section{Conclusion}
 
-This paper has picked a very simple example (the industry standard {\ft}
-input circuit and software) 
-to demonstrate
-SFMEA and HFMEA methodologies used to describe a failure mode model.
-Even a modest system would be far too large to analyse in conference paper
-and this 
+Effeciency --- the $O(N^2)$ has been broken down by making it
+several much easier to deal with $O(n^2)$ analyis stages.
 
-The {\dc} representing the {\ft} reader
-shows that by taking a 
-modular approach for FMEA, i.e. FMMD, we can integrate
-Our model is described by four FMEA reports; and these % we can model the failure mode behaviour from
-model the system from  several failure mode perspectives.
-
-With traditional FMEA methods the reasoning~distance is large, because
-it stretches from the component failure mode to the top---or---system level failure.
-
-With these four  analysis reports
-we do not have stages along the `reasoning~path' linking the failure modes from the 
-electronics to those in the software.
-Software is often written `defensively' but t 
-Each {\fg} to {\dc} transition represents a 
-reasoning stage.
+While there are no FMEA metrics to compare a sw hw hybrid
+using FMMD an estimate of the work to perform, the reasoning distance, can be calculated.
 
 
-For this reason applying traditional FMEA to software stretches
-the reasoning distance even further.
+hw sw interface is handled naturally. Any hw failures
+can now no longer be missed or forgotten in the analysis process.
+The sw faces no suprise hw errors that it has no sensible 
+way of dealing with.
 
-In fact many these reasoning paths overlap---or even by-pass one another---
-it is very difficult to gauge cause and effect.
-For instance, hardware failures are not analysed in the context of how they will
-be handled (or missed) by the software. 
-
-System outputs commanded from software may not take into account particular
-hardware limitations etc.
-
-The interface FMEA does serve to provide a useful
-check-list to ensure data and synchronisation conventions used by the hardware
-and software are not mismatched. However, the fact it is perceived as required
-highlights the the miss-matches possible between the two types of analysis
-which could run deeper than the mere interface level.
+Errors introduced by the uP are unresolved in this example. But they are listed.
 
 
-However, while these techniques ensure that the software and hardware is
-viewed and analysed from several perspectives, it cannot be termed a homogeneous
-failure mode model.
- For instance
- were the ADC to have a small value error, say adding
- a small percentage onto the value, we would be unable to
- detect this under the analysis conditions for this model, or
- be able to pinpoint it.
- 
-
-Need wishlist ticks and solved problems here.
+ Re-useability  --- the electronics --- the Pt100 --- s/w functions to read ADC values
 
 {
 \footnotesize