OMFV_Draft_RFP_W56HZV-22-R-0026.docx

OMFV Draft RFP W56HZV-22-R-0026

OMFV DRAFT REQUEST FOR PROPOSAL

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

JUNE 16, 2022

PM MCS

Detroit Arsenal, MI

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 K TBD

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 Armored Brigade Combat Team (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 adopt the latest digital engineering techniques, which will allow rapid adaptation by possessing Growth margins that allow for the insertion and integration of future technologies.

Designed from the beginning using a Modular Open Systems Approach (MOSA) and based on an Army-defined and owned open architecture standard, OMFV provides the Army an affordable pathway to OEM-independent upgrades at the hardware component level. As technology and software evolves, the Army’s open architecture standard allows the OMFV to modernize rapidly at a reduced cost. This will also offer more opportunities for increased industry competition and innovation over the OMFV’s lifecycle.

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 respect to the level of capability OMFVs provide the ABCTs.

Program Overview

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

The USG is committed to adopting digital engineering best practices, agile software development using a DevSecOps approach, and a cloud-based infrastructure in support of the OMFV program. The adoption of these principles are key enablers to support the rapid adoption, testing, and integration of future technologies.

OMFV is the U.S. Army’s first ground combat vehicle designed using modern digital engineering tools and techniques. OMFV contractors will develop the OMFV using Models Based System Engineering (MBSE) and within the digital domain to communicate the design’s maturity and evolution via a series of interconnected digital models throughout the program lifecycle.

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 virtual prototype of their design. These phases will be a single contract with up to 3 contracts awarded.

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. 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 The RFP requires 11 prototype vehicles, as well as two Ballistic Hulls and Turrets, Armor Coupons, digital models 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 the GFI included in this RFP, 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 (Value Adjusted Total Evaluated Price) will be utilized as part of the overall Price evaluation.

The USG is considering including an Economic Price Adjustment provision for prototype material for the option vehicles. Any such provision will be added by amendment shortly after the final OMFV Phase 3/4 RFP.

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. The solicitation requires proposals for a total of 11 prototypes – 7 for a contract award and an option for 4 additional prototypes.

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 fewer 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

Detailed Design, Prototype, Build and Test

CLIN 0003 Narrative Prototype Vehicles (Section C.11), all Option Prototype vehicle work under this CLIN shall be performed in accordance with Section C, Statement of Work. This CLIN will be incrementally funded in accordance with B.1. The vehicle(s) shall be shipped to the location specified IAW H.8 and Attachment 0051 (PPT Schedule).

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. 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.1.

CLIN 0003 Prototye Option

If the Option is exercised, (ref. C.11 & H.8), CLIN 0003 will be funded on an incremental basis IAW Defense Acquisition Regulation Supplement (DFARS) 252.232-7007. The following is the Incremental Funding Schedule for CLIN 0002:

Funding Period Amount ($M)

*To be Proposed by the Contractor. Not to Exceed the amounts stated in M.3.1.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 improving cost, schedule and performance.

The USG has implemented a Models Based Systems Engineering approach with an OMFV Objective Architecture to better communicate the requirements of the OMFV system in a clear and concise manner. The contractor will develop the system architecture and design based on OMFV objective architecture. The program is requiring Contractors to manage and maintain the system design and requirement compliance status in a model-based environment, the contract requires the implementation and use of the Ground Combat Systems Common Infrastructure Architecture (GCIA) provided within the OMFV OBJ Architecture and DevSecOps software development to enable the USG to quickly upgrade the OMFV in the future in a Government hosted environment.

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 The Contractor shall develop and deliver a Digital Engineering Management Plan (DEMP) IAW CDRL E002 and Attachment 0097 (OMFV Digital Engineering Strategy).

The DEMP shall include the Contractor’s configuration management plan for developing and maintaining model-based technical baselines throughout the program lifecycle IAW the technical baseline definitions in EIA-649-1.

The DEMP shall include the Contractor’s approach to use MS&A in order to reduce risk entering physical test.

OMFV System Architecture Model The Contractor shall develop an integrated System Architecture Model for the OMFV IAW CDRL E041, Attachment 0067 (CDRL Architecture Model), and Attachment 0091 (Digital System Model).

The OMFV System Architecture Model (CDRL E041) shall decompose Attachment 0008 (OMFV Objective Architecture) into the requirements and functional, logical, and physical architectural elements that satisfy the USG’s Performance Specification (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 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 (BOM).

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 requirements of the OMFV system, including Attachment 0008 (OMFV Objective Architecture) and Contractor specifications (SSS, SRS, IRS, etc.), IAW CDRL E083, Attachment 0067 (CDRL Architecture Model), and Attachment 0091 (Digital System Model).

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.

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.

Model-Based Design, Simulation, and Test The Contractor shall execute modeling, simulation, and analysis (MS&A) throughout the life of the program to satisfy the use cases of the Attachment 0097 (OMFV Digital Engineering Strategy), and to build the foundation for a digital twin of their design IAW the DEMP (CDRL E002).

Contractor MS&A Deliverables The Contractor shall deliver the following MS&A in support of system design and the design model specified in the Attachment 0097 (OMFV Digital Engineering Strategy):

a. The Contractor shall submit Attachment 0093 (Night Vision – Integrated Performance Model (NV-IPM)) IAW CDRL T023.

b. If the Contractor’s design includes Active Protections System (APS) Performance, the Contractor shall provide APS Performance Data IAW CDRL E065 and Attachment 0057 (Active Protection Data).

c. The Contractor shall provide Armor Recipe Characteristics IAW CDRL E066 and Attachment 0053 (Armor Recipe Characteristics).

d. The Contractor shall provide Underbody Analysis IAW CDRL E067 and Attachment 0054 (Underbody Analysis Data Instructions).

e. The Contractor shall deliver modeling and simulation input data as described within Vehicle Vulnerability Analysis MS&A Inputs IAW CDRL E068 and Attachment 0055 (Vehicle Vulnerability Data Instructions).

f. The Contractor shall deliver a Thermal Signature Analysis IAW CDRL E069 of their vehicle design that demonstrates the predicted system level signature using a root sum squared delta T method in IAW TOP 02-2-812A.

g. The Contractor shall deliver AFES MS&A Inputs IAW CDRL T009 and modeling and simulation input data as described within Attachment 0058 (AFES Analysis Information Request).

h. The Contractor shall fill out the data sheets, and deliver NRMM and Dynamics MS&A Inputs IAW CDRL T010 and Attachment 0059 (NRMM Data Sheet Wheeled and Tracked) for USG to run the model.

i. The Contractor shall deliver Powertrain Data IAW CDRL T011 and Attachment 0060 (Vehicle Data Package for Propulsion System Modeling & Simulation) and Attachment 0061 (Tracked Vehicle Dynamics Data Sheet).

j. The Contractor shall deliver the Vehicle Interior Noise Analysis Input Datasheet IAW CDRL T032 and Attachment 0101 (Vehicle Interior Noise Analysis Input Datasheet).

k. The Contractor shall deliver Operational Effectiveness Data IAW CDRL T013 and Attachment 0063 (Operational Effectiveness Template) on their proposed design.

l. The Contractor shall deliver C5ISR CoSite Inputs IAW CDRL T026 and Attachment 0090 (CoSite Data Instructions).

m. The Contractor shall deliver a Process SimulateTM Model Concept IAW CDRL T014 and Attachment 0064 (Process SimulateTM).

n. The Contractor shall deliver SoSAT Data Inputs IAW CDRL T019 and Attachment 0106 (SoSAT Data Inputs).

The Contractor shall deliver MS&A artifacts developed to meet the use cases and model specifications included in the Attachment 0097 (OMFV Digital Engineering Strategy) IAW CDRL E076 and the Contractor’s DEMP (CDRL E002).

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.

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

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

Any Systems Model data, 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 utilize a DAE in order to manage the scope of this contract. The USG DAE will be separate from the Contractor Integrated Digital Engineering Enviornment (IDEE).

The Contractor shall acquire access to the DAE by submitting a Digital Access Point Request IAW Attachment 0006 (Digital Access Point Request). This access will serve as the connection between the DAE and the Contractor 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 establish and utilize an IDEE in order to develop and manage the OMFV system data.

The Contractor shall update the USG at each PCM the current software used in their IDEE.

IDEE Data Rights

Contractor’s Digital Environment – Noncommercial Software The Government desires Government Purpose Rights (GPR), at a minimum, to the noncommercial computer software used within the IDEE.

Modified 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 within the IDEE.

OMFV Product Baseline and Bills of Material (BOM)

OMFV Product Baseline

The contractor shall ensure that the OMFV vehicle product baseline, as defined by EIA-649-1, 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 elements.

OMFV Bill of Materials (BOM) The contractor shall ensure the BOM is derived from the product baseline 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

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 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). The Government desires Government Purpose Rights (GPR), at a minimum, to the TDP(s).

Developmental Level TDP The Contractor shall prepare and submit a developmental TDP IAW CDRL E003 and Attachment 0011 (Developmental Level TDP Instructions).

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).

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 The Contractor shall submit a conceptual, developmental, or product level TDP for any items the Contractor Asserts Restrictions.

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 v1.0) as a guide.

The Contractor’s approach for the MOSA shall enable refreshment and upgrade of technologies at a component level, 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, Modular System Interfaces, and key interfaces at the component level of all subsystems/system-of-systems IAW CDRL E041.

The term “component level”

(A) means a configuration item (e.g. severable modules of a fire control system), which encapsulates a subset of the system's functionality/data, with a defined interface.

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 "Modular 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.

Modular 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 Modular 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 (GCIA v2.0 Architecture Description Document Rev2.1) and Attachment 0081 (GCIA v2.0 Data Architecture Definition (DAD) Rev2.1) may be used to provide further context.

The Contractor shall deliver the system architecture of the Common Infrastructure Capabilities and GCIA v2.0 interfaces 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 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 One Time DID), 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 submit a Request for Variance IAW CDRL E042 prior to using software and/or hardware that does not comply with the PEO GCS Common Infrastructure Architecture (GCIA) v2.0.

MOSA and Other Reference Architecture Interfaces Data Rights The Government intends to own the infrastructure in order to re-compete capabilities to meet future government requirements without being vendor locked. 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 government purpose 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 GCIA Components, the contractor shall deliver, with government purpose rights or specially negotiated license rights, SysML models, data architecture model, data architecture model library, 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). A GCIA component is a severable module /configuration item that is developed IAW with the GCIA 2.0 specifications, which encapsulates its associated GCIA functionality/data, with a GCIA defined/identified open standards based interface.

Other OMFV Platform Modular 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, 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 use the USG provided DevSecOps Environment IAW Attachment 0009 (DevSecOps Overview) NLT six months after contract award and provide read-only access to the USG.

Platform One 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. 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 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 Within the DevSecOps environment, the following must be maintained current and viewable to the USG:

a. Software Design Description (SDD) (CDRL E005)

b. Software Requirements Specification (SRS) (CDRL E006)

c. Interface Requirements Specification (IRS) (CDRL E007)

d. Interface Control Document (ICD) (CDRL E008)

e. Interface Design Document (IDD) (CDRL E009)

f. Software Product Specification (SPS) (CDRL E010)

g. Software Version Description (SVD) (CDRL E012)

h. Software License Requirements List (SLRL) (CDRL E013)

i. Software Test Report (CDRL E015)

j. GCIA Test Report (CDRL E045)

k. Software Test Description (CDRL E085)

l. Software Systems Integration Laboratory (SIL) Test Report (CDRL E114)

m. Software Bill of Materials (SBOM) (CDRL E004)

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

The Contractor shall provide the Software Product Package 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 Architecture Document The Contractor shall develop and deliver a Software Architecture Document (SAD) IAW CDRL E084.

OMFV System and Support Systems 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.

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 Plan IAW CDRL E034. The Contractor shall deliver the Software/SIL Test Report IAW CDRL E114.

System Software Safety Program The Contractor shall conduct a System Software Safety Program IAW Attachment 0084 (Joint Software System Safety Engineering Handbook (JSSSEH) Implementation Guide) paragraph C.

The Contractor shall conduct a System Software Safety Assessment to define, evaluate, and test the safety-significant functionality associated with the integration of the Contractor-generated, NDI, COTS, reuse, and Government-furnished computer software; and discuss the assessment during the ESOH WG. Any hazards contributed by software will be documented in the Hazard Tracking System and delivered IAW CDRL E024.

The Contractor shall conduct Level of Rigor (LOR) activities to ensure that the software will perform as specified in the SRS and IRS, without contributing to hazards.

All LOR tasks for all SwCI (Software Criticality Index) level 1-3 shall be completed no later than Test Readiness Review 1 IAW MIL-STD 882E. These results and mitigations shall be included in the Software Test Report (CDRL E015). If all LOR tasks are not completed or the LOR tasks are unspecified the SW Safety contribution to a system level risk will be documented as a Medium, Serious, or High risk depending on the SwCI level.

The Contractor shall conduct System Software Safety -specific testing and provide the results as part of the Software Test Report (CDRL E015) to verify that the design and implementation of the computer software mitigates all of the identified computer software related hazards.

Software Bill of Materials (SBOM) The Contractor shall develop and deliver a Software Bill of Materials (SBOM) IAW CDRL E004. The SBOM is a formal record containing the details and supply chain relationships of various components used in building software, and tracks version of all code; including firmware, third party developed software (to include dependent libraries), and previously developed software. International Standard ISO/IEC 5962 (as of 202108) can be used as a guide.

For each software component, the SBOM shall include the following and be delivered IAW CDRL E004:

a. Software name

b. Name of developer, distributor or location acquired (repository, website, disc delivery, etc),

c. Associated hash codes

d. Hash code algorithms

e. Version identifiers

f. Identification is the software has privileged access (ex: Administrator or Root)

g. Identification of allocation to the OMFV (LRCs or Circuit Cards)

Source Code & Executables Data and License Rights The Contractor shall deliver Government Purpose Rights or specially negotiated license rights for Software Code and Executables developed under this contract IAW DFARS 252.227-7015 and DFARS 252.227-7014.

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

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 review. The pre-test and post-test events cannot exceed six hours in length.

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).

Attack Surface Characterization The Contractor shall generate and deliver an Attack Surface Characterization Report IAW CDRL E022. The Contractor shall include all potential entry and exit points to the platform (Ex: software download, training devices, removable hardware, etc.).

Cyber Risk Management Framework The Contractor shall submit DoD Risk Management Framework (RMF) Package Deliverables IAW CDRL E017 and IAW Attachment 0024 (Risk Management Framework Package Deliverables Instructions).

Supporting Artifacts The Contractor shall deliver the RMF Package Deliverables IAW CDRL E017 and Attachment 0024 (Risk Management Framework Package Deliverables Instructions).

a. Authority to Operate (ATO) Requests

b. Assessment and Authorization (A&A) Project Plan

c. A&A Tasks and Milestones

d. System Security Implementation Plan

e. RMF Implementation Plan (RIP)

f. Software Code Vulnerability Scans

g. Operating System Vulnerability Scans

h. Software/Firmware Information Assurance Vulnerability Management (IAVM) Plan

i. Key and Certificate Management Plan

j. Plan of Action and Milestones

k. Cyber Security Waiver

Design for Security

Cryptographic Processes and Key Management Plan (KCMP) The Contractor shall follow policy provided by the Committee on National Security Systems Policy (CNSSP) 15, Use of Public Standards for Secure Information Sharing, to determine algorithms for assessing integrity and ensuring confidentiality.

CNSSP is available at:

https://www.cnss.gov/CNSS/issuances/Policies.cfm

The Contractor shall develop a copy of all encryption and signing keys / certificates assigned to each platform and deliver Cryptographic Encryption Keys IAW CDRL E075.

Cross Domain Solution If the design requires the use of a Cross Domain Solution (CDS), the Contractor shall ensure the CDS is GCIA compliant.

Corrosion Prevention and Control The Contractor shall develop, deliver, maintain, and comply with a Corrosion Prevention and Control Plan (CPCP) IAW CDRL E031 and Attachment 0082 (Chemical Agent Resistant Coating Drawing).

Environment, Safety and Occupational Health (ESOH)

ESOH Program The Contractor shall develop, implement, and maintain an ESOH program in accordance with MIL-STD-882E.

Prohibited Material The Contractor’s OMFV design shall not have prohibited materials (including alloys containing prohibited materials) present in or on any delivered systems or support equipment, required for operation and sustainment/provisioning of the system, or used in final manufacture and assembly processes.

The following are prohibited materials: asbestos, beryllium, Class I and Class II Ozone Depleting Substances (ODS), hydrofluorocarbons (HFCs), hexavalent chromium, cadmium, mercury, lead, radioactive materials, and other Group 1 Agents classified as "carcinogenic to humans" by the International Agency for Research on Cancer (IARC) Monographs.

The following exceptions are allowed without prior approval from the USG:

a. Cadmium and hexavalent…