AIMMS2 Section C.pdf

FAA Contract No. DTFAWA-14-C-00049 Aeronautical Information Management Modernization S2 (AIMMS2)

Revised 9/11/2024, Mod P00126 25

Part 1 – Section C: Statement of Work

TABLE OF CONTENTS

C.1 INTRODUCTION AND OVERVIEW

C.1.1 Scope of Work

C. 2 APPLICABLE DOCUMENTS

C.2.1 FAA Instructions, Orders, Specifications, and Standards

C.3 REQUIREMENTS

C.3.1 Program Management C.3.1.1 Program Management Plan (PMP) C.3.1.2 Conferences, Reviews and Meetings

C.3.1.2.1 Meeting Agenda and Minutes C.3.1.2.2 Post Award Conference (PAC) C.3.1.2.3 Technical PAC (TPAC) C.3.1.2.4 Program Management Reviews (PMRs) C.3.1.2.5 Technical Interchange Meetings (TIMs) C.3.1.2.6 Ad Hoc Meetings C.3.1.2.7 Program Facility Support

C.3.1.3 Earned Value Management (EVM) C.3.1.4 Risk Management C.3.1.5 System Integration Management C.3.1.6 Commercial Product Management C.3.1.7 Contract Management

C.3.1.7.1 CDRL Delivery C.3.1.8 Quality Assurance (QA) Program

C.3.1.9 Man-Hours and Dollars ($) Expenditure Report C.3.2 System Engineering

C.3.2.1 System Engineering Management C.3.2.2 System/Subsystem Specification (SSS)

C.3.2.2.1 Verification Requirements Traceability Matrix (VRTM) C.3.2.3 Engineering Reviews C.3.2.4 Configuration Management (CM)

C.3.2.4.1 Configuration Planning and Management Requirements C.3.2.4.2 Configuration Items (CIs) C.3.2.4.3 Configuration Baselines C.3.2.4.4 Configuration Control

C.3.2.4.4.1 Engineering Change Proposals (ECPs) C.3.2.4.4.2 Request for Deviation (RFD) C.3.2.4.4.3 Revisions to Engineering Change Proposals/Requests for Deviation C.3.2.4.4.4 Notice of Revision (NOR)

C.3.2.4.5 Configuration Audits C.3.2.5 Human Factors Engineering (HFE) C.3.2.6 Security

Revised 9/11/2024, Mod P00126 26

C.3.2.6.1 Security Directive Compliance C.3.2.7 System Safety

C.3.3 System and Software Architecture C.3.3.1. Software Engineering Management

C.3.3.1.1 Software Assurance C.3.3.1.2 Software Measurements and Reporting

C.3.3.2 System Architecture C.3.3.2.1 System Design C.3.3.2.2 System Requirements Review (SRR) C.3.3.2.3 Preliminary Design Review (PDR)

C.3.3.3 Software Architecture C.3.3.3.1 Software Design C.3.3.3.2 Software Requirements Specification (SRS) C.3.3.3.3 Detailed Design Review (DDR)

C.3.4 System Implementation and Integration C.3.4.1 Software Development

C.3.4.1.1 Software Release and Transition C.3.4.1.2 Software Version Description (SVD) C.3.4.1.3 System Operator Manual (SOM) and End User Instruction Manual (EUIM)

C.3.4.2 System Test and Evaluation C.3.4.2.1 Contractor Master Test Plan (CMTP) C.3.4.2.2 Software Defect Management C.3.4.2.3 Test Environment

C.3.4.2.3.1 Test Equipment C.3.4.2.4 Test Working Group(s) C.3.4.2.5 Test Readiness Review (TRR) C.3.4.2.6 Pre-test Briefings C.3.4.2.7 Post-test Briefings C.3.4.2.8 SWIM Compliance Testing C.3.4.2.9 Factory Acceptance Test (FAT) C.3.4.2.10 Integration Test C.3.4.2.11 System Test C.3.4.2.12 Operational Test Support C.3.4.2.13 Key Site Acceptance Testing (KSAT) C.3.4.2.14 Site Acceptance Test (SAT) C.3.4.2.15 Test Results C.3.4.2.16 Government Acceptance

C.3.5 System Deployment and Maintenance C.3.5.1 Hardware and COTS Software Deployment C.3.5.2 Site Surveys C.3.5.3 Implementation Support C.3.5.4 Operations and Maintenance

C.3.5.4.1 Software Maintenance C.3.5.4.2 Hardware Maintenance and Training

C.3.5.4.2.1 Hardware Maintenance C.3.5.4.2.2 Maintenance Training

Revised 9/11/2024, Mod P00126 27

C.3.5.4.3 AIM Systems Help Desk C.3.5.4.3.1 Operations Documentation C.3.5.4.3.2 User Support Management

C.3.6 Property Management C.3.6.1 Hardware Tracking and Reporting C.3.6.2 Bar Code Requirement C.3.6.3 Disposition

C.3.7 AIMM Future Enhancements C.3.8 AIMM Engineering Services C.3.9 Transition to FCS

Revised 9/11/2024, Mod P00126 28

C.1 INTRODUCTION AND OVERVIEW

Towards the end of the twentieth century the Federal Aviation Administration (FAA) faced soaring air traffic demands yet had antiquated systems, with each system requiring unique interfaces to ingest, filter, parse, and display data such as Notices to Airmen (NOTAMs) or Special Use Airspace (SUA). Numerous automated systems have been implemented to support specific needs, and are unable to integrate with each other, and, given current technology, are expensive to upgrade and maintain. These same automated systems access similar and/or the same Aeronautical Information (AI) thus creating data integrity issues. In addition, the primary infrastructure and interfaces between National Airspace System (NAS) AI systems have remained virtually unchanged. Individual NAS databases have been replicated into multiple databases used by disparate systems and applications. Often there are multiple entry points for the same information largely through error prone manual processes. This data duplication leads to increased maintenance and operations costs in times of shrinking budgets, as well as inconsistent databases purportedly containing identical data. Realizing that current AI systems are not designed to meet soaring air traffic demands, the FAA is modernizing its automation and information systems to meet its mission of providing, “the safest, most efficient aerospace system in the world.”

The FAA Destination 2025 provides the long-term strategic vision for transforming the NAS to meet current and future air traffic demands. The execution of this vision includes the modernization of automation and information systems to meet these growing demands safely and efficiently. The Aeronautical Information Management Modernization (AIMM) program supports the FAA safety mission and Next Generation Air Transportation System (NextGen) objectives by developing automation and information systems and services to address future air traffic requirements and providing aviation users with digital AI that conforms to international standards. The AIMM program’s mission is to develop systems and services to address future air traffic requirements. AIMM consists of Segment 2 (S2) and future possible options and segments.

AIMM Segment 1 (S1) focused on improvements to the Central Altitude Reservation Function (CARF) and the Federal NOTAM System (FNS). AIMM S1 achieved an In Service Decision in March 2013 and is not part of this acquisition. AIMM S2 provides the infrastructure that allows for an enterprise-based approach for AI processing and dissemination, thereby reducing future infrastructure costs in the NAS. AIMM S2 will deliver a software system (the Aeronautical Common Service (ACS)) that provides the ability for the FAA and NAS stakeholders to access aeronautical data (including NOTAMs, Special Activity Airspace (SAA), airport reference and configuration data, procedure data, and obstacle data) in multiple formats; permitting the ability of data service users to customize for themselves delivery and optimizing visual perception and data presentation in a manner that provides value to the consumer. In addition, the ACS will allow the FAA to promote more intelligent use of the NAS by using analytics; thereby improving the operational efficiency of the NAS.

The ACS is composed of the following capabilities:

• Aeronautical Information Query and Subscription Service (AIQS) - Consumers can pull, or receive pushed (on demand, and/or at requested intervals) aeronautical data. Business rules and processes can be defined within the ACS for each consumer to get the AI they need

Revised 9/11/2024, Mod P00126 29 through the publication/subscription (pub/sub) or ad hoc through querying. The AI made available in AIMM S2 includes NOTAMs from the FNS, SAA, airport reference and configuration data, procedure data, and obstacle data.

• Aeronautical Information Integration (AII) – The ACS will translate information from disparate sources into a single consistent format, permitting integration and flexibility of consumption. The ACS can be the trusted source for AI because it uses AI from authoritative sources as established by the respective data stewards. Developing business rules and processes for each type of AI in tandem with the data stewards ensures that all consumers for any type of AI receive the same information. If the source for this data ever changes, consumers need not worry about changing as the ACS will do this transparently.

• Spatial Information Mapping (SIM) - Digitalized data displayed in a geo-referenced map view that integrates and layers information in a spatial context. The ACS provides this information in Aeronautical Information Exchange Model (AIXM) format allowing consumers to fuse various types of AI together for an integrated display. For instance, a consumer can display an airport using the airport reference data, and then layer AI on top of it, such as NOTAMs, SAA, obstacles, or procedures.

• Aeronautical Information Data Analytics (AIDA) - AI integration allows the FAA to promote more intelligent use of the NAS by using analytics.

As a result of the capabilities developed in AIMM S2 the ACS will provide a “seamless information view” from a single trusted access point. AIMM S2 will establish the ACS as the trusted source of AI for internal and external consumers in the NAS, moving from a simple product-centric environment to true AI management. The ACS will create a solid foundation for additional AIMM segments that will continue to deliver greater access, integrity, and extensibility of AI systems to users across the NAS. The ACS system design will leverage the System Wide Information Management (SWIM) investment to support a net-centric enterprise architecture. Consumers will simply have to “on-ramp” to SWIM, a task that has already been done in many cases to receive other data. The AIMM S2 program will distribute NOTAMs, SAA, airport reference and configuration data, procedures data as well as other types of AI through SWIM.

The ACS will follow interface guidelines specified by the NAS Enterprise Messaging Service (NEMS) Interface Control Document (ICD) to connect to NEMS in order to provide an “on-ramp” to the NAS. This will simplify the process of distributing information between programs and will also provide for the ACS to receive information from systems which have services “on-ramped” to the NEMS.

In accordance with the FAA’s implementation of the Office of Management and Budget (OMB) “Cloud First” policy, AIMM S2 will work with the Agency to assess AIMM S2 as a candidate for early implementation of cloud computing capability in the FAA. The program will develop an enterprise approach with horizontal integration across the Air Traffic Organization’s (ATO) Program Management Office (PMO), Enterprise Services, to use cloud computing as a delivery method. FAA Cloud Services (FCS) is a separate procurement and it is anticipated that FCS implementation will not meet the timeline required for timely implementation of AIMM S2.

Therefore a transition platform will be required until such time as AIMM S2 can move to the FCS, as defined in C.3.10. The software in AIMM S2 must be “cloud ready” on this

Revised 9/11/2024, Mod P00126 30 virtualization/hypervisor-type platform with “live migration of virtual machines” for high availability.

For this acquisition the original plan was that the ACS would have to transform airport survey/ Geographic Information System (GIS) data into AIXM 5.1 before distributing to consumers.

This transformation of Airport GIS data as well as procedure ((Area Navigation/Required Navigation Performance/Required Navigation Performance (RNAV/RNP)) data will now be done by the FAA NAVLean program. All finished products transformed by NAVLean will be made available through SWIM compliant Open Geospatial Consortium (OGC) web services and distributed through the ACS. Using two-way Service-Oriented Architecture (SOA), trusted procedure developers will access the NAVLean platform through the ACS One Stop Shop.

Because NAVLean will take much of the data that has traditionally resided on National Airspace System Resources (NASR), the functions and capabilities of NASR will be subsumed into the

ACS.

It is envisioned that the implementation of the ACS may require a phased approach in 2-3 releases but the Government will consider other approaches proposed by Contractors. Overall, however, the Government favors an expedient rollout of capability to meet or exceed stakeholder expectations. These capabilities are identified in the AIMM S2 System Specification Document (SSD) as tagged requirements that must be met no later than the milestone dates defined in Section F. It should be noted that these requirements may be met in earlier releases if deemed feasible by the Contractor’s program budget and schedule. S2 Initial Operating Capability (IOC) will implement the AIMM S2 requirements in the SSD tagged as necessary for the IOC milestone. A second set of requirements are identified in the AIMM S2 SSD as Release 2. All other requirements defined in the AIMM S2 SSD are necessary for the S2 Final Operating Capability (FOC). These milestones are incentivized to promote timely completion.

AIMM S2 is a NextGen enabler supporting Operational Improvements (OI) for Improved Management of Airspace for Special Use [OI 108212] and On-Demand NAS Information [OI 103305], as well as the NextGen OIs in the Bravo (2016-2020) time frame. AIMM S2 supports the RTCA, Task Force 5 by improving delivery of digital SUA information to all NAS users.

AIMM S2 will also support International Civil Aviation Organization (ICAO) standards and practices.

The need for future enhancements including but not limited to AIMM Segment 3 (S3) and Segment 4 (S4) will be evaluated by the Government, as appropriate. Attachment J-10 provides the AIMM Modernization Vision which includes a brief overview of future AIMM capabilities in the S3/S4 timeframes.

C.1.1 Scope of Work

The AIMM S2 flagship product will be the ACS which will modernize and improve the flow of AI through digital collection, management, and distribution tools and create a solid foundation for additional segments as needed.

The Scope of Work requires that the Contractor provide the following:

1. AIMM S2

a. Requirements finalization

b. Software design, development, test, and deployment;

Revised 9/11/2024, Mod P00126 31

c. Hardware and software licensing and maintenance;

d. Commercial-Off-The-Shelf (COTS) software selection, procurement and configuration;

e. Development of technical documentation and user support manuals;

f. Infrastructure to support deployment at two FAA sites; and

g. Program Management.

2. Procurement of support (development, test, maintenance) and operational hardware;

3. Consolidated help desk support for legacy AIM systems and S2;

4. Design, development, test, deployment, and maintenance of future enhancements, as directed by the Government;

5. Development of technical documentation and user support manuals for future enhancements including but not limited to S3 and S4, as directed by the Government; and

6. Engineering Services, to include Transition to FCS, as directed by the Government.

The Scope of Work is further defined by the Contract Data Requirements List (CDRL) forms provided in Attachment J-3 which lists the work products and reports to be delivered to the Government resulting from the specific tasks described in each CDRL. The tasks required are described in section C.3 below and continue in the subsections that follow.

Revised 9/11/2024, Mod P00126 32

C. 2 APPLICABLE DOCUMENTS

The following specifications, handbooks, orders, and standards are applicable. Only the current approved version of these documents as of the contract date applies. In the event of a conflict between this Statement of Work (SOW) and any of the applicable documents cited below, the provisions of this SOW must apply. In the event that an applicable document should change after the contract award date and result in a change to programmatic, technical requirements, and/or design, the Contractor must submit an Engineering Change Proposal (ECP).

C.2.1 FAA Instructions, Orders, Specifications, and Standards

Document ID # Title

FAA Orders and Standards

FAA Order 1370.82A FAA Information Systems Security Program

FAA Order 1600.72A Contractor and Industrial Security Program

FAA Order 8040.4A Safety Risk Management Policy

FAA-STD-026A

FAA Standard Software Development for the National Airspace System (NAS)

FAA-STD-028C FAA Standard Contract Training Programs

FAA-STD-065

Standard Practice Preparation of Web Service Description Documents

FAA-STD-070

Standard Practice Preparation of Web Service Requirements Documents

Other

AIMM S2 Initial ISPD AIMM S2 Initial Implementation Strategy and Planning Document

AIMM S2 SSD 2013-07-31

Aeronautical Information Management Modernization Segment 2 System Specification Document

AMSG T& EPG, April 2013

Acquisition Management System Guidance, Test and Evaluation Process Guidelines, April

ANSI/EIA-649-B

National Consensus Standard for Configuration Management

ANSI/EIA-748C

American National Standards Institute (ANSI)/EIA-748-C Standard for Earned Value Management Systems Intent Guide

ANSI/ISO/ASQ Q9001-2008

American National Standards Institute (ANSI)/American Society for Quality (ASQ) International Organization for Standardization

Revised 9/11/2024, Mod P00126 33

Document ID # Title (ISO) 9001-2008 Quality Management Systems - Requirements

Appendix III to OMB Circular No. A-130 Security of Federal Automated Information Resources

ATO PMO RIO Plan Final PMO Risk, Issue, and Opportunity (RIO) Management Plan, October 1, 2012

ATO-S 2008, Version 2.1 Air Traffic Organization (ATO) Safety Management System Manual

ATO-S 2008-12, Version 1.5 Safety Risk Management Guidance for System Acquisition (SRMGSA)

DOT/FAA/AN-12/XX, June 2012 Acquisition Management System Guidance, Human Factors Acquisition Job Aid

FAA ATO NAS SEM, Version 3.1

Federal Aviation Administration Air Traffic Organization National Airspace System Engineering Manual

FAA Destination 2025 Federal Aviation Administration 2025

FAA System Safety HB Federal Aviation Administration System Safety Handbook, December 30, 2000

FAA Work Breakdown Structure (WBS) FAA WBS Version 5.1 dated July 2013

FIPS PUB 199

Federal Information Processing Standards Publication Standards for Security Categorization of Federal Information and Information Systems

FY13 FAA Security Authorization HB_V2

U.S. Department of Transportation Federal Aviation Administration Fiscal Year 2013 (FY13) Information Systems Security Authorization Handbook

HF-STD-001 Human Factors Design Standard

HF-STD-004

Standard Practice Requirements for a Human Factors Program

ISR Checklist_15AUG2013 In-Service Review (ISR) Checklist Template

MIL-HDBK-61A

Military Handbook Configuration Management Guidance

MIL-STD-46855A

Department of Defense Standard Practice Human Engineering Requirements for Military Systems, Equipment, and Facilities, 24 May 2011

NEMS ICD V4

U.S. Department of Transportation Federal Aviation Administration System Wide Information Management (SWIM) Program

Revised 9/11/2024, Mod P00126 34

Document ID # Title NAS Enterprise Messaging Service (NEMS) Interface Control Document (ICD) Version 4.0

NIST SP 800-18, Rev 1 Guide for Developing Security Plans for Information Technology Systems

NIST SP 800-34, Rev 1 Contingency Planning Guide for Federal Information Systems

NIST SP 800-53, Rev 4 Security and Privacy Controls for Federal Information Systems and Organizations

OMB FCC Strategy Federal Cloud Computing Strategy Solution Guide for Segment 2A_06252013 System Wide Information Management

(SWIM) Solution Guide for Segment 2A Version 1.0, June 25, 2013

SWIM Governance Plan, V3.0

System Wide Information Management (SWIM) Governance Plan, Version 3.0, June 23, 2010

SWIM Governance Policies, V2.0

System Wide Information Management (SWIM) Governance Policies, Version Number 2.0, March 19, 2012

VVSPT-A2-PDD-013

Air Traffic Organization NextGen and Operations Planning Services Test and Evaluation Handbook, Version 2.0, August 31, 2010

Revised 9/11/2024, Mod P00126 35

C.3 REQUIREMENTS

C.3.1 Program Management

The Contractor must establish and maintain an organization to efficiently and effectively execute the requirements of this contract. The Contractor’s Program Management Organization must be responsive to Government program management requirements, control AIMM business and technical activity, ensure compliance with contract requirements, and effectively manage any subcontracts. The Contractor must assign a dedicated Program Manager (PM) to organize, plan, schedule, implement, control, analyze, and report on all elements of the contract. The PM must have sufficient authority to direct, execute, and control all elements of the program subject to governmental review and approval.

C.3.1.1 Program Management Plan (PMP)

The Contractor must develop and deliver an integrated PMP. The PMP must integrate all functional areas (e.g., systems engineering, software engineering, configuration management (CM), risk management (RM), etc.) and define the specific objectives to be accomplished for the successful execution of the program. The PMP must specify the work tasks required to meet the objectives. The PMP must also identify the staffing and other resources required to meet contract requirements.

The PMP must include the Contractor’s CM and RM plans and processes.

The Contractor must develop and deliver a CWBS as Appendix A to the PMP.

The Contractor must develop and deliver a Contract Work Breakdown Structure (CWBS) as Appendix A to the PMP. The CWBS must be developed in accordance with AIMM Data Item Description (DID) AIMM-M-01. The CWBS must include a CWBS dictionary and CWBS index. The Contractor must provide a mapping of the CWBS to the FAA Work Breakdown Structure (WBS) Version 5.1 dated July 2013. The Contractor must use the CWBS as the primary framework for contract planning, budgeting, reporting program cost and schedule status to the Government, and maintain the CWBS throughout the life of the contract. Once approved, the Contractor must not modify the CWBS or associated definitions for any reporting elements identified in the CWBS without written Contracting Officer (CO) approval.

CDRL M01: PMP

C.3.1.2 Conferences, Reviews and Meetings

C.3.1.2.1 Meeting Agenda and Minutes

The Contractor must prepare and deliver for Government approval agendas, meeting minutes, action item lists, and presentation materials for all conferences, reviews and formal meetings.

The Contractor must track action items assigned during meetings until the disposition of the action is mutually agreed to by the Contractor and the Government. Once the action has been completed by the responsible organization and validated by the Government, the action must be closed. The Contractor must maintain a history of all closed action items.

Revised 9/11/2024, Mod P00126 36

CDRL M02: Agenda, Meeting Minutes, Action Item Lists and Presentation Materials

C.3.1.2.2 Post Award Conference (PAC)

The Contractor must plan and conduct a PAC at the Contractor’s facility in accordance with the schedule provided in Section F. The Contractor must be prepared to discuss issues and/or questions, such as:

Roles of the Contractor’s contract management team members;

Contract type, options, deliverables, and delivery schedules;

Special contract clauses;

Incentive features and procedures;

Government Furnished Property (GFP), Government Furnished Information (GFI), or services, if applicable;

Allowable and non-allowable costs, if appropriate;

Contractor reporting requirements;

Contractor’s quality control system/procedures;

Inspection and acceptance provisions;

Invoicing and billing procedures;

The Contractor’s overall responsibilities;

Program schedule;

Requirements;

Need for special technical directions;

Requested waivers and deviations, if any;

CDRLs; and Laboratory facilities (development, testing, etc.), if applicable.

The Contractor must address the status and progress on development of the PMP and CWBS.

C.3.1.2.3 Technical PAC (TPAC)

The Contractor must plan and conduct a TPAC at the Contractor’s facility in accordance with the schedule provided in Section F. The Contractor must demonstrate the ability to accomplish the contractual requirements for AIMM products to include (but not limited to):

1. Engineering and design reviews;

2. Software development;

3. SWIM compliance;

4. System testing;

5. Quality;

6. Deploying to the Cloud; and

7. Deploying to operational sites.

The Contractor must, at a minimum, address the status and progress on development of the following at the TPAC:

1. System Engineering Management Plan (SEMP);

2. Software Development Plan (SDP);

3. Software Release and Transition Plan (SRTP);

Revised 9/11/2024, Mod P00126 37

4. Software Maintenance Plan (SMP),

5. Human Factors Program Plan (HFPP);

6. Commercial Product Management Plan (CPMP); and

7. Plan for supporting the consolidated Legacy help desk and maintenance support.

The Contractor must plan, support, and participate in a TPAC for future enhancements including but not limited to S3 and S4 as directed by the Government.

C.3.1.2.4 Program Management Reviews (PMRs)

The Contractor must conduct and administratively support monthly PMRs in the Washington, DC area beginning at a date to be determined. PMR agendas must be mutually agreed upon between the Contractor and Government. The CO reserves the right to modify the meeting schedule to accommodate special program needs. The monthly PMR must include the status of cost, schedule and performance activities, a summary of findings and resolutions for technical reviews, and any significant non-PMR meetings conducted during the PMR reporting period.

C.3.1.2.5 Technical Interchange Meetings (TIMs)

The Contractor must conduct TIMs as required. The agenda for the TIMs must be mutually agreed upon between the Contractor and Government. The TIMs will provide the working-level forum for the Contractor and the Government to work collaboratively to review alternatives, analyze data, and ultimately make decisions on the various technical issues.

C.3.1.2.6 Ad Hoc Meetings

The Contractor must support ad hoc meetings as directed by the Government.

C.3.1.2.7 Program Facility Support

The Contractor must provide facilities that meet attendance requirements for all conferences, reviews, and meetings. The Contractor must include teleconferencing and web meeting capabilities.

C.3.1.3 Earned Value Management (EVM)

The Contractor must establish, maintain, and use an EVM System (EVMS) that complies with the provisions provided in Section I, paragraph I.2, AMS Clause 1.13-2 Earned Value Management System (January 2013). The Contractor’s EVMS must be used to plan and control cost, identify cost and schedule variances, and measure performance. The Contractor must use the same EVMS for all subcontractors. The Contractor must participate in a Government conducted Integrated Baseline Review (IBR) in accordance with the schedule provided in Section F and provisions provided in Section I. Additional guidance related to IBRs is provided in the FAA’s IBR Guide at fast.faa.gov/docs/IBRGuide.doc.

The Contractor must prepare and submit a monthly IPMR to include an Integrated Master Schedule (IMS). The IPMR must comply with the provisions provided in Section I.

CDRL M03: IPMR

C.3.1.4 Risk Management

The Contractor must implement a Risk and Opportunity Management System (ROMS) for the

Revised 9/11/2024, Mod P00126 38 purpose of conducting risk control and opportunity capture for the AIMM program to meet its technical, cost, and schedule objectives. Risk control must involve early identification and analysis of risks, continuous risk tracking and reassessment, early implementation of corrective actions, communication, documentation, and coordination.

The Contractor must identify, analyze, and prioritize risks and opportunities and develop recommended courses of action. In assessing strategic and technical risks or opportunities any interdependencies with other programs must be considered. Interdependencies must be documented in the risk/opportunity assessment submission described below.

The Contractor must develop and maintain a list identifying, analyzing, and classifying program risks/opportunities. Program risks must be classified using a 5x5 matrix for probability of occurrence and severity of impact, in accordance with the FAA System Engineering Manual (SEM), Section 4.10. The Contractor must develop risk mitigation plans for risks considered medium or high priority; and capture plans for opportunities.

The Contractor must provide the status of risks and opportunities at the monthly PMRs and in PMR presentation materials.

The Risk Management Program must be documented in the Risk Management section of the PMP. The Contractor’s Risk Management Program must follow the guidance provided in the FAA System Engineering Manual and the FAA PMO Risk, Issue and Opportunity (RIO) Management Plan. The RIO Management Plan will be provided as GFI.

C.3.1.5 System Integration Management

The Contractor must be responsible for developing, selecting, testing, integrating, and deploying the proposed developmental and/or COTS/Non-Development Item (NDI) software and hardware products as a system. The Contractor must function as a single-point of contact for program-level integration of the AIMM software. Program-level integration and schedule activities must include, but not be limited to, program management, technical reviews, interface management, testing, and coordination of deployment planning.

C.3.1.6 Commercial Product Management

The Contractor must develop and deliver a CPMP. The CPMP must describe how the Contractor will manage commercial hardware, software, and firmware products including NDI and GFP commercial products that are used in the AIMM products. The Contractor must establish and execute a commercial product management program based on the approved CPMP.

CDRL M04: CPMP

C.3.1.7 Contract Management

C.3.1.7.1 CDRL Delivery

The Contractor must use the FAA web-based system for the electronic delivery of all official CDRLs. The Contractor must provide a letter of transmittal via email to the CO.

Revised 9/11/2024, Mod P00126 39

The Contractor must provide to the Government, no later than 14 calendar days after contract award, the following information for each employee requiring access to the FAA web-based system:

1. Name

2. E-mail address

3. Work phone number

4. Functional responsibility

C.3.1.8 Quality Assurance (QA) Program

QA is applicable to all phases of the AIMM Program. In addition to the requirements in Section E, the Contractor must establish and maintain a QA program in accordance with American National Standards Institute (ANSI)/American Society for Quality (ASQ) International Organization for Standardization (ISO) 9001-2008, or equivalent.

The inspection requirements specifically set forth in this SOW and Section E must become a part of the Contractor's overall QA program. The absence of Government inspection does not relieve the Contractor of the responsibility of ensuring that all products or supplies submitted to the Government for acceptance comply with all requirements of the contract. The Contractor must establish and maintain a QA program and provide the procedures and controls to ensure that all requirements of the contract are met.

The Contractor must provide the status of QA program at the monthly PMRs and in PMR presentation materials.

The Contractor must develop and deliver a Quality System Plan (QSP). The QSP must document the Contractor’s overall QA program.

CDRL E18: QSP

C.3.1.9 Man-Hours and Dollars ($) Expenditure Report

The Contractor must prepare and deliver a contract man-hours and Dollars ($) Expenditure report for Contract Line Item (CLIN) 1602, monthly. This report provides the Government visibility into the contractor monthly expenditures for labor hours and Dollars ($), and includes a comparison to definitized contract Modification P00108, as follows:

Revised 9/11/2024, Mod P00126 40

Option Period 6 – CLIN 1602

CDRL M05: Man-Hours and Dollars ($) Expenditure Report

C.3.2 System Engineering

C.3.2.1 System Engineering Management

The Contractor must develop and deliver for Government approval a SEMP. The SEMP must document the Contractor’s system engineering management program. The Contractor’s SEMP must be compliant with the FAA NAS SEM, Version 3.1

CDRL E01: SEMP

C.3.2.2 System/Subsystem Specification (SSS)

The Contractor must develop and deliver a SSS, Volume I.

The Contractor must analyze all the requirements provided in the AIMM S2 SSD provided as Attachment J-1. The Contractor must identify the major functional subsystems of the system and, for each subsystem, must document the expanded requirements in the SSS. The Contractor must define and allocate the requirements as required and document them in the AIMM SSS.

The Contractor must use the Dynamic Object Orientated Requirements System (DOORS) tool, or an alternative approved by the FAA, to support requirements traceability between the SSS, the AIMM S2 SSD, and the Contractor’s associated design documents. If an alternative to DOORS is approved, the Contractor must provide the Government with requirements in a DOORS compatible format for Government requirements management.

CDRL E02: SSS, Volume I

Revised 9/11/2024, Mod P00126 41

C.3.2.2.1 Verification Requirements Traceability Matrix (VRTM)

The Contractor must develop and deliver a VRTM. The VRTM must document the following for each requirement in the SSS:

1. Identify the requirement traceability between the Contractor-developed SSS and the government-supplied AIMM S2 SSD, and

2. Specify the qualification status (whether the test is applicable or deferred) and method of verification.

CDRL E02: SSS, Volume II (VRTM)

C.3.2.3 Engineering Reviews

The Contractor must conduct all engineering reviews at the Contractor’s facility. These reviews must support the system software design and development phases and demonstrate the Contractor’s readiness to proceed to the next stage. The Contractor must establish a Requirements Clarification (RC) process for the purpose of documenting and resolving potential discrepancies and/or ambiguities with baseline systems requirements as written. These RC’s may include clarification of GFI provided as Attachment J-7. The RC must be used to:

1. Clarify existing requirements;

2. Document the dispositions to resolve requirements discrepancies and/or ambiguities; and

3. Propose requirements changes in response to discrepancies and/or ambiguities which arise during the lifecycle of the AIMM Program. Recommended changes to the baseline must be processed in accordance with Section C, paragraph C.3.2.4.

The Contractor must notify the CO of readiness for a review at least 20 business days in advance of the planned start date.

The Contractor must provide information on design-related activities as required by this contract and as directed by the Government.

The Contractor must complete the engineering reviews, including disposition of all action items, prior to starting the development phase, unless the Government provides explicit, written approval in advance excusing the Contractor from doing so.

C.3.2.4 Configuration Management (CM)

The Contractor must establish, within its organization, the practices, policies, and procedures for implementing the requirements of a CM program using best commercial practices.

C.3.2.4.1 Configuration Planning and Management Requirements

The Contractor must establish and maintain a CM program to manage all software, documentation, physical media, test/support items, and hardware pertaining to the AIMM program.

The Contractor’s CM program must be documented in the CM section of the PMP.

Revised 9/11/2024, Mod P00126 42

C.3.2.4.2 Configuration Items (CIs)

For CM purposes, CIs include all hardware and software items that comprise the configuration baselines. For hardware CIs (HWCIs), the indenture levels must be defined by the Contractor in a top-down, break-down order to the Lowest Replaceable Unit (LRU), and include all parts including Government specification or vendor-specific parts. NDI used in the AIMM S2 baseline must be annotated as NDI. COTS and modified COTS items used in the AIMM S2 baseline must be annotated as such. Developed Computer Software Configuration Items (CSCIs) should be identified similarly, identifying the flow down from top-level CSCIs to Computer Software Component (CSCs). Any software NDI must be similarly annotated in the top-down listing. These documents must be maintained by the Contractor through the development life-cycle and must be made available for use during the configuration audits.

C.3.2.4.3 Configuration Baselines

The Functional Baseline (FBL), Allocated Baseline (ABL) and Product Baseline (PBL) must be documented in a Configuration Status Accounting Report (CSAR). The FBL consists of the AIMM S2 SSD which will be maintained by the Government. The ABL consists of the SSS, the Web Services Description Document (WSDD), and the approved System/Subsystem Design Document (SSDD). The PBL must be established after the successful completion of the Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA), and must reflect the correction of configuration audit deficiencies.

CDRL C01: CSAR

C.3.2.4.4 Configuration Control

C.3.2.4.4.1 Engineering Change Proposals (ECPs)

The Contractor must prepare Class I ECPs when a proposed baseline change affects any CI(s) form, fit, or function, corrects a deficiency, or impacts logistics documentation or support.

The Contractor must deliver all ECPs for Government approval.

CDRL C02: ECP

C.3.2.4.4.2 Request for Deviation (RFD)

The Contractor must prepare a RFD for Government review and approval/disapproval any time the Contractor wishes to request temporary relief from a requirement of any functional, allocated, or product configuration documentation.

No items that incorporate a known departure from requirements will be delivered by the Contractor for acceptance by the Government, unless the Government has approved a RFD.

Authorized deviations are a temporary departure from requirements and do not constitute a change to the PBL documentation. Deviations do not apply to software code listings. An ECP must be processed when it is determined that a change should be permanent.

CDRL C03: RFD

Revised 9/11/2024, Mod P00126 43

C.3.2.4.4.3 Revisions to Engineering Change Proposals/Requests for Deviation

Revisions made to ECPs/RFDs must be designated as Rev1, Rev2, etc. No revisions to ECPs/RFDs will add new requirements to the original submission. No revisions to ECPs/RFDs will be permitted after they have been approved.

C.3.2.4.4.4 Notice of Revision (NOR)

The Contractor must prepare a NOR concurrent with a Class I ECP for each specification that would require revision if the ECP were approved. The NOR must also be used to describe where and how the specification change will be made, provide instructions for pen and ink changes for minor changes, or provide replacement specification pages.

A NOR must be used to describe the exact change(s) to be made to each drawing, associated list, or other affected document. NORs must be prepared in a format containing information required to accurately describe and implement the change. A NOR must be an ancillary document to the ECP which conveys the specific change to a specific document. A NOR is required when: (1) the ECP is proposed by the Government (in the role of tasking or performing activity); (2) the party proposing the ECP is not the Current Document Change Authority (CDCA) of the document being changed by the ECP; or (3) the party proposing the ECP is not responsible for pricing logistics support impact.

CDRL C04: NOR

C.3.2.4.5 Configuration Audits

The Contractor must prepare a Configuration Audit Plan/Report using MIL-HDBK-61A as guidance. An FCA/PCA must be performed on the software and hardware at the Contractor’s facility in support of Government Acceptance (GA) for each release. The Contractor must support the conduct of Government Configuration Audits. Audits must be performed to validate that all CIs have been developed in accordance with the functional and performance requirements of the specification(s) and that they accurately reflect the production configuration design documentation. The Contractor must report the FCA/PCA results in the Configuration Audit Report using MIL-HDBK-61A as guidance. The satisfactory completion of the audits, as approved by the Government, must establish the product baseline.

A list of all approved and in-process changes against hardware and software and documentation must be presented to the audit team at the beginning of the audit period.

CDRL C05: Configuration Audit Plan/Report

C.3.2.5 Human Factors Engineering (HFE)

The Contractor must develop the AIMM software in accordance with HFE best practices and standards, including the Human Factors Design Standard (HFDS) (HF-STD-001). To ensure the AIMM S2 system is developed following the FAA HFDS, the Contractor must develop a Human Factors Program Plan (HFPP) in accordance with MIL-STD-46855A and the Acquisition Management System Guidance, Human Factors Job Aid (DOT/FAA/AN-12/XX, June 2012).

The HFPP must accommodate the HFDS and the requirements for a Human Factors Program as defined in HF-STD-004. In case of conflicting requirements between the AIMM S2 SSD, HF- STD-004, and the HFDS, the HFDS must have precedence.

Revised 9/11/2024, Mod P00126 44

The Contractor must include HFE as an element of program management activities such as PMRs, design reviews, software/system demonstrations, and TIMs.

The Contractor must conduct Human in the Loop (HITL) exercises as identified in the approved HFPP. The goal of the HITL must be to ensure the AIMM S2 system meets the AIMM S2 SSD requirements.

The Contractor must develop a Graphic User Interface (GUI) Design Document for AIMM website(s) and, if applicable, system administration, system operations, and system maintenance positions.

CDRL HF01: HFPP

CDRL HF02: GUI Interface Design Document

C.3.2.6 Security

3 During the lifecycle of the AIMM program and contract period of performance, it is anticipated the FAA will transition from conducting annual security assessments to continuous monitoring of FAA programs. Continuous monitoring facilitates ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions.

The terms continuous and ongoing imply that organizations assess/analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations. Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies. Having access to security-related information on demand gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of information systems.

The Contractor must comply with the Information System Security Program, FAA Order 1370.82A (as amended), and the ATO Information System Security (ISS) Authorization Handbook (latest revision).

The Contractor must support development of the AIMM Security Authorization Package to ensure the AIMM S2 software successfully passes the certification and authorization processes as directed by the Government.

The AIMM security program must be documented in the AIMM System Security Plan (SSP).

The Contractor must mitigate all risks as directed by the Government. The SSP must apply to all phases of the program. The Contractor must meet all requirements of AIMM S2 SSD.

The Contractor must comply with the AIMM ISS Program managed and operated by the FAA

Revised 9/11/2024, Mod P00126 45 including compliance with industry-standard security engineering principles and a system development lifecycle methodology utilizing information security considerations. Security activities must be conducted in accordance with Government information security requirements as defined in Section C.2.0 (Applicable Documents). The Contractor must support required Government security authorization activities for the AIMM software. The Contractor must provide the necessary information to support the Government in updating security authorization documents, as well as annual security assessment documents in accordance with guidance and current templates provided by the FAA ISS Program Office.

The Contractor must support the Government in conducting risk assessments, conducting contingency/disaster recovery planning and testing, and security testing and evaluation in accordance with the requirements of the FAA ISS Program. The Contractor must also support the Government by responding to the risk identified by the risk assessment.

The Contractor must ensure that appropriate documentation is provided describing the functional properties of the security controls employed within the information system with sufficient detail to permit analysis and testing of the controls. The Contractor must support the development and implementation of other security related documentation as required. The Contractor must develop and submit to Government, for approval, Security Standard Operating Procedures (SSOPs) in accordance with the requirements established by the FAA ISS Program.

The Contractor must develop and deliver the Information System Contingency Plan (ISCP). The ISCP must identify the system’s concept of operations, essential resources and points of contact (POC), and processes and procedures to follow in the event of a major system outage. The ISCP is based on National Institute of Standards and Technology (NIST) Special Publication 800-34 Contingency Planning Guide for Information Technology Systems.

The Contractor must develop and deliver the System Characterization Document (SCD). The SCD must document the system description, including the system overview and mission, system architecture, hardware and software, internal and external connectivity, and system data/information types, sensitivity, and criticality.

Security testing must be conducted as part of the overall test program. Security testing must be addressed in the Test Plan, Test Procedures, and Test Report for applicable tests.

The Contractor must conduct annual ISCP testing as required by the OMB and Federal Information Security Management Act (FISMA). The Contractor must document and deliver the results of ISCP testing in the ISCP Test Plan and Results Report.

CDRL S01: SSP

CDRL S02: ISCP Test Plan and Results Report

CDRL S03: ISCP

CDRL S04: SCD

CDRL S05: SSOP

Revised 9/11/2024, Mod P00126 46

C.3.2.6.1 Security Directive Compliance

The Contractor must provide security in accordance with FAA Order 1370.82A, FAA Information Systems Security Program. The system development process must be guided by the following documents: Appendix III to OMB Circular No. A-130, Security of Federal Automated Information Resources; FAA Order 1600.72A, Contractor and Industrial Security Program; and the NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems.

C.3.2.7 System Safety

The Contractor must develop and execute a system safety program in accordance with the Safety Risk Management Guidance for System Acquisitions (SRMGSA), dated December 2008, and the System Safety Program Plan (SSPP), as approved by the FAA. The Contractor SSPP must be in agreement with the FAA provided AIMM Program Safety Plan (PSP). The primary objective of the System Safety Program must be to identify, evaluate, and eliminate or control hazards to the NAS to a level acceptable to the FAA throughout the AIMM program’s life cycle.

The Contractor must use the FAA provided Preliminary Hazard Analysis (PHA) as the initial set of identified hazards for the System Safety Program. This objective must be accomplished through the execution of a disciplined SE-based methodology to achieve Safety Risk Management (SRM) IAW FAA Order 8040.4.

The Contractor must utilize the FAA System Safety Handbook and the FAA ATO Safety Management System (SMS) Manual as guidance. The SMS integrates current FAA safety related operational policies, processes and procedures as well as introduces new elements necessary for a system approach to managing the safety risk of providing air traffic control and navigation services. When evaluating risk, the 5-by-5 Risk Matrix in the SMS Manual must be used.

The Contractor must prepare a SSPP to document in detail how the total system safety program will be conducted. Furthermore, the Contractor must:

1. Develop and deliver a Subsystem Hazard Analysis (SSHA);

2. Develop and deliver System Hazard Analysis (SHA);

3. Develop and deliver an Operating and Support Hazard Analysis (O&SHA);

4. Develop and deliver a System Safety Assessment Report (SSAR);

5. Provide status of identified hazards as required that include the status of validation and verifications of safety requirements - Safety Requirements Verification Tracking (SRVT) List;

6. Provide either written or oral status of the safety program at program management reviews as required and present Hazard Tracking and Incident Analysis data; and

7. Support and participate in system safety working groups as required or as requested by the

FAA.

CDRL SF01: SSPP

CDRL SF02: SSHA

CDRL SF03: O&SHA

CDRL SF04: SSAR

CDRL SF05: SHA

CDRL SF06: SRVT

Revised 9/11/2024, Mod P00126 47

C.3.3 System and Software Architecture

The Contractor must design a system architecture that meets the requirements of the AIMM S2 SSD.