HDTRA1-19-S-0006_Addend_1_Improvised_Threats_Detect_and_Defeat_final.pdf

ADDENDUM # 1

to the

DEFENSE THREAT REDUCTION AGENCY

BROAD AGENCY ANNOUNCEMENT

HDTRA1-19-S-0006

IMPROVISED THREATS

DETECT AND DEFEAT

SEPTEMBER 2019

Addendum 1 to HDTRA1-19-S-0006

1 FUNDING DESCRIPTION

1.1 This addendum supplements the Defense Threat Reduction Agency’s (DTRA) Improvised Threats Detect and Defeat Broad Agency Announcement (BAA), HDTRA1-19-S-0006. This research opportunity expands on multiple Research & Development Technology Areas as listed in the BAA.

1.2 DTRA’s Counter Improvised Threat Department (hereafter ‘RD-TT’) is seeking, in accordance with Section 6 of the above referenced BAA, Phase I White Papers in response to the below Topics (Attachment 1 to this addendum). Submitters of selected White Papers will be invited to submit Phase II proposals. Each Phase II proposal received in compliance with this process will be fully evaluated by the RD-TT scientific staff, in accordance with Attachment 8 of the above referenced BAA. Non- RD-TT experts of similar relevant qualification may be asked to assist this evaluation effort.

1.3 The form of any awarded contract will depend upon the Offeror's accounting system. An accounting system previously approved by DCAA will allow the award of a cost-type contract.

An Offeror without a DCAA-approved accounting system will be eligible only for a non-cost reimbursable (e.g., firm-fixed price) type contract award.

2 BACKGROUND

Past counter-improvised explosive device (C-IED) efforts have resulted in a wide variety of technologies and techniques addressing improvised threats, with varying effectiveness. These include numerous methods of threat detection, prosecution, and exploitation. The Topics presented in this Addendum are crafted to refine and advance many of these, with an ultimate goal of saving lives and defeating the improvised threat as an instrument of political influence on the battlefield as well as civilian gathering places.

3 OBJECTIVE

The Topics listed below are tightly focused and scoped to quickly accomplish advancements in specific areas of current interest, each materially contributing to the overall counter-improvised threat effort. The Topics may also serve as catalyst for innovative thought and effort, resulting in the repurposing and integrating of one or more existing technologies and techniques against these threats. The ultimate objective is to produce or uncover a gem that will significantly advance our efforts against improvised threats.

4 TOPICS

4.1 RD-TT invites Phase I White Paper packages responding to the below Topics.

Responders will provide as many Phase I White Paper packages for each Topic as they choose, but each Phase I White Paper package will address only one Topic. Please see Attachment 1.

5 MAJOR MILESTONES

5.1 The schedule for Addendum #1 is captured in the following table:

DATE EVENT

30 Sep 2019 BAA Addendum announced in FedBizOpps website

Publishing date plus xx calendar days, as shown on each Topic Final day to submit Phase I package

Deadline plus 14 calendar days RD-TT email responses to Offerors who submitted Phase I packages by the deadline. Responses will be either selection or non-selection notices, without further comment.

Selection notice plus 30 calendar days Phase II packages submission deadline

Submission deadline plus 45 calendar days Notifications of selection or non-selection will be sent to Offerors via email Selection for award plus 30 calendar days Commence discussion and negotiations

Awards expected to begin approx. 150 days following initiation of negotiations 1, 2

Notes:

1. Actual award dates will vary based on receipt of funding, complexity, statutory requirements, proposal quality, pricing considerations, DCAA audits of proposed rates, type of instrument, number of awards, and other considerations. All dates are subject to change.

2. Awards will be made subject to the availability of funds. All Offerors will be invited to begin negotiations upon notification of intent to award.

6 PHASE I and II PACKAGE SUBMISSION INSTRUCTIONS

6.1 Each of the Topics (presented in Attachment 1) is open and available for Phase I submission for only a short period of time. Each Topic identifies its open period. Phase I and II packages received past the deadlines will not be evaluated.

6.2 In accordance with paragraph 3.7 of the BAA, periods of performance may be up to five (5) years from the date of contract award.

ATTACHMENT 1

Topics

Topic 1: 60 Days to submit Phase I packages from date of publishing

Generating and Operationalizing Organism Evolutions and Excretions (GOOEE)

DTRA seeks proposals for solid materials or polymers that can be activated at point-of-use to undergo a condensation reaction. Reactants will need to be transportable, stable until activated, and lightweight. Though any solid-state, polymeric, or biochemical reactions that are able to produce water as a byproduct will be considered, preference will be given to reactants that demonstrate one or more of the following:

1. Opportunistic reaction with molecules in the environment such as nitrogenous compounds or lipids

2. Utilization of environmentally-safe or biologically derived components

3. Catalytic water production

4. Polycondensation of either the reactants or opportunistic environmental molecules

5. Safety when used in unventilated environments

Methods that are based solely on the encapsulation and delivery of water are not desired; however methods that utilize encapsulated reactants with water included as a reactant or solvent are acceptable.

Proposed concepts should include sufficient data to ascertain concept viability beyond small-scale lab or chamber environments. While no single concept of operations (CONOPs) exists, consideration should be given to the logistical burden(s) associated with the transport and deployment of the proposed water delivery method.

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Miscellaneous.

h) If requested to submit a Full Proposal, cost shall not exceed cost estimate in white paper.

Topic 2 30 Days to submit Phase I packages from date of publishing Working Against Bomb Initiation Techniques

DTRA seeks proposals for developing the capability to neutralize or defeat any battery or batteries powering an improvised explosive device (IED) or improvised threat, from a stand-off distance (and without requiring physical contact with the device), without requiring a priori knowledge of the location and type of the IED or improvised threat, and through overburden, casings or other obstructions. While there is no preferred method for stand-off neutralization/defeat, the method must NOT cause the IED or improvised threat to function as intended. Further, defeat must be verifiable under all the same non-contact/stand-off conditions stated above.

The one component that almost all IEDs and improvised threats will have is a power source, which is why the ability to defeat the power source is highly desirable. The power source found in these threats is generally a battery or set of batteries. The battery types span the entire spectrum, from dry cells, to lead acid, to nickel-metal hydride to lithium ion, and they can be in nearly any configuration imaginable. It may be the case that a capability to defeat one or more types of battery will not work against other types; there may not be a one-size-fits-all solution. A capability against some batteries or battery types (i.e. a partial solution) is acceptable.

Given the limited amount of accessible data regarding known battery failure mechanisms, studies or experimentation that lead to a proof-of-concept demonstration of intentional battery failure are acceptable. While there is no single concept of operations for this capability, end user safety, bystander safety and collateral damage potential must be part of the analysis that leads to a successful proof-of-concept demonstration.

The following factors may lead to a successful white paper:

1. Novel/innovative approach(es) to intentionally draining or disabling batteries via non-contact, stand-off methods

2. Studies that lead to complete understanding of intentional battery failure mechanisms

3. Clearly stated technical assumptions

4. Explanation of the underlying battery neutralization/failure phenomenology

5. Data or references supporting battery neutralization/failure claims

6. Brief bystander and/or user safety analysis (e.g. laser derived eye safety or ionizing radiation hazards)

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

i) Data and final reports are to be FVEY releasable.

j) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

k) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

l) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

m) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

n) Components conform to DoD Architecture Framework to the maximum extent possible.

o) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

p) If requested to submit a Full Proposal, cost shall not exceed cost estimate in white paper.

Topic 3 60 Days to submit Phase I packages from date of publishing Directed Energy Detect and Defeat of IEDs

DTRA is seeking proposals for techniques and technology to enable stand-off neutralization of threat devices by inducing any of a broad range of failure mechanisms in them using Directed Energy (DE) in the form of High Power Microwaves (HPM) or High Power Radio Frequency (HPRF). Effects such as: pre-detonation; non-explosive disabling of detonators; disruption of electronics; battery drain, degradation or destruction; and capacitor disruption are sought. Solutions that focus on the jamming of communication or control links are not of interest in this BAA.

DTRA seeks broadband, frequency agile sources. Pulsed solutions are of greater interest than are continuous wave solutions. Solutions using or dependent on single frequency or narrowband sources (e.g. magnetron-based solutions) are not of interest unless they are frequency-agile (i.e. can be “tuned on the fly”) without requiring deactivation or mechanical alteration of the source. Solutions using high energy LASERs are not of interest at this time unless they can be used to create HPM or HPRF radiation, or aid in projecting it through free space (e.g. by effectively creating a waveguide through air).

DTRA seeks

1. New or novel approaches to generating broadband HPM/HPRF.

2. Approaches that use LASER-driven photoconductive switches.

3. Approaches based on nonlinear transmission lines.

Scalability and frequency agility are both highly desired. Existing technology will be given greater consideration than concepts or designs. Performance and effectiveness claims for a proposed approach should be supported by data from tests, experiments or demonstrations.

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

q) Data and final reports are to be FVEY releasable.

r) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

s) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

t) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

u) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

v) Components conform to DoD Architecture Framework to the maximum extent possible.

w) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

x) If requested to submit a Full Proposal, cost shall not exceed cost estimate in white paper.

Topic 4 30 Days to submit Phase I packages from date of publishing Searchable Multi-Story Artificial Robotic Technology

DTRA is seeking proposals for the build or enhancement of a current robot able to successfully maneuver through a multi-story building that could be potentially armed with IED’s and-or booby traps. Key tasks that the robot shall overcome, but are not limited to, are opening and closing doors, maneuvering around various obstacles (e.g., furniture, rubble, holes, etc.), navigating over and through rough terrain, and climb up flights of stairs. Should the robot become unstable and fall it must have the ability to overcome and continue its mission. The locomotion of the robot will be required to maneuver throughout the structure at a quick pace while performing its duties to ultimately map, detect, and defeat the threats within the structure. The robot shall be as autonomous as possible with the intent to be completely autonomous in the future. No preference is given regarding overall robot weight or deployment method; however, assumptions regarding robot size, weight and power and deployment method must be clearly stated. The robot must not be adversely effected by known electronic warfare methods.

The hardware architecture is required to be open architecture. The software development model shall be government owned shared software and shall leverage and make contributions to the Robotic Technology Kernel (RTK), Robot Operating System Military (ROS-M), the Video Processing and Exploitation Framework (VPEF), and Advanced Video Activities Analytics (AVAA).

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 5 60 Days to submit Phase I packages from date of publishing Simultaneous Transmit and Receive Tracking

The goal of full-duplex radio technologies is to allow simultaneous transmit and receive enabling efficient transmission during jamming. To that end DTRA-RD-TTT invests in Science and Technology initiatives that will provide US forces improved communications capabilities.

DTRA-RD-TT seeks proposals to develop and demonstrate technologies for the next generation full-duplex radio technology devices. White Papers and subsequent proposals should address technology developments in one or more of the following research areas:

1. Same frequency simultaneous transmission and reception (SF-STAR) closed-loop echo cancellation techniques which can be implemented purely in analogue domain

2. SF-STAR digital cancellation algorithms

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 6 30 Days to submit Phase I packages from date of publishing Multi Entity Correlation, Aggregation, and Disambiguation Architecture

DTRA/RD-TT is seeking proposals to establish a multi-entity correlation, aggregation, and disambiguation reference implementation that may be agilely instantiated for a variety of mission driven applications. Proposer must provide an extensible, adaptable, reconfigurable (e.g., centralized, distributed, and hybrid), and scalable architectures and frameworks that implement multi-entity Correlation, Aggregation, and Disambiguation (e.g., data fusion) within a geospatial model. Proposal must include highly scalable converged data platforms and fabrics to host analytics and the data exploitation architecture. Proposer must be experienced with working with such systems at the Software Engineering Institute (SEI) Capability Maturity Model Index (CMMI) Level 3 or higher.

The standard references must allow interoperability across DoD and the Five Eyes partners, such as:

1. STANAG 4586 Interoperability;

2. Motion Imagery Standards Board (MISB);

3. NITF Portable Reference Imagery (PRI);

Proposal must include information on graph analytics implementations for:

1. Multi-entity correlation, aggregation, and disambiguation (e.g., data fusion);

2. Graph based self-organizing maps (SOMs) based on Kohonen and hybrid Kohonen networks;

3. Generative topographic maps (GTM);

4. Time adaptive self-organizing map (TASOM);

5. Potentially other approaches.

Proposal must include information on the application of stochastic methods used within the graph analytics based multi-entity correlation, aggregation, and disambiguation framework(s) on types of logical inference used to build associations among entities.

Information should include application of statistical inference methods such as:

1. Bayesian, frequentist;

2. Likelihood based;

3. Akaike Information Criterion (AIC);

4. Structural

5. Business Rules Management engines (BRMS).

Proposal must include information on complex graph data visualization packages and frameworks for algorithm debugging and implementing Joint director of Laboratories (JDL) Level 5 Fusion using a cognitive engineering and decision making design methodology, such as the applied cognitive systems engineering (ACSE) design process, and other cognitive sciences based design methodologies.

Proposal must include information on existing data throughput and latency evaluations of above referenced frameworks, architectures, and algorithms.

Proposal must include information on the data input and output capabilities and interfaces implemented within the above referenced frameworks.

The entities input to the architecture include:

1. Motion Imagery (MI) data from multiple spectral bands, including radars

2. Wide Area MI (WAMI) data and still Imagery data.

3. Imagery derived from radar data, such as Synthetic Aperture Radar (SAR), Inverse Synthetic

Aperture Radar (ISAR), and High Range Resolution Radar (HRR)

4. Meteorology data.

5. Open source data, such as from social media that contains geo locatable reference information.

6. Overhead Persistent Infrared (OPIR) data.

7. Radio Frequency (RF) data

8. Machine sensor data, such as from magnetometer, pressure, inertial navigation system (INS), inertial measurement unit (IMU), sound, biological detections (e.g., heartbeat, breathing, etc.), rotational speed, velocity, geolocation position, and failure sensors.

9. Point cloud data. Other geo-spatial data such as terrain, maps, etc.

Proposal must include information on documentation, such as:

1. Relevant publications, preferentially with links for downloading.

2. Software Description Document (SDD).

3. Software Architecture Document (SAD).

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 7 30 Days to submit Phase I packages from date of publishing Detect & Exploit WBIEDs Above the Surface

DTRA is seeking proposals for developing and maturing novel and innovative methods of stand-off detection technology that provide the warfighter a means of detecting Water-Borne Improvised Explosive Devices (WBIED) above the water line. DTRA would like to develop, design or modify technology to detect improvised threats at distances extending to the horizon and beyond to give the operators ample time to make decisions on how to avoid or mitigate the threat. The ultimate goal is to protect U.S. assets from WBIEDs while in port or ready to enter the port.

1. The technology shall be able to be deployed from multiple platforms, and not be restricted to shore base only.

2. The technology is not limited from deploying from the surface only.

3. The technology shall be able to identify threats that impose risk on surface platforms above the water line, but are not limited to the surface only.

4. The technology shall have the ability to give an operator the ability to react to the threat in adequate time to disable the threat.

5. The technology shall be able to provide location and speed of the threat, so that the operator can determine the potential time the threat will contact the target.

DTRA is not interested in optical and/or video-only methods of detection; identification of the device/threat needs to be a key facet of the technology or method. Change-detection technologies will only be considered if they offer detection and unambiguous identification innovations appropriate to cluttered and rapidly changing fields of view.

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 8 45 Days to submit Phase I packages from date of publishing Wide Area and Limited Range Monitoring of Contaminated Environments

DTRA/RD-TT seeks proposals for developing technologies and methods capable of providing contamination monitoring over various geographical scales (square meters to large land masses) and under a wide variety of environmental conditions: geographical, geological, meteorological, and atmospheric. The ideal solution would be able to both quantify this contamination, and monitor variations over time. The ability to perform monitoring of both bulk and trace contamination is of interest. While change detection is a consideration, the focus of this solicitation is primarily identifying the contaminant and quantifying its presence over a given geographical area.

Performing detection—and in particular trace detection—in an environment already contaminated with the target or targets of interest remains a challenge. The fundamental issue is discriminating when a detection is of interest or is simply detecting this background contamination. Understanding these contaminated environments would help guide subsequent detection technologies development, and will serve to improve operational tactics, techniques, and procedures when performing detection in the field.

DTRA is interested in both ground and airborne solutions. While DTRA has specific contamination targets of interest, this solicitation seeks to identify approaches to contamination monitoring for a wide variety of contaminants, with the expectation that these approaches can be modified to monitor DTRA contamination targets.

The following factors may lead to a successful white paper:

1. Mature technologies that can be used in a novel manner for contamination monitoring

2. The ability to loiter over a specific geographical area or region

3. The ability to quantify contamination over time

4. Real time monitoring is preferred, but not required

5. Ideal solutions have the ability to monitor a wide variety of contaminants in a variety of states of matter

6. Ideal solutions have the ability to monitor non-exposed contamination (i.e., buried, contained, or otherwise covered)

7. Capability is platform agnostic.

the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 9 30 Days to submit Phase I packages from date of publishing Non-Optical Signal Examination and Exploitation

DTRA is seeking proposals for developing and maturing technology that will provide the warfighter with a fieldable means of non-line-of-sight (NLoS) improvised explosive device (IED) detection and identification. Preference will be given to NLoS solutions that detect and identify homemade explosives (HME) used within IEDs. Methods or technologies that enable the NLoS detection of IED components (e.g. batteries, power sources) will be considered if the method or technology leads to the unambiguous identification of a deployed IED.

There is no single concept of operations. NLoS scenarios include, but are not limited to sensing around corners, buried HME detection/identification, sensing/detecting through barriers and identifying concealed explosives (including HME). This request focuses on supporting individual end users who are usually on foot or within ground vehicles. Remote sensing, while not particularly novel, may be considered if the approach is exceptionally innovative (e.g. new combinations of platforms, sensing modalities and analysis methods). No preference is given regarding active/passive methods of detection; however, near-real time or faster detection methods are preferred.

The following factors may lead to a successful white paper:

1. Novel/innovative approach(es) to detection/identification through obscurants, containers or shielding

2. Clearly stated technical assumptions

3. Demonstrated HME identification

4. Explanation of the underlying detection/identification phenomenology

5. Data or references supporting detection or identification claims

6. Brief bystander and/or user safety analysis (e.g. laser derived eye safety or ionizing radiation hazards)

Stipulations:

Proposal is to conform to the following, as applicable. Deviations are to be noted and discussed in the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and

Topic 10 45 Days to submit Phase I packages from date of publishing Penetrating Analytical Non-neutron Detection Asset

Neutron-based imaging capabilities show promise for imaging within high density materials.

However, the practical utility of this technology is limited by health and safety concerns, signal to noise issues, and challenges associated with fielding such a technology in rugged environments.

DTRA seeks proposals to identify non-neutron based technologies capable of penetrating and image targets of interest encased within high density containment, yet also readily capable of operating in the field. Minimal impacts to operator health and safety are considered a major plus. Emerging, laboratory-based technologies are of interest, but mature technologies are preferred.

the White Paper. Failure to conform does not necessarily remove a White Paper from consideration.

a) Data and final reports are to be FVEY releasable.

b) Payload integration support package will define and document all mechanical, electrical, and software interfaces available for custom third-party payload hardware and custom software automation. The package documentation should include hardware electrical schematics, computer-aided design (CAD) drawings, and software development kit (SDK) documentation for payload data and software produced in support of all other tasks. Documentation of third-party and/or open source software is not required, but the package should list third-party package dependencies, dependency version numbers, and references to publically available documentation when such exists

c) System design package will be a consolidated package including all software, hardware, and mechanical design data & software developed during execution of all tasks.

d) System Design Package, Guides or Tools will be unlimited rights and include (Commercial Off the Shelf software does not fall under this stipulation).

e) As requested, code will be uploaded to the Defense Intelligence Information Enterprise (DI2E) portal.

f) Components conform to DoD Architecture Framework to the maximum extent possible.

g) Cost breakdown in the White Paper to include, at minimum, Labor, Equipment, Travel, and