DCRA_RFI_15AUG2024_Final.pdf
PDF 252 KB Posted
- Solicitation number
- DCRA_RFI_2024
About this file
This document is a Request for Information (RFI) issued by the Army Contracting Command - Aberdeen Proving Ground (ACC-APG) on behalf of the Program Manager (PM) Intelligence Systems and Analytics (IS&A) Aberdeen Proving Ground (APG). The purpose of the RFI is to conduct market research and identify commercial items that can satisfy the government's requirements for an Automated Data Collection, Reduction, and Analysis (DCRA) Framework software solution.
The RFI outlines the desired capabilities and characteristics of the DCRA Framework, including the ability to integrate with simulation/stimulation drivers, interface with the System Under Test (SUT) data store, and provide analytical outputs to enable performance evaluations. Respondents are requested to provide information on how their software solution would meet the stated requirements, their ability to host the solution in a virtual environment, and any desired government-furnished equipment or information. The RFI also asks respondents to provide a Rough Order of Magnitude cost estimate and draft development schedule. Responses to this RFI are due within 20 days of the RFI release date.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| DCRA_RFI_28AUG2024_Final.pdf |
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
Automated Data Collection, Reduction, and Analysis (DCRA) Framework
Request for Information (RFI)
8/15/2024
1.0 Introduction
This is a Request for Information (RFI), as defined in Federal Acquisition Regulation (FAR) 15.201(e). Army Contracting Command – Aberdeen Proving Ground (ACC-APG) in support of the Program Manager (PM) Intelligence Systems and Analytics (IS&A) Aberdeen Proving Ground (APG), is conducting a round of market research to further identify commercial items to satisfy automated data collection, reduction, and analysis capabilities as defined in section 2 below. The Government invites all business and academic organizations to respond to this RFI notice.
This RFI is issued solely for information and planning purposes. It does not constitute a Request for Proposal (RFP) nor a promise to issue an RFP in the future. The Government may request additional information in the future. Solicitations are not available currently. Request for solicitation will not receive a response. This notice does not constitute a commitment by the United States Government to contract for any supply or service whatsoever. The RFI is not an authorization to begin work, and the Government will not pay any costs that contractors may incur in response to this RFI.
Contractors are not required to respond to this announcement but may do so at their own cost. The United States Government will not pay for information requested nor will it compensate any respondent for any cost incurred in developing information provided to the United States Government.
2.0 Automated Data Collection, Reduction and Analysis (DCRA) Framework Background
In a multi-domain environment, a weapons system, or System Under Test (SUT), utilizes a variety of sensor sources, reconnaissance imagery, and intelligence database information to form accurate and timely targeting recommendations. This is especially so for Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance and Reconnaissance (C5ISR) systems supporting anti-access/area denial (A2AD) weapon systems. Currently there is not a method to provide a realistic multi-domain environment to a SUT to assess its performance in ingesting and processing data, providing target information and recommendations, and incorporating simulated battle data assessment (BDA) feedback into the real-time common intelligence picture. As Army sensor and intel system capabilities grow to accommodate data a higher volume, variety, velocity, and veracity, PEO IEW&S recognizes the need to investigate automated tools to assist the testing process, and specifically Data Collection, Reduction, and Analysis (DCRA) to better derive performance metrics and inform independent evaluations in a timeframe that meets the needs of aggressive program timelines.
3.0 DCRA Framework Desired Capability and Features
PM IS&A is looking for a DCRA tool that meets the Desired Capabilities and Characteristics outlined in Table 1. The first implementation of the automated DCRA tool would be a focused proof of concept for the Tactical Intelligence Targeting Access Node (TITAN) program of record. The tool would therefore need to accommodate TITAN data types and exchanges but have an overall goal and purpose of being a program agnostic tool that could be tailored to future test and evaluations as needed.
Table 1: Desired Capabilities and Characteristics
Desired Capabilities Desired Characteristics DC #1: (System Under Test [SUT] Input Integration Interface) The DCRA Framework will integrate with a simulation/stimulation driver such as the Intelligence and Electronic Warfare Tactical Proficiency Trainer (IEWTPT) that can generate data inputs and emulate a virtual operational environment using repeatable, user-generated scenario(s). The DCRA Framework may utilize the scenario generator, or organic features, to perform orchestrated, event-based release of selected data inputs to the SUT. The DCRA Framework will truth-tag and inject those inputs into the SUT.
1.1 Orchestrate the scripted movement of large data sets, both operational in content and in message size or product size into the SUT.
1.2 Data includes textual structured (e.g., database, XML); semi-structured (e.g., USMTF); sensor inputs (e.g., FMV, SIGINT, GMTI, NITF, SAR).
1.2.1 Data must be automatically, or user-assist, tagged with truth information in order to perform the input-to-output comparison of “truth vs perceived truth”.
1.3 Generated message data must consider “signal-to-noise”
ratio (a volume of “white noise” data interlaced with “targeted” data of interest).
1.3.1 Generated message data must have the ability to contain “bad” or malformed data, and/or duplicate messages.
1.4 Data must be a product of an operationally relevant
scenario.
1.4.1 Objects, entities, and target data must contain a basic set of required metadata.
1.4.2 Message and streaming data must conform to the
standards which they portray.
DC #2: (SUT Interface) DCRA tool will have access to data interfaces from the SUT in order to inject and extract SUT-processed data using common standards.
2.1 Deliver data to the SUT via operationally relevant methods:
2.1.1 Transport, protocol
2.1.2 Schema/format
2.1.3 In scripted sequence and via repeatable means (i.e., by scenario)
2.2 Access data through interfaces provided by the SUT through the Hydra API:
2.2.1 Object data store
2.2.2 Alert notifications
2.2.3 Event logging
2.2.4 Egress messaging – targeting
DC #3: (DCRA Outputs) The DCRA Framework will provide the user with listing and aggregate summaries to enable the user to make analytical comparisons as a product of the generated data versus the SUT’s processed data.
3.1 Provide tabularized outputs of the SUT ingest and
processed data from the scenario generator. SUT processed data that may contain (not an all-inclusive list):
3.1.1 Quantity of delivered messages and objects/entities vs
those messages and objects/entities ingested by the SUT.
3.1.2 Listing of all delivered target “opportunities” from ingest data aligned with corresponding SUT-detected targets (automatically detected or user specified) with descriptive attributes such as (but not limited to):
• Date/time group (DTG) of target inject,
• Generated target inject data source,
• Target identifier (from generated data),
• Target location (from generated data),
• Target data (from generated data)
• SUT target type,
• SUT target activity,
• SUT target location,
• SUT data ingest source,
• SUT target confidence score (from the Automated
Target Recognition Model),
• SUT DTG of target detection,
• SUT DTG of target nomination
3.1.3 Listing of SUT target object history (to include
fusion/correlation) parsed into a CSV, or other spreadsheet compliant format.
3.1.4 Listing, or summary, of “bad” data provided to the SUT
by the DCRA Framework tool.
3.1.5 Listing of SUT-generated alerts with parsed/basic
descriptive attributes exposed by the SUT such as (but not limited to):
• DTG of alert,
• Alert descriptor name,
• Alert criteria,
• Object which triggered the alert,
• Last DTG history record of object which triggered the alert.
3.1.6 Listing of SUT-generated targeting messages
(automatically generated or user-generated) with message fields parsed into a CSV, or other spreadsheet compliant format.
DC #4: (User Configuration) The DCRA Framework will be used and configured by end-users.
4.1 Provide a graphical user interface that will allow end-users to configure and run the built-in features without support from the DCRA Framework developer.
4.2 Provide built-in end-user electronic documentation
DC #5: (DevSecOps/MOSA Compliance) The DCRA Framework will be modular open systems architecture (MOSA) compliant with open standards and be managed through a demonstrated DevSecOps process.
5.1 Provide DCRA Framework software architecture and
software design description listing all contractor-developed, commercial, and Government software.
5.2 Provide a description of the DevSecOps process
DC #6: (Information Assurance/Authorization to Operate) The DCRA Framework will achieve and maintain ATOs.
6.1 The DCRA Framework will not process intelligence data
6.2 The DCRA Framework will be used only on closed networks
6.3 The DCRA Framework will be installed and patched via disk
6.4 The DCRA Framework developer submit proper
documentation to achieve ATOs to interact with data classified at the following levels:
6.1.1 Controlled Unclassified Information (CUI)
6.1.2 Secret//NOFORN (S//NF)
6.1.3 Top Secret/Sensitive Compartmented Information
(TS/SCI)
Table 1: Desired Capabilities and Characteristics
4.0 White Paper Submission
Responses to this RFI are due no later than the date and time indicated in the SAM.gov posting.
Responses shall be in the form of a white paper not to exceed five pages, not including a cover letter, the Rough Order of Magnitude (ROM) estimate, and the schedule. The whitepaper must address the following information requests listed below.
The government is requesting the following information from Industry:
1. Please include the following Company overview information with your response:
a. Company name, DUNS Number, and CAGE code
b. Company size and location
c. Point of contact and email address
2. A narrative that describes how the software solution will
a. Satisfy each item in the desired capabilities and features listed in paragraph 3.0.
b. The ability to host the software solution in a virtual environment, to include a commercial cloud or fixed hardware. Please include CPU, RAM, and storage requirements for the software solution.
c. Interface with the SUT datastore and the method for accessing the data (e.g. use of an
API)
3. A list of desired GFE, GFI items that would benefit a response to a future request for proposal or request for white paper. Example GFE/GFI items could include Application Programming Interface (API) documentation for the Intelligence Electronic Warfare Tactical Proficiency Trainer (IEWTPT) and or the Test Harness data injection tool.
4. Answer yes or no to the following questions:
a. Can the responding organization currently safeguard SECRET information, and does it have at least a Secret Facility Clearance?
b. Has the responding organization successfully implemented the Risk Management
Framework (RMF) Accreditation process for the proposed solution across the SIPR and JWICS networks? If not, has the organization successfully implemented RMF for any system?
c. Has the responding organization previously received an ATO for the proposed solution?
If not, has the organization successfully executed Developmental and or Operational Testing with the United States Government? If yes, please provide one example and a Government POC (name, email address, and phone number) who can verify.
5. Provide a Rough Order of Magnitude (ROM) estimate of applicable costs for the proposed solution. The ROM should include licensing costs and follow-on maintenance/sustainment support (yearly) if applicable.
6. Provide a draft schedule to include development and integration time if applicable.
This notice is part of Government Market Research, a continuous process for obtaining the latest information on the commercial status of the industry. This RFI is for planning purposes, and does not constitute a commitment, implied or otherwise, that a procurement action will follow.
The Government will use the information submitted in response to this notice at its discretion and will not provide comments to any submission; however, the Government reserves the right to contact any respondent to this notice for the sole purpose of enhancing understanding of the notice submission.
Information received will not be considered confidential/proprietary unless marked accordingly.
Company proprietary data will be reviewed by Government employees and authorized representatives only. Responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Responders are solely responsible for all expenses associated with responding to this RFI, including any market research product demonstrations.
Responses to this RFI are to be marked Controlled Unclassified Information (CUI) and received no later than the date and time indicated in the SAM.gov posting. All interested parties shall respond in as clear manner as possible to each of the areas listed above. Information is preferred in soft-copy form in Microsoft Word or PDF. You may forward your responses via email to both bret.a.whitmore.civ@army.mil and jess.t.stock.civ@army.mil with a subject line of “RFI Response: Automated DCRA Framework”. All information must be in writing via email. Telephone requests for additional information will not be honored. Acknowledgement of receipt will be issued. IF you choose to submit proprietary information, please mark it accordingly.
mailto:bret.a.whitmore.civ@army.mil mailto:jess.t.stock.civ@army.mil
File details come from the government source that posted it. Updated .