CH8 PR, fran mor tack
This commit is contained in:
parent
9ea9b8f3f0
commit
aea7136682
@ -12,16 +12,19 @@ Environment in the context of this study
|
|||||||
means external influences under which the System could be expected to work. % under.
|
means external influences under which the System could be expected to work. % under.
|
||||||
%
|
%
|
||||||
A typical data sheet for an electrical component will give
|
A typical data sheet for an electrical component will give
|
||||||
a working temperature range, for instance.
|
a working temperature range: %, for instance.
|
||||||
Mechanical components could be specified for stress and loading limits.
|
mechanical components could be specified for stress and loading limits.
|
||||||
|
It is unusual to have failure modes described in product literature, although
|
||||||
|
for complicated components with firmware errata documents are sometimes produced.
|
||||||
|
|
||||||
Systems may have distinct operational states. For instance, a safety critical controller
|
Systems may have distinct operational states. For instance, a safety critical controller
|
||||||
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
|
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
|
||||||
authorised human intervention takes place.
|
authorised human intervention takes place.
|
||||||
A safety critical circuit may have a self test mode which could be operated externally.
|
A safety critical circuit may have a self test mode which could be operated externally:
|
||||||
|
a micro-processor may have a SLEEP mode etc.
|
||||||
%
|
%
|
||||||
Operational states and environmental conditions must be factored into the UML model.
|
Operational states and environmental conditions can %must
|
||||||
|
be factored into the UML model.
|
||||||
|
|
||||||
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
||||||
levels of electrical interference, high voltage contamination on supply
|
levels of electrical interference, high voltage contamination on supply
|
||||||
@ -31,7 +34,7 @@ affected by environmental conditions, in this case temperature, is the opto-isol
|
|||||||
which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
|
which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
|
||||||
Environmental analysis is thus applicable to components.
|
Environmental analysis is thus applicable to components.
|
||||||
Environmental influences, such as over stress due to voltage
|
Environmental influences, such as over stress due to voltage
|
||||||
can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
|
can be eliminated by down-rating components as discussed in section~\ref{sec:determine_fms}.
|
||||||
With given environmental constraints, we can therefore eliminate some failure modes from the model.
|
With given environmental constraints, we can therefore eliminate some failure modes from the model.
|
||||||
|
|
||||||
|
|
||||||
@ -52,13 +55,16 @@ When the TEST line is activated, it supplies a test signal
|
|||||||
which will validate the circuit. This circuit will have two operational states,
|
which will validate the circuit. This circuit will have two operational states,
|
||||||
NORMAL and TEST mode.
|
NORMAL and TEST mode.
|
||||||
%
|
%
|
||||||
It seems better to apply the operational states to {\fgs}.
|
It seems more appropriate to apply the operational states to {\fgs}
|
||||||
%
|
which %
|
||||||
Functional groupings by definition implement functionality, or purpose, and therefore are the best objects to model
|
%Functional groupings
|
||||||
operational states.% with.
|
by definition implement functionality, or purpose.
|
||||||
|
On this basis we associate operational states with {\fgs}.
|
||||||
|
%therefore are the best objects to model
|
||||||
|
%operational states.% with.
|
||||||
|
|
||||||
\paragraph{Inhibit Conditions.}
|
\paragraph{Inhibit Conditions.}
|
||||||
A third data class may be required if modelling of inhibit conditions~\cite{nasafta}[p.40] is desired.
|
A third data class may be required if modelling inhibit conditions~\cite{nasafta}[p.40] is required. %desired.
|
||||||
Some failure modes may only be active given specific environmental conditions
|
Some failure modes may only be active given specific environmental conditions
|
||||||
or when other failures are already active.
|
or when other failures are already active.
|
||||||
To model this, an `inhibit' class has been added.
|
To model this, an `inhibit' class has been added.
|
||||||
@ -99,7 +105,8 @@ EN61508~\cite{en61508} requires that statistical data is available and used for
|
|||||||
analysed in a system assigned a SIL level.
|
analysed in a system assigned a SIL level.
|
||||||
FMMD, as a bottom up methodology can use component failure mode statistical data, and incorporate it
|
FMMD, as a bottom up methodology can use component failure mode statistical data, and incorporate it
|
||||||
into its hierarchical model.
|
into its hierarchical model.
|
||||||
By way of example the Pt100 example from section~\{sec:pt100} has been used to demonstrate this.
|
By way of example, the Pt100 analysis %example
|
||||||
|
from section~\{sec:pt100} has been used to demonstrate this.
|
||||||
|
|
||||||
\subsection{Pt100 Example: Single Failures and statistical data}. %Mean Time to Failure}
|
\subsection{Pt100 Example: Single Failures and statistical data}. %Mean Time to Failure}
|
||||||
|
|
||||||
@ -281,7 +288,7 @@ we can also apply failure rate statistics to double failures.
|
|||||||
%%
|
%%
|
||||||
%
|
%
|
||||||
If we consider the failure modes to be statistically independent we can calculate
|
If we consider the failure modes to be statistically independent we can calculate
|
||||||
the FIT values for all the combinations failures in table~\label{tab:ptfmea2}.
|
the FIT values for all the combinations failures in table~\ref{tab:ptfmea2}.
|
||||||
The failure mode of concern, the undetectable {\textbf{FLOATING}} condition
|
The failure mode of concern, the undetectable {\textbf{FLOATING}} condition
|
||||||
requires that resistors $R_1$ and $R_2$ fail. We can multiply the MTTF
|
requires that resistors $R_1$ and $R_2$ fail. We can multiply the MTTF
|
||||||
together and find an MTTF for both failing. The FIT value of 12.42 corresponds to
|
together and find an MTTF for both failing. The FIT value of 12.42 corresponds to
|
||||||
@ -299,7 +306,7 @@ condition in higher levels of the system.
|
|||||||
|
|
||||||
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
|
The reasons for applying retrospective failure mode analysis could be approving previously un-assessed
|
||||||
systems to a safety standard, or to determine the failure mode behaviour of an instrument used in
|
systems to a safety standard, or to determine the failure mode behaviour of an instrument used in
|
||||||
safety critical verification verification.
|
safety critical verification. % verification.
|
||||||
%
|
%
|
||||||
FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with
|
FMMD can be applied retrospectively to a project, and because of its modular nature, coupled with
|
||||||
its work flow it
|
its work flow it
|
||||||
@ -319,17 +326,23 @@ We can apply retrospective FMMD to electronic and software hybrid systems as wel
|
|||||||
Each function in the software will have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
|
Each function in the software will have to be assigned a `design~contract'~\cite{dbcbe} (where violations of
|
||||||
contract clauses will be treated as failure modes in FMMD).
|
contract clauses will be treated as failure modes in FMMD).
|
||||||
%
|
%
|
||||||
By doing applying contracts and seeing how calling functions deal with
|
By %doing
|
||||||
|
applying contracts and seeing how calling functions deal with
|
||||||
the failures in the functions they call, we reveal un-handled the error conditions in
|
the failures in the functions they call, we reveal un-handled the error conditions in
|
||||||
the software.
|
the software.
|
||||||
|
By treating hardware interfaces to software as {\dcs}, we automatically have a list of the failure modes
|
||||||
|
of the electronics.
|
||||||
%
|
%
|
||||||
FMMD models both software and hardware;
|
FMMD models both software and hardware;
|
||||||
we can thus verify that all
|
we can thus verify that all
|
||||||
failure modes from the electronics module, have been dealt
|
failure modes from the electronics module, have been dealt
|
||||||
by the controlling software. If not they are an un-handled error condition.
|
by the controlling software. If not they are an un-handled error condition.
|
||||||
|
That is the hardware interfaces to software in FMMD is a {\dc},
|
||||||
|
the failure modes of this {\dc} are the list of all known failure modes
|
||||||
|
of the electronics.
|
||||||
%
|
%
|
||||||
By performing FMMD on a software electronic hybrid system,
|
By performing FMMD on a software electronic hybrid system,
|
||||||
we can reveal design deficiencies.
|
we thus reveal design deficiencies.
|
||||||
%in the hardware/software interface.
|
%in the hardware/software interface.
|
||||||
In Safety Integrity Level (SIL)~\cite{en61508} terms by identifying undetectable faults and fixing them, we raise
|
In Safety Integrity Level (SIL)~\cite{en61508} terms, by identifying undetectable faults and fixing them, we raise
|
||||||
the safe failure fraction (SFF).
|
the safe failure fraction (SFF).
|
||||||
|
Loading…
Reference in New Issue
Block a user