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
Issued by
Department of Homeland Security Office of Procurement Operations

About this file

Attachment 2 - HAIBP Self-Assessment Scorecard

View the file

Other files for this federal contract opportunity

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 #RequirementThresholdObjectiveCOTS 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-01The system shall have a Replay Tool.NThe Replay Tool shall meet the requirements in Appendix B.N/A
Non-RTM-02The system shall detect neutron radiation sources utilizing technology that is not reliant upon Helium-3.NRequirement statement is the threshold value.N/A
Non-RTM-03The system shall be able to obtain Authority to Operate (ATO)NAt 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 GoalThresholdObjectiveCOTS 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-04The system provides data streaming capability.NThe 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-05The system is lightweight.NThe system weighs less than 17lbs.N/A
Non-RTM-06The 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).NThe system's weight is distributed evenly for balanceN/A
Non-RTM-07The system minimizes interference with the operator's ease of movement (easy to wear, remove, and have adjustable openings around the arms).NThe system is adjustable and easy to remove.N/A
Non-RTM-08The 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)NThe system does not have visible wires or sensors that would suggest its detection mission.N/A
Non-RTM-09The system is re-configurable to other form factors (e.g., portal, choke point, gateway)NThe 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 RequirementKPP?ThresholdObjectiveCOTS 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 )

4HAIBP-01
The instrument shall detect SNM sources in accordance with Backpack TCS Section 6.2.YThe 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.
5HAIBP-02
The system shall notify the operator of the presence of gamma radiation sources.NThe instrument shall respond to gamma radiation in accordance with ANSI N42.53 6.3.1.Same as threshold.
6HAIBP-03The system shall notify the operator of the presence of neutron radiation sources.NThe instrument shall respond to neutron radiation in accordance with ANSI N42.53 6.4.1.Same as threshold.
7HAIBP-04The system shall have a low false alarm rate.
Note: This requirement also addresses flow of commerce during mobile operations.NThe instrument shall respond to false alarms in accordance with ANSI N42.53 6.2.1.Same as threshold.
9HAIBP-06The 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.NMaintain 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 .
10HAIBP-07aSystem shall correctly identify present radionuclides that are unshielded with a Probability of Identification (PID) ≥ 80%.YIdentify the radionuclides listed in RTM Appendix A, Table 1.Objective = Threshold
11HAIBP-07bSystem shall correctly identify present radionuclides that are unshielded with a Probability of Identification (PID) ≥ 80%.NIdentify the radionuclides listed as Threshold in RTM Appendix A, Table 2.Identify the radionuclides listed as Objective in RTM Appendix A, Table 2.
32HAIBP-07cSystem shall correctly identify present radionuclides that are shielded with a Probability of Identification (PID) ≥ 80%.NIdentify radionuclides listed as Threshold in RTM Appendix A, Table 3.Identify radionuclides listed as Objective in RTM Appendix A, Table 3.
33HAIBP-O8aSystem shall comply with specified physical configuration and marking requirements.NSystem meets specified requirements in ANSI N42.53-2013, Sections 5.2 and 5.4.Same as threshold.
45HAIBP-08a-01BRD systems shall weigh less than
10 kg (~22 lb.) including the battery. The manufacturer shall state the weight in the operation manual.YBRD systems weigh less than 10 kg (22 lbs)Minimize weight while maintaining compliance with KPP requirements HAIBP-01 and HAIBP-07a.
51HAIBP-08a-02Provisions shall be provided to permit testing of visual or audible warning indicators without the use of
radiation sources.NThe requirement statement is the threshold value.Same as threshold.
52HAIBP-08a-03Internal controls needed for operation shall be identified through markings and identification in technical manuals.NRequirement statement is the threshold value.Same as threshold.
53HAIBP-O8bSystem shall comply with data storage and communication interface requirements.NSystem meets requirements specified in ANSI N42.53-2013, Section 5.3, along with any additional derived requirements.Same as threshold.
57HAIBP-08b-01The BRD shall have the ability to store a minimum of at least 8 h of data records.N8 h storage of data records12 h storage of data records
58HAIBP-08b-02Each 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.NRequirement statement is the threshold value.Same as threshold.
83HAIBP-08b-03Each 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.NRequirement statement is the threshold value.Same as threshold.
HAIBP-O8b-04When the data storage is full, new measurement event data shall overwrite existing measurement event
data.NThe oldest non-alarming data records shall be overwritten first [first-in, first-out (FIFO)].Same as threshold.
HAIBP-O8b-05An indication shall be provided indicating that the data storage is full.NRequirement statement is the threshold value.Same as threshold.
HAIBP-O8b-06The system shall be capable of interfacing with existing DHS and component information systems.NSystem 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-07The system shall have a removable storage device.NRequirement statement is the threshold value.Same as threshold.
HAIBP-O8cSystem shall comply with power supply requirements.NSystem meets specified power supply requirements in ANSI N42.53-2013, Section 5.5.Same as threshold.
HAIBP-08c-01A BRD shall have the ability to support a continuous operating time of 8 h under standard operating conditions without replacing batteries.N8 h operating time12 h operating time

Note: Hot swapping batteries can be used to achieve the 12 hour operating time.

HAIBP-08c-02The battery compartment shall be accessible without special tools.NRequirement statement is the threshold value.With no tools.
HAIBP-08c-03The low-battery indication shall be no lower than the minimum power required for proper operation.NRequirement statement is the threshold value.Same as threshold.
HAIBP-08c-04Provided 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.NRequirement statement is the threshold value.Same as threshold.
HAIBP-O8dSystem shall comply with user interface requirements.NSystem meets user interface requirements in ANSI N42.53-2013, Section 5.8.Same as threshold.
HAIBP-08d-01The display shall be readable under low light levels (< 150 lux—overcast day or work area) and high light levels (> 10 000 lux—full daylight).NRequirement statement is the threshold value.Same as threshold.
HAIBP-08d-02The display brightness shall be adjustable.NRequirement statement is the threshold value.Same as threshold
HAIBP-08d-03The 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.NRequirement statement is the threshold value.Same as threshold.
HAIBP-08d-04The identification results, confidence indicator, and ability to access spectra shall be provided at the user interface when identification capabilities are available.NRequirement statement is the threshold value.Same as threshold.
HAIBP-08d-05The information, provided in the Clarification statement, shall be automatically displayed at the User Interface.NRequirement statement is the threshold value.Same as threshold.
HAIBP-O8eSystem shall comply with the specified energy and response range, operating parameters, and diagnostic requirements.NSystem 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-01The manufacturer shall document the energy and response range information, as defined in the Clarification statement.NRequirement statement is the threshold value.Same as threshold.
HAIBP-08e-02The 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.NRequirement statement is the threshold value.Same as threshold.
HAIBP-08e-03A BRD shall have the ability to self-stabilize (e.g., stabilize detector gain based on temperature), monitor
functionality, and diagnose malfunctions without user interaction.NRequirement statement is the threshold value.Same as threshold.
HAIBP-09The system shall operate without scheduled maintenance.NOne 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-11The system shall perform reliably.NMean time between failures (MTBF) of at least 17,520 hours.35,040 objective hours between failure for the fleet.
HAIBP-11-01The system shall record cumulative system operating hours.NRequirement statement is the threshold value.Same as threshold.
HAIBP-12The system shall be safe to operate.NPass UL-61010-1 V3 (Reference 16) certification or equivalent.Same as threshold.
HAIBP-13System shall comply with the ANSI N42.53-2013 Environmental performance requirementsNSystem meets ANSI N42.53 2013, Sections 7.1 - 7.5.Same as threshold.
HAIBP-13-01System shall meet the ambient temperature requirement in ANSI N42.53-2013.NThe instrument shall respond to ambient temperature in accordance with ANSI N42.53-2013, Section 7.1.Same as threshold.
HAIBP-13-02System shall meet the relative humidity requirement in ANSI N42.53-2013.NThe instrument shall respond to relative humidity in accordance with ANSI N42.53-2013, Section 7.2.Same as threshold.
HAIBP-13-03System shall meet the extreme temperature startup requirement in ANSI N42.53-2013.NThe instrument shall respond to extreme temperatures in accordance with ANSI N42.53-2013, Section 7.5.Same as threshold.
HAIBP-14System shall comply with the ANSI N42.53-2013 Electrical and electromagnetic performance requirements.NSystem meets ANSI N42.53 2013, Sections 8.1 - 8.4.Same as threshold.
HAIBP-14-01System shall meet the radio frequency requirement in ANSI N42.53-2013.NThe instrument shall respond to radio frequency in accordance with ANSI N42.53-2013, Section 8.1.Same as threshold.
HAIBP-14-02System shall meet the radiated emissions requirement in ANSI N42.53-2013.NThe instrument shall respond to radiated emissions in accordance with ANSI N42.53-2013, Section 8.2.Same as threshold.
HAIBP-14-03System shall meet the magnetic field requirement in ANSI N42.53-2013.NThe instrument shall respond to magnetic field exposure in accordance with ANSI N42.53-2013, Section 8.3.Same as threshold.
HAIBP-14-04System shall meet the electrostatic discharge requirement in ANSI N42.53-2013.NThe instrument shall respond to electrostatic discharge exposure in accordance with ANSI N42.53-2013, Section 8.4.Same as threshold.
HAIBP-15System shall comply with the ANSI N42.53-2013 Mechanical performance requirementsNSystem meets ANSI N42.53, 2013 Sections 9.1 - 9.3.Same as threshold.
HAIBP-15-01System shall meet the vibration requirement in ANSI N42.53-2013.NThe instrument shall respond to vibration exposure in accordance with ANSI N42.53-2013, Section 9.1.Same as threshold.
HAIBP-15-02System shall meet the mechanical shock requirement in ANSI N42.53-2013.NThe instrument shall respond to mechanical shock exposure in accordance with ANSI N42.53-2013, Section 9.2.Same as threshold.
HAIBP-15-03System shall meet the mechanical drop test requirement in ANSI N42.53-2013.NThe instrument shall respond to the exposure of being dropped in accordance with ANSI N42.53-2013, Section 9.2.Same as threshold.
HAIBP-15-04System shall meet the impact (microphonics) exposure requirement in ANSI N42.53-2013.NThe 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
TThreshold
OObjective
NNone

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)
RadionuclideThreshold (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)
RadionuclideThreshold (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 CaptureO
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)
RadionuclideThreshold (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 CaptureO
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:
ReproducibilityThe replay tool exactly reproduces the device algorithm output when given identical input.
GR-1-REPThe 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-REPThe 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-REPReproducibility 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.
AutonomyThe stand-alone tool has no additional software or run requirements.
GR-6-AUTThe 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-AUTThe replay tool shall process each input file separately.Same test as GR-5-REP.
InjectionInjection and synthetic input file generation capability exists.
GR-8-INJThe 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-INJThe 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.
OutputReply results facilitate consistent evaluation of results across devices.
GR-10-OUTThe 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-OUTThe 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-OUTThe 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-OUTThe 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-OUTSoftware 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-OUTSoftware 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.
InputsTraceability of analysis parameters and input data from input to output.
GR-16-INPDevice-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-INPModel 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-INPHardware 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-INPBackground 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 LineEfficient replay of large numbers of files.
GR-20-BATThe 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-BATDuring 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-BATBatch 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-BATDesignation 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-BATThe 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-BATThe batch facility shall flag the output of any errant file that can be processed by a unique identifier.
GR-27-BATThe 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-BATThe 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-BATThe 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-BATThe batch facility shall provide tabulated data from batch that indicates, for each batch, the number of alarming and non-alarming files.
GR-31-BATThe 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 PortabilityBackward data-handling compatibility; ability to run on standard computer platforms.
GR-32-COPThe 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-COPThe 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-COPUpdated 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 VerificationMethod and files to validate installation and verify reproducibility.
GR-35-VAVThe 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-VAVThe 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.
DocumentationComplete manual, file architecture, version documentation.
GR-37-DOCThe 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-DOCThe 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-TRABackpack 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
PROGeneral comments pertaining to Proprietary Safeguards
PRO-1The source code will not be required for installation, running, or parameter adjustment of the replay tool.
PRO-2DNDO will request the vendor to make modifications to the replay tool’s code if adjustments are required or desired by DNDO.
PRO-3Adjustments 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-4Details 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-5An 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-6The 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-7The 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 TypeMinimum number of replay installation validation input and output files*Minimum number of replay verification input and output files**Installation Validation CriteriaVerification Criteria
Backpack Device6010 hours of dataIdentical 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 DescriptionRequirement (Threshold and Objective)
A. General Security RequirementsA.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 RequirementsB.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.