RFI for AESA Radar (Rev H)_Sensors_JAN 2025.pdf

REQUEST FOR INFORMATION (RFI)

Active Electronically Scanned Array (AESA) RADAR

Program Executive Office (PEO) Aviation, In-Flight Demonstration

1.0 General

Pertaining to this notice THIS IS A REQUEST FOR INFORMATION (RFI) ONLY to support a potential in-flight demonstration of the Active Electronically Scanned Array (AESA) RADAR to be conducted on Redstone Arsenal, Al. It is the intent of the government to investigate AESA RADAR technologies capable of fulfilling the requirements of multiple rotary and fixed wing platforms. Desired capabilities include Fire Control, Pilotage, Pilot aid in Degraded Visual Environments (DVE), Pole/Tower and Cable Detection, Airborne Hazards, Terrain Following (TF), Terrain Avoidance (TA), and Shoreline mapping using Augmented Reality (AR) techniques.

If respondents can only provide a subset of capabilities, they are still encouraged to respond.

The U.S. Government, Project Manager for Apache Attack Helicopter (PM AAH) within the Program Executive Office (PEO) for Aviation is conducting market research to determine potential sources capable of meeting technical requirements for an AESA RADAR for the Army’s Attack (AH-64 Apache), Utility (UH-60 Black Hawk), Cargo (CH-47 Chinook) Helicopters, Future Long Range Assault Aircraft (FLRAA), and Fixed Wing Aircraft. Interested respondents are encouraged to provide substantiated evidence of their relevant capabilities, successes, and readiness for in-flight demonstration. Section 1.0 – “Surrogate Platform Interface Requirements” gives an overview of integration requirements to mount and connect the demonstration article to a standard Apache weapons pylon. Additional information can be obtained from the AH-64E V6 TM 1- 1520-263-10 Operators Manual, AH-64E V6 System Subsystem Design Descriptions (SSDD), MIL-STD-8591, and MIL-STD-810. United States Government (USG) will assist in the publishing of the required Airworthiness Release (AWR) and submission of the DD-1494 for this demonstration event.

The submission of this information is solely for informational, market research, and in-flight demonstration planning purposes. This submission is NOT a request for competitive proposals, quotations, or an invitation to reimburse responders for associated costs to respond or for any information provided. This notice does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This notice does not commit the USG to contract for any supply or service whatsoever. No reimbursement will be made for any costs associated with providing information in response to this notice or any follow up information requests. All costs associated with responding to this notice will be solely at the responding party's expense. At the discretion of the USG, some respondents may be selected to participate in an in-flight demonstration of their system; no reimbursement will be made for incurred vendor costs associated with the demonstration. Respondents not yet able to integrate onto a surrogate aircraft are encouraged to respond and highlight technical maturity limitations and other feasible demonstration capabilities.

If a respondent is not selected or ready for an in-flight demonstration but would like to sponsor its own system demonstration, the USG will consider attending the respondent-hosted event. At the discretion of the USG, a post-demonstration report may be generated regarding the respondent-hosted event with all the considerations described in section 5.5.

USG Demonstration Contributions - The USG is funding a variety of aspects of the demonstration and offering industry the opportunity to demonstrate their AESA RADAR system and collect data against relevant targets on a fielded AH-64E platform. The USG will provide comprehensive support, including preparation and planning, system integration assistance, and mission planning.

The event will feature USG funded test assets such as, aircraft (AH-64E) and fuel, targets, test range, test pilots, and flight test engineers. Vendors will have access to an implemented instrumentation package including an up-down control link, and navigation data. The event will be divided into two sections, in which the vendors will benefit from performance time against generalized scenarios and a customized vendor showcase demonstration section. Additionally, the USG will supply raw demonstration data, including flight cards, aircraft and target TSPI, and a detailed post-demonstration assessment report. This demonstration is intended to provide USG with information regarding available state-of-the-art AESA technology while providing industry the opportunity to showcase their system capabilities, and to collect data against a diverse target set on a fielded weapons aerial platform.

Surrogate Platform Description - The AH-64E Apache is a twin-engine, tandem-seat, aerial weapons platform. The aircraft has a fully articulated, four-bladed main rotor system equipped with elastomeric lead-lag dampers. The four-bladed tail rotor is a semi-rigid design. The aircraft is powered by two General Electric T700-GE-701D (-701D) turboshaft engines that transmit power to the main transmission through engine-mounted nose gearboxes. The main transmission drives the main rotor, tail rotor, and accessory gearbox. The flight control system consists of conventional controls connected mechanically to hydromechanical actuators for the main and tail rotors, a limited authority stability augmentation system, and an electrically driven stabilator. The AH-64E Apache has both a modernized-target acquisition designation sight (M-TADS) for targeting and a modernized-pilot night vision sensor (M-PNVS) for night pilotage; the M-TADS and M-PNVS are mounted to the nose of the aircraft. Aircraft also supports Manned Unmanned Teaming (MUM-T) to support data communications to ground and air to air systems. Left and right wings, attached to the center fuselage, provide four hard-points for mounting up to four M- 299 Hellfire missile launchers, four M-261 rocket pods, or two external auxiliary fuel tanks (inboard stations [2 and 3] only) to support a given mission. The aircraft includes two multicore mission processors that command all system-initiated tests, monitors system status and default data, and processes the data for display.

Surrogate Platform Interface Requirements:

• Mounting: The demonstration article will be mounted on the right-hand outboard wing station, Pylon 4, of an AH-64 Apache. A standard Apache ejector rack in a 2 lug, 14” spacing, and 4 sway-brace configuration shall be used. CG of mounted item shall be within 1” of center between the lugs. (ref MIL-STD-8591). The pylon can be fixed in the ground or flight stow positions. Ground stow is ~ 4.9° below the armament datum line (ADL). This equates to the demonstration article approximately parallel with the Earth’s surface while on the ground/in a hover and approximately 5° low in forward flight. Flight stow is ~ 4° above the ADL. The demonstration article will be captive carry and will not be jettisonable.

• Weight: The demonstration article shall not exceed 500 LBS ref AH-64E V6 TM 1-1520-263- 10 Operators Manual, Chapter 6, Weight/Balance and Loading

• Ground Clearance: The demonstration article will be required to maintain a ground clearance of 15” when mounted to Pylon 4 in the ground stow position (approximately parallel to the landing surface) and no less than 9” of ground clearance on flight stow. The distance from the ejector rack hook/s to the ground is ~ 48” in ground stow.

• Electrical power: The aircraft has growth capacity to supply 30 Amps per phase of 3-Phase 115 VAC at 400 Hz and 40 Amps 28 VDC to the demonstration article. The aircraft would be modified by the USG for wiring provision to the demonstration article.

• Instrumentation: USG to provide an airborne data acquisition system capable of recording MIL-STD-1553, Ethernet, Aircraft ICS, and video. Telemetry system would be installed to view this data on the ground during flight.

• Navigation Data: Aircraft navigation data may be made available to the demonstration article if requested.

• Cockpit Control/Display Connection: The demonstration article cockpit control and display device shall be a touch screen tablet that can connect to demonstration article and data acquisition system via Ethernet and run demonstration article control software. Tablet size must not exceed 8” (L) x 5”(W) x 0.75”(H) and 1.5 lbs.

Not responding to this notice does not preclude participation in any future RFP, if issued.

Responses to this notice are not offers and cannot be accepted by the USG to form a binding contract. The submission will require a detailed system description and expected performance against defined demonstration parameters and objectives to be performed by the demonstration article as detailed in section 5.4 when integrated on the Surrogate Platform, i.e. Fire Control Targeting, Pilotage, Pilot aid in DVE, Pole/Tower and Cable Detection, Airborne Hazards and TF&TA, and Shoreline mapping using AR techniques. The system description will include the Hardware Technology Readiness Level (HW TRL), Software TRL (SW TRL), readiness for flight and Manufacturing Readiness Levels (MRL). If the system is not ready for flight, each shortcoming must be listed, explained (to include a detailed schedule required to achieve flight readiness), and must be provided in the submission. It is the responsibility of the interested parties to monitor the System for Award Management (SAM) (https://sam.gov) site for additional information. Respondents are encouraged to provide unclassified submissions. However, if necessary, information at the secret level can also be provided (see section 6.3).

2.0 AESA RADAR Description

Provide information regarding the proposed AESA RADAR that will be used during the demonstration.

2.1 Readiness for Demonstration

• Is the system ready to support an in-flight demonstration as detailed in section 5.4 in accordance with the schedule as defined in section 5.1?

• If the system is not ready to support an in-flight demonstration, explain each shortcoming.

• Provide a detailed schedule to achieve flight readiness.

• Can the RADAR function during flight and in a hover?

• Is the system weather-proof?

• Has the system ever operated on a rotary-wing, or fixed wing aircraft?

• Is the system (or a variant of the system) currently fielded on any U.S. DoD aircraft? If so, please indicate aircraft type and service. Include USG PoC.

o Does the system have a DoD Airworthiness Report (AWR)?

• Has the system been demonstrated or tested in an operational or laboratory environment to any USG entity? If applicable, describe the nature of the demonstration or test to include date, location, demonstration reports or out briefs, USG organization(s) involved, and PoC names and contact information.

• Show mechanical and electrical compliance described in section 1.0 “Surrogate Platform Interface Requirements” of this document.

• Describe the approach to install the RADAR onto a surrogate aircraft pylon.

• What are the limiting factors regarding the demonstration parameters when installed on the surrogate aircraft as described in section 1.0 “Surrogate Platform Interface Requirements”?

• What navigation data is required by the RADAR to support geolocation?

• Does the system use Digital Terrain Elevation Data (DTED)?

2.2 RADAR Description

2.2.1 System

2.2.1.1 Design

• What is the primary function of the proposed system?

• What are the key design parameters of the system?

o Operational Frequency, Dual-band, Tunability & Bandwidth o Receiver instantaneous and total dynamic range o Receiver sensitivity o Minimal target velocity o Sub-clutter visibility o Accuracies of the system for all modes (range, az/el, velocity, tracking, etc.)

o Modulation techniques/Waveform details, (FM/AM/PM, PRF, pulse widths, coding, etc.)

o Maximum duty factor for each mode

• Provide a detailed description of the signal processing architecture including ADC, and DAC techniques employed.

• Provide a block diagram illustrating all Line Replaceable Units (LRU)s and connections including internal and external interfaces, that make up the integrated RADAR.

• Provide system enclosure (pod) drawing detailing the number and location of each aperture.

o Is the data collection from the apertures dependent on flight profile and target geometry?

If yes, provide details on preferred profile(s).

• Detail the RF architecture, to include up/down conversion scheme, noise figure, spectral purity, etc.

• If the system supports multiple bands, how is this achieved? What compromises in performance are made to support the multiple bands? i.e. gain, power, beamwidth, sidelobes

• Provide a description of electrical characteristics and interfaces i.e. power, data, control, and

RADAR display & products.

• Describe coordinate transformation techniques employed to correlate/translate the RADAR to the aircraft.

• What is the geo-location accuracy for stationary and moving targets (littoral, ground, and air), terrain and shoreline mapping?

• What techniques are used to generate beam manipulation (spoiled beams) to reduce sidelobe, backscatter, unwanted energy on target, interference from other radiators such as jammers?

Explain the application of beam forming. E.g. Minimum Variance Distortionless Response (MVDR), Linearly Constrained Minimum Variance (LCMV).

o Are other techniques besides beam shaping used to accomplish this purpose, e.g. auxiliary channels? Please describe.

• Explain how the RADAR will support Low Probability of Intercept (LPI), Low Probability of

Detection (LPD) and anti-jamming in a contested battlefield environment. Are there autonomous features? Is there spread spectrum functionality?

• Address Size, Weight, and Power – Cost & Cooling (SWaP-C2). What are the driving factors for each? What could be done to improve SWaP-C2 in the system?

• Is the RADAR capable of conducting passive search/track in support of electronic warfare without interfering with the RADAR mission? If so, discuss.

o Are parameters associated with passive mode consistent with the “key design parameters” discussed in bullet 2 of this section.

o What is passive response time, PRI, PW, scan detection capability?

• Was the software developed in alignment with FACE/SOSA standards?

2.2.1.2 Operation

• Provide a list of operational modes with a description of each.

o E.g. passive surveillance, search, weather, track, TF/TA, SAR, STI, MTI, littoral, air target, target feature extraction

• Is the RADAR able to detect telephone poles/towers and power transmission wires? If so, what range is detection accomplished (provide wire diameter), and is polarization diversity used to aid in detection? How is polarization used to improve detection?

• Provide an Array timing schematic, or timing allocation methodology. For search modes how is the beam allocated to the search area; what search scheme is employed? For track, and simultaneous track/search modes, what options exist for track maintenance while simultaneously searching?

• Simultaneous Operation o Can the system operate simultaneously in different modes? If so, which modes can be operated simultaneously? (Passive monitoring, wide area search, narrow search, tracking, weather, DVE, pilotage, TF&TA, and shoreline mapping) o Can the system simultaneously track multiple targets? If so, how many, and what data can be collected?

o Can the system simultaneously track multiple types of targets? e.g. ground, littoral, and air targets?

o Does the system support track priorities? If so, explain.

o Can the system simultaneously conduct RADAR operations and passive surveillance/interferometry?

o Describe beam scheduling techniques and expected timelines. Is scheduling adaptive for different modes and multi-mode operation as number of targets change?

• Define the control interfaces for autonomous and manual functions.

o Describe required aircrew interaction/workload to operate the system

• How will the data be displayed?

• When in search mode, will the system automatically detect and track targets?

• Explain how the RADAR accomplishes target detection, recognition, identification, and tracking. Discuss doppler processing and clutter mitigation (sub-clutter visibility). Discuss limitations that exist related to zero radial velocity targets.

o Provide expected detection ranges for standard targets such as small (class-1) UAVs, dismounts, bicycles w/people, motorcycles, cars, trucks, etc.

• Address ability of the RADAR to adapt to inclement weather (rain, snow, fog), back scatter from terrain and interference signals.

o Which DVEs is the system capable of operating in and what are the associated performance degradations?

• Does the RADAR employ AR as an aid in advance mapping techniques?

• Describe interoperability as both a source and victim of RF interference. What forms of mitigation are provided with the system, e.g. blanking, active interference management, etc.

2.2.2 Antenna

2.2.2.1 Characteristics

• Discuss AESA cooling methodology and required environmental conditions for operation.

• Discuss calibration methodology. Where, how often, and when is calibration accomplished?

• Overall size and dimensions of the array

• Antenna Pattern Characterization across frequencies o Field of Regard (FOR) for azimuth and elevation o What is the beamwidth degradation at the extremes of the FOR?

o How is the pattern affected by the utilization of multiple beams? i.e. beamwidth, sidelobe, power.

o If multiple beams are used, can each have a different polarization?

o Minimum 3dB beamwidth/Field of View (FOV) over Az/El, and associated sidelobes o Maximum antenna gain o Describe various beamwidths and associated sidelobes for operational modes.

o Describe the polarization diversity of the system and how it is used.

• Does the system incorporate an azimuth or elevation gimbal? If so, what is the extent of travel?

• Address latency characteristics regarding mode change and beam articulation.

2.2.2.2 Manifold

• Describe the manifold architecture: Basic, Hybrid, Multiple Input Multiple Output (MIMO), Multi-function Phased Array RADAR (MPAR), Analog or digital control.

o Provide a drawing/block diagram

• How are the elements grouped and what limitations exist in the hardware?

o Type and power capability of amplifiers (Power and LNAs) o Phase shifter resolution o Amplitude modulation

• Panels o Is the AESA made up of multiple panels?

o What is the geometry of the panels and is the AESA modular and/or scalable?

o If more than one panel is used, describe panel integration?

o What performance enhancements can be achieved by adding additional panels?

o How is panel integration controlled and calibrated?

• Can the RADAR generate multiple beams simultaneously? If so, how, and how many?

• How are weight and vectors manipulated for each element? Are the values adjusted autonomously?

2.2.2.2 Elements

• How many elements are used per panel?

• What type of elements are used?

• What is the spacing between each element?

• How is vibration and temperature compensated for?

• For dual/multi-band, describe the number of elements per band, and element design o How many elements per band?

• Can all elements transmit and receive? If not, describe the element layout and operation and limitations.

3.0 Product History and Capabilities

Discuss product history and provide examples of product(s) that have been successfully manufactured and delivered. Products described in this section are not required to be the demonstration article presented in section 2.

3.1 Previous/Current Product Information

• Describe similarities and differences between the system discussed in this section compared to the demonstration article proposed in section 2.

• Is this system currently fielded on any U.S. DoD aircraft? If so, please indicate aircraft type and service. Include USG PoC.

• Describe any demonstrated interoperability with other aircraft or weapons platforms.

• Describe system’s ability to interoperate and share information (targeting and other data) with other platform payloads to include Aircraft Survivability Equipment (ASE), RF and Optical sensors and weapon systems.

• Describe demonstrated interoperability/interference mitigation implemented on other platforms.

• Does the system support sensor fusion?

• Describe the open system architecture standards employed and does the system align with

MOSA/SOSA? Are software applications Future Airborne Capability Environment (FACE) compliant?

• What physical interfaces are used? Is there growth potential to newer standards such as IEEE

802.1DP?

• Was the system developed in alignment with HOST standards?

• Is the design versatile enough to separate the processing from the RADAR to reduce SWaP-

C2? And/or is the software separable from the inboard processor, i.e. can the software be hosted on another processor?

• Describe the TRL.

• Describe the MRL.

• Describe the Software Technology Readiness Level(s) SW TRL.

• Is the RADAR capable of conducting point to point communication (Voice and Data) support?

If so, is there interference with the RADAR mission?

• Does the system support pilotage?

• Can the system support increase safety such as operations in DVE? To include: Day, Night, Haze, Clouds, Smoke, Fog, Dust, Rain, Snow, Whiteout, Brownout. Provide details on mitigation algorithms/techniques employed during DVE conditions.

3.2 Human Machine Interface (HMI)

• Describe system’s compatibility with Multi-Purpose Displays (MPDs) and cockpit controls.

• Describe ability to process two operator inputs simultaneously (i.e. one operator selecting search while the other operator is conducting track).

• Describe HMI with regards to controls and display icons.

• Describe HMI with regards to targets, weather, terrain, shoreline, back scatter, and interference signals.

3.3 Maintenance, Updates, and Training

3.3.1 System Built-in-Test (BIT) & Degradation

• Does the system have soft fail?

o Describe the soft fail and how failures are reported to the operator, platform, and other sub-systems.

• Describe the performance degradation regarding loss of elements, channels and panels.

• Describe the level of BIT operations. Prompted BIT and Continuous BIT

• Does the system fault isolate to the LRU level?

• Provide information regarding Reliability, Availability and Maintainability (RAM)

• What is the expected Mean Time Between Failures (MTBF)?

3.3.2 Maintenance

• What level of maintenance is suggested to be performed in the field?

• What level of maintenance requires depot level support?

• Provide expected Sustainment, Field and Depot Support, to include concepts of sustainment, support, and Test Station(s) for Field, Depots, and Engineering Labs.

• Detail the process, equipment, and timetable required to update Software and Firmware. Can this be accomplished in the field?

3.3.3 Training

• Detail the process of training aircrews and maintainers.

• Can training be accomplished in the field using embedded training of or is special factory training required?

4.0 Corporate Capabilities and Limitations

• Describe your company's capabilities and experience in performing software and hardware development for aircraft AESA RADAR systems, both military and commercial.

• Describe any limitations your company may have for responding to this RFI. Include limitations and courses of action necessary to overcome the limitation. Identify whether the limitation is based on cost, schedule, facilities, or technical performance issues you feel should be considered. Describe any agreements that would preclude your company from having the ability to accomplish this effort.

• Describe your company's experience on previous projects similar in complexity to this requirement. Include contract numbers, a brief description of the work performed, period of performance, agency/organization supported, and individual point of contact (Contracting Officer or Program Manager)

• Describe your company's organization to include major products/services, primary customer base, number of employees, annual revenue history, office location, CAGE code(s), statement regarding current Small Business Administration business size and socio-economic classification under (i.e., small, Small-Disadvantaged, Service-Disabled, Veteran-Owned, HUBZone, etc.) and associated NAICS Code under which the company conducts business, statement whether your interest in this effort is as a Prime respondent or to express interest regarding subcontracting possibilities, and contact information (telephone and email) for points of contact of those able to discuss the material submitted.

• Provide any international or Foreign Military Sales export concerns to include potential technology restrictions, requirements, or protections.

• Describe any sensitivities that would disallow participation by foreign partner aircrews or foreign partner witness of the demonstration, to include data sharing.

• Does the respondent have an active facility security clearance that allows the generating, processing, storing, sending, and receiving of CLASSIFIED information/data and the ability to development/test hardware and software at the Secret or higher level?

• Describe relevant experience applying Risk Management Framework (RMF) methodologies for embedded tactical systems and show past performance in cybersecurity hardening of those systems.

• Show adherence to DoDI 8510.01 RMF and DoDI 8500.01 is required, along with Army Regulation AR25-2 Cybersecurity.

• Describe relevant experience and practical knowledge in Static Application Security Testing (SAST) of all custom developed software and provide artifacts to support software assurance requirements IAW DoD and Army regulations and Best Business Practices.

• Provide past performance in the creation of RMF required system artifacts supporting tactical systems such as the System Security Plan, Plan of Action and Milestones, Configuration Management Plan, Concept of Operations Plan, and hardware/software lists.

5.0 Demonstration Strategy

At the discretion of the USG, some respondents may be selected to participate in an in-flight demonstration of their system; no reimbursement will be made for any costs associated with post RFI submittal activities. This section provides an outline of the preparation, conducting, and reporting of the demonstration event.

5.1 Notional Schedule

This schedule provides an overview of the RFI and demonstration timeline including RFI submission, vendor selection, preparation/integration, demonstration and report. This schedule is at the discretion of the USG and is subject to change.

5.2 USG Visit to Vendor Site

As part of the overall product evaluation process the USG may entertain site visits post-RFI submission to conduct the following:

• Further discuss RFI response, and familiarize USG with proposed demonstration article

• Witness an AESA RADAR demonstration (if possible)

• Survey the vendors facility, design, test, & production capability

With the RFI submission, provide a schedule showing when USG can conduct a site visit to vendor facility.

5.3 Preparation/Integration

Prior to the demonstration there will be up to three planning meetings for each of the selected respondents. The planning meetings will take place in the “Integration” time detailed in the schedule in section 5.1. The order and timing of the below meetings may be changed at the discretion of the USG.

• The first planning meeting will be up to a two-day site visit to the Redstone Test Center (RTC) Apache hangar. It will include aircraft familiarization and interface/connection discussions with the RTC instrumentation group and experimental flight test team.

• The second planning meeting will be up to a five-day site visit to the RTC Apache hangar.

This will be an opportunity for each vendor to install the demonstration article on an Apache to check fit and function and conduct initial troubleshooting with the RTC instrumentation group and experimental flight test team.

• The third planning meeting will be up to two-day site visit to the selected vendor’s location.

The purpose of this site visit is to provide system specific hands-on training to the U.S. Army Experimental Test Pilots and Flight Test Engineers that will execute the demonstration. At a minimum, the vendor will be expected to provide training and training materials for the system control/display, discussion of modes/sub-modes, and overview of capabilities and limitations.

5.4 Demonstration Event

Each selected vendor will be allotted a three-week period to demonstrate the capabilities of their AESA system at Redstone Arsenal, Al. The demonstrations are anticipated to occur in alignment with schedule in section 5.1.

• The three-week period will include inventory, installation, ground check, instrumentation check, Electromagnetic compatibility (EMC) check, wedge check, range checkouts. These measures must be completed prior to system demonstration activities. Should the vendor be unable to meet these requirements in the allotted timeline, no demonstration flight time can be guaranteed.

• Upon completion of the required airworthiness testing, up to three pre-demonstration flights in the local flying area may be allotted to each vendor, dependent on time, weather, and maintenance. Pre-demonstration flights will support in-flight check-out, system orientation/alignment, adaptation of system to conform to targets and flight profiles.

• The three-week period will conclude with a demonstration day. The demonstration day will consist of at least one flight in which the demonstration article will be exercised against RTC developed reference scenarios. A second demonstration flight may be possible allowing vendors to further showcase key features of the demonstration article. RTC test pilots will operate the demonstration unit during the pre-demonstration flights and on the demonstration day. Vendors will be able to control/exercise the demonstration unit via the Radio Frequency (RF) up-down link as required under the direction of RTC.

• The RTC developed scenario will include attack profiles for ground, air, and littoral targeting, a Nap-of-the-Earth (NOE) route for Terrain Mapping (TM), TF, and TA, a DVE landing profile to preview pilot aided symbology, and an overwater route for Shoreline/Synthetic Aperture RADAR (SAR) mapping. During demonstration the RADAR will be required to detect, record and display targets at various ranges. i.e. Corner cubes, Dismounts, Ground Targets Stationary and Moving (motorcycle, truck, and tank), Littoral Targets (Stationary and Moving), Airborne Targets In-flight and at Hover (Apache, M530, T6, UAS’s), Telephone poles/towers and wires, Shoreline/SAR mapping, TF & TA, Weather.

o The inability of the demonstration article to perform all modes and functions may not disqualify vendor participation. The intent of the demonstration is to showcase current technology, not to dictate performance requirements. The flight profiles (height above target, aspect, slant-ranges) will be adapted to the demonstration article’s capabilities.

5.5 Post-Demonstration Report

It is the intent of the USG to develop a post-demonstration report for each vendor who participates in the demonstration event. Vendors will provide RAW and processed RADAR data to PM Apache Sensors to substantiate the report detailing the demonstrated capabilities. The USG encourages vendors to engage in the post-demonstration data analysis and provide clarification to the USG to ensure accurate interpretation of the data. A draft copy of the report will be provided to each vendor for their comments prior to finalization. Each vendor has the rights to its recorded data and select aircraft data from the demonstration flights (states, rates, TSPI). Vendors are not prohibited from sharing this data as marketing material, and product development. Final reports will be processed in accordance with Distribution D and the USG will not share the final report with industry.

6.0 RFI Protocol

6.1 Industry Discussions

The Government reserves the right to hold one-on-one meetings or an industry day as a result of responses received from this RFI as part of its market research. PM AAH office representatives may or may not choose to meet with potential respondents. Such discussions would only be intended to get further clarification of potential capability to meet the requirements, especially any development and certification risks. To facilitate information exchange Apache Sensors will entertain a vendor’s request for an NDA.

6.2 Questions

All questions relating to this RFI shall be submitted in writing only via email to Army Contracting Command point of contact, Jarrod Weeks, Contracting Officer, at jarrod.r.weeks.civ@army.mil.

The subject line on the email submissions for questions or requests for clarifications should read:

“RFI: Apache AESA/FCR, Questions/Clarifications”. Absolutely no telephone calls will be accepted in response to this RFI. Questions or requests for clarification shall NOT contain proprietary or classified information. To facilitate a timely response, all questions or requests for clarification are due no later than fifteen (15) days after the RFI Published Date at 4:00 pm Central Time. Responses to the questions received will be answered and posted no later than thirty (30) days after the RFI Published Date at 4:00pm Central Time. USG responses will be available for all interested parties to see via an amendment to the RFI on the SAM website. The Government reserves the right to not address questions or requests for clarification should it not be pertinent to the RFI.

6.3 Responses

• Responses are due no later than sixty (60) days of RFI Published Date at 4:00 pm Central

Time. Responses shall be submitted electronically via the DoD Secure Access File Exchange (SAFE) website (https://safe.apps.mil). To be able to utilize the DoD SAFE website, request a Drop-off code via e-mail to Army Contracting Command point of contact, Jarrod Weeks, Contracting Officer, at jarrod.r.weeks.civ@army.mil. After receiving the Drop-off code, use the following distribution email address as prompted by the site:

jarrod.r.weeks.civ@army.mil. The subject line for the SAFE submission should read: RFI:

“Apache AESA RADAR- YOUR COMPANY NAME”. No hard copy or fax responses will be accepted. If a late submittal is received, acceptance of such will be at the discretion of USG.

Telephone inquiries will not be accepted or acknowledged.

• Responders are requested to submit clear and concise written notification of their interest, qualifications, and technical concepts to meet the requirements of this RFI. All submitted responses shall follow the outline below and be provided in Microsoft (MS) Word compatible format or Adobe PDF. Responses shall be capable of being printed on 8.5x11 inch paper with one inch margin (top, bottom, left, and right) and no smaller than 12-point, Arial font. Line spacing shall be set no less than single space. Any drawings shall be capable of being printed on 11x17 inch paper and no smaller than 10-point font. Responses shall be no more than thirty

(30) total pages with limitations per section as follows: Twenty-page limit for section 2, eight-page limit for section 3, and a two-page limit for section 4. This limit excludes the cover page and table of contents. All figures and drawings are included in the page limits. All responses shall contain a Cover Page identifying:

o RFI Title o Company or organization name, mailing address (City/State/Zip), and Unique Entity

Identifier.

o Company web page URL, if any o Point of Contact (name, title, phone number, and e-mail address) o Distribution D statement

• Responses will be reviewed by Government representatives as approved by the PM AAH office and other governing agencies. All information provided will be adequately protected in accordance with the provided markings.

• Proprietary information should be clearly marked.

• It is suggested that no classified documents should be included in the responses. However, if necessary, the USG may entertain accommodating classified deliveries on a case-by-case basis. Coordination of classified deliveries shall be conducted via email with the Army Contracting Command point of contact, Jarrod Weeks, Contracting Officer, at jarrod.r.weeks.civ@army.mil.

6.4 Post Submission Guidelines

Please, be advised all information submitted in response to the RFI becomes the property of the USG and will not be returned. The Government is under no obligation to provide feedback to respondents with respect to any information submitted under this RFI. There is no guarantee that any submission in response to this RFI will result in a Government program or selection for demonstration. The Government may or may not use any responses to this RFI as a basis for a subsequent project. The information submitted in response to this RFI may be used to help the Government further define its demonstration and or procurement requirements. If the Government develops a program that addresses any submitted or similar topic, the resulting procurement will address technology and business specific requirements as defined by the Government to achieve the required objectives. Any projects developed from the RFI responses may be the subject of a subsequent acquisition; any such subsequent acquisition will be publicized accordingly.

Responders to this RFI will have no competitive advantage in receiving any awards related to the submitted topic area. Responders who do not submit a white paper to this RFI will not be prohibited from submitting a proposal if an RFP is published at some point in the future.