Amendment 01_Attachment 02_Attachment A_BAA 70T04023BAA7573N001.pdf
PDF 509 KB Posted
- Attached to
- On-Person Screening Broad Agency Announcement
- Solicitation number
- 70T04023BAA7573N001
About this file
This document is an attachment to a Broad Agency Announcement issued by the Transportation Security Administration seeking concept papers and proposals to develop On-Person Screening capabilities across five Technical Task Areas. Offerors are invited to submit concept papers by July 24, 2023 for consideration under two submission tracks. Track 1 involves walk-through screening systems, detection algorithms, synthetic data tools, and open architecture integration. Track 2 focuses on wideband technology to enhance advanced imaging systems. Full proposals will be requested from Track 1 concept papers selected for funding consideration. Track 2 selections will execute bailment agreements to test proposed solutions. Awards are expected by August and September 2023. The attachment provides detailed requirements for concept papers and proposals, including factors for technical and cost evaluations. It outlines deliverables, milestones and performance periods for resultant contracts or agreements.
View the file
Other files
Show all 11
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Transportation Security Administration Requirements and Capabilities Analysis Attachment A- OPS BAA 70T04023BAA7573N001
On-Person Screening Broad Agency Announcement (BAA)
70T04023BAA7573N001
Section A: General Information
A.1 Introduction This announcement is being made to support the Transportation Security Administration (TSA), Requirements and Capabilities Analysis (RCA), Capabilities Management and Innovation Division (CM&I) to open a BAA 70T04023BAA7573N001. The TSA RCA is interested in receiving concept papers for development projects that support the TSA mission of ensuring the safety and freedom of movement for people and commerce. To achieve its mission, the TSA seeks development opportunities across targeted strategic areas related to On-Person Screening (OPS) processes for potential advancement and improvement to strengthen the agency’s ability to respond to shifting adversarial threats, detect emerging and evolving threats concealed on-person, and enable efficient and effective targeting of screening resources. The TSA is specifically interested in development that will provide for near term improvement of current security operations and capabilities, as aligned with RCA’s OPS Roadmap, by addressing several Technical Topic Areas (TTAs) in two submission tracks as shown below and further defined in Section B.
OPS
Track 01
TTA- 01, Walk-Through Metallic and Non-Metallic Screening Systems TTA- 02, Detection Algorithms that Support In-Motion Screening TTA- 03, Synthetic Data Generation and/or Automated Data Annotation Tools TTA- 04, OPS Open Architecture Integration
Track 02
TTA- 05, Wideband Technology that Enhances Currently Fielded Advanced Imaging Technology (AIT)
This document supports a BAA as contemplated under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016. Contracts and/or Agreements based on responses to this BAA are considered to be the result of full and open competition and in full compliance with the provisions of Public Law (PL) 98-369, “The Competition in Contracting Act of 1984.”
TSA will not issue paper copies of this announcement. TSA reserves the right to select for award and fund all, some, or none of the submissions received in response to this Window. TSA will not provide funding or reimbursement for proposal development costs. Full submissions or any other material submitted in response to this BAA will not be returned. All submissions shall be unclassified.
The TSA is soliciting concept papers which will be evaluated in accordance with this BAA and if selected by the applicable TSA RCA Capability Manager (CM), will be submitted for consideration on the TSA RCA spend plan for the current fiscal year. If funding is provided on the spend plan, the TSA Contracting Officer (CO) will request a full proposal from the offeror; if that full proposal is found acceptable to RCA’s needs, the CO may initiate negotiations for a contract award or execute a bailment agreement to test solutions as discussed in the following sections.
Offerors who submit concept papers that have no direct application to the TTAs listed in this BAA will be declined. Concept papers must present a coherent concept/detailed plan for accomplishing the objectives of the RCA OPS mission to continue to the final review and potential contract award.
A.2 Additional BAA Instructions
Work funded under a BAA may include applied research, advanced technology development, prototyping, pilot demonstrations, and testing. FAR Part 35 restricts the use of funding in cases such as this to the acquisition of basic and applied research and that portion of advanced technology development not related to the development of a specific system or hardware procurement. Procurement instruments awarded under this BAA are strictly for those purposes;
directed towards advancing the state of the art and increasing knowledge or understanding related to transportation security. Specifically, this BAA is not for the acquisition of technical, engineering, and other types of support services, nor is it for the acquisition of development or production of specific programs or objectives. The TSA will not accept or consider submissions of concept papers that are similar to or identical to the TSA’s or the Department of Homeland Security Science & Technology (DHS S&T) Directorate’s on-going/completed efforts, or on-going/planned acquisitions. The TSA reserves the right to decline submissions that were previously proposed to the TSA or to DHS S&T and declined. The TSA reserves the right to decline submissions to the BAA if the submissions are identical to submissions currently undergoing evaluation by the TSA or DHS S&T. TSA works very closely with DHS S&T and other federal agencies on matters of research and development.
Technologies that have attained a Technology Readiness Level (TRL) 5 or higher component and/or breadboard validation in a relevant environment is the minimum scope of the BAA.
Submissions without a clear path to practical TSA applications within 12 to 18 months will be declined. In addition, submissions whose sole purpose is to request an evaluation of a product (both new and old) will not be considered for award under this BAA. TSA will accept concept papers containing commercial services and items as long as the proposed concepts are consistent with the development opportunity description found within this BAA.
The TSA is seeking to accelerate the design, realization and delivery of new capabilities to the field. Concept papers that align closely with the strategic direction, investment priorities and details of this BAA will have a higher likelihood of being selected.
The TSA reserves the right to reject submissions that meet the objectives of the RCA OPS roadmap and/or mission covered by this BAA, but do not meet current TSA mission needs as determined by the TSA or whose estimated cost exceeds current budget constraints.
Section B: BAA Objectives
B.1 Background B.1.1 OPS Requirements (Tracks 01 – 02) TSA must ensure that its security screening checkpoints are both effective and efficient. A critical aspect of checkpoint screening is making sure that all individuals seeking entry to the airport sterile area are screened for person-borne threats to aviation. These include explosives, non-explosive prohibited items, and chemical, biological, radiological, and nuclear (CBRN) threats.
TSA is continuously evaluating and modernizing the OPS processes to strengthen the agency’s ability to respond to shifting adversarial threats, detect emerging and evolving threats concealed on-person, and enable efficient and effective targeting of screening resources. The Aviation and Transportation Security Act of 2001 directs TSA to screen all passengers and property that will be carried aboard a passenger aircraft. Accordingly, TSA recognizes two categories of individuals under the Screen People mission area. They are:
• Travelers/Non-Traveling Individuals are those who are screened at a TSA security checkpoint for items not permitted aboard a passenger aircraft. Travelers are defined as boarding pass holders and working crew members authorized to enter the sterile area to travel on a passenger aircraft and listed on the flight manifest. A Non-Traveling Individual is an individual to whom a covered aircraft operator seeks to issue an authorization to enter the sterile area of an airport for a purpose permitted by the TSA, such as to escort a minor or a passenger with disabilities.
• Aviation Workers are defined as employees, contractors, or representatives of an airport, domestic or foreign airline, concessionaire, tenant, government agency (Federal, State, local, or tribal), entity in the air cargo supply chain, or other entity working or operating at an airport regulated under 49 Code of Federal Regulations (CFR) part 1542. An Aviation Worker may be required to pass through a TSA screening checkpoint or may be permitted to use another sterile area entry point subject to Aviation Worker screening standards, depending on the airport operator’s security plan and access privileges granted to the individual.
TSA’s OPS activities are focused on improving, acquiring, and deploying capabilities and technologies to enhance the operational efficiency and security effectiveness of on-person screening. TSA’s current primary solutions for on-person screening utilize Advanced Imaging Technology units (AITs) and Walk Through Metal Detectors (WTMDs).
Currently, to meet TSA’s screening objectives, both OPS screening systems require divestiture of a person’s outerwear prior to being screened. Similarly, when an individual triggers an alarm during screening, a pat-down typically is required to resolve the alarm, which is uncomfortable to many individuals. Both the divestiture of a person’s outerwear and pat-downs for alarm resolution increase the time required to screen passengers and often increase passenger wait times.
RCA’s role in TSA’s acquisition of transportation security equipment (TSE), such as AIT and WTMD units, includes identifying needs, defining user objectives, analyzing alternatives, and demonstrating new capabilities/solutions. Technology solutions borne from these activities may be procured by the Government or obtained by other aviation stakeholders. This approach requires an architecture and solution set that is flexible and involves significant work in the areas of objectives definition, policy development, test and evaluation, and compliance. The potential technology solutions defined, evaluated, and planned with the support defined in this BAA must at minimum:
• Align to ongoing plans for integrating checkpoint OPS systems with other checkpoint systems
• Maintain the checkpoint’s robust cybersecurity posture
• Promote connectivity, modularity, and open architecture to support enhancements (e.g., 3rd party algorithms, common interfaces, standardized data formats, etc.)
• Improve the security effectiveness of OPS
• Reduce manpower requirements at the checkpoint
• Accelerate the OPS process timeline for passengers
B.2 Opportunity Description In a diverse and rapidly evolving threat environment, TSA’s security effectiveness strategies must achieve maximum future-state efficiency. To enable this mission objective, TSA and the CM for OPS are looking to establish the next generation of OPS solutions with a focus on moving passengers through the checkpoint in a continuous manner, enhancing threat detection capabilities with reduced false alarm rates, installing display image standardization, and enabling operational connectivity through secure data transmission. With these objectives, TSA OPS will advance the checkpoint towards a future state of continuous screening, improving threat detection, and ensuring compatibility across screening checkpoints.
The following sections sets forth the objectives for various specific tasks related to enhancing OPS capabilities. The identified tasks for the objectives presented herein have a direct impact on meeting the objectives outlined in the Aviation and Transportation Security Act of 2001, PL 107-
71. The TSA seeks to mature threat detection technology and deliver aviation security checkpoint screening equipment and solutions that may be acquired by subsequent TSA programs.
To achieve these goals, TSA has defined the five TTAs listed in Section A1 and described in detail in the following sections. Concept papers must address at least one of these TTAs for consideration and evaluation.
B.3 TTA Objectives
B.3.1 Track 01 Objectives
B.3.1.1 Walk-Through Metallic and Non-Metallic Screening Systems (TTA 01)
TSA is pursuing screening systems that allow for a passenger to be screened without the requirement to stop walking or pose. Desired systems should include but are not necessarily limited to:
• A small footprint that has minimal impact on the screening or checkpoint design
• Economical alternative to a WTMD
• Throughput numbers similar to a WTMD
• Both metallic and non-metallic detection that utilize non-ionizing portion of the electromagnetic (EM) spectrum or non-EM technologies that enable non-contact passenger screening if there are no alarms
• The ability to detect un-divested items at performance levels determined by TSA
• The capability to allow minimum divestiture requirements such as non-divesture of:
o Light to medium outerwear and headwear o Low threat items such as keys, wallets, and small personal items.
• For avatar-based systems, providing improved identification of the alarm location to support TSO resolution via o Material discrimination o Integration of video cameras to assist TSO in visually matching alarm location
B.3.1.2 Detection Algorithms that Support In-Motion Screening (TTA 02)
TSA is developing Automatic Target Recognition (ATR) algorithms that will support TSA’s next-generation on-person screening technologies such as in-motion Millimeter Wave (MMW) systems.
Due to the inherent challenges of in-motion detection, algorithms will need to ensure there is no loss in threat detection while also meeting the detection performance levels determined by TSA.
This will allow TSA to make significant progress on screening at speed priorities that will produce increased throughput rates at the checkpoint, thus improving both the passenger and TSO experiences.
Methods to enhance detection performance may include, but are not limited to:
• Developing/improving machine learning algorithms
• Screening options that utilize non-ionizing portion of the EM spectrum or non-EM technologies
Desired threshold and objective end-states are provided below:
• Systems that achieve threshold performance will have the ability to detect the full list of threats, per detection standards, and be able to classify targets as metallic or non-metallic objects
• Systems that achieve objective performance will have the ability to identify additional material categories for targets, including but not limited to, ceramics, plastics, paper, leather, carbon fiber, and potential explosive material in accordance with the latest detection standard.
B.3.1.3 Synthetic Data Generation and/or Automated Data Annotation Tools (TTA 03)
TSA is seeking to leverage vendor solutions for synthetic image data generation and automated annotation tools to support and expedite the development and delivery of machine learning (ML) detection algorithms for future OPS systems. Because both quality and quantity of available data are major limiting factors for these algorithms, TSA is looking for efficient ways to annotate lab-collected real image data and annotate/generate large amounts of synthetic image data. These data will be used for training, validating, and testing ML-based detection algorithms.
The following should be considered:
• Proposed tools should enhance OPS detection algorithm training, validation, and/or testing capabilities.
• Data annotation tools should support keypoint detection (e.g., body joints, parts of the head), body region definition (e.g., arms, legs, torso), and target identification (e.g., gun).
• Synthetic data generation tools should be capable of altering the size, shape, and orientation/stance of individuals and various targets on them.
• Tools should be capable of generating and/or processing MMW OPS data for multiple capability types, including static 2D/3D images, in-motion walkthrough detection, and footwear screening.
• Solutions should be economical to the government.
B.3.1.4 OPS Open Architecture Integration (TTA 04)
TSA is seeking system integrators to support the implementation of checkpoint open architecture (OA) for OPS systems to enable modularity, reduce costs, expedite delivery of capabilities, and enhance security effectiveness. Through the Open Platform Software Library (OPSL), OPS imaging systems will be capable of integrating with ATR detection algorithms and viewing stations. System integration may include the following:
• Identification of software and hardware required for integrating OPSL-compliant systems for various checkpoint architectures.
• Support OSPL integration for OPS imaging systems, ATR algorithms, and viewing stations to meet applicable OPS requirements.
• Compliance with cybersecurity requirements.
• Integration with Security Technology Integrated Program (STIP).
B.3.2 Track 02 Objectives
B.3.2.1 Wideband Technology that Enhances Currently Fielded AIT Systems (TTA 05)
TSA is seeking solutions available to upgrade currently fielded AITs with wideband technology that provides enhanced images for improved screening. Desired upgrades should operate on an open architecture framework allowing for third party algorithms and user interfaces. The following capabilities should be considered:
• Enhancements that fit within the current chassis of fielded AIT systems.
• Upgrades that can be installed at location with minimal impact to the checkpoint.
• Upgrade installation time during off peak hours, usually overnight within 4 hours.
• Form, fit and function according to AIT program requirements.
• Compatibility with the OPSL.
• Operation without the use on non-ionizing radiation.
• FCC waiver approved or attainable.
• Economical to the government.
Operating in an open architecture setting relies on several entities to contribute to the overall performance of a system. While wideband enhancements alone will not increase performance without improved ATR and user interfaces, it is important to note that TSA seeks the following performance with a holistic system:
Table 1: Threshold Performance Criteria for Enhanced Detection & Throughput
Criteria Detection Standard1 Throughput (Minimum Average) Additional Criteria
Threshold 1 Level 2 150 passengers/hour -
Threshold 2 Level 1 150 passengers/hour No need to divest light outerwear2
Threshold 3 Level 1 360 passengers/hour -
• Systems that exceed threshold performance shall meet at least one of the objective criteria in Table 2.
Table 2: Objective Performance Criteria for Enhanced Detection & Throughput
Criteria Detection Standard Throughput (Minimum Average) Additional Criteria
Objective 1 Level 3 150 passengers/hour -
Objective 2 Level 2 150 passengers/hour No need to divest light outerwear
Objective 3 Level 2 360 passengers/hour -
B.4 Project Management and Support (Applicable to Track 01)
B.4.1 Project Management and Support
TSA is not providing a separate monetary award for Project Management and Support. The Project Management and Support is considered as Not Separately Priced (NSP); if a concept paper is selected and a proposal is requested as a result of this BAA as outlined in Section C, the Contractor will be required include the elements outlined below in sections B.4.1.1 through B.4.1.6 to perform project support activities and complete deliverables to enable project progress and milestone achievements. The Contractor shall maintain the formal organization to continue the project support and management to efficiently and effectively execute the objectives outlined in sections B.4.1.1 through B.4.1.6.
1 TSA will provide technical guidance and data, as appropriate, to vendors who do not have the ability to access current detection standards.
2 Light outerwear refers to headwear (e.g., hats) and light coats or jackets (e.g., windbreakers).
B.4.1.1 Post-Award Conference A post-award conference will be conducted at a site specified by the Government 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 agenda and the Contractor shall provide the draft minutes for the conference for TSA review and approval within 2 days after the conference.
During the post-award conference, the Contractor shall be prepared to address, at a minimum, a review and status of the following topics:
• Overview of the deliverable submissions status
• Invoicing procedures
• Project schedule with milestones
• Organizational status
• Cost, schedule, and performance (technical) aspects of the SOW
• Subcontractor’s technical progress on all assigned tasks (if applicable)
• Lines of communication
B.4.1.2 Status Tracking and Reporting The Contractor shall be responsible for project management throughout the entire project period of performance. The Contractor shall provide all labor, materials, planning, managing, and the 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 Project Manager who shall be the Contractor’s focal point for all required security technology related 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 TSA covering all technical aspects of the project. These meetings will occur mostly via teleconference; however, they can be in person at a location as directed by the Government CO or Contracting Officer’s Representative (COR).
If required, the Contractor will support Project Management Reviews (PMRs) where the project status is discussed in depth, and further discussion can take place on 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 and obtaining all required and necessary badges/permissions needed to accomplish installation requirements throughout all associated project phases and for all required labor personnel.
B.4.1.3 Project Risk Management The Contractor shall identify cost, schedule, and technical risks and describe how it will effectively manage these risks throughout the period of performance of this SOW.
The Contractor shall develop and maintain a list identifying, analyzing, classifying, and prioritizing project risks and a recommended course of action to address those risks. Project risks shall be classified as low, medium, or high priority and include supplier risks. The Contractor shall conduct risk mitigation and contingency planning for risks considered medium or high priority.
The Contractor shall quantify risks with respect to their impact on integration, installation, design, performance, technical parameters, schedule, cost, manufacturing, and maintainability of existing prototype fleet. Risks will be included on the status reports and regularly updated and discussed in detail with the CO or COR at least once per quarter.
B.4.1.4 General Test and Evaluation Support In support of any Contractor’s internal testing and Government laboratory and field 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 the COR.
The Contractor shall maintain a single point of contact (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 technical meetings. Additionally, this single 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:
• Provide the necessary test equipment and ensure its availability, proper calibration, fully operational status, and operation as documented by the test equipment manufacturer.
• Obtain prior written approval from the Government before using unique or modified commercial test equipment not specified in the approved test plans and procedures.
• Provide the Government, if asked, with the proof of proper calibration of test equipment provided by the Contractor.
• Conduct, or support the Government in conducting, a Test Readiness Notification (TRN) and Test Readiness Review (TRR) prior to performing any formal test.
• 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.
• 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 Contractor-conducted test.
The Contractor shall 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 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 prior to the conduct of 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 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. The Contractor shall conduct a TRR and submit the TRN to the Government and designated Government representative at least ten (10) business days prior to the conduct of each formal test. The Contractor shall submit these documents via email to the Government COR and any other representative as designated by the
CO.
If requested by the Government, a Verification Requirements Traceability Matrix (VRTM) shall be included in a 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 Government-conducted test events at Government test facilities (such as the Transportation Security Laboratory (TSL)) 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 the integration testing or conducting integration Site Acceptance Testing (iSAT) for capabilities developed and deployed under this SOW such as automated screening lanes or networking. The Government will conduct laboratory testing and/or an Operational Demonstration on OPS systems 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 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 configuration management activities as required
• Assist with all data collection, including interpretation/analysis of Field Data Reporting System (FDRS) data
The Contractor shall provide a schedule outlining the following milestones and deliverables to support general T&E activities as listed below:
• Kickoff Review and Schedule
• Test Plan
• Test Readiness Review
• Preliminary Design Review (PDR)
• Critical Design Review (CDR)
• System Design Document
• Close Out Presentation / Stage Gate – Determine Execution of Option Year, if applicable
• Final Technical Report
The scope 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, test results, and other design documentation).
The Government reserves the right to witness all Contractor-conducted test activities. The Contractor(s) shall provide the Government written notice at least 10 business day prior to conducting testing.
B.4.1.5 Configuration Management
The Contractor is responsible for meeting configuration control requirements as documented under TSA’s Configuration Management Guidance Version 2 (Attachment 3) and as applicable to the developmental systems and environments in accordance with this SOW. The Contractor is required to maintain its Configuration Management Program established under this contract and to manage the configuration baselines established for all equipment purchased.
The outline below provides key terminologies to establish common understandings for specific TSA Configuration Management artifacts:
• CSAR - The Configuration Status Accounting Report (CSAR) 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 (MCIL) 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 (DEP) describes a proposed (prior to manufacture) departure from configuration documentation for a specific number of units or for a specified period of time. A DEP enables the Government to determine the impact on performance, operational readiness, logistics support or other affected areas.
• ECP - An Engineering Change Proposal (ECP) includes both the 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 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
The Contractor shall retain all documentation for identification, control and status accounting of any 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.
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 shall be 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 equipment purchased under this contract, as needed.
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 successful completion of each FCA. The PCA shall verify system physical performance requirements.
B.4.1.6 Project Management and Support Deliverables Table 3 outlines expected milestones and deliverables for the Project Management and Support
TTA.
Table 3: Milestones and Deliverables for Project Management and Support TTA # Deliverable Frequency of Delivery
3.4.1.1 Post Award Conference (PAC) and Materials One, within ten (10) days after award
3.4.1.2 Status Calls and Reporting Materials Recurring on a bi-weekly cadence
3.4.1.2 Project Management Review (PMR) As needed to be directed by CO and COR
3.4.1.2 Technical Interchange Meeting (TIM) As needed to be directed by CO and COR
3.4.1.2 Presentation Materials Five (5) days prior to PAC, PMRs, TIMs, or other major meetings
3.4.1.2 Meeting Minutes Two (2) days after PAC, Status Calls, PMRs, TIMs, or other major meetings
3.4.1.3 Risk Reports Recurring on a bi-weekly cadence
3.4.1.4 Test and Evaluation Schedule Recurring on a bi-weekly cadence
3.4.1.4 Test Readiness Notification (TRN) Recurring based on testing
3.4.1.4 Test Readiness Review (TRR) Recurring based on testing
3.4.1.4 Preliminary Design Review (PDR) Three (3) months after reward
3.4.1.4 Critical Design Review (CDR) Six (6) months after reward
3.4.1.4 System Design Document One, within two (2) weeks of contract closeout
3.4.1.4 Final/Annual Technical Report One, annually
B.5 Cybersecurity and Network Compliance (Applicable to all Tracks) TSA is interested in OPS 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. OPS capabilities and systems need to meet current TSA Information Technology (IT) security requirements.
TSA is interested in OPS concepts that can achieve the following:
• Support networked "reach back" to TSOs in the field.
• Achieve compliance with current cybersecurity standards in accordance with requirements.
For example, does the proposed solution:
o Meet the 17 pillars of cybersecurity https://sam.gov/opp/fdc87793ced04442b8a34cd6a913749f/view o Incorporate cybersecurity measures to discriminate access-levels of the operators.
o Allow tracking of operator log-ins/decisions.
https://sam.gov/opp/fdc87793ced04442b8a34cd6a913749f/view
Section C: Submission Information
C.1 Submission and Award Information
C.1.1 Award Timeline
The following is a tentative award schedule for submission in FY23. Review the Sam.gov announcement site for updates.
Activity Date Announcement Released 6/28/2023 Questions Due 7/10/2023 Concept Paper Submissions Due 7/24/2023 Questions to Vendors (If Applicable) 7/26/2023 Full Proposal Submissions* 8/24/2023 Estimate Bailment Agreement Award** 8/10/2023 Estimate Contract Award* 9/26/2023
* Applicable to Track 01.
** Applicable to Track 02.
C.1.2 Questions
All questions for this BAA must be electronically submitted to the BAA Point of Contact (POC) at OPSinfo@tsa.dhs.gov and the Contracting Officer at Megan.Kesler@tsa.dhs.gov, referencing the BAA number, title, and company name “OPS TBAA 70T04023BAA7573N001 [company]” no later than 12:00pm Eastern Time on July 10 , 2023. All communications shall be submitted via e-mail. Do not include any classified material or Sensitive Security Information (SSI) as defined in 49 CFR 1520. If Offerors must ask questions that contain classified material or SSI, please notify the BAA POC and additional instructions will be provided.
Answers to contractual questions related to this BAA will be addressed in the form of an Amendment and will be posted to the System for Award Management (SAM) webpage at https://www.Sam.gov. Answers to technical questions will be provided solely to the requester.
C.1.3 Submission Process
• Submission Window o There will be two concept paper submission cut off dates: 1) The FY23 cut off for both tracks is July 24, 2023 at 2:00pm Eastern Time . 2) The FY24 cut off for Track 01 is January 15, 2024 at 2:00pm Eastern Time . TSA is not accepting submissions for Track 02 in FY24.
• Feasibility o Technical evaluators review concept papers and may provide questions to
Offeror(s) for further clarification. The technical evaluators will select submissions for the RCA CMs to consider with the fiscal year’s Spend Plan.
mailto:Megan.Kesler@tsa.dhs.gov https://www.sam.gov/ o If selected for funding for Track 01, the Offeror will be invited via email to submit a full proposal and begin contract negotiations with Contracting and Procurement. The full proposal due date and submission instructions will be specified in the email.
o If selected for concept Track 02, the Offeror will be required to bail their solution to the Government at no cost to support TSA testing. Bailment Agreements will be executed upon selection and bailed solutions shall be delivered to TSA within 90 days of agreement execution. One bailed solution will be required within 90 days after award and if initial testing is successful an additional two units will be required 180 days after award. Vendors that successfully meet TSA’s testing requirements will receive a letter stating that they have met testing requirements and will be eligible to compete for future requirements to field this technology.
C.2 Submission Instructions All concept paper submissions shall be sent electronically to the following email address OPSinfo@tsa.dhs.gov and the Contracting Officer at Megan.Kesler@tsa.dhs.gov no later than 2:00pm Eastern Time on July 24, 2023. All concept paper submissions shall have a subject line of the email that reads “OPS-BAA 70T04023B7573N001 Concept Paper” and includes the TTA, company name and a short title of the concept.
Due to TSA restrictions on the size of email, ensure that all emails submitted are less than 5MB. If the submission exceeds 5MB, please divide into multiple emails and include in the subject line the announcement number and # of # emails. All submissions must be in adobe pdf or Microsoft formats; links to documents on a cloud platform will not be accepted by TSA and TSA may not further consider such submission for consideration.
Offerors shall be solely responsible for knowing the limitations of their internet service provider. Offerors are encouraged to compress (e.g., zip) or separate large files into a number of smaller files and, if necessary, submit them within multiple emails. Offerors may not submit proposals on CD-ROM or other electronic media. Offers submitted via facsimile or in hard copy format will not be considered.
Prior to any evaluation, the TSA will check all files for viruses and ensure that all information is readable. In the event any files are defective (unreadable), the TSA may only evaluate the readable electronic files. However, if the defective (unreadable) media renders a significant deficiency in the Offeror’s submission, the TSA may consider the submission incomplete and may not further consider such submission for consideration.
The TSA will not award contracts on the basis of concept papers alone, and unsolicited full proposals will be rejected. Following an evaluation of submitted concept papers, the TSA may select Offerors responding to Track 01, to submit a full proposal and enter negotiations for a contract award as outlined above. For Track 02, the TSA may select Offerors to execute bailments agreements to test their proposed solutions.
mailto:OPSinfo@tsa.dhs.gov mailto:Megan.Kesler@tsa.dhs.gov
Offers submitted under the BAA are expected to be unclassified. Proposal submissions will be protected from unauthorized disclosure in accordance with FAR 15.207 and applicable law/regulations. Offerors are expected to appropriately mark each page of their submission that contains proprietary information.
Offerors shall use a consistent title throughout the document which is descriptive of the work they cover and not be merely a copy of the title of this announcement.
Concept papers must be in Adobe or Microsoft Word format (2007 or later); full proposals must be in Adobe or Microsoft Office formats (2007 or later), e.g., Word, Excel, PowerPoint, Project, etc.
All cost data shall be placed in Microsoft Excel (2007 or later) with formulas preserved. All concept papers and proposals shall be prepared to print on letter-sized paper (8 ½ inch x 11 inch), double-spaced, text only with foldouts as required. Each Offeror shall utilize Times New Roman 12-point font. Reduction may be used only for tables and figures and relevant captions. Margins shall not be less than one-inch at top, bottom and sides, excluding page number “Page X of Y Pages” numbering, the proposed title of the project, the Offeror’s name, and submission date in the footer of each page shall be used. All pages shall be sequentially numbered with no gaps, breaks, or sub-page numbers/letters.
Offers shall not exceed the specified page limitations stated below (cover letter and table of contents/proposal checklists will not be counted toward the specified page limits). The TSA reserves the right to not consider any pages in excess of the limitation for evaluation purposes.
Offerors are also advised that the use of promotional material and/or brochures will not constitute compliance with the objectives concerning the content of responses.
C.3 Content and Format of Offers
The table below and the sections that follow identify the contents of each volume. Concept papers, oral presentations and full proposals shall not contain or discuss Sensitive Security Information
(SSI).
Volume Contents Page Limits Concept Paper Elements defined in Section C.3.1
Factor 1- Entrance Criteria
Full Proposals* Elements defined in Section C.3.2
Factor 2- Technical Approach Factor 3- Past Performance Factor 4- Price or Cost Other Submission Information
See Section C.3.2
*Applicable to Track 01.
C.3.1 Concept Paper Submission Content (All Tracks)
Factor 1- Entrance Criteria: The Offeror shall present the following information in Sections A and B below to facilitate the Government’s consideration of Factor 1 for all submission Tracks.
A. Page Limits – The concept paper shall be a single document limited to 15 pages as follows:
Section Subsections Page Limit
1 Cover Letter 1 page
2 Table of Contents 1 page – Optional
3 Technical Concept 7 pages
Relevance to the TSA’s BAA TTA objective(s) and Mission + Operational Utility Assessment Plan (see description below)
6 pages (combined for sections
4-6)
List of Tasks + List of Deliverables +
Expected TSA Support + Key Dates/Milestones + Estimated Costs+ Intellectual Property
(IP)/Data Rights 6 Capabilities/Related Experience
B. Content Requirements:
1. Offers Shall Include a Cover Letter: The Cover letter shall be labeled
“CONCEPT PAPER” and shall include the BAA number “70T04023BAA7573, proposed title, points of contact, address, telephone number, facsimile number, e-mail address, corporate Unique Entity Identifier (UEI) number, Commercial and Government Entity (CAGE) Code, Taxpayer Identification Number (ID) number, certifications required at FAR 52.209-5, and the period of performance of the project. The Cover letter must also include the name and contact information for the individual authorized to negotiate and contractually obligate on behalf of the Offeror. Inclusion of a table of contents and/or proposal checklists that index proposal features as compared with BAA objectives are optional. The certifications required at FAR 52.209-5 may be submitted as an Attachment to the Cover letter.
2. Technical Concept: A description of the innovation, maturity of the concept/technology, technical risk areas, and proposed mitigation. The description should include the project objectives, the concept of operation for the new concepts to be delivered, and the expected operational performance improvements. The description should also include an estimation of the applicable system specifications (e.g., weight, dimensions, probability of detection, probability of false alarm, throughput), limitations of selected technology, a life-cycle cost estimate for the system, applicable system specifications (e.g., weight, dimensions, probability of detection, probability of false alarm, throughput) as well as other operational performance expectations, including reliability and operational availability, if applicable, a declaration of the current Technology Readiness Level (TRL) of the technology and also of the projected TRL of the technology at the end of the proposed period of performance, with a brief supporting statement for each, regarding the current state of the proposed concept and where it will be after the work is completed.
3. Relevance to TSA’s BAA TTA Objective(s) and Mission: A description of potential transportation security relevance and contributions of the effort to the agency’s specific BAA TTA objective(s). A discussion of how this innovation meets the TSA’s mission needs must be included.
4. Operational Utility Assessment Plan: A plan for demonstrating and evaluating the operational effectiveness of the Offeror’s proposed products or processes in field experiments and/or tests in a simulated environment. This would be a description of how the solution can be proven or tested to demonstrate effectiveness.
5. List of Tasks*: A description of specific tasks that would need to be accomplished in order to deliver the proposed capability.
6. List of Deliverables*: A list of items that will become TSA property (e.g., prototypes, reports, test objects, consumables, etc.).
7. Expected TSA Support*: A list of all tasks proposed in the contract that will need the TSA’s support to complete (e.g., Access to Sensitive Security Information or Classified Information, Food and Drug Administration [FDA]/ National Institute of Standards and Technology [NIST] safety testing, TSL/TSA Systems Integration Facility [TSIF]/Operational testing, etc.). The Offeror needs to list these tasks, identify the type of support needed with a justification, and include the associated costs in the estimated cost.
8. Key Dates/Milestones: A list of key dates from contract award through task completion.
9. Estimated Cost: A description of the funding required to perform the tasks being proposed and to further develop and explore the proposed concepts.
10. Capabilities/Related Experience: A brief description of similar work performed or qualifications related to the proposed solution.
11. Intellectual Property (IP)/Data Rights: A summary of the intellectual property and data rights asserted.
*Not Applicable to Track 02.
C.3.2 Content and Format of Full Proposals – Track 01
Offerors who submit the required concept paper elements defined in C.3.1 above and are found “Acceptable” for Factor 1, will be invited via email to provide a full proposal addressing the elements set forth below.
* Please note that the cover letter, technical proposal, subcontracting plan, detailed past experience information, and full price proposal will not be required if the concept paper is not selected to move to the award phase. TSA may make changes to the content of the proposed concept in the final SOW issued by the TSA, to reflect the complete requirements associated with the proposed concept. TSA reserves the right to partially fund a concept or incorporate option periods.
The anticipated format when submitting a full proposal is as follows:
A. Page Limits – Each volume of a full proposal shall be a separate document.
I. Cover Volume
Section Page Limit
1. Cover Letter 1 page
2. Proposal Checklist No page limit – Optional
The Cover Page must include the words “Business Volume” and the following:
1) BAA number
2) Title of volume
3) Identity of prime Offeror and complete list of subcontractors, if applicable
4) Technical contact (name, address, phone/fax, electronic mail address)
5) Administrative/business contact (name, address, phone/fax, electronic email address, DUNS, NAICS)
II. Technical Proposal Volume
1. Title Page 1 page
2. Table(s) of Contents No page limit – Optional
3. Table of Acronyms No page limit – Optional
4. Statement of Work (derived from the
Concept Paper) No page limit
5. Technical Approach and Justification 15 pages
6. Government Furnished Information and Equipment 2 pages
Section Page Limit
7. Relevance to TSA’s BAA TTA objective(s) and mission 2 pages
8. Operational Utility Assessment Plan 5 pages
9. List of TSA Support 1 page
10. Project Schedule and Milestones No page limit
11. Assertion of Data Rights and/or Rights in Computer Software (if any) No page limit
12. Deliverables / Reports No page limit
13. Management Approach 5 pages
14. Resumes No page limit
III. Past Performance Volume
2. Subcontracting Plan No page limit
3. Past Experience No page limit
IV. Cost Proposal Volume
2. Table of Contents No page limit – Optional
3. Cost Narrative No page limit
4. Price Assumptions No page limit
5. Cost Proposal Spreadsheet(s) No page limit
B. Technical Proposal Volume Content:
Factor 2 - Technical Approach: The…
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. Updated .