TFMData – IMPORTANT NEWS!

The TFMData Service is provided by the FAA’s Traffic Flow Management System (TFMS). It distributes TFM (Traffic Flow Management) data to users via SWIM’s (System Wide Information Management) National Airspace System (NAS) Enterprise Messaging Service (NEMS).  TFMData is a pure JMS service that provides streaming data updates as well as a variety of request/reply functions.

The TFMData Service provides the following Business Functions:

1. Flight Data
2. Flow Information
3. Request/Reply
4. Terminal Flight Data
5. International Data
6. TFMS Status

The Flight Data service provides near real-time air traffic data.  It is designed to provide the same base data as the legacy ASDI (Aircraft Situation Display to Industry) feed, but is enhanced with additional data related to flights being managed by TFMS.

The Flow Information service provides all TMI (Traffic Management Initiative) data, including the definition of TMIs, changes to those definitions, and cancellations.  It is the TFM SWIM replacement for the legacy TFMDI (TFM Data to Industry) feed. This Flow Information feed has a 15 minute data refresh.

The Request/Reply service provides access to all TFMS Services for data requests and for TMI creation and management.  The user makes a “request” to TFMS via this service, and TFMS provides a “reply” back to the user via this service.  This service also provides the mechanism for Operators to submit surface and terminal data to TFMS in support of the FAA’s TFDM (Terminal Flight Data Manager) system and future enhancements to improve departure time predictions, flight trajectories and demand predictions.

The Terminal Flight Data service provides data that TFMS receives from their partner airline systems as an aggregate feed to the FAA’s TFDM system and to Collaborative Decision Making (CDM) participants. TFDM uses this airline data, along with data from other FAA systems, to provide their Surface Collaborative Decision Making (CDM) capability. The Terminal Flight Data service also provides an interface for TFDM to submit data to TFMS.  This Terminal Data interface adheres to the FIXM (Flight Information Exchange Model) standard.

The International Data service provides a mechanism for International Data Providers (IDP) to provide their flight data to TFMS via SWIM.  This interface is two-way - TFMS will also provide relevant flight data back to the IDP’s.  IDP users will receive flight data only for flights that intersect their airspace.  This interface adheres to the FIXM (Flight Information Exchange Model) standard.

The TFMS Status service provides a periodic message that reports the status from a TFMS perspective of all incoming and outgoing message traffic that TFMS is dependent upon to maintain the flow of information, as well as the overall quality of TFMS data, to and from SWIM via TFMData.

The six business functions of the TFMData service provide a combination of both 1-way and 2-way interfaces:

1. Flight Data: This is a 1-way data feed from TFMS to the consumer (pub/sub).
2. Flow Information: This is a 1-way data feed from TFMS to the consumer  (pub/sub).
3. Request/Reply: This is a 2-way interface.  The user makes a “request” to TFMS via this service, and TFMS provides a “reply” back to the user via this service.
4. Terminal Flight Data: This is a 1-way interface.  Users can receive terminal flight data from TFMS.
5. International Data: This is a 2-way interface.  International Data Providers (IDPs) can submit their flight data to TFMS, and can also receive flight data back from TFMS.
6. TFMS Status: This is a 1-way data feed from TFMS to the consumer (pub/sub).

Please contact your SWIM POC for TFMData v3.2 JMSDD and schema.  Only the redacted version (TFMData v3.2b JMSDD) is available from the NSRR.

All users should begin their transition to TFMData version 3.2 which was released as part of TFMS Release 14 (R14) in Oct 2021.  TFMData v3.2 will replace the previous version of TFMData (v2.0.5) which was first released as part of TFMS Release 13 (R13) in May 2016. (For details on the specific TFMData changes from v2.0.5 to v3.2, refer to the TFMData v3.2 JMSDD Appendix D and TFMData v3.2 JMSDD Appendix D respectively.

As part of the release of TFMData v3.2 in TFMS R14, TFMS will also provide a "mediator", which essentially translates TFMData messages from the "new" TFMData v3.2 formatted messages back to the "old" TFMData v2.0.5 formatted messages. This mediator provides backward compatibility and allows a seamless transition for the TFMData user with zero changes required at the time of TFMS R14 deployment.

TFMData’s Terminal Flight Data service and International Data service adhere to the FIXM (Flight Information Exchange Model) standard. So, in addition to the TFMData schema, TFMData users of these two services must also use the FIXM schema. The FIXM schema files (FIXM Core and FIXM US extension) are available for download from the www.FIXM.aero website. For convenience, starting with TFMData v3.2, the FIXM schemas are included in the TFMData v3.2 schema zip file, and so they do not need to be separately downloaded from www.FIXM.aero. Any FIXM schema version different from the FIXM versions listed below is NOT supported and must NOT be used.

Summarizing:

• The following TFMData schema versions should be used:
  • Starting with TFMS Release 14:   TFMData v3.2
  • Starting with TFMS Release 13:   TFMData v2.0.5
• The following FIXM versions should be used for users of TFMData’s Terminal Flight Data service and International Data service (for both TFMData v2.0.5 and TFMData v3.0):
  • FIXM Core release 3.0
  • FIXM US (NAS) extension release 3.1

First, unzip the main TFMData file.  This will yield the JMSDD documents, as well as a second zip file containing the TFMData schemas.  Now, unzip this second zip file to unpack the multiple TFMData schema files. (Note: When extracting files from the zip file, ensure that options are set to “Extract all files” and to “Restore folders”.)

The FIXM schema is required only for TFMData users of the Terminal Flight Data service and the International Data service.  If you are not a user of these two services, then you’re done!  Otherwise, continue as follows to unzip the FIXM schema files.

For convenience, starting with TFMData v3.2, the FIXM schemas are included in the TFMData v3.2 and later schema zip file, and so the FIXM schema files will be automatically unpacked when the TFMData schema zip file is unpacked. If you are using TFMData v3.2 and later, then you’re done. Otherwise, if you’re using TFMData v2.0.5, then do the following steps:

• Unzip the two FIXM files, one for FIXM Core and one for the FIXM US (NAS) extension.
• The two folders for the FIXM schemas must then be inserted in the overall schema folder hierarchy as shown in the below figure:

An incredible wealth of TFM (Traffic Flow Management) data is provided by TFMData, and so consequently the JMSDD and schema are quite detailed and voluminous as well.   The schema is very logically arranged, and starts with the top-level schema element “tfmDataService” (which is located in the TFMData schema file “TFMData_Service.xsd”).  This top-level element then contains sub-elements for each one of the six TFMData services:

1. Flight Data
2. Flow Information
3. Request/Reply
4. Terminal Flight Data
5. International Data
6. TFMS Status

Each of these six elements for the six TFMData services is then further subdivided as required for the below services which have 2-way interfaces:

• International Data
• Terminal Flight Data
• Request/Reply

Refer to the below figure for details of the top-level schema layout.  It is highly recommended to not use a plain text editor to view the schema, but instead to use a graphical tool (such as XMLSpy, JDeveloper, etc) to navigate and explore the deep hierarchical structure of the TFMData Schema.

An incredible wealth of TFM (Traffic Flow Management) data is provided by TFMData.  Some of that data is categorized as sensitive (for example, information on military flights) and hence would be restricted and of course not available to the general public.  For specific details regarding what data in TFMData you would be granted access to, please work with your designated SWIM POC (Point of Contact) as you begin your SWIM on-ramping process to interface with TFMData.

“Mediators” are essentially translators which can convert from one version of a schema to another version of the schema. As systems and interfaces evolve, sometimes the underlying schemas which define those interfaces must also change. For example, the TFMData interface was first deployed with TFMS Release R10. When TFMS Release R13 was deployed, the TFMData interface was enhanced and its associated schema was changed. Under normal circumstances, to prevent this schema change from breaking the interface of an existing TFMData user, the TFMData user would need to update their client software to accommodate the new TFMData schema and the user’s updated client software would need to be deployed at the exact same time that the new TFMS release was flash-cut deployed. To avoid this need for a synchronized deployment and to provide a longer time duration for the user to complete the update of their client software, TFMS deployed a mediator when TFMS Release R13 was deployed. This mediator translated the new R13-formatted TFMData into a R10-formatted TFMData feed. This provided full backward compatibility and allowed a seamless transition for the user with zero changes required at the time of R13 deployment.

An identical approach will be used with the introduction of TFMData v3.1 in TFMS Release R14 (scheduled deployment Oct 2020). TFMData v3.1 will replace the previous version of TFMData (v2.0.5), which had been introduced with TFMS R13 (deployed May 2016). As part of the release of TFMData v3.1 in TFMS R14, TFMS will also provide a mediator to “translate” TFMData messages from the "new" TFMData v3.1 formatted messages back to the "old" TFMData v2.0.5 formatted messages. As with the R13-to-R10 mediator, this mediator provides backward compatibility and allows a seamless transition for the TFMData user with zero changes required at the time of TFMS R14 deployment.

IMPORTANT!!

The TFMData mediator will remain operational until March 01, 2021.

All users of TFMData v2.0.5 MUST upgrade their clients to TFMData v3.1 by this date

to continue accessing the TFMData feeds.

Just go to the FAA’s SWIM (System Wide Information Management) website at

http://www.faa.gov/nextgen/programs/swim

Connection to TFMS’s TFMData interface is done via SWIM (System Wide Information. Management).  Instructions to request authorization to access FAA data and to “onramp” to SWIM can be found at:

http://www.faa.gov/nextgen/programs/swim/products/getConnected

Refer also to the “SWIM External Consumer Brief”, which can be downloaded from:

http://www.faa.gov/nextgen/programs/swim/documentation/

Then when you’re ready to kick-off the SWIM on-ramping process for TFMData, simply send an email request to:

Data-To-Industry@faa.gov

A SWIM POC (Point of Contact) will be assigned to you to assist you with all of your on-ramping efforts.

The following resources can be helpful as you begin to build your TFMData interface:

1. TFMData Developer Kit for TFMData v2.0.5 (TFMS R13): This kit includes:

• Starter TFMData Client
• Installation / Deployment Guide
• Companion User Guide

To download the TFMData Developer Kit for TFMData v2.0.5 (TFMS R13),click here.

2.  NEMS Jump-Start Kit:  This kit can be downloaded at:

http://cdm.fly.faa.gov/wp-content/list_yo_files_user_folders/cdm_editor/JmsJumpStartKit-6.7.0.zip

3. Oracle Weblogic JMS:  Oracle Weblogic JMS API documentation can be found at:

http://docs.oracle.com/cd/E21764_01/web.1111/e13727/toc.htm

The current NEMS version is Weblogic JMS Version 11.1.1.5.  Verify the latest version with SWIM as you begin your on-ramping efforts.

The following coding guidelines are recommended for TFMData:

• Validate XML messages before sending them
  • Both NEMS and TFMS validate external messages. Invalid messages create unnecessary load.

• Use JAXB (Java Architecture for XML Binding) to marshal and unmarshal XML content  of TFMData messages into a Java representation
  • Provides means to ensure schema compliance
  • Generate JAXB library from TFMData Schema, version control, and access as any other external library
    • Do not version control JAXB parser generated Java source code. It opens the possibility to enhance source files.  Changes would be lost with the next schema update.
  • For more info, refer to https://jaxb.java.net

• Set the UUID in the Request/Reply interface to a unique value.
  • TFMS rejects requests in which the JMS property UUID does not match the uniqueMsgid element in the message body
    • It does not force uniqueness of the UUID per client
  • The TFMS response includes the UUID set by the client, allowing end-to-end tracking of the interaction across all domains:
    • End user to help match the TFMS reply to the issued request
    • NEMS for tracking messages
    • TFMS to debug potential processing issues

• Do not use a plain text editor to view the schema, but instead use a graphical tool (such as XMLSpy, JDeveloper, etc) to navigate and explore the deep hierarchical structure of the TFMData Schema.

There is also useful information in the presentation slides from the “TFMS Developer Workshop”.  The focus of this workshop was on developing TFMData v2.0.5 (TFMS R13) interfaces with the Request/Reply service and the Terminal Flight Data service.

TFMS Developer Workshop

Yes, sample data for TFMData (TFMS R14) is available for the following TFMData publication services:

• Flight Data
• Flow Information
• Request/Reply
• IDP

This sample data can be easily downloaded from the FAA NAS Service Registry and Repository (NSRR) website. (This is the same website where you can download the TFMData interface documents JMSDD (Java Messaging Service Description Document) and XSD (XML Schema Definition).)

To download this sample data from NSRR:

1. Login to NSRR at https://nsrr.faa.gov

(If you don't already have NSRR access, a new accounts can be requested here)

2. In the Search pulldown, select Search Documents

3. Enter the following search terms, and then click Search:

TFMData    +R14    +"sample data" -outdated

4. In the Search results section under Upload Files, click on the following filename to download this sample data:

OPs TFMS R14 Sample Data.zip

For the latest news and announcements on TFMData, it is very productive to attend the monthly TFMS Technical Webinar.  These webinars are held the 2^nd Thursday of every month at 1pm Eastern.  To request an invitation, simply send email to

`Chris.Burdick@faa.gov and/or Thomas.ctr.Paccione@faa.gov

Attendance at the quarterly SWIM Users Forum is also informative.  These forums are generally held the 2nd Thursday of the last month of each quarter at 2:30pm Eastern.  For more information and to register, go to:

https://www.faa.gov/nextgen/programs/swim/users_forum/

And of course, check back often to this TFMData FAQ for any new information!

For more information on the legacy TFMS data feeds which served as the basis for the new TFMData interfaces, refer to the FAA’s CDM (Collaborative Decision Making) website:

               https://cdm.fly.faa.gov/?page_id=237

If you have additional questions on TFMData, first search the TFMData FAQ to see if your question has already been answered. Search The Questions

If your question has not already been answered, you can click the link below to ask your question. Your question will then be automatically sent to our TFMS Second Level Engineering team and one of our TFMData experts will help get you an answer. Ask a Question

If you have questions on your TFMData service, you may also reach out directly to our TFMS Second Level Engineering team at the email and phone number listed in the below Call Flow. (see the bottom right corner of the below flowchart)

Note that if you are experiencing a loss of service with your TFMData interface, and your service is currently in the development and test phase, you should contact your SWIM Point of Contact (POC).

If your service has already completed development and test, and is currently operational, then you should contact the SWIM Enterprise Control Center (ECC). (see the bottom left corner of the below flowchart)

The Flight Data service provides near real-time air traffic data.  It is designed to provide the same base data as the legacy ASDI (Aircraft Situation Display to Industry) feed, but is enhanced with additional data related to flights being managed by TFMS.

Flight Data includes:

• Flight Plans
• Flight Plan Amendments
• Flight Plan Cancellation
• Departure Time notifications
• Arrival Time notifications
• Track Position Reports
• Oceanic Position Reports
• Boundary Crossings
• Flight Management Information
• and more….

Refer to the following for the high-level layout of the Flight Data schema:

TFMS publishes all Flight Data to NEMS in real time with no delay.  Any potential delay in the published data would be a function of your subscription with NEMS to consume the data.

The Flow Information service provides all TMI (Traffic Management Initiative) data, including the definition of TMIs, changes to those definitions, and cancellations.  It is the TFM SWIM replacement for the legacy TFMDI (TFM Data to Industry) feed. This Flow Information feed has a 15 minute data refresh.

The Flow Information feed contains primarily information regarding TFMS Traffic Management Initiatives (TMIs). The TMIs include FXAs, Reroutes, Ground Stops, Ground Delay Programs and CTOPs and more.  The information about these TMIs includes the initial TMI definition, any subsequent modifications and the flight data for the TMI. See Example Flow Information Data Feed Messages for detailed examples.

Flow Information includes:

• All TMI definitions
• Reroutes, Ground Stops, Ground Delay Programs (GDP), Airspace Flow Programs (AFP), Collaborative Trajectory Options Program (CTOP)
• Flow Evaluation Area (FEA) / Flow Constrained Area (FCA) definitions
• Command Center advisories
• Restrictions
• Airport Runway configuration & rates
• Airport Deicing status
• Route Availability Planning Tool (RAPT) timeline forecast data
• and more….

Refer to the following for the high-level layout of the Flow Information schema:

The Request/Reply service provides access to all TFMS Services for data requests and for TMI creation and management.  The user makes a “request” to TFMS via this service, and TFMS provides a “reply” back to the user via this service.  This service also provides the mechanism for Operators to submit surface and terminal data to TFMS in support of the FAA’s TFDM (Terminal Flight Data Manager) system and future enhancements to improve departure time predictions, flight trajectories and demand predictions.

Request/Reply capabilities include messages to:

• update/delete/model/monitor Traffic Management Initiatives (TMI)
• interact with TFMS in support of the TMI (CDM and Flight Operator System (FOS) services)
• control the Schedule Database
• issue Estimated Departure Clearance Time (EDCT) commands
• resynchronize TMI definitions and associated flight lists
• submit surface and terminal data
• and more….

There is also useful information in the presentation slides from the “TFMS Developer Workshop”.  The focus of this workshop was on developing TFMData interfaces with the Request/Reply service and the Terminal Flight Data service.

TFMS Developer Workshop

Refer to the following for the high-level layout of the Request/Reply schema:

For a detailed example of the TOS message in TFMData format, see Example Trajectory Option Set (TOS) Request to TFMS via Request/Reply..

Monitoring airport demand can be accomplished using the TFMData Service TFMSRequestReply function to generate a flight list.  Subsequent to the reply, the flight list can be dynamically maintained using the Flow Information function. Click here for details on airport monitoring.

• For Flight Data packets in TFMData format, see Example Flight Data (FD) block requests to TFMS via Request/Reply.
• For Simplified Substitution packets in TFMData format, see Example Simplified Substitution (SS) block requests to TFMS via Request/Reply .
• For Early Intent packets in TFMData format, see Example Early Intent (EI) requests to TFMS via Request/Reply .

Submitting Terminal Flight Data to TFMS can be accomplished using the TFMData Service TFMSRequestReply function, see Submitting Terminal Flight Data to TFMS via Request/Reply.

TFMData Service provides the capability to request the definition and flight list for a specific TMI via the Request/Reply message as detailed in Request TMI Definition/Flight List via Request/Reply.

TFMData Service provides the capability to request a complete list of TMIs via the Request/Reply message as detailed in Request Current Traffic Management Initiatives (TMIs) in TFMS.

The Terminal Flight Data service provides data that TFMS receives from their partner airline systems as an aggregate feed to the FAA’s Terminal Flight Data Manager (TFDM) system and to Collaborative Decision Making (CDM) participants. TFDM uses this airline data, along with data from other FAA systems, to provide their Surface Collaborative Decision Making (CDM) capability. The Terminal Flight Data service  adheres to the FIXM (Flight Information Exchange Model) standard.

This Terminal Flight Data service includes the following terminal and surface data:

• AOBT (Actual Off-Block Time)
• ATOT (Actual Takeoff Time)
• ALDT (Actual Landing Time)*
• AIBT (Actual In-Block Time)
• EOBT (Earliest Off-Block Time)
• ERTD (Earliest Runway Time of Departure)
• IOBT (Initial Off-Block Time)
• Flight Cancellation
• Flight Intent (to hold in Airport Movement Area during departure)
• Gate Assignment / Departure Stand Assignment
• and more….

* Note: The terminal element ALDT (Actual Landing Time) was mistyped in the TFMData v2.0.5 schema as ALTD.  The correct spelling should be ALDT.  This has been corrected in the v3.0 update to the TFMData schema.

There is also useful information in the presentation slides from the “TFMS Developer Workshop”.  The focus of this workshop was on developing TFMData v2.0.5 (TFMS R13) interfaces with the Request/Reply service and the Terminal Flight Data service.

TFMS Developer Workshop

Refer to the following for the high-level layout of the Terminal Data schema:

(Note that the “tfdinput” feed was reserved for future use but never actually used, and hence will be removed from a future release of the TFMData schema.)

Yes, you’re right!  The terminal element ALDT (Actual Landing Time) was mistyped in the v2.0.5 schema as ALTD.  The correct spelling should be ALDT.  This has been corrected in the v3.2 and later versions of the TFMData schema.

The International Data service provides a mechanism for International Data Providers (IDP) to provide their flight data to TFMS via SWIM.  This interface is two-way - TFMS will also provide relevant flight data back to the IDP’s.  IDP users will receive flight data only for flights that intersect their airspace.  The message set is based upon the 2007 and 2012 versions of “Doc 4444 ATM/501 Procedures for Air Navigation Services” from International Civil Aviation Organization (ICAO). This interface adheres to the FIXM (Flight Information Exchange Model) standard.

Refer to the following for the high-level layout of the International Data schema:

No, each JMS message contains just one flight data message.  This differs from the Flight Data feed where the messages are batched.

The TFMS Status service provides a periodic message that reports the status from a TFMS perspective of all incoming and outgoing message traffic that TFMS is dependent upon to maintain the flow of information, as well as the overall quality of TFMS data, to and from SWIM via TFMData.

The TFMS Status service provides status reports on the following data flows:

• TFMData - Flight Data
• TFMData - Flow Information
• TFMData - Request/Reply
• TFMData - Terminal Flight Data (input & output)
• TFMData - International Data (input & output)
• TBFM (Time Based Flow Management) Flight Data
• AIM (Aeronautical Information Management) SAA (Special Activity Airspace) schedule events
• STDDS (SWIM Terminal Data Distribution System) RVR (Runway Visual Range), Surface Movement Events, and Tower Departure Events  (future release)

The status reports include:

• status of incoming/outgoing data flows (enabled/disabled)
• time of last message
• cumulative message counts (since start of JMS or TCP session)
• source/destination of data (AIM, TBFM facility, STDDS facility, etc)

Refer to the following for the high-level layout of the TFMS Status schema: