Tools used in fault isolation cover a wide range of
applications, including (but not limited to) combat
systems tests, subsystems tests, on-line/off-line test-
ing, and diagnostic testing programs.
This section briefly covers these items and gives
examples of their use, where appropriate.
Combat Systems Tests
Combat systems tests are the highest level of tests
that can be performed to verify the readiness or align-
ment of a combat system. The OCSOT is one of the
major combat systems tests; it is designed to test a
combat system as a single, fictional unit. Major
faults in the subsystems usually show up during the
OCSOT; often, this is the first indication of a problem
in a particular subsystem. Keep in mind, however,
that the OCSOT does not test the full operability of a
combat system or its subsystems; it provides only an
overview of systems performance.
Another important test is the combat systems
alignment test, which is a programmed test tool
designed to measure the relative beam alignment (or
misalignment) between a reference sensor and a sen-
sor under test. The measure of misalignment is
accomplished by collecting the range, bearing, and
elevation data from the reference and test sensors.
Then the test sensor data is compared to the reference
data, and the results are shown on a display console
for analysis. The sensors that can be tested include the
gun or missile fire-control radars and surface-or air-
search radars. A hard-copy printout can be obtained to
provide a record.
Subsystem Tests
Subsystem tests aid in fault isolation by testing
specific functions within a subsystem to determine if
they are generated correctly. In many cases, these tests
check the transmission of data between the subsystem
under test and associated subsystems. Computer pro-
grams are available that provide specific test capa-
bilities suited to subsystem testing. An example of
such a program is the Programmed Operational and
Functional Appraisal (POFA). The POFA programs,
for which the subsystem test is named, are non-
resident programs that detect and isolate malfunctions
by transmitting selectively configured and controlled
data between a computer and a computer ancillary
equipment interface.
A typical example of a subsystem test is the fire-
control system (FCS) daily system operability test
(DSOT). The DSOT assesses weapons system
readiness in the normal mode of operation for an
antiaircraft (AA) target from designation through
acquisition, track, weapons control, simulated firing,
and post-firing evaluation.
Test procedures are controlled by the test con-
ductor, who calls out the step numbers in sequence.
The personnel performing the steps in the various
spaces inform the test conductor when the action or
observation required by that step is completed. No
response restrictions are placed on personnel, except
where the steps are underlined in the procedure. In
this case, instruction words are also underlined, indi-
cating the quantity or indication upon which the
request for the response is based. Steps not under-
lined, but containing underlined instructions, denote
the response requested (Mark, Fired, etc.). Underlined
step numbers denote those steps to be recorded for
evaluation and scoring.
All responses should be given as soon as practical
after the completion of the step, particularly in those
areas of the test where the timing is important or when
a sequence of events must commence immediately
after a required action or observation. Timely re-
sponses aid in decreasing time requirements.
When a fault occurs during combat systems or
subsystems testing and before detailed fault-isolation
procedures are initiated, the operational steps should
be repeated to ensure that the fault is an actual fault
and not an operator error. If the fault still exists, you
should ensure that the combat system or subsystem is
properly configured for the test event performed; that
is, switches are properly set, correct function codes
are selected, etc.
1-7
