Strategics | Studies, Essays, Thesises » The Naval Air Systems Command Operational Test Program Set Acquisition and Sustainment Process Standard Operating Procedures

NAVAIR SOP 13630.5 THE NAVAL AIR SYSTEMS COMMAND OPERATIONAL TEST PROGRAM SET ACQUISITION AND SUSTAINMENT PROCESS STANDARD OPERATING PROCEDURES Authored by: PMA260 Updated: 29 May 2020 Version 1.1 Approved by: BURGESS.ROB ERT.L1094116 739 Digitally signed by BURGESS.ROBERTL109 4116739 Date: 2020.0529 08:24:34 -0400 Robert L. Burgess, CAPT USN Program Manager, Aviation Support Equipment i NAVAIR SOP 13630.5 RECORD OF CHANGES Identification of Correction or Change Date of Change Supersedes The NAVAIR Operational 5/29/20 Test Program Set (OTPS) Acquisition and Sustainment Process Ver 1.0 July 2012; Incorporate changes needed due to new Mission Aligned Organization (MAO) and other needed updates. Version 1.1 Entered By T. Conard For questions or to give feedback Contact: Brian Cervenak, PMA260 ATS APML brian.cervenak@navymil, (301) 757-6836 A copy of this Handbook will be posted on the NAVAIR Directives website at https://myteam.navairnavymil/km/71/Directives/ FOREWORD This

SOP supersedes The NAVAIR Operational Test Program Set (OTPS) Acquisition and Sustainment Process document version 1.0 dated July 2012 This SOP is issued to prescribe procedures and guidance for the Naval Air Systems Command (NAVAIR) Operational Test Program Set Acquisition and Sustainment Process. This SOP is implemented consistent with ii NAVAIR SOP 13630.5 NAVAIRINST 136305 or its succeeding document(s), NAVAIR Optimizing Weapon System Avionics Support Using Automatic Test Systems. Local supplements to amplify this SOP may be issued. A local supplement will not contradict or repeat information contained in this SOP or NAVAIRINST 13630.5 Forward recommended changes to this SOP to: FRCSE ISSCSE CECIL COMMERCE CENTER ATTN: PMA260 Support Equipment (SE) Division Site Lead 6206 AVIATION AVE JACKSONVILLE FL 32221-8112 Phone: 904-317-1697 A copy of this SOP is available on the NAVAIR Directives Web site, located under the “Guidance” tab at: https://directives.navairnavymil iii

NAVAIR SOP 13630.5 TABLE OF CONTENTS CHAPTER 1 INTRODUCTION. 1-1 CHAPTER 2 THE OTPS ACQUISITION PROCESS . 2-3 CHAPTER 3 THE OTPS SUSTAINMENT PROCESS . 3-1 CHAPTER 4 DEFINITIONS . 4-1 APPENDIX A UNIT UNDER TEST (UUT) DATA REQUIREMENTS FOR OPERATIONAL TEST PROGRAM SETS DEVELOPMENT . A-1 APPENDIX B AUTOMATIC TEST EQUIPMENT DATA REQUIREMENTS FOR OPERATIONAL TEST PROGRAM SETS DEVELOPMENT . B-1 APPENDIX C CONSOLIDATED AUTOMATED SUPPORT SYSTEM (CASS) FAMILY OPERATIONAL TEST PROGRAM SETS (OTPS) DEVELOPMENT TOOLS AND EQUIPMENT. C-1 APPENDIX D ACRONYMS . D-1 iv NAVAIR SOP 13630.5 RESOURCES 1. NAVAIRINST 136305A, Optimizing Weapon System Avionics Support Using Automatic Test Systems - https://directives.navairnavymil/ 2. NAVAIR Generic OTPS Request for Proposal (RFP) (NGOR) https://pma260navairnavymil/intranet/root/framescfm 3. NAVAIR 00-25-300, “Naval Air Systems Command Technical Directives System Management and Procedures Manual” 30 July 2015 - https://mynatec.navairnavymil 4.

NAVAIR SOP 41301, Naval Air Systems Command Standard Operating Procedure https://directivesnavairnavymil/ 5. Commander, Naval Air Forces Instruction (COMNAVAIRFORINST) 47902C CH-1, “The Naval Aviation Maintenance Program” - http://www.navairnavymil/logistics/4790/ 6. DoD Automatic Test Systems Selection Process, Revision A, dated 15 June 2016 – http://www.acqosdmil/log/mpp/atshtml 7. OPNAVINST 396016B, Navy Test, Measurement, and Diagnostic Equipment, Automatic Test Systems, and Metrology and Calibration – https://doni.documentservicesdlamil/defaultaspx v NAVAIR SOP 13630.5 CHAPTER 1 INTRODUCTION 1.1 Purpose The purpose of this document is to define the overarching standard Automatic Test System (ATS) processes to be used by all Naval Aviation weapon system programs for acquiring and sustaining Operational Test Program Sets (OTPS) developed to operate on the Consolidated Automated Support System (CASS) Family of Testers (FoT), referred to in this document as CASS or CASS

FoT. CASS FoT currently includes three generations of test systems: the original CASS, the Reconfigurable Transportable CASS (RTCASS), and the latest generation, the electronic CASS (eCASS). All OTPS hosted by the CASS FoT require interoperability with the host CASS system with regard to configuration control, hardware and software architecture, and functional requirements for the software applications that operate on the CASS system, especially OTPS software. Therefore, OTPSs are to be developed and sustained per the requirements of this document. 1.2 Document Organization The document is organized into three major sections: • • • Chapter 2 defines the OTPS Acquisition Process; Chapter 3 defines the OTPS Sustainment Process; and Chapter 4 provides a brief tutorial of terms that are unique and critical to the OTPS Acquisition and Sustainment Process. (It is highly recommended that this section be reviewed.) 1.3 Background The Naval Air Systems Command (NAVAIR) OTPS Acquisition

and Sustainment Process is published by the Aviation Support Equipment Program Office (PMA260), which has the responsibility to manage the processes for acquisition and life cycle support of both common support equipment (CSE) and peculiar support equipment (PSE), including Automatic Test Systems (ATS) and OTPSs. OPNAVINST 3960.16B requires that NAVAIR programs comply with the Department of Defense (DoD) ATS acquisition strategies and to address Navy and aviation Marine Corps requirements for off-system automatic testing of electronics systems with the CASS FoT, the Navys standard family of Automatic Test Equipment (ATE) managed by PMA260. NAVAIR programs must ensure new design ATE is not acquired if the requirement can be satisfied by the CASS FoT. Per OPNAVINST 396016B, exceptions to the use of the CASS FoT require a waiver using NAVAIR Form 13630/1, which must be approved by the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN(RD&A)). Waivers must

be routed to ASN(RD&A) via the DoD ATS Executive Directorate, located in the Aviation Support Equipment Program Office (PMA 260). The 2016 DoD ATS Selection Process, Revision A, dated 15 June 2016 provides the processes and tools for conducting a Cost Benefit Analysis when considering ATE outside of the CASS FoT. 1-1 NAVAIR SOP 13630.5 PMA260 also has the responsibility to develop and maintain a generic test program set (TPS) procurement package for use by the NAVAIR program managers (PM), as well as by the Naval Sea Systems Command (NAVSEA) and the Space and Naval Warfare Systems Command (SPAWAR). PMA260 also assesses planned TPS acquisitions for compliance with CASS strategies, and budgets for and acquires new TPSs that are used for offloading and retiring legacy CSE automatic test equipment (ATE). NAVAIRINST 13630.5A, “Optimizing Weapon System Avionics Support Using Automatic Test Systems,” establishes policy, assigns responsibilities, and provides procedures for

optimizing the use of CASS and associated TPSs by the Naval Aviation Systems Team. PMA260 has responsibility for leadership across all areas related to aviation support equipment (SE) processes, including providing the weapon system PM with an initial assessment of the weapon system program OTPS acquisitions prior to proposal initiation and again prior to fielding, and authorizing OTPSs to be used on the CASS FoT. In summary, PMA260 budgets for and manages the acquisition of all CSE (e.g, CASS) and OTPSs being offloaded either from legacy intermediate-level (I-level) or depot-level (D-level) ATE in accordance with the defined program of record. Life cycle support and sustainment of CSE, including CASS, is the responsibility of PMA260. Conversely the aircraft platform weapon system PMs budget for and manage the acquisition of OTPSs that are new or peculiar to their aircraft platform, which is not currently supported by any I-level or D-level ATE. The aircraft platform weapon system PMs

also fund and manage sustainment of OTPSs that have been “off loaded” from legacy ATE by PMA260 and subsequently transferred to the aircraft platform program office for ownership and management. Life cycle support and sustainment of PSE, which includes weapon system OTPSs, is the responsibility of the weapon system program that has cognizance over the PSE. 1.4 CASS Family Acquisition and Sustainment Overarching Integrated Product Team (OIPT) and Working Integrated Product Team (WIPT) Exceptions to the use of the CASS FoT require a waiver using NAVAIR Form 13630/1, which must be approved by the Assistant Secretary of the Navy for Research, Development, and Acquisition (ASN(RD&A)). Waivers must be routed to ASN(RD&A) via the DoD ATS Executive Directorate, located in the Aviation Support Equipment Program Office (PMA 260). Waivers are reviewed by the Overarching Integrated Product Team (OIPT). The OIPT is chaired by the PMA260 product support manager (PSM). The OIPT chair

directly interfaces with the weapon system PSMs, their designated representatives, and other organizations concerning their respective OTPSs. The primary objective of the OIPT chair is to engage appropriate leadership to assist with problem resolutions and priorities to aid the WIPT. The OIPT is also supported with advisers from PMA260 program management, engineering and logistics areas that are knowledgeable on CASS FoT ATS matters. The OIPT advisers will solicit inputs from other competencies and Subject Matter Experts (SMEs) as required to address and resolve specific issues. The OIPT is supported by a functional level group, referred to as the WIPT, which acts as the execution level team for the OIPT. The WIPT lead primarily provides guidance to the weapon system PMA representatives, especially regarding proposed ATE enhancements, identified deficiencies, change requests, and 2-3 NAVAIR SOP 13630.5 their resolution. The WIPT lead manages the ATS master schedule and provides

assistance in the coordination and prioritization of software releases across the WIPT. The WIPT lead is supported by SMEs who have extensive knowledge about ATE capabilities, OTPS development, test strategies, etc., and is the facilitator for tasking SMEs in support of the OIPT The WIPT membership consists of weapon system PMA OTPS acquisition and sustainment SMEs and Automatic Test System (ATS) Fleet Support Teams (FST) members. The WIPT members communicate issues, share data with the OIPT, and assist in problem resolutions and ATE enhancements. Tasking to the WIPT may come from multiple sources: Direct from the OIPT, Failure Review Board action items, and from the PMA(s). The WIPT lead coordinates and prioritizes all tasking requests based on weapon system PMA cost and schedule requirements. The WIPT convenes meetings when required to address specific issues or tasking. All meetings include the required stakeholders and include a clear purpose and agenda. CHAPTER 2 FIGURE 1 –

CASS FAMILY ACQUISITION AND SUSTAINMENT OIPT AND WIPT - THE OTPS ACQUISITION PROCESS 2-4 NAVAIR SOP 13630.5 2.1 Introduction to OTPS Acquisition Once the need for an OTPS has been established, the weapon system PM follows the appropriate DoD and NAVAIR policies for acquisition of the OTPS. The NAVAIR Acquisition Guide provides a quick reference and overview of the major internal NAVAIR acquisition processes. NAVAIRINST 13630.5A establishes policy and identifies PMA260 and weapons systems PM responsibilities relative to the acquisition and sustainment of both ATE and OTPSs. See paragraphs 4.4 and 45 of this document for descriptions of ATE and OTPSs, respectively PMA260 developed a procurement Request for Proposal (RFP) for OTPS acquisition titled the NAVAIR Generic OTPS Request for Proposal (NGOR). See paragraph 226 of this document for a description of the NGOR. The CASS Implementation Plan (CIP) is a database used by PMA260 and weapon system PMs to determine initial OTPS site

outfitting requirements. Data is entered into the CIP via CIP datasheets which are unique for each OTPS acquisition. See paragraph 48 of this document for a description of the CIP. 2.2 Acquisition Planning This paragraph and its subparagraphs provide information peculiar to OTPS acquisition to assist weapon system PMs in OTPS acquisition planning. 2.21 Cost Estimating OTPS acquisition cost estimates include: • • • • Funding OTPS-acquisition integrated product team (IPT) members, Fleet Support Team (FST) members, and all test team member’s participation. Obtaining and preparing copies of government furnished information (GFI), which consists of the unit under test (UUT) and ATE data. Obtaining and maintaining government furnished equipment (GFE), which typically includes UUTs, ATE, and ancillary items. Note – Based upon availability of GFE, PMA260 provides ATE station(s) and any required ancillary items for use during OTPS development; however, programs pay the

associated installation costs and annual station maintenance contracts. Obtaining cost analysis data to support Program Life Cycle Cost (PLCCE) estimates. The NAVAIR Cost Department is used to provide cost estimates, alternatively, PM’s estimates or similar techniques may be used. 2-5 NAVAIR SOP 13630.5 2.22 Contract Strategy Table 1 lists some top-level generalized factors based upon UUT design, GFE, and GFI to consider when determining the best contract strategy for the acquisition. It is recommended that appropriate contracts representatives be engaged to aid in assessing other factors and risks tailored to the specific procurement to devise the optimum approach. Table 1 - Factors Influencing Contract Strategy Factors Contracting Strategies UUT Design UUT Data Availability UUT Availability ATE Availability Full and Open Competion Mature Yes- available as GFI GFE GFE GFE GFE Limited Competition Stable Sole Source (industry/government) Stable Yes, but not

available as GFI; at least two contractors have knowledge of UUTs (e.g, UUT manufacturer and weapon systems integrator) Yes, but not available as GFI Government Development Stable Limited data available 2.23 GFE GFE Government Government Determining Site Requirements and Quantities Per Site The Weapons Systems Planning Document is used to baseline the requirement for support of the weapon system and to determine site requirements. CASS OTPS workload calculations should be performed utilizing the workload tool in the CASS Implementation Plan database and will aid in determining quantities of an OTPS per site to meet weapon system repair throughput. Major contributors influencing unique site requirements include: TPS runtime, TPS setup time, mean time between failure (MTBF) of the weapon systems supported by the OTPS and number of aircraft supported at each site. Final OTPS production quantities cannot and should not be determined until formal test completion and accurate data

for those major contributors stated above, which are used in OTPS workload calculations. Therefore, if a separate OTPS production contract is not used after the formal development test, the OTPS statement of work (SOW) should include a range vice a specific quantity of OTPSs. Other site requirements should include the FST for organic support of the OTPS H/W and S/W, and Organic Depot if required. PMA260 will provide assistance in calculating the number of OTPSs per site. 2-6 NAVAIR SOP 13630.5 2.24 Production Contract Considerations The procuring activity finalizes the production strategy to be implemented while considering the quantities to put on contract as well as what contracting options are available. When determining the production contract line item number (CLIN) quantities, if specific requirements regarding total production units needed are not finalized, consider having a range for OTPS production quantities or having multiple options for procurement of additional OTPSs

production units to address uncertainties in projected UUT reliability, TPS run times, and evolving site outfitting requirements. Procurement of OTPS spares and Interim Support Item List units require a different source of funding than that used for OTPS production procurement. In some cases, including the OTPS spares as an option in the production contract should be considered to potentially leverage efforts and minimize costs. Likewise, foreign military sales (FMS) needs should be considered and an FMS OTPS option should be included if there is a possible requirement. Production units may be procured via: • • • An option on the development contract; A separate contract after the final data package has been delivered to the Government; or Manufacture by a Government activity. Each of these approaches has advantages and disadvantages depending on the schedule, quantity, and complexity of the OTPS. 2.25 OTPS Acquisition Risks OTPS acquisition has both weapon system PM peculiar

risks and PMA260 risks concerning GFE and GFI, including availability and status of GFE, funding for support of GFE CASS stations and accuracy of UUT data. PMA260 works with the weapon system PM, as well as contracts representatives to understand these risks and develop mitigation strategies. PMA260 CASS FoT related risks are managed per the PMA260 Risk and Opportunity Standard Operating Procedure. 2.26 Request for Proposal (RFP) Preparation The NGOR is a generic RFP template that PMA260 and weapon system PMs use for OTPS development and acquisition contracts that may be awarded to commercial contractors or for acquiring via in-house, organic Government teams. Available at https://pma260navairnavymil, the NGOR procurement package applies to both commercial contracts and Government efforts, and contains the following elements: 1. Language for contract Sections B through M 2. Attachments: (1) SOW for TPS/OTPS Development; (2) OTPS/TPS System Performance Specification Addendum; (3)

General Acceptance Test Procedure (GATP) for TPS/OTPS; (4) Technical Data Package (TDP) Contract Requirements; (5) Technical Manual Contract Requirements; 2-7 NAVAIR SOP 13630.5 (6) Provisioning Statement of Work; (7) Addressee List; (8) Distribution Statements; (9) DD Form 254 (Contract Security Classification Specification); (10) UUT for use with CASS; and (11) Storage Case Drawings (primarily Marine Corps applications) 3. Contracts Data Requirements Lists (CDRL) 2.27 Pre-procurement Assessment of OTPS Procurement Plan Prior to the initiation of an OTPS acquisition, a meeting is conducted between the weapon system PM or their designated representative(s) and PMA260. The focus of this meeting is a pre-procurement assessment of the OTPS procurement strategy, the following OTPS-related topics: • • Points of contact; weapon system PM IPT structure. Compatibility with CASS and ability of CASS to satisfy weapon system testing requirements as determined through engineering

analysis. The compatibility determination is made via: ¤ ¤ • • Cybersecurity requirements Contracting strategy: ¤ ¤ • Use of CASS System Synthesis Model Plus, a model which compares avionics test requirements to ATE test capabilities to determine support solutions, or Equivalent analysis resulting in determinations of incompatibility can be resolved with the issuing of a waiver for procurement of an OTPS using ATE other than CASS. Requirements for PMA260 CASS FoTs and ancillaries, data, schedule and CASS FoT OTPS Development Tools to be provided by PMA260 GFE and GFI requirements UUT information: ¤ ¤ ¤ Part numbers (P/N) Nomenclatures Identification of weapons replaceable assemblies (WRA) and shop replaceable assemblies (SRA) to be tested ¤ ¤ • • • • Preliminary MTBF data for each UUT Special power, cooling, or other infrastructure interface requirements needed above what is listed in the CASS Facilities Requirements Document Preliminary fielding sites

and quantities of required OTPSs, CASS FoTs, and ancillaries Schedule with the program, systems engineering, and logistics events identified CIP datasheet initiation. Assignment of OTPS program name Draft RFP: ¤ Identify the revision dates of the NGOR used to prepare the RFP ¤ Identify all tailoring changes or modifications to the NGOR for the planned OTPS acquisition 2-8 NAVAIR SOP 13630.5 2.3 Managing Requests for Variance (RFV) During the Contract To provide early insight into potential CASS FoT impacts, PMA260 OIPT advisors, and the WIPT are “copy-to” addressees for all Request for Variance (RFV). 2.4 Reporting CASS FoT Discrepancies Discovered During the Contract OTPS acquisition teams may identify and submit either CASS FoT related deficiencies or proposed enhancements or both via the ATS Source Data Repository (ASDR) problem reporting process. This process currently involves submission of a CASS FoT Change Request (CCR), previously known as a CASS or RTCASS System

Enhancement Request (SER) or System Problem Report (SPR). CCRs may be submitted via an email to cass ssa@navymil or by using ASDR problem reporting processes. Table 2 contains the CCR data requirements Gaps between CASS FoT capabilities and emerging UUT requirements should be documented as a potential CASS FoT enhancement with a CCR. Final resolution of those gaps may require several options such as building capabilities into the OTPS, changing CASS system software, designing new CASS ancillary equipment, using existing CASS hardware via engineering change proposals (ECP), or a mixture of these. Table 2 - CCR Data Requirements Problem Title Problem Description Required Originator Data Point of Contact for Technical Details Phone No. Date Originated Reference No. Optional Data Software Part No. 2-9 NAVAIR SOP 13630.5 2.5 Products 2.51 Product List The OTPS development process provides OTPS products for the end-users as well as OTPS products and data required for OTPS sustainment.

The delivery requirements for data prepared by the OTPS Developer are specified on the appropriate NGOR CDRL. Standard I-level OTPS development products and data are listed in Table 3 This list may be tailored per specific contract or NGOR package. Product List Prepared by OTPS Prepared by Government Fleet delivery Sustaining CIs and data Reference data Table 3 - OTPS Development Products and Data X Operational Test Program Instructions (OTPI) X XX X Master Test Program Set Index (MTPSI) files X O OTPS Hardware and T Software Operational Test Program Hardware (OTPH) Operational Test Program Media (OTPM) X X X XX X X X Descriptions and Comments (Note: For new OTPSs, all products except for Support Equipment Recommendation Data (SERD), OTPH and CIP data is resident in ASDR. See paragraph 49 for a description of ASDR.) Includes Interface Device (ID), Test Fixtures, Holding Fixtures, Cables, etc. Compact Disc (CD) or Digital Versatile Disc (DVD) containing OTPS executable

code. Pulled from ASDR and merged by Government onto common CASS, RTCASS, and/or eCASS TPS software DVDs as required. The common TPS DVDs are reproduced and distributed by Government. Portable document format (PDF) files. For eCASS and RTCASS, included in OTPM. For CASS, separate disc than OTPM. Merged by Government onto common test set DVDs, which are reproduced and distributed by Government. MTPSI source / distributed data (e.g, *.tpsi) files. Included in OTPM, OTPI discs, or both if applicable. 2-10 OTPH Technical Manual (TM) User Logistic Support Summary (ULSS) X X X X X X NAVAIR SOP 13630.5 When applicable, fleet version on CD in PDF format; distributed via Naval Air Technical Data and Engineering Services Command (NATEC) website and Automatic Data Requirements List (ADRL). Unable to deliver when supported by Interactive Electronic Technical Manual. In PDF. 2-11 OTPS Data (continued) Product List Prepared by OTPS Prepared by Government Fleet delivery Sustaining CIs

and data Reference data NAVAIR SOP 13630.5 Descriptions and Comments (Note: For new OTPSs, all products except for SERD, OTPH and CIP data is resident in ASDR. See paragraph 49 for a description of ASDR.) TDP X X Includes source data and copy of Joint Engineering Data Management Information and Control System (JEDMICS) files, if applicable. OTPS Software Source Data X X Includes build files and procedures, any unique software tools, etc. The same set of TPS software source code is used to create all CASS Family TPS executable code. See figure 8 OTPI Source Data OTPH TM Source Data ULSS Source Data System Specification X X X X X X X Developed per MIL-STD-3001 or S1000D Stored on PMA260 website If required per contract Interface Control Document (ICD) Software Requirements Specification (SRS) Software Detail Design (SDD) Interface Control Specification (ICS) Interface Detail Design (IDD) X X If required per contract X X If required per contract X X X X If required

per contract If required per contract X X If required per contract Subsystem Detail Design (SSDD) Logistics Management Information (LMI) Data Maintenance Plan (MP) X X If required per contract X X Source of Logistics deliverables X X X CIP Data SERDs X Interim Support Items List X Government Test Reports Pilot Production Acceptance Test Report X X X X Resident in CIP database Resident in Support Equipment Management System (SEMS) database X If required per contract X X X From all test events X X From developmental tests 2-12 NAVAIR SOP 13630.5 Fleet Introduction (FI) Report X RFVs or Problem Identification Reports (PIR) X X X From initial operational capability (IOC) fielding events X X 2.52 Establishing Initial Baselines ASDR is used to store OTPS data deliverables and aid in establishing the various S/W baselines during the development phases. TPS source code developed under contract is delivered via CDRLs to the Government for audit and test purposes.

Copies sent on media to ASDR are stored in the ASDR media library for archival. The ASDR team uploads unclassified TPS source code into the "CDRL Delivery" team project in the ASDR Software Lifecycle Management (SLM) tool to be used for various purposes. If any OTPS data changes are needed to resolve problems found during testing, a final CDRL delivery is eventually made to the Government. Upon acceptance, the final CDRL delivery becomes the Governments initial baseline. Copies sent on media to ASDR are stored in the ASDR media library. Upon notification that a CDRL delivery for TPS source code was approved, the ASDR team supersedes any TPS source code previously uploaded into the ASDR SLM tool with the final version. Upon acceptance of sustainment responsibilities for an OTPS, the applicable FST populates its ASDR SLM team project with all pertinent OTPS data. 2.6 Testing 2.61 OTPS Developmental Testing The process and responsibilities for testing OTPS deliverables is

defined in NAVAIR Instruction 13600.3 and “Test and Evaluation Policy for Aviation Support Equipment”, NAVAIR M-13600.3 Testing of OTPS deliverables, aviation Support Equipment (SE), during development is comprised of both Verification and Validation. Verification is accomplished by means of performing specification compliance tests. Validation of the operational mission effectiveness and safety is accomplished by conducting a government Test and Evaluation (T&E) program. Specification Compliance tests are performed to ensure the OTPS contractual end items performance requirements are being met. The government T&E program is conducted to validate the OTPS end items are operationally effective, suitable and safe in its intended environment. Test criteria, performance parameters, and the overall testing framework is documented in the TEMP or equivalent document. The TEMP and system specification requirements are used to produce the development SOW and, along with the NGOR

GATP, establish the CDRL “DEVELOPMENTAL TEST PROCESS”. Included in the “DEVELOPMENTAL TEST PROCESS” CDRL is the Specification Requirements Test Verification Matrix. Separate Production Acceptance Testing, if required, is conducted on production units after the closeout of the development phase. 2-13 NAVAIR SOP 13630.5 2.611 Specification Compliance Tests Specification Compliance Tests commence upon successful completion of developer integration activities. Specification Compliance Tests involve various methods, as described in the “DEVELOPMENTAL TEST PROCESS” CDRL, to determine contract requirements compliance including active on-station testing and demonstration as well as analysis and examination. The developer, the Government IPT, or a combination of these representatives typically perform Specification Compliance Tests. This is normally performed at the developers facility utilizing ATE stations provided by PMA 260, test WRAs and SRAs provided by the PMA, and

pilot-production hardware developed by the developer. Verifying key performance parameters and technical specifications of the OTPS deliverables consumes a majority of the time and resources dedicated to Specification Compliance Tests. Demonstration of performance parameters such as the ability of the OTPS to correctly detect and isolate WRA, SRA, and OTPH faults down to the correct component occurs. Transportability demonstration of faults across multiple UUTs and UUT faults across multiple ATE stations also occurs. Government IPT monitoring, control, and reporting is essential for program success. The developer spends a significant amount of time and resources performing and documenting the Specification Compliance Test phase. Successfully meeting contract cost, schedule and performance requirements requires coordinated IPT monitoring, control, and reporting during Specification Compliance Tests. Reporting is a critical part of Specification Compliance Tests. Deficiencies found

during Specification Compliance Tests are reported via CDRL “PROBLEM IDENTIFICATION REPORTS”. Results of Specification Compliance Tests, including the completed analysis in the Specification Requirements Test Verification Matrix are reported via CDRL “TPS/OTPS ACCEPTANCE TEST REPORT (ATR)”. 2.612 Government T&E Program Independent Government Testing is performed by the Government test team and evaluates operationally effectiveness, suitability, safety, and supportability of the OTPS deliverables in their intended environment. Operationally effectiveness, suitability, safety, and supportability requirements are typically defined in the Program Designation Letter, Acquisition Program Baseline Agreement, TEMP, or equivalent required program documents. Requirements to establish a test team will generally originate with a program sponsor’s assistant PM for test and evaluation. The Government test team is comprised of personnel from the NAWCAD Support Equipment Test and

Evaluation (SE T&E) Branch and fleet personnel. Test team members from other competencies and other Government agencies may play a role depending on the nature of the specific test program. The SE T&E test team develops an SE or Government test plan, executes the test plan, and produces a test report. The Government test plan and subsequent test report are critical elements of the acquisition process. Government test plans are drafted by the assigned SE test team and reviewed using a tiered review process to ensure the Government test plan is 2-14 NAVAIR SOP 13630.5 responsive to the customer. Tiered review also provides a mechanism to ensure adequate test planning, preparation, and coordination have been accomplished. After approval, the test plan is the governing document used by the SE T&E test team to conduct testing. The SE T&E test team utilizes the Government test plan to schedule and execute the test event. SE acquisition programs, Acquisition Category IVM or

Abbreviated Acquisition Programs, generally do not require formal Operational Test and Evaluation conducted by the Commander, Operational Test and Evaluation Force; therefore, the assigned SE T&E test team executes this Independent Government Testing event. The final phase of the Independent Government Testing is the fleet evaluation (FLEETEVAL). FLEETEVAL of the OTPS in its intended operational environment utilizing fleet operators allows for the introduction of the OTPS deliverables to the end user; allows for the validation of the mission performance; allows for the evaluation of the OTPS’s maintenance, training, and supportability elements; and allows for critical end user feedback prior to program completion. The FLEETEVAL is coordinated with the OTPS program sponsor; Commander, Naval Air Forces (COMNAVAIRFOR); and participating fleet activities. The results of the FLEETEVAL are provided to the program sponsor in the final test report phase. Deficiencies identified during

Independent Government Testing are identified in the test report and can be reported in a separate Deficiency Report (DR), depending on the needs of the program sponsor. The DR is a stand-alone document for reporting mission-related issues identified during testing. The DR is specifically designed to provide program management with sufficient understanding of technical issues to facilitate an appropriate corrective action plan. DRs document technical issues and risks as near real-time as possible, assisting sponsors and other acquisition executives in understanding, assessing, and mitigating overall program concerns. DRs serve as formal documentation of test deficiencies, which are then enclosed in the final test report. DRs may be created during Government test periods, integrated government and contractor testing, or during government observation of contractor verification tests. Initiation of a DR occurs when a deficiency is identified in design, material, construction, data (e.g,

OTPI), or software that results in a malfunction, failure, or unsatisfactory performance of the TPS for its intended mission or safety. A deficiency may include a failure of either the system to meet specification or TEMP requirements or contract guarantees or a combination of these. Mission or safety-related deficiencies do not have to be linked to a specification, TEMP, or contract requirement. All technical issues identified do not necessarily result in a DR, as they may be corrected prior to the end of the test phase or other program milestone. However, critical technical issues should be documented as soon as possible. A signed DR is a stand-alone, formal document that presents a clear picture of the deficiency, the consequences, and identifies the mission impact if not resolved. The results of the Government test should be quickly and accurately reported in the final test report. Expedient reporting is necessary so that proper action can be taken by IPT leaders if deficiencies

are identified. The report includes the actual results of Government testing, identification of deficiencies, and provides conclusions and recommendations to the milestone decision authority (MDA) and the program’s sponsor. The formal Government test report is published within 60 days after completion of testing. 2-15 NAVAIR SOP 13630.5 2.62 OTPS Production Acceptance Testing OTPS hardware production acceptance testing is required if OTPS production is contracted with industry. The GATP describes production OTPS testing If any production units fail, the cause of the failure is to be investigated and corrected. Results of production acceptance testing are typically reported via CDRL “PRODUCTION STATUS REPORT.” 2.7 Authorization for Fielding Following successful completion of all test events and resolution of all Part I DRs, perform an IOC supportability assessment prior to OTPS fielding. 2.71 PMA260 OTPS Offload Programs For PMA260 OTPS offload programs, an IOC

Supportability Review (IOCSR) is chaired and approved by the PSM. The OIPT advisors participate in the IOCSR The PMA provides the final authorization for fielding based upon the successful completion of testing and resolution of: 1. All Part I DRs; 2. The approved IOCSR; and 3. Any other programmatic considerations that the PMA may have 2.72 Direct to CASS (DTC) OTPS Programs For all Direct-to-CASS (DTC) Operational Test Program Set (OTPS) programs, an Independent Logistics Supportability Readiness Assessment (ILSRA) shall be chaired by the NAWCAD Lakehurst Support Equipment Department Sustainment Lead or their designated representative to assess the adequacy of the logistics support being delivered with the OTPS. As a minimum ILSRA participants shall include the OTPS lead logistician, lead engineer and Support Equipment Project Officer (SEPO). PMA 260 CASS FoT logistics advisors and the appropriate Commander Naval Air Forces (CNAF) Type Commander (TYCOM) shall be invited to

participate in the ILSRA at their discretion. ILSRA findings and any deficiencies and associated recommended corrective actions shall be provided to the weapon system Product Support Manager (PSM) or appropriate Assistant Program Manager, Logistics (APML) within the weapon system program office. Final authorization for OTPS fielding shall be provided by the owning PMA PSM or as delegated to the APML or SEPO and should be based upon the successful completion of requirements validation/verification, physical configuration audit, suitability and supportability testing, the resolution of all Part I Deficiency Reports, the resolution of any ILSRA deficiencies, the results of the supportability risk assessment, and any other programmatic considerations as determined by the PSM, APML and/or SEPO. 2.8 Initial Outfitting The OTPS PM coordinates the delivery of all CASS OTPS products to end-users as directed by the COMNAVAIRFOR SE CASS TPS Class Desk who determines fielding priorities. The

associated software and data may be produced, packaged, and shipped separately from the OTPH to the end-user. 2-16 NAVAIR SOP 13630.5 2.81 Fleet Introduction (FI) FI, which is described in the GATP, occurs if one or more fleet sites are chosen to participate in the initial fielding of the OTPS. Requirements for FI are determined by the program FI typically occurs at one or more fleet sites and is usually scheduled to begin at the first designated site no later than 60 days after acceptance of the first production hardware. FI is to be scheduled as agreed by the Navy and the OTPS developer. All site FIs are to be completed within a 12month period FI is performed by the OTPS developer with Government assistance and oversight. The OTPS developer duties include documenting the FI, providing the OTPS hardware and spares, providing knowledgeable personnel, and identifying required UUTs, and storage requirements. Government duties include providing and maintaining the ATE and UUTs,

providing an operator and supporting the storage and maintenance of the test hardware. Successful demonstration of the FI consists of OTPS installation per the OTPI and successful execution of the ID self-test(s) and UUT performance tests. Every variant of each UUT, whether ready for issue (RFI) or non-RFI, are to be demonstrated via end-to-end program execution across the ATE during the FI, if possible. A certificate of completion form is completed and signed by on-site Government and fleet personnel at the conclusion of each successful FI. Results of FI are typically reported via CDRL “OTPS FLEET INTRODUCTION REPORT”. 2.82 Fleet Delivery Following successful FI, formal fleet deliveries commence using the latest versions of OTPS components and data are delivered to the end-users as follows: • OTPH – Delivered as directed by the weapon system PM and COMNAVAIRFOR. The Support Equipment Resources Management Information System (SERMIS) process is used to log and track all OTPH

deliveries. • OTPM o Normally, per PMA260 direction, the OTPS software is merged into the common TPS DVDs; P/Ns CASS-TPS-xxx (for CASS), RT-TPS-xxx (for RTCASS), and eCASS-TPS-xxx (for eCASS). These common DVDs, which contain all I-level test set TPS software, are reproduced and delivered to fleet sites as unlimited releases. PMA260 directs "limited" releases of the common TPS DVDs to specific sites as required. Alternately, per weapon system PM direction, PM representatives may build, reproduce, and deliver temporary OTPMs for OTPS IOC events. This software is distributed by PMA260 on the next unlimited fleet release of the common TPS DVDs. • OTPI o CASS 2-17   NAVAIR SOP 13630.5 Normally, per PMA260 direction, the OTPI is merged into common CASS Test Program Instructions (TPI) DVD, P/N CASS-TPI-xxx; then reproduced and delivered with the common CASS TPS DVD, P/N CASS-TPS-xxx, as described above. Alternately, per weapon system PM direction, PM

representatives may create, reproduce, and deliver a temporary OTPI disk as part of an OTPS IOC. This OTPI is distributed on the next unlimited Fleet release of the common CASS TPI DVD, similar to the common CASS TPS DVD described above. o RTCASS and eCASS  Normally, per PMA260 direction, merged into the common TPS DVDs and delivered as described above.  • Alternately, per weapon system PM direction, PM representatives may include the OTPI on a temporary OTPM as part of an OTPS IOC. This OTPI is distributed on the next unlimited fleet releases of the common TPS DVDs as described above. MTPSI 2-18 NAVAIR SOP 13630.5 o Normally, merged into the common TP o I DVDs, which contain all MTPSI data, and delivered as described above. o Alternately, PM representatives may create, reproduce, and deliver the MTPSI as part of an OTPS IOC. This MTPSI data is distributed on the next fleet release of the common TPI DVD(s). • TM – The TM PDF file, if applicable is posted to the

NATEC website (https://mynatec.navairnavymil) where the fleet can download it The TM on a CD can accompany OTPS deliveries as long as it is already posted on the website • ULSS – The ULSS is created, approved and posted to the PMA260 website. A hard copy may accompany the OTPH delivery • Supplemental data – Any supplemental OTPS software and documentation (e.g, supplemental OTPI), including classified data, is distributed by weapon system PM representatives. Any related Operational Flight Programs (OFP), which may be considered OTPS supplemental data, is distributed by weapon system PM representatives. 2.83 OTPS Distribution When directed by the weapon system PM, PM representatives may distribute OTPM, OTPIs, and MTPSI data for CASS, RTCASS, or eCASS OTPS IOC events per the following sequential process: a. MDA declares IOC b. PM representatives: (1) Accept OTPS CIs from the developer. (2) Upload sustaining CIs and Data (see Table 3) into ASDR. (3) Build, test, and

reproduce one or more distributable interim release disks (containing TPS software, OTPIs, MTPSI data) for OTPS IOC events. (4) Inscribe unique P/Ns on interim release disk labels. The common convention for the temporary P/Ns is: • • C-TPSaaa-bb-xxx (for CASS OTPS software media). C-TPIaaa-bb-xxx (for CASS OTPI media). • E-TPSaaa-bb-xxx (for eCASS media). • R-TPSaaa-bb-xxx (for RTCASS media). 2-19 NAVAIR SOP 13630.5 Where: “aaa” – represents the weapon system PM’s numerical identifier (e.g, “209” for PMA209). “bb” – represents a two-character-long integer (with a leading zero, if necessary), unique for each OTPS. Typically, this number is “01” for each PM’s first OTPS software release identified using this methodology and is incremented by one for every new release. If more than 99 releases are assigned temporary P/Ns, then the dash (“- “) preceding “bb” can be replaced by a third integer, allowing “100”, etc. to be used “xxx” –

represents the disk’s version number, a three-character-long integer (with leading zeroes, when applicable). Ideally, this number is “001” for the first version of each disk and will never be incremented. However, a weapon system PM that has an established convention for these software P/Ns can temporarily continue to use that convention until their local processes are updated to use the common convention. (5) Release IOC naval message. (6) Distribute IOC OTPS disk(s) to IOC sites. c. PMA260 representatives: (1) Merge new OTPM, OTPI, and MTPSI data into common TPS/TPI disks. (2) Release updated common TPS/TPI disks via technical directives (TD), which indicate disposal of any interim release OTPS disk(s) explicitly identified by (temporary) P/N(s). 2-20 NAVAIR SOP 13630.5 CHAPTER 3 THE OTPS SUSTAINMENT PROCESS 3.1 Introduction to OTPS Sustainment Sustainment involves the supportability of fielded OTPSs during the Operations and Support phase of the DoD 5000 acquisition

lifecycle model. Sustainment begins when any portion of the low rate initial production or full-rate production quantities have been fielded for operational use. Per SECNAVINST 5400.15C, weapon system PMs establish IPTs to execute their responsibilities, including in-service support. Per DoDI 5000.02, lifecycle sustainment considerations include initial provisioning; supply; maintenance; transportation; sustaining engineering; data management; configuration management (CM); environment, safety, and occupational health; inventory management; supportability; and interoperability. 3.2 OTPS Sustainment To maintain authorization to use an OTPS on the CASS FoT, the sustainment processes in this document are followed by the cognizant weapon system PM and its representatives. 3.21 OTPS Sustainment Accountabilities The cognizant PM is accountable for sustainment of OTPS products and data. Weapon system PMs are accountable for their respective PSE OTPS CIs. PM representatives sustainment

duties include: a. Maintaining OTPS CIs per the processes documented herein and the following documents, which are available on the PMA260 website: b. c. d. e. • CASS User’s Guide for TPS Developers • CASS Station Interface and General Purpose Interface (GPI) Pin-Out Data • Prime Item Development Specification (PIDS) for the CASS Test Station • RTCASS Requirements Verification Traceability Matrix (RVTM) • NGOR • PMA260 CM Plan for Aviation Support Equipment • ASDR SLM Users Guide • CASS TPS Advisories Reporting any problems with the CIs listed in Appendix C using ASDR problem reporting processes per paragraph 3.2103 of this document Reporting any OTPS problems per paragraph 3.2103 of this document Ensuring the respective data within ASDR is current with or more advanced than the latest fleet release. Making changes to ASDR with all relevant supporting data about each OTPS change. This includes: 3-1 NAVAIR SOP 13630.5 • • A CASS OTPS Change Description

Document (CDD) illustrated in Figure 2; A copy of all affected source data including an updated MTPSI *.tpsi file and any build files and procedures; • Updated header information in the main TPS program that provides appropriate revision information; • Updated comments field near the affected code change that describes the code change rationale per best software CM practices; and • A copy of electronically captured test results from CASS FoTs that demonstrate the code changes were successfully implemented without negative consequences. Note: Weapon systems PM representatives follow approved OPSEC procedures to ensure ASDR is not loaded with classified or malicious data. f. Ensuring the respective data within the CIP is current and accurate; communicate any needed changes to PMA260 CIP manager. The CASS Family Acquisition and Sustainment OIPT should be used to ensure CIP updates occur as the systems are being updated. It is expected the CIP updates by the PMA representatives occur

in real time, as needed, and not later than quarterly. g. Working with PMA260 representatives to identify and maintain all peculiar software tools used to sustain their respective OTPS CIs. h. Establishing depot rework capability per NAVAIRINST 136801D, “DEPOT LEVEL REWORK PROGRAM FOR SUPPORT EQUIPMENT END ITEMS” for OTPH, if required. i. Managing and delivering the following items, including those that are classified, using existing OPSEC processes: • All OTPS supplemental software and documentation; and • Any related OFPs, which may be considered OTPS supplemental data. PMA260 is accountable for sustainment of CSE OTPS CIs, ASDR, Common ATE hardware, software that includes system software, support software, maintenance software, documentation, and related data. Upd Del Affected Configuration Items New ASDR Team Project: DESCRIPTION OF CHANGE SCP/SSC No: OTPS Nom: OTPS P/N: TPSLib Updates: New OTPS/TPS(s): New TWP(s): Deletion of Obsolete OTPS Data: OTPILib Updates:

OTPS Update: MTPSILib Updates: 3-22 NAVAIR SOP 13630.5 Superseded OTPS TWP(s), media, and/or SSC(s): Other related TD(s): N/A Figure 2 – CASS OTPS CDD 3.22 Configuration Identification 3.221 CI Table 3 identifies the types of OTPS products and data that are sustained as CIs. The following are typical OTPS related CIs that are updated by the cognizant PMs representatives as needed to meet user end requirements: • • • • • • TPS software MTPSI/TPSI files OTPI ULSS OTPH TM OTPH The following are typical OTPS related CIs that are sustained by the cognizant PMs representatives, as needed, to help meet near and long-term weapon system or ATS program objectives: • TDP • TPS software source data • OTPI source data • OTPH TM source data • ULSS source data • SRS • SDD • ICS • IDD • SSDD • LMI data • MP • CIP Data • SERDs Historical archives (e.g, CDRL deliverables, Government documents, and reports) • Configuration Baselines 3-23 NAVAIR SOP

13630.5 Once an OTPS baseline is established in ASDR by the weapon system PM representatives, it is maintained to reflect the current approved and fielded fleet version, all working versions, and the approved updated fleet version pending issue. Weapon system PM representatives use ASDR as a tool for internal SLM workflow and routinely have OTPS data within ASDR that is beyond the latest fleet release that may be considered as an incremental baseline. All OTPS source data in ASDR is maintained on a file-by-file basis to ensure traceability of all changes. No classified data is to be stored in ASDR 3.23 OTPS Sustainment Requirements OTPS CIs are subject to their respective PMs program-peculiar guidance and requirements normally documented in a platform CM plan, none of which should conflict with the processes documented herein. In order to maintain authorization to use OTPSs on the CASS family, PM representatives sustain OTPS products and data per the processes documented herein and

the following documents: • • • • • • • CASS User’s Guide for TPS Developers; CASS Station Interface and GPI Pin-Out Data; PIDS for the CASS Test Station; RT CASS RVTM; NGOR; PMA260 CM Plan for Aviation Support Equipment; and ASDR SLM Users Guide. 3.24 OTPS Sustainment Tools Appendix C lists hardware, software, and documentation used to sustain CASS OTPSs. PMA260, through the CASS Family Acquisition and Sustainment OIPT, assists PM representatives in obtaining and maintaining the tools necessary for initial FST stand-up and sustainment of these tools. PM representatives obtain and maintain all peculiar hardware, such as Alpha support computers or emulators software, and documentation needed to sustain their respective OTPSs. 3.25 OTPS Change Processes 3.251 Decentralized Configuration Control Boards (CCB) All OTPS changes are processed per the weapon system PM CM Plan and approved via a NAVAIR chartered Decentralized Configuration Control Board (DCCB). In an effort

to streamline the SE change process, the CM/DM Sustainment Group chartered PMA260 as a DCCB authority for SE software changes which do not have any hardware impact. This designation is per NAVAIR 00-25-300, Section 2.3, and NAVAIR SOP 41301 Encl (3), Para 6. Weapon system PM representatives have the option of processing SE software-only changes via the PMA260 DCCB, the NAVAIR CCB or other authorized DCCBs. Any PSE OTPS software 3-24 NAVAIR SOP 13630.5 changes not processed via the PMA260 DCCB are routed to PMA260 for concurrence or information (to assess potential CSE impacts) as an associate member of the NAVAIR CCB per NAVAIR SOP 4130.1 Encl (3), Para 10 All other OTPS changes that affect hardware, require approval through the normal NAVAIR CCB or other designated configuration control authority. In the case where an OTPS software change is part of an overarching ECP that impacts hardware, the OTPS software change is addressed by the overarching ECP. The ECP is then routed for

concurrence or information to PMA260 as an associate member of the NAVAIR CCB per NAVAIR SOP 4130.1 Encl (3), Para 10. Regardless of the applicable CCB, all changes that affect OTPS software that is used in conjunction with the CASS family of ATE require PMA260 concurrence. 3.252 OTPH Changes Any proposed OTPS change that involves a change to the OTPH that affects form, fit, or function is documented and processed as a Class I ECP. These ECPs address all impacts to all affected OTPS CIs and are approved through the normal NAVAIR CCB or other approved change control authority. Only ECPs with corresponding changes to OTPS software are routed for concurrence or information to PMA260 as an associate member of the NAVAIR CCB per NAVAIR SOP 4130.1 Encl (3), Para 10 Approved OTPH changes are usually packaged as change kits and released via a support equipment change (SEC) per NAVAIR 00-25-300, Section 3.48 Corresponding CASS, RTCASS, and eCASS OTPS software updates will be part of the next

scheduled common TPS DVD releases distributed via a support software change (SSC) per NAVAIR 00-25-300, Section 3.419 Ensure TPS software updates associated with OTPH changes do not introduce incompatibility problems with currently fielded TPS media to avoid multiple variations of a common TPS DVD. For example, if a platform incrementally fields an updated version of OTPH while the older OTPH is still fielded, then the corresponding updated software either has to work with both versions of hardware or the updated software has to be named differently so both versions can exist on the same common TPS DVD. Per NAVAIR 00-25-300 Section 3.24 and 348, a rapid action minor engineering change (RAMEC) can be used to authorize and direct end-users to incorporate approved OTPH changes if those changes can be implemented by using either only materials commonly on-hand at each site or readily available through normal supply channels, or both, when applicable. RAMECs are SECs issued via naval

message. 3.253 OTPS Software Changes A proposed CASS OTPS software change that does not involve a hardware change is documented and processed as a Software ECP per the PM’s CM plan or a Software Change Proposal (SCP) per the PMA260 CM Plan for Aviation Support Equipment when using the PMA260 DCCB. These ECPs and SCPs address all impacts to all affected OTPS CIs Weapon system PM representatives have the option of processing software-only ECPs via NAVAIR chartered DCCB (platform or PMA260) but all PSE with a potential CSE impact are routed for 3-25 NAVAIR SOP 13630.5 concurrence or information to PMA260 as an associate member of the NAVAIR CCB per NAVAIR SOP 4130.1 Encl (3), Para 10 The PMA260 CM Plan for Aviation Support Equipment contains a copy of the SCP form and describes the SCP process. SCPs are submitted to the PMA260 DCCB for approval. An approved OTPS software-only change is released as an SSC per NAVAIR 00-25-300, Section 3.419 CASS, RTCASS, or eCASS-compatible TPS

software updates: • Include all corresponding OTPI and MTPSI files. • Are merged into the next applicable scheduled common TPS DVD release(s). • Are documented and approved by PMA260 via SCPs and packaged as SSC kits CASS, RTCASS, and eCASS TPS DVD fleet releases are planned on a quarterly basis or when warranted by weapon system PM direction. Information about each scheduled release, including its cut-off date for submission of updated TPSs, is formally disseminated to all stakeholders via PMA260 representatives. TPS software updates that do not meet the cut-off date for one scheduled release will normally be incorporated into the following release. Emergent requirements are communicated by the relevant PM representatives to PMA260 representatives. When required, a limited release of the common TPS DVDs (denoted by "Lx" appended to the end of the software P/N, where "x" represents an integer) may be issued by PMA260 with COMNAVAIRFOR concurrence to selected

sites on a case-by-case basis. All OTPS software changes shall comply applicable DoDI 8500.01, Cybersecurity and DoDI, 8501.01Risk Management Framework (RMF) software or application cyber security controls With regards to OFP supplements to OTPS CIs, it is highly recommended that the OTPM, OTPI, and MTPSI be written in generic terms so that each OFP update does not initiate an SCP or SSC change to the OTPS. Once the airborne software change has been released updating the OFP on aircraft system(s), a corresponding SSC should be issued against the OTPH. The purpose of the SSC is to provide the required classified supplemental disk(s) to affected fleet sites regardless of which CASS FoT members are used for diagnostic testing and repair of the aircraft WRA. 3.254 OTPS Documentation and Data File Changes Any proposed OTPS documentation or data file change related to a hardware change is addressed in the relevant Class I ECP. OTPI or data file (e.g TPSI) changes unrelated to a hardware

change are processed like OTPS software-only changes as described in paragraph 3.253 of this document Updates to the TDP should only result from a properly documented ECP. A proposed TDP change that does not involve a Class I ECP is documented and processed as a Class II ECP as directed by the cognizant PM’s CM Plan. Class II ECPs do not impact the OTPM or OTPI Proposed OTPH TM changes are documented, tracked, and processed by the applicable PM representative via Technical Manual Source Data Record. When a TM change is deemed to be urgent, the cognizant PM representative pushes an interim rapid action change (IRAC) or 3-26 NAVAIR SOP 13630.5 electronic rapid action change (eRAC) to the fleet, providing updated data in advance of the formal TM update. After all appropriate TM changes have been incorporated into the editable TM source data and a distributable version of the TM is made, the cognizant PM representative pushes the updated TM to NATEC for distribution and archiving.

3.255 Validation of Updated OTPS Products Validation of updated OTPS products is conducted to ensure suitability for fleet release. OTPS validation methods include analysis, test sampling, or full verification OTPS end-to-end or diagnostics testing or a combination of these. Although the duties of the WIPT member who introduced a particular OTPS change include its validation, the other affected WIPT members are notified and, when appropriate, are involved with validation efforts. Regression testing is coordinated through the WIPT and results are shared. Weapon system PM representatives validate their proposed OTPS software changes for all applicable ATE variations. Regardless of the origin of the OTPS changes, all validation efforts are coordinated through the WIPT to ensure a systems-level approach is taken and to avoid adverse impacts to software release schedules. All validation results are adequately documented and communicated to all affected WIPT functional stakeholders. All

required validations are performed prior to TD verification. 3.256 TD Verification TD verification is conducted per NAVAIR 00-25-300 Section 3.9 3.26 Distribution of Updated OTPS Products and Data 3.261 OTPS Components, Related End Items, and Data Updated OTPS components, related end items, and data are distributed as follows: (a) OTPH changes are distributed and incorporated via TD (e.g, SEC) at the direction of the cognizant PM. The incorporation of the TD is documented via a Maintenance Action Form and inputted to Decision Knowledge Programming for Logistics Analysis and Technical Evaluation (DECKPLATE) via Optimized-Organizational Maintenance Activity. DECKPLATE is used to track TD incorporation at the end-user site. (b) OTPM delivery – TPS executables are merged into a common TPS DVD, which contains all TPSs for each applicable FoT member, then reproduced and distributed quarterly by PMA260. (c) OTPI delivery – OTPIs are merged into a common TPI DVDs. (d) MTPSI data–

Embedded in common TPS DVDs. Separate delivery is not required Viewed or printed by end-users on-demand. (e) Supplemental software, documentation, and any related OFPs – Reproduced and distributed per direction of the cognizant PM. (f) TM deliveries may be completed using various methods. 1. Weapon system PM representative provides NATEC with the updated TM, if applicable. NATEC pushes the updated TM to fleet activities via the ADRL, loads a copy into Technical Manual Application System (TMAPS), and pushes a copy of the 3-27 NAVAIR SOP 13630.5 PDF file to its data repository for archival purposes. 2. Partial TM updates may be issued by the cognizant PM representative as IRACs until they are replaced by the next full TM release. IRACs are typically issued as naval messages per the NAVAIR 00-25-100, Naval Air Systems Command Technical Manual Program. Extensive IRACs or those with figures or illustrations are issued in hardcopy format. (g) ULSS are reproduced and distributed by the

cognizant PM representative. (h) TDP Drawings that include editable native source files and PDF images are updated and provided by the cognizant PM representative to ASDR and drawings are provided to JEDMICS as a PDF image per NAVAIRINST 5600.14E (i) TPS Software Source Data is maintained within ASDR. (j) MTPSI Source Data is maintained within ASDR. (k) OTPI Source Data is maintained within ASDR. (l) OTPH TM Source Data is optionally delivered to ASDR and is usually maintained by the platform Tech Data group. (m) ULSS Source Data is optionally maintained within ASDR. (n) SRS is optionally maintained within ASDR. (o) SDD is optionally maintained within ASDR. (p) ICS is optionally maintained within ASDR. (q) IDD is optionally maintained within ASDR. (r) SSDD is optionally maintained within ASDR. (s) LMI Data, in the form of Document Change Notices, is provided to the Naval Supply Systems Command and is optionally maintained within ASDR or the FSTs integrated logistics support repository.

(t) MP is optionally maintained within ASDR. (u) SERDs are optionally maintained within the SEMS database. 3.262 Types of Releases Updated OTPS products and data are typically released to all sites with earlier versions of those items. However, there are times when only a subset of the potentially affected sites is provided with copies of updated components. For example, a PM may direct a limited release of a common TPS DVD to one or a few selected fleet sites to meet high-priority requirements. Likewise, preliminary versions of software may be forwarded to one or more sites for engineering or test purposes. Although Figure 3 provides information about the various types of releases for CASS FoT system software, much of that information can also apply to OTPS products and data. 3-28 NAVAIR SOP 13630.5 Figure 3 – Types of Software Releases 3.263 Shipping Addresses for Fleet Sites All updated OTPS CIs sent to fleet sites should be addressed to Maintenance Material Control Officer,

Work Center 020 at fleet sites for inventory tracking purposes. 3.27 OTPM Update Process Summary The following is a summary of major steps taken by the WIPT to update OTPS software source code: a. Weapon system PM representatives: • • • • • Pull applicable TPS source data from ASDR. Make appropriate changes to source data. Generate updated CASS, RTCASS* and eCASS TPS executable code. Validate changes for CASS, RTCASS* and eCASS. Update ASDR as described in paragraph 3.222 of this document * - when applicable b. For common CASS, RTCASS, or eCASS TPS release: (1) Weapon system PM representatives: • Stage TPSs to be released from the established baseline into the appropriate xFLEET DELIVERABLE directory in ASDR using automated methods whenever possible (e.g batch files) to ensure accuracy and completeness • Complete a CDD and store in ASDR. (2) PMA260 representatives: • Assemble files from each weapon system PM representative’s xFLEET DELIVERABLE directory in

ASDR. 3-29 NAVAIR SOP 13630.5 Add any other required common files, including both the Summary of Changes and Supported UUTs documents. • Create a common TPS disk. • Submit an SCP Package and draft TD to PMA260. • Perform QA checks on the media. • Send a preliminary copy of the disk to each affected weapon system PM representative for verification. (3) Once each weapon system PM representative is satisfied the disk is correct: • PMA260 signs the SCP and releases the TD. • PMA260 representatives duplicate and distribute the final media to affected fleet sites. • 3.28 Interim Changes and Work-Arounds Other than IRACs and eRACs, interim changes to fielded CIs cannot be released to end-user sites. Test Workaround Procedure (TWP) To mitigate a problem with either fielded OTPS software, hardware, or both, cognizant Fleet Support Team representatives may, upon weapon system PM direction, issue a TWP via naval message and optional hardcopy format. These written (vice

software-coded) TWPs authorize end-user sites to work around existing problems with fielded OTPS elements until an official update can be processed and released via TD. TWPs are not a method of releasing software CIs to end-users and are not to be used for distributing software changes to end-users. Each TWP must: • • • • • Have a unique identifier for CM and tracking purposes. Identify all applicable UUTs and, preferably, TPSs. Identify the applicable CASS FoT member(s). State that the TWP is considered a TPS element and any problems or deficiencies should be reported to the FST per COMNAVAIRFORINST 4790.2C Indicate that sites should retain the TWP until a solution is incorporated into an SSC or SEC. Each common TPS DVD is to contain both a summary of applicable, active TWPs and a copy of each. Additionally, applicable UUT TPSI files should provide a reference to the TWP The TD that renders a TWP obsolete is required to state that the TWP has been superseded. 3.29

Configuration Status Reporting PM representatives maintain information lists and batch files of all of their programs’ current fleet release versions of OTPM, OTPIs, and OTPH TMs. This data is traceable to named releases in ASDR for configuration status reporting. The lists also include all outstanding TWPs and IRACs. This configuration status information is to be made available to all end-users 3-30 NAVAIR SOP 13630.5 3.210 Deficiency Reporting, Processing, and Resolution OTPS sustainment teams may identify and submit either CASS FoT related deficiencies, proposed enhancements, or both via the ATS ASDR problem and enhancement reporting process. This process currently involves submission of a CASS FoT CCR CCRs may be submitted via an email to cass ssa@navy.mil or using ASDR problem reporting processes CASS ATS related deficiencies and proposed enhancements can be submitted by different CASS users, including ATE developers, TPS developers, CASS technical working group members,

engineering activities, FSTs, NATEC representatives, FMS customers, and fleet users. Figure 4 illustrates the new reporting methodology established for the CASS ATS community. While implementing this methodology, steps will be taken to prevent bottlenecks, implement process improvements and to streamline the overall processing. For example, if the CASS FST submits an ATS CCR identifying a deficiency with a CASS CI under its cognizance, no action from other WIPT members is normally required to create and process the resultant ATS CCR. In that example, other WIPT members get involved only if the ensuing proposed CASS CI change will likely affect one or more CIs under their cognizance. Weapon system PM representatives record and track all types of deficiencies with their respective OTPSs. This information is made available to the CASS Family Acquisition and Sustainment OIPT. 3-31 NAVAIR SOP 13630.5 Figure 4 – Future CASS FoT CCR Processing 3.2101 Discrepancy Reporting by the Fleet

Per COMNAVAIRFORINST 4790.2C, the fleet reports deficiencies with OTPSs exclusively as Engineering Investigation (EI) requests, Product Quality Deficiency Reports (PQDR), and Technical Publication Deficiency Reports (TPDR). EIs and PQDRs are submitted per COMNAVAIRFORINST 4790.2C using the Joint Deficiency Reporting System, which is accessible via: https://jdrs.mil TPDRs are submitted per COMNAVAIRFORINST 4790.2C using TMAPS available via NATEC: https://mynatec.navairnavymil CASS engineering sites responsible for investigating and resolving OTPS deficiencies reported by the fleet typically generate record purpose DRs using various CM tools or processes described in this handbook to track EIs and other CM CI items. 3-32 NAVAIR SOP 13630.5 3.2102 Deficiency Reporting During OTPS Sustainment Weapon system PM representatives record and track all types of deficiencies with OTPSs under their cognizance using locally established processes. This information is made available to the CASS

Family Acquisition and Sustainment OIPT. Users may propose an enhancement to a single OTPS or all OTPSs via naval message, at fleet user forums, during boots-on-the-ground inspections, etc. For example, many of the CASS Operational Readiness Review (ORR) formerly referred to as the Fleet Support Review (FSR) action chits identify proposed OTPS enhancements. The database for FSR action chits is on the PMA260 website portal (https://pma260.navairnavymil) PMA260 forwards the action chit to the WIPT for processing to the appropriate stakeholders. Non-fleet users may report OTPS deficiencies via email or ASDR problem reporting processes by submitting a CCR. PMA260 uses their problem report database, which is available at the PMA260 website, to report and track deficiencies identified during development and fielding of PMA260 CASS FoT products. Those deficiencies that ultimately require changes to fielded ATS components, primarily the TPS software, are adjudicated by the WIPT and are tracked

using ASDR problem reporting processes and documented using CCRs. The WIPT provides disposition and recommended corrective actions. Whenever the WIPT cannot reach a consensus regarding an issue, the issue is to be raised to the OIPT for adjudication. OTPS sustainment teams may identify and submit CASS FoT related deficiencies via ASDR problem reporting processes and document them using CCRs. OTPS sustainment team members without access to ASDR may submit CCRs via email to cass ssa@navy.mil 3.2103 Processing Deficiencies Deficiencies are processed per the following procedures utilizing the CASS Family Acquisition and Sustainment OIPT depicted in Figure 1. In addition, all EIs and PQDRs are processed per COMNAVAIRFORINST 4790.2C and established processes Deficiency processing includes 3-33 NAVAIR SOP 13630.5 initial investigation through discovery of its root cause and development of its proposed resolution. All OTPS deficiencies are routed to the cognizant PM representatives for

initial investigation. The cognizant representative informs (via email, inclusion in the INFO list on EI responses, etc.) the WIPT Lead of the deficiency and the progress of its investigation. The WIPT Lead involves all appropriate stakeholders under the OIPT and ensures that a systems-level approach is taken in the proposed resolution. The WIPT Lead may also provide SMEs, as appropriate, to assist in investigations, root cause determination, and development of proposed resolutions, including depot rework. Any unresolved conflict or issue at the WIPT level is reported to the OIPT chair for coordination with applicable weapon system PSM(s). PMA260 may lead the investigation and resolution of specific OTPS-related deficiencies or proposed enhancements using the WIPT. For example, an ORR action chit that describes a proposed enhancement to many or all OTPSs would typically be led by PMA260, and implementation would be coordinated with all affected PM representatives. OTPS migration

described in paragraph 3.211 of this document is an example of a major OTPS enhancement effort led by PMA260. WIPT representatives of each PMA have visibility into the status of all deficiencies being worked by the WIPT, which fosters communication of systemic problems and reinforces accountability for all reported problems. WIPT representatives may request accounts for ASDR, which stores details about CASS FoT problems, proposed enhancements, and resolution status. Weapon system PM representatives ensure the WIPT Lead is copied on all EI responses or has a method for retrieving information. In addition, PM representatives ensure the WIPT Lead is informed of all other deficiencies with their respective OTPSs tracked via either local procedures, databases, or both. Each proposed deficiency resolution is forwarded to the WIPT Lead for awareness. The appropriate PM(s) make the final implementation decisions. The WIPT Lead assists with the coordination of resolutions involving multiple

PMAs. Proposed resolutions that are not implemented due to either limited funding, limited resources, or both are tracked as unresolved deficiencies. Investigation results may avoid future investigations of the same deficiency by keeping all stakeholders informed about known, unresolved deficiencies. Solutions to unresolved DRs may be implemented at a future date Deficiencies or resolutions involving external interfaces normally dealing with training and FoT facilities beyond OTPS CIs are coordinated by the OIPT Chair. 3.2104 Deficiency Resolution Depending on the affected CI, the weapon system PM representative or PMA260 handles deficiency resolution. 3-34 NAVAIR SOP 13630.5 Per PM direction, all approved OTPS changes are implemented into all affected CIs listed in paragraph 3.221 of this document Changes are to be documented, processed and validated as described in paragraph 3.25 of this document Per PMA260 direction, all approved CASS family changes are implemented into all

affected CIs listed in appendix C. 3.211 OTPS Migration The OTPS migration process updates OTPS for use on other CASS FoT members. When required, PMA260 updates selected OTPS products to support the newest as well as the older CASS family ATE members. This update process is referred to as “OTPS migration” and may include a standardization process that helps ensure compatibility with newer CASS FoT members, when appropriate while maintaining functionality on older CASS FoT members. This migration process produces well-documented updates to OTPS products and related OTPS CIs. The goal of the migration process is to preclude affecting the integrity or functionality of the OTPS. For many OTPSs, migration includes a one-time standardization process that results in common TPS source code containing operator instructions that are compatible with all CASS FoT members. OTPSs that are not targeted for use on newer CASS FoT members may never be selected for standardization. Recently developed

and future OTPSs will already be compliant with standardization when delivered per the NGOR, so no changes will be required. TPS migration from one CASS FoT member to another may also involve additional TPS changes needed to resolve variations in ATE timing, impedance, functionality, etc. These types of changes may be needed each time an OTPS is migrated to a different CASS FoT member. Figure 5 provides an overview of the current OTPS migration process. The steps in this process are: a. Retrieve current version of TPS source data from ASDR b. Standardize operator instructions (ie, make generic) per current TPS development guidelines. This is a one-time occurrence for each TPS c. Document proposed changes and update TPS in ASDR d. Use standardized source code to: • Create new version of CASS TPS executable code for testing. • Create new version of either RTCASS, eCASS TPS executable code or both if applicable for testing. e. Test TPS executable code on all applicable systems (CASS,

RTCASS, eCASS) f. If failure(s); fix code, then return to step d g. Once testing passes, notify TPS representative, citing documentation of changes for review and incorporation into future fleet releases. 3-35 NAVAIR SOP 13630.5 Figure 5 – OTPS Migration Process 3.212 OTPH Rework A rework program for certain CASS OTPH components may be required and is being implemented to extend their service life for continued use on CASS FoT members. The focus of this program is scheduled overhauls of selected, chronically problematic OTPH components rather than routine maintenance or repair of OTPH components. Routine OTPH maintenance or repair is typically performed as individual OTPH components fail, using normal repair processes at I-level. OTPH rework enhances the OTPS sustainment program by providing an overhaul or rework program for some of the currently fielded OTPH components, especially those that have significantly degraded over time due to the cumulative effects of wear-and-tear.

OTPH rework selection criteria will be based upon many factors such as: anticipated remainder of years’ inservice, high time components, serviceability, and fleet demands. OTPH components selected for rework are approved by the COMNAVAIRFOR Type Commanders with inputs from all applicable stakeholders. PMA260 has teamed with Commander, Fleet Readiness Centers Aviation Support Equipment and COMNAVAIRFOR N423 to establish a rework facility for CASS OTPH at the New Orleans, Avionics Depot Overhaul Point. Any proposed configuration changes to OTPS CIs as a result of OTPH rework efforts are processed per paragraph 3.25 of this document. 3-36 NAVAIR SOP 13630.5 CHAPTER 4 DEFINITIONS 4.1 Common Support Equipment (CSE) SE acquired for use on multiple weapon systems and on multiple platforms is designated as CSE. CASS is one example of CSE. Life cycle support of CSE is the responsibility of PMA260 4.2 Peculiar Support Equipment (PSE) SE acquired for use on a single weapon system (regardless

of number of platforms) is designated as PSE. Life cycle support of PSE is the responsibility of the cognizant weapon system PM for the PSE. A peculiar weapon system OTPS is one example of PSE 4.3 Automatic Test System (ATS) An ATS includes ATE hardware, documentation and operating software; OTPSs, which include the hardware, software and documentation required to interface with and test individual weapon system component items; and associated TPS software development tools, referred to as ATE Support Software. The term “ATS” also includes ATE self-test and calibration elements An ATS is the complete system used to identify failed components, adjust components to meet specifications, and assure that an item meets required performance specifications in support of a RFI certification. 4.4 Automatic Test Equipment (ATE) ATE refers to the test set hardware and its operating software. The hardware itself may be as small as a man-portable suitcase or it may consist of eight or more racks

of equipment weighing over 6,000 pounds. ATE is often ruggedized commercial equipment for use aboard ships or in mobile maintenance facilities. ATE used at fixed, non-hostile environments such as depots or factories may consist purely of commercial off-the-shelf equipment. The heart of the ATE is its primary computer which is used to control complex test instruments such as digital voltmeters, waveform analyzers, signal generators, and switching assemblies. This equipment operates under control of test software to provide a stimulus to a particular circuit or component in the UUT, and then measure the response at various pins, ports, or connections to determine if the UUT has performed to its specifications. The ATE has its own operating and support software which performs housekeeping duties such as self-test, tracking preventative maintenance requirements, test procedure sequencing, and storage and retrieval of digital TMs. ATE is typically very flexible in its ability to test

different kinds of electronics. It can be configured to test both avionics electronics assemblies (aka WRAs) and circuit cards (aka SRAs). When connected to the ATE, the WRAs and SRAs are usually referred to as UUTs 4-1 NAVAIR SOP 13630.5 The CASS Family of ATE is depicted in figure 6 and includes Mainframe CASS (e.g Hybrid, Radio Frequency; Electro-Optical; High Power Device Test Set and Communications, Navigation, and Identification configurations), RTCASS (e.g Reconfigurable Transportable (RT) High Power and RT Depot), and various configurations of eCASS. CASS functionality is augmented by ancillary equipment when needed, typically when supporting new, advanced weapon systems. Ancillary equipment is limited to weapon systems special needs and is fielded based on work load. Newer CASS FoT members (ie, RTCASS, eCASS) include some of the capabilities previously satisfied by CASS ancillary equipment for older CASS FoT members (e.g, Mainframe CASS) CASS is used afloat (CV and L-Class

ships) and ashore at: • • • • • • • • • • • • COMNAVAIRFOR sites; Commander, Naval Air Reserve Force sites; Commander, Naval Surface Forces sites; NAVAIR sites; NAVSEA sites; Center for Naval Aviation Technical Training sites; SPAWAR sites; United States Special Operations Command sites; United States Marine Corps sites; FMS sites; Fleet Readiness Centers; and Depots. 4-2 NAVAIR SOP 13630.5 Figure 6 – The CASS FoT Members 4.5 TPS and OTPS A TPS consists of the software, hardware, and documentation (beyond that associated with the ATE or weapon system technical manual) needed to test, fault detect and isolate, or perform any other evaluation of a specific UUT’s performance. An OTPS is a logically-bundled group of TPSs which use the same set of hardware items. An OTPS usually contains TPSs that test one or more WRAs and their SRAs. OTPSs contain the following elements: a. OTPH – The hardware portion of the OTPS typically consists of the following: 4-3

NAVAIR SOP 13630.5 • • • • ID – The OTPH component that mates with the ATEs main interface panel and the UUT. IDs, which are often the largest OTPH component, are designed to facilitate interface connection and enable communication between the ATE and UUT. Test Fixture – A device which provides additional active and passive circuitry to resolve incompatibilities between the UUT and the ATE, which is not appropriate for inclusion in the ID because of weight, size, circuit proximity or heat limitations. It may also be used as a holding fixture to secure the UUT. Holding Fixture – A device designed to maintain proper positioning of an UUT during testing on ATE. It may also be used to direct facility cooling air to the UUT The holding fixture does not contain any circuitry. Cables – Specifically designed items, with or without branches, having one or more ends processed or terminated in fittings for use between UUTs, OTPH (e.g, ID) and ATE. These cables can be very

specialized, consisting of special materials and fabrication processes to preserve signal integrity and UUT compatibility. OTPH may also include special connectors, plugs, adapters, alignment tools, specialized electronic test equipment, etc. Examples of OTPH components are shown in Figure 7. Figure 7 – OTPH Components b. OTPM – The OTPM contains the executable software used to test, fault isolate and adjust or align the applicable UUTs and OTPH components. c. OTPI – The OTPI is the resultant merger of all Test Program Instructions (TPI) associated with an OTPS. Each TPI consists of information needed to support the TPS d. MTPSI – The MTPSI contains a list of all items required to test a unique UUT on a specific ATE and other appropriate data for testing the UUT. 4-4 NAVAIR SOP 13630.5 e. OTPH TM – The TM contains OTPH-related information including description, principles of operation, testing and troubleshooting information for parts removal or installation; the Group

Assembly Parts Lists; the Illustrated Parts Breakdowns; and Source, Maintenance and Recoverability Codes. f. ULSS – The ULSS identifies the logistics and maintenance support required to operate and maintain the OTPS. 4.6 CASS Family OTPM CASS Family OTPMs are end-user deliverable CIs that contain TPS executable software. An OTPM for each applicable CASS Family member is delivered by TPS developers on CD or DVD media. However, TPS executable code is combined by the Government onto common DVDs, typically before distribution to fleet sites. As depicted in Figure 8, all CASS Family TPS executable code is created from the same set of TPS software source code. Figure 8 – CASS Family OTPM CIs 4.7 CASS Family OTPS Support Tools Development or sustainment of an OTPS for the CASS Family requires access to a variety of documentation, hardware, and software tools. Appendix C provides information about CASS Family OTPS Support Tools. 4.8 CASS Implementation Plan (CIP) The CIP is an automated

on-line data management and modeling tool used by PMA260 to determine and track user requirements to support outfitting of CASS test sets, ancillary equipment, and OTPSs by configuration, quantity, and location. As inputs, the CIP uses Naval Aviation Logistics Data Analysis induction data, flight hour data by type-model- series, OTPS data, weapon system and avionics configuration data, and ASDR 4-5 NAVAIR SOP 13630.5 data. The CIP model calculates requirements based on aircraft type and quantity, weapon systems being supported, flight hours, UUT failure rates, mean time on station to repair UUTs, and test set availability. The CIP is used for multiple purposes. PMA260 uses the CIP to determine quantities of CASS Family test stations and ancillary equipment to be procured. The CIP planning toolset can be used by any PMA to help determine the quantities of CASS OTPSs required by each user site based on workload calculations. In addition, the CIP hosts and maintains the master list of

all UUTs repaired on the CASS family of ATE. OTPS data in the CIP is initially provided to PMA260 by the procuring activity with input from the TPS Developer and Acquisition IPT. Accuracy of the data in the CIP is essential Any impact to CIP data due to an OTPS change, including the addition or removal of a weapon system from an OTPS group, is reported to PMA260. 4.9 ATS Source Data Repository (ASDR) The ASDR is a centralized data management system that stores all pertinent data from OTPS acquisitions. It is used to support the sustainment of OTPS data, the development of future ATS, and the maintenance of existing CASS CIs. PMA260 funds the ASDR, and manages ASDR-related processes. CSE CIs within ASDR are owned and supported by NAVAIR PMA260. However, the PSE CIs within ASDR will continue to be owned and supported by the cognizant weapon system program. ASDR provides the following functions and features: • • • • • • • An enterprise repository for all CASS Family data

owners and users. A standard enterprise SLM tool to support ATE and OTPS Development. A common SLM tool to support ISE functions. A repository to facilitate efforts to migrate OTPSs to newer ATE configurations. Optimization for ISE among all CASS Family FSTs. Standard directory structures for CASS Family source data. FSTs may use ASDR data to support non-organic CASS users. The following types of OTPS CIs cannot reside within the ASDR SLM tool itself: • • • • OTPS hardware components Classified data -- because the ASDR server is an unclassified system. CIP related data. SERDs. However, any media sent to ASDR are stored and tracked separately. The ASDR server infrastructure physically resides at the Patuxent River Data Center and is maintained with assistance from the CASS Family Software Support Activity (SSA). The ASDR server is reachable from either the 4-6 NAVAIR SOP 13630.5 Navy/Marine Corps Intranet or the Research, Development, Test and Engineering (RDT&E)

network, providing remote access for the CASS SSA and other Government entities such as weapon system FSTs and ATS developers located at the NAVAIR In-Service Support Centers. Access to data in ASDR is controlled via user accounts with varying degrees of read, write, edit, and delete privileges. Weapon system PMs and their representative’s duties include: • • • • Ensuring the TPS code in ASDR is current with, or is more advanced than, the latest fleet (i.e, fielded) version Providing ASDR with copies of all of their updated OTPS CIs and adequate supporting data no later than initial fleet release of any associated OTPS CI. Ensuring all OTPS data elements delivered to or uploaded into ASDR complies with the Standard OTPS Data Directory Structure (shown in Appendix K of the CASS Users Guide for TPS Developers). Ensuring their OTPS source data within ASDR is managed on a file-by-file basis to provide traceability of all changes. Help Desk and point of contact information as

well as details about accessing and using ASDR are provided in the ASDR Basic Users Guide and ASDR SLM Users Guide. 4-7 NAVAIR SOP 13630.5 APPENDIX A UNIT UNDER TEST (UUT) DATA REQUIREMENTS FOR OPERATIONAL TEST PROGRAM SETS DEVELOPMENT Requirements 1. Assembly drawings of all WRAs and SRAs. Comments Used to identify parts location, physical size and structure of UUT. Used for designing holding fixtures 2. Parts lists Used to identify piece parts by type and manufacturer. Also used to identify UUT mating connector type(s) and manufacturer(s). Required to determine how the WRA functions. Used to aid in fault isolation. Determine bus structure Identifies the function of the UUT. Required to determine how the WRA functions. Used to aid in fault isolation. Determine bus structure Can be eliminated if interconnecting diagram is provided. Provides theory of operation. Allows functional testing 3. Interconnect diagrams for WRAs 4. Schematics for SRAs 5. Wire lists for WRAs without

circuit card assembly motherboards 6. Theory of operation (may be available from technical manual 7. Programmable device source data Programmable devices include Read Only Memory, Programmable Array Logic, Electrically Programmable ReadOnly Memory, and field-programmable gate arrays. Required to perform digital automated test program generator testing of devices. 8. Proprietary data Any proprietary data rights need to be disclosed. May require non-disclosure agreement with original equipment manufacturer. 9. Test operational flight program Required if OFP is to be tested or reloaded after testing and (OFP) and (if available) source repair. Required if OFP provides Self-Test capability code for OFPs and mission software. 10. Built in Test (BIT) source data Required to make full use of BIT capabilities Shortens run times. Allows intermediate level (I-level) to capitalize on organizational level (O-level) testing. 11. Test Requirements Documents Provides all testing requirements as

identified by developer or equivalent 12. Test Specifications (WRAs Provides minimum tests required to ensure that the UUT is only) ready for issue (RFI). 13. Acceptance Test Procedures Provides minimum tests required to ensure that the UUT is RFI. 14. Factory test procedures Allows capitalizing through reuse of existing factory test software. A-1 NAVAIR SOP 13630.5 15. Environmental requirements Required, if the UUT has specific cooling requirement, liquid, forced air, etc. May be able to determine requirements from the WRA technical manual 16. Engineering Change Notices Provides information on changes to the baseline or proposed and Engineering Change changes Proposals 17. Interface Control Documents Provides how each circuit is designed to be used (design interface) in the system. Should also provide special timing characteristics, waveforms, and functional or logic specifications Provides timing information (e.g, between stimuli and 18. UUT Timing Diagrams responses) A-2

NAVAIR SOP 13630.5 APPENDIX B AUTOMATIC TEST EQUIPMENT DATA REQUIREMENTS FOR OPERATIONAL TEST PROGRAM SETS DEVELOPMENT ITEM Consolidated Automated Support System (CASS) Users Guide for Test Program Set Developers Prime Item Development Specification for the CASS Test Station CASS Station Interface and General Purpose Interface Pin-out Data Software User’s Manual for Support Software Software User’s Manual for the Station Control Software Software User’s Manual for the Intermediate Maintenance Operations Management System Test Program Set Development Tools B-1 NAVAIR SOP 13630.5 APPENDIX C CONSOLIDATED AUTOMATED SUPPORT SYSTEM (CASS) FAMILY OPERATIONAL TEST PROGRAM SETS (OTPS) DEVELOPMENT TOOLS AND EQUIPMENT Development or sustainment of an OTPS for the CASS family of automatic test equipment (ATE) requires access to a variety of documentation, hardware, and software tools. Tools and Equipment CASS User’s Guide for test program set Developers CASS Station Interface and

general purpose interface Pin-out Data Prime Item Development Specification for the CASS Test Station ATE configuration Ancillary Software Documentation PMA260, through the CASS Family Acquisition and Sustainment overarching integrated product team (OIPT), assists PM representatives in obtaining and maintaining the tools necessary for development, initial fleet support team stand-up and sustainment of OTPSs. PMA260 works within the OIPT to help obtain and support any peculiar tools not listed in Appendix C that are used to sustain CASS OTPSs. This list of known peculiar tools used to support CASS Family OTPSs is populated and maintained with the assistance of representatives from all OIPT members and is made available on the PMA260 website. Descriptions and Comments X Contains multiple volumes & appendices. Part of CASS Test Program Set Developers Hypertext Guide (THG). X Part of CASS THG. X Part of CASS THG. Software User’s Manual for Support Software Tailored Version -

Software User’s Manual for the Station Control Software X Part of CASS THG Tailored Version - Software User’s Manual for the Intermediate Maintenance Operations Management System Requirements Verification Traceability Matrix X Part of CASS THG NAVAIR Generic OTPS RFP X Part of CASS THG X Performance and verification requirements specification for reconfigurable transportable consolidated automated support system (RTCASS). Part of CASS THG X C-1 ATE configuration Ancillary Software Documentation NAVAIR SOP 13630.5 Tools and Equipment PMA260 Configuration Management Plan for Aviation Support Equipment X ASDR Software Lifecycle Management (SLM) Users Guide X RTCASS TMs CASS TPS advisories NAVAIR OTPS Acquisition and Sustainment Process Handbook CASS technical manuals CASS Block I Hybrid test set CASS Block I communication, navigation and identification (CNI) test set CASS Block I radio frequency (RF) test set CASS Block II CNI test set CASS Block II electro-optical

(EO) test set CASS Block II high power device test set CASS Block II Hybrid test set CASS Block II RF test set CASS Block III Hybrid test set CASS Block III RF test set RTCASS test set Reconfigurable transportable (RT) high power (HP) test set X X X RTCASS Depot (RTCASS-D) test set Electronic CASS (eCASS) RF eCASS EO eCASS HP Air Data Test Set Air Flow Management Set Auxiliary Equipment Fixture Common Interface Device EO+ Optical Equipment Set Inertial Device Test Set (IDTS) IDTS Shore Antenna Kit X X X 2048AS775-01 2048AS775-03 X X X X X X X X X X 2048AS775-02 2054AS400-03 2054AS400-04 2054AS400-05 2054AS400-01 2054AS400-02 2056AS800-01 2056AS800-02 3841AS0101-01 3841AS0101-03 X X X X 3841AS0101-05 4027AS0977-01 4027AS0979-01 4027AS0978-01 ADTS405-5643 2060AS810-01 2057AS050-01 2051AS610-01 74D061415-1001 2056AS953-01 26020909-101 X X X X X X X C-2 Descriptions and Comments Tools and Equipment IDTS Van Antenna Kit Mounting Ancillary Set Multiple Analog Capability

Multi-Purpose Stroke/Raster Display Ancillary Set Power Inverter Power Strip Ancillary Set Printer RF Probe RS-485 Manchester/HARPOON Bus Synchro Generator/Measurement Assembly Ancillary Set UUT Loads Ancillary Set Test Equipment Dolly UUT Power/Ground Cable Set Video Pattern Generator Ancillary Set CASS Block I Applications Software System Synthesis Model Plus (SSM+) CASS Block I operating system software CASS Block II and Block III Applications Software CASS Block II and Block III operating system software CASS Support Software (OpenVMS 6.2 compatible) ATE configuration Ancillary Software Documentation NAVAIR SOP 13630.5 Descriptions and Comments X X X X 26020943-101 3947AS0100-01 D0030004-1001 2055AS833-01 X X X X X X 2057AS310-01 2055AS815-03 Multiple P/Ns (e.g, 2T-LA48W-AA) 2046AS926-01 2051AS163-06 2055AS831-01 X X X X 2056AS631-02 D0030021-1001 000CT001 2055AS808-01 CASS-1-xxx X X X CASS-2-xxx X VECP-1-xxx X CASS-4-xxx X VECP-SUP-xxx. Components: Abbreviated

Test Language for All Systems (ATLAS) Compiler, Test Executive Simulator, Test Program Software Development Shell, etc. CASS-PC1-xxx. Components: Master Test Program Set Index Development Tool, CASS Tools, etc. Lockheed Martin commercial off the shelf software (COTS). "Global" license purchased for US Government-owned CASS Block I and Block II test sets. No licenses purchased for CASS Block III test sets. CASS Support Software (Windows compatible) X Direct Instrument Control Software XX C-3 Tools and Equipment MemTest RTCASS Applications Software RTCASS operating system software RTCASS development tools ATE configuration Ancillary Software Documentation NAVAIR SOP 13630.5 XX X X X Automatic Test Systems (ATS) Source Data Repository (ASDR) RTCASS COTS for L200 X CASS implementation plan C-4 Descriptions and Comments Teradyne COTS software. "Global" license purchased for United States (US) governmentowned CASS Block I test sets. Seventy-five

licenses purchased for CASS Block II and III test sets. RT-APPS-xxx RT-OPSYS-xxx RT-DEV1-xxx. Non-digital, US Governmentowned portion of RTCASS TPS conversion tools. Components: ATLAS to TPML Converter, L200 conversion support tools, etc. Tailored version of Microsofts Team Foundation Server SLM tool hosted on a Patuxent River data center Navy/Marine Corps Intranet server. Populated with CASS related data. Used by non-fleet sites to record and track CASS-related CASS change requests. Currently used for system anomalies and proposed enhancements to CASS family members. RT-DEV2-xxx. Digital, licensed portion of RTCASS TPS conversion tools. Components: Teradyne TPS Converter Studio, etc. Licenses for Weapons System PM Reps are managed by PMA260 reps. Oracle database application on a PMA260 server. Stores and processes CASS ATE and OTPS related data for multiple purposes. NAVAIR SOP 13630.5 APPENDIX D ACRONYMS ADRL AKA ASDR ATE ATLAS ATR ATS BIT CASS CCB CCR CD CDRL CI CIP CLIN CM CNI

COMNAVAIRFOR COTS CSE DCCB DECKPLATE D-level DoD DR DTC DVD eCASS ECP EI EO eRAC FI Automatic Data Requirements List also known as ATS Source Data Repository automatic test equipment Abbreviated Test Language for all Systems acceptance test report Automatic Test System built in test Consolidated Automated Support System Configuration Control Board CASS FoT Change Request Compact Disc Contracts Data Requirements List configuration item CASS Implementation Plan Contract Line Item Number configuration management Communications, Navigation, and Identification Commander, Naval Air Forces commercial off-the-shelf Common Support Equipment Decentralized Configuration Control Board Decision Knowledge Programming for Logistics Analysis and Technical Evaluation depot-level Department of Defense deficiency reports Direct to CASS Digital Versatile Disc electronic Consolidated Automated Support System engineering change proposal engineering investigation Electro-Optical electronic rapid action

change fleet introduction D-1 NAVAIR SOP 13630.5 FLEETEVAL FMS FoT FSR FST GATP GFE GFI GPI HP ICS ID IDD IDTS I-level IOC IPT IRAC ISE JEDMICS LMI MDA MP MTBF MTPSI NATEC NAVAIR NAVSEA NGOR OIPT OPF ORR OTPH OTPM OTPS P/N PCA PIR PM Fleet Evaluation foreign military sales family of testers fleet support review fleet support team general acceptance test procedure government furnished equipment government furnished information general purpose interface High Power Interface Control Specification Interface Device Interface Detail Design Inertial Device Test Set Intermediate-level initial operational capability integrated product team Interim Rapid Action Change in-service engineering Joint Engineering Data Management Information and Control System Logistics Management Information milestone decision authority maintenance plan Mean Time Between Failure Master Test Program Set Index Naval Air Technical Data and Engineering Services Command Naval Air Systems Command Naval Sea Systems

Command NAVAIR generic OTPS request for proposal Overarching Integrated Product Team operational flight programs Operational Readiness Review Operational Test Program Hardware Operational Test Program Media Operational Test Program Set part number physical configuration audit Problem Identification Reports program manager D-2 NAVAIR SOP 13630.5 PMA PMA260 PQDR PSE PSM RAMEC RFV RFI RFP RT RTCASS RTR RVTM SCP SDD SE SEC SEMS SEPO SER SERD SERMI SLM SME SOW SPAWAR SRA SRS SSA SSC SSDD TDP TEMP THG TM TMAPS TPDR Program Manager, AIR Program Manager, AIR 260 (Aviation Support Equipment Program Office) product quality deficiency report Peculiar Support Equipment Product Support Manager Rapid Action Minor Engineering Change Request For Variance Ready For Issue Request For Proposal Reconfigurable Transportable Reconfigurable Transportable Consolidated Automated Support System report of test results Requirements Verification Traceability Matrix software change proposal software detail

design support equipment support equipment change Support Equipment Management System Support Equipment Program Officer System Enhancement Request support equipment recommendation data Support Equipment Resources Management Information System Software Lifecycle Management Subject Matter Expert statement of work Space and Naval Warfare Systems Command shop replaceable assembly software requirements specification Software Support Activity support software change Subsystem Detail Design technical data package Test and Evaluation Master Plan Test Program Set Developers Hypertext Guide Technical Manual Technical Manual Application System Technical Publication Deficiency Report D-3 NAVAIR SOP 13630.5 TPI TPS TWP ULSS US UUT WIPT WRA Test Program Instruction Test Program Set Test Workaround Procedure User Logistic Support Summary United States Unit Under Test Working-level Integrated Product Team Weapons Replaceable Assembly D-4