diff --git a/papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex b/papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex index 97bdcd1..cf25222 100644 --- a/papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex +++ b/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 diff --git a/submission_thesis/CH2_FMEA/burntoutpinto.png b/submission_thesis/CH2_FMEA/burntoutpinto.png deleted file mode 100644 index b5d0baf..0000000 Binary files a/submission_thesis/CH2_FMEA/burntoutpinto.png and /dev/null differ diff --git a/submission_thesis/CH2_FMEA/mvamp.png b/submission_thesis/CH2_FMEA/mvamp.png deleted file mode 100644 index be51da7..0000000 Binary files a/submission_thesis/CH2_FMEA/mvamp.png and /dev/null differ diff --git a/submission_thesis/CH2_FMEA/tech_meeting.png b/submission_thesis/CH2_FMEA/tech_meeting.png deleted file mode 100644 index c25606b..0000000 Binary files a/submission_thesis/CH2_FMEA/tech_meeting.png and /dev/null differ