STARS Section C.docx

Raytheon - Competition Sensitive Standard Terminal Automation Replacement System

(STARS)

Section C – Statement of Work (SOW) Enhancement and Sustainment

November 25, 2024

693KA7-21-D-00001/MOD 7

STARS Section C – SOW Raytheon - Competition Sensitive Draft SIR 693KA7-19-R-SS3_OPS STARS Section C - SOW Raytheon - Competition Sensitive

Page viii 11/25/2024

Table of Contents

TABLE OF TABLES

STARS Section C - SOW Raytheon - Competition Sensitive

STARS Section C – SOW

Page i 11/25/2024

1.0 STARS Overview

1.1 Background

The Federal Aviation Administration’s (FAA) STARS was designed to modernize the air traffic control (ATC) systems at all the nation's major airports by combining and upgrading multiple ATC technologies to a single state-of-the-art platform. STARS provides increased safety and efficiency within the National Airspace System (NAS).

The Raytheon STARS contract was competitively awarded in 1996 to replace the legacy Terminal Automation Systems, Automated Radar Terminal System (ARTS) and Common Automated Terminal Systems (CARTS) at all Terminal Radar Approach Control (TRACON) facilities. The Raytheon-developed STARS automated platform is standardized within the terminal environment. STARS hardware and software is deployed at 440 Remote - Airport Traffic Control Towers (R-ATCT), 149 TRACONs, and 175 DoD facilities.

The STARS acquisition strategy is aligned in phases to allow for time sensitive tech refresh, deployment of future applications, and necessary enhancements and sustainment. Continued improvements and efficiency will be achieved through planned future acquisitions. This Statement of Work (SOW) addresses requirements for a new STARS follow on contract that will fulfill STARS Sustainment 3 (SS3), STARS Sustainment 4 (SS4), future STARS enhancement and sustainment requirements, Operational Support, and DoD program requirements.

1.2 Scope

This SOW is applicable to the STARS Enhancement and Sustainment program and requires the Contractor to provide for the development, enhancement, production, deployment, and sustainment of the STARS in the NAS. The Government requirements are provided in Section J Attachments. Specifically, the STARS System Specification Document (SSD), FAA-E-2904 contained as a J-1 Attachment and the STARS Program/Product Requirements will be contained within individual Delivery Orders (DOs). This SOW also covers deployment of hardware kits for increased operational capability to existing STARS sites (e.g. additional workstations positions or radar interfaces).

The SOW identifies the scope of activities of which the Contractor may be asked to perform on this contract. The applicability of the SOW paragraphs is based on the individual Contract Line Item Numbers (CLINs) and/or Delivery Order Change Proposals (DCPs) negotiated between the Contractor and Government. The specific requirements of each program, product, or services will be identified using individual DOs at the program level via DCPs. Within each DO, site identification and configuration, spare allocations, deployment waterfalls, and task allocations will be identified. Applicable SOW paragraphs and tailoring will be provided for each DO using the SOW Compliance Matrix of the respective DO. The Contractor will not be required to perform to any SOW paragraphs not authorized through a DO or DCP.

This SOW is structured to follow the FAA Work Breakdown Structure (WBS) at the program level (provided as J-2 Attachment). As a result, In-Service Management (STARS Sustainment and Operational Support) is contained in Section 4.0. Additionally, Section 4.0 Operational Support will form the base of the new STARS contract for the initial Period of Performance (PoP) and options to cover the entire period. Section 3.0 tasks cover Sustainment and Enhancements requirements.

2.0 Applicable Documents

The following listed documents referencing specifications, handbooks, orders, standards, policies, publications, and drawings are part of this contract and are applicable to the degree they are specified herein.

The current approved version of these documents as of the contract date applies. In the event of a conflict between this SOW and any applicable documents cited below, the provisions of this SOW must apply.

· Requests for security-related documents, or copies of documents not covered in the preceding paragraph, should be addressed to the Contracting Officer (CO). Requests should fully identify material desired and cite the solicitation or contract number.

· Copies of Military Standards and Specifications may be obtained via the following website, http://DoDssp.daps.dla.mil/ or can be ordered from the Department of Defense Single Stock Point (DoDSSP), Building 4/Section D, 700 Robbins Avenue, Philadelphia, PA 19111-5098.

· Copies of AS9100 D Quality Management Systems - Requirements for Aviation, Space, and Defense Organizations can be obtained from: https://www.sae.org/standards/content/as9100d/.

· Copies of the Acquisition Management System Test and Evaluation Process Guidelines are available in the FAA Acquisition System Toolset (FAST). The online internet address of FAST is: http://fast.faa.gov/.

2.1 FAA Documents

Table 1. FAA Documents SOW Applicable Documents and Standards

FAA Integrated Baseline Review Guide

2.2 Military Documents

Table 2. Military Documents SOW Applicable Documents and Standards

2.3 Other Documents

Table 3. Other Documents SOW Applicable Documents and Standards

3.0 Enhancements and Sustainment (Solution Implementation)

3.1 Prime Mission Product

The Contractor must purchase prime mission product materials for hardware subsystems, software subsystems, software Builds and releases, and the associated subsystem integration assembly test and checkout that will be identified in the products specifications and CLINs. These elements include Section 3 tasks as required for prime mission product subsystem development. See FAA WBS for a complete definition of prime mission products.

3.2 Platform Integration, Assembly, Test, and Checkout

The Contractor must perform platform integration, assembly, test, and checkout activity associated with installation and test of prime mission products in the host facility and operational environment, as identified in the products specifications and CLINs. See FAA WBS for a complete definition of platform integration, assembly, test, and checkout.

3.3 System Engineering

The Contractor must execute System Engineering (SE) activities necessary for the definition, design, development, manufacture, verification, performance measurement, integration, and testing of the system. SE activities include analysis, design, component selection, development, and integration to modify the system, and must consider all aspects of performance, quality, life cycle cost, maintainability, reliability, sustainability, schedule, data processing reserves, and future growth requirements.

The Contractor must maintain effective control over the SE design and development process, including subcontract items and services, to ensure that cost, performance, and schedule are met, provide early detection and correction of problems, and to reduce risk. The Contractor must specify a senior system engineer with the authority to serve as Point of Contact (POC) for SE tasks.

The Contractor must prepare and maintain a single System Engineering Management Plan (SEMP) IAW Contractor Data Requirements Lists (CDRL) SE04 that describes the Contractor’s methods for conducting and controlling the SE activities (detailed in Sections 3 and 4 of this SOW) throughout the contract period, including the performance of task orders.

CDRL SE04 System Engineering Management Plan (SEMP)

3.3.1 System Design

3.3.1.1 Design Reviews

The Contractor must conduct the following technical reviews:

· System Requirements Review (SRR)

· System Design Review (SDR)

Review presentations must be based upon the Contractor’s system and subsystem engineering efforts and related documentation. At each review, the Contractor must provide back-up data on assumptions made and methodologies used in arriving at specific recommendations and conclusions for the design approach. The Contractor must make available for reference and inspection at the reviews: applicable engineering data; specifications; drawings; schematics; design and test documentation; software development files; schedules; working papers; and results of studies and analyses.

There must be a free exchange of ideas between the Contractor and the Government at the formal reviews to establish program progress, identify technical problems, and resolve problems in a timely manner. Key Contractor personnel must be available to respond to Government questions.

The Contractor must notify the Government of readiness for a review at least fourteen (14) calendar days in advance of the planned start of each review.

The Contractor must submit an agenda for all technical reviews at the time of notification of readiness. The Contractor must provide the documentation for review at least seven (7) calendar days prior to the scheduled meeting in order to facilitate understanding of the design and discussion points for the meeting. The minutes must include documentation of any conclusions and/or agreements between the Government and the Contractor, and action items resulting from the review with planned closure dates, responsible person(s), planned action(s) to resolve and any Government action(s) required. The status of each open action item must be reviewed at appropriate technical working meetings until the Government concurs with closure.

3.3.1.1.1 System Requirements Review

3.3.1.1.1.1 System Requirements Review Entrance Criteria

The Contractor must conduct an SRR on significant system enhancements/modifications as directed by the Government. The objective of this review is to ascertain the adequacy of the Contractor’s efforts in defining system requirements.

3.3.1.1.1.2 System Requirements Review Presentation

The Contractor must present and review the following items with the Government, as they relate to system design:

· Analysis of the relevant portions of FAA-E-2904, including crosswalk of System/Subsystem Specification (SSS) to FAA-E-2904 that demonstrates mapping of requirements between the two specifications

· Identification of all new/modified SSS requirements traceable to the new/modified FAA-E-2904 requirements directed for implementation for the Government, including an updated Verification Requirements Traceability Matrix (VRTM)

· Preliminary functional flow analysis and mapping of new/modified FAA-E-2904 requirements to Hardware Configuration Item/Computer Software Configuration Item (HWCI/CSCI), including indication of which requirements are new developmental requirements

· Identification of Technical RIOs, including assumptions, assessments, trade-offs, mitigation plans and alternative approaches

· Identification of design-driving/cost-driving requirements and potential cost-saving alternatives

· Security requirement analysis

· CM overview, with emphasis on maintenance of requirements and design baselines The Government reserves the right to tailor the above components of the SRR presentation, to delete items not required for a specific SRR, and/or to add new items as deemed relevant. Such discussion will be held with the Contractor at the time the requirement for an SRR is established by the Government.

3.3.1.1.1.3 System Requirements Review Acceptance Criteria

The Contractor must meet the following acceptance criteria to successfully complete the SRR:

· Allocation of new and modified FAA-E-2904 requirements, HWCI/CSCIs, and indication of new developmental requirements and their allocated HWCI/CSCIs

· Gain concurrence on test methodology and event as specified in the VRTM of FAA-E-2904

· Demonstrate mapping of new and modified FAA-E-2904 requirements to the Contractor’s SSS requirements

3.3.1.1.2 System Design Review

3.3.1.1.2.1 System Design Review Entrance Criteria

The Contractor must conduct an SDR on significant system enhancements/modifications as directed by the Government. The Government may direct the Contractor to conduct an SDR even if an SRR was not required. If an SRR was required, the SRR must be approved by the Government before an SDR may be conducted. Additionally, all SRR action items must be closed prior to conducting the SDR, unless the Government has given permission to proceed. The purpose of this review will be to:

· Determine that the design, including all CIs, satisfies the performance and engineering specialty requirements of the CI development specifications

· Establish the design compatibility among the CIs and other items of equipment, facilities, computer software and personnel

· Assess CI design and development risk areas on a technical, cost, and schedule basis

3.3.1.1.2.2 System Design Review Presentation

The SDR must cover the design of all Contractor-developed hardware and software CIs. For items that are not Contractor-developed, the Contractor must provide a functional/physical description of the item, the results of the analysis that verifies the item will meet the associated technical requirements, and a description of the interfaces with other CIs. At the SDR, the Contractor must describe the products, processes, methodologies, milestones, and measurements to be used in conducting system development activities. The Contractor must describe its plans for acquiring and developing the required software to meet contract requirements. The Contractor must describe their process for providing a system compliant with AS9100 D, Quality Management Systems - Requirements for Aviation, Space, and Defense Organizations.

As part of the SDR, the Contractor must present and review the following items with the Government, unless otherwise agreed to by the Government:

· System overview and basic design approach for each HWCI and CSCI that shows use of an open architecture to promote modularity and scalability

· Architecture diagrams that provide data flow and control flow diagrams, and a design overview of each HWCI/CSCI

· Description of system interfaces and data flow diagrams

· Functional flow analysis and requirements allocation

· Operator controls and displays, and maintenance features overview, including examples of control and display screens

· Physical description, including lists of materials and parts

· Commercial Off-The-Shelf (COTS) and non-COTS items identification including:

· Results of any Contractor make/buy decisions and/or tradeoffs

· Justification for any use of proprietary and/or non-COTs components

· Commercial software documentation, licensing agreements, and usage limitations

· Information, analysis, and predictions of the reliability and maintainability of components

· Security considerations and design (see Section 3.3.3.7), including how interfaces will be protected, how system access will be controlled, availability and integrity of data

· Safety considerations

· Environmental Health and Occupational Safety (EHOS) considerations

· Environmental design concerns, such as thermal control, electromagnetic compatibility/interoperability, technical risks, etc., in accordance with FAA-G-2100H

· Power consumption goals for each component of the system

· Discussion of design tradeoffs

· Documentation status and availability, such as manuals for Contractor equipment and commercially available equipment, and notification of any proprietary or restricted design/process/components and information

· Quality Assurance (QA) overview

· Updates to Technical RIOs, including assumptions, assessments, trade-offs, mitigation plans and alternative approaches and any newly identified RIOs

· Identification of production long-lead items The Government reserves the right to tailor the above components of the SDR presentation, to delete items not required for a specific SDR, and/or to add new items as deemed relevant. Such discussions will be held with the Contractor at the time the requirement for an SDR is established by the Government.

3.3.1.1.2.3 System Design Review Acceptance Criteria

To successfully complete the SDR, the Contractor must meet the following acceptance criteria:

· Allocate all new/modified requirements in the requirements baseline to HWCIs and CSCIs

· Provide a traceability of the requirements baseline to the HWCIs and CSCIs

· Identify which requirements are satisfied by Non-Developmental Item (NDI) or COTS, which requirements are already implemented, but require modification, and which requirements require development for each HWCI and CSCI

· Present a preliminary design that shows how COTS/NDI, modified COTS/NDI, and new development will work together to satisfy the requirements baseline

3.3.1.2 Interface Documentation

3.3.1.2.1 Management of Interfaces

The Contractor must support the Government in the identification, resolution, documentation, and maintenance of STARS interface issues. The Contractor must develop draft updates to STARS interface documentation when requested by the Government. The Contractor must also provide review and technical support for all Government-developed interface documentation.

3.3.1.2.2 Interface Control Document

The Contractor must develop Interface Control Documents (ICDs) for external STARS System interfaces. ICDs must be developed based on analysis and decomposition of the requirements contained in the FAA-E-2904, and must define and illustrate performance, physical, and functional characteristics in sufficient detail to ensure that all details of the interface can be determined solely from the information in the ICDs.

The Contractor must submit ICDs (CDRL SE03) for Government approval.

CDRL SE03 Interface Control Document (ICD)

3.3.1.2.3 Interface Design Description

The Contractor must develop Interface Design Description documents (IDDs) for internal STARS System interfaces. IDDs must describe the internal interface characteristics between system HWCIs and/or CSCIs, and other system components within STARS. The resultant IDDs must define and illustrate performance, physical, and functional characteristics in sufficient detail to ensure that all details of the interface can be determined solely from the information in the IDDs.

The Contractor must submit IDDs (CDRL SE02) for Government approval.

CDRL SE02 Interface Design Description (IDD)

3.3.1.3 Reliability, Maintainability, and Availability Analysis and Predictions

The Contractor must ensure that Reliability, Maintainability, and Availability (RMA) requirements are considered in selecting, assembling, and integrating system products. The Contractor must document the RMA as an integrated subsection of the SEMP. The Contractor must ensure that any maintenance time used in the RMA predictions is consistent with the requirements in FAA-E-2904.

The Contractor must:

· Document inputs, outputs, and configuration data for each model used to support the RMA program

· Deliver electronic copies of the model(s) results upon request The Contractor must provide preliminary information, analysis, and predictions on the reliability and maintainability of STARS components at SDR (CDRL RM01). Procedures used to establish this information must conform to methods described in MIL-HDBK-217F.

CDRL RM01 Reliability, Maintainability, and Availability (RMA) Modeling and Prediction Report

3.3.2 Human Factors

The Contractor must support the Government in ensuring that the system design is consistent with the capabilities and limitations of the user to operate and maintain it in its operational environment and is consistent with performance requirements and logistics capabilities.

3.3.3 Documentation and Support Management

3.3.3.1 System Refresh and Upgrade

The Contractor must inform the Government of any recommended updates, upgrades, design modifications, and corrective performance improvements identified during engineering development activities. The Contractor must provide a proposal to include a cost/benefit analysis, risk analysis, and life cycle and transition planning, only if requested by the Government. Any proposed change must be approved by the CO. The Government will advise the Contractor of its approval, disapproval, or requested modification of the change.

3.3.3.2 System/Subsystem Specification

The Contractor must deliver an SSS in accordance with Section 4.8.4.4.

CDRL SE01 System/Subsystem Specification (SSS)

3.3.3.3 System/Subsystem Design Description

The Contractor must deliver a System/Subsystem Design Description (SSDD) that specifies the system design and requirements allocation. The SSDD describes the system or subsystem-wide design and the architectural design of a system or subsystem. The SSDD may be supplemented by IDDs and Database Design Descriptions (DBDDs) as appropriate. The SSDD, with its associated IDDs and DBDDs, is used as the basis for further system development. The Contractor must prepare the SSDD in accordance with CDRL SE05 and maintain it to ensure that the Product Baseline is reflected.

CDRL SE05 System/Subsystem Design Description (SSDD)

3.3.3.4 Database Design Description

The Contractor must deliver a DBDD that describes the design of the STARS Adaptation database (CDRL SE06). The DBDD should describe the design of the database and include information documenting its structure, as well as any other information required for software support activity. The Contractor must prepare the DBDD in accordance with CDRL SE06 and maintain it to ensure that the Product Baseline is reflected.

CDRL SE06 Database Design Description (DBDD)

3.3.3.5 System Engineering Support Services

The Contractor must support the following SE activities.

3.3.3.5.1 System Trouble Report Working Group Support

For Facilities and Equipment (F&E) support activities as defined in Section 3, the Contractor must provide support to the STARS System Trouble Report Working Group (STRWG) meetings as per section 4.8.3.2.8.2.

3.3.3.5.2 Hardware Engineering Working Group Support

For F&E support activities as defined in Section 3, the Contractor must participate in bi-weekly Hardware Engineering Working Group (HEWG) teleconference meetings as per Section 4.8.3.2.7.3.5.

3.3.3.5.3 Hardware System Engineering Support

In accordance with Section 4.8.3.2.7.3.6, the Contractor must provide hardware SE support.

3.3.3.5.4 Surveillance and Tracking Working Group

The Contractor must provide support to the STARS Surveillance and Tracking Working Group (SATWG).

In support of the SATWG, the Contractor must:

· Prepare for and participate in formal SATWG scheduled meetings

· Perform assigned action items from prior meetings, and provide status reports on ongoing action items

· Conduct research on, and present selected topics as requested by, the FAA SATWG Chair

· Support ad hoc (off-cycle) Technical Interchange Meetings (TIMs)/meetings on selected topics (e.g., brainstorming with other SATWG teammates on potential approaches to new functionalities)

3.3.3.5.5 STARS Strategic Planning Support

The Contractor must provide support to the STARS Strategic Planning (SSP).

In support of the SSP, the Contractor must:

· Support and participate in STARS hardware and software road mapping activities and meetings

· Prepare for and participate in monthly SSP meetings

· Perform assigned action items from prior meetings, and provide status reports on ongoing action items

3.3.3.5.6 STARS Information System Security Working Group

For supported security products/projects, the Contractor must support the STARS Information System Security Working Group (ISSWG) meetings per section 4.8.3.2.8.7.8.

3.3.3.5.7 Other Technical Support

The Contractor must support any designated work groups and boards or technical meetings.

3.3.3.5.7.1 Prototyping

The Contractor must perform prototyping of new functional applications, and adaptation corrections and/or improvements on STARS in accordance with Section 4.8.1.1.4.

3.3.3.5.8 Engineering Support

The Contractor must:

· Provide hardware, firmware, software, and SE support to the STARS Program Office (PO).

· Document and track these activities in the Contractor’s Customer Trouble Report (CTR) database. The database must differentiate CTRs between Operations and Maintenance (O&M) and Facilities & Equipment (F&E) CTRs. Within the F&E CTRs, the database must further differentiate between Programs/Products.

· Document and track these activities in the Contractor’s CTR database. The database must differentiate Operational Support Facility (OSF) CTRs between O&M and F&E CTRs.

· Document all investigation activities and results in the CTR database in a timely manner.

· Summarize F&E support activities to the Government in a joint monthly O&M and F&E Support Work Group highlight report. For F&E CTRs, the report must include hours spent per individual CTR, estimated total hours at completion per individual CTR, and estimated hours remaining by Fiscal Year.

· Provide separate reporting for O&M hours and F&E hours. Within the F&E reporting, differentiate hours by Programs/Products.

· Review O&M and F&E support activities with the Government in joint quarterly face-to-face meetings. Meetings will be held alternately at the Contractor’s facility and the FAA William J. Hughes Technical Center (WJHTC).

3.3.3.5.9 Product Support Engineering Services

The Contractor must provide engineering services to investigate, analyze and evaluate field related issues resulting from new products. The Contractor will perform analysis of save-crash data, continuous data recording, and adaptation, failed hardware, firmware, Commercially Available Software (CAS) and other available technical information related to a reported field problem or issue resulting from new products.

3.3.3.5.10 Task Orders

As authorized by the CO, the Contractor must provide engineering, products, data and/or other services to support Task Orders in accordance with Section 4.8.1.1.

3.3.3.6 Requirements Management and Baselines

The Contractor must execute a SE process for requirements management to ensure traceable validation, integration, testing, and verification of the system requirements. The Contractor, using a requirements management database, must generate and maintain traceability from requirements of the FAA-E-2904 to the Contractor’s SSS and subsequent verification methods. The Contractor must trace the requirements in FAA-E-2904, including referenced Interface Requirements Documents (IRD), when applicable, to requirements in the SSS. The Contractor must further trace the requirements in the SSS to lower-level test documents, as necessary, to ensure 100% verification of requirements.

The Contractor must manage the STARS program requirements. The Contractor’s requirements management must include, but not be limited to, maintaining a database tracing of FAA-E-2904 requirements to the SSS (CDRL SE01). The Contractor’s Requirement Management Database must be compatible with the FAA’s Dynamic Object-Oriented Requirements (DOORS) management database. The Contractor must deliver the Requirements Management Database in accordance with CDRL SE07.

The Contractor must submit a Class I ECP for any requirement update or change impacting the SSS. If the ECP is approved by the Government and Contractor documentation is impacted, the Contractor must deliver all updated documents as defined in the ECP.

CDRL SE07 Requirements Management Database

3.3.3.6.1 Requirements and Design Change Development

The Contractor must support all SE activities necessary for definition of new requirements or modifications to the existing baseline.

3.3.3.7 Information Systems Security

For supported security products/projects, the Contractor must support the Government's Information System Security (ISS) program and processes per Section 4.8.3.2.8.7.

3.3.3.7.1 Information System Security Compliance & Requirements Management

For supported security products/projects, the Contractor must support Security Compliance and Requirements Management per Section 4.8.3.2.8.7.1.

3.3.3.7.2 Information System Security Development, Test and Evaluation

As directed by the Government, the Contractor must follow established processes for…