Attachment_2_-_HAIBP_Self-Assessment_Scorecard.xlsx
XLSX spreadsheet 344 KB Posted
- Attached to
- Helium-3 Alternative Implementation Backpack Program Federal contract opportunity
- Solicitation number
- 70RDND18R00000005
About this file
Attachment 2 - HAIBP Self-Assessment Scorecard
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| HAIBP_-_Instructions_to_Offerors_-_Amd_A00004.pdf | ||
| A00003_-_RFP_70RDND18R00000005_-_HAIBP_-_Instructions_to_Offerors_-_Track_Changes.pdf | ||
| RFP_70RDND18R00000005_-_HAIBP_Offerors_Questions_&_Answers.xlsx | XLSX spreadsheet | |
| A00003_-_RFP_70RDND18R00000005_-_HAIBP_RTM_(2017-11-07)_v1.00.pdf | ||
| A00003_-_RFP_70RDND18R00000005_-_DRAFT_HAIBP_Interface_Control_Document.pdf | ||
| A00001_-_Att1_-_Incoming_Foreign_National_Visitors_Form.docx | DOCX document | |
| RFP_70RDND18R00000005_SF_1449.pdf | ||
| Attachment_1_-_DNDO_Replay_Requirements_Specification_January_2016.pdf | ||
| Attachment_4_-_HAIBP_Past_Performance_Questionnaire.docx | DOCX document | |
| RFP_70RDND18R00000005_-_HAIBP_Instructions_to_Offerors.pdf | ||
| Attachment_3_-_HAIBP_Oral_Presentation_Questions.pdf |
Show all 11
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Scorecard RFP 70RDND18R00000005 Attachment 2 - HAIBP Self-Assessment Scorecard
| Company Name: | ||||||
| System Name, Model, Version No.: | ||||||
| Req # | Requirement | Threshold | Objective | COTS System that forms basis of HAIBP Configuration Meets: | ||
| (T / N) | By End of Prototype Development Phase, Proposed HAIBP System is Expected to Meet: |
(T / N)
| NON-RTM REQUIREMENTS | |||||||
| Non-RTM-01 | The system shall have a Replay Tool. | N | The Replay Tool shall meet the requirements in Appendix B. | N/A | |||
| Non-RTM-02 | The system shall detect neutron radiation sources utilizing technology that is not reliant upon Helium-3. | N | Requirement statement is the threshold value. | N/A | |||
| Non-RTM-03 | The system shall be able to obtain Authority to Operate (ATO) | N | At the end of phase 3 the system shall be verified by TSA to enable ATO. Any issues precluding ATO must be resolved before systems can be fielded. | N/A | |||
| Req # | Innovation Goal | Threshold | Objective | COTS System that forms basis of HAIBP Configuration Meets: | |||
| (T / N) | By End of Prototype Development Phase, Proposed HAIBP System is Expected to Meet: |
(T / N)
| Non-RTM-04 | The system provides data streaming capability. | N | The system shall be capable of automatically reporting system status, health, location and alarm results (for example, energy calibrated gamma ray spectra and neutron counts) at 1Hz. The system’s streaming and wifi/Bluetooth capability can be disabled at user command. Any vendor whose initial article contract includes this goal will be provided with an Interface Control Document. | N/A | |||
| Non-RTM-05 | The system is lightweight. | N | The system weighs less than 17lbs. | N/A | |||
| Non-RTM-06 | The system distributes weight ergonomically (for example, heavier side being closer to the wearer’s back and the weight as even as possible left to right for good balance). | N | The system's weight is distributed evenly for balance | N/A | |||
| Non-RTM-07 | The system minimizes interference with the operator's ease of movement (easy to wear, remove, and have adjustable openings around the arms). | N | The system is adjustable and easy to remove. | N/A | |||
| Non-RTM-08 | The system is inconspicuous as a law enforcement equipment to a casual observer to the maximum extent practical (e.g., providing varying external appearance, including different colors and style of backpack, no visible wires, etc.) (ANSI N42.53-2013: 5.2.1) | N | The system does not have visible wires or sensors that would suggest its detection mission. | N/A | |||
| Non-RTM-09 | The system is re-configurable to other form factors (e.g., portal, choke point, gateway) | N | The system has a modular hardware design which enables detector to be reconfigured to non-wearable configuration. Modules containing firmware or software need to be updateable and/or replaceable. | N/A | |||
| RTM REQUIREMENTS | |||||||
| Req # | RTM Requirement | KPP? | Threshold | Objective | COTS System that forms basis of HAIBP Configuration Meets: | ||
| (T / O / N) | By End of Prototype Development Phase, Proposed HAIBP System is Expected to Meet: |
(T / O / N )
| 4 | HAIBP-01 | ||||
| The instrument shall detect SNM sources in accordance with Backpack TCS Section 6.2. | Y | The instrument shall detect unshielded SNM sources listed in Table 4 while moving at a relative speed of 1.2 m/s when the source-to-detector distance is 2 m. The BRD shall alarm no later than 2 seconds after the source passes through the distance of closest approach. | The instrument shall detect shielded and unshielded SNM sources listed in Table 4 while moving at a relative speed of 1.2 m/s when the source-to-detector distance is 2m. The BRD shall alarm no later than 2 seconds after the source passes through the distance of closest approach. | ||
| 5 | HAIBP-02 | ||||
| The system shall notify the operator of the presence of gamma radiation sources. | N | The instrument shall respond to gamma radiation in accordance with ANSI N42.53 6.3.1. | Same as threshold. | ||
| 6 | HAIBP-03 | The system shall notify the operator of the presence of neutron radiation sources. | N | The instrument shall respond to neutron radiation in accordance with ANSI N42.53 6.4.1. | Same as threshold. |
| 7 | HAIBP-04 | The system shall have a low false alarm rate. |
| Note: This requirement also addresses flow of commerce during mobile operations. | N | The instrument shall respond to false alarms in accordance with ANSI N42.53 6.2.1. | Same as threshold. |
| 9 | HAIBP-06 | The system shall be able to maintain detection sensitivity without additional false alarms when exposed to background radiation changes. |
| Note: As defined in ANSI N42.53 5.1. The system must maintain required sensitivity for detection and false alarm rates despite increasing or decreasing background radiation levels. | N | Maintain detection sensitivity without additional false alarms when background changes by + 2.5 times the starting background (≤25 microroentgen per hour (uR/hr) in < 2 sec (ANSI N42.53: 6.13). | Maintain detection sensitivity without additional false alarms when background changes by + 3 times the starting background (≤25 uR/hr) in < 2 sec . | |||
| 10 | HAIBP-07a | System shall correctly identify present radionuclides that are unshielded with a Probability of Identification (PID) ≥ 80%. | Y | Identify the radionuclides listed in RTM Appendix A, Table 1. | Objective = Threshold | |
| 11 | HAIBP-07b | System shall correctly identify present radionuclides that are unshielded with a Probability of Identification (PID) ≥ 80%. | N | Identify the radionuclides listed as Threshold in RTM Appendix A, Table 2. | Identify the radionuclides listed as Objective in RTM Appendix A, Table 2. | |
| 32 | HAIBP-07c | System shall correctly identify present radionuclides that are shielded with a Probability of Identification (PID) ≥ 80%. | N | Identify radionuclides listed as Threshold in RTM Appendix A, Table 3. | Identify radionuclides listed as Objective in RTM Appendix A, Table 3. | |
| 33 | HAIBP-O8a | System shall comply with specified physical configuration and marking requirements. | N | System meets specified requirements in ANSI N42.53-2013, Sections 5.2 and 5.4. | Same as threshold. | |
| 45 | HAIBP-08a-01 | BRD systems shall weigh less than | ||||
| 10 kg (~22 lb.) including the battery. The manufacturer shall state the weight in the operation manual. | Y | BRD systems weigh less than 10 kg (22 lbs) | Minimize weight while maintaining compliance with KPP requirements HAIBP-01 and HAIBP-07a. | |||
| 51 | HAIBP-08a-02 | Provisions shall be provided to permit testing of visual or audible warning indicators without the use of | ||||
| radiation sources. | N | The requirement statement is the threshold value. | Same as threshold. | |||
| 52 | HAIBP-08a-03 | Internal controls needed for operation shall be identified through markings and identification in technical manuals. | N | Requirement statement is the threshold value. | Same as threshold. | |
| 53 | HAIBP-O8b | System shall comply with data storage and communication interface requirements. | N | System meets requirements specified in ANSI N42.53-2013, Section 5.3, along with any additional derived requirements. | Same as threshold. | |
| 57 | HAIBP-08b-01 | The BRD shall have the ability to store a minimum of at least 8 h of data records. | N | 8 h storage of data records | 12 h storage of data records | |
| 58 | HAIBP-08b-02 | Each record (i.e., data output file), including alarm records, shall contain information specified in the clarification statement. All output data shall be formatted as XML based on the requirements stated in ANSI N42.42. | N | Requirement statement is the threshold value. | Same as threshold. | |
| 83 | HAIBP-08b-03 | Each record produced as a result of an identification shall contain information specified in the clarification statement. | ||||
| Output data shall be formatted as XML based on the requirements stated in ANSI N42.42. | N | Requirement statement is the threshold value. | Same as threshold. | |||
| HAIBP-O8b-04 | When the data storage is full, new measurement event data shall overwrite existing measurement event | |||||
| data. | N | The oldest non-alarming data records shall be overwritten first [first-in, first-out (FIFO)]. | Same as threshold. | |||
| HAIBP-O8b-05 | An indication shall be provided indicating that the data storage is full. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-O8b-06 | The system shall be capable of interfacing with existing DHS and component information systems. | N | System must be able to connect and download stored data wirelessly through Bluetooth or WIFI technology and wired through a USB port. | Same as Threshold | ||
| HAIBP-08b-07 | The system shall have a removable storage device. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-O8c | System shall comply with power supply requirements. | N | System meets specified power supply requirements in ANSI N42.53-2013, Section 5.5. | Same as threshold. | ||
| HAIBP-08c-01 | A BRD shall have the ability to support a continuous operating time of 8 h under standard operating conditions without replacing batteries. | N | 8 h operating time | 12 h operating time |
Note: Hot swapping batteries can be used to achieve the 12 hour operating time.
| HAIBP-08c-02 | The battery compartment shall be accessible without special tools. | N | Requirement statement is the threshold value. | With no tools. | ||
| HAIBP-08c-03 | The low-battery indication shall be no lower than the minimum power required for proper operation. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-08c-04 | Provided battery chargers shall meet US electrical standards and shall be capable of operating from single-phase ac power with voltage between 100 V – 240 V and frequency from 47 Hz – 63 Hz. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-O8d | System shall comply with user interface requirements. | N | System meets user interface requirements in ANSI N42.53-2013, Section 5.8. | Same as threshold. | ||
| HAIBP-08d-01 | The display shall be readable under low light levels (< 150 lux—overcast day or work area) and high light levels (> 10 000 lux—full daylight). | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-08d-02 | The display brightness shall be adjustable. | N | Requirement statement is the threshold value. | Same as threshold | ||
| HAIBP-08d-03 | The detector response (gamma-ray exposure and/or count rate and, when provided, neutron) and battery status shall be provided at the user interface and updated at a minimum rate of once per second. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-08d-04 | The identification results, confidence indicator, and ability to access spectra shall be provided at the user interface when identification capabilities are available. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-08d-05 | The information, provided in the Clarification statement, shall be automatically displayed at the User Interface. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-O8e | System shall comply with the specified energy and response range, operating parameters, and diagnostic requirements. | N | System meets specified requirements in ANSI N42.53-2013, Section 5.7 (energy and response), Section 5.9 (operating parameters) and Section 5.11 (Diagnostics). | Same as threshold. | ||
| HAIBP-08e-01 | The manufacturer shall document the energy and response range information, as defined in the Clarification statement. | N | Requirement statement is the threshold value. | Same as threshold. | ||
| HAIBP-08e-02 | The manufacturer shall provide the list of all user-adjustable parameters (e.g., default alarm thresholds and | |||||
| background update mode) with a description of their function and recommended values or settings. | N | Requirement statement is the threshold value. | Same as threshold. | |||
| HAIBP-08e-03 | A BRD shall have the ability to self-stabilize (e.g., stabilize detector gain based on temperature), monitor | |||||
| functionality, and diagnose malfunctions without user interaction. | N | Requirement statement is the threshold value. | Same as threshold. | |||
| HAIBP-09 | The system shall operate without scheduled maintenance. | N | One depot-level maintenance per year. |
No maintenance exceeding charging and changing of batteries, non-invasive cleaning, and system operational checks that require no special training or tools.
HAIBP-10 The system shall minimize the impact to the operator’s non-Rad/Nuc mission.
Note: The intent is to not detract from operator's situational awareness or restrict their movement and use of their hands. N User is able to complete all mission-essential operations while using standard equipment.
Standard equipment:
Ballistic vest with carrier(worn with carrier or under polo shirt) Duty belt:
holster duty weapon baton with baton holder handcuffs and cuff case radio with radio carrier ammunition magazines with carrier RDE(pager or SPRD) Belt badge Same as Threshold
| HAIBP-11 | The system shall perform reliably. | N | Mean time between failures (MTBF) of at least 17,520 hours. | 35,040 objective hours between failure for the fleet. |
| HAIBP-11-01 | The system shall record cumulative system operating hours. | N | Requirement statement is the threshold value. | Same as threshold. |
| HAIBP-12 | The system shall be safe to operate. | N | Pass UL-61010-1 V3 (Reference 16) certification or equivalent. | Same as threshold. |
| HAIBP-13 | System shall comply with the ANSI N42.53-2013 Environmental performance requirements | N | System meets ANSI N42.53 2013, Sections 7.1 - 7.5. | Same as threshold. |
| HAIBP-13-01 | System shall meet the ambient temperature requirement in ANSI N42.53-2013. | N | The instrument shall respond to ambient temperature in accordance with ANSI N42.53-2013, Section 7.1. | Same as threshold. |
| HAIBP-13-02 | System shall meet the relative humidity requirement in ANSI N42.53-2013. | N | The instrument shall respond to relative humidity in accordance with ANSI N42.53-2013, Section 7.2. | Same as threshold. |
| HAIBP-13-03 | System shall meet the extreme temperature startup requirement in ANSI N42.53-2013. | N | The instrument shall respond to extreme temperatures in accordance with ANSI N42.53-2013, Section 7.5. | Same as threshold. |
| HAIBP-14 | System shall comply with the ANSI N42.53-2013 Electrical and electromagnetic performance requirements. | N | System meets ANSI N42.53 2013, Sections 8.1 - 8.4. | Same as threshold. |
| HAIBP-14-01 | System shall meet the radio frequency requirement in ANSI N42.53-2013. | N | The instrument shall respond to radio frequency in accordance with ANSI N42.53-2013, Section 8.1. | Same as threshold. |
| HAIBP-14-02 | System shall meet the radiated emissions requirement in ANSI N42.53-2013. | N | The instrument shall respond to radiated emissions in accordance with ANSI N42.53-2013, Section 8.2. | Same as threshold. |
| HAIBP-14-03 | System shall meet the magnetic field requirement in ANSI N42.53-2013. | N | The instrument shall respond to magnetic field exposure in accordance with ANSI N42.53-2013, Section 8.3. | Same as threshold. |
| HAIBP-14-04 | System shall meet the electrostatic discharge requirement in ANSI N42.53-2013. | N | The instrument shall respond to electrostatic discharge exposure in accordance with ANSI N42.53-2013, Section 8.4. | Same as threshold. |
| HAIBP-15 | System shall comply with the ANSI N42.53-2013 Mechanical performance requirements | N | System meets ANSI N42.53, 2013 Sections 9.1 - 9.3. | Same as threshold. |
| HAIBP-15-01 | System shall meet the vibration requirement in ANSI N42.53-2013. | N | The instrument shall respond to vibration exposure in accordance with ANSI N42.53-2013, Section 9.1. | Same as threshold. |
| HAIBP-15-02 | System shall meet the mechanical shock requirement in ANSI N42.53-2013. | N | The instrument shall respond to mechanical shock exposure in accordance with ANSI N42.53-2013, Section 9.2. | Same as threshold. |
| HAIBP-15-03 | System shall meet the mechanical drop test requirement in ANSI N42.53-2013. | N | The instrument shall respond to the exposure of being dropped in accordance with ANSI N42.53-2013, Section 9.2. | Same as threshold. |
| HAIBP-15-04 | System shall meet the impact (microphonics) exposure requirement in ANSI N42.53-2013. | N | The instrument shall respond to the impact (microphonics) exposure in accordance with ANSI N42.53-2013, Section 9.3. | Same as threshold. |
| LEGEND | |
| Items shaded in light blue indicate Innovation Goals | |
| Items shaded in orange indicate Go/No Go requirements. Failure to meet Threshold results in a No Go decision. | |
| Performance Rating | |
| T | Threshold |
| O | Objective |
| N | None |
Ordinal Req_Num Rqmt_Requirement Item3_PT
| Ordinal |
| Req_Num |
| Rqmt_Abbr |
| Rqmt_T_O |
| Rqmt_Variant |
| Rqmt_Requirement |
| Rqmt_Baseline |
| Rqmt_Maritime |
| Refs_PT_v2_1_pptx |
| Refs_OT_v2_1_pptx |
| Item1_Claim |
| Item1_Step2_Results |
| Item1_Step2_Refs |
| Item1_Step2_Net |
| Item1_PT |
| Item_1_PT_Refs |
| Item1_OT |
| Item1_OT_Refs |
| Item1_SW |
| Item1_SW_Narrative |
| Item1_Risk |
| Item1_Risk_Narrative |
&F &"-,Bold"&KFF0000SOURCE SELECTION SENSITIVE Page &P
Appendix A OR-7a-c Tables
| TABLE 1 (Source: BHH ORD) | |
| Radionuclide | Threshold (T) or Objective (O) for Unshielded Sources |
| Americium-241 [Am-241] | T |
| Cesium-137 [Cs-137] | T |
| Cobalt-60 [Co-60] | T |
| Iridium-192 [Ir-192] | T |
| Neptunium-237 [Np-237] | T |
| Plutonium - 239 [Pu-239] | T |
| Uranium-235 [U-235] | T |
| Uranium-238 [U-238] | T |
| TABLE 2 (Source: BHH ORD) | |
| Radionuclide | Threshold (T) or Objective (O) for Unshielded Sources |
| Barium-133 [Ba-133] | T |
| Cesium-131 [Cs-131] | T |
| Cobalt-57 [Co-57] | T |
| Fluorine-18 [F-18] | T |
| Gallium-67 [Ga-67] | T |
| Iodine-123 [I-123] | T |
| Iodine-125 [I-125] | T |
| Iodine-131 [I-131] | T |
| Lathanum-138 [La-138] | T |
| Palladium-103 [Pd-103] | T |
| Plutonium-238 [Pu-238] | T |
| Potassium-40 [K-40] (a) | T |
| Radium-226 [Ra-226 + Daughters(a)] | T |
| Strontium-90/Yittrium-90 [Sr-90/Y-90] (b, c) | T |
| Technetium-99m [Tc-99m] | T |
| Thallium-201 [Tl-201] | T |
| Thorium-232 [Th-232 + Daughters (a)] | T |
| Uranium-232/Uranium-233 [U-232/U-233] (b) | T |
| Scandium-46 [Sc-46] | O |
| Tungsten-187 [W-187] | O |
| Antimony-124 [Sb-124] | O |
| Cromium-51 [Cr-51] | O |
| Europium-152 [Eu-152] | O |
| Hydrogen Neutron Capture | O |
| Indium-111 [In-111] | O |
| Lutetium-176 [Lu-176] | O |
| Lutetium-177 [Lu-177] | O |
| Manganese-54 [Mn-54] | O |
| Manganese-56 [Mn-56] | O |
| Molybdenum-99 [Mo-99] | O |
| Niobium-95 [Nb-95] | O |
| Radium-223 [Ra-223] | O |
| Samarium-153 [Sm-153] | O |
| Selenium-75 [Se-75] | O |
| Strontium-89 [Sr-89] (c) | O |
| Thallium-202 [Tl-202] | O |
| Thallium-204 [Tl-204] | O |
| Yittrium-88 [Y-88] | O |
| Table 2 Notes: | |
| When found at background levels, these radionuclides should be saved in background spectral files but do not need to be identified on the screen or separately identified in radioisotope ID spectral files. | |
| Any of the Identification Names listed are acceptable for screen display. | |
| “Beta Emitter” may be displayed in lieu of the name of the radionuclide. |
| Table 3 (Source: BHH ORD) | |
| Radionuclide | Threshold (T) or Objective (O) for Shielded Sources |
| Americium-241 [Am-241] | T |
| Barium-133 [Ba-133] | T |
| Cesium-137 [Cs-137] | T |
| Cobalt-57 [Co-57] | T |
| Cobalt-60 [Co-60] | T |
| Iridium-192 [Ir-192] | T |
| Neptunium-237 [Np-237] | T |
| Plutonium - 239 [Pu-239] | T |
| Plutonium-238 [Pu-238] | T |
| Potassium-40 [K-40] (a) | T |
| Radium-226 [Ra-226 + Daughters(a)] | T |
| Thorium-232 [Th-232 + Daughters (a)] | T |
| Uranium-232/Uranium-233 [U-232/U-233] (b) | T |
| Uranium-235 [U-235] | T |
| Uranium-238 [U-238] | T |
| Scandium-46 [Sc-46] | O |
| Tungsten-187 [W-187] | O |
| Antimony-124 [Sb-124] | O |
| Cesium-131 [Cs-131] | O |
| Cromium-51 [Cr-51] | O |
| Europium-152 [Eu-152] | O |
| Fluorine-18 [F-18] | O |
| Gallium-67 [Ga-67] | O |
| Hydrogen Neutron Capture | O |
| Indium-111 [In-111] | O |
| Iodine-123 [I-123] | O |
| Iodine-125 [I-125] | O |
| Iodine-131 [I-131] | O |
| Lathanum-138 [La-138] | O |
| Lutetium-176 [Lu-176] | O |
| Lutetium-177 [Lu-177] | O |
| Manganese-54 [Mn-54] | O |
| Manganese-56 [Mn-56] | O |
| Molybdenum-99 [Mo-99] | O |
| Niobium-95 [Nb-95] | O |
| Palladium-103 [Pd-103] | O |
| Radium-223 [Ra-223] | O |
| Samarium-153 [Sm-153] | O |
| Selenium-75 [Se-75] | O |
| Strontium-89 [Sr-89] (c) | O |
| Strontium-90/Yittrium-90 [Sr-90/Y-90] (b, c) | O |
| Technetium-99m [Tc-99m] | O |
| Thallium-201 [Tl-201] | O |
| Thallium-202 [Tl-202] | O |
| Thallium-204 [Tl-204] | O |
| Yittrium-88 [Y-88] | O |
| Table 3 Notes: | |
| (a) When found at background levels, these radionuclides should be saved in background spectral files but do not need to be identified on the screen or separately identified in radioisotope ID spectral files. | |
| (b) Any of the Identification Names listed are acceptable for screen display. | |
| (c) “Beta Emitter” may be displayed in lieu of the name of the radionuclide. |
Appendix B Replay Tool Reqmts
| Requirement Description: | Requirement: | Proposed Tests: |
| General Requirements: | ||
| Reproducibility | The replay tool exactly reproduces the device algorithm output when given identical input. | |
| GR-1-REP | The replay tool shall exactly reproduce the live results of the radiation detection system under test when provided the identical input data |
The meaning of “exactly reproduce” is device-type dependent as specified in Table 3 under “verification criteria.”
Compare the set of verification live output files to those output files obtained by replaying the verification input files.
A procedure, as indicated in Table 2, shall be documented to test this requirement for radiation detection systems that are not required by the ANSI standard to produce input data files.
Allowed differences are listed in Table 3.
Verify the replay tool by comparing results files from the live system and the replay tool:
• Alarms and identified isotope alarms, when applicable, shall be identical.
• Alarm and identification confidence, when applicable, shall be identical to the number of reported decimal places (dependent on device type).
• Identification results in output files (when applicable to device type) shall include identical sets of isotopes, even when the confidence of such isotopes does not merit an alarm.
• When applicable for device type, categorization (e.g. industrial, medical, SNM) results shall be identical for identified isotopes and alarms.
• Measured data written in the output files, when applicable for device type, shall be identical.
• Pre-processed data written in the output files, when applicable for device type, shall be identical.
GR-2-REP The replay tool shall accept as its only required inputs the input data provided by the radiation detection system along with any analysis parameters used by the detection system.
Differences in the implementation of this requirement for radiation detection systems that do not record input data files are specified in Table 2. In the event that input data must be pre-processed before analysis by the recognition algorithm, the replay tool shall perform the pre-processing. This is in particular to enable the processing of synthetic data by the replay tool.
Note: The internal structure of the replay tool (i.e. the number of components) is not prescribed. For radiation detection systems that produce input files, test that the replay tool will run and produce output files from the specified input data.
For radiation detection systems that do not produce files that can be input, verify that the properly formatted captured or simulated data can be replayed and produces the same alarm status as the live system under similar conditions as described in Table 3.
Test that the results from the replay tool match the results from the in-situ algorithm for all verification files, as for GR-1-REP.
GR-3-REP The replay tool shall have a user-accessible facility for adjustment of algorithm parameters.
| User-adjustable parameters in the replay tool shall be set via parameter input files, and optionally a user-interface facility in the replay tool. | Test that parameters can be adjusted as documented. | |
| GR-4-REP | The replay tool shall include the same range and functionality for adjusting algorithm parameters as the in-situ algorithm on the radiation detection system. |
Any parameters or parameter ranges in the replay tool not accessible to the operator on the radiation detection system shall be clearly indicated to the user as such before the replay is initiated. Check that parameters that can be adjusted via settings on the radiation detection system can be set in the replay tool.
Check that setting any parameters that fall outside the parameter range accessible on the detection system causes a message, alarm, or other clearly identifiable notification before the replay of the file or files is initiated.
| GR-5-REP | Reproducibility of results shall be achievable as in GR-1-REP independent of the order of processing. | Verify that the output (results) files are identical to the output validation files provided in the validation package when the input validation files are replayed in any order. |
| Autonomy | The stand-alone tool has no additional software or run requirements. | |
| GR-6-AUT | The replay tool shall be a stand-alone software tool that can be installed and operated autonomously. |
| Autonomous operation in this context means without use of web services, an internet connection, or other devices. | Install the replay tool on each standalone (internet-disconnected) supported platform and check that the replay tool can replay all input validation files. | ||
| GR-7-AUT | The replay tool shall process each input file separately. | Same test as GR-5-REP. | |
| Injection | Injection and synthetic input file generation capability exists. | ||
| GR-8-INJ | The replay tool package shall include a translator facility to generate N42.42 files from vendor format raw data files, and translate the N42.42 files back into the raw data files suitable for use with the replay tool. The gamma-ray spectral data, neutron count data, and energy calibration data shall be stored in standard N42.42 data elements; vendor-specific auxiliary data may be in permitted extensions to N42.42. |
See Appendix A for an example of N42.42 spectral data elements.
The translator facility shall be subject to the same requirements as the replay tool regarding autonomy, batch processing, and documentation as the replay tool itself. Check that the translator can produce readable N42.42 files from an original raw input data file.
Check that the translator can produce a raw input data file from the N42.42 file, referred to as the translated raw input data file.
Test that the replay outputs of the original raw input file and the translated raw input data file are identical.
| GR-9-INJ | The replay tool shall be capable of processing synthetic input data for injection studies in the same manner as measured input data. | Test that reply of synthetic input data can be executed and will produce an output file consistent with the measured object data for the same source. |
| Output | Reply results facilitate consistent evaluation of results across devices. | |
| GR-10-OUT | The replay tool shall provide output (results) in N42.42 -2012 format with device-type appropriate detail. |
| Device-appropriate detail shall be as prescribed in Table 2. | Test that all output files produced by replaying the set of validation input files are valid N42.42 files with detail as required in the detailed level requirements for the device type. | ||
| GR-11-OUT | The replay tool shall provide, when device-type-appropriate as prescribed in Table 2, traceability (achieved either by inclusion or by cross-reference or pointer) to raw data, ancillary data and analysis parameters in the output (results) file. | Verify that all output files produced by replaying the set of verification input files include (when required) raw data, ancillary data, and analysis parameters via cross-reference or inclusion. | |
| GR-12-OUT | The replay tool shall provide, when device-type appropriate as prescribed in Table 2, version information for the firmware in the output file. | Verify that all output files produced by replaying the set of verification input files include (when required) the appropriately tagged version information for the firmware. | |
| GR-13-OUT | The replay tool shall provide, when device-type appropriate as prescribed in Table 2, hardware identification in the output (results) file. Hardware identification shall be via the appropriate XML tag from the N42.42 (2012) standard [1]. | Check that all output files produced by replaying the set of verification input files include (when required) the appropriately tagged hardware identification. | |
| GR-14-OUT | Software version for the recognition algorithm used in the replay tool shall appear in the output (results) file for all input files processed by the replay tool. | Check that the software version for the replay tool’s detection algorithm is appropriately tagged and listed in all output files produced by replaying the input validation files. | |
| GR-15-OUT | Software version for the recognition algorithm used in the detection system shall appear in the output (results) file for all output files produced by the in-situ recognition algorithm. | Check that the software version for the (in-situ) recognition algorithm is appropriately tagged and listed in all output files produced by the in-situ recognition algorithm. | |
| Inputs | Traceability of analysis parameters and input data from input to output. | ||
| GR-16-INP | Device-type appropriate input data as defined in Table 2 shall appear in the input file. | Check that the files produced by the detection system and used as input to the replay tool include (when required) the appropriately tagged data. | |
| GR-17-INP | Model name and serial number for the radiation detection system shall appear in the input file, regardless of the format (native or ANSI N42.42-2012) used. | Check that the files produced by the device and used as input to the replay tool include the appropriately tagged model name and serial number for the detection device. Native format files may be checked by verifying the model name and serial number is present in the translated data files. | |
| GR-18-INP | Hardware identifier and firmware (when applicable) version(s) for the detection system as specified by the device-type requirements in Table 2, should appear in the input file when possible. |
Firmware includes any firmware used in the detection system to produce the input file. Check that the files produced by the device and used as input to the replay tool include the appropriately tagged hardware identifiers and firmware version(s) for the detection system.
Check that these data are present in native format files after translation.
| GR-19-INP | Background and foreground data shall appear in the input file from the detection system according to the requirements listed in Table 2. | Check that the input files produced by the detection system and used as input to the replay tool include (when required) the appropriately tagged background and foreground data. |
| Batch Mode /Command Line | Efficient replay of large numbers of files. | |
| GR-20-BAT | The replay tool shall provide a facility for batch processing of a minimum of 5,000 input files without further human intervention. The batch facility should be callable from a command-line interface. |
The batch facility may be a wrapper around a replay tool program that processes a single file, or the primary replay tool facility may have this capability. Check that a batch processing capability exists.
Check that at least 5,000 files can be processed without further human interaction after launch of the replay tool batch facility.
Check that parameters as designated in the tuning of the replay tool are listed in the output files when the files are processed via batch processing.
| GR-21-BAT | During batch processing, processing of valid input files shall continue without interruption regardless of the presence of any errant, invalid, incomplete, rejected, or otherwise non-replayable input files. Non-replayable input files shall be skipped by the replay tool and processing of valid input files continue. | Verify that errant, valid, incomplete, or otherwise rejected files are skipped by the replay tool and processing of valid input files continues when the errant files are inserted in the beginning, the middle, and the end of the batch of files. |
| GR-22-BAT | Batch processing in the replay tool shall be subject to all requirements regarding singly-replayed files. | Check that each file processed via batch mode corresponds to a uniquely labelled output file. |
Verify that batch processing of input files produces identical output, with the exception of time stamp, regardless of the order in which the files are processed.
GR-23-BAT Designation of the input files for batch processing shall be either via a replay input directory under which all files will be processed, or via a file of input file names and path specifications to allow processing of files in a path other than that of the replay tool. One or both methods may be implemented to satisfy this requirement.
A virtual-appliance-based replay tool should use an input-directory based approach.
| If used, the file of filenames will be formatted as one path and filename per line. | Check that file names can be input to the command-line processing facility via a file of file names, including path, or by dropping the files into the input directory. | ||
| GR-24-BAT | Designation of analysis parameters for batch processing shall be via a file of parameters (see GR-3-REP) either specified at the start of the batch process, or introduced into the replay input directory. | Check that analysis parameters can be set by designating the path and filename of a parameter file, or by copying the parameter file into the replay input directory. | |
| GR-25-BAT | The batch processing facility shall provide a human-readable tabulated summary file from batch processing of files. | Check that the batch facility produces a file of tabulated data indicating correctly the number of files from a batch that are processed, skipped, rejected or otherwise not processed, files with errors that are nonetheless processed, and the files that are alarming. |
Check that the file of batch output is human-readable and independent of the order in which the files are processed.
| GR-26-BAT | The batch facility shall flag the output of any errant file that can be processed by a unique identifier. |
| GR-27-BAT | The batch facility shall provide tabulated data from batch that indicates, for each batch, the number of files from the batch that are processed. |
| GR-28-BAT | The batch facility shall provide tabulated data from batch that indicates, for each batch, the number of files from the batch that cannot be processed. |
| GR-29-BAT | The batch facility shall provide tabulated data from batch that indicates, for each batch, the number of files that are errant but can be processed. |
| GR-30-BAT | The batch facility shall provide tabulated data from batch that indicates, for each batch, the number of alarming and non-alarming files. |
| GR-31-BAT | The batch facility shall generate a separate file of the names of non-replayable files from each batch formatted as one filename per line. |
If the replay tool generates a reason or justification for the rejection of processing (e.g. “file truncated,” “incomplete occupancy,” “unknown XML tag”), the batch facility should record that reason in the list of non-replayable files. Reasons or justifications may be inclusions or cross-references. Insert non-replayable files into a batch processing list in the beginning, middle, and end of the list. Ensure in each instance that all non replayable file names appear in the separate output file’s list of non-replayable files and names of replayed files do not appear in this separate output file’s list.
If a cross-reference code for the rejection reason is recorded, check that a cross-reference is listed in the documentation for the replay tool.
| Compatibility and Portability | Backward data-handling compatibility; ability to run on standard computer platforms. |
| GR-32-COP | The replay tool shall be compatible with and provide installation mechanisms for standard-issue x86-based commercial computers running generally available standard-issue operating systems. |
| Such computers may be expected to run a supported version of Microsoft Windows or Linux at the time of the release. | Check that the replay tool can be installed and run on the designated platforms, and that results from each run of the validation files are identical to the extent required in Table 3. | |
| GR-33-COP | The replay installation package shall be complete, including all packages, libraries, third-party software, and licensing required to install and run the platform specific version of the replay tool. |
| If the replay tool requires the use of virtual machine or virtual appliance software, the software shall be included in the installation package and no additional licensing shall be required to run the replay tool. | Ensure that the installation package includes all required software for correct installation of the replay tool according to installation instructions. | |
| GR-34-COP | Updated versions of the replay tool shall be backward compatible with input files generated by earlier versions of the radiation detection system and processed by earlier versions of the replay tool. |
Updated versions of the replay tool should be delivered, along with appropriate validation and verification data sets, whenever substantive changes are made to the radiation detection system’s algorithm. Verify that the updated replay tool includes a change in the version number as written to the output file.
Test that subsequent versions of the replay tool are able to replay all files from the validation and verification data sets from previous versions.
Test that subsequent versions of the replay tool indicate the hardware and firmware version, with appropriate tag.
Test that any delivered version of the replay tool includes separate verification and validation packages of input and output files.
| Validation and Verification | Method and files to validate installation and verify reproducibility. | |
| GR-35-VAV | The replay tool shall provide validation files to ensure that the tool’s performance as described by the vendor is reproduced with each installation. The number of required installation validation files is listed in Table 3. Validation files include both the unanalyzed measurement input files and the vendor-produced replay output results files from processing the input files. | Check that the validation files are delivered with the replay tool. Verify that all validation input files can be run by the replay tool. Validate the installation and compare the results of the replay tool against the replays run by the vendor; differences allowed in replay results shall be limited to those listed in Table 3. |
| GR-36-VAV | The vendor shall provide a minimum number of replay verification input files (unanalyzed input data files) and the corresponding verification output files generated by the detection system (“live”), with the number dependent on device type, appearing in Table 3. |
| These input files and others will be replayed to test GR-1-REP. | Check that the correct number of verification input and output files are delivered with the replay tool. Verify that all verification input files can be processed by the replay tool. | |
| Documentation | Complete manual, file architecture, version documentation. | |
| GR-37-DOC | The replay tool shall include a complete manual for installation, operation and troubleshooting. |
• The replay tool shall include documentation for each parameter setting.
o Each parameter shall be identified and its effect on the recognition algorithm shall be indicated o Default parameter settings shall be identified in the documentation o If the label of a parameter in the in-situ algorithm in the device differs from the label of a parameter in the replay tool, this discrepancy shall be explicitly noted o The vendor need not reveal proprietary information
• The replay tool shall include definitions of statistical measures used in batch processing report. Check that the manual is complete and comprehensive Check that the required parameter documentation exists.
Check that definitions of the particular statistical measures used in batch or aggregate statistics exist and are among the standard definitions.
| GR-38-DOC | The replay tool documentation shall include the file input and output architecture description. This includes complete description of the data file formats and content. | Check that the documentation is delivered, complete, and matches collected data. |
| Backpack Devices: | Backpack radiation detection systems detect gamma radiation and may include neutron detection. They may identify gamma emitting radionuclides. The ANSI standard N42.53-2013 requires that the devices are able to store up to 8 hours of data records internally. Recorded information includes date, time and time zone, manufacturer, model, version and serial number for the device, GPS location, background gamma count, background neutron count if equipped with neutron detector, measured gamma and neutron count rates, and operational status [6]. Each recorded spectrum shall have a time stamp, real time, live time, and calibration coefficients. As stated in requirement GR-11-OUT, the replay tool output file shall include this raw measurement data. | |
| DLR-BP-1-TRA | Backpack replay tool input files shall include the following fields, either in native file format or in compliant ANSI n42.42-2012 format. |
• Instrument identification
• Time, Date
• Detector Information (e.g. NaI, He-3)
• Energy Calibration
• Foreground spectrum for each detector
• Background spectrum for each detector
• Live time for each spectrum measurement
• FWHM Calibration, if available
• Dose Rate (if applicable)
• Definition of a measurement group that links background and foreground measurements
• Any Pre-processed data as it would be delivered to the in-situ algorithm
DLR-BP-2-OUT Backpack replay tool output (results) files shall include the following fields in compliant ANSI N42.42-2012 format.
• All Input data above in DLR-BP-1-INP
• Algorithm Version and Release Date
• Algorithm Configuration
• Alarm Data (Color, description)
• Analysis start time and end time
• Background Spectrum
• Nuclide information – name, confidence value, description/category( e.g. NORM) if applicable
• Spectrum peak analysis results – peak energy value, peak net area value, peak net area uncertainty value (if available).
| Proprietary Safeguards | |
| PRO | General comments pertaining to Proprietary Safeguards |
| PRO-1 | The source code will not be required for installation, running, or parameter adjustment of the replay tool. |
| PRO-2 | DNDO will request the vendor to make modifications to the replay tool’s code if adjustments are required or desired by DNDO. |
| PRO-3 | Adjustments to the replay tool by the vendor will be necessary if the following objective criteria are encountered: |
• Disagreement of in-situ (“ live”) and replay results beyond what is listed in the verification requirements
• Disagreement of vendor-replayed and local installation-replayed files beyond what is listed in the validation requirements.
• Update of in-situ device algorithm according to the criteria listed under Compatibility and Portability
• Vendor-requested modifications to the algorithm
• Non-compliance with N42.42 (2102) standards for the device-type
• Disagreement in results of the replay algorithm between platforms
• Disagreement in results of the replay algorithm dependent on order of replays
• Inability of the replay algorithm to replay valid files, regardless of their origin (native , injected or synthetic)
• Inability of the batch or command-line mode to replay files as required
• Disagreement between results obtained via batch or command line mode and single-replay mode
• Failure of the replay tool to reproduce the tuning (setting of user-accessible parameters) ability in the in-situ (“ live”) detection device algorithm
• Non-standard versions of statistical algorithms used to produce batch or aggregate statistics are used
• Disagreement between replays of a single file other than in processing date/time stamp
• Robustness failure in batch mode/command line processing in the replay tool (e.g. memory leak)
• Other failure of any of the requirements.
| PRO-4 | Details of the recognition algorithm(s) are not required for the replay tool to run, beyond the documentation of parameters necessary to adjust the performance of the detection system (e.g. for specific deployment locations or to lessen occurrence of nuisance alarms). |
| PRO-5 | An independent verification by DNDO-directed scientists or engineers that the replay tool exactly reproduces the live recognition algorithm results, consistent with guidelines in Table 3, will be undertaken with collected field data and DNDO-prescribed test data in addition to the vendor-supplied verification files. |
| PRO-6 | The translator facility to convert between the vendor-specific data input file format and the N42.42 file format is not expected to contain vendor IP. As such, it is recommended that the source code for the translator be available to the government. |
| PRO-7 | The wrapper software used to manage the processing of input data files by the recognition algorithm(s) is not expected to contain vendor IP. As such, it is recommended that the source code for the wrapper software be available to the government. |
| Table 3 Validation and Verification Criteria | ||||
| Detection System Type | Minimum number of replay installation validation input and output files* | Minimum number of replay verification input and output files** | Installation Validation Criteria | Verification Criteria |
| Backpack Device | 60 | 10 hours of data | Identical output, with the exception of time stamp and replay device operating system information; identification confidence within precision given in the live output file. | Identical input, <Nuclide>, <SpectrumPeak> (if applicable) confidence within precision given in the live output file. |
Appendix C TSA Inf. Assurance
| Information Assurance Requirements for TSA Government Acquisitions (April 2016) | |
| Requirement Description | Requirement (Threshold and Objective) |
| A. General Security Requirements | A.1 - The Contractor shall comply with all Federal, Department of Homeland Security (DHS) and Transportation Security Administration (TSA) security and privacy guidelines in effect at the time of the award of the contract, As well as those requirements that may be discretely added during the contract. |
| A.2 - The Contractor shall perform periodic reviews to ensure compliance with all information security and privacy requirements. | |
| A.3 - The Contractor shall comply with all DHS and TSA security controls to ensure that the Government's security requirements are met. These controls are described in DHS PD 4300A and TSA MD 1400 series security policy documents and are based on the current National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 standards. | |
| A.4 - The Contractor shall include this guidance in all subcontracts at any tier where the subcontractor is performing the work defined in this statement of work (SOW). | |
| A.5 - The Contractor shall ensure all staff have the required level of security clearance commensurate with the sensitivity of the information being accessed, stored, processed, transmitted or otherwise handled by the System or required to perform the work stipulated by the contract. At a minimum, all Contractor staff shall be subjected to a Public Trust background check and be granted a Public Trust clearance before access to the System or other TSA resources is granted. | |
| A.6 - The Contractor shall sign a DHS Non-Disclosure Agreement (NDA) within (30) calendar days of the contract start date. | |
| A.7 - The Contractor shall not release, publish, or disclose agency information to unauthorized personnel, and shall protect such information in accordance with the provisions of the pertinent laws and regulations governing the confidentiality of sensitive information. | |
| A.8 - The Contractor shall ensure that its staff follow all policies and procedures governing physical, environmental, and information security described in the various TSA regulations pertaining thereto, and the specifications, directives, and manuals for conducting work to generate the products as required by this contract. Personnel shall be responsible for the physical security of their area and government furnished equipment (GFE) issued to the contractor under the terms of the contract. | |
| A.9 - The Contractor shall make all system information and documentation produced in support of the contract available to TSA upon request. |
| B. Training Requirements | B.1 - All Contractor employees, requiring system access, shall receive initial Organizational Security Fundamentals Training within 60 days of assignment to the contract via the Online Learning Center (OLC). Refresher training shall be completed annually thereafter. |
| B.2 - The Contractor shall complete annual online training for Organizational Security Fundamentals and TSA Privacy training. | |
| B.3 - Role Based training is required for contract employees with Significant Security Responsibility (SSR), whose job proficiency is required for overall network security within TSA, and shall be in accordance with DHS and TSA policy. The contractor will be notified if they have a position with significant security responsibility. | |
| B.4 - Individuals with SSR shall have a documented individual training and education plan, which shall ensure currency with position skills requirements, with the first course to be accomplished within 90 days of employment or change of position. The individual training plan shall be refreshed annually or immediately after a change in the individual’s position description requirements. | |
| B.5 - Information Secuirty and Privacy training supplied by the Contractor shall meet standards established by NIST and set forth in DHS and TSA security policy. | |
| B.6 - The Contractor shall maintain a list of all employees who have completed training and shall submit this list to the contracting officer representative (COR) upon request, or during DHS/TSA onsite validation visits performed on a periodic basis. | |
| B.7 - The contractor shall its employees review and sign the TSA Form 1403 Computer and Wireless Mobile Device Access Agreement (CAA) prior to accessing IT systems. |
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.