Attachment 5_FMDS Acquisition Strategy White Paper v1.0.docx

Acquisition Strategy for Flow Management Data and Services (FMDS)

DRAFT, Version 1.0 June 27, 2022

Federal Aviation Administration 800 Independence Avenue SW

Table of Contents

WARNING: This document contains information that is subject to the U.S. Export Administration Regulations (EAR, 15 C.F.R. Parts 730-774) and designated as EAR99. As a consequence, this information cannot be exported nor re-exported to country group E:1 or E:2 countries/persons (see Supp.1 to Part 740 of the EAR), nor can be made available to any national of such country. In addition, the information in this document cannot be exported nor re-exported to an end-user or for an end-use that is prohibited by Part 744 of the Export Administration Regulations (15 C.F.R. Part 744).

Acquisition Strategy for FMDS June 27, 2022 ii

Introduction and Background The National Airspace System (NAS) is a dynamic system that must respond to variability in weather, system constraints, and traffic demand. The fundamental goal of Traffic Flow Management (TFM) is to promote a safe, orderly, and expeditious flow of traffic that minimizes delays. This is achieved through coordination, utilization, and analysis of Traffic Management Initiatives (TMIs) that modify demand to account for changes in capacity.

The planned Flow Management Data and Services (FMDS) architecture, subsystems, and deployment strategy is described in the accompanying Attachment 3 Implementation Strategy for FMDS. The FAA is exploring various acquisition approaches to achieve FMDS and desires to foster stakeholder and industry collaboration.

The planned FMDS subsystems are show in Table 11 and are described in detail in the referenced Implementation Strategy for FMDS. The FAA may use the same or different acquisition approaches for the different FMDS subsystems identified in the table below.

Table 11. FMDS Subsystems

· Ingests, processes, matches, and updates flight data from the following sources:

· NAS flight data

· International flight data

· CDM flight data

· Flight schedule data

· TMIs issued via FMS

· Performs trajectory modeling and conformance monitoring

· Publishes and archives flight data

· TFM-specific functions, such as demand/capacity monitoring and TMI modeling and implementation

· Centralized architecture, minimizing footprint at remote sites

· New thin client Situation Display integrating existing TFMS applications

· Public-facing APIs and data publication services

· Modernized and integrated web application portals leveraging FMS microservices

Assumptions The FAA has identified the following assumptions for the acquisition strategy. This list may be updated as the acquisition progresses and will be informed by the responses to this FMDS Request for Information.

1. The FMDS subsystems (FMD, FMS, and Auxiliary Applications) may be acquired using the either same or different acquisition alternatives defined in this paper.

2. The preferred FMDS infrastructure alternatives will inform the acquisition alternative(s).

3. If multiple vendors are used for the acquisition of the FMDS subsystems, the FAA may serve as the system integrator or may use an outside entity for this function via agreement or contract.

Acquisition Alternatives The FAA is considering multiple acquisition approaches for use in FMDS. Currently, the desired strategy is described below. The FAA may choose either of the strategies below or may pursue a traditional acquisition for FMDS via a prime vendor. Nothing described in this paper is a commitment on the part of the FAA to pursue a particular strategy or necessarily to apply a given strategy exactly as stated. It is intended to generate industry feedback and support further investigation.

Multiple vendor system acquisition Currently, The FAA is investigating a course of action for acquiring FMDS by contracting with multiple vendors to design, build, and maintain the system. This approach could be implemented through multiple contracts, such as by dividing the system into components, each of which is awarded to a different vendor. At a minimum, the system could be divided between FMD, FMS, and the Auxiliary Applications, each competed separately.

The preferred contract vehicle is an Indefinite Delivery Indefinite Quantity (IDIQ) contract with multiple vendors. After the teams are awarded the master contracts, individual system components, such as functional groupings that are included in a single software build, are awarded via Task Orders. They can be awarded as a directed award to a specific vendor or competed within the teams awarded the master contract. The FAA may use a challenge-based multiple down-select strategy to refine requirements and identify the most viable vendors.

This option benefits the FAA in the following ways:

1. Offers long-term flexibility and multiple options for software/services development

2. Spurs innovation through engagement of multiple industry providers

3. Provides opportunity to execute multiple parallel projects (e.g. FMS software builds)

4. Reduces risk of vendor lock throughout system/services lifecycle

5. Increases competition

6. Maximizes opportunity for retention of knowledge and data rights by the FAA

7. Increases TFM domain and system knowledge by industry FAA Responsibilities The FAA performs the following function in the multiple vendor acquisition strategy described above. This list is not exhaustive or static, and it captures the FAA’s thinking as of the current stage of the acquisition process.

1. Establish and own program requirements and engineering design

2. Establish and own system architecture

3. Establish and conduct sustainment activities

4. Establish overall program schedule

5. Issue and manage contracts

6. Grant authority to operate and manage cybersecurity policy

7. Conduct training

8. Respond to audits System Integrator Responsibilities The FAA will either function as the system integrator for the multiple vendors or use an external system integrator via a contract or agreement. If a contractor serves as the system integrator, no duties that are inherently governmental will be assigned to the contractor. Additionally, the system integrator would not be eligible to bid on other components of the acquisition. The FAA retains final approval authority for adoption of system specifications and requirements.

The responsibilities of the system integrator include the following:

1. Provide engineering oversight for all vendors in accordance with FAA requirements and engineering design.

2. Establish software architecture in alignment with FAA system architecture.

3. Develop system specifications in accordance with FMDS system requirements and architecture and ensure all vendor tasks and deliverables align with approved FAA requirements and architecture.

4. Establish and maintain boundaries, platform rules, operating procedures, and system documentation for all vendors.

5. Establish the processes for and oversee conduct of configuration management of all FMDS software, hardware, and documentation.

6. Create and maintain an overall development and integration schedule.

7. Integrate the components produced by multiple developers and support independent testing.

8. Ensure robust use of DevSecOps processes by all vendors and integration with FAA DevSecOps processes.

9. Establish and conduct acceptance processes for all vendor tasks and deliverables.

10. Facilitate root cause analysis for identified issues and implement corrective actions.

11. Ensure products are ready for deployment and release by FAA.

12. Manage quality and risks.

13. Support development and implementation of FAA sustainment plan for FMDS, including support of FAA integration of FMDS into the NAS.

Development Vendor Responsibilities This approach involves additional vendors for software development and provision of the platform/infrastructure used for FMDS. Software development vendors are responsible for the following:

1. Bid on FAA IDIQ task orders

2. Develop FMDS SW builds

3. Follow DevSecOps processes established by the system integrator

4. Follow the boundaries, platform rules, operating procedures, cybersecurity policies, and system documentation administered by the system integrator and in accordance with the FAA contract.

Platform/Infrastructure Provider Responsibilities Finally, the platform/infrastructure vendor is responsible for the following:

1. Provide and operate platform technology used for the FMDS core computing infrastructure

2. Update and patch technology stack used for FMDS

The relationship among the FAA, vendors, platform provider, and system integrator is illustrated in Figure 1.

Figure 1: Summary of Responsibilities Using a Multiple Vendor Acquisition Approach

Additionally, a notional flow of software development activities using this strategy is shown in Figure 2.

Figure 2: Multiple Vendor Software Development Activities Use of multiple vendor strategy necessitates clear establishment of the scope of each vendor task, associated specifications, interface documentation, timelines, and reporting requirements to prevent actual or perceived conflicts between vendors. These activities add complexity to the acquisition planning and execution. The FAA recognizes there are both risks and benefits with this acquisition strategy that is under investigation.

Service acquisition The service acquisition strategy is one where the FAA would contract with a vendor, or multiple vendors, to pay a regular subscription fee to access one or more cloud-based applications that satisfy the established requirements of the FMDS system. The vendor would be responsible for receiving and processing the necessary data sources that contribute to FMDS and delivering the required services to the FAA at a contractually defined demarcation point. The vendor would also conduct all service monitoring and maintenance activities to ensure that the service performs according to contractual requirements. Service design and development would be performed by the vendor and approved by the FAA.

FAA Responsibilities The FAA’s responsibilities using this acquisition approach include the following:

1. Define subscription fees, including performance thresholds full payment

2. Approve design, development, and testing of vendor service

3. Conduct integration testing of FMDS service with other NAS services

4. Conduct security assessments and grant authorization(s) to operate for the defined NAS services, with support from the vendor

5. Perform independent service monitoring and logging

6. Enforce contractual obligations with service provider Service Provider Responsibilities The service provider performs the following functions in this acquisition approach.

1. Design, develop, test, and deploy FMDS services

2. Provide and operate platform/infrastructure for FMDS

3. Perform FMDS service monitoring and issue resolution

4. Maintain development and integration schedule

5. Develop, test, and integrate FMDS software components

The relationship between the FAA and the service provider is shown in Figure 3.

Figure 3. Summary of Responsibilities Using a Service Acquisition Approach Figure 4 shows the cloud-computing infrastructure that would result from a service acquisition, or Software as a Service (SaaS). The figure shows comparison and contrast to On-premises infrastructure, Infrastructure as a Service (IaaS), and Platform as a Service (PaaS). A service acquisition by the FAA would follow the SaaS model. This acquisition option provides various benefits, but the FAA recognizes that it also promotes vendor lock and the agency may face challenges in obtaining security approval for an authorization to operate a decision support tool hosted outside of the NAS.

Figure 4: Service Acquisition Comparison Acronyms

image1.wmf image2.jpeg image3.png image4.jpeg image5.png