OMFV_Draft_RFP_W56HZV-22-R-0026_15APR.docx

OMFV Draft RFP W56HZV-22-R-0026

OMFV DRAFT REQUEST FOR PROPOSAL

Detailed Design (Phase 3) and Prototype Build and Test (Phase 4)

APRIL 15, 2022

PM MCS

Detroit Arsenal, MI

CU

Distribution Statement A: Approved for public release; distribution is unlimited

TABLE OF CONTENTS

SECTION a: executive summary section b: supplies and price cost section c: Statement of Work

section d: packaging and markings section e: inspection and acceptance section f: deliveries section g: contract administration data section h: special contracting requirements section i: clauses section j: list of attachments section l: instructions, conditions, and notices to offerors section m: evaluation for award

Optionally Manned Fighting Vehicle (OMFV) Executive Summary

SECTION A Executive Summary

OMFV Program Vision The Optionally Manned Fighting Vehicle (OMFV) will serve as the Army's Infantry Fighting Vehicle (IFV) tasked to maneuver through the enemy's security zone as part of a combined arms team for the purpose of creating an advantageous position, relative to the enemy, and providing protection and direct fire lethality while manned or remotely operated. In the close fight, the OMFV enables the ability of dismounted elements to maneuver by detecting and destroying targets at a range beyond the enemy's capability.

Transformational Elements The OMFV will transform how Soldiers and squads accomplish their mission in the following ways.

Enable Command and Control The OMFV will enable command and control at the platoon level and higher by rapidly generating, receiving, and passing information to dismounted elements, other vehicles, and command nodes.

Provide Decisive Lethality The OMFV will be able to detect, engage, and destroy enemy infantry fighting vehicles beyond the range of the enemy's primary weapon system, and rapidly defeat dismounted enemy threats. The OMFV will also enhance formation lethality by providing target acquisition data, shared situational understanding, and the lethal effects required to protect and orient the dismounted element.

Enhance Organizational Effectiveness The OMFV will improve organizational effectiveness by reducing the logistics burden on the ABCT. This will be achieved through enhanced reliability and on-board diagnostics and prognostics; ease of maintenance with the use of standard, common tools; and reduced burdens on the supply chain in terms of spare parts, fuel, and munitions.

Ability to Rapidly Adapt The OMFV will be constructed to allow rapid adaptation by possessing Growth margins that allow for the insertion and integration of future technologies, and by the adoption of a modern acquisition approach.

Designed from the beginning as a Modular Open Systems Architected (MOSA) platform based on an Army-defined and owned open standard, OMFV will provide the Army an affordable pathway to OEM-independent upgrades at the sub-system level. As technology and software evolves the Army’s open architecture standard allows the OMFV to modernize rapidly at a reduced cost. The open architected OMFV will also offer more opportunities for industry competition and innovation.

OMFV is also the U.S. Army’s first ground combat vehicle designed using modern digital engineering tools and techniques. A true models-based program, OMFV contractors will create an Authoritative Source of Truth (ASOT) in the digital domain and thread digital requirements, design, logistics products, modeling and simulation, and manufacturing tools and processes into the ASOT.

This digital approach to delivering OMFV creates a situation where the Army can affordably upgrade at the pace of technological advancement, and reduce the risk posed by strategic unpredictability with respects to the level of capability OMFVs provide the ABCTs.

Program Overview

Fundamentals The Army is conducting a five (5) phased acquisition approach to design, prototype, test, and produce the OMFV.

Technical performance is critical for the success of OMFV. Additionally, the USG must be able to rapidly adapt to changes in threats and integrate new technology. The OMFV program is using a Models Based Systems Engineering (MBSE) approach to manage the complexity of the current environment. Full adoption of a Modular Open Systems Approach (MOSA), Agile software development using the DevSecOps framework, and adoption of modern digital engineering principles ensures the OMFV platform will pace the threat without extensive, costly, and time-consuming redesigns.

OMFV is the lead Army ground combat vehicle program for implementation of a common MOSA architecture and use of digital engineering principles. Intellectual Property license rights needed for MOSA and other USG purposes will be pursued. OMFV Phase 2 provided the basis for these principles.

Phase 3: Detailed Design and Phase 4: Prototype Build and Test The purpose of Phase 3 is to conduct detailed design activities to mature the OMFV designs and will culminate in a critical design review (CDR). Immediately following Phase 3 is Phase 4, Prototype Build and Test. The purpose of Phase 4 is to verify performance against the performance specification. Late in this phase, a Limited User Test will be conducted. In addition to the delivery of prototypes, the contractor will develop, mature, and deliver a digital twin of their design. These phases will be a single contract with up to 3 contracts awarded (additional details below).

Phase 5: Production and Fielding The purpose of this phase is to have a single LRIP contract for production, testing and initial fielding. Activities include Pre-Production Quality Testing (PQT) and Initial Operational Testing and Evaluation (IOT&E). This single contract is planned to be awarded from a competition limited to the Phase 3/4 contractors. The USG is finalizing the criteria to select the LRIP contract, but are currently exploring performance, MOSA compliance, IP rights provided, AUMC, end to end digital thread, and manufacturability. These will be further expanded on in the final Phase 3/4 RFP. The Government intends to require follow-on production of the OMFV to occur in the United States (US).

OMFV Phase 3/4 Solicitation and Contract Offerors should review this draft information carefully and provide any recommendations or concerns for the Army to consider in finalizing the RFP.

The RFP requires 12 prototype vehicles, as well as an early risk reduction prototype, two Ballistic Hulls and Turrets, Armor Coupons, ballast kits, digital twins, and data. Some data will be treated differently as part of the digital environment as per Section C.

A GFP/GFI list is included, however GFI, in addition to that included in this draft, will not be provided until contract award.

The OMFV Phase 3/4 RFP is a Full and Open Competition. The Army intends to award up to three firm-fixed price contracts with a 54 month period of performance. Formal source selection procedures will be used. See Sections L and M for information required to be submitted in proposals and evaluation of proposals. VATEP will be utilized as part of the overall Price evaluation.

The Gov’t is considering including an Economic Price Adjustment provision for prototype material in the final OMFV Phase 3 and 4 RFP. Request potential offerors provide comments and recommendations on the desirability of such a provision – i.e. whether or not one should be included – with rationale. If so, please i) provide your planned prototype material cost percentage for each year of contract performance and ii) your recommendations on the specifics of such a provision including (with rationale for each):

· What material should be included or excluded

· What method of adjustment should be used

· What index or indices should apply to which material (if index method)

· What cost data the gov’t should require to establish a base for adjustment

· Whether the prototypes (or their material) be separately CLINed/priced

· Whether the EPA provision should be extended to subcontractors. If so, what criteria should apply to eligibility?

· Any potential issues with other impacts to material prices such as supplier labor costs or exchange rate changes

· What should be included to insure that all offerors are competing on an equal basis?

· Any other specific recommendations

Solicitation This solicitation is for the Detailed Design, Prototype, Build and Test (Phases 3 and 4), and is solicited on a Firm-Fixed-Price basis.

Offeror shall submit proposals in six separate volumes in accordance with (IAW) Section L no later than (NLT) 12:00pm local time on TBD.

Information in this solicitation takes precedence over any information shared by the Government preceding the solicitation release, including but not limited to, information shared at Industry Day, one-on-one sessions, draft solicitation, or through Q&As released to date.

Assertion of Restrictions: The Offeror shall include in its proposal submission, its Assertion of Restrictions Attachment 0012 (Technical Data and Assertions). Additionally, any proposed special license(s) shall follow the format prescribed within Attachment 0013 (Special License Requirements).

Availability of Funding and Affordability: Contract award(s) will be made subject to the availability of funding. Affordability is addressed at M.3.1.

Phase 3/4 Proposal Evaluation The Government will conduct a full and open competition using Best Value Source Selection procedures for the award of up to three contracts during third quarter of Fiscal Year (FY) 23. The Government reserves the right to make less than three awards if the value of additional awards up to three would offer only limited benefit (See M.1.1).

Administrative Eligibility requirements for award and Rejection Criteria are included in the solicitation. Offerors should carefully review the solicitation to ensure all requirements for award are met.

Access to Classified, Controlled Unclassified Information (CUI), and Export Controlled Documents: All Offerors must have a valid minimum FCL including safeguarding at SECRET level in order to respond to this solicitation. See the Department of Defense (DD) Form 254 (Attachment 72) for security requirements. For Export Controlled information, it is the responsibility of the Offeror, not the Government, to obtain the appropriate export licenses, or process the appropriate export license exemption, necessary for authorization to share information with foreign vendors. Offerors who have not had prior access to CUI attachments shall send their request to the general mailbox identified below. Your request shall include the following:

i. Your Company's name and address

ii. Your Name, Title, Office phone number and email address

iii. Copy of the approved DD Form 2345

Points of Contact (POCs):

Michael Chaney, Procuring Contracting Officer 586-282-5057 usarmy.detroit.peo-gcs.mbx.ngcv-omfv-contracting@mail.mil

Joe Felice, Contract Specialist 586-282-9450 usarmy.detroit.peo-gcs.mbx.ngcv-omfv-contracting@mail.mil

James Giacchina, Contract Specialist 586-282-4131 usarmy.detroit.peo-gcs.mbx.ngcv-omfv-contracting@mail.mil

Army Contracting Command—Warren (DTA) Ombudsperson Information regarding the Ombudsperson for this contract is located at the following website: http://acc.army.mil/contractingcenters/acc-wrn/CompMgmtOffice.html

Public Activity Involvement Subcontract opportunities under this solicitation and any resulting contracts are open to competition between Department of Defense activities and private firms. In addition, Army Industrial Facilities are available to sell manufactured articles or to perform work at such Facilities on behalf of Offerors, in certain circumstances and as permitted by law. Rock Island Arsenal, Waterlivet Arsenal, Anniston Army Depot, Sierra Army Depot, or Red River Army Depot have expressed interest in securing subcontracting opportunities under this RFP. For information related to the capabilities of these facilities visit the following links: http://www.amc.army.mil/Portals/9/Documents/AMC%20Publications/AMC%20P3Contact%20Information.pdf?ver=2017-09-18-073343-597 http://www.amc.army.mil/Portals/9/Documents/AMC%20Publications/AMC_0817_RESOURCE-GUIDE.pdf?ver=2017-10-03-110207-990

Acknowledgement of Amendments Acknowledge all the amendments received from the Government by identifying the amendment number and its issue date in the box below:

Amendment Number: Date:

Electronic Contracting All Army Contracting Command – Detroit Arsenal solicitations will be publicized on the System for Award Management website (https://www.sam.gov). Any additional attachments, including Technical Data Packages (TDPs) when available electronically, will be separate attachments or links embedded in the solicitation.

Pay close attention to the Issued By block location on the cover page of the solicitation for closing date and time. The closing date and time is based on the local time of the listed location of the Issued By office. In accordance with FAR 15.208(a), offerors are responsible for submitting proposals, and any revisions, and modifications, so as to be received by the Government office designated in the solicitation by the time specified.

It is the responsibility of the Offeror to ensure the proposal/quote is received by the date and time specified on the cover page of this solicitation. In accordance with FAR 15.208, if the proposal/quote was not received at the initial point of entry to the Government infrastructure by the exact date and time specified on the cover page of this solicitation, it will be determined late. Proposal/quote is defined to mean ALL volumes or parts required in the solicitation are included in the submission.

Questions pertaining to this solicitation should be directed to the Contract Specialist identified on the cover page of this solicitation. For technical assistance in doing business with the Government, and doing business electronically, please visit the Procurement Technical Assistance Center (PTAC) website at http://www.aptac-us.org/ to locate a regional center.

SECTION B Supplies and Price Cost

Incremental Funding

CLIN 0001

The Government will provide funds under CLIN 0001 on an incremental basis IAW Defense Acquisition Regulation Supplement (DFARS) 252.232-7007. The anticipated Incremental Funding Schedule is provided in Section B.1.2. It is estimated that the amounts shown are sufficient for the performance of the work in each of the cited funding periods.

The following is the Incremental Funding Schedule for the CLIN 0001:

*To be Proposed by the Contractor. Not to Exceed the amounts stated in M.3.1.

SECTION C Statement of Work

Introduction This contract is for the Detailed Design and Prototype Build and Test of the Optionally Manned Fighting Vehicle (OMFV). The United States Government (USG) is implementing a digital acquisition. The digital approach is intended to significantly streamline the standalone documents delivered by the Contractor, while providing the USG unparalleled insight to the design, with the goal of reducing overall programmatic risk.

The USG has implemented an objective architecture to better communicate the requirements of the OMFV system in a clear and concise manner. The OMFV program is requiring Contractors to establish an Authoritative Source of Truth (ASoT) and provide regular updates of the data to the USG.

Additionally, the contract requires use of Modular Open Systems Architecture (MOSA), DevSecOps software development and the Ground Combat Systems Common Infrastructure Architecture (GCIA) to enable the USG to quickly upgrade the OMFV in the future.

OMFV Requirements The Contractor shall comply with the requirements within Attachment 0008 (OMFV Objective Architecture) and Attachment 0029 (Classified Specification) in the design of the OMFV.

Systems Engineering

OMFV System Architecture Model The Contractor shall develop an integrated System Architecture Model for the OMFV IAW CDRL E041 and Attachment 0091 (One-time DID Digital System Model).

The OMFV System Architecture Model (CDRL E041) shall decompose and derive the Attachment 0008 (OMFV Objective Architecture) into the requirements, functional, logical, and physical architectural elements that satisfy the USG’s PSPEC IAW Attachment 0008 (OMFV Objective Architecture) and Attachment 0091 (Digital System Model).

The Contractor shall establish and maintain bi-directional traceability between the OMFV System Architecture Model (CDRL E041) and the Attachment 0008 (OMFV Objective Architecture); including requirements, functional, logical, and physical architecture elements to the lowest level component in the Contractor’s Bill of Materials.

Specification Tree The Contractor shall develop, maintain, and deliver a Specification Tree that defines the hierarchical and inter-relationship of the specifications that fully represent the functional and non-functional requirements of the OMFV system, including Attachment 0008 (OMFV Objective Architecture) and Contractor specifications (SSS, SRS, IRS, etc.), IAW CDRL E083.

System / Sub-system Specifications (SSS) The Contractor shall develop, maintain, and deliver the System/Sub-system Specifications for the OMFV IAW CDRL E081 which are identified in the Specification Tree (CDRL E083).

System / Sub-system Design Descriptions (S/SDD) The Contractor shall develop, maintain, and deliver the System/Sub-system Design Descriptions (S/SDD) for the OMFV IAW CDRL E082 for systems and sub-systems identified in the Specification Tree (CDRL E083).

Requirements Traceability Verification Matrix The Contractor shall deliver a Requirements Traceability Verification Matrix (RTVM) IAW CDRL E077 which show the full bi-directional traceability and verification across the requirements contained in the Specification Tree (CDRL E083).

Digital Twin Capabilities Throughout the life of the program, the Contractor shall develop and mature a digital twin of their design. The contractor shall develop the digital twin maturation plan IAW CDRL E004 and Attachment 0098 (OMFV Digital Twin Maturation Pathway).

Capability Twin The contractor shall develop a Capability Twin focused on high fidelity sub-system designs needed to conduct sub-system MS&A. The Capability Twin shall have bi-directional connection from the System Architecture Model (E041) to the developmental TDP within the USG Digital Acquisition Environment. The contractor shall deliver the capability twin IAW CDRL E026 and Attachment 0098 (OMFV Digital Twin Maturation Pathway).

Product Twin The contractor shall develop a Product Twin, by maturing the Capability Twin, which accurately models interactions between sub-systems within the complete system. The Product Twin shall be able to completely model the capabilities within the risk reduction prototype, and bi-directional connection from the System Architecture Model to the Product level TDP within the USG Digital Acquisition Environment. The contractor shall deliver the capability twin IAW CDRL E026 and Attachment 0098 (OMFV Digital Twin Maturation Pathway).

Production Digital Twin The contractor shall develop a Production Digital Twin, by maturing the Capability Twin and Product Twin. The Production Digital Twin shall be able to replicate the physical testing during developmental test within the digital environment using physics based modeling, showing all interactions between sub-systems within the complete system. The Production Digital Twin shall be able to completely model the capabilities within the full system prototypes, and bi-directional connection from the SysML model to the TDP within the USG Digital Acquisition Environment. The contractor shall deliver the Production Digital Twin IAW CDRL E026 and Attachment 0098 (OMFV Digital Twin Maturation Pathway).

Technical Baseline and System Model Data Rights

For all OMFV system non-commercial Technical Baseline and System Model data and computer software developed exclusively at Government expense, the Contractor shall provide Unlimited Rights to the Government. This includes all system model data and computer software which supports the development, operation and sustainment, configuration management, maintenance, repair, overhaul, replacement of components and parts of the OMFV System as well as documented and digital data representations.

For all OMFV system commercial Technical Baseline and Systems Model data and computer software, the Contractor shall provide a license to the commercial Technical Baseline and Systems Model data.

The Government desires, at a minimum, Government Purpose Rights (GPR) rights to all Technical Baseline and Systems Model data and computer software.

The contractor shall ensure all data rights markings are captured in the System Model for all model elements.

Any Systems Model data or digital artifacts or computer software not included in the Assertion of Restrictions will be considered to be delivered with at minimum GPR for the System Model deliverables provided to the Government by the Contractor.

OMFV Digital Environments

USG Digital Acquisition Environment (DAE) The USG will host a DAE in order to manage the scope of this contract.

The Contractor shall acquire access to the DAE by submitting a Digital Access Point Request IAW Attachment 0006 (Digital Access Point). This access will serve as the connection between the DAE and the Contractor Integrated Digital Engineering Environment (IDEE).

The Contractor shall be responsible for ensuring all Contractor IDEE connections/trace links/etc. are maintained when transferred from the Contractor IDEE to the USG DAE.

Contractor Integrated Digital Engineering Environment (IDEE) The Contractor shall use the Contractor's IDEE to manage the engineering artifacts and models used to design and maintain the as-built system.

The Contractor shall deliver an IDEE Database Design Description (DDD) IAW CDRL E039.

The Contractor shall deliver an IDEE Software Version Description (SVD) IAW CDRL E038 to identify all versions of commercial computer software the offeror used to create the IDEE. The Contractor shall include any modifications the Contractor intends to make to those software applications to customize the IDEE for this contract.

The Contractor shall deliver the computer software source code in an IDEE Software Product Specification (SPS) IAW CDRL E037 for any modifications the Contractor shall make to any commercial computer software to create the IDEE.

The Contractor shall deliver a Data Accession List (DAL) IAW CDRL E040.

The Contractor shall deliver an IDEE Software User Manual IAW CDRL E027.

IDEE Environment Data Rights

Contractor’s Digital Environment – Noncommercial Software The contractor shall deliver any noncommercial computer software used to instantiate its integrated digital data environment. This includes the software applications that comprise the integrated digital/data environment, the MBSE/DE tools and API used to establish the digital thread, the software-authoring environment, the source code, the executable code and all software libraries.

The Government desires Government Purpose Rights (GPR), at a minimum, to the noncommercial computer software.

Modified Commercial Computer Software Applications The contractor shall deliver the licenses for all commercial items and/or COTS software applications. This includes the source code to any modifications the contractor may make to any commercial computer software, to include Digital Engineering tools and API, used to create the IDEE. Additionally, the contractor shall deliver the executable code to those commercial computer software applications.

The Government desires Government Purpose Rights (GPR) at a minimum to any modifications to commercial items and/or COTS software applications for the source code and the executable code to those commercial computer software applications.

Commercial Computer Software Applications The contractor shall deliver the licenses for all commercial items and/or COTS software applications for executable code to any commercial computer software, to include Digital Engineering tools and API.

0. IDEE Software Documentation The contractor shall deliver any noncommercial computer software documentation used to instantiate its integrated digital data environment to include the user manuals IAW CDRL E027 and the software and database installation instructions IAW CDRL E039.The Government desires Government Purpose Rights at a minimum to the noncommercial computer software documentation.

IDEE Software Version Description The contractor shall deliver a Software Version Description (SVD) that identifies all versions of commercial computer software the contractor shall use to create the IDEE, and all modifications the contractor shall make to those software applications to customize the IDEE for OMFV program. The Government desires Government Purpose Rights at a minimum.

IDEE Data Accession List The Government desires Government Purpose Rights at a minimum to all data listed on the Data Accession List (DAL).

The Contractor shall deliver IP rights to all preliminary data (e.g. draft/work-in-progress technical data), other information products and computer software equivalent to the IP rights the Government will receive to the final product on the DAL.

The contractor shall identify what IP rights it will grant to the government to all the data that will reside within the IDEE. The contractor shall map the IP rights it will grant to the Software Product Specification (SPS) (that requires the delivery of the software applications that comprise the integrated digital/data environment), the SVD (that identifies all versions of that software that create that environment), DDD (that identifies the file folder structure/hierarchy of the IDEE), and the DAL.

IDEE Database Structure The Contractor shall deliver a Database Design Description (DBDD) that identifies the file folder structure/hierarchy of the IDEE. The Government desires Government Purpose Rights at a minimum to the DBDD.

OMFV Product Structure and Bills of Material (BOM)

OMFV Product Structure Throughout the life of the contract, the contractor shall ensure that the OMFV vehicle product structure accurately captures the decomposition of the overall functionality of the OMFV vehicle system into:

1) Defined functions

2) The component part(s) of the vehicle system that provide those functions

3) The interfaces between those components part(s)

The contractor shall ensure the OMFV vehicle product structure also captures the end products, to include end product assemblies, quantities, and the relationships between the hardware and software products and the component parts.

The contractor shall ensure that the OMFV vehicle product structure accurately traces and is linked to the OMFV system architecture model, the contractor’s configuration status accounting system information, all BOM data, data from its suppliers, and CSDR CWBS element (IAW C.11.3.1.11 CSDR Mapping Review).

OMFV BOM

The contractor shall ensure the BOM is derived from the product structure and delivered IAW CDRL B008 and Attachment 0088 (OMFV Bill of Materials).

Prototype Vehicle BOM The Contractor shall prepare and submit an As-Built Configuration Baseline Bill of Materials (ABC-BOM) for each prototype vehicle IAW CDRL E029.

Configuration and Data Management

Engineering Change Notice (ECN) The Contractor shall submit Engineering Change Notice (ECN) IAW CDRL E098 after the product baseline has been established for the system or any subsystem. The Contractor retains configuration approval authority for all ECNs. The ECN process will be used to support configuration management for the OMFV test program, log package development, and Government cost estimates. The Contractor shall resubmit CDRLs which were affected by the ECN at no additional cost to the USG. All ECNs shall be integrated into the CDRL E041 (System Architecture Model).

Request for Variance (RV) The Contractor shall prepare Requests for Variance (RFV) IAW CDRL E042 at any time the Contractor intends to deviate from the requirements of this contract.

Specification Change Notice (SCN) For proposed changes to USG Furnished Property (GFP) Specifications, the Contractor shall develop and submit SCNs IAW CDRL E046 and MIL-STD-961.

Technical Data Package (TDP) The Contractor shall identify Key Characteristics IAW AS 9103 for each part, and identification of these features shall be included within engineering drawings and the Technical Data Package (TDP).

Developmental Level TDP The Contractor shall prepare and submit a developmental TDP IAW CDRL E003 and Attachment 0011 (Developmental Level TDP Instructions). CDRL E003 shall be tagged in the delivery of System Architecture Model (CDRL E041).

Product Level TDP The contractor shall prepare and deliver a Model-based Technical Data Package (TDP) IAW CDRL E080 and Attachment 0087 (Product Level TDP Instructions).

Engineering Release Record (ERR) The Contractor shall prepare and submit a final ERR IAW CDRL E028.

TDP In-Process Reviews (IPRs) The Contractor shall participate in TDP IPRs, during scheduled PCMs, to receive feedback on E003 and/or E080 submission deficiencies. Rather than reject entire submissions, the USG intends to give incremental feedback for the Contractor to resubmit portions of TDP that aren’t meeting contractual requirements. The Contractor shall resubmit TDP CDRLs and/or portions of TDP CDRL submissions according to the TDP IPRs.

Technical Data Package supporting Assertions of Restrictions For any items the Contractor has Asserted Restrictions, the Contractor shall prepare and submit a developmental TDP IAW CDRL E003 and Attachment 0011 (Developmental Level TDP Instructions).

Technical Design Data Rights and Intellectual Property

Development Level TDP The USG's TDP IPRs will be used to ensure completeness and content of the TDP as the system is developed and to help identify IP rights of data. The TDP review process will be a continuous process throughout the execution of this contract. The Contractor shall mark all TDP drawings IAW Attachment 0011 (Development Level TDP Instructions).

Product Level TDP TDPs shall include both Prime contractor and suppliers’ data and shall contain sufficient data to manufacture, procure, or rework items at a future date through competitive procurement. The Government desires Government Purpose Rights (GPR) at a minimum to the Product Level TDP(s).

Technical Performance Measures and Metrics The Contractor shall develop and deliver Technical Performance Measures (TPMs) Report IAW CDRL E001 and Attachment 0010 (Technical Performance Measures).

Use of Modular Open Systems Approach (MOSA) The Contractor shall develop and employ a Modular Open Systems Approach (MOSA) for the OMFV design using Attachment 0007 (Program Executive Office (PEO) Ground Combat Systems (GCS) MOSA Implementation Guide) as a guide.

The Contractor’s approach for the MOSA shall enable refreshment and upgrade of technologies at a Component of End Item (COEI) level, using the AR-700-18 definition of COEI, through modular designs for severable end item components of all subsystems/system-of-systems by using open standards for the modular system interfaces of the OMFV system. The Contractor shall deliver interface control documents for all major system component, major system interfaces, and key interfaces at the COEI level of all subsystems/system-of-systems within IAW CDRL E041.

The term “major system component”

(A) means a high-level subsystem or assembly, including hardware, software, or an integrated assembly of both, that can be mounted or installed on a major system platform through modular system interfaces; and

(B) Includes a subsystem or assembly that is likely to have additional capability requirements, is likely to change because of evolving technology or threat, is needed for interoperability, facilitates incremental deployment of capabilities, or is expected to be replaced by another major system component.

The term "major system interface"

(A) means a shared boundary between a major system platform and a major system component, between major system components, or between major system platforms, defined by various physical, logical, and functional characteristics, such as electrical, Mechanical, fluidic, optical, radio frequency, data, networking, or software elements; and

(B) Is characterized clearly in terms of form, function, and the content that flows across the interface in order to enable technological innovation, incremental improvements, integration, and interoperability.

Major System Interfaces:

- Hull and Turret

- Hull and System Survivability

- Turret and System Survivability

- Hull and Suspension

- Hull and Power Pack

- Hull and Drive Train

- Turret and Armament

- Turret and Automatic Ammunition Handling

- Fire Control and Armament

- APS and Turret/Hull

Key Interfaces are subsets of Major System Interfaces, and are interfaces which support or enable:

- Rapid changes in technology

- Rapid changes in threat systems

- Interfaces existing between systems

- Multiple, long term, viable sources or where COTS exist

- Mission Critical Functions

- Isolates US-only systems

- Connections to GFE, GFP, and USG Information Systems

- Software capability insertion

Some examples Key Interfaces include:

- A Modular Radio Interface Unit that allow the integrations of multiple different radios (power, signals, waveforms and data).

- Power Control Units which allow updating channel outputs enabling system changes without hardware updates.

- A standardized message set for software (SW) communication to enable third party software (SW) insertion such as a standardized message set for software communication to enable third party software insertion (e.g. Artificial Intelligence and Fire Control).

- VICTORY enabled interfaces which facilitate information availability via standardized messages.

- Data bus standards, e.g. SAE-J1939 CAN, gigabit Ethernet.

- Vetronics computer backplanes and cards, e.g. 3UVPX.

- Interface and ports for USG equipment and devices, e.g. maintenance equipment, software loading, prognostics/diagnostics, and embedded training.

- The interface between the general-purpose processor and higher-level software abstraction layers

- The interface between business logic software and communication services

- The interface between hardware device drivers and higher-level software abstraction layers

The Contractor shall apply standards according to the order of importance below:

a. Standards as specified within the contract (including all the attachments)

b. Commercial standards

c. Widely supported, adopted, and consensus-based standards in the market place

d. Standards developed by US industry standards bodies that have been widely adopted by industry

Common Infrastructure Capability The Contractor shall implement a reusable, modular, and severable Common Infrastructure Capability that complies with the PEO GCS Common Infrastructure Architecture (GCIA) v2.0 IAW Attachment 0028 (GCIA v2.0 SysML Model) and Attachment 0102 (GCIA v2.0 Data Architecture Model). Attachment 0030 (Architecture Description Documents) and Attachment 0081 (Data Architecture Definition Document) may be used to provide further context.

The Contractor shall deliver the Common Infrastructure Capabilities and GCIA v2.0 interfaces in the System Architecture Model within the OMFV System Architecture Model IAW CDRL E041.

The Contractor shall extend the Common Infrastructure Capability instead of creating duplicate capability for implementing additional functions related to the Common Infrastructure Capability not specified IAW Attachment 0028 (GCIA v2.0 SysML Model).

The Contractor shall utilize instantiations of the Common Infrastructure Capability IAW GCIA v2.0 for the integration of subsystem capabilities.

The Contractor shall utilize the services available through the Common Infrastructure Capability, if available, to refrain from duplication of resources across subsystems.

The Contractor shall ensure that all subsystem integrations comply with GCIA v2.0 Attachment 0028 (GCIA v2.0 SysML model).

The Contractor shall always utilize GCIA 2.0-compliant software or hardware interfaces for accessing and providing data within the GCIA in-vehicle network.

All data used by the OMFV platform shall be open, visible, accessible, understandable, trusted, interoperable, and secure (VAUTIS) within the Common Infrastructure Capability.

The Contractor shall develop, extend, and deliver OMFV Data Model Artifacts IAW CDRL E103, Attachment 0099 (Data Architecture Artifacts), Attachment 0028 (GCIA v2.0 SysML Model) and Attachment 0102 (GCIA v2.0 Data Architecture Model).

The Contractor shall develop and deliver a GCIA Test Plan IAW CDRL E044. The Contractor shall deliver a GCIA Test Report IAW CDRL E045.

MOSA/Common Infrastructure Capability Exceptions The Contractor shall request a Request for Variance IAW CDRL E042 prior to using or designing the following:

a. Proprietary, special, or non-commercial software and/or hardware

b. Exceptions to the specifications of Section C.2.4.5.

c. Sole source suppliers

d. Software configuration items that are coupled with hardware

MOSA and Other Reference Architecture Interfaces Data Rights The Government intends to own the infrastructure in order to re-compete capabilities without having to go back for approval to the original developer. The Government also intends to modify the interfaces and infrastructure without any approval from the original developer as GCIA matures. The Government intends to reuse the interfaces for follow on Phases or on other GCS platforms (ICD's).

GCIA Interfaces For the design of the Common Infrastructure Capability, modular system interfaces of the OMFV system, and the interfaces between the subsystem capabilities and the GCIA v2.0 compliant Common Infrastructure Capability, the Contractor shall deliver, with unlimited rights or specially negotiated license rights, the SysML models, ICDs, IDDs, form, fit & function, and all corresponding specifications/requirements documents. The definition of GCIA modular system interfaces, and a listing of them, can be found in attachment 0030 (GCIA v2.0 Architecture Description Document (ADD) Rev2.1).

GCIA Components (Implementation of Infrastructure) For all reusable GCIA Components, the contractor shall deliver, with unlimited rights or specially negotiated license rights, SysML models, data architecture model and artifacts, source code for the software infrastructure implementation (including configuration files), executables, and all corresponding design/specification/requirements documents as it relates to GCIA implementation (software and hardware components).

Other OMFV Platform Major System Interfaces In addition to GCIA, The Government intends to upgrade and re-compete capabilities that fall outside the boundary of GCIA. The Government wants to reuse interfaces for follow on Phases or on other GCS Platforms (ICD's). It is critical that the government obtain rights to the modular interfaces on OMFV, to enable a MOSA.

For other modular interfaces not encompassed by the GCIA interfaces in section 2.4 of attachment 0030 (GCIA v2.0 Architecture Description Document (ADD) Rev2.1), the contractor shall deliver the SysML models, ICDs, IDDs, form, fit & function, and all corresponding specifications/requirements documents. The Government desires Government Purpose Rights. These modular interfaces are defined as Shared boundaries between major systems, major system components, or modular systems, defined by various physical, logical, and functional characteristics, such as electrical, mechanical, fluidic, and radio.

Software Development

DevSecOps The Contractor shall establish a DevSecOps Environment IAW Attachment 0009 (DevSecOps Environment) NLT 6 months after contract award.

Platform One The Contractor shall establish and use their DevSecOps environment in DoD Platform One and provide access to the USG. The Contractor shall use this environment for development of OMFV software. The Contractor shall have all sub-contractors develop software within Platform One. The contractor shall import all previously developed software into Platform One for validation. The Contractor shall include all software integrated into Platform One for system level qualification testing.

The Contractor shall deliver OMFV System Architecture Model IAW CDRL E041. The Contractor shall continually update their backlog within their DevSecOps environment and make their backlog viewable by the USG.

The Contractor shall execute DevSecOps on a sprint timeline not to exceed six weeks.

The Contractor shall identify and track all software system risks (IAW MIL-STD-882E section 4.4 and sub-sections) in the Hazard Tracking System IAW E024.

Software Design Documentation The Contractor shall develop and deliver the following software design documentation:

1. Software Design Description (SDD) IAW CDRL E005

2. Software Requirements Specification (SRS) IAW CDRL E006

3. Interface Requirements Specification (IRS) IAW CDRL E007

4. Interface Control Document (ICD) IAW CDRL E008

5. Interface Design Description (IDD) IAW CDRL E009

6. Software Architecture Document (SAD) IAW CDRL E084

Source Code & Executable The Contractor shall deliver a Software Product Specification (SPS) IAW CDRL E010.

The Contractor shall provide all maintainer's guides and instructions to reprogram and update the Configuration Items IAW CDRL E011.

For uploading software updates to the OMFV system, the Contractor shall implement and use a secure software updating process to ensure that the code has not been corrupted or altered. The design shall be detailed in block diagram, activity, behavior views within the System Architecture Model IAW CDRL E041.

Software Version Description (SVD) The Contractor shall develop and deliver a Software Version Description (SVD) to describe each computer software version release IAW CDRL E012.

Software Test Description (STD) The Contractor shall develop and deliver a Software Test Description (STD) to describe each computer software version release IAW CDRL E085.

Software Licenses The Contractor shall deliver all Software Licenses IAW CDRL E013 for all software utilized on the OMFV systems, including commercial software licenses, required for compiling, building, installing, and maintaining all software utilized on the OMFV system, as well as all software licenses required for operation and maintenance of the OMFV system. The Contractor shall also identify licenses for computer software that are commercial software that cannot be transferred to the Government from the Contractor.

Software Transition Plan The Contractor shall develop and deliver a Software Transition Plan (STrP) IAW CDRL E014.

Software Qualification Testing (SQT) The Contractor shall conduct software qualification testing of each Software Configuration Item and deliver Software Quality Test Report (SQTR) IAW CDRL E015.

Software Quality Assurance The Contractor shall prepare and deliver a Software Quality Assurance Report (SQAR) IAW CDRL E016.

Software Assurance The Contractor shall ensure that protection and assurance activities aimed at mitigating attacks against the operational system throughout the system life cycle and those that address threats to the development environment that are implemented and documented in a Software Assurance Plan IAW CDRL E070.

Software/Systems Integration Lab The Contractor shall conduct system qualification tests, including cybersecurity and safety tests, utilizing an environment that most closely represents the actual OMFV design: i.e. verified software integrated on actual hardware-in-the-loop, including vehicle harnesses to the maximum extent that is to fully represent vehicle's parameters. The Contractor shall develop and deliver the Software/Systems Integration Laboratory (SIL) Test Description IAW CDRL E034. The Contractor shall deliver the Software/SIL Test Report IAW CDRL E114.

Software Deliverables & Licenses The contractor shall provide technical data and license rights for software, as required, to maintain, sustain, operate, and modify the OMFV system.

Source Code & Executables Data and License Rights The Contractor shall deliver unlimited rights for Software Code and Executables IAW DFARS 252.227-7015 and DFARS 252.227-7014.

Software Licenses Rights The Contractor shall transfer all licenses that support OMFV that were procured during the execution of this contract to the Government at the conclusion of the contract.

Vetronics Infrastructure The Contractor shall prepare and deliver a Vehicle Electronics Infrastructure Report IAW CDRL E104 and Attachment 0092 (Vehicle Electronics Infrastructure Architecture).

Program Protection

Critical Technologies (CT) and Critical Program Information (CPI) The Contractor shall identify all Critical Technologies (CT) and Critical Program Information on the OMFV and document results in the Program Protection Implementation Plan (PPIP) IAW CDRL E018 and Attachment 0026 (Inherited Critical Technologies and Potential Countermeasures). The contractor shall document trusted system design countermeasures in the OMFV System Architecture Model IAW CDRL E041.

Inherited CT and CPI The Contractor shall include any CT and CPI inherited from GFE IAW Attachment 0026 (Inherited Critical Technologies and Potential Countermeasures).

Program Protection Implementation Plan (PPIP) The Contractor shall develop and implement a PPIP IAW CDRL E018 that describes the Contractor's process for managing risks to technology and mission-critical system functionality from foreign collection, design vulnerability, supply chain exploitation, and battlefield loss throughout the acquisition lifecycle IAW DoDI 5200.44.

Program Protection Criticality Analysis The Contractor shall develop and deliver a Program Protection Criticality Analysis IAW CDRL E019 and Attachment 0014 (Program Criticality Analysis Template).

Critical Component Subcontractors The Contractor shall take steps to ensure that products purchased or obtained shall not be identified as being destined for inclusion in a USG system.

Risk Mitigation of Critical Components The Contractor shall develop risk mitigation strategies for all Critical Components (CCs) identified from the Program Protection Criticality Analysis IAW CDRL E019.

Critical Component Control The Contractor shall certify that the underlying computer software, firmware, and hardware, which in totality, constitute the managed service, have been controlled, evaluated, and tested to ensure that the service delivers what it is designed to deliver and nothing more.

The Contractor shall test all Critical Component code against the top 25 Common Weakness Enumerator (http://cwe.mitre.org).

The Contractor shall deliver details in tab ‘SwA Table’ of the Program Protection Criticality Analysis IAW CDRL E019. All Contractor-developed source code shall be provided for independent system assurance testing within the DevSecOps environment.

Supply Chain Risk Management (SCRM) The Contractor shall submit a Supplier Performance Risk System (SPRS) Certification IAW CDRL E020.

The Contractor shall develop, implement, and deliver a Counterfeit Parts Prevention Program Plan IAW CDRL E021.

Cybersecurity

Cybersecurity Test Events For all Cybersecurity Test Events, the Contractor shall participate in a pre-test event and post-test event reviews. These events shall last no longer than 6 hours.

For all pre-test event reviews, the Contractor shall generate briefing materials in support of the review IAW CDRL P002. All pre-test reviews shall occur five (5) to twenty-one (21) days prior to the test event.

For all post-test event reviews, the Contractor shall generate briefing materials in support of the review IAW CDRL P002. All post-test reviews shall occur five (5) to twenty-one (21) days after the test event.

All Cyber Testing events, Cyber Tabletop Exercise, Cooperative Vulnerability Identification, Adversarial Cyber Development Testing, and Cooperative Vulnerability Penetration Assessment shall be events, pre-test reviews, and post-test reviews shall be classified events. The contractor shall work with the PCO to identify a location for these events.

Cyber Tabletop Exercise The Contractor shall participate in a Cyber Tabletop Exercise (CTT) IAW Attachment 0015 (Cybersecurity Test Events).

Cooperative Vulnerability Identification (CVI) The Contractor shall participate in a Cooperative Vulnerability Identification (CVI) event IAW Attachment 0015 (Cybersecurity Test Events).

Adversarial Cyber Developmental Testing (ACDT) The Contractor shall participate in an Adversarial Cyber Developmental Testing (ACDT) event IAW Attachment 0015 (Cybersecurity Test Events).

Cooperative Vulnerability Penetration Assessment (CVPA) The Contractor shall participate in a Cooperative Vulnerability Penetration Assessment (CVPA) event IAW Attachment 0015 (Cybersecurity Test Events).

Security Controls Traceability Matrix (SCTM) The Contractor shall provide a SCTM IAW CDRL E041, and cross examine it against the system requirements to identify gaps to controls, requirements, and the CSAs IAW Attachment 0020 (OMFV Tailored Control Correlation Identifiers (CCI)).

Attack Surface Characterization The Contractor shall generate and deliver an Attack Surface Characterization Report IAW CDRL E022.