Air Launch Effects (ALE) RFI.docx
DOCX document 2 MB Posted
- Solicitation number
- W56KGU-20-R-0001
View the file
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Army Combat Capabilities Development Command (CCDC) Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance and Reconnaissance (C5ISR) Center, Air Launch Effects (ALE) Request for Information (RFI) Disclaimer This is a Request for Information (RFI) synopsis. This RFI is for planning purposes only. This is NOT a request for Quotations or Proposals. Interested parties are responsible for adequately marking proprietary or competition sensitive information contained in their response. In accordance with FAR 15.202 (e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. The Government will not reimburse costs incurred by Respondent in response to this RFI or for participating in information exchange regarding details of the RFI. Responses may include data that the offeror does not want disclosed to the public for any purpose or used by the Government except for informational purposes. However, please note that the Government and its Systems Engineering and Technical Assistance (SETA) contractors will review the responses to this RFI.
Synopsis The future multi-domain operational environment will present a highly lethal and complex set of traditional and non-traditional targets. These targets will include networked and mobile air defense systems with extended ranges, and long and mid-range fires systems that will deny freedom of maneuver. To gain and maintain overmatch in the future conflict, Army Aviation must modernize and distribute its reconnaissance, surveillance, target acquisition (RSTA) and lethality with an advanced team of manned and unmanned aircraft as part of the Future Vertical Lift (FVL) Future Attack Reconnaissance Aircraft (FARA) ecosystem. The synergistic effect of the ecosystem enables the penetration, dis-integration, and exploitation of an adversary’s Anti-Access Area Denial (A2AD) comprised of an Integrated Air Defense System (IADS) and Integrated Fires Complex (IFC), as well as surveillance and targeting systems, command, control and communications (C3) capabilities, and essential logistical infrastructure. Part of this ecosystem is Air Launched Effects (ALE), a family of small1 and large2 unmanned air launched systems that operate as members of a team with other manned and unmanned platforms to detect, identify, locate, report (DILR) and deliver lethal and non-lethal effects against threats across multiple scenarios and domains in a constantly changing Operational Environment (OE).
The Army Combat Capabilities Development Command (CCDC) Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance and Reconnaissance (C5ISR) Center is currently working on Science and Technology (S&T) planning and development of ALE capability to deliver coordinated and distributed sensing and effects across Electro-Optical (EO), Infrared (IR) and Radio Frequency (RF) spectrums. The overall goal of this RFI is to identify novel and highly capable technologies and enablers that can inform S&T development to better align current and future S&T investment in technology areas of interest for ALE, inform ALE payload and platform requirements, and ultimately identify candidates for current and future ALE mission systems program acquisitions.
It is expected that there will be a Virtual Industry Day held on September 28th, 2020 (less than 60 days post RFI release), where U.S. Government (USG) will walk through details of this RFI, and vendors will have an opportunity to ask questions they may have about its content and objectives. Virtual Industry Day is expected to be about one day in length, with follow-on classified and/or unclassified one-on-one sessions to be coordinated with respective Government Subject Matter Experts. Initial agenda is provided below with details to follow:
· Opening Remarks
· Technology Survey and Execution Strategy
· Multi-Domain Operations Overview
· ALE Operational Employment
· C5ISR Center Technology Briefs
· Q&A and Closeout The follow on virtual one-on-one meetings will be scheduled with the respective C5ISR technology groups and respondants within a week post Industry Day event. The intent of these meetings is to give respondants an opportunity to field detailed questions that may be proprietary in nature, and obtain more in-depth understanding of the information request relevant to their technology areas.
This RFI invites participants from academia and industry to respond. The Response Requirements section details the requirements for responding to Phase I of the RFI which includes the respondent’s reservation of attendance at Industry Day (see template in Attachment A), and requirements for a subsequent whitepaper response to Phase II of the RFI addressing the capability needs for the technologies of interest (see Attachment B). Figure 1 below, provides an objective timeline for Phase I and Phase II announcements, Industry Day event and response submissions for planning purposes. Any adjustments to the timeline will be communicated on the posting site and at Industry Day as appropriate.
Figure 1: RFI Timeline Opportunity for Investment RFI responses are intended to inform the C5ISR Center’s ALE investment strategy. Based on the whitepaper responses, there may be opportunities for respondents to demonstrate their technology to USG personnel and ALE stakeholders (whether in an M&S environment, high fidelity laboratory or in the field) during the FY21 cycle and beyond. Technologies that prove candidacy for potential investment, may be pursued for further technology maturation and evaluation within S&T, and/or for participation in competitive bidding for technology transition into Army Programs Of Record (POR) that ultimately support ALE. S&T investment timeframes may start as early as FY21 and span thru FY25 and beyond. The ALE effort is on a Mid-Tier Acquistion timeline, therefore the transition path to a Program of Record will be dependent on the ability to demonstrate relevancy and applicability of the technology or capability to the ALE CONOPS, technology maturity timelime, and cost/risk to mature and procure the product.
1 ALE Small Platform: < 100lbs 2 ALE Large Platform: < 225lbs
Technology Areas of InterestTable 1 : Functional Domains
The C5ISR Center is focused on core functional domains that span sensors, effectors and enablers across the spectrum for both ALE small and large as shown in Table 1 Respondents shall address these functional domains in their responses using the technology areas below:
1. Hardware for primary ALE mission payloads - DILR, Decoy, Disrupt
2. Hardware, software, and/or techniques for enabling distributed collaborative teaming capabilities, including processing technologies, cyber protection, platform prime power, and radio systems/data links that enable command, control & communications of ALEs. Note: the radio/data links enable command, control, communications of ALE from the launch platform, between ALEs in a team, and between ALEs and back-haul communications links to the ownship/UAS. In addition, position and movement sensors are needed to assess spatial and temporal reference to teammates to support adaptive reasoning.
3. Software/algorithms that fuse, process, decide and act on sensor data enabling the ALEs to autonomously react and adapt their countermeasure techniques to changes in the environment.
4. Multi-mode/Multi-function technologies which may consist of common payloads for Synthestic Aperture + Moving Target Indicator Radar, or combined EW, radar, and communication functions that share common apertures, processing, etc. In addition, responses may include technologies that enhance a lethal strike capability such as multi-function sensing technologies that can also be used for active or passive munitions guidance, or command and control systems that can also be used for munitions targeting.
5. Modular Open Systems Architecture (MOSA): The Government is interested in systems with non-proprietary interfaces and software with non-proprietary program interfaces. ALE will use a MOSA to implement a resilient digital backbone through a government defined reference architecture. Government Owned OSAs under consideration include Joint Common Architecture (JCA), Future Airborne Capability Environment (FACE), and Hardware Open Systems Technology (HOST). However, other open system approaches are requested. Note: documentation on the government owned architectures are not distributable with this RFI, but knowledge information can be found online. Ability to perform/support agile software development is also of interest.
Respondents are encouraged to provide technology and capability responses that address the Technology Areas of Interest from above and align to the technical information highlighted in Attachment B to ensure responses can best inform ALE S&T investment strategies. However, the C5ISR Center will consider other performance or spectral capabilities within the Table 1 functional domains, that may be optimal, but may not have been considered in this information request. Additionally, any new or novel concepts that require additional techincal innnovation will be considered as well.
1 ALE Small – Platform: < 60lbs; Payload: < 8lbs 2 ALE Large – Platform: 150lbs to < 250lbs lbs; Payload: < 30lbs
Payload SWaP and TRL Sensors and effectors may reside in different payloads each with its own platform allocated Size, Weight and Power – Cooling (SWaP-C). Please consider the following categories for payload weight and power:
Table 2: ALE Payload SWaP Targets
| ALE Small |
| < 10lbs |
| 20W – 50W |
| ALE Large |
| < 30lbs |
| 50W – 100W |
| Special Missions* |
| < 100lbs |
| 100W – 150W |
*Exceeds current ALE Payload SWaP but enables consideration of technologies with enhanced capabilities if more power/space was available Payload volume metrics are not yet established, and cooling needs will be based on the prime power system selected for the platform.
The C5ISR Center is looking for innovative technologies that span Technology Readiness Level (TRL) 2 thru TRL 5, and can achieve TRL 6 in the desired timeframes as specified in Table 2. Note that “Time to TRL 6” is not a requirement, but mainly an objective. Therefore information on technologies that may exceed the desired timeframe is still requested.
TRL 6 is defined at minimum, as a system/subsystem model or prototype that can be demonstrated in a relevant environment (ie: simulated operational environment, software partially integrated with hardware system).
Table 3: Hardware/Software TRL Definitions and Timeframe to TRL 6
| TRL |
| TRL Definition |
| Supporting Information |
| Time to TRL 6 |
| TRL 1 |
| NOT Applicable for RFI |
| TRL 2 |
| Technology concept and/or application formulated: Practical applications invented. Potential material or process to solve a problem, satisfy a need, or find application is confirmed. Applications are speculative, and there may not be proof or detailed analysis to support assumptions. Examples are limited to analytic studies. |
| HW: Publications or other references that outline application being considered and provide analysis to support the concept. |
SW: Applied research activities, analytic studies, small code units, and papers comparing competing technologies.
<8 years
| TRL 3 |
| Analytical and experimental critical function and/or characteristic proof of concept: Applied research advances and early stage development begins. Analytical studies and laboratory measurements validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative. |
| HW: Results of laboratory tests performed to measure parameters of interest, and comparisons to analytical predictions for critical subsystems |
SW: Algorithms run on a surrogate processor in a laboratory environment, instrumented components operating in a laboratory environment, laboratory results showing validation of critical properties.
<6 years
| TRL 4 |
| HW: Component and/or breadboard validation in laboratory environment: |
Basic technological components integrated to establish that they will work together. Relatively “low fidelity” compared with eventual system. Examples include integration of “ad hoc” hardware in laboratory.
SW: Module and/or subsystem validation in a laboratory environment:
Basic software components integrated to establish that they will work together. Relatively primitive in efficiency and robustness compared with eventual system. Prototypes developed to demonstrate different aspects of eventual system.
HW: System concepts that have been considered and results from testing laboratory-scale breadboard(s). References to who did this work and when. Provide an estimate of how breadboard hardware and test results differ from the expected system goals.
SW: Stand-alone prototype solving a synthetic fullscale problem, or standalone prototype processing fully representative data sets.
<4 years
| TRL 5 |
| HW: Component and/or breadboard validation in relevant environment: System component and/or process validation is achieved in a relevant environment. Examples include “high-fidelity” laboratory integration of components. |
SW: Module and/or subsystem validation in a relevant environment:
Integration with existing systems. Prototype implementations conform to target environment/interfaces. Experiments with realistic problems. Algorithms run on a processor(s) with characteristics expected in the operational environment.
HW: Results from testing laboratory breadboard system which is integrated with other supporting elements in a simulated operational environment.
SW: Processor selection analysis, Simulation/Stimulation (Sim/Stim) Laboratory buildup plan. Commercial-of-theshelf/ government-off-the-shelf (COTS/GOTS) components in the system software architecture are identified.
<2 years
Technology Readiness Level only tells part of the story of system maturation. Integration and manufacturing are also critical to overall system performance. While, these areas are expected to be less resolved or even unexplored for novel technology development or component level technologies, there is interest in understanding a Respondent’s approach for assessing Manufacturing and Integration Readiness Levels (MRL and IRL) if applicable to the information being provided.
Response Requirements The following section details the Phase I and Phase II RFI approach as well as requirements for whitepaper content. Respondents may submit more than one white paper or provide single solutions that cover multiple functional domains.
Respondents should also note that the Concept Overview and Technical Information Scope in Attachment B will include a Classified Appendix to be provided upon request.
Phase I – Synopsis and Industry Day R.S.V.P.:
For Phase I response to this RFI, respondents must use the template in Attachment A to submit a synopsis of the technology or capability on which they will be providing information. In addition the template must be used to also R.S.V.P for the event. Interested parties cannot R.S.V.P or attend Industry Day without submitting a synopsis, and cannot submit a synopsis without using Attachment A. Instructions on formal submission of visit requests will be provided upon successful receipt and acknowledgment of Attachment A.
If multiple topics are being submitted, only a single R.S.V.P. template needs to be submitted with multiple synopsis pages. Each synopsis shall be limited to one page per topic.
Responses shall be in electronic format, either “.docx” or “.pdf”. The Government will review the submitted responses and follow up with confirmation of receipt and attendance.
Submissions must be unclassified and submitted within thirty days of the Phase I announcement to: usarmy.apg.ccdc.mbx.i2wd-ewags-ale-rfi-1@mail.mil. All emailed questions, requests for clarification, and Attachment A responses shall contain the subject line: “Phase I: C5ISR ALE RFI”.
Phase II - Whitepaper Response:
A final Phase II RFI will be posted within 30 days after the Industry Day event. Interested parties are requested to respond to Phase II with a whitepaper(s), which MUST contain at minimum the following information as it applies to your technology:
· A one page summary of the respondent’s experience with the Technology Area of Interest and applicable Functional Domain
· A clear and concise description of the technology and its capability with technical drawings, concepts, diagrams, pictures or other informative illustrations of the technology
· Use the Technical Information Scope in Attachment B (and Classified Appendix as applicable) as a guide for performance objectives and information requested.
· SWaP-C of the presented technology. Including the following:
· Payload power source type and details, for example:
· What is system prime power dependence?
· Are additional batteries required to maintain encryption:
· Engine type or battery chemistry?
· Manufacturer or developer?
· Payload power specifications
· Energy and capacity of the power source
· Power draw during different modes: AC/DC, average, peak, standby
· Power durations during modes: Peak, Average, Standby (include % time)
· Size and weight of payload energy source
· Payload cooling specifications/constraints
· Describe any interfaces used in technology (i.e. Ethernet, discrete signals, RS-422, etc.)
· Provide any open standards used (VICTORY, FACE, OpenVPX, Big Iron, etc)
· If no open standards used then note any that could be applicable to technology or indicate if it’s a company proprietary interface
· Current TRL and justification
· Technology development path to TRL 6
· Cost Rough Order of Magnitude (ROM) to reach TRL 6 (itemize per year or development phase)
· If applicable, provide technology MRL and IRL and assessment approach
· Estimated per unit cost (for quantities 3, 100, 500, 1000 per ALE variant)
· Employment of technology in operational concept as described in Attachment B
· For component level technologies, respondent shall provide an understanding of how the component could be part of a larger payload or subsystem to provide the target capability.
· For technologies that are multi-mode/multi-function, respondent shall provide the performance tradespace of a single technology with multi-modes/functions vs. a single-mode/function solution.
Responses may include solutions developed for other services (i.e. Air Force, DARPA, ONR), or other applications (i.e. ground systems, ship systems), but must show transferability to an ALE environment. Multiple submissions for different technologies will be accepted, and technologies that span multiple functional domains are also accepted. Submission of proprietary and other sensitive information shall be marked and identified with disposition instructions (submitted material will not be returned) and must be releasable to DoD contractors for Government SETA review (nondisclosure agreements are in place with CCDC).
Responses shall be in electronic format, either “.docx” or “.pdf”. White paper submissions shall be limited to twenty pages in length. There is no page limit on supplemental information (i.e. Security Classification Guide (SCG), publications, laboratory test results). Please do not send previously written proposals or RFIs as supplemental information. They will not be accepted. Responses must be submitted within thirty days of the Final Phase II Announcement.
The Government will review the submitted responses and may schedule further discussions with responding vendors individually. All emailed questions, requests for clarification, and RFI responses shall contain the subject line: “Phase II: C5ISR ALE RFI”.
· Unclassified questions and responses must be submitted to: usarmy.apg.ccdc.mbx.i2wd-ewags-ale-rfi-1@mail.mil.
· Classified questions and responses up to SECRET shall be submitted via SIPRNet to: usarmy.apg.ccdc.mbx.i2wd-ewags-ale-rfi-1@mail.smil.mil.
If you do not have access to SIPRNet, classified information will be accepted by mail; please mark it accordingly and send it via proper channels. Instructions for mailing classified information can be requested via unclassified email at usarmy.apg.ccdc.mbx.i2wd-ewags-ale-rfi-1@mail.mil.
Responses submitted by contractors that contain U.S. classified military information (CMI) generated in conjunction with a DoD program should be classified in accordance with the applicable SCG. Please include a copy of the SCG with the submission. Responses submitted that contain information classified by a foreign government (i.e. Canadian SECRET), should be handled with the same security procedures as U.S. CMI. If the security classification of the foreign government document is shown in English, no other classification marking will be applied. If the classification is not shown in English, the equivalent U.S. classification designation will be marked conspicuously on the document.
Attachment A Phase I: Virtual Industry Day RSVP Response
Please provide the following information on your response
1. Organization Name: ________________________________
2. Primary POC: Name_______________ Phone _____________ Email____________________ (This will be the primary POC for all Industry Day Communications)
3. Total # of Sites for Dial-In: _______________ (Needed to ensure max capacity is not exceeded in teleconference)
4. Information for each attendee (U.S. only attendees for Industry Day. Clearance information required for 1:1 sessions. Security requirements and scheduling of 1:1 sessions (up to SECRET) to occur post receipt of R.S.V.P):
| Name |
| Phone |
| Clearance Level |
| Ex: Jane Doe |
| 123-456-7890 |
| Jane.Doe@Company.com |
| SECRET |
*Add addional rows as needed
5. Based on the information in this RFI, are there questions you would like to have explicity addressed prior to or on Industry Day? Please include your questions here with your submission.
6. Start a new page for each synopsis. Include the following information at minimum:
a. The technology name and description
b. Indicate whether it is proprietary or non-proprietary
c. Indicate whether there is a desire to have one-on-one discussions with the government and in which area’s of interest
d. Indicate applicability to ALE
e. Current TRL
f. Also, for each synopsis, include the following table and mark ‘X’ next to the functional domain(s) that apply to that technology or capability:
Active DILR
Decision-Based Algorithms
Passive DILR (Specify RF or EO/IR)
Platform Prime Power
Decoy (Specify EW, Cyber, Comms, NAVWAR)
Cyber Protection
Disrupt (Specify EW, Cyber, Comms, NAVWAR)
Command, Control, Communications
Attachment B Phase II: Concept Overview and Technical Information Scope I. Introduction Attachment B provides the Operational Concept and Technical Information Scope for the Phase II whitepaper response. Respondents shall provide information on innovative solutions development that could evolve to enable the objectives highlighted in Section III or provide information on technologies that could best support the capability objectives.
This attachment contains a Classified Appendix, which can be mailed/emailed via the appropriate classified channels to Respondents upon request. Questions regarding content in the Classified Appendix should be sent to the classified email address provided in the Response Requirements Phase II section of this RFI.
II. Operational Concept
Figure 2 : ALE Operational View – 1 within FARA Ecosystem During mission execution the FVL ecosystem employs all or some of the ALE functions (DILR, Decoy, Disrupt) dependent on the mission, threat, and environment. The advanced team of manned and unmanned platforms facilitates execution of penetration, dis-integration, and exploitation of the IADS during multi-domain operations to open a window of superiority required to establish reach, lethality and freedom of maneuver for the combatant commander.
ALE Definitions The following sensor and effector functions are primary for the operational concept:
1. Passive Detect, Identify, Locate, and Report (DILR) – Passive detection and reconnaissance while reducing targetable emissions from the ALE. Can be within RF/EO/IR spectrum(s).
2. Active DILR – Further reconnaissance of targets in emission controlled and camouflaged/concealed positions that deny the use of passive detection. RF based
3. Decoy - The capability to employ a credible decoy(s) against an enemy integrated air defense system. Can be electronic warfare (EW), cyber, communications, or NAVWAR.
4. Disrupt – Reducing threat engagement ranges or preventing the acquire/track/guidance of munitions against Army Aviation. Can be EW, cyber, communications, or NAVWAR.
The following functions enable employment of the above sensing and effects for autonomous operation in a distributed environment:
1. Decision-Based Algorithms – Decision Aiding/Making Software resident within the ALE. Interacts with the payload and mission processor to drive an agent to execute a set of behaviors to autonomously react and adapt its sensing and effects.
2. Command, Control & Communications – Radio systems and data link hardware and software that provide highly available (Low Probability of Detection/Intercept/Jamming) low latency short range rapid communications within the FARA Ecosystem. Can include Line Of Sight (LOS) and Non-Line of Sight (NLOS) RF, satellite, optical/laser communications.
3. Power – Advanced batteries, materials and prime power management capabilities for low-SWaP platforms requiring high power efficiencies.
4. Cyber Protection – Prevention of damage to, protection of, and restoration of computers, electronic and wired communications/systems/services including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.
ALE Operational Employment The Operational employment provides context for use of the various technologies that enable the primary ALE functions. However, “out-of-the-box” concepts for multi-function or non-traditional application of technologies in the operational context below is also of high interest.
ALE …
· Executes assigned missions consistent with commander’s intent without requiring direct intervention.
· Self-organizes through Artificial Intelligence (AI) enabled teaming to maximize coverage of assigned mission area and tasks
· Provisioned with the ability to transfer control from the launching platform to another supported element, via permissions-based scalable control interface, ensuring ALE capabilities are maximized across all domains.
· DILR: Passively collects and shares information on threat disposition to provide situational awareness and enable development of Common Operating Picture (COP).
· Decoy: Represent a credible threat to the adversary and provoke illumination of emitters or movement from their positions of cover and concealment.
· DILR: Passive and active sense & geolocate to provide targetable locations to ALE swarm & ownship
· Disrupt: Activate against threat targets of interest denying or degrading the adversary’s ability to target friendlies, communicate, or perform fire control.
· Disrupt: Relay disruption to ownship allowing for coordinated lethal strike
· DILR: Conduct battle damage assessment (BDA) and report to ownship
· DILR: Actively and passively perform additional reconnaissance, detecting threats and obstacles along routes. Share threat information with Disrupt to deny/degrade threats, and ownship for communications to ground maneuvers
· DILR: Actively detect to support BDA during the attack and provide AI-augmented feedback on specific degradation to combat systems including differentiation of firepower, mobility, and catastrophic kills
III. Requested Technical Information Scope The following provides the technical information scope for Respondents’ Technology Areas of Interest per each Functional Domain. The descriptions represent objective system capabilities which are meant to encourage both the creation of novel concepts that will one day enable those objectives and the evolution of mature technologies that can produce those capabilities in the near term. Items marked (C-A) are provided with additional information in a Classified Appendix under the same heading/section as below.
1 Active RF DILR
1.1 Seeking Radar sensor with modes that include but not limited to Synthetic Aperture Radar (SAR), SAR motion video (e.g. VideoSAR), Moving Target Indication/Tracking, Forward-looking Real-beam Imaging, Scanning Doppler Beam Sharpening, and Monopulse Ground Mapping
1.1.1 It is not expected that hardware supports all of the above-mentioned modes post-launch, but a pre-launch selectable/re-programmable implementation is desired if all modes are not available post launch due to SWaP-C constraints.
1.1.2 For SAR/imaging modes, assume sigma_sub_N (noise equivalent RCS) of -25 dB when calculating maximum operating ranges.
1.1.3 For MTI and other Target detection modes, assume a 10 dBsm target RCS, a detection probability of .85 (single scan) and a false alarm rate of 10^-6, when calculating range performance.
1.2 Radar capabilities requested in RFI response as technology maturity is sufficient to define as technology maturity is sufficient to define:
| 1.2.1 |
| Data Collection Modes |
| (e.g. strip, spotlight, circle, RRCA, GRCA, STT, RBM etc.) |
| 1.2.2 |
| Operating Frequencies |
| Include associated frequency authorizations (e.g. FCC licenses, JF12’s, etc.) if available |
| 1.2.3 |
| Bandwidth |
| · Instantaneous transmit and receive bandwidths |
· Total tunable/accessible bandwidth of the system
| 1.2.4 |
| Antenna |
| · Gain |
· Beamwidths
· Dimensions of active area
· Number of subarrays and/or aux channels
· Scan Performance
| 1.2.5 |
| Transmit Power and Duty Cycle Limits |
| 1.2.6 |
| Resolution and Fields of View |
| Per radar mode |
| 1.2.7 |
| Link Budget |
| Per radar mode |
(with all necessary parameters i.e. Blake Chart for calculation of maximum range)
| 1.2.8 |
| Detection Capability |
| · Probability of Detection |
· Detection Range
· False Alarm Rate
· Target Location Accuracy
| 1.2.9 |
| Minumum Detectable Velocities |
| MTI Modes |
| 1.2.10 |
| Multiplicative Noise Ratio |
| Imaging Mode |
| 1.2.11 |
| Processing |
| · Include On-board and Realtime processing |
· Indicate # of Independent Transmit & Receive Channels
| 1.2.12 |
| Grazing Angles Used for any Previous Data Collections |
| · Maximum and minimum angles per collection mode |
· Stand off ranges per angle
· Shadow mititgation for low grazing angle collections: The government is interested in unique and novel methods for avoiding terrain masking when operating at low grazing angles, to include but not be limited to, automated and dynamic retaskings, pre-mission planning, route following modes or other techniques.
| 1.2.13 |
| Automatic Target Recognition (ATR) |
| Targets to be used for development |
· Algorithm development status
· Radar modes used to train algorithm
| 1.2.14 |
| Sample Imagery |
| Label imagery with the following minimum parameters of the collection: Slant Range, Altitude, Grazing Angle and Resolution |
2 Passive EO/IR DILR
2.1 Payloads should consist of an EO/IR sensor unit, Inertial Measurement Unit (IMU), and Aided Target Recognition (AiTR) processor.
2.2 AiTR Onboard Processor may process full bandwidth imagery with AiTR algorithms
2.2.1 False Alarm Rate (FAR) of 0.06 false alarms per square degree of area searched. Graceful degradation past specified range in low to mid clutter, or a high clutter complex environment.
2.2.2 Aided Target Cueing/Detection (AiTD) for automatic cue to operator indicating presence of potential targets of a selected target size and/or profile within a scene. Post processes near real time. Allows operator to adjust false alarm rate by selecting target detection probability.
2.2.3 Aided Target Recognition of Detected Targets (AiTR) for automatic aid to operator to support recognition of target-like objects detected. Performing on scanned and/or point-and-stare imagery generating potential target locations at increased recognition resolution. Allows operator to adjust false alarm rate by selecting target detection probability.
2.3 Sensor unit may come in two variants (C-A):
· Small Payload: consists of an EO/IR sensor unit, stabilized gimbal, IMU, and AiTR processor.
· Large Payload: consists of common sensor backbone architecture (EO/IR sensor, stabilized gimbal, IMU, and AiTR processor) as the Small payload with additional SWaP to support increased standoff range, probability of detection and recognition. May include provisions for a Laser Range Finder for improved target location accuracy.
2.3.1 Sensor payloads to function in day, night and Degraded Visual Environments (DVE).
2.3.2 Sensor to look forward or nadir as required by ALE airframe mission altitude and attitude to achieve the payload performance requirements.
2.3.3 Output of payloads capable of selecting either Full Motion Video (FVM) or single image target pictures to include target coordinates.
2.3.4 Sensor stabiliziation using a mechanically stabilized gimbal with an on board IMU unit
· For Small Payload: ≤ 200 µrad for IMU unit
· For Large Payload: ≤ 100 µrad for IMU unit
· Resolution measured by Instantaneous Field of View (IFOV) in mrad for narrowest FOV in each camera band. Field of View Search (C-A)
2.3.5 EO/IR sensor capabilities requested for each of the payload variants in response as technology maturity is sufficient to define:
| 2.3.5.1 |
| Spectral Bandwidth |
| Provide spectral bandwidth to cover both the EO Visible band and Thermal IR band for day and night performance. |
Target performance:
· EO Day Camera Perfromance
· EO Day Camera Light Level Performance
· IR Night Thermal Camera Performance
· EO Sensor Coverage Rate
· IR Sensor Coverage Rate
| 2.3.5.2 |
| Sensitivity |
| Include thermal camera’s Noise Equivalent Temperature Difference (NETD) and the Low Light Level capability of the reflective camera(s) |
| 2.3.5.3 |
| Optical Field of View (FOV) |
| Provide the narrowest Optical FOV for each of the sensors. If a sensor has multiple FOVs include the Widest FOV as well. |
| 2.3.5.4 |
| Field of Regard (FOR) |
| Provide operational FOR for each sensor when in the narrowest FOV. |
| 2.3.5.5 |
| Target Location Error (TLE) |
| Provide measured or predicted TLE for sensor |
3 Passive RF DILR
3.1 Sensor technologies will passively detect RF targets with a high probably of detect and identify, geolocate radar threat emitters with sufficient accuracy, and provide detected emitter data/waveform parameters to advanced team for threat classification.
3.2 Sensor payloads may come in two variants:
· Small Payload: Consists of antenna, RF signal processing, and processor which performs task management and Mission Data File (MDF) functions.
· Large Payload: Consists of antenna, RF signal processing, and processor which performs similar task management and MDF functions as the Small payload with additional SWaP to support increased performance such as standoff range, probability of detection, identification of agile waveforms, and FOV.
3.2.1 High probability to detect and identify threats with agile complex waveforms in complex RF background with low false alarm rates (C-A)
3.2.2 Detect, identify, and locate threats across the frequency spectrum using minimal antennas. Frequency range and high priority threats (C-A)
3.2.3 Detect and identify in all polarizations
3.2.4 Wide IBW with high dynamic range to help with high probability of intercept and to detect large and small signals. Examples include, but not limited to, very wide IBW per channel or use of multiple channels.
3.2.5 Efficient channel count per unit SWaP. This helps to perform more functions, geolocation, and/or detect and track multiple threats simultaneously.
3.2.6 Detect and identify multiple threats simultaneously for better situational awareness. This includes monitoring mode changes, waveforms, and threat behavior. (C-A)
3.2.7 Perform battle damage assessment
3.2.8 High sensitivity to detect at farther ranges as well as low signals (C-A)
3.2.9 Wide FOV for detection from different aspect angles while requiring less maneuvering. (C-A)
3.2.10 Payload should perform rapid real-time or near real-time geolocation of RF emitter using a single ALE in a communications denied environment. Accuracy and time to resolve location (C-A)
3.2.11 Payload should perform rapid real-time or near real-time geolocation of RF emitter using multiple ALEs in a communications denied environment. Accuracy and time to resolve location (C-A)
3.2.12 Payloads should mitigate blue force emitters fractricde. It is crucial to not detect and identify blue force emitters as adversary emitters.
3.2.13 Use of cognitive ES to improve detection, idenfication, and battle damage assessment of unknown RF emitters in a complex background. Cognitive ES algorithms will need to balance performance with limited computing resources, prime power, and other functions.
3.2.14 Payloads to function in day and night in all weather conditions.
3.2.15 Report capability of information to a C2 node or other ALEs. This includes, but not limited to, target data, Battle Damage Assessment (BDA), and other raw and/or processed tactical messages.
3.3 Payloads should be scalable from Small to Large ALE allowing use of common components or modules to build the payload by simply increasing or decreasing number of modules. Reduces NRE, cost, and time to develop per platform constraints and mission requirements.
3.4 Passive RF sensor capabilities requested for each of the payload variants in response as technology maturity is sufficient to define:
| 3.4.1 |
| Spectral Bandwidth |
| Include: |
· Frequency Coverage
· Instaneous Bandwidth (IBW)
· Dynamic range
| 3.4.2 |
| Antenna Design |
| Include: |
· Antenna type and configuration
· Antenna gain
· Field of View (FOV)
| 3.4.3 |
| Detection Capability |
| · Ability to detect and identify agile complex waveforms |
· Signal measurement accuracies
· Algorithm description
· Approach for future growth to cognitive ES or approach for handling unknown signals
· # of Channels
· Any ability for channels to adapt, retune, filter
· Detected radar modes
· Angle of arrival
· Sensitivity
· Operational detection ranges
· Simultaneous detections
| 3.4.4 |
| Real-Time Single-ship and Multi-ship Geolocation |
| · Algorithm description |
· Geolocation accuracy
· Time to resolve location at specific ranges (including Angle of Arrival)
| 3.4.5 |
| Tradespace |
| · Addressing all the above capabilities may be challenging which may result in a tradespace. Please describe the tradespace for performing these capabilities versus SWaP, FOV, scalability, thermal/cooling, and platform constraints. If design trades or considerations were made, please discuss rationale for making those decisions for small and large payloads. |
4 Decoy/Disrupt (EW, Offensive Cyber, Counter-Communications, NAVWAR)
4.1 Decoy should stimulate adversary ISR capabilities
· Particularly ISR systems that feed adversary’s kinetic decision-making, such as Direction Finding, Time/Frequency Difference of Arrival, Power on Arrival, Air and Ground Moving Target Indication, and other Geolocation, detection and sensing capabilities not mentioned.
4.2 Decoy technology should present a credible threat to provoke illumination of emitters (that are operational but in a dormant state) or movement from their positions of cover and concealment. Decoy should create accurate signature to radar in range and/or Doppler, frequency, amplitude. (C-A)
4.3 Decoy/Disrupt sensor units may come in two variants:
· Small Payload: Consists of antenna, signal processing, and processor
· Large Payload: Consists of antenna, signal processing, and processor with additional SWaP to support increased performance such as standoff range, technique effectiveness, FOV, and multiple functions.
4.3.1 Decoy/disrupt threats with agile complex waveforms with sophisticated techniques to address modern threat counter-countermeasures (C-A)
4.3.2 Decoy/disrupt across the frequency spectrum using less antennas and high efficient wideband amplifiers on an ALE. Frequency range and high priority threats (C-A)
4.3.3 Decoy/Disrupt in all polarizations
4.3.4 Decoy/disrupt threats with ERP required to perform techniques and/or mission (C-A)
4.3.5 Wide IBW with high dynamic range to perform against agile threats. Use of IBW and channels enable better track of radar pulses and helps improve countermeasure response.
4.3.6 Efficient channel count per unit SWaP. This helps to perform more functions and/or disrupt multiple threats simultaneously.
4.3.7 Decoy/Disrupt multiple threats simultaneously. (C-A)
4.3.8 Support digital beamforming depending on aperture design.
4.3.9 Wide FOV to disrupt from different aspect angles and require less maneuvering of ALE (C-A)
4.3.10 Simultaneous transmit and receive (STAR) for very low latency and/or adaptive response
4.3.11 Perform effects on current and emerging complex emitters. Focus on disrupting advanced waveforms, modern EP, and adaptive modulations. To perform advanced effects, must monitor mode changes, waveforms, and threat behavior. Example techniques include but not limited to range-based, doppler-based, false plots, decoys, coherent, masking, noise, adaptive polarization. Additional technique description and threats or threat types are (C-A).
4.3.12 Perform team-based and/or distributed techniques across multiple ALE.
4.3.13 Payloads should mitigate blue force emitters fractricde to avoid countering blue force emitters.
4.3.14 Use of cognitive capabilities to improve effectiveness against unknown threat emitters. Will need to balance performance with limited computing resources, prime power, and other functions.
4.3.15 Able to host third party techniques and/or EW/Cyber/Communications/PNT applications
4.4 Payloads need to be scalable from Small to Large ALE. Intent is to use common components or modules and build the payload by simply increasing or decreasing number of modules. This should reduce NRE, cost, and time to develop a system that meets platform constraints and mission requirements.
4.5 Payloads to function in day and night in all weather conditions.
4.6 Decoy and Disrupt capabilities requested in response as technology maturity is sufficient to define:
| 4.6.1 |
| Spectral Bandwidth |
| · Frequency Coverage |
· Instaneous Bandwidth (IBW)
· Dynamic range
| 4.6.2 |
| Antenna Design |
| · Antenna type and configuration |
· Antenna gain
· FOV
· Beamforming capability (if applicable)
· STAR
· If implementing conformal antennas, describe tradespace on impact to performance and above requirements
| 4.6.3 |
| Decoy/disrupt capability |
| · ERP |
· Operational range
· Number of Simultaneous threats
· Types of techniques or specific techniques for decoy/disrupt (includes single ship and multi-ship based techniques)
· Describe use of cognitive EA given ALE platform constraints
· Latency
| 4.6.4 |
| Decoy Signature |
| · Targets or types of signatures that can be presented |
· Approach for creating a decoy
| 4.6.5 |
| Tradespace |
| · Addressing all the above capabilities may be challenging which may result in a tradespace. Please describe the tradespace for performing these capabilities versus SWaP, FOV, scalability, thermal/cooling, and platform constraints. If design trades or considerations were made, please discuss rationale for making those decisions for small and large payloads. |
· Multifunction - Describe tradespace for implementing any combination of EW, Cyber, Communications, PNT disrupt functions using same system or components.
5 Decision-Aiding/Making Software/Algorithms
5.1 Decision based software algorithms should be capable of assessing the environment (blue force vulnerabilities and activities, red force activities) to determine the most optimal behaviors required within the functional constraints of the agent.
5.2 Decision aiding are decisions that may be sent upstream to aid in execution of mission level tasks or support situation awareness for the common operating picture (i.e. maneuvering for optimized effect). Decision making are decisions made local to the system to change its own behavior or execute a payload function (i.e. perform disrupt techniques X then Y).
5.3 Decisions will be sensor and effector focused and lead to behaviors that drive execution of an effect or execution of an action needed to create an effect, including:
· Algorithms that autonomously characterizes known/unknown threat emitters
· Algorithms that autonomously determine the best technique or combination of techniqes to decoy/disrupt the threat, including # of agents, location of agents and time on target
· Algorithms that monitor countermeasure effectivness to further optimize response
5.4 Algorithms should enable employment with a single agent or across a team of agents in a distributed environment (i.e. Multi-platform sensor data correlation to make more informed decisions, or coordination across multiple platforms for cooperative engagement)
5.5 Decisions may be based on fixed rules for pre-optimized behaviors, or may employ adaptive reasoning per changing environment/states.
5.6 State changes include but not limited to the following and can occur within the Blue Force or Red Force:
· Change in mission/function (New target resulting in change from Decoy to Disrupt)
· Change in techniques (from Masking to Attack)
· Change in position (to improve technique effectiveness or compensate for degradation, etc)
· Change in threat mode and/or threat position
· Change in # of ALEs (attrition or acquisition of agents)
5.7 Decisions should take into account platform geometries and operational constraints, for example roll rate, turn radius, pitch angle, etc.
5.8 Decision based algorithms should support operations in a degraded communications environment.
5.9 Algorithm information requested in response as technology maturity is sufficient to define:
| 5.9.1 |
| Adaptability |
| Discuss levels of adaptability employed in algorithm approach (ie: Preprogrammed Collaborative Adaptive) and how increasing levels of adaptability is achieved. |
| 5.9.2 |
| Coordination |
| Discuss factors for coordination across distributed elements, i.e.: |
· Number of nodes
· Level of Autonomy
· Information shared between agents to enable coordination
Also discuss how coordination is achieved and further optimized for an increasing level of coordination among distributed assets.
| 5.9.3 |
| Architecture |
| Provide information on architecture approach including requirements impact on communications interface, computing resources, and decision tree analysis. Include information on structure (centralized, decentralized) and type (open, proprietary) |
| 5.9.4 |
| Cognition |
| · Describe information used to formulate optimal decisions (i.e. environmental, threat, friendly data) |
· Describe the state of the information (i.e. pre-processed vs. post-processed data)
| 5.9.5 |
| Information Sources |
| In addition to cognition of the environment, there may be information required from the resource manager or communications interface to inform decisions (for ex. How much power is available drives the decision to use a single agent or multiple agents to disrupt a target; Knowing there is loss of communications drives decisions to be made with reduced dependency on external resources) |
· Describe the information used from the resource manager that informs decisions for EW operations and how this information drives requirements for adaptability and/or level coordination across the team for the EW mission.
· Indicate what information requires low-latency communications vs what coms from the mission processor
| 5.9.6 |
| Data Correlation |
| Describe how data correlation capability within technology is performed, managed and shared in a decentralized architecture |
| 5.9.7 |
| Tradespace |
| It’s inderstood that technology application and mission requirements will impose constraints on the decision based algorithms including the complexity of the decisions, the decision path, and the amount of information available to make a decision vs the level of congnition a system must have to adapt its behaviors. Describe the tradespace for the decision algorithms that support the above (or similar) capabilities vs communications bandwidth, level of autonomy, latency requirements to support mission, level of coordination, and edge processing capability. |
6 Command, Control, Communications (C3)
6.1 Links must be resilient in congested and contested EW environments with characteristics such as Anti-Jam and Low Probability of Intercept/Low Probability of Detect.
6.2 Provides a resilient, mesh self-healing network.
6.3 C3 capabilities requested in response as technology maturity is sufficient to define:
| 6.3.1 |
| Frequency |
| Provide operating frequency bands |
| 6.3.2 |
| Bandwidth |
| Provide channel bandwidth(s) |
| 6.3.3 |
| Latency |
| Provide glass-to-glass latency |
| 6.3.4 |
| Number of Nodes |
| Provide the number of physical network nodes that can be supported |
| 6.3.5 |
| Radio Systems/Data Links |
| Provide link capability for ALEs to operate as a single asset or as part of a team of ALEs or a Swarm to execute the same mission or different missions. Include type of communications system(s) used (including LOS, BLOS, point-point, etc.) and protocol(s). |
| 6.3.6 |
| Multi-Function |
(C3 and Assured PNT) If applicable, describe the capability within technology to multiplex critical C3 and precision timing and location applications from a single radio. Include tradespace for this approach.
| 6.3.7 |
| Multi-Function |
(C3 and Assured PNT) If PNT and C3 is included in a single radio, provide the following support information:
· Operating frequency bands for PNT
· Concepts or approaches for Real Time Kinematic positioning based on terrestrial or team sources
· Timing transfer approaches to synchronize carrier frequency resolution to at least 12GHz
· Approaches to generate non-GPS based PNT within single ship or transmit timing information to generate PNT within the team/formation to support collaborative missions
7 Platform Prime Power
7.1 ALE is tube launchable from a manned aircraft or large UAS. The ALE Prime Power may come in two variants and should be able to support the metrics provided in table 7.2 below. (Note: KTA = Knots True Airspeed)
· ALE Large - targets per prime power type
· Propulsion power: ~20 hp (15 KW)
· Electric motor/battery weight: ~90 lbm with 175 km range
· Engine/fuel weight: 90.5 lb with >400 km range
· ALE Small - targets per prime power type
· Propulsion power: ~10 hp (7.5 KW)
· Electric motor/battery weight: 65 – 75 lbm with >150 km range
· Engine/fuel weight: 20 – 30 lb
7.2 Metrics table for novel power and energy technologies:
| 7.2.1 |
| System metrics |
| ALE Small |
| ALE Small |
| ALE Large |
| ALE Large |
| Metric |
| Objective |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .