RFWP HMIF Dismounted Common Controller Revision 1.pdf

Request for White Papers (RFWP)

Human Machine Integrated Formations

Dismounted Common Controller Requirement

Issued by:

Rapid Capabilities and Critical Technologies Office (RCCTO) 3307 Wells Road

Redstone Arsenal, AL 35898

Request Issue Date: 21 May 2024 Submission Deadline: 24 June 2024

RFWP/CSOW HMIF Dismounted Common Controller

Table of Contents

1.0 Introduction/Background

2.0 Project Description

3.0 Government Objectives

3.1 Scope

3.2 Key Features

3.3 System Functionality

3.4 Sensor Integration

3.5 Sub-System Integration

3.6 Communication

3.7 Safety Concept/Case requirements for the dismounted common controller

3.8 Performance Requirements

3.9 Ergonomics requirement for the dismounted common controller

3.10 Haptics

3.11 Ruggedization

3.12 Lighting

3.13 Development and Testing

3.14 Training and Documentation

3.15 Cybersecurity

3.16 Preliminary Design

3.17 Design Refinement

3.18 Operational Prototype Production

3.19 Test and Demonstrations

3.20 Data Deliverables

3.21 Environmental and Safety

3.22 Government Furnished Property, Government Furnished Equipment, ,

3.23 Period of Performance (POP)/Delivery Date and Exit TRL

4.0 Procedures

5.0 Non-Government Personnel

6.0 Points of Contact

7.0 Response Dates

8.0 Contract Structure & Funding Availability

8.1 Funding

8.2 Instrument Type

8.3 Project Award Value

8.4 Period of Performance/Delivery Date

9.0 White Paper Preparation & Submission Instructions

9.1 White Papers & CSOW

9.2 Format of RFWP Submittals

9.3 Content of WPS

9.4 Content for the CSOW

9.5 WP Approach & CSOW Content

9.5.1 Technical Approach

9.5.2 Qualifications and Experience

9.5 Timeliness of RFWP Submissions

9.6 Solution Presentation

10.0 Proposal Preparation and Submission Instructions

10.1 Technical Content

10.2 Cost Proposal Content

10.3 Submission of Cost proposal

11.0 Evaluation Information

11.1 White Paper & CSOW Evaluation Criteria

11.1.1 WP/CSOW Evaluation Criteria #1: Technical Approach

11.1.2 WP Evaluation Criteria #2: Qualifications and Experience

11.1.3 WP Evaluation Criteria #3 – ROM Cost

11.2 Proposal Evaluation Criteria

11.3 Offeror Exchanges

12.0 Award Information

13.0 Other Information

13.1 Follow-On Production Work

13.2 Security & Anti-Terrorism Operations Security (AT-OPSEC)

13.2.1 AT Level I Training

13.2.2 Access and General Protection Policy and Procedures

13.2.3 Non-Eligible Contractors for CAC Requiring Installation Access

13.2.4 iWATCH Training

13.2.5 Contractor Army Training Certification Tracking System (ATCTS) Registration

13.2.6 Requirement for OPSEC Training

13.2.7 Information Assurance/Information Technology Training

13.2.8 Information Assurance/Information Technology Training Certification

13.2.9 Threat Awareness Reporting Program (TARP)

13.2.10 Data and Report Markings

1.0 Introduction/Background

The U.S. Army’s Rapid Capabilities and Critical Technologies Office (RCCTO) is issuing this Request for White Papers (RFWPs) with the intent of awarding an Other Transaction Agreement for Prototype (pOTA) in accordance with (IAW) 10 U.S.C. § 4022. The RCCTO invites interested entities to provide white paper technical inputs, suggestions, solutions, prototypes, or concept descriptions, to portions or all of the requirements outlined herein. The Army has designated a RCCTO and Army Futures Command (AFC) team to define and prototype integrated solutions for robotics in order to develop and manage a human-machine integrated formation (HMIF) architecture that will guide emerging Robotics and Autonomous Systems (RAS) capabilities. This team will conduct prototyping, tests, and evaluations using soldier touch points that will enable valuable warfighter feedback on the system and drive system improvements.

The RCCTO invites interested entities to review the embedded statement of objectives (SOO) in Section 3 below and provide technical write ups for products/solutions that could meet or exceed the objectives for a Dismounted Common Controller. RCCTO, in coordination with Army Futures Command (AFC), plans to advance robotics and autonomous systems (RAS) technologies by delivering operational prototypes for the HMIF project. The Dismounted Common Controller solution/capability will be integrated into the Infantry and Armored robotic platforms as part of the overarching HMIF deliverable.

Problem Statement: Winning wars today and in the future will depend on adaptive leaders, skilled Soldiers, and well-trained teams empowered with advanced technologies. The U.S. Army must develop capabilities under the Robotic and Autonomous Systems (RAS) that will allow future Army forces to conduct operations consistent with the concept of multi-domain battle, projecting power outward from land into maritime, space, and cyberspace domains to preserve Joint Force freedom of movement and action. A critical capability being pursued by U.S. Army and the Joint Force is the Integrated human-machine teams which will allow forces to learn, adapt, fight and win under uncertain situations with the strategic employment of Unmanned Ground Systems (UGS) and Unmanned Aircraft Systems (UAS) with a common control architecture.

Common robotic and autonomous control is the ability for one common software package to control an array of ground and air systems and is critical for maximizing management of multiple and varied Robotic Autonomous Systems. Common control will allow one Soldier to control multiple robots with one controller reducing physical and cognitive burdens on Soldiers operating the system. Common control also overcomes operational limitations (data sharing / encryption / range / transferring control of platforms and payloads), while realizing cost savings and simplifying sustainment through compatible display units, batteries, and radios.

The Offeror shall include whether it’s company currently has a Facilities Clearance Level (FCL) of at least SECRET and SIPRNet. If the Offeror does not currently possess an FCL of SECRET and SIPRNet, the Offeror shall describe their progress and plan to obtain FCL and SIPRNet. A detailed timeline of the progress and plan is required. Unless RCCTO is aware of information which would likely prevent granting FCL/SPIR access, RCCTO is willing to sponsor an offeror for an FCL of SECRET and/or SIPRNet.

The RCCTO cautions Offerors that this RFWP will be used first to inform current and future requirements and might not be used to award any prototype projects. However, responses and evaluations may be shared with similar DoD agencies who may pursue this technology and RCCTO may utilize this RFWP to assist with the formation of contracts in conjunction with or on behalf of those other DoD agencies.

2.0 Project Description

This Dismount Common Controller effort will build on the work and demonstrations of prior Hand- Held controller efforts conducted by the DEVCOM Armaments Center (DEVCOM AC) and the DEVCOM Ground Vehicle Systems Center (DEVCOM GVSC). Prior efforts include the Common Robotic System (Individual) or CRS-I, the Soldier Control Kit Common Software (Hardware Configuration Wearable / Tablet / Mounted) facilitated by DEVCOM GVSC , and the robotic controller facilitated by the DEVCOM AC/Rapid Defense Experimentation Reserve (RDER). It will take derived operational specifications and evaluation criteria to develop a selected candidate for the Dismounted Common Controller as an operational prototype to integrate with existing and future unmanned Army ground/air vehicles, lethality, ISR, and Electronic Attack payloads. This effort will result in common control platforms, government-owned architecture, interoperability, and modular payloads. Implementation of the H-MIF Dismounted Common Controller technology must be capable of enduring operation without impacting the speed and tempo of the host vehicle/unit’s operations.

White Papers (WPs) and a Contractor’s Statement of Work (CSOW) are sought to satisfy the U.S.

Army RCCTO’s requirements to develop and deliver a quantity of four (4) engineering units at month three (3) after contract award for initial demonstration, eight (8) qualification units, at the fifth (5) month after contract award to support contractor testing (with Government observation) on the robotic platforms, Control Vehicles (AMPV & ISV), and ground and air payloads. A total of twenty (20) full production units will be delivered to the Government after the completion of the successful contracting testing event referenced previously. The desired characteristics, features, and objectives of the Dismounted Common Controller are as follows in Section 3.0.

3.0 Government Objectives

The solutions are envisioned to be embodied as a Dismounted Common Controller capable of data, power and physical integration with manned and/or autonomous vehicles designed to enhance existing capability without limitation to operational envelopes.

The dismounted common controller software will provide a means for an operator to control functions of all the payloads integrated on the Armor and Infantry robotic and manned control vehicle platforms. The controller capability will also have the adaptability to add new payloads to the Armored and Infantry Formations.

3.1 Scope

The dismounted common controller should be optimized for the dismounted solider environment and include user interface components to be applicable to the control of a wide range of robotic platforms, including unmanned ground vehicles (UGVs), unmanned aerial vehicles (UAVs), and payloads on those platforms with both lethal and non-lethal capabilities. Safety assured control for safety critical systems must demonstrate detection of failure conditions of safety critical functions consistent with IEC-61508 and execute a deterministic safe state response.

3.2 Key Features

• Modular Design: The dismounted common controller should have a modular architecture built using the WMI / CROWS KDA CISC V3 Government Furnished

Architecture.

• Modular Software: The controller should have a modular software architecture to accommodate alternative and extensible controller software running on the common dismounted controller hardware.

• User-friendly Interface: Design an intuitive and ergonomic user hardware interface for easy operation in diverse environments.

• Interoperability: Ensure compatibility with different robotic systems, communication protocols, and sensor types through integration of government software, hardware, and architecture. Controller hardware will utilize electrical and mechanical interfaces compatible with Nett Warrior.

• Mount design shall support carrying of dismounted common controller during movement.

• Safety critical control: Controller includes an independent, safety certified (or certifiable) component to monitor safety critical user inputs and generate the appropriate messages for transmission to the remote platform or payload. Critical functionality (hazard rate of 1E-08 per hour) for assured mobility and lethality control of the UGVs/UAVs by ensuring correct implementation of the government software, hardware, and architecture.

• Soldier Centered Design: The controller includes an intuitive and ergonomic user hardware interface for easy operation by the dismounted soldier in a range of operational environments and conditions.

• Durability: Controller hardware is of a rugged and durable hardware design capable of withstanding the dismounted soldier environment and operational conditions.

• Portability: The controller is optimized in size, weight, and human interface for extended hand-held use by the soldier in a dismounted operational environment and operationally relevant equipment.

3.3 System Functionality

• Control Capabilities: The Dismounted Common Controller provides a set of discrete inputs as well as arbitrary soft inputs for the solider necessary to control a generalized remote robotic capability. A portion of the discrete inputs are dedicated to specific functionality regardless of control mode, the balance of the discrete inputs are reprogrammable to accommodate the needs of a particular platform or payload as determined by the current controller mode. Further, a subset of the discrete control functionality is identified as safety critical. Safety critical controls include specialized requirements for signal redundancy and independent monitoring so that these controls can be used for functionality explicitly relied upon within the safety case and can be independently verified. Finally, the Dismounted Common Controller incudes a touch enabled display interface to allow arbitrary software defined input that may or may not be used for control functions as determined by the software running on the controller.

The minimum set of discrete control inputs required for the Dismounted Common Controller are as follows:

Table 1

Control Description

Dedicated Functionality

Safety Critical

Input Type

Application(s)

Power On/Off, Momentary Yes No Digital Turn On/Off Controller

Automation Enable

Yes

Digital

Allow for maneuver autonomy modes beyond assisted teleop

NVIS, Toggle

No

Switch Display Mode between NVG Compatible/Night and Day

2-Axis Displacement, Self-Centering, Redundant Axis Monitoring

Proportional

RWS Az/El, Generic Payload Gimbal, 2-Axis Displacement, Self-Centering, Redundant Axis Monitoring

Proportional

Omni-Directional Platform Maneuver Control - Direction/Speed

Lethality Safe/Arm, Covered Toggle

Master Inhibit/Enable for all lethality functions

Mobility Inhibit, Toggle

Master Inhibit/Enable for platform maneuver (parking brake)

E-STOP, Mushroom

Master Inhibit/Enable - all functionality

Trigger, 1-axis Threshold Displacement, Self-Return Yes Yes Digital Lethality Trigger

Operator Presence Interlock (LH), Momentary

Interlock for functions requiring interlock

Operator Presence Interlock (RH), Momentary Yes Yes Digital Alt Interlock

Bezel Button, Momentary

Payload Control, Mirror Touch Screen soft button

5D Rocker Joystick No No Digital Programmable Individual Buttons No No Digital Programmable

In the above table, the number of bezel buttons and the number of individual momentary buttons are not given a specific quantity – and are instead meant to be optimized from a human factors perspective by the vendor depending on the overall size and geometry of the controller. The vendor may add additional discrete controls beyond this minimal set to support the efficient operation of remote capabilities.

3.4 Sensor Integration

Support seamless integration with a variety of sensors, including cameras, LiDAR, and other relevant technologies. The dismounted common controller architecture shall support a mission optimized user interface, that integrates the native CROWS RWS controls into the Warfighter Machine Interface (WMI) Graphical User Interface (GUI) for consistency between operating modes and with the native RWS controls. This software solution will be government furnished.

3.5 Sub-System Integration

• Software Support: The Dismounted Common Controller should provide a hardware computing environment capable of running the following GFE software:

• WMI: The Dismounted Common Controller will run the WMI software component of RAC2/ARCs. This software will communicate through the Nett.Warrior interface on the controller, through the Nett Warrior personal area network, to an attached radio that will be utilized for linking up with specific remote assets.

• TAK: The Dismounted Common Controller will support running TAK software so that the controller can be used as an alternative EUD for Nett Warrior if configured.

• External Interfaces: The controller hardware will include a Nett Warrior compliant personal area network interface. When connected to a Nett Warrior system through this interface, the Dismounted Common controller will draw power sufficient for its operation without requiring an additional battery. If the controller has an internal battery, the internal battery shall be charged while connected to Nett Warrior. The controller shall also be capable of using the Nett Warrior interface to connect to a radio attached to the Nett Warrior PAN. The vendor may include additional external interfaces with the Dismounted Common Controller (direct connect external radio, direct connect external battery) but these interfaces should not be required when operating with a Nett Warrior system and should be protected from the environment when not in use.

• Hardware Support :

• CROWS CISC Card V3 Part Number #60301250-01. hardware & software into the dismounted controller. Intent is to provide the KDA CISCv3 card (P/N #60301250-01) as a Government Furnished Item to the selected vendor after contract award. Vehicle System Transponder (VST): Include and integrate VST (acts as remote ESTOP) USG Vehicle Safety Transponder (VST) should be utilized for the project. The architecture of the dismounted common controller will include an interface to the Emergency Stop (VST button).

• RVMS: Include and integrate RVMS (Monitors mobility control and performs automatic intervention for safety in case of a fault). RVMS is an Adaptable Platform Management System (HW&SW) that enables assured control of a platform as well as provides independent monitoring and fault detection to robotic platforms to achieve the necessary performance and integrity for safety critical applications

• MPU5 / Silvus Radio Link: Interfaces with MPU5 and Silvus radios. May integrate both with one in use at a time or have modular design capable of easily swapping between them in the field.

• SINCGARS: Provide connection for SINCGARs headset for two-way voice communication.

• Removable battery requirements:

• Maintain a minimum 12 hours of operational time with chosen power solution.

• Dismounted common controller power system shall be compatible with standard US military BB2590 and BB2557 batteries, and capability to power the controller and external communications radio link.

• A dual connection battery harness design should support the usage of up to two batteries at a time and hot swap battery interchange to support uninterrupted extended operations.

3.6 Communication

Implement reliable communication protocols to facilitate real-time data exchange between the controller and robotic platforms:

• Minimize control input latency to ensure responsive and timely robotic system operation.

• Keep overall system latency for the operator to 250ms or less and implement method to monitor comms latency.

• Dismounted common controller capable of communicating with robotic systems.

• Dismounted common controller design shall support mission modularity and multi-domain operations and includes interchangeable communications modules, interfaces to kill-switch and ATAK based situational awareness networks, and support for advanced mapping and control systems.

• Shall support Line of sight comms with controlled vehicle up to (2000m) through the external radio network Line of Site (LOS) & NLOS

• Dismounted common controller shall have intra-network supporting all communications and allow wired ethernet connection.

All outputs from the controller shall be capable of delivery over wired

Ethernet UDP.

All inputs from the controller shall be capable of delivery over wired

Ethernet UDP.

3.7 Safety Concept/Case requirements for the dismounted common controller The Dismounted Controller includes a high reliability independent component – a trusted safety module - that is directly connected to the safety critical controls to allow for monitoring of the safety critical control state without any additional software in the monitoring path. This component independently connects to the control network and establishes a network path between the controller and a user selectable companion component on a remote platform. Vendors may propose their own solution to the trusted safety module, built in accordance with an open government specification, or may choose to integrate a GFE solution for this capability within their controller.

If the vendor proposes their own solution, they must be willing to submit all implementation details, including software source code, to the government for review and verification. Additional implementation details of the trusted safety module are available upon request.

3.8 Performance Requirements

Capable of both mounted and dismounted operations, should provide users with a wide range of inputs to allow for control of complex robotic platforms and support a range of external peripherals.

• Control design interface:

Mode Switch (Required where hardware interfaces are used in multiple non-simultaneous functions.)

The dismounted common controller shall be designed with a 10 inch diagonal display size to support presentation of full HD (1080P) video from weapon system & 360SA to improve Detection, Recognition, and Identification (DRI) and target acquisition performance.

Dismounted common controller hardware interface shall incorporate the CISC v3 ICD.

3.9 Ergonomics requirement for the dismounted common controller

• Total weight should be <20 lbs. (threshold), ≤15 lbs. (objective).

• Total hand-held burden should be <8 lbs. (threshold), ≤6 lbs. (objective).

• All components must either be held or worn on body (Plate carrier mounted, backpack, sling, etc.)

• According to Table 1:

All functions assigned a priority level of 1 shall be accessible within the thumb and index finger sweep of the operator's hand in the natural grip position without repositioning of the hand.

All functions assigned a priority level of 2 shall be accessible within the thumb and index finger sweep of the operator's hand in the natural grip position with minor repositioning of the hand.

All functions assigned a priority level of 3 shall be accessible with repositioning of the hand from the natural grip position.

All functions assigned a priority level of 4 shall be implemented as space allows and shall have the function implemented in the Graphical User Interface (GUI).

All functions assigned a priority level of 5 shall be considered for implementation pending all functions of priority 1 through 4 have been met and additional space has not been allocated.

Safety Critical controls shall not be repurposed in across modes.

• The dismounted common controller design shall accommodate for the size of the 5 - 95% adult hand size for both male and female operators both gloved and ungloved

• The force needed to actuate a push button switch shall be continuous at a rate of 1.5lbf.

• The displacement of a toggle switch shall be more than 20 degrees but no more than 30 degrees.

• The displacement of a joystick shall be more than 30 degrees but no more than 60 degrees and the force required to displace from the neutral position shall be 1.5lbf.

• The force needed to move a toggle or 4-way switch from the neutral position to another position shall be continuous at a rate of 1.5lbf.

• The displacement of a trigger shall be more than 20 degrees but less than 45 degrees if rotationally actuated or more than 5mm but less than 20mm.

• The system shall be usable wearing Flame Resistant Combat Gloves LIN DA154H

• All switches shall provide a detent (i.e. physical click) at the electrical activation point of the switch.

• A variety of switch caps shall be utilized to distinguish similar switches: flat, flat textured, concave, convex, concave dimple, convex dimple, etc. A unique switch cap type shall be utilized for each switch of the same type activated by the same finger / thumb.

• Switch caps shall provide a means to distinguish grouped functions.

• For any joystick including a momentary push button, the push button shall only be activated from the neutral position of the joystick.

• The screen shall be no larger than 10 inches diagonal, maintain a 16:9 aspect ratio, and support non-gloved and gloved touch input.

3.10 Haptics

• Haptic Feedback shall be provided to the operator's palms and index fingers with the use of motors located within the dismounted common controller body and trigger bodies.

• Haptic Feedback intensity shall be configurable in scale from any percentage from 0 to

100% equal or less than 10% increments.

3.11 Ruggedization

• The dismounted common controller design, development, and assembly shall be handled in accordance with MIL-STD 810G, MIL-STD-810, MIL-STD-461, and MIL STD-464, and IP68 for construction.

• Design shall support submersion levels of ingress protection.

• All port connections shall be reinforced by tri-start screw type connections.

• The cabling to the controller shall allow for flexibility and strain relief to prevent failure of the cable after 1000 hours or more of use.

• The cabling to the controller shall be coiled, spooled, or any other manner of self-withdrawing to allow for stretch.

• The dismounted common controller thermal management solutions shall be developed in accordance with supporting AR 70-38 Basic Cold through Hot environments with full solar loading effects.

3.12 Lighting

• All status lights or backlight switch caps utilized for the display screen of the dismounted common controller shall be compatible with MIL-STD-3009 Night Vision Imaging Systems compatible (NVIS) filter systems and have a blackout mode.

• The display screen for the dismounted common controller shall support the full range of operating environments that includes direct sunlight as well as blackout and low light operating modes.

Dimmable screen to support naked-eye night operations (preserve user’s night vision/dark adaptation).

The integrated display screen on dismounted common controller shall be sunlight readable, Lumibond display with a brightness of 1000 nit (lux) or more.

3.13 Development and Testing

3.13.1 Prototyping

• Develop prototype versions for iterative testing and refinement based on user feedback.

• The internal architecture of the dismounted common controller shall be architected to support expansion hardware with corresponding, physical, electrical, and thermal provisions.

3.13.2 Simulation

• Provide prototypes that integrate with hardware integration labs (HILs) and software integration labs (SILs) for testing in virtual environments.

3.13.3 Benchtop Testing

• Conduct benchtop experiments of controller, verifying system communication with available robotic systems early in development (prior to achieving mobility).

• Emphasis on checking for various failure conditions via intentional hardware and software fault injection (ex. loss of comms, power loss, cable failure, etc.)

3.14 Training and Documentation

3.14.1 User Training

Develop training materials and conduct training sessions to familiarize users with the dismounted common controller's features and functionalities.

3.14.2 Technical Documentation

• Provide an interactive multimedia technical manual with a browser-based interface that can be loaded on to the dismounted common controller and activated by touch.

• Available hard copy of technical manuals should include comprehensive troubleshooting processes, maintenance procedures, PMCS, RPSTL, and MAC.

• The Graphic User Interface should be customizable, supporting text, photographs, illustrations, and videos.

3.15 Cybersecurity

• Implement robust cybersecurity measures to protect the controller and connected robotic systems from unauthorized access and potential cyber threats.

• The scanning of the HW/SW for the dismounted common controller shall have the lowest number of vulnerabilities possible IAW with MIL-STD-1553.

• Dismounted common controller system shall be capable of logging all relevant security related activity.

• System shall have an interface for authentication.

3.16 Preliminary Design

Selected offeror will develop an initial design for the HMIF Dismounted Common Controller and will present the design as part of a preliminary design review (PDR). The preliminary design is anticipated to be approximately TRL 6 or higher and will demonstrate the capability for continued efforts to meet all requirements of the program. The PDR will represent the first gating activity for continued efforts. The effort will incorporate and be assessed by the following standardized testing requirements that include MOSA target goals.

Tasks in this period include:

• Kickoff Meeting

• Preliminary Design Review

Deliverables for this period include:

• Kickoff meeting slides

• PDR design documentation and report

3.17 Design Refinement

The selected offeror will refine the HMIF Dismounted Common Controller design during this period. Design capability for an assured mobility and lethality control of all HMIF Increment1 payloads (also future modular payloads) shall be demonstrated. Further refinement will mature the design for a critical design review (CDR). The CDR will represent the second gating activity for continued efforts.

Tasks in this period include:

• Systems Engineering Management Plan (SEMP)

• Test and Evaluation Master Plan (TEMP)

• Critical Design Review

Deliverable for this period include:

• Demonstration 2 report

• CDR design documentation and report

• One or more prototype Dismounted Common Controller systems for government evaluation

3.18 Operational Prototype Production

During the final phase of the program, the offeror will finalize the design, including documentation of all interfaces, and will produce operational prototypes. The design will be presented in an operational readiness review (ORR). The ORR will be accompanied by demonstration(s), in which a set of first-article systems will be demonstrated to be fully operational in “field” conditions. Each first-article Dismounted Common Controller will include all HMIF Increment1 payloads (also future modular payloads). This phase will conclude with delivery of operational prototype systems.

Tasks in this period include:

• Operational Readiness Review

• Prototype Demonstration

Deliverables for this period include:

• ORR design documentation and report Interface Control Documents (ICDs) Technical Data Package (TDP)

• Prototype Demonstration report

• Operational prototype systems – QTY 20

3.19 Test and Demonstrations

Interim test events are anticipated throughout the development process, with advancement of the system TRL evident at the demonstration.

• TRL for demonstration would be at: TRL 8 or higher.

• Demonstrations will be conducted at locations identified by the government and are anticipated to include relevant vehicle platforms and end-users.

3.20 Data Deliverables

The Contractor shall be required to deliver the following Data Item Descriptions (DIDs), at a minimum. Contractor is encouraged to add other DIDs that support the proposed solution during the proposed Period of Performance:

1. Kick-Off Meeting/System Requirements Review

2. Monthly Status Reports (MSRs)

3. Test Plans for Performance Validation, both laboratory and field tests

4. Test Reports for Performance Validation, both laboratory and field tests

5. Preliminary Design Review (PDR)

6. Critical Design Review (CDR)

7. Operational Readiness Review (ORR)

8. Technical Exchange Meetings & Reports

9. Demonstration and/or Soldier Touch Point (STP) Reports following each event

10. Low-Rate Initial Production (LRIP)/Full Rate Production (FRP) Plans

11. Interface Control Documents (ICD)

12. Technical Data Package (TDP)

13. Software Documentation

14. Authority to Operate (ATO) Artifacts (for any network applications)

15. Safety Assessment Report (SAR)

16. System Training Package/User Training Manuals, both hardware & software

17. Software Requirements Specification (SRS)

18. Final Closeout Review Meeting & Report

3.21 Environmental and Safety

The components of the solution developed under this SOO shall be of safe design and not interfere with vehicle operations. It is anticipated that individual vehicle PMs will approve integration into their relevant vehicles. The U.S. Army Test and Evaluation Command (ATEC) will conduct a system safety review.

3.22 Government Furnished Property, Government Furnished Equipment, Government Furnished Information The Warfighter Machine Interface (WMI) software, and the KDA CISC V3 will be provided for the development. The Government may also provide access to Army remotely controlled autonomous and/or manned vehicles for testing during system development and at demonstration events.

3.23 Period of Performance (POP)/Delivery Date and Exit TRL

The desired timeline for engineering efforts is anticipated to be five (5) months from contract award, four (4) months for contractor testing with Government observation on the HMIF platforms (AMPV, ISV, RCV, and SMET) and payloads (CROWS, T-UAS, C-sUAS, LASSO, SRR, and MRR), and twelve (12) months of Field Service Engineering support for Integration and Government testing. U.S. Army RCCTO’s requirements are to develop and deliver a quantity of four (4) engineering units at month three (3), eight (8) qualification units at month five (5), and twenty (20) full production units at month eleven (11).

Expected TRL at program completion will be TRL 8 or higher. Time is of the essence in the performance of this effort.

4.0 Procedures

This RFWP consists of the submission of a White Paper (WP) and CSOW, and if selected, a final technical submission and cost proposal will be requested. This RFWP is considered a competitive process. Key milestones are listed in Table 2 and described in more detail below.

Table 2 RFWP Release Date 05-21-2024 RFWP Questions Cut-off Date 05-29-2024 WP/CSOW Due Date 06-24-2024

The HMIF Dismounted Common Controller SOO in Section 3.0 above supports the creation of the WP technical content, a draft CSOW, and the Rough Order of Magnitude (ROM) costing. Offerors shall submit a WP in accordance with the format and content instructions in Section 9.0 and contractor best practice WP format; the CSOW submittal will follow the form/format of the HMIF SOW template. Failure to timely submit CAGE Code information, or related Offeror errors, will not be a basis for extensions of time for questions or submissions. Note: If an Offeror wishes to propose multiple solutions, they must propose those approaches in separate WPs.

Upon receipt of WPs and CSOW, the Government will evaluate submitted WPs/CSOW IAW the specified WP/CSOW Evaluation Criteria, Section 11.0, to determine which submissions represent the most advantageous solution to the Government. At that time, the Government may elect to request additional information or a solution presentation from any Offeror that made a submission, or from only the Offeror(s) that submitted the most advantageous WP solution. Offerors that made a submission that are not selected for award may not be notified until after award.

Except in situations such as those noted in below, the Government will notify the selected Offeror that submitted the WP/CSOW deemed to represent the most advantageous solution to provide a cost proposal and a final technical submittal against a proposed Government Statement of Work (GSOW) to the Government. Upon receipt of the cost and final technical submittal, the Government may collaborate with the Offeror to finalize the SOW to ensure mutual agreement to the technical deliverables. Upon receipt of the cost proposal, the Government will evaluate the cost proposal IAW the specified Proposal Evaluation Criteria, Section 11.0. If the cost proposal is deemed advantageous to the Government, the GSOW is mutually agreeable, and a consensus on the terms of the agreement are agreed to, the Offeror will be awarded the pOTA, subject to the availability of funding.

If the evaluated cost proposal is not found to be acceptable or the parties cannot successfully reach a consensus on the GSOW or the terms of the agreement, as determined at the sole discretion of the Government, the Government reserves the right to engage the Offeror with the next best WP/CSOW solution based on the original WP/CSOW evaluation. Once the Government has engaged the Offeror with the next best WP/CSOW solution, no further engagements with the previous Offeror will be entertained until after the agreement has been awarded. The process will continue until an agreement is successfully reached and a pOTA is awarded. All documents necessary for the review and evaluation of the HMIF Dismounted Common Controller submittals shall be provided as described in this RFWP.

5.0 Non-Government Personnel

Offerors are advised that employees of the firms identified below may serve as non-Government advisors in the review and evaluation of WPs. Such firms are expressly prohibited from competing on the subject acquisition. The non-Government advisors will be required to submit to the Government a Non-Disclosure Agreement reflecting the effort(s) that they will be supporting. The Offeror’s submission of a WP under this RFWP indicates concurrence with the use of non- Government advisors.

a. CONTRACTOR: Exponent, 23445 North 19th Avenue, Phoenix, AZ 85027, (602) 653-6867 Dr. John Pye (Contractor POC: John Pye, Exponent Corp, john.d.pye5.ctr@army.mil )

b. CONTRACTOR: DCS CORP. 6909 Metro Park Drive, Suite 500 Alexandria VA 22310 (571)-227-6000 Mr. Steven Lee (Company POC: Mr. Tim Thomas, DCS Corp, timothy.j.thomas137.ctr@army.mil)

c. CONTRACTOR: SGS Innovations, LLC, 40205 Main Street, Waterford, VA 20197, (703) 581-8715 Mr. Mark Sullivan (Contractor POC: Mr. Mr. Sullivan, SGS Innovations, LLC, mark.a.sullivan110.ctr@army.mil )

In accomplishing their duties related to the RFWP evaluation, the aforementioned firm may require access to proprietary information contained in the Offerors' submittals. Therefore, the firm may execute an agreement with each Offeror that states that they will: (1) protect the Offerors’ information from unauthorized use or disclosure for as long as it remains proprietary; and (2) refrain from using the information for any purpose other than that for which it was furnished. To mailto:john.d.pye5.ctr@army.mil mailto:timothy.j.thomas137.ctr@army.mil mailto:mark.a.sullivan110.ctr@army.mil expedite the evaluation process, each Offeror must contact the above company to effect execution of such an agreement prior to the submission of proposals. Each Offeror shall submit copies of the agreement with their submittal, if applicable.

6.0 Points of Contact

All questions regarding RFWP submissions must be emailed to ALL of the following personnel:

1. Simone Brightmon, simone.l.brightmon.civ@army.mil

2. Tessa Jones, tessa.a.jones.civ@army.mil

3. Jolynda Ivy, jolynda.v.ivy.civ@army.mil

7.0 Response Dates

All questions regarding this RFWP shall be submitted via email no later than 1600 EST on 29 May 2024 to all points of contact listed in Section 6.0. It is preferred that only one set of questions be submitted by each Offeror instead of submitting multiple sets of questions. Questions received by the Government after 1600 EST on 29 May 2024 may not be answered prior to the closing date/time for receipt of white paper submissions. Questions submitted by any method other than email will not be accepted or answered. The Government will post responses to all questions received and any amendments issued as a result of submitted questions.

All RFWP submittals must be received no later than 1600 EST on 24 June 2024 by all the POCs listed in Section 6.0. It is the responsibility of the submitting party to confirm receipt of submissions.

The Government will provide additional information and instructions, including submission dates and clarifications, in a request for a final proposal submission and cost proposal to the selected Offeror(s).

8.0 Contract Structure & Funding Availability

8.1 Funding

The Government reserves the right to consider all, some, or none of the WPs or cost proposals received in response to this RFWP for selection of award. The Government reserves the right to cancel this RFWP at any time for any reason or for no reason. Issuance of this RFWP does not commit the Government to pay for any preparation costs incurred by the contractor in compiling a response to any aspect of this RFWP and any such costs are not allowable or allocable to any USG contract or agreement. All potential Offerors should be aware that due to unanticipated budget fluctuations, funding in any or all areas may change with little or no notice, and any award is subject to the availability of funding. The Government might decline to complete a review required to proceed into the next phase of the project, or otherwise decline to move into subsequent phases based on mission, funding requirements, or higher headquarter (HHQ) instructions.

8.2 Instrument Type

The preferred instrument type is a pOTA awarded as a firm-fixed price contract. This contract type allows for fixed payable milestones based on the agreed-upon milestone schedule. Funding arrangements are at the discretion of the Government.

mailto:joshua.e.flinn.civ@army.mil mailto:brian.j.burton.mil@army.mil mailto:jolynda.v.ivy.civ@army.mil

8.3 Project Award Value

Offerors should provide ROMs & cost proposals that are commensurate with the proposed level of effort to complete the proposed approach and meet the requirements of the SOO as outlined herein.

8.4 Period of Performance/Delivery Date

The period of performance and delivery date for the dismounted common controller hardware/software systems of the anticipated pOTA is 9 months, and an additional 12 months of Field Service/Engineering Representative Support (FSE/FSR) to platform integration at efforts at designated Government Software/Hardware Integration Laboratories (SILs/HILs), and system of systems testing activities at ATEC facilities.

9.0 White Paper Preparation & Submission Instructions

9.1 White Papers & CSOW

• Only UNCLASSIFIED submittals will be accepted. The Government’s decision to invite an Offeror to submit a final proposal and cost proposal will be based upon the evaluation results of the RFWP submissions.

• In the event of a possible or actual compromise of classified information in your submission, immediately and within no more than 24 hours, bring this to the attention of the POCs in Sections 6.0.

9.2 Format of RFWP Submittals

Offerors shall submit the WP IAW the following:

• Number of Pages: The WP is limited to 10 pages. There is no maximum page for the CSOW or the ROM. The WP cover sheet is not included in the page limit. Pages submitted in excess of the WP page limit will not be read or evaluated.

• Number of Copies & Format: One electronic copy of the WP and cover sheet

• Text & Font Format: Text shall be at least single-spaced, on 8½ x 11-inch paper, with a minimum of one-inch margin all around. Pages shall be numbered consecutively. Font size shall be of minimum 12-point font. Bolding, underlining, and italics may be used to identify topic demarcations or points of emphasis. Graphic presentations, including tables, while not subject to the same font size and spacing requirements, shall have spacing and text no less than 9-point font that is easily readable.

• Security: Do not lock or encrypt any files uploaded as part of your white paper submission. Any locked or encrypted files will not be read or evaluated.

• Use of legible diagram(s) or figure(s) to depict the essence of the proposed solution is encouraged.

• All RFWP submittals shall be UNCLASSIFIED. Submittals containing data that is not to be disclosed to the public for any purpose or used by the Government except for evaluation purposes shall include the following sentences on the cover page:

“This WHITE PAPER includes data that shall not be disclosed outside the

Government, except to non-Government personnel for evaluation purposes, and shall not be duplicated, used, or disclosed -- in whole or in part -- for any purpose other than to evaluate this submission. If, however, an agreement is awarded to this Offeror as a result of -- or in connection with – the submission of this data, the Government shall have the right to duplicate, use, or disclose the data to the extent agreed upon by both parties in the resulting agreement. This restriction does not limit the Government's right to use information contained in this data if it is obtained from another source without restriction. The data subject to this restriction are contained in sheets [insert numbers or other identification of sheets]”

• Each restricted data sheet should be marked as follows:

“Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.”

Questions regarding the objectives or preparation of the WP should be addressed to the POC’s listed in Section 6.0.

9.3 Content of WPS

The Offeror’s WP must include the following:

• Cover Sheet (Offerors shall provide the following information on the cover sheet):

Organization Information: name, mailing address, technical POC, phone number, e-mail address, CAGE code, and Tax Identification Number (TIN) Business POC, phone number, and e-mail address Self-Certification of Offeror: (select all that apply)

• Small business

• Large business

• Academic institution

• Non-traditional defense contractor (see definition below)

• Other

Non-traditional defense contractor (NDC) is defined in 10 U.S.C. § 3014 as an entity that is not currently performing and has not performed, for at least the one-year period preceding the solicitation of sources by the Department of Defense for the procurement or transaction, any contract or subcontract for the Department of Defense that is subject to full coverage under the cost accounting standards prescribed pursuant to section 1502 of title 41 and the regulations implementing such section.

9.4 Content for the CSOW

The requirements and objectives in the HMIF Dismounted Common Controller SOO will be used by offerors to develop, draft, and submit a CSOW that clearly outlines the contractor’s proposed effort. The CSOW submittal shall detail and structure a sound technically viable program, which is innovative, affordable, designed to be executable, and able to satisfy (meet or exceed) Government objectives. The CSOW must clearly align with the SOO and must be submitted in the form/format of the attached HMIF SOW Template to the maximum extent possible. The CSOW should only include proposed efforts, as described above; any capability statements or assertions with the CSOW will not be evaluated as demonstrating knowledge or understanding, though they may only be considered if they introduce risk as to the Vendor’s approach, knowledge or understanding.

9.5 WP Approach & CSOW Content

Ensure your submittals adequately describes the proposed approach, capabilities and resulting contributions. The WP shall include the following sections in the order given below, as applicable:

9.5.1 Technical Approach.

Describe how the proposed technical approach to accomplish the proposed task is feasible, achievable, and complete, meeting or exceeding Government objectives. The technical approach, in addition to the list below, should address the approach to develop the HMIF Dismounted Common Controller. Address the following:

• Project approach to meeting objectives and scope. Present approach to meet the technical characteristics and objectives as identified in the SOO. RCCTO will evaluate the entire Technical Approach holistically, considering these desired characteristics.

• Proposed capabilities of the Offeror’s system.

• Inclusion of Modular Open System Architecture (MOSA) into the design process and solution.

• Overview of tasks and methods planned to accomplish the technical approach and the HMIF Dismounted Common Controller to be delivered as part of the base agreement that supports the contract PoP.

• Identify particular approaches the Offeror will take to ensure successful completion within the clear schedule constraints (e.g., opportunities to accelerate schedule).

• Present scalability of prototype production methods, commercial items, and resources in order to meet the Government’s schedule.

• Identify and assert any restrictions on the Government's use, release, or disclosure of technical data or computer software pertaining to its proposal submission. If the offeror has no restrictions for a particular section, then it shall state “none.” All assertions (including entries of “none”) shall be signed by an authorized representative of the offeror. If all assertions are contained on one page, one signature is sufficient. If the assertions are separated, each assertion shall be signed (separately) as required. The offeror's assertions, including the assertions of its subcontractors or suppliers or potential subcontractors or suppliers, shall be submitted in the required format, dated, and signed by an official authorized to contractually obligate the offeror. The offeror shall provide a detailed discussion of the degree to which asserted data rights restrictions, as well as any proposed option(s) for additional data rights, affect the proposed technical solutions and the Government’s ability to use, modify, reproduce, release, perform, display, or disclose the resulting technical data and computer software for Government purposes as defined in DFARS 252.227-7013(a)(12) and DFARS 252.227-7014(a)(11). Note:

The data rights assertions are not subject to the page limit specified for this part of the proposal.

9.5.2 Qualifications and Experience.

Limited to the past five (5) years, related prior or current work, identify Offeror’s roles and responsibilities:

• Offeror’s projects related to the development and demonstration of HMIF Dismounted Common Controller in a robotic environment or in similar settings, including Small Business Innovation Research (SBIR)/Small Business Technology Transfer (STTR) contracts and Independent Research & Development (IR&D).

• Offeror’s projects related to the integration of the HMIF Dismounted Common Controller onto Army tactical and combat vehicles, or other DOD applications, and testing of those systems, including SBIR/STTR contracts and IR&D projects.

• Identify team member(s) role assignments and each team member's qualifications and experiences in comparison to the respective SOO performance requirement(s) the team members are proposed to perform.

• If the offeror proposes the use of one or more NDCs, the following information is required for each participating NDC:

Legal Name and CAGE code.

Explanation of how proposed NDC meets 10 U.S.C. § 3014 definition.

Contribution to the effort, based on at least one of the following factors:

Supplying new key technology or products.

Causing a…