robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

S/w spec improved by knowing h/w interface

Browse Source 
failure modes supplied by FMMD
This commit is contained in:
Robin Clark 2012-05-13 18:56:15 +01:00
parent 3bc024e545
commit 228f190964
2 changed files with 14 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
papers/fmmd_software_hardware/software_fmmd.tex
View File

@ -1023,7 +1023,9 @@ detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
Detailing this however, is beyond the scope %and page-count Detailing this however, is beyond the scope %and page-count
of this paper. of this paper.
A software specification for a hardware interface will concentrate on
how to interpret raw readings, or what signals to apply for actuators.
Using FMMD we can determine an accurate failure model for the interface as well.
%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! %Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!

11
submission_thesis/CH5_Examples/copy.tex
View File

@ -3045,6 +3045,10 @@ 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) are the failure modes of the software components (other functions it calls)
and the hardware its reads values from. and the hardware its reads values from.
Its outputs are the data it changes, or the hardware actions it performs. 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 When we have analysed a software function---using failure conditions
of its inputs as failure modes---we can of its inputs as failure modes---we can
@ -3616,11 +3620,14 @@ Each functional group to {\dc} transition represents a
reasoning stage. reasoning stage.
% %
With traditional FMEA methods the reasoning~distance is large, because With traditional FMEA methods the reasoning~distance is large, because
it stretches from the component failure mode to the top---or---system level failure. it stretches from the component failure mode to the top---or---system level failure.
For this reason applying traditional FMEA to software stretches For this reason applying traditional FMEA to software stretches
the reasoning distance even further. the reasoning distance even further.
We now have a {\dc} for a {\ft} input in software. We now have a {\dc} for a {\ft} input in software.
Typically, more than one such input could be present in a real-world system. Typically, more than one such input could be present in a real-world system.
Not only have we integrated electronics and software in an FMEA, we can also Not only have we integrated electronics and software in an FMEA, we can also
@ -3630,6 +3637,10 @@ The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addresse
by another software function to read other known signals by another software function to read other known signals
via the MUX (i.e. voltage references). This strategy would via the MUX (i.e. voltage references). This strategy would
detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
A software specification for a hardware interface will concentrate on
how to interpret raw readings, or what signals to apply for actuators.
Using FMMD we can determine an accurate failure model for the interface as well.
% %
%Detailing this however, is beyond the scope %and page-count %Detailing this however, is beyond the scope %and page-count
%of this paper. %of this paper.