Performance_Work_Statement.doc

DOC document 304 KB Posted

Attached to
Engineering Services - Technical Data Package Modernization Federal contract opportunity
Solicitation number
FA8534-19-R-0011
Issued by
Department of the Air Force Materiel Command Lifecycle Management Center Robins Air Force Base

About this file

PWS

View the file

Other files for this federal contract opportunity

Show all 19

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Performance Work Statement For Technical Data Package (TDP) Modernization

For United States Air Force (USAF) Support Equipment and Vehicles (SE&V) Program Office Purchase Request: FD2060-19-30512 31 January 2019 Distribution Statement: C: Distribution is authorized to US Government agencies and their contractors. Other requests for this document shall be referred to AFLCMC/WN-SEV.

1.0 DESCRIPTION OF SERVICES. This Performance Work Statement (PWS) describes the engineering services required to update and modernize the existing legacy Government drawings/Technical Data Packages (TDPs) for equipment managed by the Support Equipment and Vehicles (SE&V) Program Office located at Robins AFB, GA.

During the contract period, the Government will furnish individual task orders detailing “task description(s)” related to SE&V equipment TDP. Each task order will clearly describe specific tasks to be performed and/or data to be delivered, and will reference appropriate paragraphs/subparagraphs herein. The Contractor shall be responsible for comprehensively addressing each task order and all relevant PWS references therein. Task orders will be within the scope of the requirements herein, will identify a period of performance, and be within the maximum value (or remaining value) of the contract. Responsibility for meeting all requirements herein, and driven by task orders, resides with the Contractor.

Each task order will address specific task requirements, project scheduling, and other related performance criteria, as applicable. All task orders shall require delivery of a final report per paragraph 4.6. The Government shall own unlimited rights to all data deliverables generated as a result of this PWS or individual task order; this requirement cannot be waived. When specified by the task order, the deliverables shall meet nuclear certification requirements per Air Force Manual (AFMAN) 91-118 or equivalent.

1.1 Objective(s). This effort seeks to improve sustainment of aging and legacy SE&V equipment by updating and modernizing (see 4.3.1) the existing legacy Government drawings/TDPs. The Contractor shall, in response to Government issued task orders, furnish appropriate resources such as skilled and qualified personnel, equipment, materials, facilities, etc. necessary to perform any tasks required by this PWS or individual task order. The engineering services required in the PWS (including reverse engineering, diminishing material and manufacturing sources, and sources of supply updates) are not in the areas of electrical/electronic/hydraulic/etc. component(s)/subassemblies listed in the Government TDPs, unless these services are required to accomplish an individual task order. Rather, this effort is limited to areas of mechanical and/or structural components, subassemblies, complete assemblies.

1.2 Benefit to United States Air Force (USAF). This effort will benefit the USAF by directly improving operational system safety and suitability (OSS&E) and supporting engineering/technical sustainment (i.e., engineering analysis, repair, manufacturing, inspection/Quality Assurance (QA), configuration management, etc.) for the following SE&V programs and their system/subsystem equipment:

- Aircraft engine trailers

· Aircraft handling equipment

· Aircraft recovery systems

· Base Expeditionary Airfield Resources (BEAR)

· Borescopes

· Boresights

· Base Support Equipment

· Calibration, Optical, & Ancillary Testers (COATS)

· Cryos and Compressors

· Cargo & Utility Vehicles (CUV): Medium Tactical Vehicles (MTV)

· Engine Download Devices (EDD)

· Engine Test Stands (ETS)

· Flight Control System Test Set (FCSTS)

· Firefighting Equipment/Crash

· Crash Recovery Vehicles (CRV)

· Halvorsen

· Hydraulics

· Jammers

· Material Handling Equipment/Trailers

· Material Handling Unit (MHU)-196/204

· Miscellaneous Aerospace Ground Equipment (AGE)

· Mine Resistant Ambush Protected (MRAP)

· MRAP Recovery of Airbases Denied by Ordnance (RADBO)

· Pallets & Nets

· Secondary Power

· Special Purpose Vehicles (SPV)

· Security and Tactical Vehicles (S&TV)

· Test Sets and Fixtures

· Noise Suppressors

· Air Transportable Galley-Lavatory (ATGL)

· Tunner

· Heating, Ventilation and Air Conditioning

· Tow Vehicles

· Refueler Vehicles

· Hush Houses Additionally, this effort directly corresponds to the Department of Defense (DoD) goal to transform DoD to a modern technical data infrastructure based on 3D Intelligent Portable Document Format (3D iPDF) models.

1.3 Background. The Government requires these engineering services in support of the OSS&E responsibilities on aging and legacy fleet of equipment managed by the SE&V Program Office located at Robins AFB. The objectives and requirements identified within this PWS are described in general terms. Each task order will address specific task requirements, systems/subsystems, project scheduling, and other related performance criteria, as applicable.

2.0 SERVICES SUMMARY.

Table I. Services summary.

Performance Objective
PWS Reference
Performance Threshold

Quality of Contract Data Requirements List (CDRL) deliverable

4.2.1
There shall be no more than one rejection of any deliverable. There shall be no more than two total rejection(s) of deliverables per quarter. The Government will reject a deliverable if one or more technical errors or two or more minor errors are found within the deliverable. A technical error is defined as the format not being in accordance with the CDRL or the content not being accurate and complete in accordance with the CDRL, PWS, or contract. A minor error is exemplified by a typographical error, a grammatical error, etc. The rejected deliverable shall be corrected and resubmitted within 15 business days of notification of Government rejection or in accordance with associated DD Form 1423 instructions/requirements.
Receipt of CDRL deliverable
4.2.2
There shall be no more than one late submission(s) of deliverables per quarter. The Contractor shall notify the Government if the delivery of any data/document will not meet the scheduled delivery date and negotiate a revised delivery date. The data/document shall be delivered by the revised delivery date acceptable to the Government.

Engineering data

4.3
The Contractor shall submit the TDP in accordance with this PWS and all CDRL requirements. One Government directed revision per drawing is allowed. The Contractor’s final product shall be 100% accurate and comply with all applicable CDRL requirements.
Model-based TDP (MTDP).
4.3.1
The Contractor shall provide a Model-based TDP (MTDP) for the respective system, subsystem, assembly, subassembly, or part pertaining to SE&V equipment. Items with an existing TDP shall have their TDP revised/updated and converted to a MTDP. The Contractor’s final product shall be 100% accurate and comply with this PWS and all CDRL requirements.
Delivery of final report
4.6
The Contractor shall provide a final report in accordance with 4.6. The Government shall reject the submitted report if one or more technical flaws or one or more minor flaws are found within the report. A technical flaw is defined as the format not being in accordance with the PWS, CDRL, or contract or the content not being complete in accordance with the PWS, CDRL, or contract. A minor flaw is defined as a typographical or grammatical error. There shall be no more than one rejection of each report. There shall be no more than one total rejection(s) of reports per quarter.
Contractor Manpower Reporting
5.7
Within 30 calendar days of contract/order award, the Contractor shall establish a record for the contract/order in eCMRA including Order Data, Contact Data and Location Data.

The Contractor shall provide a count of Contractor/subcontractor personnel performing services for each fiscal year and report all Contractor/sub- contractor labor hours required for performance of services for each fiscal year. All data shall be reported no later than October 31 of the following fiscal year.

Adherence to Contractor Quality Management System (QMS)
5.9
100% compliance with the QMS is required.

3.0 GOVERNMENT PROPERTY/SERVICES.

3.1 Contractor responsibility. The Contractor shall be responsible for the Government property in accordance with the Federal Acquisition Regulation (FAR) and as specified in the contract/task order.

3.2 Government property to be provided. Government property to be provided will be specified within the issued individual task order.

3.3 Base support. The Government will furnish property incidental to the place of performance including office space and equipment, i.e., computer equipment, software, output device(s), phone/phone line, facsimile equipment, reproduction equipment and office supplies.

3.4 Reporting of Government property. The Contractor shall create and maintain records of all Government property accountable to the contract/task order. The Contractor shall record receipt and return of Government-Furnished Property (GFP) in the Item Unique Identification (IUID) Registry.

3.5 Loss of Government property.

3.5.1 Definition of loss of Government property. “Loss of Government property” means unintended loss of or damage to Government property including property that cannot be found after a reasonable search, loss due to inadequate storage, loss due to lack of security, theft, damage requiring repair to restore the item to usable condition, or damage that renders the property useless for its intended purpose or Beyond Economical Repair (BER). Loss of Government property does not include manufacturing defects, obsolescence, normal wear and tear, or purposeful destructive testing. Unless otherwise stated in the contract/order, loss of Government property does not include normal and reasonable inventory adjustments, i.e., losses of low priority consumable material, such as common hardware, as agreed to by the Contractor and the Government Property Administrator.

3.5.2 Reporting loss of Government property. The Contractor shall report loss of Government property using Defense Contract Management Agency (DCMA)/Access To eTools.

3.6 Return or retention of Government property. All property provided by the Government remains the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the Procuring Contracting Officer (PCO) directs the Contractor to retain the property for continued use under a successor contract. All Government property shall be returned to the Government in the condition provided unless approved in advance by the PCO. All material generated under the contract/order becomes the property of the Government and shall be returned to the Government as directed, but no later than completion of the contract/order, unless the PCO directs the Contractor to retain the material for continued use under a successor contract.

3.7 All data and material developed and generated under this contract/task order becomes the property of the Government and shall be provided to the Government upon completion of the contract/task order. All Department of Defense (DD) Form 1423-1 CDRL deliverables, the data and information therein, become the property of the Government upon receipt.

3.8 Government furnished information. Should the Contactor require information from the Government necessary to complete individual task order, the responsible Government engineer for respective SE&V system/subsystem will be responsible for providing that information to the Contractor within 15 business days after receipt of the written request (email is acceptable). The Government engineer will furnish the following information to be used for this task:

a. Reports providing related technical or historical data.

b. The USAF 3D iPDF template and/or Technical Orders (TOs).

c. Required information pertaining to the Government drawings (i.e., noted discrepancies, missing drawing, etc.).

d. Unless otherwise specified in the task order, required exhibits for analysis will be provided within 15 days of receipt by AFLCMC/WNZE. After completion, the Contractor shall contact AFLCMC/WNZE for disposition instructions for any exhibits provided for analysis.

4.0 TECHNICAL REQUIREMENTS

4.1 Period and place of performance.

4.1.1 Contract/task order period of performance. The contract period of performance for placing orders is 5 years. Each individual task order will specify a period of performance.

4.1.2 Place of performance. The services shall be performed at the Contractor’s facility, at the subcontractor’s facility, or at Government installations as required in the task order. No task order will require access to Government installations for more than 30 business days. Place of performance shall be stated on each individual task order.

4.2 Contract Data Requirements List(s) (CDRL).

4.2.1 Quality of CDRL deliverable. There shall be no more than one rejection of any deliverable. There shall be no more than two total rejection(s) of deliverables per quarter. The Government will reject a deliverable if one or more technical errors or two or more minor errors are found within the deliverable. A technical error is defined as the format not being in accordance with the CDRL or the content not being accurate and complete in accordance with the CDRL, PWS, or contract. A minor error is exemplified by a typographical error, a grammatical error, etc. The rejected deliverable shall be corrected and resubmitted within 15 business days of notification of Government rejection or in accordance with associated DD Form 1423 instructions/requirements.

4.2.2 Receipt of CDRL deliverable. CDRL deliverables may be submitted via Wide Area Work Flow e-Business Suite / Invoicing, Receipt, Acceptance, and Property Transfer (iRAPT) or be submitted directly to the MFT member identified on the CDRL. There shall be no more than one late submission(s) of deliverables per quarter. The Contractor shall notify the Government if the delivery of any data/document will not meet the scheduled delivery date and negotiate a revised delivery date. The data/document shall be delivered by the revised delivery date acceptable to the Government.

TABLE II. Summary of required CDRLs with delivery schedules.

Document Identifier
DID
Title
PWS Reference(s)
A001
DI-SESS-81000E/T
Product Drawings/models and Associated Lists
4.3
A002
DI-ADMN-81249B
Conference Agenda (Engineering Data Guidance Conference)
4.3.3
A003
DI-ADMN-81250B
Conference Minutes (Engineering Data Guidance Conference)
4.3.3
A004
DI-ADMN-81249B
Conference Agenda (In-process review (IPR) of the TDP)
4.3.4
A005
DI-ADMN-81250B
Conference Minutes (In-process review (IPR) of the TDP)
4.3.4
A006
DI-MISC-80508B
Technical Report – Study/Services (Reverse Engineering)
4.4
A007
DI-MGMT-80894A
Source/Vendor List
4.4
A008
DI-MGMT-80797
Producibility Analysis Report
4.4.1
A009
DI-MISC-80508B
Technical Report – Study/Services (Over and Above)
4.5
A010
DI-MISC-80508B
Technical Report – Study/Services (Final Report)
4.6
A011
DI‑SESS-80639D
Engineering Change Proposal (ECP)
4.7.1
A012
DI-SESS-80642D
Notice of Revision (NOR)
4.7.1
A013
DI‑MGMT‑80227
Contractor's Progress, Status and Management Report
4.8.3
A014
DI-ADMN-81249B
Conference Agenda
4.9.4
A015
DI-ADMN-81250B
Conference Minutes
4.9.5
A016
DI-MGMT-81861A
Integrated Program Management Report (IPMR)
4.10
A017
DI-ENVR-81840
Programmatic Environmental Safety and Health Evaluation Plan
5.5.3

4.3 Engineering data. When a TDP is required by a task order, the Contractor shall develop/produce/maintain and deliver a TDP that accurately depicts the final product. The TDP shall represent the approved, tested, and accepted configuration of the defined delivered item(s). This shall include software and all test requirement documentation data required to test systems, subsystems and/or components. Vendor Item Control Drawings per ASME Y14.24 shall be used to specify the requirements for purchased items when such items have been approved for use in the design and are used without alteration, selection or source qualification (testing of an item prior to procurement action to ensure that it satisfies the specified requirements). TDP data includes, but is not limited to, Computer Aided Design (CAD) data, CAD models, model based definition data sets, 3D data, Gerber data, and Master Bill of Materials (BOM). The TDP shall provide the necessary design, engineering, manufacturing, testing and quality assurance requirements information necessary to enable the procurement or manufacture of an interchangeable item that duplicates the physical and performance characteristics of the original product without additional design engineering effort or recourse to the original design activity or any third party. All engineering product definition data created using Government funding as a result of this contract shall be considered a part of the TDP and shall be delivered to the Government with unlimited rights excluding existing proprietary data. The TDP delivery and format shall be in accordance with CDRL A001. (A001, DI-SESS-81000E/T, Product Drawings/Models and Associated Lists). One Government directed revision per drawing is allowed. The Contractor’s final product shall be 100% accurate and comply with all applicable CDRL requirements.

4.3.1 Model-based TDP (MTDP). When requested in an individual task order, the Contractor shall provide a Model-based TDP for the respective system, subsystem, assembly, subassembly, or part pertaining to SE&V equipment. Items with an existing TDP shall have their TDP revised/updated and converted to a MTDP. All referenced specifications/standards shall be updated to the most current version. If a specification is cancelled, superseded, or obsolete, a replacement specification that meets the design requirements shall be identified and used. Marking notes shall be updated to specifically address the complete marking instructions in MIL-STD-130. The new MTDP shall also incorporate any outstanding Change Orders against the existing TDP. Existing TDPs for which the USAF is not the current design activity shall not be revised unless otherwise directed by the Government. The Contractor’s final product shall be 100% accurate and comply with this PWS and all CDRL requirements.

MTDPs shall consist of a fully annotated (see MIL-STD-31000B) native model created in SolidWorks 2017, a fully annotated 3D iPDF derived from the native model, and a .stp file derived from the native model. The native model file (.sldprt, .sldasm, etc.) created in SolidWorks shall serve as the master from which all neutral files (e.g. STEP, IGS, JT, STL, PRC, PDF, etc.) are derived. MTDPs shall not include 2D drawings unless specifically authorized by the Government.

4.3.1.1 3D models. Native 3D models created for items with an existing TDP shall be accurate to, and contain no-less than, the information present in the existing TDP. At a minimum, neutral file formats (e.g. STEP, IGS, JT, STL, PRC, PDF, etc.) shall be produced/producible from all native 3D models with no errors. Native 3D models shall accurately depict the items they define in both product structure, geometry, metadata, and management information. All 3D models shall be mono-detail. For any existing drawings containing insufficient information to fully define the part, a 3D model shall be created that captures the: envelope boundaries of the part or assembly, any interface requirements, and all other information from the original drawing.

4.3.1.2 Notes and dimensions. Native 3D models shall be dimensioned and fully annotated (see MIL-STD-31000B) in accordance with ASME Y14.5 and ASME Y14.41. All notes within native 3D models shall be in accordance with ASME Y14.100. However, terms that refer to 2D mediums (e.g. DRAWING, PARTS LIST, etc.) shall be replaced with “MODEL”, as needed, to translate any standard notes for use in the context of 3D models. Instructions within these standards and any articles they reference that are only applicable in the context of 2D drawings are not required.

4.3.1.3 Material. The correct material shall be assigned to all native 3D models. The properties of the assigned material shall be accurate and at a minimum, shall include the density of the material.

4.3.1.4 Standard views. All dimensions, tolerances, notes, lists, tables, figures, annotations, and other information necessary to define an item to the appropriate level shall be presented in various views within the native 3D model in accordance with ASME Y14.41. The default state of a given view shall display all relevant content, and shall be configured to maximize content legibility and minimize empty space. All displayed content may rotate if needed to meet the requirements defined in this document.

The first view shall display all applicable restrictive legends (e.g. Distribution Statement, Export Control Notice, Destruction Notice, Proprietary Statement, etc.), the second view shall display all applicable management information (e.g. management data (see ASME Y14.41), contract number, data rights, and control marking), the third view shall only display the unannotated model in an axonometric position, the fourth view shall display all notes (e.g. general notes, flag notes, special notations, material, treatment, finish, tolerances, mass/weight, units, scale, etc.), and the fifth view shall display the Parts List (PL) or Bill of Materials (BoM) if applicable. The first and second views shall also display the unannotated model in an axonometric position, if space and legibility allow. The fourth view shall also display the model, unannotated or annotated with flag notes, if space and legibility allow. Subsequent view(s) shall display figures, lists, tables, dimensions, annotations, sections, details, product manufacturing information, and any other necessary information.

The first view, which displays restrictive legends, shall function as the default view for the model and shall display when the model is initially opened. All views shall be identified with a name that corresponds to the view’s content and/or perspective, and an alphanumeric prefix that corresponds to the view order (e.g. 1-Restrictive Legends, 2-Management Information, 3-Axonometric, 4-Notes, 5-Parts List, 6-Exploded, 7-Figure 1, 8-Datums, 9-Section A 10-Gear Dimensions, etc.). It may not be possible to change the identification of the default view, in which case, the default view is excluded from the view identification requirements.

4.3.1.5 Assemblies. All native 3D models of assemblies shall accurately reflect true-to-life functional and interface constraints to the fullest extent possible. Exploded views shall be presented in all native 3D models as necessary to clearly identify all subcomponents within a given assembly. The functional motion of a given assembly shall be represented in that assembly’s native 3D model unless otherwise directed by the Government. For example, if an assembly’s function requires motion (e.g. springs, bearings, gears, linkages, etc.), the motion shall be represented in the native 3D model either by animation or user interaction. The functional motion of a given sub-assembly shall be represented in the native 3D model of the next-higher assembly as well, continuing to the top level assembly.

When modeling assemblies, priority shall be given to depicting an accurate product structure with the native 3D model’s model tree, unless otherwise directed by the Government. For example, assemblies shall not be modeled as single entities (merged or unmerged) to better represent weldments, as this would result in the assembly being incorrectly represented in the model tree as a piece-part with no subcomponents/subassemblies. All PLs/BoMs shall be integrated with their corresponding native 3D model and shall be displayed in the model’s fifth view (see 4.3.1.4). PLs/BoMs shall not exist as separate documents and shall not be separately revisable from their native 3D model.

4.3.1.5.1 Parts List/Bill of Materials Integration. When converting an existing TDP with a separate PL/BoM to an MTDP, the following procedure shall be followed to integrate the PL/BoM with the native 3D model. Both the existing PL/BoM and Drawing/Model shall be revised and shall readily display the following note: THIS DATASET HAS BEEN INTEGRATED WITH <identify corresponding integrating dataset>, SEE <identify integrated MTDP> REV: <revision ID of integrated MTDP> FOR INTEGRATED DEFINITION. The integrated MTDP shall be created with a Revision ID, one increment higher than the highest revision between the revised PL/BoM and Drawing/Model. The MTDP shall be identified with the base Document/Drawing Number, Dataset ID, and Title (see ASME Y14.100 and 4.3.1.11) of the existing Drawing/Model. The existing PL/BoM and Drawing/Model shall no longer be updated or revised. Below are examples of the previously described procedure:

Existing TDPs:

Drawing: 123ABC CAGE: 98752 Rev: B PL: 123ABC CAGE: 98752 Rev: - Revised TDPs and Integrated MTDP:

Drawing: 123ABC CAGE: 98752 Rev: C PL: 123ABC CAGE: 98752 Rev: A MTDP: 123ABC CAGE: 98752 Rev: D

Revised Drawing Note:

THIS DATASET HAS BEEN INTEGRATED WITH PARTS LIST 123ABC CAGE: 98752, SEE 123ABC CAGE: 98752 REV: D FOR INTEGRATED DEFINITION.

Revised PL Note:

THIS DATASET HAS BEEN INTEGRATED WITH DRAWING 123ABC CAGE: 98752, SEE 123ABC CAGE: 98752 REV: D FOR INTEGRATED DEFINITION.

Existing TDPs:

Drawing: DWG123ABC CAGE: 98752 Rev: B PL: 123ABCPL CAGE: 98752 Rev: C Revised TDPs and Integrated MTDP:

Drawing: DWG123ABC CAGE: 98752 Rev: C PL: 123ABCPL CAGE: 98752 Rev: D MTDP: 123ABC CAGE: 98752 Rev: E

Revised Drawing Note:

THIS DATASET HAS BEEN INTEGRATED WITH 123ABCPL CAGE: 98752, SEE 123ABC CAGE: 98752 REV: E FOR INTEGRATED DEFINITION.

Revised PL Note:

THIS DATASET HAS BEEN INTEGRATED WITH DWG123ABC CAGE: 98752, SEE 123ABC CAGE: 98752 REV: E FOR INTEGRATED DEFINITION.

Existing TDPs:

Model: 123ABC-3D CAGE: 98752 Rev: H BoM: 123ABC CAGE: 98752 Rev: W Revised TDPs and Integrated MTDP:

Model: 123ABC-3D CAGE: 98752 Rev: J BoM: 123ABC CAGE: 98752 Rev: Y MTDP: 123ABC CAGE: 98752 Rev: AA Revised Model Note:

THIS DATASET HAS BEEN INTEGRATED WITH BOM 123ABC CAGE: 98752, SEE 123ABC CAGE: 98752 REV: AA FOR INTEGRATED DEFINITION.

Revised BoM Note:

THIS DATASET HAS BEEN INTEGRATED WITH 123ABC-3D CAGE: 98752, SEE 123ABC CAGE: 98752 REV: AA FOR INTEGRATED DEFINITION.

4.3.1.6 Applied items and non-geometric models. Applied items, also called bulk items, are items that are applied to parts and/or assemblies, rather than installed. Applied items usually exist in a non-solid form that may or may not cure to a solid after application. Common examples of applied items include lubricants, adhesives, and coatings. Due to their inherit nature and/or method of application, geometry may not be applicable when modeling such items. When geometry is not applicable, a native 3D model with no geometry (non-geometric) shall be created for the subject item, unless otherwise directed by the Government. Also, with the exception of 3D iPDFs, neutral files shall not be created from non-geometric native 3D models, unless otherwise directed by the Government.

4.3.1.7 Multiple configurations. Items with multiple configurations, often called part families or tabulated parts, are groups of items with common properties and features that differ across variations of a given item. Examples of common differences between part family members are: variations in color/material, inclusion/omission of simple features and/or subcomponents, variations in size of common features, and mirrored geometry. Part families consist of a parent and children, where the parent serves as the generic, and each child represents a configuration. All family members are defined in the same document/dataset and share a base PIN. For example, if parent part ABCDEF has two children: ABCDEF-1 and ABCDEF-2, ABCDEF is the generic, ABCDEF-1 and ABCDEF-2 are the configurations, and “ABCDEF” is the base PIN. Part family members are not separately revisable from one another.

Only one native 3D model file shall be created for a given part family, and the customary tools/procedures corresponding to the respective native CAD software shall be utilized to create all family members within the same file. The appropriate PIN and differentiating properties shall be applied to the parent and each respective child in the native 3D Model. If the parent is not a producible item, then it shall not have a PIN. Children shall not be created from existing children within a native 3D model, often called multilevel or generational families. Part families modeled as described above are still considered mono-detailed and are similar to tabulated mono-detail drawings described in ASME Y14.24.

4.3.1.7.1 Multi-detail and inseparable assemblies. Items that are not similar in geometry and product structure shall not be modeled as a family. Children shall also not be used as a subcomponent of their parent or siblings within a native 3D model. Consequently, when converting an existing TDP that defines multiple items (e.g. multi-detail drawing, inseparable assembly drawing, etc.) to an MTDP, it may be necessary to create separate MTDPs for the individual items defined in the existing TDP. In such cases, the PIN of an item requiring a separate MTDP shall serve as the new MTDP’s Document Number. New separate MTDPs shall also have the same Original Design Activity (ODA) as their existing TDP. The existing TDP shall be updated to avoid conflict with the content of the new separate MTDP(s) (e.g. removal of technical content that is now present in the new MTDP, changing basic dimensions that are now present in the new MTDP to reference dimensions, etc.).

4.3.1.8 Reference models. 3D models that do not serve as the official definition of a subject item are called “reference models”. Reference models shall be created for items when an official 3D model: cannot be obtained from the subject item’s CDA, does not exist and cannot be created by the modeling/procuring organization, or cannot be accurately used in the required context. Reference models are separately revisable from the data that officially defines the respective item, and are most commonly needed for: items defined by industry or military standards, commercial-off-the-shelf (COTS) items, items that must be modeled with different geometry/properties for use in a specific context (e.g. assemblies, contracts, etc.), and subcomponents that do not have assigned PINs and are only defined at the assembly level. Reference models shall accurately depict items to the level of detail needed for the required context(s) and shall be devoid of notes that communicate technical information. Reference models shall not be annotated, and only views one through four defined in 4.3.1.4 are required. All requirements in 4.3.1.3 shall also apply. Derived neutral files shall not be created from reference models.

All reference models shall have the following note, referencing the article(s) that serves as the official definition for the subject item: “REFERENCE MODEL: SEE <REFERENCE> FOR OFFICAL DEFINITION OF THE SUBJECT ITEM.”, where <REFERENCE> is the identification number(s) of the referenced article(s).

Examples:

REFERENCE MODEL: SEE NASM39086 FOR OFFICAL DEFINITION OF THE SUBJECT ITEM.

REFERENCE MODEL: SEE 201646960 CAGE: 98752 FOR OFFICAL DEFINITION OF THE SUBJECT ITEM.

REFERENCE MODEL: SEE 201646968 CAGE: 98752 AND 201646968PL CAGE: 98752 FOR OFFICAL DEFINITION OF THE SUBJECT ITEM.

REFERENCE MODEL: SEE ASME Y14.41-2012 FOR OFFICAL DEFINITION OF THE SUBJECT ITEM.

Reference models shall be uniquely identifiable by combining the following metadata fields:

PIN | ODA_CAGE | MDA_CAGE | CONTEXT_ID | INSTANCE_PREFIX

When a PIN is not applicable for a given reference model and would normally be left blank, the PIN shall be populated with the same value as the DOCUMENT_NUMBER. Below are examples for correctly populating these fields for reference models created by the USAF for PIN: MS20995C20; a wire defined by industry standard NASM20995.

Reference model with multiple configurations:

Generic:

NASM20995 | 80205 | 98752

Configurations:

MS20995C20 | 80205 | 98752

MS20995C32 | 80205 | 98752

Reference model for wire with different geometry/properties for use in PIN: 201646968 CAGE: 98752 (The Original Design Activity (ODA) CAGE code can be added to the end of PINs in the CONTEXT_ID field, separated by an underscore, to differentiate reference models made for separate assemblies, where the assemblies happen to have the same PIN. However, this is an extremely rare occurrence and is usually unnecessary.):

MS20995C20 | 80205 | 98752 | 201646968

MS20995C20 | 80205 | 98752 | 201646968_98752

MS20995C20 | 80205 | 98752 | 201646968_19200

Multiple reference models for same wire with different geometry/properties for use in PIN: 201646968 CAGE: 98752:

MS20995C20 | 80205 | 98752 | 201646968 | AFT

MS20995C20 | 80205 | 98752 | 201646968 | FORWARD

MS20995C20 | 80205 | 98752 | 201646968 | 1ST

MS20995C20 | 80205 | 98752 | 201646968 | 2ND

MS20995C20 | 80205 | 98752 | 201646968 | 1

MS20995C20 | 80205 | 98752 | 201646968 | 2

MS20995C20 | 80205 | 98752 | 201646968 | A

MS20995C20 | 80205 | 98752 | 201646968 | B

4.3.1.9 3D Intelligent PDFs (3D iPDFs) 3D iPDFs shall be created from all native 3D models, excluding reference models. With the exception of elements intrinsic to the 3D iPDF (i.e. title block, logo, headings, frame, etc.), all content represented in the 3D iPDF shall be derived from and match the content of the corresponding native 3D model. All 3D iPDF content shall be digitally text searchable to the fullest extent possible. The Contractor shall utilize the latest USAF 3D iPDF template and Anark software to create3D iPDF. The USAF 3D iPDF template shall not be modified unless otherwise directed by the Government. The Contractor shall also provide all supporting files (e.g. Anark recipes) and documentation necessary to convert the delivered native 3D models to the delivered3D iPDF. The supporting files and documentation shall be provided to the Government with unlimited rights.

4.3.1.10 File names.

4.3.1.10.1 USAF native files. All native files under the design control of the USAF that are not reference models or format/template files, shall follow the standard naming convention:

Document Number_ODA CAGE_Title.xxx

Example:

201646968_98752_USAF LOGO.asm

4.3.1.10.2 Reference model files. All reference model files shall follow the standard naming convention:

PIN_ODA CAGE_MDA CAGE_Context ID_Instance Prefix_Title.xxx

Examples:

MS20995C20_80205_98752_201646968_AFT_WIRE.prt

MS20995C20_80205_98752_WIRE.prt

If a field is not applicable, then it shall be left blank and extra separators removed, as shown in the second example above. If filename size restrictions prevent population of all fields, then the following actions shall be taken in the order presented until an acceptable filename is created:

1.

Abbreviate/Shorten Title

2.

Remove Title

3.

Remove MDA CAGE

4.

Remove ODA CAGE

5.

Shorten Instance Prefix

6.

Shorten Context ID

If these actions still result in an invalid filename, the modeling organization shall contact the Government for direction on how to name the file.

4.3.1.10.3 Derived neutral files. All filenames for derived neutral files shall match their corresponding native file’s name, but shall also include the Revision ID before the Title:

Document Number/PIN_ODA CAGE_Revision ID_Title.xxx

Examples:

201646968_98752_-_USAF LOGO.stp

201646968_98752_A_USAF LOGO.stl

201646968-2_98752_A_USAF LOGO.igs

201646968_98752_B.pdf

However, if a neutral file is created from a native file for a single child in a part family, as described in 4.3.1.7, then the PIN shall be used instead of the Document Number for the first field, as shown in the third example above. The Title shall be abbreviated/eliminated as needed to satisfy file name length restrictions, as shown in the fourth example above.

4.3.1.10.4 Other files. The naming convention used for files not under the design control of the USAF shall be at the discretion of the current design activity, subject to the approval of the Government. However, all native CAD files that define items shall include the Document Number/PIN, filenames for derived neutral files shall include the Document Number/PIN and Revision ID, and filenames for format/template files shall include the ODA CAGE code assigned to the respective file. All filenames shall be unique with respect to the ODA.

4.3.1.11 Metadata. The following table lists metadata fields that shall be present within all native 3D models.

TABLE III. Metadata Fields

Name
Type
Format/Values
Description
USAF_TEAMCENTER_ITEM_TYPE
String
CAD Template

Master Part

Reference Model

TDP Document The item type of the dataset in the USAF’s Teamcenter system.

PIN
String
All Uppercase
Part or Identifying Number (See ASME Y14.100).
DOCUMENT_NUMBER
String
All Uppercase
Drawing/Document Number (See Y14.100) or Dataset ID (See ASME Y14.41).
DOCUMENT_TYPE
String
3D Model
Always "3D Model".
ODA_CAGE_CODE
String
Five characters

All uppercase CAGE code of the original design activity.

ODA_NAME
String

Name of the original design activity.

ODA_ADDRESS
String

Address of the original design activity.

TITLE
String
All Uppercase
Drawing/Dataset title (See ASME Y14.100 and ASME Y14.41)
CDA_CAGE_CODE
String
Five characters

All uppercase CAGE code of the current design activity.

CDA_NAME
String

Name of the current design activity.

CDA_ADDRESS
String

Address of the current design activity.

MDA_CAGE_CODE
String
Five characters

All uppercase CAGE code of the reference model’s original design activity.

CONTEXT_ID
String
All Uppercase
ID of the context the reference model was specifically created for (e.g. contract number, next higher assembly PIN, etc.).
INSTANCE_PREFIX
String
All Uppercase
ID needed to differentiate reference models of the same item created for the same context.
REVISION_ID
String
All Uppercase
ID of the revision (e.g. -, A, MZ, 1, 3.2, 1A, B4, etc.)
REVISION_DATE
String/

Date

ISO 8601 extended format
Date of the revision.
REVISION_DESCRIPTION
String

Description of what changed in the revision compared to the previous revision.

REVISION_APPROVAL
String

Name of the person who approved the revision.

SECURITY_LEVEL
String
Confidential

Secret

Top Secret

Unclassified Security level of the dataset.

DATA_RIGHTS
String
Government Purpose

Limited

Negotiated

Unlimited The data rights the government has to the dataset.

DISTRIBUTION_CODE
String
A

B

C

D

E

F The distribution code assigned to the dataset.

EXPORT_CONTROLLED
Boolean

Indicates whether or not the dataset has an export control notice.

FOREIGN_SECURE
Boolean

Indicates whether or not the export control notice contains an ITAR or EAR statement?

CONTRACT_NUMBER
String
All Uppercase
Contract Number that the dataset was created under.
CONTROL_MARKING
String
All Uppercase
Control drawing/model type (e.g. vendor item control, source control, etc.) (See ASME Y14.24).
CRITICAL_SAFETY_ITEM
Boolean

Indicates whether or not the dataset depicts a critical safety item (See ASME Y14.100).

CRITICAL_SAFETY_PROCESS
Boolean

Indicates whether or not the dataset depicts a critical safety process (See Y14.100).

ELECTROSTATIC_SENSITIVE_DEVICE
Boolean

Indicates whether or not the dataset depicts an electrostatic sensitive device (See ASME Y14.100).

ENVIRONMENTAL_IMPACT
Boolean

Indicates whether or not the dataset depicts an entity with adverse environmental impact (See ASME Y14.100).

ENVIRONMENTAL_STRESS_SCREENING
Boolean

Indicates whether or not the dataset depicts an item that requires environmental stress screening (See ASME Y14.100).

HARDNESS_CRITICAL_ITEM
Boolean

Indicates whether or not the dataset depicts a hardness critical item (See ASME Y14.100).

HARDNESS_CRITICAL_PROCESS
Boolean

Indicates whether or not the dataset depicts a hardness critical process (See ASME Y14.100).

HAZARDOUS
Boolean

Indicates whether or not the dataset depicts a hazardous entity (See ASME Y14.100).

INTERFACE_CONTROL
Boolean

Indicates whether or not the dataset defines or controls an interface to a system (See ASME Y14.100).

OBSERVABLE_CRITICAL_ITEM
Boolean

Indicates whether or not the dataset depicts an observable critical item (See ASME Y14.100).

OBSERVABLE_CRITICAL_PROCESS
Boolean

Indicates whether or not the dataset depicts an observable critical process (See ASME Y14.100).

OZONE-DEPLETING CHEMICAL
Boolean

Indicates whether or not the dataset depicts an ozone-depleting chemical (See ASME Y14.100).

OZONE-DEPLETING SUBSTANCE
Boolean

Indicates whether or not the dataset depicts an ozone-depleting substance (See ASME Y14.100).

MODELED_NAME
String

Name of modeler.

MODELED_DATE
String/

Date

ISO 8601 extended format
Date modeler approved dataset.
CHECKED_NAME
String

Name of checker.

CHECKED_DATE
String/

Date

ISO 8601 extended format
Date checker approved dataset.
ENGINEERING_NAME
String

Name of engineering reviewer.

ENGINEERING_DATE
String/

Date

ISO 8601 extended format
Date engineering reviewer approved dataset.
MANUFACTURING_NAME
String

Name of manufacturing reviewer.

MANUFACTURING_DATE
String/

Date

ISO 8601 extended format
Date manufacturing reviewer approved dataset.
CORROSION_NAME
String

Name of corrosion reviewer.

CORROSION_DATE
String/

Date

ISO 8601 extended format
Date corrosion reviewer approved dataset.
SUPPLY_CHAIN_NAME
String

Name of supply chain reviewer.

SUPPLY_CHAIN_DATE
String/

Date

ISO 8601 extended format
Date supply chain reviewer approved dataset.
QUALITY_NAME
String

Name of quality reviewer.

QUALITY_DATE
String/

Date

ISO 8601 extended format
Date quality reviewer approved dataset.
APPROVED_NAME
String

Name of approver.

APPROVED_DATE
String/

Date

ISO 8601 extended format
Date approver approved dataset.
USAF_AUTHENTICATION_NAME
String

Name of USAF authenticator.

USAF_AUTHENTICATION_DATE
String/

Date

ISO 8601 extended format
Date USAF authenticator approved dataset.
USAF_RELEASE_NAME
String

Name of USAF release authority.

USAF_RELEASE_DATE
String/

Date

ISO 8601 extended format
Date USAF release authority approved and released dataset.
REFERENCE_*
String
All Uppercase
ID of any article referenced in the dataset. (When more than one reference is used, append “_*” to the name where a number or letter is substituted for “*”.)
REFERENCE_*_CAGE
String
Five characters

All uppercase CAGE code of the original design activity of a corresponding reference. (Leave blank if not applicable for a given reference.)

UDF_USAF_CDA
Boolean

Indicates whether or not the USAF is the current design activity.

UDF_ACCURATE_MODEL_TREE
Boolean

Indicates whether or not the model tree of an assembly model accurately depicts the assembly’s product structure (e.g. parts list or bill of materials).

4.3.2 Verification and validation. All models generated from existing 2D drawings shall be validated through a line check comparison conducted between the original drawing and the new model’s axonometric and/or orthographic views unless otherwise directed by the Government. A static interference analysis shall be accomplished at each assembly level to ensure no dimensional interferences occur. A functional interference analysis shall also be accomplished at each assembly level as directed by the Government to ensure no dimensional interferences occur. In addition, one of the following options shall be pursued for final verification of the MTDP at the discretion of the Government:

a. Reverse First Article - the new MTDP shall be used to dimensionally check existing parts made to the previous TDP. All discrepancies shall be identified and resolved.

b. New Production to Previous Drawing Check - the new MTDP shall be used to create a new part and checked against the previous TDP.

c. New Production to Functional Check - the new MTDP shall be used to create a new part which shall be substituted into an existing system for a functional and/or live fire check out.

d. Rapid Prototyping - the new MTDP shall be used to create a rapid prototype of the new part and compared dimensionally or through a functional check to an existing part.

As MTDPs are created and problems are found that prevent the MTDPs from conforming to the exact requirements of the original drawing, each issue and resolution shall be documented and reported to the Government. MTDPs shall not be accepted until they have been reviewed and approved by the Government for compliance with the requirements of this PWS and DI-SESS-81000E/T.

4.3.3 Engineering data Guidance Conference. The Contractor shall support and co-chair a Guidance Conference with AFLCMC/LZPEM for engineering data within 60 days after contract award. The Conference shall be convened at a site and on a date agreed upon by the Government Contracting Officer and the Contractor. The Contractor shall prepare an agenda and record the minutes of the Guidance Conference. The Contractor shall address, discuss, and provide status on the following:

a. Understanding of all CDRL requirements, applicable DIDs, specifications and standards.

b. TDP review requirements and schedules.

c. TDP delivery requirements and schedules.

d. Contractor's drafting practices/procedures/TDP drawing formats/CAD programs.

e. The Contractor's quality assurance procedures relating to TDP documents, including quality control of subcontractor and vendor data.

f. The role of subcontractors and vendors who may deliver TDP documents under this contract.

g. The Contractor's configuration management system, including methods for releasing documents, approving documents, and incorporating changes into documents.

h. Digital Technical Data Package (TDP) deliverables.

Note: Guidance Conference may be held in conjunction with other meetings or conferences. (A002 DI-ADMN-81249B, Conference Agenda; A003 DI-ADMN-81250B, Conference Minutes)

4.3.4 In-process review (IPR) of the TDP. The Contractor shall host, support, and co-chair an IPR of the engineering drawings and associated lists and other documentation to be included in the TDP. The IPR shall be conducted only after the Contractor's quality assurance personnel have completely reviewed the data and determined that data are of sufficient quality that Government time will be effectively utilized during the review. IPR may be scheduled when data has reached the 50% percent completion point and shall be held, when possible, in conjunction with other reviews (i.e., PDR, CDR). Concurrent with the IPR, the Contractor shall submit four (4) representative samples of each digital data format of data for this project in accordance with Air Force drawing 9579776 (CAGE 98752); these shall consist of the Native, Neutral, Word Searchable PDF, HPGL, Metadata Spreadsheet, BOM, Gerber Data, and Software/memory Device Data. Additionally, the Contractor shall submit sample solid modeling data in SolidWorks 2017 and a fully annotated 3D iPDF derived from the solid model with an embedded .stp file also derived from the solid model. The Contractor shall notify AFLCMC/LZPEM a minimum of 30 days prior to the anticipated date of completion point. The IPR shall focus on the Contractor's progress in the preparation of the TDP. The Contractor shall support and provide the necessary resources, i.e., meeting agenda, conference room, applicable data, minutes, and appropriate personnel available to answer any questions to perform the IPR effectively. The Contractor shall correct all discrepancies identified in the IPR. All subcontractor/vendor data shall be made available for review. If the quantity of subcontractor/vendor data is of sufficient magnitude, the Government may schedule a separate IPR at the subcontractor's/vendor's facility. (A004, DI‑ADMN‑81249B, Conference Agenda; A005, DI‑ADMN‑81250B Conference Minutes)

4.3.5 Relationship of the Contractor with subcontractors and vendors. The Contractor shall levy on sub-contractors and sub-vendors the same requirements for TDPs as levied on them by the basic contract and any task order. This requirement shall apply at all tiers of sub-contractor/vendor levels associated with the program.

4.3.6 Engineering data updates and revisions. The Contractor shall (and shall cause subcontractors and vendors to) update and maintain engineering data for the item(s) designed/developed/modified/produced and funded by task orders for the life of the basic contract and task orders and shall incorporate all changes in accordance with the following:

a. All engineering changes shall be incorporated into the applicable engineering data within 90 days after engineering release/Air Force concurrence or at intervals of five changes, whichever occurs first, except a change involving safety, which shall be incorporated immediately.

b. All engineering changes shall be incorporated into the applicable engineering data prior to delivery of data for review.

c. All engineering changes shall be incorporated into the applicable engineering data prior to delivery of final media.

d. Revisions to existing engineering drawings/models and associated lists and other documentation to be included in the TDP for which the Contractor is the current design activity shall result in the delivery of the entire revised document and associated data file. For example, when a portion of a document is revised the entire document shall be delivered.

4.4 Reverse engineering. Upon Government request, the Contractor shall reverse engineer an item, items or subsystems, duplicating the equipment both functionally and dimensionally, by physically examining and measuring existing equipment and/or parts. The Contractor shall develop comprehensive technical data (physical, mechanical, material characteristics, etc.) for the purpose of Government competitive procurement. The Government shall own the data delivered or data/equipment resulting from this effort (unlimited data rights). The delivered product level TDP(s) shall meet all requirements specified in this PWS (see 4.3). The final configuration shall meet or exceed the operational requirements of the original design. (A006, DI-MISC-80508B, Technical Report – Study/Services; A007, DI-MGMT-80894A, Source/Vendor List)

4.4.1 Producibility study. The Contractor shall conduct a producibility study that shall include, but is not limited to, the following:

a. Order of product assembly and disassembly drawings, instructions, special tools required, and inspection procedures.

b. The materials specified shall be reviewed…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it.