DARPA-SN-25-08_Attachment_01-Final.pdf

DARPA-SN-25-08 Attachment 01

Title: Pulling Guard Program Objectives Posted: March 07, 2025 CLASSIFICATION LEVEL: Controlled Unclassified Information (CUI) and SECRET level TECHNICAL POC: Dr. Christopher Kent, TTO Program Manager E-MAIL: DARPA-SN-25-08@darpa.mil

Dates/Time: All Times are Eastern Time Zone (ET)

• Industry Day: March 18, 2025

• Question Submittal Closed: March 25, 2025 at 4:00 p.m.

DARPA-SN-25-08 Amendment 01 Disclaimers and Important Notices

This Special Notice (SN) is not a Broad Agency Announcement (BAA) and/or a request for proposals. Responses do not bind DARPA to any further actions related to this topic, including requesting follow-on proposals from respondents to this SN.

DARPA will not provide reimbursement for costs incurred should you chose to respond to this SN.

Respondents are advised that DARPA is under no obligation to acknowledge receipt of the information received or provide feedback to respondents with respect to any information submitted under this SN.

The Pulling Guard sections below provide information to potential proposers about the purpose and structure of the Pulling Guard Program in advance of Industry Day and a planned BAA.

Pulling Guard Objectives

The Pulling Guard program aims to create an ecosystem in which two commercial entities provide semi-autonomous point-defense overwatch/escort systems (a “Pulling Guard system”) that delivers escort services in partnership with the Department of Defense (DoD). These systems have several key attributes/features to meet these objectives:

• Pulling Guard systems will provide escort at a significantly reduced total life-cycle cost (to the DoD and commercial operators) compared to traditional large combatant escort in a high-threat environment.

• Pulling Guard systems will be commercially owned and provided under contract to the vessel under escort with a “protection as a service” model.

• Pulling Guard services will be delivered in partnership with the military (initially the United States Navy) with appropriate authorities for the engagements and munitions involved.

• Through the envisioned business model, a commercial entity will produce, own the system, generate income, and manage the maintenance, and the military/government will operate appropriate aspects of the system when a Pulling Guard system is providing escort services.

• Pulling Guard systems will retain remote military operators in the loop for engagement authority, supervision, and making high-consequence decisions.

• Pulling Guard systems should not require permanent modifications to protected vessels and be easily detachable from the protected vessel for loitering offshore between missions and rapid redeployment with the next outbound vessel requiring escort. This feature is key because merchant and logistics vessels face prohibitions on entering port while armed.

• Pulling Guard will retain a command and control (C2) capability with the protected vessel to keep the ship’s master in the decision-making loop.

• Pulling Guard should use passive (preferred) or low probability of detection (LPD) sensing techniques to enable operations in a contested environment.

• Pulling Guard systems should have critical interfaces managed by a consortium established to ensure easy interoperability/modularity of sub-systems and unified command and control architecture.

• To retire risk early, Pulling Guard system development will use an iterative development model focused on a build-test-build for both hardware and software with hardware-rich risk reduction events.

• Pulling Guard systems will be developed using an iterative design approach that enables production and fielding of a flexible, scalable, and cost-effective solution to suit the defense needs of both commercial and DoD logistics vessels.

Pulling Guard Summary

The Pulling Guard Program has three focus areas (FA) with potential for multiple performers in the first two FAs. Focus Area 1 (FA1) is the kill chain design with sensor package development and choice of effector with components shown in green in Figure 1. Focus Area 2 (FA2) is platform design with components shown in purple in Figure 1 (of note, effectors pertain to both FA1 and FA2 efforts). FA2 performers must develop a commercial business case for transition.

FA1 performers may optionally choose to develop a commercial business case for transition.

Figure 1. Pulling Guard Conceptual Diagram

FA1 and FA2 performers are expected to work collaboratively to ensure the resulting Pulling Guard system of systems is modular and utilizes common interfaces such that any platform developed by the FA2 performers can host any sensor suite developed by FA1 performers. Focus area 3 (FA3) addresses the business development for Pulling Guard systems, and the doctrine, policy and legal challenges. FA3 is primarily DARPA led with support required from FA1 and FA2 performers. A more detailed description of each focus areas is included below.

A successful Pulling Guard system’s overarching capabilities include:

• Sensors that un-detectably detect and track small surface threats at ranges for multiple engagements.

• Scene interpretation that supports rapid remote operator-in-the loop decision-making.

• Sensors that un-detectably support targeting with government-provided effectors.

• Integration with any logistics vessel via a single connection only for towing (i.e., power generation organic to Pulling Guard platform).

• Ability to engage and retire Unmanned Surface Vehicle (USV) threats to the platform under escort

• Rapid connect and disconnect from the protected vessel subsequent to port departure and prior to port entry, respectively

• Common physical and digital interfaces

• Delivered by a commercial entity under a services business model. The desired end state of the program is to have two complete and functional demonstrator Pulling Guard systems that can then be transitioned into commercial production and service delivery by the performers.

Pulling Guard Structure

The Pulling Guard program is a 39-month, two-phase program grouped into three (3) focus areas. Proposals should consider the full scope and vision of the program as illustrated in Figure 2 below, however, it is anticipated that the Government will only request proposals for the following:

• Phase 1 Iterative Design Maturation:18 months duration

• Phase 1 Option: 3 months duration

• Phase 2 Integration, Manufacture, Demonstration and commercialization rough order of magnitude (ROM): 21-month duration

A detailed Phase 2 Integration, Manufacture, Demonstration and commercialization proposal is not requested at this time.

Figure 2: Program Schedule

Pulling Guard Focus Areas:

FA1- Sensing, Sensemaking and Targeting

a. This focus area requires development of a sensor package that can detect small, high-speed, agile targets in a complex environment and include autonomy to evaluate potential threats; connectivity with a remote supervisor; and autonomy to complete multiple kill chains with a set of government-defined low-cost effectors (described below). FA1 performers shall:

• Develop a robust, cost-informed kill chain(s) that meet the mission-level performance objectives listed in Table 2 within the Program Constraints in Table 3 and with the effectors defined in Table 4.

• Deconstruct the mission-level metrics into a set of technical performance metrics (TPMs), which support incremental system maturation.

• Conduct incremental risk-reduction or validation events for critical systems and services (e.g., software).

• Develop an elevated sensing platform for passive or low probability of detection/intercept.

• Develop the platform physical interfaces for sensor stability (e.g., tension control) and required computing power.

• Develop a system that addresses the detection phenomenology at longer-ranges necessary for multi-threat raids.

• Develop autonomy required for sensor stability management, object detection, scene interpretation, threat assessment, targeting of multiple low-cost effectors (e.g., laser guided).

• Develop the autonomy and interface for a single Title-10 operator to supervise and make lethality decisions on the end-to-end mission for multiple Pulling Guard platforms.

• Participate in the consortium, which is a cross-performer working group which manages the development of common physical and digital interfaces that enable Pulling Guard sub-system swaps and ongoing development for future threats

• Develop a solution that addresses hardware reliability and anti-tamper/anti-theft features.

• Develop a robust solution that addresses software resiliency (e.g. Formal Methods) through design and development vice post-delivery compliance.

• Complete Situational Awareness / Overwatch demonstration event on surrogate platform.

• Provide data and artifacts that support intra-government coordination required to authorize force employment and operations

• Complete the milestones in Table 5 and the deliverables in Table 6.

FA2 Platform Design and Integration

This focus area centers on hull/platform design, integration, and marinization that enables connection with the protected platform and open interfaces (physical and digital) that enable connection with any FA1 performer’s sensor package. While FA2 proposers are welcome to explore all options for the towed platforms they are encouraged to focus on proven small hullforms with and concentrate on evolution and marinization of critical subsystems: line management, power harvesting, position management, etc. FA2 performers shall:

• Develop a cost-informed platform that meets the mission-level performance objectives listed in Table 2 within the Program Constraints in Table 3 and hosts multiple effectors defined in Table 4.

• Deconstruct the mission-level metrics into a set of technical performance metrics (TPMs), which support incremental system maturation.

• Conduct incremental risk-reduction or validation events for critical systems and services (e.g., software).

• Develop autonomy for power management and tension management with protected platform.

• Develop power system that generates, stores for operation, and supports the FA1 sensor package.

• Develop a system that enables rapid connect and disconnect from protected platform.

• Develop a solution that addresses hardware reliability and anti-tamper/anti-theft features.

• Develop a robust solution that addresses software resiliency (e.g. Formal Methods) through design and development vice post-delivery compliance.

• Develop a cost-informed platform that meets the mission-level performance objectives listed in Table 2 within the Program Constraints in Table 3 and hosts multiple effectors defined in Table 4.

• Deconstruct the mission-level metrics into a set of technical performance metrics (TPMs), which support incremental system maturation

• Conduct incremental risk-reduction or validation events for critical systems and services (e.g., software).

• Develop autonomy for power management and tension management with protected platform.

• Develop power system that generates, stores for operation, and supports the FA1 sensor package.

• Develop a system that enables rapid connect and disconnect from protected platform.

• Develop a solution that addresses hardware reliability and anti-tamper/anti-theft features.

• Develop a robust solution that addresses software resiliency (e.g. Formal Methods) through design and development vice post-delivery compliance.

• Participate in the consortium, which is a cross-performer working group that manages the development of common physical and digital interfaces that enable Pulling Guard sub-system swaps and ongoing development for future threats.

• Accomplish milestones in Table 5 and produce deliverables in Table 6.

• Provide data and artifacts that support intra-government coordination required to authorize force employment and operations.

• Develop a business plan for the end-to-end system (i.e., platform, sensors, effectors, operations, logistics, etc.) for a commercial transition pathway.

• Complete the milestones in Table 5 and the deliverables in Table 6.

FA3 Ecosystem, Commercialization and Transition

This DARPA-led focus area centers on developing an Ecosystem for Commercialization and Transition that provides a cohesive design between sensor package, platform, and effectors into a fully operational system of systems with a business plan for procurement and delivery as a commercial service. While not a unique proposal area, this focus area requires coordination between Government and FA1/FA2 performers on the non-technical aspects of new capability delivery, which includes legal implications and Doctrine, Organization, Training, materiel (support equipment), Logistics, Personnel, Facilities, and Policy (DOTmLPF-P) needed for employment.

When requested, the high-level Phase 1 tasks proposers should address in proposal submissions are delineated in Table 1 below.

Proposers Scope of Phase 1 Proposal

FA1

Iterative/Agile hardware and software development* Support ecosystem interface development* Support data/artifacts required for the DARPA-led FA3 efforts* Conduct Overwatch / Situational Awareness demo (e.g., barge) Fixed price Phase 1 Option CLIN Rough order of magnitude cost for Phase 2

FA2 Iterative/Agile hardware and software development* Support for ecosystem interface development*

Support data/artifacts required for the DARPA-led FA3 efforts* Develop business case and commercial transition pathway Fixed price Phase 1 Option CLIN Rough order of magnitude cost for Phase 2

Table 1: Phase 1 Proposal Scope

*Note Figure 2 Program Schedule shows the iterative design and test cycles. FA1 and FA2 performers shall work collaboratively on cross-performer integration, commonality and both physical and digital interface controls. Performers will meet with the government team to finalize required decisions. Each performer’s iterative design and test cycles will be interlaced with cross-performer the Technical Interchange Meetings (TIM) (reference the Program Execution section below) for interface commonality coordination and support to operational employment.

The Government expects cooperation and implementation of the common physical and digital interfaces of paramount importance.

Program Plan

As previously stated, the Government expects selected FA1 and FA2 performers to work together on common, cross-performer interfaces, which will be reviewed during incremental engagements and provided as Program deliverables by each performer.

1. Program Metrics

To achieve program objectives, the Pulling Guard Program includes metrics related to technical performance as reflected in Table 2, which delineates which metrics apply to FA1 and FA2. Additionally, Table 3 provides an overview of constraints applicable to all FAs to guide solutions toward a system-of-systems that completes the end-to-end mission and presents a promising case for commercialization and transition to operational use.

Metric Performance Objective Applicable FA

1. Probability of Raid Defeat 85% vs. raid of three (3) USVs FA1, FA2

2. Prob. Detection by Effector Range 95% FA 1

3. False alarms to operator (per day) 2 FA 1

4. Overwatch Endurance 14 days with protected vessel operating at 12-18 knots

FA1, FA2

5. Sea State (SS) Limit (operational) SS 4 FA1, FA2

6. Sea State (SS) Limit (survive) SS 6 FA1, FA2

Table 2. Program Metrics

Constraint Performance Objective

Port Entry and Exit Protected vessel must be able to enter and exit neutral ports with minimal (< 15 minute) delay attributable to the Pulling Guard system

Magazine Depth Supports three (3) raids per mission

Repair and Maintenance Depot-based (no dry dock), economical, scalable concepts for maintenance in a standard small commercial boat yard

Autonomous station-keeping When un-tethered from a Protected Vessel, should be able to maintain position in low-idle mode within a 10-meter radius for up to 24 hours

Marinization All physical components must be constructed or retrofitted to withstand the maritime environment

Cost Ship design and maintenance architecture traceable to cost- reduction strategies

Communications

Data link requirements for health/status, threat reports to remote operator, and effector release.

Data link must support electro-optical and/or infrared images sufficient for engagement decision (i.e., combat identification).

Support limited interactions with remote supervisor and be tolerant of quality-of-service degradations.

Provide a situational awareness display to the protected vessel operator and enable cueing to potential threats.

Availability Materiel Availability of at least 3:1 (time ready for at-sea operation vs. undergoing maintenance).

Table 3. Program Constraints

2. Government Furnished Effectors

The list of effectors applicable to the Pulling Guard system is shown in Table 4, and updates are allowed based on performer recommendations in the first six (6) months after kickoff.

Both FA1 and FA2 performers must coordinate to ensure their components complete the effects chain against expected targets, and the information in this table applies to both FA1 and FA2 efforts.

Effector Description

Poniard

This 2.75-inch diameter guided rocket is a South Korean design demonstrated at Rim of the Pacific Exercise (RIMPAC) 2024 and incorporates an Imaging Infrared (IIR) seeker that provides fire-and-forget capability. Advertised range of 8 km (5 mi).

Advanced Precision Kill Weapon System

(APKWS) II

This 2.75-inch diameter guided rocket is a United States design update from the Hydra 70 rocket and incorporates a semi-active laser guidance kit for low-cost engagement. Advertised range of over 5 km (3.1 mi)

Stinger or Fan Infantry Missile

(FIM)-92

This 2.75-inch diameter guided missile is a United States design with infrared guidance system. Advertised range of 4.8 km (3 mi).

Air Interception Missile (AIM)-9X Sidewinder

This 5-in (127.0 mm) diameter missile is a United States design that includes an active optical target detector (AOTD), proportional navigational guidance, and, in the Block II variant, lock-on-after-launch capability via added data link, thrust vectoring maneuverability, and advanced IIR seeker to hit targets behind the launching platform.

Despite the Sidewinder’s history as a solely air-to-air missile, the AIM- 9X can attack surface targets. Although the exact range is classified, the missile is optimized for short-range engagements (~20 mi).

Tamir Interceptor

This 6.3-inch (0.16 m) diameter missile is an Israeli design which incorporates active radar seeker and data link for in-flight updates.

Currently a component of the Israeli Iron Dome system and integrated into the Combat-Prove Iron Dome (C-DOME) system for maritime application. Limited data on capability in a counter USV role.

Advertised range of 70 km (43 mi).

Joint Air-to-Ground Missile (JAGM) or

AGM-179

This 7-inch diameter guided missile is a United States design and incorporates a semi- active laser and millimeter wave radar seeker.

Advertised range of 8 km (5 mi).

Table 4. Government Furnished Effectors

3. Program Milestones and Deliverables

A summary of required program milestones is presented in Table 5 and required program deliverables are presented in Table 6. Proposers are expected to include additional milestones based on their technical execution plan. Examples may include risk reduction demonstration events and iterative hardware reviews.

Milestones Due date Description

Kick-off meeting presentation 1 Month after award (MAA)

Presentation that summarizes the Phase 1 plan, highlighting changes made since proposal submission and details for the first three months of Phase 1.

Technical Status Teleconference Monthly

Teleconference to discuss progress over the previous month and upcoming month plans.

Business Case Kickoff

** FA2 Performers, FA1 Optional

3 MAA

Expanded details and actions to date beyond Oral Proposal on business case approach alignment with technical decisions.

Performer should demonstrate understanding of program plan and Phase 2 vision.

Iterative Design Reviews 4-6 (approx. quarterly)

Presentation on the iterative development progress toward technical objectives and shall include:

• Risk reduction / test event results

• Update to program risks

• Current interface/protocol standards; identify cross-performer alignment challenges.

Note: Critical interfaces will be approved and managed by the consortium.

• Hardware design with changes from last review

• Software architecture with changes from last review

• Tasks: Completed and Outstanding efforts (backlog)

• Management update (cost, schedule, personnel)

• Government input or assistance required

Technical Interchange Meetings

Quarterly

Cross-performer meeting to verify alignment on mission thread, threat, environment, and review interfaces standards common across FA1 and FA2 performers.

Overwatch / Situational Awareness Demo

** FA1 Performers only

16 MAA

• Demonstrate performance of the sensor package and the associated software in passive detection (or low probability detection/intercept) , threat assessment, and tracking.

• Validate effector performance in Live Virtual Constructive simulation, which uses real-world data collection for sensor and track accuracy.

• Communication and data reports to remote operator for engagement decision.

• Quantitative results that validate proposed TPMs and mission level metrics

• Demo is allowed on surrogate platform with lower SS than Table 1 requirement.

Table 5. Program Milestones

In addition to the explicit Phase 1 milestones above, Phase 1 proposers are expected to demonstrate via technology maturation and risk reduction activities a readiness to proceed through Phase 2 of the program.

Deliverable Due date Description

Operation Security Plan (OPSEC) and Controlled Unclassified Information (CUI) Mitigation Plan

1 MAA

and for any change in security posture

Plans used to identify and monitor security activities during the performance of a contract. Both plans are intended to be a living document that will require periodic updates throughout the life of the contract.

Technology Maturation Plan (TMP)

Initial at kick-off, then updated at iterative design review

Document that defines the technology maturation plan in iterative model linked to risks and program schedule.

Must include current risk assessment and progress against risk waterfalls.

Risk reduction activity report

< 2 weeks after completion and at iterative design review

Report or annotated briefing that describes the major risk reduction activity, outcomes, and consequences to design and development.

Requirements Deconstruct 3 MAA

The Technical Performance Measures (TPMs) aligned to each sub-system necessary to deliver the Pulling Guard solution

Integrated Master Schedule (IMS)

Initial at kick-off, then updated at iterative design reviews

Iterative program schedule, incorporating detailed plans to test hardware, test software, and incrementally review designs through stages of maturity.

Resilient Systems Implementation Plan

3 MAA, then updated at iterative design

Document software architecture, data formats, and processes for the design, implementation, and delivery of reviews or more frequently resilient software. Performers should leverage the DARPA Guide for Formal Methods to Deliver Resilient Systems in development of this plan.1 Identify software modules for which export controls may require unique development to expand the addressable market.

Technical and financial status report Monthly Report that provides technical, financial, and schedule updates.

Phase 2 Approach

** FA2 Performers, FA1 optional

11 MAA

Initial plan for Phase 2 that includes subsystem technical selection, update to the initial rough order of magnitude (ROM) cost, and the current commercial business plan.

Overwatch / Situational Awareness report

** FA1 Performers only

17 MAA

Technical report that supports performance assessment and integration with modeling and simulation environments (e.g., probability of detection versus range curve, false alarm rate, track quality, etc.).

Digital Design Files 17 MAA

Product representation compact (PRC) design files for major components in a non-proprietary format that enables integration and visualization in commercial simulation environments (e.g., Unity, Unreal Engines).

Phase 1 final report 18 MAA

Report that details all Phase 1 activities, capturing top-level results of all trade studies, design performance analyses, and demonstrator design.

Manufacturability Study Pending Option

Review of technical approach for manufacturing readiness and cost saving options for Phase 2.

Table 6. Program Deliverables

Reports shall include narrative content that provide added detail beyond slides presented during review meetings.

1 Link to SAM.gov for DARPA I2O Request for Information (RFI), https://sam.gov/opp/1fbef90fc098420e9e942f9ce2b643f5/view

Program Execution Program execution should include regular collaborative meetings and teleconferences to inform the Government of program, design, and development status. During Phase 1, quarterly Technical Interchange Meetings (TIM) to support cross-performer integration on commonality on interface controls, both physical and digital, with required decisions by the Government. At substantial decision points, in-person technical reviews should be held to solicit Government input balancing objectives and risk. Proposers should aggressively identify technical and programmatic risks and resource parallel risk reduction paths over the life of the program. The minimum anticipated meeting rhythm is outlined below and may include multiple meetings on the same day.

• Monthly program management tag-ups (Virtual Meetings)

• Bi-weekly performer tag-ups for each proposed Integrated Product Teams with maximum commonality with performer’s iterative development cycle vice unique meetings focused on contract compliance. Discussion topics should include completed activities, backlog, next steps and risk update (Virtual).

• Quarterly Program Reviews to convey technical progress and overall program performance (In-person).

• Technical Interchange Meetings (TIMs) on specific areas of interests or substantial decisions (Virtual or Virtual + In-Person)

Throughout the design process, iterative analysis of alternatives should be used to select configurations and hardware components. Software and subsystems should be tested to verify accomplishment of deconstructed technical requirements, and that sufficient design margin remains for a semi-autonomous platform. Subsystem designs and risk reduction demonstrations should account for potential variability in areas where no validated models exist.

1. Characteristics Required of all FAs

a. Resilient Software - The Department of Defense is focused on delivering resilient software capability at the speed of relevance. Resilience implies software that is high-quality, secure, and able to withstand and recover in the face of challenging conditions.

See “Department of Defense Software Modernization Strategy” November 2021, p. 2.

DARPA’s preferred method to achieve this goal is the use of formal methods. “Formal Methods” is an umbrella term for a range of mathematically rigorous techniques for producing software along with machine-checkable evidence that the software does what it is supposed to do and, perhaps more importantly, does not do what it is not supposed to

do. Used judiciously, formal methods can eliminate virtually all exploitable vulnerabilities in software. For more information on Formal Methods, please refer to the draft Best Practices Guide posted on https://sam.gov/opp/1af518c646e44ced895efe56f71f6df6/view.

b. Commercialization Transition Description - Beyond the technical focus, the Pulling Guard proposal and solution approach should deliver a system with viable commercial application under a services business model. Proposers may use DARPA’s Embedded

Entrepreneur Initiative (EEI; https://eei.darpa.mil/) in development of the long-term business viability in parallel with platform design trades, system development, and risk reduction events. A description of EEI from the website follows:

“The Embedded Entrepreneur Initiative provides funding to connect DARPA’s technical teams with commercialization experts. We provide funding, mentoring, and connections. The EEI grants DARPA teams with access to techno-economic market mapping to understand the commercial market for the technology’s success and connections to investors and corporate partners to bring in curated capital.

DARPA will continue to scale the EEI program through regional Commercial Accelerators.”

The Pulling Guard performers shall ensure that the technical teams and business/entrepreneurial teams work in parallel, leveraging the EEI resources as appropriate, in the development of viable design solutions for the commercial “protection as a service” business model.

c. Weapon System Autonomy – Pulling Guard is planned as an operator-supervised system where autonomy manages platform operation (e.g., tension control), detects and identifies threats, makes threat-level assessment recommendations, and performs threat track development. The proposal and system solution shall provide the remote operator with reports and real-time information on system status/health, contact data (e.g., latitude, longitude, course, speed, time to intercept, closest point of approach, etc.), threat assessment recommendations, and imagery (as required for identification) that supports high-consequence decision making by a remote operator. Proposers shall not suggest autonomous weapon system solutions as defined in DoD Directive 3000.09.

Interface Coordination - As discussed above, all performers shall work to develop a common set of interfaces through the use of Integrated Product Teams and Technical Interchange Meetings (TIMs) that enable any FA1 performer system to interface (physically and digitally) with any FA2 performer. A program deliverable is commercial standards for the internal interfaces for data exchange and physical interfaces between FA1 and FA2 performers. Phase 1 requires interface validation digitally between performers, and Phase 2 may include validation via system swap between the commercial teams https://eei.darpa.mil/