Notice to Air Missions (NOTAM) System/Services   2

*****Update Submission Due Date extended to 5/18/23 at 5:00PM (EST).****

NOTICE TO AIR MISSIONS (NOTAM) SYSTEM/SERVICES

MARKET SURVEY/ REQUEST FOR INFORMATION

This Market Survey/Request for Information (RFI) is being issued in accordance with the Federal Aviation Administration (FAA) Acquisition Management System (AMS) Policy 3.2.1.2.1.

I. PURPOSE

This Market Survey/RFI seeks to identify existing Notice to Air Mission (NOTAM) systems and services available within industry available to meet the FAA's requirements for the origination, management, and dissemination of NOTAM information throughout the NOTAM lifecycle.

The purpose of this Market Survey/RFI is to:

1. Inform Industry of the FAA's end state objectives for managing the NOTAM lifecycle and to solicit Industry feedback.
2. Assess market interest and existing industry capabilities to provide systems and services for the lifecycle management of NOTAMs.
3. Determine the degree of customization required to enable integration of existing industry NOTAM capabilities into the FAA infrastructure.
4. Obtain feedback from Industry on risks, considerations, and other related feedback on the FAA's concept for managing the NOTAM lifecycle.

II. CURRENT FAA NOTAM SYSTEMS

Today, in the As-Is state, the FAA has two, interconnected, NOTAM systems. The legacy US NOTAM System (USNS) is the authoritative source for NOTAMs, though various functions have been migrated over time to the newer Federal NOTAM System (FNS). FNS has most NOTAM origination, management, and distribution capabilities operational in parallel to USNS, with the most notable exceptions being that only USNS issues authoritative NOTAM numbers and interfaces with International NOTAM Offices via the Aeronautical Fixed Telecommunication Network (AFTN) for the exchange of NOTAM and other information.

The FNS supports the digital NOTAM concept following the Aeronautical Information eXchange Model (AIXM) Event Specification and NOTAM scenarios. Even though FNS is operational and has been making progress towards digitizing and centralizing NOTAM management, the US NOTAM environment is characterized by a mix of legacy and modernized capabilities, with redundant systems and data flows. There are many applications, web services, and databases that comprise both the legacy USNS and the FNS to support the FAA's NOTAM origination, management, and distribution capabilities. These systems are required to interface with the authoritative source aeronautical information systems, which include various data formats, to support the digital NOTAM concept. These two current NOTAM systems reside on on-premises hardware and interface with the FAA's NAS Enterprise Security Gateway (NESG), the FAA's System Wide Information Management (SWIM) network, and the FAA's National Airspace Data Interchange Network (NADIN) to access AFTN. A conceptual view of the complex current FAA NOTAM System can be seen in Figure 1 (See Attachment).

III. NOTAM SYSTEM/SERVICE END STATE OBJECTIVES

Notice to Air Mission (NOTAM) provides critical information essential for safe flight operations that are not known far in advance. They provide the abnormal status of a component of the National Airspace System (NAS). NOTAMs are time-sensitive and mandatory to be reviewed before takeoff per CFR 91.103(a)(1), which states that pilots must become familiar with all available information concerning the flight, including NOTAMs that could affect the safety of the flight. Lack of this information in a timely manner could disrupt NAS operations. NOTAMs have existed for more than seven decades and have been issued as concise text strings containing contractions in capital letters as they were built for communication via the teletype channels that had constraints on the length of the messages. There were numerous disadvantages to using this mechanism, including but not limited to the non-standard use of these messages to communicate the same information.

Digital NOTAMs eliminate the limitations of the text-based NOTAMs by encoding the temporary change being captured by a NOTAM into a digital model allowing standardization and transformation into different formats, including geospatial representation. The latest versions of the Aeronautical Information Exchange Model (AIXM), starting at 5.0, were built to support digital NOTAM representation and dissemination to enable machine interpretation of this critical information.

The FAA's objective is to provide an end-to-end digital NOTAM platform that supports the lifecycle management of NOTAMs, including origination/collection, management, and distribution and provides flexibility and scalability for future growth of new entrants into the airspace.

NOTAM Origination/Collection Platform

• The NOTAM collection/origination platform must support both a user and machine interface. Authorized NOTAM originators will use the human interface via a browser to create and manage their NOTAMs. Third-party systems will interface their systems to the NOTAM system to issue and manage NOTAMs via application programming interfaces (APIs).
• The user interface must be a web application with no additional products or plugins to be downloaded to provide complete functionality. The web application must be able to support all modern browser platforms.
• While NOTAMs are the final artifact or by-product, the platform must capture the changes to an aeronautical feature as temporary changes following the AIXM temporality model.
• Both the user and machine interfaces must support the FAA's digital NOTAM event specification, where the various temporary events are described as scenarios. The scenarios include data elements required to describe the event, associated business rules, and transformation rules to convert the digitally captured data into FAA's current NOTAM format as described in JO 7930.2 (latest version), International Civil Aviation Organization (ICAO) NOTAM format, and Plain Language format.
• The platform must support both digital NOTAMs and free-text NOTAMs. While digital NOTAMs are preferred, the option for free form (non-digital) is required to support unexpected or rare events.
• All temporary events (NOTAMs) must be entered (encoded) at the source, and the originator will be responsible for both entering it in a timely manner and quality-checking the information. This means the originator must have access to only their relevant scenarios and features.
• The system must make available baseline (static) information to ensure a consistent view of the underlying feature. This is for enhancing the reliability and accuracy of the encoded temporary event.
• The NOTAM scenarios/event specification must be presented to the user as form elements associated with a scenario. The form associated with a scenario/event must ONLY contain elements relevant to that scenario.
• The originator must be presented a graphical view of the underlying aeronautical features for the selected facility/feature so there is no ambiguity on which feature they are issuing a NOTAM on.
• The originator must be able to view the transformation of the digitally captured information (via scenarios) into various formats, including FAA format (as described in JO 7930.2), ICAO, and plain language format.
• The system must allow changes or additions to digital scenarios/events via a meta-data model. In other words, changes to form display, rules, and transformation must be data-driven so changes can be incorporated without requiring software code updates. An editor to manage the meta-model is required to support the maintenance of these scenarios.
• The digital NOTAM system must provide validation against business rules and publish the approved temporary events (NOTAM). Transformation to multiple output formats will be provided as a service to help with human interpretation.
• To ensure consistency, a particular event must always be encoded the same way in the NOTAM system. For example, the closure of a Runway will require specific elements of the AIXM XML to be populated.
• The system must provide an optional pre-validate capability that takes the encoded event through validation and transformation. This allows the originator to view the transformation of the encoded event and also look for potential failures due to business rule validations before the event is actually submitted for activation. Events submitted for pre-validation must not be stored in the system.
• The system must require mandatory metadata to accompany the encoded event. This could include information regarding the user inputting the information and other contact details. This is to enhance the traceability of the published events.
• For a subset of NOTAMS submission of the encoded events to the system must go through a workflow process, including validation and transformation, before it is approved for publication. Failure at any point of the workflow process must return an error message to the originator.
• The system must support a workflow process for some NOTAM scenarios that require review of the NOTAM data by additional user roles prior to NOTAM publication.
• The platform must provide the capability to originate NOTAMs via a machine interface. The message must be encoded following the digital NOTAM specification.
• The platform must be able to manage user information, user roles/permissions, and provide multi-factor authentication for user access.
  • System must include support for decentralized user management. In other words, individual facilities (airports for example) must be able to administer and manage their own users.
  • All the users with access to a facility must be able to view, originate and manage NOTAMs at that facility.
• The platform must include notification capability via email and other channels to communicate the origination and cancellation of NOTAMs. The originator must be able to add the list of users who would receive these notifications.

NOTAM Management Platform

• Baseline data is a critical component of a digital NOTAM platform to ensure the temporary change is applied over the static feature state.
  • The system must be able to ingest all relevant aeronautical baseline data from FAA's authoritative sources.
  • Each data source follows its own bespoke format, so the system must have data adapters to interface with these sources.
  • Publication timeframes of the baseline data vary based on type. While most of the data is published every AIRAC (28 days) cycle, certain data types are published daily or on different cycles.
  • It is critical for the NOTAM system to have the latest baseline data to ensure temporary changes are applied to the latest published static data.
• The NOTAM platform must support dynamic workflow capability allowing different workflows to support different stakeholder needs.
• Support for all rules, numbering, and workflow must be in accordance with FAA's NOTAM policy JO 7930.2 (latest version).
• The NOTAM platform must support five different NOTAM types. This includes Domestic, FDC, Military, Local Military, and International NOTAMs. Details can be found in the FAA NOTAM policy (JO 7930.2)
• The system must also be ready to transition in the future to the ICAO NOTAM policy following ICAO Annex-15 NOTAM requirements as adopted by the FAA.
• The system must be capable of supporting and managing multi-part NOTAMs. This includes splitting the NOTAMs into multi-parts and consolidating them into single NOTAMs.
• The management of NOTAMs is a critical function, and the NOTAM Office plays a central role in ensuring the accuracy, timeliness, and completeness of NOTAM information. The following are some key requirements for a NOTAM Office to manage NOTAMs effectively:
  • Access to up-to-date information: The NOTAM Office must have access to all the NOTAMs to ensure that they are accurate and comprehensive.
  • NOTAM Office must have the ability to approve certain types of NOTAM based on the FAA NOTAM Policy 7930.2 prior to NOTAM publication.
  • NOTAM Office collaborates with numerous stakeholders, including International NOTAM offices. The NOTAM platform must support these requirements to include NOTAM/message ingestion from, NOTAM/message distribution to, and message exchanges with foreign nations via the AFTN/NADIN network.
  • Compliance with regulatory requirements: The NOTAM Office must comply with all relevant regulatory requirements, such as those set forth by the FAA, to ensure the safety and efficiency of air navigation. The system must have the capability to support this requirement.
  • Not all NOTAMs are transmitted to international NOTAM offices. NOTAM Office personnel must have capability to identify and transmit certain set of NOTAMs that meet the policy criteria.
  • While FAA currently does not follow ICAO format for NOTAMs, the ones distributed internationally must be converted to ICAO format.
• The NOTAM platform must be able to automatically process NOTAM Checklists ( a list of all active NOTAMS at a given time) for foreign nations with minimal intervention from the NOTAM Office personnel. The NOTAM platform must also be able to issue US Checklist NOTAMS. Flight Service (FS) plays a key role in the management of NOTAMs. The system must be able to allow Flight Service personnel to create and review NOTAMs. FS personnel are distributed across services and flight plan areas defined by geography. The system must be able to route incoming NOTAMs requiring review based on these area definitions. Furthermore, the FS personnel must be able to lock the NOTAMs for review preventing access by other personnel.
• Given the large number of FS personnel distributed across different flight service area and flight plan areas, the system must have the ability to present NOTAMs to FS users based on their active service area(s).
• The system must include reporting functionality. Preferably the reporting capability should be configurable along the lines of business intelligence tools to meet the diverse needs of the user community without the need for software updates.
  • NOTAM Originators need access to multiple years' worth of NOTAM to meet their regulatory requirements.
• The system must provide logging functionality with log archival and retrieval.
• The system must provide system monitoring and control functionality.

NOTAM Distribution Platform

• Access to NOTAM data must be made available via both a human interface and a machine interface.
• Human interface via a web browser must support searching, filtering, and sorting. Search criteria, at a minimum, must include location, geospatial, and flight path search.
• In addition to providing timely access to all active NOTAMs, the NOTAM platform must also provide access to a minimum of three-year archive.
• The human interface must graphically display NOTAMs where the geospatial data is available. For example, temporary flight restrictions must be displayed graphically.
• The system must provide a machine interface that integrates with FAA's SWIM providing both a request/response and a publish/subscribe capability.
• The system must support legacy NOTAM distribution XML interfaces (e.g. XML Query) to minimize impacts to existing NAS systems.
• The request/response interface must, at a minimum, support access to all active NOTAMs at any point in time and access to changes (new and updates) for the past seventy-two hours.
• The payload for the encoded events provided via the machine interface must be at a minimum in AIXM and preferably in other additional formats, including GeoJSON.
• The system must not alter any information entered at the source. Exceptions resulting from invalid encoding must be provided to the originator for correction. Valid and approved events (NOTAMs) contain original encoded events by the originator and transformations provided to help with human interpretation.

Availability Requirements

• The system must be hosted in multiple geographically separate locations within the United States in an active-active configuration, ensuring the unavailability of services at a single location does not affect the NOTAM system operations.
• Access to the NOTAM services must be seamless for the user, irrespective of the number of sites supporting the system. This should preferably be achieved via geolocation-based routing. Failover or switchover between sites must be transparent to the user.
• The total unplanned outage of the system must not exceed a total of sixty minutes in a year. Each unplanned event cannot exceed fifteen minutes.
• Planned outages to support operations and maintenance activities must be coordinated and communicated at least six weeks in advanced and implemented only after written approval from the FAA. The expectation is that maintenance related outages are minimized and are planned to have minimal to zero impact to users.

Transition/Implementation Requirements

• To the extent a solution requires additional development, FAA's development practices including DevSecOps tool guidance, and zero trust guidance shall apply.
• The NOTAM Platform must follow a rigorous test and evaluation process that meets the requirements of the FAA's Test and Evaluation Handbook.
• The NOTAM Platform must include system specification, description, and maintenance documentation to meet FAA NAS configuration management and second level engineering needs.
• The NOTAM Platform must include user manuals, reference guides, and training documentation for end users and system maintainers.
• The implementation of the NOTAM Platform must consider existing user groups and result in no loss of NOTAM information.
• The vendor shall apply an effective stakeholder engagement process to identify, manage and validate feedback. The NOTAM stakeholders include airspace users and aeronautical infrastructure providers that need to notify users of any change in the status of a component of the NAS.

IV. CONSTRAINTS/CHALLENGES

The new NOTAM system/service requires integration into the existing FAA infrastructure that accounts for FAA safety, security, and integration processes. The FAA anticipates a NOTAM system/service transition structure that includes the following constraints:

• Safety Risk Management: Commercial vendors would implement a formal, disciplined, and documented decision-making process to address safety risks. Integration of the vendor's system/service would be required to successfully meet all requirements and outcomes of the FAA safety risk management process. This process is governed by FAA Order 8040.4A Safety Risk Management Policy which identifies policy and procedures for implementing safety risk management within the FAA.
• Information System Security: Organizations, system or services wishing to interface with the FAA need to ensure the following cybersecurity considerations:
• FAA policies align with applicable law and policies, including, but not limited to:
• The Federal Information Security Modernization Act (FISMA) 2014;
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource, and
• Various National Institute of Standards and Technology (NIST) documents. The NIST documents include, but are not limited to
  • Special Publication (SP) 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations;
  • NIST 800-37 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy ;
  • NIST 800-39 Managing Information Security Risk: Organization, Mission, and Information System View; and,
  • NIST Cybersecurity Framework.
• FAA also complies with Executive Orders (EOs) that define critical infrastructure and the protection of it, outline risk management for critical infrastructure, and prioritize strengthening of cybersecurity in federal networks and implementation of zero trust and multi factor authentication. The EOs include, but are not limited to:
• • EO 13011: Federal Information Technology;
  • EO 13231: Critical Infrastructure Protection in the Information Age;
  • EO 13636: Improving Critical Infrastructure Cybersecurity; and,
  • EO 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure; and, EO 14028: Improving the Nation's Cybersecurity.
• The FAA Information Security and Privacy Service assigns organizational, management, and user responsibilities to develop, direct, and facilitate the consistent implementation of tailored FAA information security and privacy programs across all FAA organizations and systems.
• The FAA's Air Traffic Organization (ATO) is the air navigation service provider for the United States. All FAA systems, including those controlling air traffic, must be Authorized to Operate (ATO) per the FAA authorization process.
• Based on (NIST) 800-37 R2 (Appendix F, p 139), Authorization is the process by which a senior management official, the authorizing official, reviews security and privacy information describing the current security and privacy posture of information systems or common controls that are inherited by systems. The authorizing official uses this information to determine if the mission/business risk of operating a system or providing common controls is acceptable and if it is, explicitly accepts the risk.
• Identifying and then assessing the strength of NIST Controls is the primary way that we protect against cyber threats. Through its risk management processes, the FAA provides cyber requirements around selected security controls, assesses the implementation of those controls required upon systems, and maintains awareness through monitoring of changes in current and future risk.
• Access to NAS Data: Currently the FAA's NOTAM systems access NAS and FAA Mission Support systems for baseline aeronautical data to support digital NOTAMs.
• Digital NOTAMs: The NOTAM platform must be able to support the Aeronautical Information eXchange Model (AIXM) using authoritative source static baseline data (e.g. runway, taxiway, navigational equipment, obstacle, airspace, etc. definitions) and defining the digital NOTAM changes using the AIXM temporality model.
• FAA Workforce Transition: The NOTAM platform requires integration with the FAA's labor rules to transition users to the new system/service. This may include ensuring the system requirements meet unique user needs and the transition plan accounts for the FAA's labor relations processes.

V. ASSUMPTIONS

The FAA has made the following assumptions based on the current operational environment and available technology that are applicable to the provision of a NOTAM system/service:

• Commercial systems/services do exist to provide aviation information services similar to NOTAM origination, management, and dissemination capabilities but will require some level of custom modification to meet the unique needs of the FAA's NOTAM environment.
• Commercial vendors will continue to innovate and offer advanced technology and keep up with the evolving needs of the airspace.
• To enable Industry to provide the NOTAM service/system, FAA will:
  • Ensure reliable access to all its aeronautical data and interfacing systems
  • Explore other Government Furnished Information/Government Furnished Equipment/Government Furnished Property (GFI/GFE/GFP) that would be required
  • Support integration with FAA processes (e.g. Test & Evaluation, Safety Risk Management, Information Security, etc.)

VI. REQUEST FOR CAPABILITY STATEMENT

The FAA requests the following information from interested vendors:

Capability Statement that demonstrates your vendor's capability and experience implementing and providing the necessary system and services outlined in this RFI. Each vendor must consider the FAA's end state and any constraints and assumptions with their proposed solution. Please include your business size (e.g., Large, Small) and any small business designations in your response.

1. Describe your current solution capability and how it meets the capabilities as described in the FAA's end state objectives for the future NOTAM system/service.
   1. To what extent you are already providing the system/service and other similar aeronautical information services to aviation industry stakeholders
2. Describe the changes required to your current solution that would be needed, and the timeline required to realize and deploy the identified changes, to fully meet the FAA's stated end state objectives for the future NOTAM system/service. Please include a discussion of the potential need for any new development or integration of COTS products as appropriate.
3. Describe any assumptions or constraints made in your capability response.
4. Describe the performance and scalability requirements supported by the system and indicate any limitations. For example:
   1. How many concurrent users can the system support for both origination and distribution?
   2. How long does the system take to transform an event/change to the various transformations including human readable forms and machine-readable ones like AIXM?
5. Provide any recommended risk mitigation approaches that the Government should consider for this effort. This includes any approaches the Government could be unaware of that would support an accelerated schedule to achieve the intent of the objectives stated for the NOTAMS service.

Interested parties must provide their responses in writing. Responses must be no more than 7 pages long (includes the 5-page maximum Capability Statement), single spaced, 12-point Times New Roman and must be in MS Word format. Please limit company background information to one page.

The FAA may request one-on-one discussions in which respondents to this Market Survey may be invited to discuss their responses in more detail. If contacted, respondents' participation is voluntary, but would be appreciated. If any of the FAA Orders or documents referenced herein are required, they can be provided upon request.

Responses must be submitted electronically no later than 5:00 pm EST on Thursday, May 11, 2023, to the Contracting Officer, Chrishaun Jones, at 9-FAA-RFI-NOTAMS@faa.gov. Any proprietary or confidential information contained in the Market Survey submissions must be appropriately marked.

Disclaimer: This is a Market Survey/RFI FAA will use responses to this market survey/RFI for informational purposes only. FAA is not seeking or accepting unsolicited proposals. FAA may request additional information or submissions, or request discussions or in person meetings in furtherance of the market survey/request for information. FAA will not pay for any information received or costs incurred in preparing responses to this market survey/RFI. Any costs associated with the market survey/RFI submittal, including the initial submission and any subsequent submissions, discussions, or in person meetings, if requested by FAA in furtherance of the market survey/RFI effort are solely at the interested vendor's expense.

This market survey/RFI is not a Screening Information Request (SIR) or a solicitation or request for offer (SFO or RFO). No commitment, or implied agreement will arise as a result of responding to the market survey/RFI. Submission to this market survey/RFI does not guarantee eligibility or impart a requirement for the market research participant to participate in or receive a SIR, SFO, RFO or a contract. Consistent with AMS 3.2.1.2.1, the information obtained as a result of the market survey may refine a future acquisition strategy. Any future acquisition strategy may be implemented without public notice unless required by AMS.

Note: The FAR references cited in SAM.gov are not applicable to the Federal Aviation Administration (FAA) as the FAA has its own policies and guidance referenced in the Acquisition Management System (AMS).