5
NAVAIR SOP 13630.5
i
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:
Robert L. Burgess, CAPT USN Program Manager, Aviation Support Equipment
NAVAIR SOP 13630.5
ii
RECORD OF CHANGES
Identification of Correction or Change
Date of Change
Version Entered By
Supersedes The NAVAIR Operational 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.
5/29/20 1.1 T. Conard
For questions or to give feedback Contact: Brian Cervenak, PMA260 ATS APML [email protected], (301) 757-6836
A copy of this Handbook will be posted on the NAVAIR Directives website at https://myteam.navair.navy.mil/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
mailto:[email protected]://myteam.navair.navy.mil/km/71/Directives
iii
NAVAIR SOP 13630.5 NAVAIRINST 13630.5 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.navair.navy.mil
https://directives.navair.navy.mil/
NAVAIR SOP 13630.5
iv
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
NAVAIR SOP 13630.5
v
RESOURCES
1. NAVAIRINST 13630.5A, Optimizing Weapon System Avionics Support Using AutomaticTest Systems - https://directives.navair.navy.mil/
2. NAVAIR Generic OTPS Request for Proposal (RFP) (NGOR) -https://pma260.navair.navy.mil/intranet/root/frames.cfm
3. NAVAIR 00-25-300, “Naval Air Systems Command Technical Directives SystemManagement and Procedures Manual” 30 July 2015 - https://mynatec.navair.navy.mil
4. NAVAIR SOP 4130.1, Naval Air Systems Command Standard Operating Procedure -https://directives.navair.navy.mil/
5. Commander, Naval Air Forces Instruction (COMNAVAIRFORINST) 4790.2C CH-1, “TheNaval Aviation Maintenance Program” - http://www.navair.navy.mil/logistics/4790/
6. DoD Automatic Test Systems Selection Process, Revision A, dated 15 June 2016 –http://www.acq.osd.mil/log/mpp/ats.html
7. OPNAVINST 3960.16B, Navy Test, Measurement, and Diagnostic Equipment, AutomaticTest Systems, and Metrology and Calibration –https://doni.documentservices.dla.mil/default.aspx
https://directives.navair.navy.mil/https://pma260.navair.navy.mil/intranet/root/frames.cfmhttps://mynatec.navair.navy.mil/https://directives.navair.navy.mil/http://www.navair.navy.mil/logistics/4790/http://www.acq.osd.mil/log/mpp/ats.htmlhttps://doni.documentservices.dla.mil/default.aspx
NAVAIR SOP 13630.5
1-1
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 bereviewed.)
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 Navy's 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 3960.16B, 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.
NAVAIR SOP 13630.5
2-3
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
NAVAIR SOP 13630.5
2-4
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
NAVAIR SOP 13630.5
2-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 4.5 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 2.2.6 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 4.8 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.2.1 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.
NAVAIR SOP 13630.5
2-6
2.2.2 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
Contracting Strategies
Factors UUT
Design UUT Data Availability UUT
Availability ATE
Availability Full and Open Competion Mature Yes- available as GFI GFE GFE
Limited Competition Stable
Yes, but not available as GFI; at least two contractors have
knowledge of UUTs (e.g., UUT manufacturer and
weapon systems integrator) GFE GFE
Sole Source (industry/government) Stable Yes, but not available as
GFI GFE GFE Government Development Stable Limited data available Government Government
2.2.3 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.
NAVAIR SOP 13630.5
2-7
2.2.4 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.2.5 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.2.6 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://pma260.navair.navy.mil, 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;
https://pma260.navair.navy.mil/
NAVAIR SOP 13630.5
2-8
(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.2.7 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:
¤ 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.
• Cybersecurity requirements • Contracting strategy:
¤ 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
NAVAIR SOP 13630.5
2-9
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 [email protected] 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
Required Data
Problem Title Problem Description Originator Point of Contact for Technical Details
Phone No. Optional Data
Date Originated Reference No. Software Part No.
mailto:[email protected]
NAVAIR SOP 13630.5
2-10
2.5 Products
2.5.1 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.
Table 3 - OTPS Development Products and Data
Product List
Prep
ared
by
OTP
S Pr
epar
ed b
y G
over
nmen
t Fl
eet d
eliv
ery
Susta
inin
g CI
s and
dat
a R
efer
ence
dat
a
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 4.9 for a description of ASDR.)
OTP
S H
ardw
are
and
Softw
are
Operational Test Program Hardware (OTPH)
X X X Includes Interface Device (ID), Test Fixtures, Holding Fixtures, Cables, etc.
Operational Test Program Media (OTPM)
X X X X 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.
O T Operational Test Program Instructions (OTPI) X X X X 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.
Master Test Program Set Index (MTPSI) files
X X X MTPSI source / distributed data (e.g., *.tpsi) files. Included in OTPM, OTPI discs, or both if applicable.
NAVAIR SOP 13630.5
2-11
OTPH Technical Manual (TM)
X X X 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.
User Logistic Support Summary (ULSS)
X X X In PDF.
NAVAIR SOP 13630.5
2-12
Product List
Prep
ared
by
OTP
S Pr
epar
ed b
y G
over
nmen
t Fl
eet d
eliv
ery
Susta
inin
g CI
s and
dat
a R
efer
ence
dat
a
Descriptions and Comments (Note: For new OTPSs, all products except for
SERD, OTPH and CIP data is resident in ASDR. See paragraph 4.9 for a description of
ASDR.)
OTP
S D
ata
(con
tinue
d)
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 X X OTPH TM Source Data X X Developed per MIL-STD-3001 or S1000D ULSS Source Data X X Stored on PMA260 website System Specification X X If required per contract
Interface Control Document (ICD)
X X If required per contract
Software Requirements Specification (SRS)
X X If required per contract
Software Detail Design (SDD) X X If required per contract Interface Control Specification (ICS)
X X If required per contract
Interface Detail Design (IDD) X X If required per contract Subsystem Detail Design (SSDD)
X X If required per contract
Logistics Management Information (LMI) Data
X X Source of Logistics deliverables
Maintenance Plan (MP) X X CIP Data X X Resident in CIP database SERDs X X Resident in Support Equipment Management
System (SEMS) database Interim Support Items List X X If required per contract Government Test Reports X X X From all test events Pilot Production Acceptance Test Report
X X X From developmental tests
NAVAIR SOP 13630.5
2-13
Fleet Introduction (FI) Report X X X From initial operational capability (IOC) fielding events
RFVs or Problem Identification Reports (PIR)
X X X
2.5.2 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 Government's 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.6.1 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 close-out of the development phase.
NAVAIR SOP 13630.5
2-14
2.6.1.1 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 developer's 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.6.1.2 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
NAVAIR SOP 13630.5
2-15
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.
NAVAIR SOP 13630.5
2-16
2.6.2 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.7.1 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.7.2 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.
NAVAIR SOP 13630.5
2-17
2.8.1 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 12- month 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.8.2 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
NAVAIR SOP 13630.5
2-18
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.
• MTPSI
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.
NAVAIR SOP 13630.5
2-19
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.navair.navy.mil) 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.8.3 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).
https://mynatec.navair.navy.mil/
NAVAIR SOP 13630.5
2-20
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).
NAVAIR SOP 13630.5
3-1
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.2.1 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:
• 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
b. Reporting any problems with the CIs listed in Appendix C using ASDR problem reporting processes per paragraph 3.2.10.3 of this document.
c. Reporting any OTPS problems per paragraph 3.2.10.3 of this document. d. Ensuring the respective data within ASDR is current with or more advanced than the
latest fleet release. e. Making changes to ASDR with all relevant supporting data about each OTPS change.
This includes:
NAVAIR SOP 13630.5
3-22
• 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 13680.1D, “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. ASDR Team Project:
DESCRIPTION OF CHANGE
SCP/SSC No: Affected Configuration Items Ne
w
Del
Upd
OTPS Nom: OTPS P/N: TPSLib Updates:
New OTPS/TPS(s):
New TWP(s):
Deletion of Obsolete OTPS Data:
OTPS Update:
OTPILib Updates:
MTPSILib Updates:
NAVAIR SOP 13630.5
3-23
Superseded OTPS TWP(s), media, and/or SSC(s):
Other related TD(s): N/A
Figure 2 – CASS OTPS CDD
3.2.2 Configuration Identification
3.2.2.1 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 PM's 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 PM's 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
NAVAIR SOP 13630.5
3-24
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.2.3 OTPS Sustainment Requirements
OTPS CIs are subject to their respective PM's 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.2.4 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.2.5 OTPS Change Processes
3.2.5.1 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 4130.1 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
NAVAIR SOP 13630.5
3-25
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.2.5.2 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.4.8. 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.4.19.
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.2.4 and 3.4.8, 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.2.5.3 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
NAVAIR SOP 13630.5
3-26
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.4.19. 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.2.5.4 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.2.5.3 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
NAVAIR SOP 13630.5
3-27
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.2.5.5 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.2.5.6 TD Verification
TD verification is conducted per NAVAIR 00-25-300 Section 3.9
3.2.6 Distribution of Updated OTPS Products and Data
3.2.6.1 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
NAVAIR SOP 13630.5
3-28
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 FST's integrated logistics support repository.
(t) MP is optionally maintained within ASDR. (u) SERDs are optionally maintained within the SEMS database.
3.2.6.2 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.
NAVAIR SOP 13630.5
3-29
Figure 3 – Types of Software Releases
3.2.6.3 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.2.7 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.2.2.2 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.
NAVAIR SOP 13630.5
3-30
• 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.2.8 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.2.9 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.
NAVAIR SOP 13630.5
3-31
3.2.10 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 [email protected] 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.
mailto:[email protected]
NAVAIR SOP 13630.5
3-32
Figure 4 – Future CASS FoT CCR Processing
3.2.10.1 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.navair.navy.mil
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.
https://jdrs.mil/https://mynatec.navair.navy.mil/
NAVAIR SOP 13630.5
3-33
3.2.10.2 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.navair.navy.mil). 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 [email protected].
3.2.10.3 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
https://pma260.navair.navy.mil/mailto:[email protected]
NAVAIR SOP 13630.5
3-34
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.2.11 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.2.10.4 Deficiency Resolution
Depending on the affected CI, the weapon system PM representative or PMA260 handles deficiency resolution.
NAVAIR SOP 13630.5
3-35
Per PM direction, all approved OTPS changes are implemented into all affected CIs listed in paragraph 3.2.2.1 of this document. Changes are to be documented, processed and validated as described in paragraph 3.2.5 of this document.
Per PMA260 direction, all approved CASS family changes are implemented into all affected CIs listed in appendix C.
3.2.11 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 (i.e., 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.
NAVAIR SOP 13630.5
3-36
Figure 5 – OTPS Migration Process
3.2.12 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’ in-service, 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.2.5 of this document.
NAVAIR SOP 13630.5
4-1
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.
NAVAIR SOP 13630.5
4-2
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 (i.e., 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.
NAVAIR SOP 13630.5
4-3
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:
NAVAIR SOP 13630.5
4-4
• ID – The OTPH component that mates with the ATE's 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) a
![[NAVAIR 00-80T-114]](https://static.documents.pub/doc/80x56/577d26651a28ab4e1ea1163e/navair-00-80t-114.jpg)
