Attachment 2 - PWS for TraCSS Presentation Layer (08.01.24).pdf

Solicitation: 1305M424R0047 Version 11 Attachment 2 – PWS 07/18/2024

PERFORMANCE WORK STATEMENT

FOR PRESENTATION LAYER OF THE

TRAFFIC COORDINATION SYSTEM FOR SPACE (TraCSS)

Contents

1.0 Presentation Layer PWS Overview 3

1.1 Purpose 3

1.2 TraCSS Overview 3

1.3 TraCSS Phases and High-Level Interfaces 5

1.4 Presentation Layer Scope 6

1.5 Users 9

2.0 Presentation Layer Requirements 10

3.0 Development Approach 14

4.0 Log Data Service Requirements 15

5.0 Model-Based System Engineering Requirements 16

6.0 Security and User Management Requirements 16

7.0 Key Personnel 16

8.0 Other Applicable Conditions 17

9.0 Acronyms 20

10.0 References 22

Appendix A: TraCSS Phase 1 Capability Roll-out 23

Appendix E: Lessons Learned from the DoD Website Space-Track.org 30

1.0 Presentation Layer PWS Overview

Section 1 provides background on the scope, architecture, and planning for the Traffic Coordination System for Space to inform and provide additional context for the requirements in Section 2 and beyond.

1.1 Purpose

The National Oceanic and Atmospheric Administration (NOAA), Office of Space Commerce (OSC), requires a presentation layer (user interface and user experience) for the Traffic Coordination System for Space (TraCSS).

The Government seeks to leverage mature commercial capabilities for the TraCSS Presentation Layer (user interface), which consists of web-based graphical user interfaces (GUI) and a Data Products service to generate formatted human-readable data products (Figure 3). The Government also requires the Contractor to build the TraCSS website to present the GUIs and data products.

The GUI, Data Products, and website will utilize TraCSS Application Programming Interfaces (APIs) and Gateway Business Logic defined by the System Integrator to store and retrieve data.

The System Integrator services are procured through a separate procurement activity.

1.2 TraCSS Overview

The TraCSS is being developed to fulfill the 2018 U.S. National Space Council released Space Policy Directive-3 (SPD-3) to provide space traffic coordination safety services to space operators.

TraCSS is the Department of Commerce's (DOC) enterprise solution for ingesting, archiving, processing, and disseminating Space Situational Awareness (SSA) data and products. TraCSS will provide conjunction analysis and warning services to satellite owner/operators. The system will store data from the Department of Defense (DoD), NOAA, commercial SSA data providers, and commercial and civil satellite Owner/Operators (O/O). The TraCSS system will operate 24 hours per day, 7 days a week. An overview of the TraCSS is shown in Figure 1.

Figure 1: Overview of TraCSS (OV-1).

Figure 1 illustrates the TraCSS components from left to right, including: (a) Data Sources; (b) TraCSS-SKYLINE (SSA application services); (c) TraCSS-OASIS (data repository); and (d) TraCSS-HORIZON; and (e) TraCSS User Interface (Presentation Layer). TraCSS HORIZON is the computational environment where new applications and services may be developed and introduced into the TraCSS.

The Government’s initial focus will be on providing the TraCSS services to support the basic safety cycle, which includes importing data on space objects (satellites and space debris), performing quality checks on the data at ingest and every step of the processing cycle, and estimating if there are any close approaches.

TraCSS will be operated at an unclassified level and will not require storage or handling of any classified data. However, DoD data with CUI handling requirements will be ingested into the OASIS data repository. The DoD data will be processed through an ITAR rated software system, and the resulting products will not require any further special handling. The TraCSS system will be hosted on a GovCloud at a FISMA HIGH level, which is procured through a separate procurement activity.

1.3 TraCSS Phases and High-Level Interfaces

Figure 2: Phase 1 End State and High Level Data Interfaces.

The TraCSS system will be implemented in Phases. For Phase 1, the Government plans to implement on-orbit conjunction screening for the commercial community at an unclassified level.

Figure 2 illustrates the final Phase 1 instantiation which will be built up in increments, utilizing an Agile development approach, starting in Quarter 4 (Q4) Fiscal Year (FY) 2024. Appendix A outlines the Phase 1 capability execution plan.

An overview of the TraCSS system and the planned release schedule and roadmap for Phase 1 can be found on the OSC website at the following link: https://www.space.commerce.gov/july-28-update-on-tracss/.

The Presentation Layer capabilities are not expected to be available at Phase 1.0 being delivered in Q4 FY 2024, but are expected to be fully functional by Phase 1.4 in Q4 FY 2025.

As Figure 2 depicts, conjunction screening includes importing state vectors, owner/operator ephemerides and other data on resident space objects (RSOs; satellites and space debris), performing automated quality checks on the data, automatically generating ephemerides from state vectors, and automated conjunction analysis (CA) screening for any close approaches. If objects are predicted to pass close by each other (and potentially collide), automated conjunction data message (CDM) warnings are generated and auto-distributed to involved parties to allow O/O’s time to determine a course of action to mitigate the potential collision. For objects in a CDM that are not well-tracked, a Mission Planning capability may be used to task commercial providers to make additional observations and supply updated ephemerides that would be re-screened at the next scheduled conjunction analysis, or sooner if warranted.

https://www.space.commerce.gov/july-28-update-on-tracss/ https://www.space.commerce.gov/july-28-update-on-tracss/

Phase 2 addresses launch collision avoidance and transition to orbit. Phase 3 addresses the transition from orbit to re-entry and re-entry related topics. These future phases have not yet been defined and may be initiated during the presentation layer contract period of performance.

1.4 Presentation Layer Scope

The TraCSS notional architecture provides the foundation for defining the scope of the Presentation Layer Contractor expected responsibilities. Specifically, the Presentation Layer Contractor shall be responsible for the services and service layers highlighted in Figure 3 by green boxes (GUI and Data Products).

Figure 3: Notational Architecture with Presentation Layer Services

Specifically, the Presentation Layer services include:

● Web Graphical User Interface: This service is the Web user interface for human-readable displays and data.

o Includes the ability for TraCSS users to input/upload data to the system via a GUI.

o Includes GUI for requesting user accounts.

● Data Products: This service generates standard data products for users (e.g., PDFs) that may be downloaded from the Web GUI.

In addition, the contractor shall:

(1) support the System Integrator in integrating the presentation services with the TraCSS system including any applicable parts of the TraCSS architecture and services;

(2) follow processes and APIs developed by the System Integrator to access services and data that are necessary for presentation layer functionality;

(3) follow appropriate guidelines, set by the TraCSS program and implemented by the System Integrator, for security, scalability and continuity of operations; and

(4) work with users and user representatives to develop, manage, maintain, administer, and evolve the presentation services needed to support TraCSS space safety services, including operations support for 24/7 operations.

(5) design, develop, and maintain the TraCSS website which will host the presentation layer displays for the public and the web GUI for the TraCSS users.

(6) assist the government in migrating the current commercial and civil Space-Track.org community of users to the TraCSS website by the end of Q4FY25. Space-Track.org is the DoD website portal for input and distribution of SSA data and services.

The presentation layer Contractor and the System Integrator have separate responsibilities however are required to work together closely both in the development and operation of TraCSS. The main interactions between the Presentation Layer Contractor and the System Integrator, which are defined in sequence diagrams that will be available to the contractor, are highlighted in Table 1 below.

Table 1: Presentation Layer Vendor/SI Interface Division of Responsibilities

Service Presentation Layer Vendor Responsibility

System Integrator Responsibility

Gateway Business Logic Access service as required Develop and provide service

Data Policy/Rule Engine Use service to check data access controls (Role Based Access Control [RBAC] and Attribute Based Access Control [ABAC]) when responding to requests.

Develop and provide service

Log Data Service Use service to log invocations, transactions and events in GUI and Data Products.

Develop and provide service

Workflow Engine Design Presentation Services to use inversion of control so that the System Integrator can integrate these services with the Workflow Engine

Develop and provide service

Data Store/Retrieval Use only this service to store or access data

Develop and provide service

Data Pub/Sub Agent Message Publication responds to events generated by Data Pub/Sub Agent.

Develop and provide service

Web Graphical User Interface Develop and provide this service, including enabling users to input data to a GUI and register an account.

Integrate this service into the TraCSS platform.

Data Products Generation Develop and provide this service to generate standard products for users to download if desired

Integrate this service into the TraCSS platform.

TraCSS.gov website Design, build, maintain, evolve website

Manage and provide access to cloud infrastructure to host website.

The Contractor shall follow an Agile approach to developing the presentation layer to the maximum extent practicable. The contractor shall maintain presentation services and respond to bug reports and feature requests in support of operations.

1.5 Users

Data and services available on the TraCSS Presentation Layer will be based on user role and data attributes. This role-based access, which includes multi-factor authentication, manages access to the STC and SSA content through user groups, permissions, and credentials managed by the TraCSS System Integrator. Users will be required to establish accounts to access data and services beyond publicly available data. There are two distinct communities of users of the TraCSS Presentation Layer. The first set of users is the TraCSS operators working in the TraCSS Operations Centers. The second set of users is broadly the consumer of TraCSS data and services. The government expects significant overlap in the functionality of the Presentation Layer for the two different communities, however anticipates that there will be a subset of displays, and potentially different types of displays, that are only available to the TraCSS operator user group. Examples of notional user types include:

TraCSS data and services consumers user group:

● General Public User: No account or registration required, can see public data displays.

● Registered Public User: Free account, requires registration, can see public data displays and download permitted subsets of data, similar to basic Space-Track.org account.

● Owner/Operator Account: Free account, requires registration and completion of appropriate forms to verify the user is a satellite owner/operator. Enables users to receive automated CDM warnings and other appropriate data as well as submit satellite data, including ephemerides and data used to generate improved owner/operator ephemerides.

● International Owner/Operator Account: The same as an Owner/Operator account however separate policies may apply to international owner/operators.

● Private SSA Data/Service Provider Account: Free account, requires registration. Enables users to submit data, including ephemerides, for use in conjunction screening. Enables users to receive notifications of tasking lists for requested data and quality of data submitted.

● Inter-Government Agency Account: Free account established to enable transfer of data between OSC’s TraCSS and other US government agencies. This account enables both data import and export. Initially, the DoD will have the only account of this type. This category includes other U.S government agencies that might require access to TraCSS data and services.

● International Partner Account: Free account established to enable transfer of information between OSC’s TraCSS and international partner STC Centers for international coordination.

TraCSS operators user group:

● TraCSS Operator Account: Used to access TraCSS Skyline operational data displays and interfaces. These accounts are very tightly controlled.

● TraCSS Administrator Account: Supports administrative activities such as account administration, review of permissions for all users. This also includes system software and administration tasks and maintenance that will be performed by System Integrator and/or civil servants to monitor overall health of the operational system. These accounts are very tightly controlled.

● TraCSS Government User Account: Access to all data but does not have administrative privileges.

2.0 Presentation Layer Requirements

The Contractor shall provide commercial capabilities that meet the requirements of this PWS.

Additional development will be required on a T&M basis to create additional GUIs as the TraCSS system matures.

2.1 General Requirements

2.1.1 Web-based GUI: The Government requires web-based GUIs that can display space situational awareness data and products in alignment with the users delineated in 1.6 and outlined in 2.1.3. All TraCSS user displays shall be implemented as web Graphical User Interfaces. GUIs will be required for both the TraCSS user community (the public and registered TraCSS users) and the TraCSS operations team. By “Presentation Layer GUIs” the government includes the design, build, deployment, evolution and administration of the TraCSS.gov website that hosts the TraCSS user displays/interface.

2.1.2 User Interface Requirements. The following requirements are intended to provide insight into the type of functionality the government is seeking, but are not intended to be exhaustive.

2.1.2.1 User interface displays shall follow best practices and industry standards for usability, user centered design, UI/UX, and human factors.

2.1.2.2 Look and Feel: In addition to applicable human factors design and engineering principles, the Contractor shall standardize look and feel across TraCSS displays including colors, fonts, icons, toolbars, layout, and branding. Look and feel standards shall be submitted to the Government for approval before implementation.

2.1.2.3 If a function is not allowed based on User Access Controls, it shall be clearly stated along with resolution information (i.e what level would be required and who to contact for help).

2.1.2.4 The Presentation Layer shall be capable of querying all data available through the REST

API, defined by the System Integrator, in human-readable format.

2.1.2.5 The Presentation Layer shall enable users to set conditions for receiving alerts via text or email. This capability shall be user-configurable, both as a default, and real-time user-selectable.

2.1.2.6 The Presentation Layer shall allow users to choose between a default initial display when logging on, or a user-configurable fixed set or template of widgets, displays, panels, and/or windows.

2.1.2.7 The Presentation Layer shall support mobility requirements.

2.1.2.8 The Presentation Layer shall support Consultative Committee for Space Data Systems

(CCSDS) standards and formats.

2.1.3 Types of Displays: The following provides some examples of the types of activities, and hence interaction with the Presentation Layer, that are envisioned for users for TraCSS Phase

1. Users must log-on, if not a General Public User, before interacting with appropriate displays.

The examples are not exhaustive but are presented to provide scope and context:

● General Public User: high-level displays which provide an overview of predicted conjunctions with configurable thresholds and related public conjunction information, SSA tools and space weather warnings, general system status, ability to register as a TraCSS user, access to public data

● Registered Public User: displays to discover, search, sort and download permitted data and tools from the TraCSS website. Until being verified, satellite owner/operators would leverage this account as well.

● Verified Owner/Operator: displays that allow users to register and receive notifications of conjunctions; and interfaces that allow for submitting ephemerides, maneuver plans, and/or data to create improved owner/operator ephemerides. Ideally this user group interface capability includes a configurable display and the ability to edit user configurable account information, access to data, CDMs, and an owner/operator point of contact directory, detailed views of conjunctions of interest and satellite registration forms. This user group capability also includes the ability to use the TraCSS REST APIs to interact with TraCSS to input or extract allowed data.

● Commercial Data/Services Provider: displays that allow users to register and manage accounts, and provide interfaces to submit data and ephemerides to TraCSS, and the ability to extract permissible data. These displays may include the ability to use TraCSS REST APIs to interact with TraCSS to input or extract allowed data.

● Inter-Government Agency: displays to transfer data to TraCSS and receive data from TraCSS. This functionality includes account management, data alerts signaling availability of data of interest, registration, and potentially any satellite owner/operator presentation layer features. These displays also include the ability to use REST APIs to interact with TraCSS to input or extract allowed data.

● International Partner: Displays to transfer data to TraCSS and receive data from TraCSS for various international coordination activities. This includes account management, data alerts, ability to track CDMs of interest. These displays also include the ability to use TraCSS REST APIs to interact with TraCSS to input or extract allowed data.

● TraCSS Operator: displays to monitor system performance data quality, and take courses of action in response to unplanned events. The displays need to notify when the system is not performing to be able to take corrective action. These displays include the ability to detect and track the steps of the conjunction screening process, detect data errors and output issues. NOTE: The presentation layer Contractor will work closely with the System Integrator and the TraCSS operators to evolve these displays.

● TraCSS Administrator Account: Supports administrative activities such as account administration, review of permissions for all users. This also includes system software and administration tasks and maintenance that will be performed by System Integrator and/or civil servants to monitor overall health of the operational system. These accounts are very tightly controlled.

● Government User: similar functionality to operator displays but read-only

2.1.4 Plan, Design and Mockups: The Contractor shall submit an overall plan and design

(including mockups or prototypes) of any new displays that must be developed for government approval before implementing the displays.

2.1.5 The Contractor and its subcontractors, as applicable, may provide external SSA services for TraCSS such as improved owner/operator ephemerides or SSA data (including ephemerides) consistent with avoiding any conflict of interest situations and an OCI mitigation plan must be submitted. In such cases where the presentation layer Contractor is also providing SSA data or services to TraCSS, the presentation layer must be able to equally integrate with all capabilities from all contractors.

2.1.6 The Contractor shall support and enable the oversight activities of the Government and its FFRDC Team.

2.1.7 In the event of contract termination, the Contractor shall provide handover education, documentation, and training to their successor.

2.1.8 The Contractor shall create TraCSS User Manuals (UM) and System Manager’s Manuals that provides help and documentation that is easily located, specific to the task at hand and worded in a way that will guide the user through the necessary steps towards a solution to the issue they are facing.

2.1.9 Software Ownership and Licensing: The Contractor may deliver the TraCSS Presentation

Layer using existing, proprietary software, augmented by existing open source software and new software or modifications.

2.1.9.1 For any existing software (including source codes, object codes, executables, ancillary files, and any and all related documentation) developed at the Contractor’s expense and delivered under this contract, the Contractor may retain copyright and any other intellectual property rights but shall grant the Government a nonexclusive, worldwide license for the duration of the contract that permits its use by the Government, by the Government’s other contractors and affiliates, and by an unlimited number of TraCSS users.

2.1.9.2 For any new software or modifications to existing software (including source codes, object codes, executables, ancillary files, displays and any and all related documentation) developed and delivered under this contract, the Contractor may retain copyright and any other intellectual property rights but shall grant the Government a perpetual, nonexclusive, worldwide license to such software providing “unlimited rights,” as defined in the Federal Acquisition Regulation Subpart 27.401.

2.1.10 The Contractor shall do any necessary development of TraCSS’s Presentation Layer on free, open-source software. If that solution is not possible, the Contractor shall develop a plan to use commercial-off-the shelf (COTS) products and seek government approval for it. If none of the previous approaches are feasible, the Contractor shall develop a plan for creating new software and seek government approval for it.

2.1.11 The Contractor shall grant full access and use of the TraCSS Presentation Layer and full access to documentation, code, and other work products only to personnel authorized by the Government.

2.1.12 The Contractor shall deliver a TraCSS Presentation Layer capable of being deployed to multiple cloud service provider infrastructures as well as on-premises data centers.

2.1.13 The Contractor shall ensure that the Presentation Layer accesses Data Services and Software Services solely through APIs developed by the System Integrator.

2.1.14 The Contractor shall work with the Space-Track.org team and the Government to migrate commercial and civil users from the Space-Track.org website to the TraCSS.gov website by the completion of Phase 1.4 and submit a final report of migration of commercial and civil users from Space-Track.org.

2.1.15 The Contractor shall provide on-call support for the TraCSS operations center staff 24/7 and provide a help desk support function for general users during normal business hours in the time zone where the operations center is located.

2.1.16 The Contractor shall provide monthly reports on their overall progress. This report shall include a summary of all work performed by service, an assessment of technical progress, schedule status, and any contractor concerns or recommendations for the previous reporting period. Labor hours and materials (if any) used per labor category/contractor resource shall be provided for all T&M services.

2.2 Performance Requirements

The Contractor shall ensure that the integrated TraCSS presentation services satisfy the following performance requirements. Key Performance Parameters (KPPs) shall include, but are not limited to, the numerical values listed below.

2.2.1 The Contractor shall enable the TraCSS Presentation Layer to:

● Be highly reliable, durable, and capable of operating despite failure of portions of services, i.e., a failure in one service should not prevent other services from functioning.

● Be scalable and capable of providing secure access to globally dispersed users, SSA data producers, and SSA data consumers. Secure access means that the Presentation Layer meets TraCSS thresholds for data confidentiality, integrity and availability performance parameters defined in section 6.

2.2.2 Latency for User Interface: The Presentation Layer Contractor shall work with the System Integrator to optimize latency.

2.2.3 System Availability: The TraCSS shall be designed for high availability with full operational capability better than 99.95% of the time (i.e., 4.38 hours of unscheduled downtime per year).

2.2.4 Continuity of Operations (COOP): The Contractor shall support the System Integrator's

COOP plan.

2.2.5 Mean Time To Recovery: The Contractor shall ensure that mean time to recovery from a system failure is one hour, with one standard deviation of 20 minutes.

2.2.6 Concurrent Users: The Contractor shall work with the System Integrator to accommodate expected numbers of concurrent users and website visitors.

3.0 Development Approach

The TraCSS program is employing an agile development methodology and the Presentation Layer Contractor must align their development processes with those the program utilizes and are managed by the TraCSS System Integrator. Consequently, for any development required for the presentation layer:

3.1 The Contractor shall follow an Agile approach to plan, design, test, develop, manage, maintain, administer, and evolve TraCSS Presentation Layer, including the TraCSS website.

Specifically, relevant plans, documents, tests and code shall be updated consistently during the sprint and delivered at the end of each sprint.

3.2 The Contractor shall ensure that the TraCSS Presentation Layer, including the TraCSS website, operates as intended through continuous monitoring, testing, validation, interface management, and verification, including support of operations.

3.3 The Contractor shall follow the TraCSS resiliency plan developed by the System Integrator to prescribe the service level objectives (SLOs) for performance, resource scalability, redundancy, reliability, continuity of operations, and cost underlying operation of TraCSS. The contractor shall submit a final report explaining how they are meeting the resiliency plan for their part of the system (ie. the website).

3.4 The Contractor shall use the continuous integration / continuous delivery (CI/CD) pipeline developed by the System Integrator for software updates to TraCSS services. The Contractor may choose to utilize their own CI/CD pipeline, but in that case the contractor must still process the Presentation Layer product and updates through the CI/CD pipeline developed and maintained by the System Integrator prior to any updates being introduced to the operational environment.

3.5 The Contractor shall support the System Integrator in testing and vetting of new presentation layer services and their transition from the TraCSS-HORIZON Development and Test (DevTest) environment to TraCSS-SKYLINE operations, including test, and validate the appropriate patches, updates, and workarounds for TraCSS presentation services before promoting these services to operations.

3.6 The Contractor shall verify non-degradation testing at the conclusion of patch updates for

TraCSS presentation services that are in operations.

3.7 The Contractor shall ensure that individual methods in code and individual blocks of configuration files are documented inline using comments that permit the use of documentation-generation tools.

3.8 The Contractor shall deliver a user research plan and conduct usability testing at regular intervals throughout development with customers, users, and operations staff.

3.9 The Contractor shall deliver containerized presentation services to the System Integrator for integration and test in the TraCSS HORIZONS DevTest environment.

3.10 The Contractor shall utilize a tool selected by the System Integrator and the government to track incidents, change requests, and the continuous integration and continuous deployment (CI/CD) of TraCSS presentation services.

3.11 The Contractor shall work with the government and the System Integrator to coordinate sprint planning to align Presentation Layer functionality with TraCSS capability evolution.

4.0 Log Data Service Requirements

4.1 The Presentation Layer contractor shall work with the System Integrator to determine what

Presentation Layer service data will be provided to the Log Data Service and how that data will be transferred.

5.0 Model-Based System Engineering Requirements

5.1.The Contractor shall inform the System Integrator and the government of any necessary changes to high-level architecture and sequence diagrams in the Authoritative Source of Truth (ASOT) for TraCSS presentation services using SysML/UML/UAF in the MBSE tool (such as Cameo) selected and maintained by the System Integrator.

6.0 Security and User Management Requirements

6.1 The Contractor shall comply with all government and NOAA and Department of Commerce security requirements (FedRAMP, FISMA, Risk Management Framework, DOC Enterprise Security Policy and NOAA IT Security Manual) deployed and defined by the System Integrator as applied to code repository management, configuration management, branching/merging code, building automation, test code coverage, automated scanning tools, logs, zero trust model, continuous monitoring, scanning for CVEs, and runtime behavior analysis to support the TraCSS Authority to Operate (ATO) certification.

6.2 All presentation services shall check Data Policy/Rule Engine before fulfilling user (person or non-person entity) requests for data.

6.3 The Contractor shall support the System Integrator's software vulnerability detection after delivery and integration and describes the actions taken from the cybersecurity vulnerability testing

6.4 The Contractor shall leverage automated tools to identify and remediate cybersecurity vulnerabilities.

6.5 The Contractor shall assist the System Integrator in developing a classified data spill mitigation plan to protect against an inadvertent classified data spill from DOD sources. Specifically, the contractor shall provide input into the plan for the Presentation Layer component. In an event of a spill, the contractor shall execute the plan and submit any required reports.

6.6 Contractor personnel will be screened in accordance with the requirements for Low Risk contracts as specified by CAM 1337.70 Section 2.2 (Jun 2024); specifically, in accordance with CAR 1352.237-71 Security processing requirements - low risk contracts (April 2010).

Any access by contract personnel who are Foreign Nationals must be in accordance with the requirements of CAR 1352.237-73, Foreign National Visitor and Guest Access to Departmental Resources (APR 2010).

The contractor must submit security forms required by CAR 1352.237-71 two (2) weeks prior to each new contract employee’s start of work so NOAA staff has sufficient time to process requests for background checks, NOAA badges, and network access.

To protect information confidentiality, the Contractor shall ensure that all personnel supporting this PWS sign a Non-Disclosure Agreement (NDA).

Badges

All Contractors shall complete a Department of Commerce Personal Identity Verification (PIV) Request form CD-591 and a Defense Enrollment Eligibility Reporting System (DEERS) and Common Access Card (CAC) form 1172-2 prior to being granted access to U.S. Federal Government facilities.

Exit Interviews

The Contractor shall conduct exit interviews with all departing Contractor personnel and return Government-issued identification badges and Government-issued equipment to the COR. In addition, the Contractor will review with all departing Contractor personnel all requirements and restrictions as related to applicable Non-Disclosure Agreements and Conflict of Interest.

7.0 Key Personnel

7.1 Before replacing any individual designated as Key by the Government, the Contractor shall notify the Contracting Officer no less than 15 business days in advance, submit written justification for replacement, and provide the name and qualifications of any proposed substitute(s). All proposed substitutes shall possess qualifications equal to or superior to those of the Key person being replaced, unless otherwise approved by the Contracting Officer. The Contractor shall not replace Key Contractor personnel without approval from the Contracting Officer. The following Contractor personnel are designated as Key for this requirement:

Project Manager

7.2 Project Manager

The Contractor shall provide a Project Manager who shall be responsible for all Contractor work performed under this PWS. The Project Manager shall be a single point of contact for the Contracting Officer and the COR. The name of the Project Manager, and the name(s) of any alternate(s) who shall act for the Contractor in the absence of the Project Manager, shall be provided to the Government as part of the Contractor's proposal. The Project Manager is further designated as Key by the Government. During any absence of the Project Manager, only one alternate shall have full authority to act for the Contractor on all matters relating to work performed under this contract. The Project Manager and all designated alternates shall be able to read, write, speak and understand English. Additionally, the Contractor shall not replace the Project Manager without prior approval from the Contracting Officer.

The Project Manager shall be available to the COR via telephone between the hours of 8:00 am and 5:00 pm, Monday through Friday, and shall respond to a request for discussion or resolution of technical problems within 24 hours of notification.

8.0 Other Applicable Conditions

8.1 Contractor Screening

The contractor must submit security forms required by CAR clause 1352.237-70 four (4) weeks prior to each new contract employee’s start of work so NOAA staff has sufficient time to process requests for background checks, NOAA badges, and network access.

To protect information confidentiality, the Contractor shall ensure that all personnel supporting this PWS sign a Non-Disclosure Agreement (NDA).

Badges All Contractors shall complete a Department of Commerce Personal Identity Verification (PIV) Request form CD-591 and a Defense Enrollment Eligibility Reporting System (DEERS) and Common Access Card (CAC) form 1172-2 prior to being granted access to U.S. Federal Government facilities.

Exit Interviews The Contractor shall conduct exit interviews with all departing Contractor personnel and return Government-issued identification badges and Government-issued equipment to the COR. In addition, the Contractor will review with all departing Contractor personnel all requirements and restrictions as related to applicable Non-Disclosure Agreements and Conflict of Interest.

8.2 Employee Conduct

Contractor’s employees shall comply with all applicable Government regulations, policies and procedures (e.g., fire, safety, sanitation, environmental protection, security, “off limits” areas, etc.) when visiting or working at Government facilities. The Contractor shall ensure Contractor employees present a professional appearance at all times and that their conduct shall not reflect discredit on the United States or the National Oceanic and Atmospheric Administration (NOAA). The Project Manager shall ensure Contractor employees understand and abide by NOAA established rules, regulations and policies concerning safety and security.

8.3 Removing Employees for Misconduct or Security Reasons

The Government may, at its sole discretion (in coordination with the Contracting Officer where practical), direct the Contractor to remove any Contractor employee from NOAA facilities for misconduct or security reasons. Removal does not relieve the Contractor of the responsibility to continue providing the services required under the contract. The Contracting Officer will provide the Contractor with a written explanation to support any request to remove an employee.

8.4 Place of Performance

The work required for this Task Order will be both on-site and off-site. Services may be performed at the contractor’s facilities, remotely as teleworkers, or on-site at NOAA locations in the greater Washington, DC metropolitan area as determined by the Government.

8.5 Hours of Operation

The contractor shall provide 24/7 support to users and user representatives to develop, manage, maintain, administer, and evolve the presentation services needed to support TraCSS space safety services, including operations support.

The contractor shall ensure that adequate support for this requirement is maintained at all times.

The contractor shall ensure that all support personnel are present and available for all hours of operations (either on-site or off-site as agreed upon between the contractor and the government on a task basis). If for any reason the contractor staffing levels are not maintained due to vacation, leave, appointments, etc., and replacement personnel cannot be provided as needed, the contractor shall provide a written notification to the Contracting Officer’s Representative (COR) and the Task Manager.

8.6 Post Award Conference

The Contractor shall attend a Post Award Conference with the Contracting Officer and the COR no later than 14 calendar days after the date of award. The purpose of the Post Award Conference, which will be chaired by the Contracting Officer, is to discuss technical and contracting objectives of this contract and review the Contractor's draft management plan. The Post Award Conference will be held virtually.

8.7 Progress Meetings

The Project Manager shall be responsible for keeping the COR informed about contractor progress throughout the performance period of this contract, and ensure contractor activities are aligned with OSC objectives. At a minimum, the Project Manager shall review the status and results of contractor performance with the COR on a quarterly basis in meetings at the Government’s facility or virtually as requested by the Government. Additionally, the Project Manager shall be available to meet with the COR upon request to present deliverables, discuss progress, exchange information and resolve emergent technical problems and issues.

8.8 General Report Requirements

The Contractor shall provide all written reports in electronic format with read/write capability using applications that are compatible with NOAA workstations (e.g., Windows XP and Microsoft Office Applications).

8.9 Protection of Information

Contractor access to proprietary information is required under this PWS. Contractor employees shall safeguard this information against unauthorized disclosure or dissemination in accordance with the Privacy Act, OMB M06-16 (PII) and other pertinent laws and regulations governing the confidentiality of privileged information and Safeguarding Sensitive But Unclassified (SBU) (For Official Use Only) Information. The Contractor shall ensure that all Contractor personnel having access to business or procurement sensitive information sign a NOAA Non-Disclosure Agreement.

8.10 Section 508 Compliance

Pursuant to Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) as amended by P.L.

105-220 under Title IV (Rehabilitation Act Amendments of 1998) all Electronic and Information Technology (EIT) developed, procured, maintained and/or used under this contract shall be in compliance with the “Electronic and Information Technology Accessibility Standards” set forth by the Architectural and Transportation Barriers Compliance Board (also referred to as the “Access Board”) in 36 CFR Part 1194. The complete text of Section 508 Standards can be accessed at http://www.access-board.gov/ or at http://www.section508.gov.

8.11 Travel

Contractor travel may be required to support this requirement. All travel required by the Government outside the local commuting area(s) will be reimbursed to the Contractor in accordance with the Federal Travel Regulations. The Contractor shall be responsible for obtaining COR approval (electronic mail is acceptable) for all reimbursable travel in advance of each travel event.

The Contractor shall be responsible for coordination of travel in support of Government requirements. The Contractor shall be required to invoice in accordance with FAR 31.205- 46, Travel Costs, and Federal Travel Regulations (FTR), and must submit documentation and receipts of all travel costs. Only the contractor’s actual direct costs proposed in accordance with the terms of the task order (and contract it was placed against) associated with Non- Local Travel shall be reimbursed; no profit or prime contractor fee shall be added. Non-Local Travel is defined as travel that is more than 50 miles (using the quickest route on Google maps) from the contractor’s regular Primary Place of Performance (the place where they incur/perform 80% of their hours worked under this order).

The contractor shall not be reimbursed for any “Local Travel.” Local Travel defined as travel within 50 miles (using Google Maps driving directions) of the contractor personnel’s primary place of performance where they perform the majority of their hours under the call order.

8.12 Government Furnished Resources

http://www.access-board.gov/ http://www.access-board.gov/ http://www.section508.gov/ http://www.section508.gov/

The Government will provide the necessary access to any NOAA system required to perform services (i.e. YubiKey, NOAA email address). A CAC and/or laptop will be issued if the Government determines that it is required to perform services. Contractor personnel shall obtain and maintain all required training and credentials (i.e. annual online training and HSPD- 12 clearance) to have account access.

8.13 Contractor Furnished Property

The Contractor shall furnish all facilities, materials, equipment and services necessary to fulfill the requirements of this contract, except for the Government Furnished Resources specified in this PWS.

9.0 Acronyms

18SDS: 18th Space Defense Squadron 19SDS: 19th Space Defense Squadron; a backup to 18SDS.

ABAC: Attribute-Based Access Control.

ASOT: Authoritative Source of Truth.

ATO: Authority to Operate.

API: Application Programming Interface.

CA: Conjunction Assessment.

CARA: Conjunction Assessment Risk Analysis.

CASB: Cloud Access Security Broker.

CCSDS: Consultative Committee for Space Data Systems.

CDM: Conjunction Data Message.

COLA: Collision Avoidance.

CI/CD: Continuous Integration / Continuous Delivery.

CNCF: Cloud Native Computing Foundation.

COTS: Commercial-off-the Shelf.

CUI: Controlled Unclassified Information CVEs: Common Vulnerabilities and Exposures.

DISA: Defense Information Systems Agency.

DE: Digital Engineering.

DevTest: Development and Testing.

DevSecOps: Development, Security, Operations.

DNG: DOORS Next Generation.

DOC: Department of Commerce.

DOD: Department of Defense.

FAIR: Findable, accessible, interoperable, reusable.

FFRDC: Federally Funded Research and Development Center.

IaaS: Infrastructure as a Service.

IaC: Infrastructure as Code.

ICT: Information and Communication Technology ITAR: International Traffic in Arms Regulations IPV6: Internet Protocol Version 6.

LCOLA: Launch Collision Avoidance.

LOST: Line of Sight Tool.

LTS: Long-Term Sustainability.

MBSE: Model-Based System Engineering.

NAPA: National Academy of Public Administration.

NASA: National Aeronautics and Space Administration.

NESDIS: National Environmental Satellite, Data, and Information Service.

NOAA: National Oceanic and Atmospheric Administration.

OADR: Open Architecture Data Repository.

OCI: Open Container Initiative.

OD: Orbit Determination.

OEM: Orbit Ephemeris Message.

O/O: Owner/Operator.

OPM: Orbit Parameter Message.

OSC: Office of Space Commerce.

PaaS: Platform as a Service.

PasC: Policy as Code.

Pc: Probability of collision.

PWS: Project Work Statement.

RBAC: Role-Based Access Control.

REST: Representational State Transfer.

RFP: Request for Proposals.

RMF: Risk Management Framework.

RSO: Resident Space Object SaaS: Software as a Service.

SCSS: Sidecar Container Security Stack.

SDA: Space Domain Awareness.

SDS: Space Defense Squadron.

SEP: Space Environment Preservation.

SIP: System Integration Platform.

SLO: Service Level Objective.

SPD: Space Policy Directive.

SSA: Space Situational Awareness.

SSN: Space Surveillance Network.

SST: Space Surveillance and Tracking.

STC: Space Traffic Coordination.

STM: Space Traffic Management.

SysML: Systems Modeling Language.

TCA: Time of Closest Approach.

TLE: Two-Line Element.

TraCSS: Traffic Coordination System for Space.

TraCSS-HORIZON: Research and DevTest environments.

TraCSS-OASIS: TraCSS Data Lake.

TraCSS-SKYLINE: TraCSS Operations Environment with SSA application services.

TraCSS SIP: TraCSS System Integration Platform.

UAF: Unified Architecture Framework.

UML: Unified Modeling Language.

VCM: Vector Covariance Message.

VM: Virtual Machine.

10.0 References

9.1 Aerospace OTR 2022-01112, Maneuvering into the Future: Open-Architecture Data

Repository (OADR) Prototype: Towards Civil and Commercial Space Traffic Coordination.

9.2 Aerospace OTR 2022-00578, Statement of Dr. Matthew Hejduk to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives.

9.3 DISA Container Platform Security Requirements Guide, 2022.

9.4 DoD Data Strategy, 2020.

9.5 George, Eric and Harvey, Seth, A Comparison of Satellite Conjunction Analysis Screening

Tools, Advanced Maui Optical and Space Surveillance Technologies Conference, 12-16 Sep 2011, Wailea, Maui, HI.

9.6 Statement of Dr. Mariel Borowitz to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives, April 29, 2022.

9.7 NASA Spacecraft Conjunction Assessment and Collision Avoidance Best Practices Handbook, December 2020.

9.8 National Oceanic and Atmospheric Administration (NOAA) Space Object Commercial Data Request for Information (RFI), Notice ID NOAA-22-SOCD-OSC, February 16, 2022.

9.9 National Oceanic and Atmospheric Administration (NOAA) Cloud Platform Management Services Request for Information (RFI), Notice ID NOAA-22-CPMS-OSC, July 19, 2022.

9.10 National Oceanic and Atmospheric Administration (NOAA) Enhanced Safety Services Request for Information (RFI), Notice ID NOAA-22-OADRESS-OSC, August 16, 2022.

9.11 Space Policy Directive–3, National Space Traffic Management Policy, June 18, 2018.

9.12 GAO AGILE ASSESSMENT GUIDE: Best Practices for Agile Adoption and

Implementation. GAO-20-590G. September 2020.

Appendix A: TraCSS Phase 1 Capability Roll-out

For background information, the following set of diagrams outlines the Phase 1 TraCSS capability implementation plan.

Phase 1.0: Q4FY24

Phase 1.2: Q2FY25

Phase 1.3: Q3FY25

Phase 1.4: Q4FY25 (NOTE: Phase 1 is complete after Phase 1.4)

Appendix B: Definition of Terms

Gateway Business Logic: This service contains business logic to intercept requests from the Presentation Services layer and retrieve data through the Data Services to create a response. It has dependencies on the Web Application Service, the Authorization/Authentication Service, and possibly others. This service is placed in the Conjunction Analysis and Application Services layer to isolate business logic from data access. The System Integrator implements and maintains this service.

Data Policy/Rule Engine: This service contains business logic that manages data access controls and context-aware data security policies for the Presentation, Conjunction Analysis and Application, and Data Services layers. It has dependencies on the Authentication/Authorization service in the Software Services Layer and the Security service in the Infrastructure Services layer.

This service is placed in the Conjunction Analysis and Application Services layer to isolate business logic from data access. The System Integrator implements and maintains this service.

Data Store/Retrieval: This service manages underlying data storage mechanisms and retrieves data from storage. This service includes create, read and delete functions, with delete functions being heavily controlled and restricted. Some details of data objects are shown in the following diagrams. Ephemerides stored in TraCSS will conform to the standard CCSDS OEM format. The System Integrator implements and maintains this service.

Log Data Service: This is a centralized service (or collection of services) for continuous monitoring and logging to automatically collect performance metrics from all TraCSS services and use the service performance metrics to do analytics for performance management, debugging, and cybersecurity monitoring. The System Integrator implements and maintains this service.

Workflow Engine: This service is responsible for executing a series of tasks across a computer cluster. The System Integrator implements and maintains this service.

Data Store/Retrieval: This service manages underlying data storage mechanisms and retrieves data from storage. This service includes create, read and delete functions, with delete functions being heavily controlled and restricted. Some details of data objects are shown in the following diagrams.

Ephemerides stored in TraCSS will conform to the standard CCSDS OEM format. The System Integrator implements and maintains this service.

Data Pub/Sub Agent: This service allows approved TraCSS users to subscribe to new data from internal TraCSS systems such that new data fitting this subscription will automatically be sent to the user. The System Integrator implements and maintains this service.

Appendix C: Performance Requirements Summary (PRS)

The PRS establishes key elements of Contractor performance that represent “mission essential” service requirements, which are identified in the table below in the “Service Output” column.