PdM VPS Sensor CSO Questionnaire-(VendorNameHere).xlsx
XLSX spreadsheet 26 KB Posted
- Attached to
- ACC-DTA Commercial Solutions Opening (CSO)
- Solicitation number
- W912CH-26-S-0001
- Issued by
-
Department of the Army
About this file
This file is a questionnaire template used by the Product Manager for Viper Platform System (PdM VPS) Sensor to collect detailed technical specifications from vendors offering Counter-Unmanned Aircraft System (CUAS) sensor solutions. The questionnaire is structured around five primary categories: General System Info, Spatial Info, Temporal Info, Threat Parameters, and Sensor Algorithms.
Under General System Info, vendors must provide specifications including system name and type (e.g., RADAR, EO/IR), multiband capability, primary waveband, input voltage, operating temperature range, cooling method, dimensions, weight, nominal power consumption, peak transmission power (for active sensors), technology readiness level (TRL L1-L9), DD1494 regulatory documentation availability, and quantity of sensors required for 360-degree hemispherical coverage. Vendors must also describe their current relationship with PdM VPS/DEVCOM regarding Modular APS Framework (MAF) interoperability and provide a Rough Order of Magnitude (ROM) production cost estimate for an integrated sensor system with full coverage and required subsystems. Spatial Info requirements include azimuth and elevation field of view, horizontal and vertical resolution, pixel size, instantaneous field of view, RADAR antenna array dimensions, and beamwidth specifications. Temporal Info specifications cover scene acquisition rate in Hz, track accuracy (angular and range), declaration time, and threat reporting update rate. Threat Parameters section requests range-to-detect capabilities, false threat reporting rates, maximum simultaneous target tracking capability, and minimum angular separation for target classification. The Sensor Algorithms section addresses edge processing capability, threat deconfliction in overlap regions, algorithm maturity level, On-The-Move (OTM) demonstration capability, classification status of algorithms and data logs, day/night lighting performance, and capability to detect missile threats such as RPGs and ATGMs in addition to UAS threats.
View the file
Other files
Show 40 more
Latest 50 of 69 listed here. See the rest on GovTribe.
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
CUAS Questionnaire
| CUAS Sensor - Vendor Questionnaire | ||||
| Category | Sensor Parameters | Units | Vendor Response (provide separate answers for each detector) | Notes |
| General System Info | System Name | - | ||
| System Type | Ex: RADAR, EO/IR | List the sensing modality that the system employs. | ||
| Multiband? | Yes/No | Specify whether or not the sensor has multiband sensing capability. | ||
| Primary (or Ref.) Waveband | Ex: MWIR | Specify the primary operating frequency band for RADAR, IR spectrum for EO/IR, etc. | ||
| Input Voltage | V | Specify the nominal operating voltage and/or the power specification to which the sensor is designed (e.g. MIL-STD-1275) | ||
| Operating Temperature Range | deg C | Specify the temperature range in which the sensor is designed to exhibit full sensing performance. | ||
| Cooling Method | Ex: passive | Specify any specialized cooling needs that the sensor may have. | ||
| Dimensions (L x W x D) | inches | Specify the overall dimensions of each component within the sensor subsystem. | ||
| Device Weight | lbs. | Specify the weight of the device. If an additional processing device is required, specify the weight of that device as well. | ||
| Power Consumption (Nominal) | W | Specify the nominal power consumption. | ||
| Peak Transmission Power (If Applicable) | W | If an active sensor, specify the peak transmission power. | ||
| Estimated Technology Readiness Level | L1-L9 | Follow US DoW definitions for technology readiness level specification. | ||
| DD1494 Documentation Available for active emmitting sensors. | Yes/No | Please reply with availability of regulatory data for active sening solutions. Describe locations where previous range clearance was achieved via 1494 approval. Also, provide information regarding any locations where Special Temporary Authority was achieved. | ||
| # of Sensors Required for 360 full hemispherical coverage. | Integer | |||
| Modular APS Framework (MAF) Readiness? | Description | Describe current relationship with PdM VPS/DEVCOM GVSC/GVSP MAF standard and describe the path to make the proposed technology MAF interoperable. | ||
| Estimated Production Cost (unit cost) | $ | A Rough Order of Magnitude (ROM) estimate of the production cost of an integrated sensor system, to include enough sensor units for 360 degree coverage, and whatever other subsystems are required for signal processing and threat recognition. Include caveats, to include the subsystems included in a system, and the number of systems to be produced for that estimate. |
| Spatial Info | Azimuth Field of View or Search Angle | deg | If multiple windows are available (Wide FoV and Narrow FoV) please list them all in this section. |
| Elevation Field of View or Search Angle | deg | If multiple windows are available (Wide FoV and Narrow FoV) please list them all in this section. | |
| Horizontal Resolution (if applicable) | # pixels | The horizontal resolution of the sensing element. | |
| Vertical Resolution (if applicable) | # pixels | The vertical resolution of the sensing element. | |
| Pixel size (if applicable) | microns | ||
| Instantaneous Field of View (if applicable) | mrad | ||
| RADAR Antenna Array Width (if applicable) | m | ||
| RADAR Antenna Array Height (if applicable) | m | ||
| Horizontal Beamwidth (if applicable) | deg | If adjustable, provide information regarding the total range. | |
| Vertical Beamwidth (if applicable) | deg | If adjustable, provide information regarding the total range. |
Temporal Info Scene acquisition time Hz Provide the number of times per second the full scene is captured by the sensor.
| Track Accuracy | Angular Accuracy | deg | |
| Range Accuracy (if applicable) | m | ||
| Declaration Time | sec | This is the amount of time required to acquire scene information, process targets within the scene, and provide target information via the external communication link. | |
| Threat Reporting Update Rate | Hz | This represents the frequency at which threat parameters are updated via the external interface. |
| Target Parameters | Range to detect a threat of size X x Y x Z | m | Note: If classified, an appropriate means to provide that information to PdM VPS will be supplied. |
| What is your false threat reporting rate? | threats/time | Note: If classified, an appropriate means to provide that information to PdM VPS will be supplied. | |
| Can More than 1 Target Be Simultaneously Tracked? | Yes/No | ||
| Maximum Number of Targets Simultaneously Tracked? | Integer | Note: Only list this information if not classified. | |
| Angular Separation | deg | What is the minimum perceived angular bearing between threats before they are classified as individual objects in the scene? |
| Obscurred Environment | Has Obscurred Environment Performance Been Characterized via Test? If yes, what environments have been characterized? | Yes/No | Obscurred environments include rain, snow, fog, smoke, and dust. |
| Has Obscurred Environment Performance Been Characterized via Simulation? If yes, what environments have been simulated? | Yes/No | Obscurred environments include rain, snow, fog, smoke, and dust. |
| Sensor Algorithms | Can/Are threat processing algorithms hosted at or near the edge (on the sensor head)? | Yes/No | Describe if algorithms are hosted on the sensor endpoints or if additional computing resources are required. |
| Can algorithms deconflict threats in coverage overlap regions? | Yes/No | Describe the system ability to ensure that threats are not over-reported when they exist in overlap regions between sensors. | |
| What is the level of maturity of threat tracking algorithms? | Writeup | Please describe the state of the threat processing algorithms utilized by the proposed technology. Are they proven, developmental/incomplete, lab tested, etc.? | |
| Has threat tracking been demonstrated on a mobile platform in an On The Move (OTM) scenario? If yes, please describe the scenario. | Yes/No | ||
| Are any aspects of the threat processing algorithms classified? | Yes/No | ||
| Are resulting data logs from threat processing algorithm classified? | Yes/No | ||
| Can sensor perform in all (day/night) lighting conditions? | Yes/No | Intent is for the sensor to operate both during the day and at night in all lighting scenarios. Please list any limitations of the proposed sensor with respect to lighting environments. | |
| In addition to UAS threats, can the candidate sensor detect missile threats (RPG, ATGM, etc)? If so, please explain. | Yes/No |
&A UNCLASSIFIED &F
&A UNCLASSIFIED &F
File details come from the government source that posted it. Updated .