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

.

Browse Source
This commit is contained in:
Robin 2010-05-30 19:10:11 +01:00
parent 9ea027ac14
commit 1dbea224e9
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
symptom_ex_process/symptom_ex_process.tex
View File

@ -194,9 +194,14 @@ output stage, and a failed internal audio amplifier,
will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms}
The common symptoms of failure are identified and collected.
The common symptoms of failure and lone~component failure~modes are identified and collected.
we can now consider the functional~group as a component and the common symptoms as its failure modes.
Note that here because this is bottom up, we can ensure that all failure modes
associated with a functional~group have been handled.
It is possible here for an automated system to flag unhandled failure modes.
\ref{requirement at the start}
% \paragraph{symptom abstraction represented on the diagram} This process can be applied using a diagram. From the collection of parts for the sub-system under analysis, a set of failure modes for each component is obtained. A diagram is then drawn with each component failure mode represented by a contour. Component failure mode combinations are chosen for `test cases'.\footnote{Combinations of component failure modes can be represented by overlapping contours} A `test case' is represented on the diagram as a point or asterisk, in a region enclosed by the contours representing the failure modes it investigates. The effect on the sub-system of each test case is analysed. %It is then represented on the diagram by an asterisk on the contour representing the failure mode. The `test~case~results' are archived. When all test cases have been analysed, we switch our attention to a higher abstraction level. % We treat the sub-system as a black box, or as a component part itsself. % We can now look at the test case results from the perspective of a `user' % of this sub-system. % %
% We treat the sub-system as a `black box' and view the effects of the component failure
% at the sub-system level. This mean we are not interested so much in what the compoent does,