HR001119S0019-Amendment-01.pdf

HR001119S0019

Broad Agency Announcement

Operational Fires (OpFires) Integrated Weapon System

(Phase 3)

Tactical Technology Office

HR001119S0019

Amendment 01

June 26, 2019

The purpose of this amendment is to revise language in the following section:

Section IV.B.1.b. Removed reference to Attachment 5, page 34

Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

II. Award Information

A. General Award Information

B. Fundamental Research

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

V. Application Review Information

A. Evaluation Criteria

B. Review of Proposals

VI. Award Administration Information

A. Selection Notices and Notifications

B. Administrative and National Policy Requirements

C. Reporting

D. Electronic Systems

VII. Agency Contacts

VIII. Other Information

PART I: OVERVIEW INFORMATION

• Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Tactical Technology Office (TTO)

• Funding Opportunity Title – Operational Fires (OpFires) Integrated Weapon System

• Announcement Type – Initial announcement

• Funding Opportunity Number – HR001119S0019

• Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable

• Dates o Proposers Day: June 4, 2019 o Posting Date: June 5, 2019 o Request Classified BAA Annex by: June 21, 2019 o Questions Due Date: July 3, 2019 o Proposal Due Date and Time: August 5, 2019, 1200PM Eastern Time

• Concise description of the funding opportunity – The OpFires Integrated Weapon

System task will be a three-phased effort to design, develop, and flight test an end-to-end prototype system enabling a novel ground-launched system for tactical weapons deployment.

• Anticipated individual awards – Multiple awards for Phase 3a, Preliminary Design, with an option for Phase 3b, Critical Design, and potential follow on award for Phase 3c, Assembly, Integration, and Test.

• Types of instruments that may be awarded – Procurement contract or other transaction agreement.

• Agency contact o Points of Contact

The BAA Coordinator for this effort can be reached at:

HR001119S0019@darpa.mil

DARPA/TTO

ATTN: HR001119S0019

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process. DARPA BAAs are posted on the Federal Business Opportunities (FedBizOpps) website, http://www.fbo.gov/. The following information is for those wishing to respond to the BAA.

DARPA is seeking innovative system solutions that will enable capabilities for a mobile, ground-launched tactical weapon delivery system capable of carrying a variety of payloads to a variety of ranges. DARPA anticipates that successful performers for this program will have recent, relevant, and significant experience and expertise in end-to-end weapon system design, integration, development, and demonstration. The use of a BAA allows a wide range of innovative ideas and concepts, and proposer(s) will have the flexibility to develop a tailored program plan that best advances OpFires in accordance with program objectives.

This BAA encompasses a three-phase effort for Integrated Weapon System design, development, and flight test. Phase 3a consists of the integrated weapon system preliminary design, Phase 3b consists of the integrated weapon system critical design, and Phase 3c encompasses flight test execution. DARPA expects full technical and cost proposals for the combined Phase 3a and Phase 3b effort, with a rough order of magnitude (ROM) cost estimate and an associated list of assumptions for Phase 3c (this will be for planning purposes only and will not be evaluated as part of the selection decision). DARPA plans to award multiple Phase 3a base efforts with Phase 3b options to be exercised/awarded at the end of Phase 3a based on concept viability and program execution. Towards the end of Phase 3b, DARPA may ask performers whose 3b options were exercised for full Phase 3c technical and cost proposals.

A. OpFires Program Background and Overview

The United States ground-based forces are currently limited in effective range of surface-to-surface precision fires. The OpFires program seeks to provide operational/theater level commanders with flexible capabilities to strike time-sensitive targets while providing persistent standoff from unpredictable land-launch positions. This flexibility would restore combatant commander options in force deployment and employment, enabling adaptable engagement at extended ranges.

The overarching goal of the OpFires program is to develop and demonstrate a novel ground-launched system enabling hypersonic boost-glide weapons to penetrate modern enemy air defenses and rapidly and precisely engage critical time-sensitive targets. Specific capability objectives for the OpFires system and components are in the classified annex to this BAA.

DARPA-CG-969 Rev. 1 provides instructions and guidelines on the classification/ declassification of information and material associated with the OpFires program. Instructions for requesting the Classification Guide and classified annex are in Section IV., Application and Submission Information.

The OpFires program includes three main elements:

(1) This Integrated Weapon System BAA, referred to as Phase 3, focused on developing an operational system design and leveraging the innovative propulsion solutions under development in the Propulsion System task. This design will inform a prototype missile system suitable for integrated flight testing to demonstrate the end-to-end OpFires system. Proposals submitted for this effort must address the full scope of the program described herein.

(2) The ongoing Propulsion System task, referred to as Phases 1 and 2, which is developing innovative propulsion solutions for an advanced tactical weapon system.

Government Furnished Information (GFI) resulting from this effort may be provided to OpFires Integrated Weapon System task awardees.

(3) A completed study to inform system and launcher characteristics. Details may be found in the classified annex to this BAA.

For clarity and consistency, the OpFires program will use the following system and component definitions:

• Payload – the hardware that will separate from the booster and execute the flight to target;

• Booster – all propulsion associated hardware that is launched from the ground vehicle including: control actuator system (CAS), the rocket motor/engine(s), interstage hardware, nozzles and separation systems. Does not include the shroud or payload;

• Missile – payload, booster, shroud (nose fairing);

• Canister – assembly/launch tube to protect the missile during transport and storage;

• All Up Round (AUR) – missile and any other hardware that is launched from the ground vehicle, when packaged in its canister;

• Control Actuator System – the associated hardware that controls the flight of the vehicle. Can be applied to the missile, booster, or payload;

• Launch Platform – Ground vehicle or trailer and associated interface hardware from which the missile will be launched.

B. OpFires Integrated Weapon System Task Scope

This BAA, OpFires Integrated Weapon System, focuses on the development of a mobile, ground-launched, operational system design, and flight-test demonstration of an end-to-end prototype weapon system. This includes both a mobile ground launcher and AUR capable of achieving the OpFires performance objectives outlined in the classified annex to this BAA. In addition to the stated performance objectives, performers are expected to include the following considerations when developing their approach to integrated weapon system design and prototype demonstration (details can be found in the classified annex to this BAA):

• Summary results from AUR and Launcher trade studies;

• Objective payload interfaces and compatibility constraints;

• Information to inform an OpFires concept of operations, including classes of targets and representative deployment environments;

• Notional flight test objectives and Test Range considerations;

• Integrated Weapon System affordability goals; and

• Environmental conditions and safety standards required for system operation in tactical, ground environments (also refer to MIL-STD-810G and MIL-STD-882E).

Performers are also expected to consider available Phase 1 propulsion system design data and test results, outlined in Table 1, for incorporation into their Phase 3 design solution. A summary of Phase 1 design approaches, Phase 2 technology maturation plans, and system status was provided as a part of the Proposers Day. Additional information regarding environments and specifications specific to other relevant ground launched missiles, as well as the possible launch platforms, will be included in the Proposers Day briefing package available for request in accordance with section VIII of this BAA.

DARPA has developed a notional baseline schedule, shown in Figure 1, which includes the envisioned top-level program activities and shows the concurrent nature of the Propulsion System and Integrated Weapon System development tasks. The Weapon System Integration task will consist of a base period (Phase 3a) followed by an option period for Phase 3b.

Figure 1: Phase 3 Schedule Overview

The primary objectives of Phase 3 are to 1) develop an Operational System (OS) design;

2) design, develop, fabricate, and integrate an end-to-end Operational Prototype System (OPS) based on that OS design; 3) conduct compelling prototype system demonstrations starting no later than mid FY2022; and 4) establish and document clear traceability between the as-designed OS and the as-built OPS. This phase will also leverage the propulsion system development and technology maturation activities conducted concurrently under OpFires Phase 1 and Phase 2. In support of the primary objectives described above, it is envisioned that the scope of Phase 3 consists of the distinct and related efforts described below and illustrated in Figure 2.

Figure 2: Phase 3 will develop and demonstrate a prototype system that is traceable to an operational system design.

Operational System Design

Phase 3 will address the development of an OS design for both an integrated mobile launcher and the AUR, consisting of missile and canister. Designs should be informed by a well-defined concept of operations (CONOPS) and system technology trade studies, resulting in a preferred OS concept that meets performance and capability objectives as outlined in the BAA classified annex. The CONOPS should incorporate information including, but not limited to, target sets, areas of operation, system survivability, and United States (U.S.) Army force structure. Phase 3 performers should define the targeting information necessary for the launcher to provide executable mission data to the missile, including how functions of fire control, missile monitoring, and trajectory design are allocated across (and perhaps outside) the system architecture. Due to the unique features of the propulsion system, as well as to support payload variants, the OS must be capable of calculating and executing boost phase trajectories independent of the payload avionics/flight computer. Trade studies should fully explore innovative approaches to the weapon system concept, with a focus on key system characteristics such as a robust operational envelope, launcher mobility, and system affordability to develop an optimal configuration. Trade studies should be conducted using metrics that include, but are not limited to, military utility, performance, cost, risk and reliability. Based on the results of these trade studies, the proposed OS point of departure (POD) concept(s) will be matured into a conceptual OS design. The OS design definition is intended to demonstrate the feasibility and achievability of a design that meets the program objectives. As such, the OS design must account for operational missile considerations including, but not limited to, selection and location of system components that support assessment of metrics for operational system reliability, maintainability, safety, availability, and service life. These examples are not exhaustive and it is expected that performers will update their understanding of proposed operational characteristics and considerations during Phase 3.

At the completion of Phase 3, an OPS-to-OS Traceability Assessment that integrates data from all testing, results of risk reduction efforts, and system analysis activities should be delivered to support accelerated entry of the operational system into the DoD acquisition process.

That report should also include a design plan, risk reduction approach, and test plan, including Rough-Order- of-Magnitude (ROM) schedule and cost, needed to fully realize an operational system design. The intent of this task is to provide final context to the Phase 3 results and provide top-level planning information to support Government follow-on and transition activities.

Prototype System Design, Fabrication, and Testing

Phase 3 prototype system design, fabrication and testing should include:

1) Plans for identifying and maturating OS-enabling component technologies necessary to achieve system objectives. This should explicitly include any elements of the propulsion system not anticipated to be fully addressed in Phases 1 and 2;

2) Incorporation of those technologies into a prototype system that matches the form and fit of the OS design with the functionality necessary to support Phase 3 demonstration objectives; and

3) Execution of fully integrated prototype system demonstrations and tests.

Per section IV.B1.a, “Volume I, Technical and Management Proposal – Prototype

System Development Plan (PSDP),” proposers must document their approach and plans for these three elements in a Prototype System Development Plan (PSDP) that will demonstrate how they propose to achieve the technical objectives of the Phase 3 program.

The OpFires Prototype System (OPS) that is produced and flight tested in Phase 3 is not intended to be a fully specified design that meets all potential operational system requirements, but rather a system with matching form and fit that will demonstrate critical system attributes, technologies, and functionality of the OS design through demonstration and test. To ensure successful transition of OpFires capabilities, it is critical that all Phase 3 activities are clearly traceable to an operational system that meets BAA performance objectives. This does not mean that the prototype system and operational system have to be identical vehicles. Per section IV.B1.a, “Volume I, Technical and Management Proposal – Prototype System Development Plan (PSDP),” the proposed PSDP should document the traceability of the OPS to the OS, including how the planned system demonstrations efficiently reduce risk for necessary elements that may not be directly traceable to the OS.

Component Technology Development: Phase 3 will include identification and development of OS-enabling critical technologies, including propulsion system technologies originating from the Phase 1 and Phase 2 Propulsion System Task. Per section IV.B1.a, “Volume I, Technical and Management Proposal – Prototype System Development Plan (PSDP),” Phase 3 proposals must include an initial assessment that identifies the technologies that require further development in order to achieve the Phase 3 objectives. Where appropriate, proposals should distinctly address the ongoing elements of Phase 1 or Phase 2 necessary to support this maturation, as well as a plan to manage those interactions across contracted efforts. The proposed technology development approaches should describe the extent of the Phase 3 effort, including key points at which the subject technology will be assessed against associated performance metrics. Technology development plans, which are expected to be refined over the course of Phase 3, should identify early demonstration and test events that support proof-of-concept, substantiate derived performance metrics, and demonstrate required functionality.

Candidate technologies for early demonstration and testing could include: Stage 1 booster/subsystems; booster thermal management techniques; Stage 2 component technologies;

Launcher/subsystems; Hardware-in-the-loop (HWIL) system simulations; missile guidance, navigation and control (GNC) simulations; and approaches to system safety (insensitive munitions, tactical booster drops). It is highly desired that performers focus on maturing key technologies early through well-defined test activities, in concert with a comprehensive risk management plan.

Prototype System Design: Phase 3 will include design of an integrated OPS that is traceable to an OS design incorporating the enabling component technologies matured throughout the Phase 3 effort. The major elements of the prototype system are the mobile ground launcher, the AUR, and any ground or test support equipment (GSE/TSE) required to support integrated system testing. Per section IV.B1.a, “Volume I, Technical and Management Proposal

– Prototype System Development Plan (PSDP),” Phase 3 proposals must include an initial approach to OPS design that is capable of meeting all BAA performance objectives. This should include design considerations and allowances to readily support the OS design. These design allowances, along with known deviations from their OS, must be documented in the proposed PSDP. In addition to hardware integration, software integration and data hand-offs between all of these elements must be identified and managed. The proposed System Development Approach described in section IV.B1.a, “Volume I, Technical and Management Proposal – System Development Approach,” should include the approach to identifying software interfaces and data exchanges.

Phase 3 will include design of an OpFires ground mobile launcher, including associated command and control hardware and software to monitor missile status and health and process mission data. Studies have identified an initial trade space that can be used to inform launcher design; however, it is anticipated that proposals will address unique performer-defined approaches to launcher, missile, and canister interfaces. The Government desires common launch support equipment compatible with multiple ground platforms. Initial assessments indicate that both the M870 tri-axle trailer and United States Marine Corps Logistic Vehicle System Replacement (USMC LVSR) are suitable and capable mobile launch platforms, but this does not preclude consideration of other approaches to providing a mobile launch platform solution.

LVSR MKR18s will be made available as Government Furnished Equipment (GFE) to support launcher development and test. Additional requests for GFE should be addressed IAW IV.B1.a, “Volume I, Technical and Management Proposal – Government Furnished Equipment.”

Phase 3 will also include design of an integrated OpFires AUR that leverages operational booster designs developed under Phases 1 and 2. While those booster designs are informed by system integration considerations and derived from a notional AUR, they may not fully address all aspects of weapon system integration. Phase 3 proposals should address those integration considerations (e.g., canister design, hardware and software solutions for booster GNC, and payload integration – shroud and adapter) as part of their approach to both OS and OPS missile designs. Table 1 outlines a notional Government plan for concurrent execution of the Propulsion System Task and the Integrated Weapon System Task (Phase 3); direct coordination with Phase 1 and 2 performers will be necessary. Phase 3 proposals should provide additional detail on these, as necessary, to support the proposed approach to system design and maturation.

DARPA desires aggressive approaches to technology development and expects Phase 3 proposals to identify opportunities to accelerate system definition and demonstration that leverage the Government investment in Phases 1 and 2. Table 1 shows anticipated concurrency of Phase 1/2 and Phase 3 events, including the information that should be available to Phase 3 proposers/performers at major milestones.

Table 1: Anticipated dependencies, information exchanges, and event timing between phases Phases 1&2 Phase 3 Plan for Concurrent Execution Booster System Requirements Review (SRR)/ Conceptual Design Review (CoDR)

Phase 3 BAA Release

Summary: Phase 3 BAA focused on robust system solutions enabled by various booster configurations.

Phase 1: Booster requirements and operational system concepts defined and initial risk reduction testing complete. Booster PDR expected prior to Phase 3 proposal due date. Available information used to inform Phase 3 Proposers Day.

Phase 3: Phase 3 proposals informed by available Phase 1 test results and preliminary booster designs. Following Proposers Day, the Government expects industry to form teaming arrangements to support sharing of Phase 1 information. Phase 3 proposals should include system concepts that demonstrate design compatibility with one or more booster solutions derived from Phase 1 designs.

Preliminary Design Review

(PDR)/

Phase 2 Kickoff

Phase 3 Proposals

Summary: Available Booster PDR design details incorporated into Phase 3 proposals. Phase 1 technology maturation information incorporated into Phase 3 designs and proposals.

Phases 1&2: Selection of up to two performers that have achieved Booster PDR success criteria informed by successful TME1 test events.

Phase 3: Phase 3 proposals include Point of Departure system concept(s), subsequently updated with TME1 results for Phase 3 Kickoff meeting.

Booster TME 2 (hot/static fires)/ Booster Critical

System PDR Summary: Phase 3 performer(s) execute System PDR for the OPS that should include Phase 2 CDR-level booster design information substantiated by TME2 results.

Phases 1&2 Phase 3 Plan for Concurrent Execution Design Review

(CDR)

Phase 2: Primary testing effort complete. Test report should include TME2 results and recommended approach to further booster development and testing to support Phase 3 flight tests.

Performance validates approach to design in support of Booster CDR. Phase 2 CDR includes specifications and interfaces, design details, and performance assessments used to inform Phase 3 System/Subsystem CDR(s).

Phase 3: System Preliminary Design complete, including single booster configuration defined by weapon system integrator.

System CDR Summary: Phase 3 performer(s) execute System CDR for the OPS substantiated by technology maturation testing and risk reduction efforts.

Phase 2: N/A Phase 3: System Critical Design complete for all components in the OPS architecture.

Per section IV.B1.a, “Volume I, Technical and Management Proposal – System

Development Approach,” Phase 3 proposals must provide evidence of a program approach that ensures that the AUR design and performance is complementary to the adopted booster solution(s). This should be part of an overall description for accomplishing first stage motor development and AUR integration that is informed by on-going propulsion system design efforts (Phase 1 and Phase 2) and technology maturation results. To accomplish this, the proposed Phase 3 system development approach should demonstrate how available propulsion system design data and test results will be obtained and incorporated into the Phase 3 design effort. As well, the proposed Phase 3 Statement of Work (SOW) should clearly indicate any Phase 1 & 2 products leveraged in support of Phase 3 tasks. The proposed Phase 3 weapon system concept should also include one or more AUR POD designs that may incorporate different booster solutions. If multiple booster designs are included, the proposal should include a discussion of the benefits and risks, including unique considerations and/or approaches to system integration specific to each concept. Booster solutions originating from outside of the OpFires Phase 1 & 2 must be accompanied by substantiating technical, cost, and schedule data that achieves stated system performance objectives and prototype system demonstration timelines while effectively managing risk.

Prototype System Fabrication and Testing: OPS design completion, risk reduction, and component technology development should be documented by completion of the OPS CDR.

Following this, Phase 3 performers should commence fabrication, software coding, integrated component/subsystem testing, OPS assembly and checkout, culminating in integrated OPS flight tests. Phase 3 performers should plan and execute a minimum of three prototype system flight tests. The notional objectives for each are outlined below:

• Flight Test 1 (FT-1) Booster/Missile Characterization: This test should provide data to confirm that the integrated missile system can achieve associated OpFires performance objectives. At a minimum, this test should integrate a performer-provided [instrumented] payload mass simulator. The government retains the option of providing a GFE payload. Design and flight testing of the GFE vehicle will be based on Phase 3 performer-defined flight test objectives and should not drive any additional flight test requirements. Phase 3 performers will be responsible for integration of any GFE payload built to established booster interfaces and payload design constraints and should account for those costs (ROM only) in Phase 3c.

Additional details are provided in the BAA Classified Annex.

• FT-2 Minimum Range Demonstration: This test should demonstrate the energy management system capability to achieve the OpFires minimum range performance objective in an integrated missile system. At a minimum, this test should integrate a performer-provided [instrumented] payload mass simulator. The government retains the option of providing a GFE payload. Design and flight testing of the GFE vehicle will be based on Phase 3 performer-defined flight test objectives and should not drive any additional flight test requirements. Phase 3 performers will be responsible for integration of any GFE payload built to established booster interfaces and payload design constraints and should account for those costs (ROM only) in Phase 3c.

Additional details are provided in the BAA Classified Annex.

• FT-3 Maximum Range Demonstration: This test should demonstrate the capability of a fully integrated OPS (Launcher and AUR) to achieve the OpFires maximum range performance objective. The payload for this test will be capable of extended flight and inertial guidance, which the performer should be prepared to support during integration and test. Additional details regarding FT-3 are included in the BAA Classified Annex.

By PDR, Phase 3 performers are expected to augment these objectives consistent with their own flight test planning, risk mitigation activities, system performance objectives and system design solution. Performer test plans should include the approach to flight test data collection sufficient to verify the performance of the integrated system, ensure continuous telemetry coverage, and enable full post-flight assessment after each test to evaluate system performance. Additional flight test details and considerations for related elements such as payloads and potential test range locations are provided in the BAA classified annex.

C. OpFires Integrated Weapon System Task Plan

As identified in Figure 1, the OpFires Integrated Weapon System task will be conducted in three phases. Per section IV.B1.a, “Volume I, Technical and Management Proposal – Integrated Master Schedule,” Phase 3 proposals must include a detailed schedule tailored to the proposed system design, fabrication, and testing approach. That schedule should include additional key program events such as Interim Design Reviews, test readiness reviews, and/or component/subsystems tests and any additional key events that are unique to the performer’s approach. The next three sections describe the technical objectives specific to each part of Phase 3 followed by a description of systems engineering and design review expectations as well as a listing of expected Phase 3 deliverables.

Phase 3a: Phase 3a will include establishment of an operational weapon system conceptual baseline. Performers should demonstrate that all system requirements are traceable to performer-defined CONOPS, supporting analyses, trade studies, or other substantiating documentation and sources. The performers should substantiate that a complete set of system functions have been identified and demonstrate that those functions have been translated into an appropriate set of system requirements. System external interfaces should be clearly identified and requirements defined. This complete set of system requirements and interfaces should be allocated to major systems elements including the mobile launcher and AUR. The performers should demonstrate that the baseline system, launcher, and AUR conceptual designs close around the defined functional/performance/interface requirements, showing clear traceability between design features/solutions and requirements. A tailored SRR and CoDR for the OS and OPS should be completed approximately four months following contract award. SRR/CoDR should document any known divergences between the OS and OPS, including rationale for these divergences. The associated design review data package should include the system capabilities, system/launcher/AUR requirements, system/launcher/AUR conceptual designs, and an updated PSDP for review and baseline. As shown in Figure 3, SRR/CoDR will serve as the point where the focus of the design effort moving forward shifts to the OPS, in accordance with the PSDP.

As such, periodically in Phase 3, the performer is expected to update their OS conceptual design based on the refined OPS design as well as emerging results from risk reduction activities.

Development of a preliminary design for the OPS and continuation of component technology development, as identified in the PSDP, should follow completion of SRR/CoDR.

Performers are expected to conduct testing and analysis as necessary to mitigate identified risks, benchmark performance, and substantiate preliminary design maturity at the end of this phase.

During the PDR design cycle, performers should update their PSDP prototype system test plan.

The prototype system test plan should include the identification and description of the ground test facilities and flight test range(s) and launch platform(s) to be used for Phase 3 testing, the schedule of and detailed execution plan for pre-test, test, and post-test events, the scheme for collecting and processing telemetry, and appropriate security measures. Proposals should address these each at a summary level, while explicitly addressing the approaches to payload integration.

Selection criteria for ground test facility(s) should include costs and risks while considering availability, safety requirements, and system integration. Approximately six months following SRR/CoDR, performers should execute a PDR covering the preliminary design of the OPS, elements/segments, and subsystems, as well as the system test plan, for review and baseline. The preliminary design should clearly identify the selected booster configuration that is carried forward to system critical design phase. During the last month of Phase 3a, the performers should resolve any PDR liens and document the Phase 3a effort.

Phase 3b: Determinations to exercise Phase 3b options will be based on overall Phase 3a contract performance, technical performance and risk reduction demonstrated by the PDR design, and funds availability. Phase 3b will include development of a detailed design and initiation of long-lead procurements in support of the OPS. The updated PSDP, risk management and prototype system test plans developed in Phase 3a should continue to guide the system design activity. Ongoing development activities should include modeling and simulation, component and subsystem testing, and ground testing/demonstrations to synthesize a comprehensive technical performance baseline. Performers are expected to continue testing and analysis as necessary to mitigate identified risks, complete component technology development, benchmark performance, and substantiate critical design maturity at the end of this phase. A CDR should be conducted approximately nine months after the start of Phase 3b and prior to prototype fabrication/production to ensure that the detailed design solution satisfies the baselined requirements. This review should establish a “build-to” design, validate compatibility among the hardware and software configuration items, assess configuration item risk areas, demonstrate the capability to fabricate, code and integrate hardware and software, and review the hardware drawing and work packages. To achieve the aggressive schedule and enable early component fabrication and procurement, the Government anticipates rolling subsystem CDRs leading up to the final full prototype system CDR and final system Interface Control Document (ICD). Per section IV.B1.a, “Volume I, Technical and Management Proposal – Design Review Content and Data Package Development,” Phase 3 proposals must provide a disciplined and detailed rolling CDR approach in the context of critical path analysis, design maturity, and interface maturity to substantiate that the plan does not impart undue programmatic risk. Prior to CDR, the Government may request a full Phase 3c proposal with further instructions provided at that time.

During the final months of Phase 3b, the performers should resolve any post-CDR action items and commence component fabrication/procurement and testing.

Phase 3c: Phase 3c will include system fabrication, system integration and checkout, and subsystem/element/system tests that culminate in an end-to-end integrated test of the mobile launcher and AUR prototypes. The performer should execute their prototype system test plan that includes clear test objectives and tracks to performer-defined performance metrics, or other system capabilities for each test event. It is the Government’s desire that the prototype system provide compelling test demonstrations that validate the critical technology challenges and feasibility of the integrated system. These demonstrations should also substantiate the OpFires vision and generate program advocacy for continued operational system development. The prototype system test program should include approaches for early integrated system test events, multiple flight test events, additional flight test vehicles/back up hardware, and/or other approaches that mitigate risk to successful integrated system testing. The system demonstration and test plans must be developed in the context of program funding and schedule objectives.

Performers should develop balanced plans that leverage both hardware test, as well as modeling and simulation (validated by subsystem tests or flight data), to confirm performance capabilities and system attributes. The combination of Phase 3 flight tests, ground tests and simulation must show that the prototype system achieves BAA performance objectives and enables the capabilities envisioned for an operational system. The performer should also consider and identify recovery strategies to enable attainment of program objectives in the event that a system test does not achieve its objectives.

Systems engineering and program reviews

The Government expects that a rigorous systems engineering process will be used to identify operational integrated weapon system concepts and mature those concepts into a prototype system while identifying areas of high risk to be mitigated over the course of the Phase 3 effort. Phase 3 performers are expected to appropriately tailor their systems engineering processes such that they support tracking design maturation, managing risk, and documenting prototype system traceability to both established requirements and to the operational integrated weapon system. In this context, “system” includes all components and their integration: payload, booster, canister, launch platform, range systems, etc. Per section IV.B1.a, “Volume I, Technical and Management Proposal – System Development Approach” Phase 3 proposals must address the system engineering processes, including the approach for defining sufficient intermediate reviews to periodically assess progress toward flight demonstration. The Government seeks innovative approaches to enable a lean and affordable demonstration program that features early system/subsystem/component demonstrations or tests that mitigate key risks and/or substantiate key performance characteristics.

Per section IV.B1.a, “Volume I, Technical and Management Proposal – Design Review Content and Data Package Development,” Phase 3 proposals must describe the approach for executing system/subsystem SRR/CoDR, PDRs and CDRs. Content and entrance and exit criteria for these reviews should be tailored from a recognized industry or military standard (e.g., Defense Acquisition Guidance (DAG) guidelines available at https://dag.dau.mil and MIL-STD- 1521B are suggested sources) for appropriate application to a prototype development program.

Any tailoring of design review content and criteria must include an assessment of the design maturation of the prototype system with traceability to an operational system, technical risks unique to the chosen design concept, and incorporate demonstrable technology development and verification throughout the Phase 3 design and fabrication cycles. OpFires system design review expectations for those aspects of the program are outlined below followed by specific system SRR/CoDR, PDR and CDR guidance for incorporation into the performer’s comprehensive list of tailored design review criteria. Figure 3 outlines the preferred approach to design maturation of the OS and OPS concepts.

Figure 3: Preferred design maturation approach enforces desired OS-to-OPS design traceability

The tailored SRR/CoDR, PDR, and CDR entrance and exit criteria, as well as the tailored SRR/CoDR, PDR, and CDR content checklists, must be provided in the proposal to allow the government to understand and assess the adequacy of the proposed tailoring of these reviews.

The system hierarchy shown in Figure 3 and described below (System – Level 1, Element – Level 2, Subsystem – Level 3, Component – Level 4) is notional and may be replaced by the https://dag.dau.mil/ performer’s preferred topology so long as the lowest level of that topology is the component level of indenture in the performer’s system architecture. Design reviews and data package development will be incorporated in the performer’s system development process with required content provided via the appropriate Table 2 deliverable.

General:

• Requirements Development - A complete set of operational and prototype weapon system requirements is established down to the lowest expected level of the system hierarchy (i.e., system, element, subsystem, and component) for the subject review. Each requirement must include verification provisions, must include rationale statements and be traceable to a source and be validated for incorporation into the system baseline.

System interfaces must be identified and documented.

• Design Definition - The preferred operational and prototype system architecture is established down to the lowest expected level of the system hierarchy for the subject review, is traceable to and satisfies established requirements, and is sufficiently detailed to enable the next level of design definition. Appropriate design margins are identified and maintained. Operational system design considerations are documented including deviations/traceability to the prototype system.

• Risk Management - Technical risks are identified and assessed (e.g., consequence and likelihood). Mitigation plans are in place along with associated completion criteria and linked to the Integrated Master Schedule (IMS). Technical risks have been updated with results of any mitigation activities.

• Technology Development – Plans for upcoming technology development activities are documented and results from any completed technology development activities have been documented and reviewed for impacts to the Prototype System Development Plan.

SRR/CoDR:

• Requirements Development - System and element requirements are complete for both the OS and OPS. Initial verification methods (e.g., analysis, integration, test, demonstration) and complete verification statements explaining process and/or methods are documented.

Requirements must be attributable to a source and traceable to BAA performance metrics. External system interfaces are documented and intra-system interfaces are identified. As shown in Figure 3, it is anticipated that by SRR/CoDR, the OPS requirements will capture unique aspects associated with the PSDP such as flight test and test range requirements.

• Design Definition - OS and OPS conceptual designs are complete to the element level, close around documented requirements, include provisions for payload integration, and adequately demonstrate that performance achieves BAA objectives.

• Risk Management – Risks must include system design and flight test execution risks.

• Technology Development – Initial results of early proof-of-concept and risk mitigation activities are reflected in system requirements development and design definition.

PDR:

• Requirements Development - Subsystem requirements are complete for the OPS, including an initial allocation to and derivation of software requirements. Subsystem verification methods and statements are documented. Traceability and rationale for each requirement are documented. Internal system interfaces between major subsystems are documented with requirements allocated to each side of the interface.

• Design Definition – OPS preliminary design is complete to the subsystem level, closes around documented requirements, and adequately demonstrates that performance achieves BAA objectives. OS conceptual design is updated and performance estimates are provided.

• Risk Management – Risk update and mitigation status provided. High risks are mitigated to an acceptable level.

• Technology Development – Key system performance characteristic(s) substantiated with test/demonstration results.

CDR:

• Requirements Development – OPS Component requirements are complete. Component verification methods and statements for each requirement are established. Traceability of requirements across all levels the system hierarchy must be documented. All interface requirements, including hardware to software are documented.

• Design Definition - OPS critical design is complete to the component level and achieves compliance with all associated requirements. All interfaces are under configuration control. OS conceptual design is updated and performance estimates are provided.

• Risk Management – Risk update and mitigation status provided. Risks are mitigated to an acceptable level that supports component fabrication and software coding.

• Technology Development – System design is fully substantiated by documented analysis, test, and demonstration results.

In addition to the major design reviews identified above, the Government expects to participate in technical and programmatic reviews as the performer progresses through the Phase 3 program at the location of the performer’s activity (performer, subcontractor, range and/or Government facilities, etc.). Expected reviews include, but are not limited to, the following:

• Kick-off meeting, within 2 weeks of contract award.

• Ground Test Readiness Reviews.

• Failure and Engineering Review Boards.

• Flight Test, Range, and Range Safety Coordination Meetings.

• Pre-Ship Readiness Reviews.

• Airworthiness Certification Board Review(s).

• Flight Readiness Reviews.

• Post Flight Reviews.

• Phase 3 Final Review.

• Weekly programmatic and technical status teleconferences.

For reporting regular status to the Government, the performer will schedule reviews on at least a quarterly basis. These reviews can and should be aligned with other significant program events to the extent practical. The primary purpose for these reviews is to evaluate technical and programmatic progress, gauge team performance, and assess the need for any modifications to the overall program plan. These reviews will include a Program Management Review, including financial and staffing status, and a review of the Integrated Master Schedule (IMS), including critical path analysis. At a minimum, it is expected that the following events and activities will be addressed as part of every quarterly review:

• Technical development status update, including design updates, updated performance predictions, new technical issues and risks, risk reduction activities and major upcoming events in the IMS, such as long lead procurement, system integration tasks, ground test, and flight test operations.

• Financial performance and staffing status.

• IMS, including critical path analysis.

• Test planning and review of test results.

• OS/OPS traceability analysis updates.

• Prototype System Development Plan updates.

• OS cost and affordability updates.

Phase 3 deliverables

Table 2 outlines the minimum deliverables expected. Per section IV.B1.a, “Volume I, Technical and Management Proposal – Management Approach” Phase 3 proposals must identify any deviations from or additions to this list. Proposals must also identify submission frequency for deliverables where it has not been defined. Electronic copies of all program deliverables and other Government-owned material developed in the program shall be delivered to the Government at the completion of the program in lieu of paper deliverables, with the exception of the final report. At program conclusion, the Government will work with the performer to disposition any residual OPS hardware in a manner that maximizes the follow-on value from the Government’s investment, potentially including assignment to another contract.

Table 2: List of Phase 3 contract deliverables

Item # Deliverable Frequency 1 SRR/CoDR, PDR, CDR, and Interim Review data packages and presentations which will include the following:

• OS Concept of Operations (CONOPS)

• Requirements Specification(s) and associated Requirements

Verification Traceability Matrix

• Interface Control Document(s), including appropriate

Hardware/Software ICDs

• Design drawings (in CAD format) and schematics

• Design data package substantiating OS and OPS performance estimates, including basis of analysis (e.g., empirical data, simulation codes, handbook methodologies) and methodology used

• Prototype System Development Plan inclusive of component technology development status, prototype system design, and OPS system test plan

• OS-to-OPS Traceability Assessment

• Risk Management and Mitigation Plan

• Test results and analyses for all major risk reduction and component technology development activities

10 working days in advance of review

2 Configuration, Performance, and Weight Status Report Quarterly 3 Risk Management Plan, including mitigation status Quarterly 4 Component technology development status Quarterly 5 Integrated Master Schedule Monthly 6 Test plans, procedures, reports for major ground and flight test events

(e.g., Ground Vibration Test, Flight Test)

7 Pre-test predictions, test results, and analysis for all major risk reduction activities and demonstrations

15 days pre & post-test event

8 All models, databases, and algorithms (algorithmic descriptions and software implementations) required to implement a fully representative 6 Degree of Freedom simulation of the performer’s system design

9 Software development/management plan 10 Document that provides the system characteristics that serve as the basis for the Guidance, Navigation & Control design, simulation, and analysis

11 Integrated Data Handling and Analysis plans (flight tests) 12 Raw and processed flight data 13 Range, range safety, system safety, treaty-compliance and airworthiness documentation

14 Post-flight quick look test reports 24 and 72 hours post-flight

15 Mishap and anomaly investigation plan

Item # Deliverable Frequency 16 Flight Test Trajectories and Safety Matrix 17 Detailed photographic record of the progression of manufacturing, integration, and test activities for the flight demonstration system

18 Security Standard Operating Procedures (including Data Protection and OPSEC Plan)

30 days after award of each Phase

19 Transportation, handling and storage plans 20 OPS Cost Model to WBS Level 3, including Basis of Estimate to WBS

Level 3 6-months

21 OS Recurring Cost Model to WBS Level 3, including Basis of Estimate to WBS Level 3

6-months

22 Phase 3a/b/c final reports End of each Phase

23 Data Accession List that includes the inventory of technical documents generated under the program and their respective data rights

End of each Phase

24 Final OS to OPS Traceability Analysis, including a design plan, risk reduction approach, and test plan, including Rough-Order- of- Magnitude (ROM) schedule and cost, needed to fully realize an operational system design

End of Phase 3c

25 Program Executive Summary and Final Report End of Phase 3c

D. Government Management Approach and Operations

The Government recognizes that a streamlined, collaborative management approach is essential to achieving the program technical, cost, and schedule…