requirements for system specification. Quantitative testability
requirements are derived from the tradeoff analysis during the D&V phase
and are incorporated in the system specification. Requirements may be
expressed in terms of goals and thresholds rather than as a single number.
Model requirements for testability in a system specification are provided in
5 and are discussed below.
The system specification includes
testability requirements for failure detection, failure isolation and BIT
constraints. Requirement (a) defines the interface between the prime syetem
and an external monitoring system, if applicable. Particular attention should
be given to the use of BIT circuitry to provide performance and status
monitoring. Requirement (b) provides the basis for all subsequent test design
and evaluation. Failure modes are characterized besed upon the component
technology used, the assembly process used, the detrimental environment
effects anticipated in the intended application, etc. Maximum use should be
made of prior reliability analysis and fault analysis data such as FMEA and
fault trees. The data represent a profile of estimated system failures to be
constantly refined and updated as the design progresses.
Requirements (c) through (e) deal with
test approaches. Requirement (c) permits the use of all test resources and, as
such, should always demand 100% failure coverage. Requirement (d) indicates
the proportion of failures to be detected automatically. Excluded failures
form the basis for manual troubleshooting procedures (swapping large items,
manual probing, etc.). Requirement (e) is a requirement for dealing quickly
with critical failures and is a subset of (d). The failure detection approach
selected is based upon the requirement for maximum acceptable failure latency.
Concurrent (continuous) failure detection techniques (utilizing hardwere
redundancy, such es parity) are specified for monitoring those functions which
are mission critical or affect safety and where protection must be provided
against the propegation of errors through the system. The maximum permitted
failure latency for concurrent failure detection and other classes of
automatic testing is imposed by requirement (f). This requirement determines
the frequency at which periodic diagnostic softwere, etc. will run. The
frequency of periodic and on-demand testing is based upon function, failure
rates, wear out factors, maximum acceptable failure latency, and the specified
operational and maintenance concept.
Requirement (g) is the maximum BIT false
alarm rate. Alarms which occur during system operation but cannot be later
duplicated may actually be intermittent failures or may indeed be a true
probtem with the BIT circuitry. It may be useful to use the system
specification to require sufficient instrumentetion in the system to allow the
sorting out and correction of real BIT problems (e.g., BIT faults, wrong
thresholds, etc.) during operational test and evaluation.
Requirement (h) requires fault isotation
by BIT to a subsystem or to a lower level part, depending upon the maintenance
concept. This requirement is usually expressed as "fault isolation to one
item X% of the time, fault isolation to N or fewer items Y% of the time."
Here, the total failure population (100%) consists of those failures detected
by BIT (requirement (d)). The percentages should always be weighted by failure
rates to accurately reflect the effectiveness of BIT in the field.
Requirement (i), fault isolation time, is
derived from maintainability requirements, primarily Mean Time to Repair
(MTTR) or repair time at some percentile.
Fault isolation time = repair time -
(preparation time + disassembly time + interchange time + reassembly time +
alignment time + verification time)
The preparation time, disassembly time,
interchange time, reassembly time and alignment time may be estimated. The
verification time is usually equal to the failure detection test time in that
the same tests are likely to be used for each.
Requirement (j), BIT constraints, should
not be arbitrarily imposed but should be consistent with the BIT performance
specified in requirements (a) through (i). Historically, systems have needed
about 5 to 20% additional hardware for implementations of adequate BIT.
However, for some systems, 1% may be sufficient whereas other systems may need
more than 20%.
Requirement (k), BIT reliability, again
should not be arbitrarily imposed but should be consistent with the required
BIT performance. This requirement may also be used to specify those critical
functions for which a failed BIT must not