CSS-FD SIR J-12 Flight Object_DRAFT_v0.009-09-16-2024.xlsx

Title Page Federal Aviation Administration (FAA) Common Support Services - Flight Data (CSS-FD) Solicitation #

Attachment J-12: Flight Object Workbook

Federal Aviation Administration 800 Independence Avenue, SW Washington, DC 20591

Version History

Removed '(if different from operator') for Major Carrier Identifier cell in FO tab Added Predicted Runway Arrival Time and Predicted Runway Departure Time in FO tab Added Crossing Point in FO tab Added additional rules in the TFMS tab's CSS-FD FO/CSS-FD Track? column to find matches on Flight Object and CSS-FD Track sheets.

Changed a couple of entries in the TFM column on FO sheet that started with flight instead of NasMessage Marked some items in red in the TFMS tab Also put in a comment on FO tab on remarks and why the multiplicity was set to more than 1, do we need to take to the FIXM group?

Added rows for Translatede FPL, Predicted Runway Arrival Time, Predicted Runway Departure Time, and Crossing Point to the Flight Object sheet.

Added * to STAR Transition Fix to denote multiple potential occurrences in Flight Object sheet

Flight Object Summary

This Workbook The purpose of this workbook is to collate all the flight data elements relevant to the CSS-FD Flight Object made available by various sources data sources, and to be able to identify what elements are included/excluded.

It is intended to serve as a collaboration tool amongst CSS-FD and the NAS programs whose systems/services feed CSS-FD (FMDS, SFDPS, STDDS, ATOP, etc.) and/or those whose systems/services will ingest flight data from CSS-FD, and as an aid to the CSS-FD vendor.

This attachment is considered a living document. As new information becomes available, changes in requirements are identified, or relevant standards evolve, this document will be updated accordingly. These updates will continue until the Final SIR is released and then after award, will be communicated to the Contractor as they occur, and it will be the responsibility of the Contractor to ensure that all changes are reviewed and incorporated as required.

The ‘FO for a flight’ is an instance of the FO for a given flight. However, depending on context, the term 'Flight Object' could be used as a shorthand for an instance, that is, to mean 'the FO for a flight'. Also, the FO may be represented in the database as one table or multiple tables. Since flight data changes over time (for example, the estimated time of arrival for a flight may change through the lifetime of the flight), FO history also needs to be maintained. When reconstituting data, users can request both FO(s), which provide the most current snapshot, as well as FO history (which would provide multiple snapshots – probably in terms of deltas – over time).

The Flight Object tab details all the elements that need to be stored and published as part of CSS-FD's FO Publication and how data from different CSS-FD source services and the eAU map to these elements. Thus this tab identifies equivalent data elements from different source services, establishing the semantic relationship among data from these different sources (SFDPS En Route Flight Data Publication Service, STDDS TAIS, STDDS TDES, STDDS SMES, TFDM TTP services,TFMData/FMDS, TBFM MIS, and TBFM RTCS - though for TBFM there is currently no plan to hold anything other than the ids). For elements that are semantically equivalent (identified by the mapping of elements from different sources in each row), business rules will further define the circumstances under which FO data in CSS-FD should be updated on receipt of data from these sources.

The FO Publication publishes FO data as FOs are created and modified. When an FO for a flight is created in CSS-FD, the FO data is published in FIXM 4.3 format. Every subsequent update to the instance results in the publication of the change, including identifying information for the flight (unique identifiers - eAU GUFI and/or CSS-FD UFI and other identifying information).

(Note 1: This sheet does not include Track Data elements, TFDM Elapsed taxi time data [essentially surface tracks], and STDDS SMES Safety Logic Alerts. Track Data, while technically a part of FO data, will be handled separately. For each track message or batched track message received from various source services [SFDPS En Route Flight Data Publication, STDDS TAIS, and STDDS SMES], the message will be unbatched if necessary and each track will:

1. Be matched to the corresponding flight in CSS-FD's FO Data store if one exists or have a new FO created for it if one does not, and be associated with the FO [based on the unique identifier for the FO - eAU GUFI/CSS-FD UFI]

2. Have a 'CSS-FD Track' created for it with a set of elements representing the position, altitude, and other pertinent information for a flight, if the received track is from the currently controlling facility (as determined by business rules)

CSS-FD Tracks will be published. The intervals between these tracks may vary since the source track messages from which CSS-FD Tracks are derived may be published and received at different intervals.

CSS-FD may also publish each source track message with the same information with which it was received, with the addition of the eAU GUFI/CSS-FD UFI elements in FIXM [Core 4.3, NAS Extension 4.4/4.5] format, with various JMS properties. Users subscribing to these source tracks would have to determine for themselves which track message is the best one to use at any given point in time.

Track messages (whether the CSS-FD Track or track messages as received from individual sources with eAU GUFI/CSS-FD UFI applied, if such a publication is instituted) may be reconstituted by users.

Flight Object Header Definitions Name Specifies a human-readable name of the data element that CSS-FD will maintain and publish as part of its FO Data. All the values in this column together define the (non-track) elements that represent the data that needs to be stored and made available as part of the FO for each flight. Track information is depicted on a different tab. While the most recent position (track) of a flight is also technically FO information, this information will not be made available upon FO reconstitution.

A handful of elements are new and specific to the FO, i.e., they are not received from other sources ingested by CSS-FD and are populated based on business rules and messages received and/or potentially other events (such as timer expiration), and so are not directly mapped to elements in messages ingested by CSS-FD.

It is envisioned that users will reconstitute the FO data separately from any track data.

The element is represented here in terms of the Data Item column in the eAU-FFP sheet and links to the corresponding cell in that column.

SFDPS Specifies elements in relevant SFDPS En Route Flight Data Publication Service messages that will be used to populate the FO. These elements are primarily those from FH/AH/HU messages, but some pertinent elements from other messages are also included. Some messages ingested from SFDPS may change the status of the FO or have other impacts on the FO based on business rules. Each populated element links to the relevant row in the SFDPS sheet, which provides details on the element.

The element is represented here in terms of the corresponding cell in the Name in Simple Schema column in the SFDPS sheet and links to that cell.

SFDPS publishes data in the Simple XML schema as well as the FIXM schema. While likely CSS-FD will ingest SFDPS's FIXM publication, since SFDPS FIXM messages do not contain all the data that the SFDPS Simple XML messages contain, CSS-FD may have to ingest some SFDPS messages in Simple XML if an element of interest is available only in the Simple XML flight data publication. Alternatively, SFDPS will have to be modified to ensure FIXM messages contain all the elements of interest to CSS-FD.

STDDS TAIS Specifies elements in relevant STDDS TAIS service messages that will be used to populate the FO. The only relevant message from this service is the TATrackAndFlightPlan message. Only Flight Plan data from the message is represented in this column, with track data being included in the CSS-FD Track tab. Each populated element in this column links to the relevant row in the STDDS_TAIS sheet, which provides details on the element.

The element is represented here in terms of its XPath (STDDS custom schemas in stdds-schema-v6.1.0.0-s4.0-20240112) and links to the corresponding cell in the Data Element column in the STDDS_TAIS sheet.

STDDS SMES Specifies elements in relevant STTDS SMES service messages that will be used to populate the FO. Messages of interest to CSS-FD from STDDS SMES include the various position/track messages (ASDE-X CAT11, ADSB, Surface Movement Events). As previously mentioned, position/track messages/elements are depicted on a different sheet, however, some elements are depicted in this column because FO entries could be created or may need to be updated based on track messages received (also, the ASDE-X CAT 11 tracks could have some manually entered flight plan fields entered by terminal controllers that need to be populated in the FO and made available as part of the FO on reconstitution). Since the one column is used to represent multiple messages from STDDS SMES, sometimes multiple elements are included in each cell - each being the data element in messages of different types. However, the cell will link to the corresponding element for the first element within the cell. Because the purpose of these links is to further define the element per the service's documentation, and since the definitions are all the same, regardless of the type of message, this representation was thought sufficient.

The element is represented here in terms of its XPath (STDDS custom schemas in stdds-schema-v6.1.0.0-s4.0-20240112) and links to the corresponding cell in the Data Element column in the STDDS SMES sheet.

STDDS TDES Specifies elements in relevant STTDS TDES service messages that will be used to populate the FO. Messages of interest from STDDS TDES include the D-ATIS messages from TDLS and the TDLSCSPMessages which convey various data exchanges between pilots and TDLS. Each populated element in this column links to the relevant row in the STDDS TDES sheet, which provides details on the element. Since the one column is used to represent multiple messages from STDDS TDES, sometimes multiple elements are included in each cell - each being the data element in messages of different types. However, the cell will link to the corresponding element for the first element within the cell. Because the purpose of these links is to further define the element per the service's documentation, and since the definitions are all the same, regardless of the type of message, this representation was thought sufficient.

The element is represented here in terms of its XPath (STDDS custom schemas in stdds-schema-v6.1.0.0-s4.0-20240112) and links to the corresponding cell in the Data Element column in the STDDS TDES sheet.

TFM/FMDS Data FMDS, which will replace TFMS, will rely on CSS-FD's FO publicationas its primary source of flight data, rather than ingesting flight data from disparate sources itself (as TFMS does today). FMDS will continue to ingest OAG data and CDM-user-provided early intent data - but will create FOs in CSS-FD's FO datastore using a CSS-FD-provided API. CSS-FD treats these FOs as any other FOs, relating them to subsequent flight data recieved about those flights, and maintaining the FOs as necessary.

This column specifies elements relevant to TFMS today. These elements are flight data elements that are published as part of TFMData's flight data business function TFMData's Terminal Flight Data Business Function today. Also included are elements speific to TFMData's Request-Reply business function (for any flight-related data) if not already accounted for - since in the future FMDS will need to create/modify Flight Objects within CSS-FD's Flight Object data store using this data. TFMData allows CDM users to submit FD Block messages (messages conveying Flight Creation, Modification, Cancellation, and Early Intent).

This column is included to ensure that all the data elements that FMDS will need to store in (or retrieve from) the Flight Object and all the flight data elements CSS-FD will need to make available to users in lieu of the TFMData flight data publication are accounted for. An assumption being made is that FMDS will populate and need the same data that TFMData does.

The elements represent elements relevant to TFMData R14. Each populated element in this column links to the relevant row in the TFMS Fields sheet, which provides details on the element.

The element is represented here in terms of the corresponding cell in the FIXMElementPath column in the TFMS Fields sheet and links to the cell in the ElementName column.

TFDM Flight Data (including SMP Data) Specifies elements in relevant TFDM TTP Flight Data Service and TTP SMP Service messages that will be used to populate the FO. Messages of interest from TTP Flight Data Service include Flight Add/Update, Flight Notification, and Flight Delete messages. Messages of interest from the TTP SMP Service include the TFDM SMP Flight List Update message. The Flight Delete message is used only to update an indicator in the FO that indicates the flight was deleted from TFDM.

Each populated element in this column links to the relevant row in the TFDMServices sheet, which provides details on the element.

The element is represented here in terms of the corresponding cell in the Data Type (XPath) column in the TFDMServices sheet and links to the corresponding cell in the Data Element Name.

TFDM Flight Delay Specifies elements in relevant TFDM TTP Flight Delay Service messages that may be used to populate the FO. Messages of interest include the Flight Delay Message. This data is currently included but may end up not being part of the Flight Object.

Each populated element in this column links to the relevant row in the TFDMServices sheet, which provides details on the element.

The element is represented here in terms of the corresponding cell in the Data Type (XPath) column in the TFDMServices sheet and links to the corresponding cell in the Data Element Name.

TBFM RTCS Each populated element in this column links to the relevant row in the TBFM RTCS Service Information sheet.

The element is represented here in terms of the corresponding cell in the Data Element column in the TBFM RTCS Service sheet and links to that cell.

TBFM MIS Since ATC automation systems (ERAM and others) cannot definitively provide any information on whether metering is in force, it was decided that it is unnecessary (and possibly misleading) to published detailed metering data related to flights. However, in CSS-FD Phase 1, CSS-FD will ingest information from TBFM's MIS service, relate flight information from MIS to flights stored in the FO data store, and associate unique identifiers from TBFM with related flights, so that users who separately obtain information from TBFM can match the information received from TBFM in a simple manner with flight data published by CSS-FD. Each populated element in this column links to the relevant row in the TBFM-MIS-Aircraft Information sheet.

The element is represented here in terms of the corresponding cell in the Data Element column in the TBFM-MIS-Aircraft Information sheet and links to that cell.

Only a few entries have been filled in in this column currently, work on this column is ongoing.

Required Will specify whether the element is required in the stored Flight Object.

(For Flight Object data that is published, while the FIXM 4.3 schemas with the relevant US extension will dictate whether an element is required in published data, any elements that CSS-FD will mandatorily publish in spite of the schemas indicating the elements are optional need to be indicated and another column will be provided for this in the future).

Since the rates at which tracks are made available differ by system (ERAMs at centers publish track messages at different rates than STARS at TRACONs do), the rate at which CSS-FD publishes tracks may differ depending on the phase of flight and its ultimate source of the track data (ERAM - via SFDPS, STARS via STDDS TAIS, ASDE-X/ADSB via STDDS SMES and ATOP tracks via an ATOP SWIM feed). Alternatively, CSS-FD may publish these tracks at the lowest rate published by any of its source systems/services.

A column for TFMData is maintained on this sheet (TBS), which will help identify any gaps in track data that TFMData publishes today.

CSS-FD FO/CSS-FD Track? column - The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets (work ongoing).

STDDS TAIS Sheet Depicts relevant information in the STDDS TAIS schemas (in stdds-schema-v6.1.0.0-s4.0-20240112.zip) based on the STDDS TAIS JMSDD.

CSS-FD FO/CSS-FD Track? column - The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheets, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheet (work ongoing).

STDDS SMES Sheet Depicts relevant information in the STDDS SMES schemas (in stdds-schema-v6.1.0.0-s4.0-20240112.zip) based on the STDDS SMES JMSDD.

CSS-FD FO/CSS-FD Track? column -The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets (work ongoing).

STDDS TDES Sheet Depicts relevant information in the STDDS TDES schemas (in stdds-schema-v6.1.0.0-s4.0-20240112.zip) based on the STDDS TDES JMSDD.

CSS-FD FO/CSS-FD Track? column - The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets (work ongoing).

TBFM -MIS-Aircraft Information Sheet Depicts the information in TBFM MIS schemas based on the TBFM MIS JMSDD.

CSS-FD FO/CSS-FD Track? column - The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets.

TBFM RTCS Sheet Depicts the information in TBFM RTCS schemas based on the TBFM RTCS JMSDD.

CSS-FD FO/CSS-FD Track? column - The intent here is to point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets.

TFDMServices Sheet TFDM Messages (of interest) and their elements are represented on this sheet, and are based on TFDM's JMSDDs (v2.01 for TFDM B-2.2) - (Core v4.0, NAS v4.1.1) CSS-FD FO/CSS-FD Track? column - point to the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets.

TFMS Fields Sheet This sheet contains rows for the elements within the messages included in TFMData's flight data exchanges with its users, in terms of their FIXM (core v4.0, NAS v4.0) representations (in the ElementPath column) or the TFMData schema v2.0.5 representations in some cases, and in terms of the FIXM (Core v4.0, NAS v4.1.1) representations (in the FixmElementPath column), without indicating which message types are relevant to each element. All of these elements need to be represented in CSS-FD's FO, since FMDS (i.e., the system that will replace TFMS) will use CSS-FD to store its flight data and use flight data published by CSS-FD in lieu of maintaining its own connections to various systems/services from which it needs flight data.

Columns include:

ElementName - The name of the element in question. Even though multiple rows sometimes contain the same name, the XPath of the element (Element Path or FIXMElementPath) will differ, indicating that the rows actually refer to different elements/attributes (this sheet does need some clean-up, and currently there may be some elements that are truly repeated).

ElementPath - The XPath of the element in the current TFMData schemas mediated to FIXM (Core v4.0, NAS v4.0), or the TFMData schema, as noted in the documentation column.

ElementComment - Provides a description of the element.

Documentation - Shows what documents were used to glean information on this element. For elements represented in FIXM in the ElementPath, the FIXM mediation documentation used was relevant to TFMData R13 and JMSDD TFMData v2.0.5 (for which a FIXM mediation was implemented). The same FIXM representations remain relevant to the current JMSDD TFMData v3.2 used by TFMData R14. The changes between JMSDD TFMData v2.0.5 and JMSDD TFMData v3.2 were looked at and any changes needed based on those were also reflected on this sheet.

Elements.DataFormat DataType FIXMElementPath - The XpPath in FIXM (Core v4.0, NAS v4.1.1) likely appropriate for this element. This mapping (and most of data in this sheet) was part of a Data Dictionary previously provided by Volpe. Some additional elements identified as being needed because of additional request/reply data exchanges or other published data not covered by the earlier FIXM mediation document referenced have been added (this work is ongoing and more elements needed are being identified).

isCoreFIXM? - Indicates if an extension or core element is being used in the mapping. The same element may sometimes be mapped to both core and extension elements (that decision on which to actually map it to being deferred, and possibly depending on the data - for example, whether the data contains provenance information or not).

CSS-FD FO/CSS-FD Track? column - The intent here is to provide a lookup of the corresponding entry in the Flight Object and/or CSS-FD Track sheet, to aid in determining which elements are not represented in at least one of the Flight Object or CSS-FD Track sheets (work ongoing - please see TFDM Services Sheet for how this column will be populated).

JMS Properties Sheet Depict the JMS Properties that should be included when FO Data is published.

Flight Object Name Generated By CSS-FD Internal Processing tc={DB250869-8410-4AB1-A021-891F6FF0E39B}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Didn't really put in a column for NCR, so anything from NCR handled in this column eAU SFDPS tc={C6136A9B-EE90-47AA-8615-6C8BC01BEE66}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

ERFDP Simple Schema Element Name Specifying the Simple XML because likely that is what we will have to consume to get data that's not present in SFDPS's FIXM feed.

(Corresponding JMS Property Name also included when relevant) STDDS TAIS STDDS SMES STDDS SMES ASDE-X ADSB Reports STDDS SMES SurfaceMovementEvent STDDS TDES TFM/FMDS Data TFDM Flight Data (including SMP information) TFDM Flight Delay TBFM RTCS TBFM MIS ATOP/Other Offshore??

tc={475E4670-0DC1-4E80-BCE0-2AE81F60B54D}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

This will not really introduce anything new and beyond what ERAM already does, but it's here as a placeholder for the future if needed. FFICE/FIXM 4.3-US Extension 4.4 (future) Representation tc={DA16D14F-C45F-404A-BD14-A03466FCBABC}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Notice many attributes in FIXM 4.0 were converted to elements in FIXM 4.3.

This will be populated in future. Currently, only some rows have been populated. Required?

tc={A75E755B-F1D7-4BCD-900E-ABDA9CEFAA5C}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

A few rows have been populated for illustration, the remaining need to be populated. Published Only/Stored as part of FO/Both?

tc={5C514271-2C39-4743-9C81-825998AD8DCD}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

b. if same value in both UFI and GUFI - this is a CSS-FD created FO

c. if UFI and GUFI both populated and have different values, then CSS-FD created first then eAU provided GUFI.

And there are many other ways to implement this.

tc={94BE1021-A442-408D-A763-B391930EC0D3}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Could be based on a trajectory computation or response or update from NCR etc. Strictly NCR updates may want to go in an NCR column. Type of Request/Response propMessageType (property) TATrackAndFlightPlan/msgType

TDLSCSPMessage/time TowerDepartureEventMessage/eventTime /NasMessage/metadata/provenance/timestamp /NasMessage/flight/tfdmFlightCreationTime N B Need to figure out what good holding all this is for when we give recon. We do need it for record-keeping.

STDDS DATIS: For DATIS, this is a special case. Though we keep the time here, we also have to note it against the DATIS data (or perhaps we don't need a common field like this) since that's intrinsic to the DATIS-data and we need to hold with each DATIS entry Time at which CSS-FD's source published its message Message Date-Time propSentTime header/timestamp timestamp header

tc={0A69B6C8-A87E-47A5-9D44-E49BDB858F55}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Sensitivity if/as determined by CSS-FD (CSS-FD may need to determine for various reasons) propSensitive (FDPS_sensitive header) TATrackAndFlightPlan/sendTo (header)

STDDS: Have to care for units. This is in ft. - can we be sure this is the same as what was in ERAM? Since STARS gets its FPs from ERAM yes, unless controller typed in? - in which case also it's okay to keep in same field.

TDLSCSPMessage/beaconCode (if not populated, use TowerDepartureEventMessage/enhancedData/beaconCode) tc={C0EBC936-A9ED-4E62-8FF0-4A5806500358}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Business rule on when to use enhancedData vs. other. While this cell can only link to one row - to display the definition of field, there are actually two relevant rows, but the sheet will be too cluttered to show columns for each type of message received from STDDS TDES. /NasMessage/flight/enRoute/currentSsrCode /NasMessage/flight/enRoute/currentModeACode No Once there's a mapping, we can determine if there is any need to reconcile or anything to reconcile. If reconciliation is not needed or possible, we need to create a new field in the FO to hold any data. Only fields that cannot be mapped are new and need to be maintained in flight object if we think they are useful information for the user. The mapping exercise only provides more information to us and the vendor.

The STDDS beacon codes are:

TAIS - Assigned Beacon code SMES - Reported Beacon code Will TAIS's assignedBeaconCode on the flight plan and the enhancedData beaconCode ever be different? - Turns out TAIS doesn't publish the enhancedData.beaconCode (verify though - that's what's stated in documentation).

Classified speed Requested Cruising Speed classifiedSpeed_05d /NasMessage/flight/requestedAirspeed/classified Yes, if neither trueAirSpee d_05a nor machSpeed _05c are present.

Note that this is mandatory on certain messages incoming from SFDPS, but not mandatory in the stored Flight Object, since this won't exist on FH etc.

(if not populated, use TowerDepartureEventMessage/enhancedData/departureAirport)

All enhancedData elements from STDDS will be used for matching but values need not replace SFDPS values if they already exist, but can be used to populate values if an FO is created with the STDDS message.

header/tracon (STDDS TRACON - source airport stored separately with track)

TATrackAndFlightPlan/record/flightPlan/callsign asdexMsg/positionReport/flightId/aircraftId asdexMsg/adsbReport/enhancedData/callsign SurfaceMovementEventMessage/callsign SurfaceMovementEventMessage/callsign (though this can go to 8 characters, and so doesn't match the SFDPS one) SurfaceMovementEventMessage/manualCallSign (can this occur at same time as callSign)?

TowerDepartureEventMessage/aircraftID (if not populated, use TowerDepartureEventMessage/enhancedData/callsign) TDLSCSPMessage/aircraftID (if not populated, use TDLSCSPMessage/enhancedData/callsign) (though this can go to 8 characters, and so doesn't match the SFDPS one) /NasMessage/flight/flightIdentification@aircraftIdentification /NasMessage/flight/flightIdentification/@aircraftIdentification /NasMessage/flight/flightIdentification/@aircraftIdentification acid /NasMessage/flight/flightIdentification/@aircraftIdentification Yes SFDPS: Why does it also map to supplemental flight data name/value pair per Volpe documentation?

STDDS: Will TAIS's flight plan's acid ever be different from TAIS's enhancedata's callsign - there is no callsign in the JMSDD...

STDDS: Should we keep the starsFlightRules separate from the flight rules that ERAM gives us for the enroute portion - No, STARS gets the flight plan from ERAM, so it should have the same value. But the potential values are different between SFDPS and TAIS, why?

Additional ICAO Field 18 indicator ICAOStoredFormat_918a No SFDPS: This one is currently not represented in FIXM (by SFDPS). So need to map and represent with another name/value pair.

tc={D80435FA-4351-4C14-BD63-4FE5938378C7}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Business rule on when to assign TAIS category to this. NAVIndicator_918l TATrackAndFlightPlan/record/flightPlan/category

tc={3D372329-201E-478B-9CA4-D76A9725259B}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

tc={F16C9777-A8E9-4BD3-8C75-C09DCE146A30}: [Threaded comment]

Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924

Comment:

Business rule may be needed around units, here and everywhere else there's a mapping. Requested Cruising Level requestedAlt_09a TATrackAndFlightPlan/record/flightPlan/requestedAltitude /NasMessage/flight/requestedAltitude No STDDS: Have to care for units. This is in ft. - can we be sure this is the same as what was in ERAM? Since STARS gets its FPs from ERAM yes, unless controller typed in? - in which case also it's okay to keep in same field.

3/28/2024 - This shoud be fine to map.

vfrOnTop altitude Requested Cruising Level requestedAlt_09b No SFDPS: This element specifies an IFR flight requesting to operate above the clouds in VFR conditions.

TBFM: The description says this is 'assigned requested' altitude. Is it assigned, or requested? Or does it signify different things based on message type?

Requested Altitude…