Attachment 1 SOW.pdf

ATTACHMENT 1

PART IIA

STATEMENT OF WORK

Statement of Work

Overview TSA's Alarm Resolution (AR) activities are focused on improving, acquiring, and deploying capabilities and technologies to enhance the operational efficiency and security effectiveness of the AR and Advanced Alarm Resolution (AAR) capability. RCA's role in TSA's acquisition of TSE includes identifying needs, defining suitability and specific user requirements, analyzing alternatives, and demonstrating new capabilities/solutions.

Background

The mission of the TSA is to protect the nation's transportation system to ensure freedom of movement for people and commerce. TSA's mission is derived from the Aviation and Transportation Security Act of 2001, which directs TSA to screen all passengers and property that will be carried aboard a passenger aircraft. To achieve its mission, TSA must ensure that its aviation security screening equipment is both effective and efficient. AR, including AAR, is used to resolve explosive and Non-Explosive Prohibited Items (NEPI) alarms occurring during primary screening. The Alarm Resolution Capability Management Mission involves Advancing Materiel and Non-Materiel capabilities to accurately identify, analyze, verify, resolve, and connect alarms within the TSA security ecosystem.

Place of Performance

This Contract will consist of multiple places of performance to include, but not limited to the Transportation Security Laboratory (TSL) located in Atlantic city, NJ, the TSA Systems Integration Facility (TSIF) located in Arlington, VA as well as airport locations (TBD).

Period of Performance

The period of performance (PoP) of this contract shall be a base period of twelve (12) months from date of award plus two (2) 12 month options periods for a total 36 months if the Government decides to exercise the options.

Security Clearances The Contractor shall ensure all of its staff members have the required level of approved 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 any system or other TSA resources as granted.

The Contractor shall sign a DHS Form 11000-6 Non-Disclosure Agreement (NDA) within thirty

(30) calendar days of the contract start date.

Contract Requirements

The Contractor shall provide two (2) fully functional bailed systems, that satisfy the requirements of the RFP and this SOW at no cost to the Government per a Bailment Agreement.

(Attachment 2). Systems shall not be delivered without TSA authorization based on the process below.

1. Project Management and Support

While TSA will not evaluate proposals on Project Management strategies, this multi-year program requires robust planning and management. TSA is not providing separate monetary award for Project Management and Support. The Project Management and Support area is considered as a Not Separately Priced (NSP) item; the Contractor is still required to perform project support activities and complete deliverables to enable project progress and milestone achievements.

The Contractor shall maintain a formal organization to manage and execute the objectives of this SOW efficiently and effectively. During the period of performance, the Contractor shall be available to provide on-site or remote support to the Government as requested by the Contracting Officer’s Representative (COR).

1.1 Post Award Conference

A post-award conference will be conducted at a site specified by the Government or via WebEx, within ten (10) days after award. The TSA will designate Government conference attendees and will identify any unique conference support objectives. The Government will develop an initial agenda to include the following, which the Contractor shall be prepared to address.

• Overview of the deliverable submission status

• Invoicing procedures

• Project risk management

• Project schedule with milestones

• Organizational status

• Price, schedule, and performance (technical) aspects of the SOW

• Subcontractor’s technical progress on all assigned tasks (if applicable)

• Lines of communication

The Contractor shall provide the minutes for the conference to the COR within two (2) days after the conference.

1.2 Status Tracking and Reporting

The Contractor is responsible for project management throughout the entire period of performance. The Contractor shall provide all labor, materials, planning, management and equipment necessary to complete the tasks for design, development, integration, and/or testing objectives in accordance with this SOW and all applicable State and Federal codes and laws. The Contractor shall identify a single point of contact (POC), such as a Project Manager who shall be the Contractor’s focal point for all required project tasks. The Project Manager can also be a technical lead on the project, thus wearing multiple hats in performing contractual tasks.

The Contractor shall perform monthly project status tracking and reporting, project management reviews, and technical interchanges during the life of the contract. An annual technical report will be provided to the COR and cover all technical aspects of the project. These meetings are mostly via teleconference; however, they can be in person at a location as directed by Government Contracting Officer (CO) or COR.

The Contractor will support Project Management Reviews (PMRs), where the project status is discussed in depth and further discuss issues most critical at the time. A Technical Interchange Meeting (TIM) can be called by the CO, COR, or Contractor, to discuss design updates and/or evaluate merits of proposed technical changes. PMRs and TIMs can satisfy status reporting and the CO or COR may cancel the regular project status reporting as a result.

The Contractor shall be responsible for identifying, vetting, and obtaining all required and necessary badges needed to accomplish installation requirements throughout all associated project phases and for all required labor personnel. Contractor shall reach out to the COR to initiate the process.

1.3 Project Risk Management

TSA believes that the Risk Management process is an ongoing effort of identification, assessment (likelihood, impact), response planning (including developing contingency plans), and monitoring. The Contractor shall highlight methods to managing, identifying, mitigating and tracking risks throughout the period of performance of this contract. The Contractor shall identify price, schedule, and technical risks and describe how these will be effectively managed throughout the period of performance of this contract.

With the incorporation of a new process and technology into the checkpoint, there are inherent risks spanning operations, technology, legal and contracts, maintenance, and data collection, assessment, and reporting. Mitigation options will be identified through coordination across stakeholders at the TSA, airports, and technology vendors. Options may include contingency plans, passenger communications, training, staffing needs, and modifications to support contracts. Additional development of legal and contractual agreements may be needed.

1.4 Project Schedule Management

Post award, the contractor shall provide their planned project schedule including expected completion time periods pertaining to the project milestones and deliverables defined in Table 1 - Milestones and Deliverables, and an expected completion time period for the overall project.

Contractors are expected to develop and maintain a schedule using an Integrated Master Plan (IMP) and/or an Integrated Master Schedule (IMS) process.

Post award, the Contractor shall provide a schedule outlining the following milestones and deliverables to support general Test and Evaluation (T&E) activities as listed below:

o Kick-off Review & Schedule o Preliminary Design Review (PDR) o Critical Design Review (CDR) o System Design Document (SDD) (baseline) o System Test Plan o Pre-Certification Readiness Test (Pre-CRT) o Test Readiness Review (TRR) o Test Execution o Quick Look Report (QLR) o Final Technical Report o Closeout Report Presentation / Stage Gate – Determine Execution of Option Year

(OY)

An outline of each report shall be delivered to the COR for Government comment at least ten

(10) calendar days prior to delivery due date of each report per the Table 1 - Milestones and Deliverables. The Final Report shall be delivered thirty (30) days prior to the end of the period of performance to permit Government review, comments, and resulting Contractor revisions.

1.5 General Test and Evaluation (T&E) Support

In support of any Government laboratory and field testing, as well as Contractor’s internal testing for the development and completion of the work, the Contractor shall:

• Plan, communicate, and conduct Contractor tests

• Support Government-conducted testing and continuous assessment

• Prepare and deliver all scan and test plans, training sets (for machine learning algorithms), procedures, necessary Government forms, and report results and associated deliverables for each test activity as required or directed by COR.

• maintain a single POC as the lead for all testing activities related to this SOW. The single POC shall deliver and/or receive all test reports and schedules to/from the Government as required and participate in the technical meetings. This particular POC shall be responsible for coordinating all test activities and shall relay pertinent reports and schedules to the site-specific project managers and internal Contractor stakeholders as required. The Contractor shall:

o Provide the necessary test equipment and ensure its availability, proper calibration, fully operational status, and operation as documented by the test equipment manufacturer.

o Obtain prior written approval from the Government before using unique or modified commercial test equipment not specified in the approved test plans and procedures.

o Provide the Government, if asked, with the proof of proper calibration of test equipment provided by the Contractor.

o Conduct, or support the Government in conducting, a Test Readiness Notification

(TRN) and Test Readiness Review (TRR) prior to performing any formal test.

o Notify the Government at least ten (10) business days prior to commencement of all formal Contractor conducted Acceptance Testing and permit the Government to witness the test.

o Perform all data collection and analysis associated with Contractor testing and furnish original data and analysis methods and results to support claims of Test and Evaluation (T&E) success. If requested by the Government, the Contractor shall provide the data collection report inclusive of data, methods and results, within fifteen (15) days after the completion of a Government-directed and/or Contractor-conducted test.

o Record all inputs, outputs, and test results as described in any approved test plans and/or procedures. Anomalies, test deviations, test equipment substitutions, members of the test team, any other significant events, and the start and stop time for each test shall be documented.

• The Test Readiness Notification (TRN) is a notification from the Contractor to the Government stating that the system will be ready for testing on the specified date.

The Contractor shall provide the Government a TRN at least ten (10) business days before conducting each formal test. A formal test includes any test that the Government deems as formal and demonstrates operational capabilities to verify machine (hardware and/or software) functionality. TRN shall be submitted via email to the Government COR and any other representative as designated by the CO. The TRN shall include, but not be limited to the following:

o Contract number o Serial number of the unit(s) to be tested o Type of test to be conducted o Open test anomalies observed to date o Open Engineering Change Proposal (ECP), Request for Deviation (RFD), Request for Waiver (RFW) or deviations o Test procedure status (version—date) o System configuration (i.e., stand-alone, fully integrated, exit-integrated) and part numbers of critical components as identified in the MCIL o Software version o Affirmation that the system will be ready for testing o Comments

• The Test Readiness Review (TRR) is a formal review of the Contractor’s software or equipment, as specified in the TRN, and related documentation to verify readiness for test.

In the event that the Contractor presents equipment to the Government or designated Government representative without the aforementioned documentation or on account of preventable failures, the Government reserves the right to request the Original Equipment Manufacturer (OEM) to provide additional Independent Validation and Verification (IV&V) testing at no additional cost to the Government.

If requested by the Government, a Verification Requirements Traceability Matrix (VRTM) shall be included in test plan or procedure, clearly listing each specification and lower-level derived requirement to be verified in that test with a reference to the appropriate requirement paragraph, including test location and test method.

The Contractor shall support (as described below) Government’s developmental testing with or without representative field operators in the intended operational environment, or at an Operational Demonstration site when directed by the Government. These events may include integration testing or conducting Site Acceptance Testing (SAT) for capabilities developed and deployed under this SOW such as automated screening lanes or networking. The Government will conduct laboratory test and/or an Operational Demonstration on AR solutions with new or updated algorithms, to include various configurations and/or software and hardware components desired by the Government, to assess operational effectiveness and suitability of the algorithms and/or any proposed software or hardware modifications or integration. The level of testing effort will be determined by the Government. The Contractor shall support the Government’s developmental testing by providing at a minimum the following support as directed by the Government:

• Attend and participate in on-site planning meetings and test preparation at the designated test sites

• Prepare, review with the Government, and deliver applicable test plans

• Conduct Operator Training and provide updated operational manuals

• Provide on-site technical support

• Support for configuration management activities as required

• Assist with all data collection, including interpretation/analysis of Field Data

Reporting System (FDRS) data

The scope of developmental testing will include a Government evaluation of technical reports and/or briefings through System Design Reviews (e.g., System Concept Reviews [SCR], Preliminary Design Reviews [PDR], Critical Design Reviews [CDR]), test plans, Pre- Certification Readiness Test (Pre-CRT) results, and other design documentation. The Government reserves the right to witness all Contractor-conducted test activities.

1.6 Configuration Management

The Contractor is responsible for meeting configuration control requirements as documented under TSA’s Configuration Management Guidance and as applicable to the developmental systems and environments in accordance with this developmental opportunity as identified in section 1.6.1 below. The Contractor is required to maintain its Configuration Management Program during testing of two (2) fully functional bailed systems as established under this contract and manage the configuration baselines established for all equipment.

The following list outlines key terminologies to establish common understanding for specific TSA Configuration Management artifacts:

• CSAR - The Configuration Status Accounting Report provides text and (marked-up) technical documents (e.g., specifications, engineering drawings) that identify discrepancies between the material (including software) and the requirements delineated in the applicable technical documents. Depending on the type of audit, the identified discrepancies may be attributable to the material, the technical documents, or both.

• MCIL - The Master Configuration Item List establishes and maintains the definitive, current basis for control and status accounting of a system and its designated hardware, software, and firmware configuration items (CI) throughout their lifecycle that are being developed for and/or used in the TSA security system inventory. This information is needed to manage and support those items during their lifecycle.

• DEP - A Deviated Engineering Proposal describes a proposed (prior to manufacturing) departure from configuration documentation for a specific number of units or for a specified period. A DEP enables the Government to determine the impact on performance, operational readiness, logistics support, or other affected areas.

• ECP - An Engineering Change Proposal includes both engineering change and the documentation by which the change is described and suggested. It describes changes to configuration items and associated configuration documentation that are affected by the proposed engineering change.

The Contractor shall retain all documentation for identification, control, and status accounting of all Configuration Items (CI) throughout the program life cycle. The CI identification shall be available in the MCIL and provided on monthly basis. The Contractor shall apply configuration change management measures to each baseline CI and its configuration documentation. The Contractor’s configuration change management system shall provide effective means, as applicable, for proposing changes to CIs and ensuring implementation of the approved change.

The Contractor shall maintain configuration change management of hardware; software;

firmware; and developmental, commercial, and training documentation. The Contractor shall maintain configuration change management of hardware to the Lowest Replaceable Unit (LRU) level and software to the version level.

The Contractor shall make available the following required documents as evidence of maintaining the baseline:

• CSAR

• MCIL

• Design documents

• Engineering drawings

• Bill of Materials (BOM)

• Source code documents

• Product data sheets

• Software release notes

• Approved Change Requests

Change requests represent opportunities for improvement or correction of deficiencies and must be documented and submitted to the Government for review and approval. Desired changes are documented in Requests for Change (RFC) in the form of ECPs or DEPs. All change requests are entered, tracked, controlled, and documented by the Contractor.

The Contractor shall support Government-conducted Functional Configuration Audits (FCA) and Physical Configuration Audits (PCA) on the two (2) fully functional bailed systems under this contract. The FCA shall verify system functional performance requirements. Upon successful completion of the FCA, a PCA will be performed. The PCA shall be conducted after the successful completion of each FCA. The PCA shall verify system physical performance requirements.

2. Bulk Detection & Improved Identification for Explosives, Non-Explosive Precursors for

HME, and Non-Explosive Threat Materials

The two (2) fully functional bailed systems must be able to meet or exceed detection capability for the defined characterization list at concentrations of 8% or greater within a sample by the end of the performance period.

2.1 Initial Assessment of Bulk Detection System

At the time of installation, the Government will provide threat training identification sets for all threats to the Contractor for initial identification capability. The Contractor shall demonstrate to the government their identification development process through internal testing using a limited number of Contractor provided threats from TSA’s threat data documentation. Upon installation completion and notification by the Government, the Contractor shall provide on-site support to the Government to collect and analyze threat sample data from the TSL and/or other Government test facilities to support identification performance. The Contractor shall ensure the Government’s ability to collect the signature data and results for each threat. The Contractor shall ship disc drives containing the data collected and metadata to stakeholders coordinated and approved by TSA.

2.2 Preliminary Design Review (PDR)

PDR shall follow the guidelines and best practices of The DHS Research, Development, Test and Evaluation (RDT&E) & International Council on Systems Engineering (INCOSE), and Defense Acquisition University (DAU), and be tailored as appropriate.

With an estimated due date of three (3) months from date of award, the Contractor shall hold a PDR and present preliminary system concepts prior to initiating any development of the above capability developments. The PDR will cover requirements review (top-level from TSA EDS/AT platform) to include Concept of Operations (CONOPS) summary and External System Interfaces.

The Contractor shall provide a presentation of proposed conceptual design and planned technical approach. This meeting will review intermediate progress on all tasks and will highlight the status of the system and subsystem specifications. The PDR also determines whether subsystem requirements track with the system design. Any concerns as to whether the logical design is aligned and supportable by the technical architecture should be raised and resolved by the contractor before starting the detailed design. The Contractor shall also include a presentation to the TSA that summarizes the results of subtask 4.1.6 (General Test and Evaluation Support) efforts and present data analysis representing the anticipated performance of proposed detection algorithm enhancement approaches. The contractor shall present the expected differences between the current sampling technology and the proposed sampling method/system; all conclusions shall be discussed and substantiated. The Contractor shall present a functional description for each proposed sampling enhancement. The presentation shall indicate any proposed modifications. The Contractor shall also include considerations for the User Interface of the prototype. The Contractor shall prepare an agenda and provide it to TSA for approval four (4) weeks in advance of the PDR and provide slides for review five (5) business days prior to the PDR scheduled date.

2.2.1 Proposed System Baseline

Proposed system baseline in preliminary form to include:

1. Functional baseline, diagram, performance, and functional interfaces with allocation to physical architecture (hardware and software subsystems)

a. Sampling methods

i. Preparation

ii. Standoff detection distance

b. Calibration/verification frequency

c. Material analysis time

d. If clear-down is necessary

2. Physical architecture, system block diagram to subsystem and card-level definition

3. Power needs; total and allocation to the card-level

4. System and subsystem packaging

5. Subsystem interfaces

6. Software system diagram to software subsystems and interfaces

a. Current Library

7. Software operating system environment(s)

8. Interfaces and communications

9. Information security architecture

10. Functional allocation to physical architecture (H/W and S/W)

11. Performance review and analysis of key processing threads

12. Detection processes and photon budgets including Automated Threat Recognitions

(ATR) and other algorithms

13. Processing timeline budgets

14. System throughput budgets

15. Environmental specifications

16. Risk areas and mitigation approaches

17. Test and integration plan and procedure

18. Integrated Logistics Support (ILS) and Resource Allocation Module (RAM) plan

19. Quality Assurance (QA) plan

20. Change Control Board (CCB) plan

21. Compliance matrix of requirements

22. System specifications (as proposed for manufacturing)

23. Bill of materials estimate ROM (or budget allocated to subsystems, H/W & S/W)

24. Critical and long lead items (to include per item costing)

25. Identify Commercial off-the-shelf (COTS) items (hardware and software)

26. Software security

27. Software Operating System

28. Usability Assessment

29. Human Factors and/or Human System Integration considerations

30. Key Trade Studies (Planned and underway. A list shall be maintained during the project and provided to TSA.)

31. Technical approach to meeting the new Detection Standard v6.2A at highest capability in the Detection Standard

2.3 Critical Design Review (CDR)

The contractor shall hold a CDR (estimated date six (6) months from date of award) and present near-final detailed design concepts and results prior to the initial Request for Deviation to enter TSL testing. The COR will provide approval for system algorithm approaches to be matured in the CDR prior to the contractor beginning work. The Contractor shall submit a Preliminary Design Review and Report for their proposed system. The CDR will be used to evaluate the system’s detailed design completeness towards meeting requirements and the development entity's readiness to begin algorithm assessment. This meeting will report on the completion of an updated algorithm version. Continuing progress on all tasks will be summarized along with a detailed discussion of the deliverables. Trade studies and a final plan for design studies will be presented to DHS S&T/TSA for feedback. To complete the CDR stage, the COR will provide approval for all detection algorithm approaches to be matured per the CDR guidelines discussed in this section prior to the contractor beginning work. The Contractor shall submit a report for each algorithm developed. The contractor will generate and deliver a System Design Document (SDD) covering all tasks which shall include, but is not limited to, the physical designs, system designs (including source code with comments as developed and executable code), hardware, parts lists/bill of materials, system interfaces, software architecture, simulators, algorithms, software tools, software libraries, testbeds, interfaces, test fixtures, testing, and test results. The Contractor shall provide additional plans for end-user (i.e. Transportation Security Officers (TSOs)) discussion.

CDRs shall follow the guidelines and best practices of DHS RDT&E, International Council on Systems Engineering (INCOSE), and Defense Acquisition University (DAU), tailored as appropriate. An agenda will be prepared and provided to TSA four (4) weeks in advance for approval prior to the CDR event.

The CDR will provide PDR items as listed in section B.4.2.2 prior to readiness for build and will include the following additional items:

1. Detailed designs of the hardware, software, and packaging. The detailed hardware designs will include signed-off. Software designs need to be at a completion level such that detailed implementation or coding can begin if CDR passes Government review. Contractors shall include Bill of Materials with estimated manufacturing costs, baseline schedule and risk mitigation plans.

2. Performance reviews of key processing threads and system response timelines, for example:

a. Detection processes, adequate signal-to-noise and dynamic ranges, discrimination of threats, and clutter:

i. Test data per class

ii. Receiver Operating Characteristic (ROC) curves

iii. False alarm rate

b. System throughput

c. Human Factors / Human System Integration considerations

d. Environment specifications

e. Technical approach for compliance with new Detection Standard. The contractor shall provide detailed designs along with supporting analysis and/or experiments of the end-state system at the PDR.

3. The key trade studies shall be presented, covering key issues needing resolution, requirements impacted, architecture impacts, methods or approaches used in the trade study, findings, and rationale for the recommended approach used in the CDR system baseline.

4. Test Readiness Review (TRR) and Test Reviews.

a. The test readiness reviews will establish the goals and metrics of the testing that will occur, the success or passing criteria, and non-passing criteria. It also includes the test conditions and environment descriptions including all support equipment, test articles, requirements compliance matrix and test procedures. A checklist will be signed off indicating readiness and include a requirements compliance matrix that will be provided to TSA. The test reviews will cover the test results and summarize performance (both above performance and areas below performance).

For areas of underperformance, approaches that enable reaching required performance will be addressed including options or methods for improvements and mitigation of related risks.

2.4 Contractor Facility Demonstration – Pre-TSL Proof of Concept

Via Bailment Agreement and at no cost to the Government, the Contractor is expected to provide two (2) fully functional prototypes that satisfy the requirements of this RFP. Prior to TSL testing, TSA will travel to the Contractor Facility to witness equipment demonstration upon approval of TRN. The Contractor will demonstrate two (2) fully functional bailed systems to TSL that will be used for testing and data collection at TSL.

2.5 Detection Algorithm Development and Evaluation

The Contractor shall develop enhanced detection algorithms that can demonstrate the detection performance as specified for each algorithm delivery. The Contractor shall investigate, design, and develop detection algorithm enhancements using the analysis acquired in Section B.4.1.6 General Test and Evaluation Support to establish some different algorithm development approaches. The contractor shall ensure the resulting detection algorithm developed can be implemented on the Checkpoint Alarm Resolution two (2) fully functional bailed systems utilized at TSL/ TSA Systems Integration Facility (TSIF) to support further government evaluation. The proposed detection algorithm changes shall minimize modification of existing system computer architecture or require modification of existing TSL/TSIF test articles used in the certification process. The Contractor shall develop internal equivalency test reports for all changes. The proposed detection algorithm changes shall be field upgradeable and support long-term risk-based screening goals to switch algorithms dynamically. All detection algorithm design approaches and internal test data shall also be readily available to be discussed during design reviews and considered for further inclusion in Algorithm Assessment Data Packages. If the Contractor is proposing to change any hardware or software design elements, the Contractor must notify the COR to hold a Technical Interchange Meeting (TIM) with the Government to discuss and for the COR to determine the appropriate direction(s) and decision(s). The COR must approve all such proposed changes in writing.

2.6 Preparation and Submission of Algorithm Assessment Data Package

Under this subtask, the Contractor shall prepare and submit a Pre-CRT Data package to include the TRN and TRR to TSL. Pre-Certification Readiness Tests (Pre-CRT) will be conducted in accordance with the Alarm Resolution System defined process. The Pre-CRT plan will be provided by TSA. Section B.4.2.9 discusses the Development of Developmental Deviation (DEP) and Engineering Change Proposal (ECP) packages. The Pre-CRT Data package shall identify any configuration changes relative to a certified baseline or previously submitted and tested configuration. The package shall contain expected performance differences relative to the previously submitted configuration, including a functional description of the modified algorithm.

The package shall indicate any modified detection parameters. Detection performance impact statements shall address detection factors such as explosive type, mass, and concealment.

The Contractor shall submit a Pre-CRT Data package for each developed algorithm. Algorithm Assessment Data Packages submitted for Pre-CRT should be submitted as part of the CDR milestone. Upon further direction from TSA and TSL, the Contractor shall ensure that the algorithm is fully loaded and available on the two (2) fully functional Alarm Resolution bailed systems. Contractor shall ensure the fully functional bailed system under test and evaluation is fully operational and compliant with the Configuration Management Plan provided by TSA; all manuals, instructions, and procedures shall be up-to-date. All resulting Alarm Resolution system data shall be available to the government testers upon request.

2.7 TSL Technical Reports

The Contractor shall develop a technical report after the initial submission of their Pre-CRT Data Package to TSL (Initial Technical Report) and their final submission of their Pre-CRT Data Package to TSL (Final Technical Report). Technical Report packages shall include the following elements at a minimum:

• Title Page

• Introduction

• Summary and Methodology

• Results

• Contractor Assessment of TSL Results

• Path Forward

2.8 Support Pre-CRT Evaluations

The Contractor shall provide support for TSL Pre-CRT and Certification testing, for the two (2) fully functional bailed systems, until positive results are achieved, or maximum test opportunities are exhausted. The Government reserves the right to authorize additional certification test efforts or to remove the Contractor and terminate the contract as it determines appropriate. Throughout Pre-CRT and Certification testing, the Contractor shall continue to provide the detection capability of threat data offline, provide on-site testing support, additional data collection, and data package updates as necessary to support Pre-CRT and certification testing at Atlantic City, New Jersey, Huntsville, Alabama or Panama City, Florida locations.

To enable detection assessment against detection standards and/or mutually defined detection material, the Contractor shall support the Government for all necessary scanner upgrades, both hardware, and software, to ensure timely test completion. The Contractor shall also provide training to the Government test teams. Furthermore, all fully functional bailed systems shall be maintained in accordance with the Configuration Management requirements listed under section B.4.1.7.

2.9 Deviated Engineering Proposal (DEP) and Engineering Change Proposal (ECP)

To submit algorithms for test and evaluation, the Contractor shall submit a DEP for the applicable fully functional bailed system. It is required that the Contractor submit individual DEP requests as requested by the government, separating out the request for the scanner versus the system, thus identifying specific change requests for each equipment piece at its location.

The Contractor shall provide documented Installation and Activation Procedures and update the latest version of the Master Configuration Item List that reflects the new certified algorithm as an additional algorithm (an additional line item) within the document. The contractor shall submit the DEP to include and as a part of the Algorithm Assessment Data Package described in Section B.4.2.6.

Upon successful completion of Subtask B.4.2.6, Preparation and Submission of Algorithm Assessment Data Package and submission of DEP packages, the Contractor shall submit an ECP for the detection algorithm software, covering the effectivity of the Transportation Security Laboratory (TSL), Tyndall AFB, Terrorist Explosive Device Analytical Center (TEDAC) Improvised Explosives Detection and Synthesis (TIEDS), and TSA Systems Integration Facility (TSIF). This includes associated cost data to implement and deploy the proposed change to each AR system.

2.10 Phase 1: Pre-TSIF Proof of Concept Demonstration

Prior to installation of the proposed two (2) fully functional bailed systems, the Contractor shall conduct a demonstration of its enhanced AR capabilities at the Contractor’s facility with TSA as a witness. The Contractor will demonstrate their system’s abilities prior to deployment/bailment to TSIF. Contractor support of the AR system demonstration may include:

• Supporting in the validation of all input, output, and timing signals from the prototype. All integration and testing issues shall be reported to the Government.

• Supporting system testing and validation conducted by internal or external organizations including a Test Plan for the iSAT and pre-iSAT project testing; and availability throughout the planning phases including the issuance of the iSAT, TRN, and TRR. When determining resources, the Contractor shall, at a minimum, plan on one (1) test effort and one (1) retesting effort.

• Providing FDRS data in Comma Separated Value (CSV) format as requested for the duration of the operational run-in. In addition to the FDRS data, Government may request other reports, to include the equipment summary reports, bag summary reports, and system event reports that are used to support the evaluation of a predetermined thirty (30)-day operational run-in period.

• Demonstrating system’s compliance with DICOS v2.0A Software Development Kit

(SDK).

• Identification of bugs and how they will be resolved along with the design changes for version 2.0A.

• Supporting the development of a Security Technology Integrated Program (STIP) Integrated Requirements Development (IRD).

2.11 Phase 2: TSIF Installation and Assessment

Phase 2 will be the implementation of the proposed and validated two (2) fully functional bailed systems at TSIF by the Contractor. The Contractor shall benefit from reduced installation, test and evaluation times due to the availability of systems/infrastructures already in place from the two (2) fully functional bailed systems and all the planning activities in Phase 1. This phase covers the installation and any necessary upgrades for the two (2) fully functional bailed systems.

2.11.1 TSIF Installation and Coordination

The Contractor shall be responsible for all labor, materials, equipment, and support services needed to ship, assemble, power up, configure, and install the two (2) fully functional bailed systems in preparation for an AR Site Acceptance Test. This includes any system AR component, software, or configuration needed to meet the required end-state configuration. All equipment is subject to Government approval for the specified installation site configuration.

The Contractor shall:

• Coordinate with the TSA Office of Property Management

• Provide oversight and technical guidance

• Notify appropriate TSA personnel promptly in the event of improper equipment handling

• At the time of installation, deliver an operator manual and conduct training events that describe the necessary instructions and requirements for the installation, setup, operation, and configuration of the proposed AR solution

Date of installation will be determined by the Government. The Contractor shall deliver the two

(2) fully functional bailed systems to the installation site only upon direction of the Government.

The Contractor is responsible for all coordination in regard to the delivery of the equipment.

2.11.2 TSIF Assessment Support For Bailed Systems

Prior to the operational start of the bailed AR checkpoint solution, the Contractor shall support the training of TSIF personnel on any and all portions of the bailed AR checkpoint solution. The Contractor shall provide any manuals, training documentation, and on-site training prior to the formal assessment. The training documentation should provide effective and comprehensive details on how to operate the AR solution. The Contractor shall provide on-site support during the assessment activities to adjudicate any issues/errors specific to the two (2) fully functional AR bailed systems. The Contractor shall provide assessment data reports as requested. In addition to the data report, the Government may request other reports, to include equipment summary reports, bag summary reports, and system event reports.

The Contractor shall provide technical consultations to the Government regarding project efforts that may include but are not limited to teleconferences, reviews of drawings and specifications, and exchanges of technical documentation such as specifications, manuals, and guides. The Contractor shall provide technical consultations to the Government during the AR site installation engineering and design analysis process.

2.12 Phase 3: Airport Field Assessment and Equipment Placement

With a successful TSIF assessment and proper planning, the installation at an airport should occur with minimum issues and interruptions to the checkpoint operation. All security equipment shall be physically positioned in accordance with the equipment installation guidelines and air carrier operational requirements. The equipment layout must (to the highest extent possible) provide clear and unrestricted access to any rack or equipment units (including consoles) to permit equipment maintenance or removal.

The Contractor shall execute a stream of commerce data collection in the operational airport, and after system installation, training, and a thirty (30) day burn-in period, the system will be ready for operational assessments. RCA will conduct direct observations to record SoC item characteristics and screening performance. Data collection results will validate the proposed CONOPS and inform screening procedures and performance capabilities.

2.12.1 Airport Field Assessment Support For Bailed Systems

Prior to the operational start of the two (2) fully functional bailed systems, the Contractor shall support the training of TSOs on any and all portions of the two (2) fully functional bailed systems. The Contractor shall provide any manuals, training documentation, and on-site training prior to screening passenger’s accessible property. The training documentation should provide effective and comprehensive details on how to operate the AR solution The Contractor shall provide on-site support during the initial operational run-in and during go-live activities to adjudicate any issues/errors specific to the two (2) fully functional bailed systems. The Contractor shall support the Government’s operational run of the live accessible property once the Government provides determination of satisfactory completion or conditional acceptance of the AR acceptance test. The Contractor shall provide field data reports as requested. In addition to the field data report, Government may request other reports, to include equipment summary reports, bag summary reports, and system event reports that are used to support the evaluation of a predetermined thirty (30) day burn-in period.

2.12.2 Regression Testing

Because the intent of the AR program is to ultimately procure modified COTS equipment (with custom developed software), all quality assurance is validated throughout the development, demonstration and assessment process. In this process, the OEM goes through the following test stages:

• System Test

• Transportation Security Laboratory (TSL) Test

• TSA Systems Integration Facility (TSIF) Test

• Airport Field Assessment

During each stage, both hardware and software components go through critical assessments.

System Level Architecture and Design documents are provided as part of the AR solution development and are used to assess if there are any design flaws in the architecture. During the test stages, the test team verifies that all results are obtained through repeatable operations.

Therefore, the Contractor shall run the system through dozens of cycles to demonstrate the consistency of the result. At other times, the requirement itself dictates that rigorous testing is needed in order to achieve a certain result (such as false alarm rates or operational availability requirements). Any changes made to the AR solution by the Contractor to address any failure will often result in additional regression testing to ensure no adverse effect has occurred, and to provide assurance as to the quality of the two (2) fully functional bailed systems.

3. Milestones and Deliverables Table 2 outlines the expected Milestones and Deliverables for this Statement of Work.

Table 2- Milestones and Deliverables Item SOW/RFP

Reference Deliverable Due By

Life of Contract A SOW 1.1 Post Award Conference (PAC) and

Materials One, within ten (10) days of award or as directed by the CO B SOW 1.2 Status Tracking and Reporting Calls and Materials Recurring on a bi-weekly cadence C SOW 1.2 Project Management Review (PMR) As needed to be directed by

COR

D SOW 1.2,

2.5 Technical Interchange Meeting (TIM) As needed, as directed by COR or Contractor

E SOW 1.1

Presentation Materials

Five (5) days prior to PAC, PMRs, TIMs, or other major meetings

F SOW 1.1

Meeting Minutes Two (2) days after PAC, Status

Calls, PMRs, TIMs, or other major meetings

Base Period

1 SOW 1.4,

1.5, 2.2, 2.3

System Development Preliminary Design Review (PDR) Three (3) months after award

2 SOW 1.4,

1.5, 2.3, 2.6

System Development Critical Design Review (CDR) Six (6) months after award

3 SOW 1.5,

2.4, 2.6, 2.10

Initial Test Readiness Notification (TRN) 1st TSL Submission for CRT

4 SOW 2.7 Initial Technical Report One after 1st TSL Evaluation

5 SOW 1.5,

2.4, 2.6, 2.10

Final TRN 2nd TSL Submission for CRT

6 SOW 2.7 Final Technical Report One after 2nd TSL Evaluation Option Period One

7 SOW 1.4,

1.5, 2.2, 2.3

System Development Preliminary Design Review (PDR)

Three (3) months after start of option period one

8 SOW 1.4,

1.5, 2.3, 2.6

System Development Critical Design Review (CDR)

Six (6) months after award of option period one

9 SOW 1.4,

1.5, 2.3, 2.6, 2.10

Transportation Security Laboratory (TSL) Submission- Test Readiness

Review (TRR) 1st TSL Submission for CRT

10 SOW 2.7 Initial Technical Report One after 1st TSIF Evaluation

11 SOW 1.4,

1.5, 2.3, 2.6, 2.10

Transportation Security Laboratory (TSL) Submission- Test Readiness

Review (TRR) 2nd TSL Submission for CRT

12 SOW 2.7 Final Technical Report One after 2nd TSIF Evaluation Option Period Two

13 SOW 1.4,

1.5, 2.2, 2.3

System Development Preliminary Design Review (PDR)

Three (3) months after start of option period one

14 SOW 1.4,

1.5, 2.3, 2.6

System Development Critical Design Review (CDR)

Six (6) months after award of option period one

15 SOW 1.4,

1.5, 2.3, 2.6, 2.10

Transportation Security Laboratory (TSL) Submission- Test Readiness

Review (TRR) 1st TSL Submission for CRT

16 SOW 2.7 Initial Technical Report One after 1st Airport Pilot Study

17 SOW 1.4,

1.5, 2.3, 2.6, 2.10

Transportation Security Laboratory (TSL) Submission- Test Readiness

Review (TRR) 2nd TSL Submission for CRT

18 SOW 2.7 Final Technical Report One after 1st Airport Pilot Study

Deliverables to be complete for the desired capability development/identification technology to be evaluated against target materials of interest outlined in the TSA Accessible Property Screening System (APSS) v6.2a at the Transportation Security Laboratory (TSL) once CDR requirements are TSA approved.

---End of Statement of Work---

Detection Capability and System Functionality

TSA is interested in AR solutions that can identify Stream of Commerce (SOC) and threat materials alarmed on primary screening TSE. AR capabilities and systems need to meet critical detection and identification requirements. For the solution to be successful, TSA is interested in AR solutions that can achieve the following by the end of the third year:

• Clear all threats detectable by primary screening.

• Detect/Confirm all threats (or suspected items) detected by the primary screening device.

o Detect all explosive and chemical threats identified in primary screening.

o Detect and identify alarmed items in containers or concealments that do not allow access for sampling.

The threshold capability shall be to analyze materials through clear, translucent, amber, and different color containers of glass. The objective capability shall be able to analyze materials through opaque plastic and glass, ceramic, metal, and cardboard containers.

o Increase the number or percentage of alarms resolved for SOC powders, solids, and oversized Liquid, Aerosol, and Gel (LAG) without the need for AAR.

o Increase the number or percentage of alarms resolved for benign items (i.e., benign items commonly suspected by the primary screening device) without the need for AAR.

• Reduce the average number of decisions, processes, and TSE required for AR.

• Ability to update the hardware of the system to conform to TSA requirements for outer and interior screening compartment sizes and weight which will be provided as Government Furnished Information (GFI).

• Ability to update the software and user interface to conform with TSA requirements regarding threat libraries and usability functions which will be provided as GFI.

• In addition to through-barrier analysis, the system shall have an additional mode to analyze SOC and threat items by taking small bulk samples. Sampling shall be no more than two (2) grams, and the system shall come with easy to use sampling tools.

• The system shall support positive identification of threats and/or benign items for improved resolution (e.g., presenting a bottle of lotion within the normal associated container as a “green” cleared item and/or enhancing positive identification of the system indicating the substance matches known lotion properties in the system’s database).

DHS and TSA Enterprise Architecture Compliance

TSA is interested in AR solutions that can function in an interoperable and networked environment with the ability to align and be compliant with current DHS and TSA Enterprise Architecture and the Federal Enterprise Architecture Framework requirements. AR capabilities and systems need to meet current Information Technology (IT) security requirements.

For the solution to be successful, TSA is interested in AR solutions that can achieve the following by the end of the third year:

• All solutions and services shall meet DHS and TSA Enterprise Architecture policies, standards, and procedures.

• All…