typos mainly

This commit is contained in:
Robin P. Clark 2012-07-31 08:36:31 +01:00
parent ec8d020d4e
commit 3705057f9b

View File

@ -282,7 +282,7 @@ we have yet another layer of complication.
%we need to re-think the
%FMEA concept of simply mapping a base component failure to a system level event.
%
SFMEA regard, in place of hardware components, the variables used by the programs to be their equivalent~\cite{procsfmea}.
SFMEA regards, in place of hardware components, the variables used by the programs to be their equivalent~\cite{procsfmea}.
The failure modes of these variables, are that they could become erroneously over-written,
calculated incorrectly (due to a mistake by the programmer, or a fault in the micro-processor it is running on), or
external influences such as
@ -697,7 +697,7 @@ SFMEA and HFMEA methodologies used to describe a failure mode model.
%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 four several perspectives.
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.
@ -718,11 +718,11 @@ 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 may not take into account particular
System outputs commanded from software may not take into account particular
hardware limitations etc.
The interface FMEA does serve to provide a useful
checklist to ensure conventions used by the hardware
check-list to ensure data and synchronisation conventions used by the hardware
and software are not mismatched.
However, while these techniques ensure that the software and hardware is