These are frequently asked questions about the TFMS TFMData Service. The questions are grouped by the categories shown below. Click on a question to view the answer.
TFMData – IMPORTANT NEWS!
TFMData v4.0a Sample R14 Messages are now available. Please visit the NSRR to download the sample messages.
TFMData Service – General
What is the TFMData Service?
The TFMData Service is a Traffic Flow Management System (TFMS)
service that provides TFM data to internal and external users via the National
Airspace System (NAS) Enterprise Messaging Service (NEMS) Enterprise Service
Bus (ESB).
What functions are available in the TFMData Service?
How can I obtain documentation about the TFMData Service?
Please contact your SWIM POC for TFMData v4.0 JMSDD and schema. Only the redacted version (TFMData v4.0a JMSDD) is available from the NSRR.
What schema versions should I be using?
The latest version of TFMData is version 3.2, with version 4.0 expected to be deployed in TFMS Sustainment 3 Release in Oct. 2025.
(For details on the specific TFMData changes from v3.2 to v4.0, refer to the TFMData v4.0 JMSDD Appendix D.)
As part of the release of TFMData v4.0, TFMS will also provide a "mediator", which essentially translates TFMData messages from the "new" TFMData v4.0 formatted messages back to the "old" TFMData v3.2 formatted messages. This mediator provides backward compatibility and allows a seamless transition for the TFMData user with zero changes required at the time of TFMData v4.0 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 v4.0, the FIXM schemas are included in the TFMData v4.0 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 Sustainment 3 Release: TFMData v4.0
- Starting with TFMS Release 14: TFMData v3.2
- 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
I downloaded the TFMData and FIXM schemas. Now what?
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 v4.0 and later, then you’re done.
The TFMData JMSDD and schema seem confusing. Where do I start?
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:
- Flight Data
- Flow Information
- Request/Reply
- Terminal Flight Data
- International Data
- 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.
What is a “mediator” and what do I do when the TFMData schema changes?
“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 v4.0 in TFMS Sustainment 3 Release, (scheduled for deployment Oct 2025). TFMData v4.0 will replace the previous version of TFMData (v3.2), which had been introduced with TFMS R14 (deployed Oct 2020). As part of the release of TFMData v4.0, TFMS will also provide a mediator to “translate” TFMData messages from the "new" TFMData v4.0 formatted messages back to the "old" TFMData v3.2 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 Sustainment 3 Release.
IMPORTANT!!
The TFMData v4.0 to v3.2 mediator will remain operational until further notice
Where can I get more information about SWIM?
Just go to the FAA’s SWIM (System Wide Information Management) website at
How do I request access to connect to the TFMData interface?
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:
https://www.faa.gov/air_traffic/technology/swim/products/get_connected
Then when you’re ready to kick-off the SWIM on-ramping process for TFMData, simply send an email request to:
A SWIM POC (Point of Contact) will be assigned to you to assist you with all of your on-ramping efforts.
Can you provide any software development support when I start to build my TFMData interface?
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
- TFMS rejects requests in which the JMS property UUID does not match the uniqueMsgid element in the message body
- 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.
Do you have any sample data for TFMData that I can use to help develop and test my TFMData interface?
Yes, sample data for TFMData (TFMS R14) is available for the following TFMData publication services:
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).)
How can I keep up to date on any future changes to the TFMData interface?
For the latest news and announcements on TFMData, it is very productive to attend the monthly TFMS Technical Webinar. These webinars are held the 2nd Thursday of every month at 1pm Eastern. To request an invitation, simply send email to
`tracy.coleman@faa.gov and/or Thomas.ctr.Paccione@faa.gov’
Where can I get more information on other data feeds?
For more information on available SWIM services, visit
https://www.faa.gov/air_traffic/technology/swim/products/get_connected
What if I have additional questions on TFMData?
If you have additional questions on TFMData, first search the TFMData FAQ to see if your question has already been answered.
Depending on whether your service is in development/test or Operations, please contact the appropriate parties below:
TFMData Service – Request/Reply
How do I monitor departures and/or arrivals for an airport?
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.
Tell me more about this TFMData service.
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.
How do I submit terminal flight data using request reply interface?
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.
Where can examples of Flight Data, Simplified Substitution and Early Intent Packets in TFMData format be found?
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 .
How is a Trajectory Option Set (TOS) submitted via Request/Reply?
For a detailed example of the TOS message in TFMData format, see Example Trajectory Option Set (TOS) Request to TFMS via Request/Reply..
How do I submit a request for a list of all TMIs currently in TFMS?
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
How do I submit a request for a specific TMI Flight List?
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
.
How can I reconstitute my flight database?
TFMData Service provides the capability to request a complete or partial flight data reconstitution via the Request/Reply function. Details on flight data reconstitution can be found here.
TFMData Service – Terminal Flight Data
Tell me more about this TFMData service.
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....
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.
TFMData Service – Flight Data
Is the Flight Data feed data delayed?
TFMS publishes all Flight Data to NEMS in real time with no delay. Any delay in the published data is a function of your subscription with NEMS to consume the data.
Tell me more about this TFMData service.
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....
TFMData Service – Flow Information
What type of information is available over the Flow Information feed?
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.
Tell me more about this TFMData service.
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...
TFMData Service – International
Are flight messages batched in the International data feed?
No, each JMS message contains one flight data message. This differs from the Flight Data feed where the messages are batched.
TFMData Service – TFDM
TFMData Service – TFMS Status
Tell me more about this TFMData service.
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
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)