Instrumentation & Measurement Magazine 23-5 - 14

procedures; identification of support equipment; safety and
other precautions; and data related to future modifications and
enhancements of the TPS.

TPS Debug and Integration - Phase D
Before the TPS is loaded on the ATS, a pre-integration review
is normally conducted to verify that the TPS, both software
and hardware, is ready to go on station. After the TPS has
been integrated with the ATS, a large number of faults are actually inserted in the UUT itself to check the performance of
the program. Any errors that are encountered will be noted,
and appropriate rework will be started. Records will be kept
of all fault-insertion and testing activities in an engineering
logbook, that will include the time expended on the ATS or development stations, number and description of faults inserted
and isolated, corrections made to the TPS, and any problems
encountered during the tests. The customer, along with the
TPS development organization's QA representation, will participate in the fault insertion testing occurring at this time.
Intended users of the TPS may also participate during this
testing, providing valuable user feedback. Observations from
everyone involved will form the best historical data on the TPS
performance and will affect the customer confidence level in
the final product. This data may be used in the future to compare against actual data that is acquired over time with respect
to performance on UUTs. This will allow for QA to provide
feedback for potential improvements to the overall process
and procedures.

TPS Acceptance and Delivery - Phase E
At the conclusion of Debug and Integration, the developer will
formally notify the customer that the TPS is ready for acceptance and provide to the customer all materials to be used in
the demonstration. This formal submission will be at least 15
days prior to the scheduled acceptance testing. The customer
will review the submitted material for completeness and correctness and participate in the demonstration, including fault
insertion, if necessary. A post demonstration meeting will be
held to discuss the customer's acceptance or rejection of the
TPS. If the TPS is rejected, the alternatives will be discussed,
and a course of action will be recommended by the customer;
this may include redesign or rework of the TPS.

Quality Assurance Program Plan
Fig. 2. Phased TPS Development Control Plan.

TPS Production - Phase C
The actual coding of the test sequences and the fabrication
of the interface device will be initiated only after customer
approval of the detailed TDD review. The developer will comply with customer standards for coding and documentation
as stated in the contract or in the contractor's approved TPS
QA Plan. All documentation for use and maintenance of the
TPS will be developed. It will include Test Description (TD);
operator instructions for setup, execution, and tear down
14

The Quality Assurance Program Plan must describe in detail the QA organization, planning, testing, and inspection to
be performed on the TPS. This plan when developed should
provide maximum assurance that the quality and reliability inherent in the original design is maintained through all phases
of the manufacturing, test, and acceptance process of the TPS.
The following items are of major importance and should be defined and/or described within this plan.
◗◗ Description of the quality organization and responsibility
and authority of each functional element;
◗◗ Documentation prepared to implement the quality
program (e.g., training and indoctrination manuals,

IEEE Instrumentation & Measurement Magazine

August 2020

Instrumentation & Measurement Magazine 23-5

Table of Contents for the Digital Edition of Instrumentation & Measurement Magazine 23-5