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