Section C GEO.pdf

Federal Aviation Administration

Wide Area Augmentation System

GEO 7 Service Lease

STATEMENT OF WORK

DTFAWA-17-R-00028

26 July 2017

PART 1 SECTION C

Page C-2 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

Table of Contents

1 Introduction and Scope

1.1 Wide Area Augmentation System Overview

1.2 WAAS GEO Satellite and GUS Pair

1.3 Scope

2 Applicable Documents

2.1 Order of Precedence

2.2 FAA Document

2.3 Other Publications

3 Requirements

3.1 General Requirements

3.2 Program Control

3.2.1 Post Award Conference (PAC)

3.2.2 Risk Management

3.2.3 Integrated Program Management Report (IPMR)

3.2.4 Technical Exchange Meetings (TEMs)

3.2.5 Technical Reviews

3.2.5.1 Preliminary Design Review

3.2.5.2 Critical Design Review

3.2.6 Federal Communications Commission (FCC)/International

Telecommunications Union (ITU) Radio License

3.2.7 Reliability Maintainability Availability (RMA)

3.2.8 GUS Site Access

3.2.8.1 GUS Site Inspection

3.2.9 Safety Engineering

3.2.10 Software Development and Assurance

3.2.10.1 DO-178B Development Approach

3.2.10.1.1 Software Development Plan

3.2.10.1.2 Plan for Software Aspects of Certification (PSAC)

Page C-3 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.2.10.1.3 Software High Level Requirements Documentation

3.2.10.1.4 Verification of High Level Requirements

3.2.10.1.5 Software Quality Assurance

3.2.10.1.6 Software Configuration Management

3.2.10.1.7 FAA Reviews of Software Assurance Activities and Artifacts

3.2.10.1.8 Software Accomplishment Summary (SAS)

3.2.10.2 DO-278A Alternate Approach

3.2.10.2.1 Software Development Plan

3.2.10.2.2 Plan for Software Aspects of Approval (PSAA)

3.2.10.2.3 COTS Software Integrity Assurance Case

3.2.10.2.4 Software High Level Requirements Documentation

3.2.10.2.5 Verification of High Level Requirements

3.2.10.2.6 Software Quality Assurance

3.2.10.2.7 Software Configuration Management

3.2.10.2.8 FAA Reviews of Software Assurance Activities and Artifacts

3.2.10.2.9 Software Accomplishment Summary (SAS)

3.2.11 RFU Software User’s Manual

3.3 Phase 1: SGS/RFU/GSP Implementation

3.3.1 GEO Satellite Payload (GSP)

3.3.2 Radio Frequency Uplink (RFU) Subsystem

3.3.3 SGS/RFU/GSP Integration and Test (Milestone 1)

3.3.3.1 SGS/RFU/GSP Test Plan, Test Procedure and Test Report

3.3.4 Program Trouble Report

3.3.5 GUS and GSP Documentation

3.3.6 As-Built Engineering Drawings

3.3.7 GUS Site Requirements

3.3.7.1 SGS Installation

3.3.7.2 Omni Antenna

3.3.7.3 Side-by-Side Test Rack Installation

Page C-4 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.3.7.4 RFU Monitor and Control (M&C) Simulator

3.3.7.5 Terrestrial Communication Network (TCN)

3.4 Phase 2: WAAS Integration, Test & Cutover Support

3.4.1 Integration, Test and Cutover Service

3.4.2 Contract Engineering Support

3.4.2.1 WAAS Integration and Test (Milestone 2)

3.4.2.2 Contract Engineering Support to the GUS Development

3.4.2.2.1 Contract Engineering Support to WAAS Integration

3.4.2.3 GEO/GSP and GUS Maintenance Support

3.4.2.4 Cutover to Operational WAAS

3.4.2.5 Logistics Support

3.5 Phase 3: Operations and Maintenance (O&M)

3.5.1 Satellite Service Lease

3.5.2 Operations Support

3.5.3 First Level Maintenance – GUS

3.5.3.1 First Level Maintenance – SGS

3.5.3.2 Familiarization – SGS

3.5.3.3 Logistics Service – SGS

3.5.4 Second Level Maintenance – RFU

3.5.4.1 Configuration Control Management – RFU Subsystem

3.5.4.2 Emergency Trouble-Shooting Changes – RFU Subsystem

3.5.4.3 Request for Waivers and Deviations

3.5.5 Maintenance Support

3.5.5.1 Contractor/FAA Telephone Conferences

3.5.5.2 Contractor/FAA Meetings

3.5.5.3 Calibration of Test Equipment

3.5.6 Site Visits

3.5.7 Security

3.5.7.1 Security Breach Reporting

3.5.7.2 Data Security

Page C-5 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.5.7.3 Physical Security

3.5.8 Quarterly Operational Status Reporting (QOSR)

3.5.9 Service Lease Contract Closeout

Page C-6 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

1 Introduction and Scope

1.1 Wide Area Augmentation System Overview

The Wide Area Augmentation System (WAAS) is a safety-critical system consisting of equipment and software that augments the Department of Defense (DoD) Global Positioning System (GPS) Standard Positioning Service (SPS).

The primary mission of WAAS is to provide air navigation for all phases of flight in the National Airspace System (NAS). The WAAS augments the GPS with:

o A ranging function, which improves availability;

o GPS corrections, which improve accuracy; and o Integrity monitoring, which improves safety.

WAAS provides a Signal-in-Space (SIS) to WAAS-certified avionics for FAA approved phases of flight. The ranging capable SIS provides data corrections for the GPS and Geostationary Earth Orbit (GEO) satellites.

Figure 1-1 shows the WAAS architecture consisting of the Wide-area Reference Stations (WRSs), the Wide-area Master Stations (WMSs), the GEO Uplink Subsystems –(GUS), the GEO Satellite Payloads (GSPs), and the Terrestrial Communications Subsystem (TCS) which interconnects the WAAS components.

Each GSP operates with two geographically diverse GUSs which are functionally redundant. They operate under coordinated control such that one GUS operates as the Primary uplink to the GSP while the other operates as a Backup terminated in a dummy load.

Broadcasts from the GPS and GEO satellites are received and processed by widely-dispersed WRSs that are strategically located for data collection within the WAAS service volume. Processed data from all WRSs is forwarded to WMSs for further processing to determine the integrity, corrections, and residual errors for each monitored satellite and for each predefined Ionosphere Grid Point (IGP).

Multiple WMSs are provided to eliminate single-point failures within the WAAS.

Although all WMSs send data to all GUSs, only data from the selected Primary WMS is accepted by the GUS. The Primary GUS formulates the navigation message and transmits the GPS-like SIS to their its respective GEO satellite which broadcasts the WAAS SIS to Users.

Page C-7 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the

Figure 1-1 WAAS Architecture

1.2 WAAS GEO Satellite and GUS Pair

Figure 1-2 shows the architecture of a typical WAAS GEO satellite and its dedicated GUS pair – one operating in the Primary mode and the other in the Backup mode. The Contractor Furnished Equipment (CFE), shown in blue broken lines, consists of a GSP and its associated pair of Radio Frequency Uplink (RFU) subsystems. The Government Furnished Equipment (GFE) consists of the Signal Generator Subsystem (SGS). Each GUS consists of an RFU subsystem and an SGS, including associated site-specific equipment and facilities. The FAA will also provide telecommunication circuits to the GUS sites.

Users J B J B

WRS

(Quantity 38)

Terrestrial Communications Subsystem (TCS)

WMS

(Quantity 3)

Anik F1R

(CRE)

GEO

SIS

GEO

SIS

GEO SIS

GEO SIS

GPS

Constellation

CRW GUST

Sites:

Napa, CA Littleton, CO

GEO SIS

Inmarsat-4F3

(AMR)

Galaxy 15

(CRW)

AMR GUS Sites:

Santa Paula, CA

Paumalu, HI

CRE GUST Sites:

Brewster, WA Woodbine, MD

F A A W A A S

GEO 7

GEO SIS

GEO 7 pair of GUS Sites

Page C-8 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

SGS

(GFE) RFU RFU SGS

(GFE)

Uplink L1/L5

L1/L5

Primary GUS Backup GUS

L1/L5

WAAS Components:

Wide-area Master Stations (WMSs) and Wide-area Reference Stations (WRSs)

TCS TCS

Contractor Furnished Equipment (CFE) Includes site-specific equipment & facilities

GEO

satellite

L1/L5

J B J B

L1/L5

Users

Uplink L1/L5

L1/L5 L1/L5

Figure 1-2 WAAS GEO Satellite and GUS Pair

1.3 Scope

The Contractor will provide leased service in compliance with the Section J Technical Specifications for GEO 7 Service Lease (hereinafter referred to as Technical Specifications). The leased service includes a GSP and its associated pair of RFU subsystems and any GUS site-specific equipment and facilities. The FAA will provide to the Contractor an SGS for each RFU subsystem of the GUS pair associated with the GEO 7 satellite.

The effort to be performed by the Contractor is summarized below and depicted in Figure 1-3 Phases 0, 1, 2, and 3.

Phase 0: Capability Determination and Proposal Definitization – three (3) months, nominal In Phase 0, the Contractor will be responsible for the following activities:

1. Submit signed subcontracts with Subcontractors needed in support of the scope and efforts identified in Phases 1, 2, and 3

Page C-9 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

2. Submit the technical, management and cost proposal for Phases 1, 2, and 3.

3. Submit an approved baseline schedule as part of its program management approach that is coordinated with all subcontractors.

Phase 1: SGS/RFU/GSP Implementation – thirty-seven (37) months, nominal In Phase 1, the Contractor will be responsible for the following activities towards the achievement of critical Milestone 1:

1. Definition of specifics of contracts with Contractor’s sub-contractors (details provided to FAA for information);

2. GSP design and development, satellite launch, in-orbit tests;

3. RFU subsystem design, development, installation and tests at GUS sites;

4. Integration and testing of the SGS/RFU/GSP;

5. Ensuring suitable RFI environment at the GUS sites.

Milestone 1 is defined as the successful verification of the SGS/RFU/GSP integrated operation in accordance with the Technical Specifications. Conditional acceptance (Milestone 1A) is anticipated to be completed within thirty-four (34) months of contract award. Final acceptance (Milestone 1B) is anticipated to be completed within thirty-seven (37) months of contract award. Milestone 1A and Milestone 1B are defined in Section 3.3.3.1. Final acceptance of all Phase 1 CDRLs concludes Phase 1.

Phase 2: WAAS Integration, Test & Cutover Support– Twelve (12) months

The integration of the SGS/RFU/GSP will be the responsibility of the FAA. Under Phase 2, FAA will coordinate the integration efforts of the GEO Contractor with other WAAS contractor(s), if any.

In Phase 2, the GEO Contractor will provide support for Phase 2 activities which will include:

1. Integration and test of each integrated GUS/GSP to the WAAS Shadow System (a WAAS simulation tool); and

2. Cutover of the integrated GUSs/GSP to the operational WAAS.

Phase 2 activities will start upon FAA conditional acceptance of Milestone 1.

Conditional acceptance of Milestone 1 is defined in SOW 3.3.3.1 SGS/RFU/GSP Test Plan, Test Procedure and Test Report.

Page C-10 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

Milestone 2 is defined as the successful completion of the integration and test of the SGS/RFU/GSP to the WAAS Shadow System. Conditional acceptance (Milestone 2A) is anticipated to be completed within six (6) months of conditional acceptance of Milestone 1. Final acceptance (Milestone 2B) is anticipated to be completed within three (3) months of Milestone 2A. Milestone 2A and Milestone 2B are defined in Section 3.4.2.1.

Phase 2 Cutover activities will start upon FAA conditional acceptance of Milestone 2. Conditional acceptance of Milestone 2 is defined in SOW 3.4.2.1 WAAS Integration and Test (Milestone 2).

Phase 2 Cutover to operational WAAS is anticipated to be completed within six

(6) months of conditional acceptance of Milestone 2.

Phase 3: Operations and Maintenance – Ten (10) - year Service Lease In Phase 3, the Contractor will be responsible for the operation and maintenance of the GSP and GUS, including site-specific equipment and facilities, such that the Technical Specifications will continue to be satisfied for the duration of the service lease.

Figure 1-3 Phases 0, 1, 2 and 3

Phase 2 – WAAS Integration, Test & Cutover Support

Phase 1 SGS/RFU/GSP Implementation

Phase 3 – Operations & Maintenance Milestone 2A Conditional Acceptance

Phase 0B Authorization to

Proceed

Milestone 1B Final Acceptance

(Test Report Approval)

Milestone 1A Conditional Acceptance

(Test Summary)

GSP/GUST/Shadow Integration 6 months

Cutover 6 months

10 years

34 months, nominal mo mo

IOT/

Milestone 0

Start of CLIN 1 Satellite Lease

Payments

Milestone 2B Final

Acceptance mo

37 months, nominal

Phase 0 Capability Determination and

Proposal Definitization

Phase 0A IDIQ Contract

Award

3 months, nominal

Page C-11 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

2 Applicable Documents

The following specifications, handbooks, orders, standards, and drawings form a part of this contract and are applicable to the extent specified herein. The latest version of these documents as of the contract award date will apply.

2.1 Order of Precedence

In the event of a conflict between the text of this Statement of Work (SOW) and the documents cited below in [2.2 and 2.3], the text of this SOW takes precedence. Nothing in the SOW, however, supersedes applicable laws and regulations unless a specific exemption has been obtained In writing.

2.2 FAA Document

Document Number Document Title, Issue Date

WAAS100161A WAAS SGS/RFU Interface Control Document, new release

WAAS100184 Satellite Control Center/Message Control Processor Interface Control Document, new release

TI6882.1 Technical Instruction Book for the Wide Area Augmentation System, Version 1.30.001, December 21, 6882.2A WAAS Maintenance Handbook, November 15, 2010

WAAS100232 Technical Specifications for GEO 7 Service Lease, FAA-STD-021A DOT Federal Aviation Administration Standard:

Configuration Management, August 17, 1987

DI-MGMT-81861 DoD’s Integrated Program Management Report (IPMR) Data Item Description (DID)

Page C-12 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

2.3 Other Publications

Document Number

Document Title, Issue Date

RTCA/DO-178B Software Considerations in Airborne Systems & Equipment Certification, December 01, 1992

RTCA/DO-278A Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems, December 13, 2011

SAE ARP 4761 Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment

N/A Earned Value Management Guide, July 2016

MIL-HDBK-61A Configuration Management Guidance, February 7, 2001

Page C-13 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3 Requirements

3.1 General Requirements

The Contractor must design, develop and test a GSP and GUS pair and operate them on a lease basis. The GSP will broadcast WAAS L1 and L5 signals with signal characteristics that comply with the Technical Specifications. The Contractor selected GEO satellite must support this payload over the period of performance of the contract without resource support interruptions and without impacting other payloads on the satellite. The Contractor must provide and maintain the GSP on-orbit in an orbital slot approved by the government. The Contractor must provide, operate and maintain the GSP and associated GUS pair for the exclusive use of the WAAS.

The pair of GUS associated with a GSP must be separated by at least 300 miles.

The Contractor must provide personnel, equipment and services necessary to manage and maintain the GSP, GUS pair and ancillary equipment to ensure continued provision of broadcast services in accordance with the terms of the contract.

3.2 Program Control

A Program Manager must be assigned to organize, plan, schedule, implement, control, analyze and report on all elements of the contract. The Program Manager must have the resources and authority to ensure effective, efficient and timely program execution.

The Contractor must develop and deliver a Monthly Program Status Report (MPSR) for the duration of Phase 1 and Phase 2. The MPSR must contain, at a minimum:

1. Open, Closed and Planned Activities;

2. Status of Action Items and Issues;

3. Status of Engineering Change Proposals (ECP);

4. Risk Management; Identify Contractor risks, issues and opportunities being tracked; Provide detailed description; Planned risk mitigations;

5. Safety Assurance Activity Status;

6. Incurred Cost (Inception to date, Year to date and Current Period);

7. Critical path changes affecting Milestone 1, Satellite Launch Date, Milestone 2 or the start of Phase 3 require FAA approval; and

8. Earned Value Management Reporting.

Page C-14 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the

CDRL A001 Monthly Program Status Report

Page C-15 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.2.1 Post Award Conference (PAC)

The Contractor must host a PAC within 30 days after contract award. As a minimum, the agenda must include the following topics:

1. Introduction of key personnel

2. Statement of Work Review

3. Discussion of program plan and approaches;

4. Detailed schedule; and

5. Contract Review to discuss deliverables, tasks to be performed and special contract provisions.

CDRL A002 PAC Meeting Minutes

3.2.2 Risk Management

The Contractor must establish, implement, and maintain a Risk Management program that provides an overall strategy and approach for effectively managing cost, schedule, and technical performance risks for the duration of the contract.

The Contract Risk Management Plan (RMP) must describe the process for timely identification of risks; accurate risk assessment; development and implementation of mitigation plans; and monitoring, tracking, and reporting of risk items. The RMP must identify the Contractor’s coordination with sub-contractors, suppliers, and the FAA. The Contractor must include risks identified by the FAA within the risk management process.

3.2.3 Integrated Program Management Report (IPMR)

The Contractor must deliver an Integrated Program Management Report (IPMR) (A003) each month starting 12 business days after the second full accounting month after contract award. The FAA reserves the right to require reporting to a lower level of detail, down to the Work Package level. The Contractor’s Earned Value Management system must be able to generate reports to the Work Package level.

The Contractor must ensure that the results of program risk assessments are incorporated into the IPMR Estimate at Completion (EAC). Technical or schedule impacts to the EAC as a result of the risk assessment must be fully explained in the IPMR. The Contractor must include a monthly spend plan that identifies monthly planned expenditures for total estimated award value of all cost reimbursable contract line items. The planned expenditures must be identified by

Page C-16 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

Contract Line Item Number (CLIN) and must be delivered with the IPMR. The planned expenditures must be reconcilable to the IPMR Format 1 as defined in

DI-MGMT-81861.

The Contractor must develop and maintain an Integrated Master Schedule (IMS) based on a logical and efficient sequence of events designed to accomplish the tasks described in the contract. The IMS must present a networked schedule with critical path identified for design, development, integration, installation and test activities. The IMS must be consistent with the Contractor WBS. The IMS must incorporate activities for subcontracts consistent with the Contractor’s approved Earned Value Management System. The IMS must be delivered as part of the IPMR. The FAA will review and approve the initial submission IPMR Format 6, as defined in DI-MGMT-81861, as the initial contract baseline IMS for contractual milestones. The Contractor must submit all proposed baselined IMS changes that affect contract milestones to the FAA for approval.

The Contractor must incorporate CDRL deliveries into the IMS except for recurring monthly CDRLs. The IMS must include significant activities and milestones of the Contractor, sub-contractors and dependencies on the FAA.

IMS activities must have constraints, dependencies, and relationships identified.

CDRL A003 Integrated Program Management Report (IPMR)

3.2.4 Technical Exchange Meetings (TEMs)

The Contractor must conduct and provide administrative support during quarterly TEMs (nominally 2 days in length), to be held at the Contractor’s facility through the completion of Phase 2. The FAA may require that up to two TEMs per year be held in Washington, D.C. or in Oklahoma City, OK. During the TEMs the Contractor and the FAA will discuss specific technical activities, including studies, test plans, test results, design issues, technical decisions and implementation concerns, to ensure continued FAA visibility into the technical progress of the contract. The Contractor must conduct the first TEM in conjunction with the PAC.

The following topics, as applicable, must be on TEM agendas:

1. Schedule of activities with critical paths and risks identified;

2. GSP design and satellite launch status;

3. RFU design, including its Monitor and Control (M&C) and all site-specific equipment and facilities;

4. Engineering drawings;

Page C-17 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

5. Reliability, Maintainability, and Availability (RMA) analyses;

6. RFU Failure Modes and Effects Analysis/Failure Mode Effects

Summary (FMEA/FMES);

7. GSP Failure Mode Analysis;

8. Site Surveys;

9. SGS/RFU/GSP Integration and Test Plan and Procedure, including a Verification Requirements Test Matrix (VRTM);

10. Test Report, including test results and a compliance table; and

11. Configuration Management Plan.

The Contractor must make available for reference and review all applicable engineering data, specifications, drawings, schematics, design and test documentation, schedules, minutes of meetings, working papers and results of studies and analyses, as well as key Contractor personnel to respond to FAA questions.

The Contractor must submit to the FAA an agenda and presentation material at least two (2) weeks in advance of the scheduled start of each TEM. The Contractor must prepare and deliver the TEM minutes including action items resulting from previous TEMs with planned closure dates, person(s) assigned to action items, planned action(s) for resolution of issues, and any action(s) required. The status of each open action item must be reviewed at each TEM until approved by the FAA for closure.

CDRL A004 Technical Exchange Meeting Minutes

3.2.5 Technical Reviews

The Contractor must conduct a formal PDR and a formal CDR for the system.

The Contractor must allow FAA participation at the GSP and GUS/RFU PDR and CDR. At each review, the Contractor must be prepared to provide back-up data on assumptions and methodologies used in arriving at specific recommendations and conclusions for the technical decisions and 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; minutes of meetings;

working papers and results of studies and analyses, as well as key personnel to respond to FAA questions.

The Contractor must notify the Contracting Officer in writing of readiness for a review at least thirty (30) days in advance of the planned start of both PDR and

Page C-18 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

CDR. The Contractor must prepare and submit an agenda and provide presentation materials two (2) weeks in advance of the review. The minutes for the PDR, CDR, and each TEM must comply with CDRL A004 requirements and instructions. They must include action items resulting from the review with planned closure dates, responsible person(s), planned action(s) to resolve and any FAA action(s) required. The Contractor must make GSP and GUS/RFU PDR and CDR minutes available to the FAA.

3.2.5.1 Preliminary Design Review

The Contractor must conduct a system level PDR to demonstrate an understanding of the Technical Specifications and preliminary design of the GSP and GUS/RFU subsystem. The Contractor must define the PDR as a milestone in the IMS.

The Contractor must present and/or discuss in detail the hardware and software design. The Contractor must provide particular attention to any issues associated with the satellite transponders, RFU designs, GFE and interfaces.

At a minimum, the PDR must cover the following topics.

1. Discussion of the following:

a. Traceability of the contractor requirements to the Technical

Specification requirements

b. Architecture description

c. Hardware and software design

d. Software Development Plan (SDP)

e. Plan for Software Aspects of Certification (PSAC) or Plan for

Software Aspects of Approval (PSAA) as applicable

f. RFU design

g. External interface design

h. Test plans

i. RMA analysis

j. FMEA

2. Functional Flows, requirements allocation and schematic diagrams;

3. System overview and requirements allocations to hardware and software components;

4. Physical description including preliminary lists of materials, parts, and equipment layout;

5. Information security considerations and identification of security related requirements, including how interfaces will be protected, how system access will be controlled, availability and integrity of data;

Page C-19 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

6. Physical security of GUS sites and satellite control centers

7. Maintainability and Reliability modeling and predictions;

8. Integrated Master Schedule overview;

9. Overview of Contractor GUS site engineering;

10. Design concerns such as environmental control, electromagnetic compatibility/interoperability, technical risks; and

11. Program risk analysis, including assumptions, trade-offs and alternative approaches.

For all Commercial Off-The-Shelf (COTS)/Non-Developmental Items (NDI) the Contractor must provide:

1. A functional/physical description,

2. COTS technical specifications,

3. Interfaces with other system components,

4. Results of the analysis that verifies the item will meet the associated technical specifications, and

5. Methods to be used to ensure that each Technical Specification requirement has been met.

The PDR will not be complete until the Contractor has:

1. Demonstrated a thorough understanding of the requirements in the Technical Specifications and the Statement of Work;

2. Initiated the functional baseline and identified traceability to Technical Specifications; and

3. Closed all action items with FAA approval.

CDRL A005 Preliminary Design Review Package

3.2.5.2 Critical Design Review

The Contractor must conduct a system level CDR to establish the development configuration. The Contractor must present the detailed design of all hardware and software configuration items. The Contractor must define the CDR as a milestone in the IMS.

The Contractor must present and/or discuss in detail the following items:

1. Discussion of the following:

Page C-20 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

a. Satellite Operations Procedures

b. Integrated Master Schedule

c. Architecture description

d. Interface Control Documents

e. RFU design

f. Operations & Maintenance Plan

2. System and software/hardware configuration items overview;

3. System overview and requirements allocations to hardware and software components

4. System interface and schematic diagrams;

5. Processing algorithm descriptions;

6. Design analysis results;

7. Information security considerations and identification of security related requirements, including how interfaces will be protected, how system access will be controlled, availability and integrity of data;

8. Physical security of GUS sites and satellite control centers

9. RMA analysis and predicted performance values;

10. FMEA;

11. Description of Test Approach and draft test plan;

12. Design concerns such as environmental control, electromagnetic compatibility/interoperability, technical risks;

13. Identification of design-driving/cost driving requirements;

14. Integrated Master Schedule overview with detailed review for development and test schedule;

15. Documentation status;

16. Installation requirements including telecommunications criteria;

17. List of LRUs including model numbers and options; and

18. Lists of all other parts and materials.

For COTS/NDI the Contractor must provide the following:

1. Detailed functional/physical description;

2. Any additional results or analyses; and

3. Detailed description of the interfaces.

4. COTS verification approach

The CDR will not be complete until the Contractor has:

Page C-21 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

1. Established the development configuration according to the approved design documentation;

2. Established the final design that complies with the Technical Specifications;

3. Defined the final internal and external interfaces for each configuration item;

4. Reviewed the resources, requirements and schedule for development tests; and,

5. Closed all action items with FAA approval.

CDRL A006 Critical Design Review Package

3.2.6 Federal Communications Commission (FCC)/International

Telecommunications Union (ITU) Radio License

The Contractor must obtain and maintain mandatory radio licenses and perform regulatory work necessary for the continuous and uninterrupted operation of the GSP and its associated GUS pair as required in the contract. The Contractor must be responsible for satisfying any other pertinent International Telecommunications Union (ITU) and Federal Communications Commission (FCC) Regulations. This includes requirements for the cessation of emissions if necessary to obtain the mandatory radio licenses.

3.2.7 Reliability Maintainability Availability (RMA)

The Contractor must perform RMA analyses on the GSP and associated GUS pair, and deliver a report to FAA, which will be used to assess compliance with the Technical Specifications. The RMA analyses must include values for Mean Time Between Failure (MTBF) and Mean Time to Repair (MTTR) of the RFU Lowest Replaceable Units (LRUs) as well as switchover or replacement times for LRUs. The Contractor must indicate sources of predicted values for the MTBF and MTTR. The Contractor must identify component redundancy for the RFU and GSP in the RMA Analyses. RMA data on the operational SGS will be provided by the FAA as Government Furnished Information.

The Contractor must produce a combined functional RFU FMEA/FMES document in accordance with the Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. The Contractor must deliver the draft RFU FMEA/FMES to the FAA for review and comment no less than 45 days prior to CDR.

Page C-22 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

FMEA/FMES must be performed at the LRU functionality of the RFU subsystem and interfaces between the RFU LRUs. The failure effects and the resulting effects on other components and subsystems, and their interfaces, must be analyzed at the RFU level along with the impact to the GUS interfaces. At a minimum, the FMEA/FMES must identify failure modes that could result in Hazardously Misleading Information (HMI) and/or Loss Of Functionality (LOF), as well as document Local Effects, Fault Detection methods, Failure causes, Failure Rates and sources for LRUs, and failure modes. The FMEA/FMES must also identify interfaces external to WAAS and assumptions made for the analysis.

The Contractor must perform a GSP Failure Mode Analysis to verify that GSP failure modes that contribute to HMI and Loss of Continuity (LOC) are consistent with those currently captured in the WAAS Fault Tree Analysis (FTA). The Contractor must provide the necessary information to support the development of the WAAS FTA by the FAA. The GSP Failure Mode Analysis must include a failure rate estimate for each failure mode that contributes to HMI and/or LOC.

3.2.8 GUS Site Access

The Contractor must provide GUS site access to FAA and associated WAAS contractors within one week of the FAA’s request for site surveys, conduct of integration and test activities, periodic inspections and any other activities for the duration of the contract.

3.2.8.1 GUS Site Inspection

The Contractor must allow FAA and designated FAA personnel to inspect the GUS facilities at the initial site survey for the SGS installation, and at the completion of RFU/SGS installation, telecommunication service racks and side-by-side test racks, prior to initial testing. Any Contractor facilities and equipment identified as having the potential to degrade performance as specified in the Technical Specifications must be changed or upgraded at the expense of the Contractor.

3.2.9 Safety Engineering

The Contractor must provide engineering support on the activities listed below.

This support must include the appropriate expertise to participate in weekly 1-hour teleconference, semi-monthly System Safety Working Group (SSWG) teleconferences, and documentation reviews through the completion of Phase 2.

SSWG are expected to occur twice a month through the first phase.

Page C-23 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

1. Hazard Identification – verification that the HMI and LOC hazard causes associated with the RFU and GSP are consistent in source and likelihood with those documented previously for WAAS;

identification of new HMI and/or LOF hazard causes associated with functional or design analysis.

2. Risk Assessment – determination of the likelihood of hazard cause/failure occurrence associated with newly identified causes.

3. Hazard Tracking and Risk Isolation – participation in Hazard Review and Adjudication activity as necessary; implementation of design changes for mitigation of Hazard Risk items assigned to the GEO Satellite.

4. Safety Critical Requirement Allocation and Verification – identification of RFU functions that support Safety Critical WAAS Requirements and demonstration of compliance with those requirements allocated to the RFU. Representative Safety Critical requirements address uplink control (e.g., transmission to dummy load in Backup mode) and transmission and receive channel time delay performance.

5. Safety Assurance Process Requirements (SAPR) Support – Submission of artifacts required for SAPR compliance to the FAA for review and Safety Baseline control; artifact modification as required to address review findings. Artifacts may include, but are not limited to, requirements documentation, design documentation, RFU FMEA/FMES, GSP Failure Mode Analysis, LRU/subsystem verification procedures, LRU/subsystem verification results, VRTM, Configuration Management plans and records, Quality Assurance plans and records.

3.2.10 Software Development and Assurance

The Contractor must provide RFU subsystem software lifecycle data that complies with the guidance and objectives of either RTCA/DO-178B assurance Level D or with RTCA/DO-278A Assurance Level (AL) 5, in accordance with the direction provided in this section of the SOW. The DO-278A AL5 is identical to DO-178B/C Software Level D for the software safety assurance criteria required for the software controlling the WAAS RFU subsystem. The equivalence of these two software assurance levels is documented in DO-278A Section 2.3.3, Table 2.2.

The software processes and life cycle data required are dependent on the Contractor’s approach for providing the software. Two approaches are allowed by this SOW:

Page C-24 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

1. The first approach applies when a Contractor will execute a full software development activity without the use of COTS or when a Contractor will submit or modify previously approved software (inclusive of COTS components) that already complies with RTCA/DO-178B safety assurance Level D. The DO-178B Development Approach as specified in Section

3.2.10.1 defines the activities and products that need to be generated.

2. The second approach applies when a Contractor will apply COTS, modified COTS, or previously developed software that was developed or previously applied without consideration of DO-178B Level D (or higher).

The DO-278A Alternate Approach specified in Section 3.2.10.2 defines the activities and products that need to be generated. DO-278A is being used in this approach, because it provides a more prescriptive and systematic means of showing compliance with design assurance objectives when COTS software is used.

Figure 3-1 is an overview of the life cycle activities and data required for the two approaches mentioned above.

Page C-25 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the

Figure 3-1: Overview of Approaches for RFU Subsystem Software Development

Developmental S/W Item

Approach 1

Developmental S/W with integrated COTS

COTS

Approach 2

Software shall be compliant to DO-178B Level D --Guidance provided in DO-178B sections 4-9 --Objectives identified in DO-178B Annex A, Tables 1-10

Software shall be compliant to DO-278A DAL 5 --Guidance provided in DO-278A sections 4-9 --Objectives identified in DO-278A Annex A, Tables 1-10 --Example: requirements and code associated with wrappers

Software shall be compliant to DO-278A DAL 5 --Guidance provided in DO-278A sections 4-9 --Objectives identified in DO-278A Annex A, Tables 1-10 --Additional guidance provided in DO-278A section 12.4 --Additional Objectives identified in DO-278A Tables 12-2, 12-3, 12-4, and 12-5.

Page C-26 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

Independent of the approach taken, the Contractor must support execution of FAA RFU subsystem software test activities and correct deficiencies identified during execution of those tests.

The development and assurance efforts are applicable for the duration of the contract. The applicant/contractor must show compliance with all objectives identified in DO-178B or DO-278A for defined Designed Software Assurance Level. A subset of the required compliance documentation must be delivered to the FAA. The required deliverables are listed in sections 3.2.10.1 or 3.2.10.2 depending on the selected approach. The existing Contractor artifacts are acceptable in Contractor format, as long as the artifact content fulfills the requirements of this SOW. The Contractor must maintain the software assurance artifacts for the duration of the contract. At any time, the FAA must have the right to obtain the artifacts or copies of the artifacts.

Table 3-1 summarizes the development processes and the subset of life cycle artifacts delivered for each approach to fulfill the DO-178B/DO-278A objectives.

Correlations to SOW sections are provided when specific deliverables are required as an output of a life cycle activity.

Table 3-1: Software Development and Assurance Processes & Artifacts

DO-178B Development Approach DO-278A Alternate Approach Software Planning Process & Outputs: Software Planning Process & Outputs:

Plan for Software Aspects of Certification [3.2.10.1.2]

Plan for Software Aspects of Approval [3.2.10.2.2]

Software Development Plan [3.2.10.1.1] Software Development Plan [3.2.10.2.1] COTS Software Integrity Assurance Case

[3.2.10.2.3] Software Development Processes & Outputs: Software Development Processes & Outputs:

High Level Requirements Documentation [3.2.10.1.3]

High Level Requirements Documentation [3.2.10.2.4]

Software Design and Code Software Design and Code Software Integration Software Integration COTS acquisition [3.2.10.2.4] COTS Integration Integral Processes & Outputs: Integral Processes & Outputs:

Test Cases, Procedures, Results [3.2.10.1.4] Test Cases, Procedures, Results [3.2.10.2.5] COTS verification Quality Assurance Records [3.2.10.1.5] Quality Assurance Records [3.2.10.2.6] Software Conformity Review [3.2.10.1.5] Software Conformity Review [3.2.10.2.6] Configuration Management Records [3.2.10.1.6] Configuration Management Records [3.2.10.2.7] Change Tracking / Problem Reporting [3.2.10.1.6] Change Tracking / Problem Reporting [3.2.10.2.7] Software Configuration Index [3.2.10.1.8] Software Configuration Index [3.2.10.2.9] Software Accomplishment Summary [3.2.10.1.8] Software Accomplishment Summary [3.2.10.2.9] DO-178B Audit Support [3.2.10.1.7] DO-278A Audit Support [3.2.10.2.8]

Page C-27 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.2.10.1 DO-178B Development Approach

This section of the SOW specifies the Contractor requirements for RFU Subsystem software that is newly developed without the use of COTS, or for modifications to software (including any COTS components) that has been previously approved to RTCA/DO-178B safety assurance Level D or better. The submitted software must be assured to RTCA/DO-178B Level D and comply with all objectives for this required assurance level.

3.2.10.1.1 Software Development Plan

The Contractor must develop and implement a Software Development Plan (SDP) [CDRL A007] that complies with the objectives of RTCA/DO-178B Annex A, Table A-1. The SDP must describe the software lifecycle(s), the software development processes and transition criteria, and software development environment that satisfy the software development process objectives for software assurance Level D. The SDP must contain the definition of software performance and functional characteristics, plans for verification, plans for software configuration management, including problem reporting, and plans for software quality assurance. The SDP must also describe the requirements traceability activities conducted to ensure the RFU Subsystem software high level requirements [A009] fulfill the Technical Specifications [Section J].

CDRL A007 Software Development Plan

3.2.10.1.2 Plan for Software Aspects of Certification (PSAC)

The PSAC identifies the Contractor’s means of compliance with RTCA/DO-178B Annex A Level D objectives, that is agreed upon with the approval authority to establish the certification basis. The Contractor must prepare and implement a PSAC [CDRL A008] in accordance with RTCA/DO-178B Annex A, Table A-1 to address safety critical software life cycle certification activities and considerations. The PSAC must include provisions for independent RTCA/DO- 178B compliance audits. The Contractor must support these audits as outlined in the PSAC.

CDRL A008 Plan for Software Aspects of Certification

Page C-28 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized disclosure under 5 U.S.C, Section 552(b)(4). No information shall be released except as authorized by the Contracting Officer.”

3.2.10.1.3 Software High Level Requirements Documentation

The Contractor must develop, document, and maintain a set of software high level requirements for the RFU subsystem that complies with the objectives of RTCA/DO-178B Annex A, Tables A-2 and A-3. The requirements must be developed in sufficient detail to support the development of the software necessary to implement control of the RFU subsystem and satisfy WAAS SGS/RFU Interface Control Document, WAAS100161A.

Items including but not limited to hardware dependencies, interrupt handling, interface handling, or error handling must be considered. The software high level requirements must have traceability to the RFU system requirements derived from the Technical Specifications [Section J]. They also must provide traceability to the software verification cases and identify the test methods (see Section 3.2.10.1.4). Derived software high level requirements must be defined and provided to the system process, including to the system safety assessment process.

CDRL A009 RFU Subsystem High Level Software Requirements

3.2.10.1.4 Verification of High Level Requirements

The Contractor must plan, implement, and document the verification activities to ensure that all RFU subsystem software high level requirements are satisfied, and that the requirements in the Technical Specifications [Section J] are met.

The SDP [A007] must define the means by which the software verification process objectives of DO-178B will be satisfied. It must describe the verification methods used, verification environment used for testing the RFU subsystem software, re-verification guidelines for modified software, and (if applicable) verification compliance of previously developed software.

The RFU Subsystem Software High Level Requirements [A009] must identify the verification method applied for each requirement and also trace to verification cases.

The Contractor must develop software test cases and procedures that comply with RTCA/DO-178B verification objectives in Annex A, Table A-6 and Table A-7.

Test cases and procedures may be contained in the same artifact, as long as the required content is captured in accordance with RTCA/DO-178B. The test cases must exercise normal and robust conditions and trace to the RFU Subsystem

Page C-29 of 61 July 2017

“This contract may contain information considered sensitive unclassified information (SUI) and would merit protection from unauthorized…