1 / 13

Flight Object Data Distribution / “Messaging”

Flight Object Data Distribution / “Messaging”. Task Order No. T2004 “Air Traffic Systems Management and Engineering Support” Technical Memorandum #1 TASK 9 – Systems Engineering. Dee Llewellyn. Service Model for FIXM – the need. From CP 3.2 - Issue 3.2.3. The Publish of a Flight Object.

sheng
Download Presentation

Flight Object Data Distribution / “Messaging”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Flight Object Data Distribution / “Messaging” Task Order No. T2004 “Air Traffic Systems Management and Engineering Support” Technical Memorandum #1 TASK 9 – Systems Engineering Dee Llewellyn

  2. Service Model for FIXM – the need

  3. From CP 3.2 - Issue 3.2.3

  4. The Publish of a Flight Object • A key aspect of the ongoing USA FAA-led Flight Object Exchange Service (FOXS) initiative: • Defining and establishing the information exchange services needed to provide and receive flight data • FOXS will support Publish FO to subscribers, as well as support Request/Reply to effect changes to the FO • Both Publish/Subscribe mechanisms and Create/Update/Delete/Get request/reply mechanisms must be identified • LM has started work on a Distribution / Publishing / Messaging white paper to assist the FAA/SJU in identifying key technical considerations related to the Publish of a FIXM Flight Object

  5. Distribution/messaging white paper • Goal of paper • Collect input from a team of knowledgeable Systems Engineers, worldwide, who can represent majority of FIXM users • Provide the recommended method(s) for publishing FIXM FO • Content • Alternatives identified • Measurement criteria identified • Possible schema mechanisms to be used • Other considerations

  6. Messaging Alternatives • #1 - Full Flight Object • Conceptually, the entire Flight Object would be published • Consumer would not need to subscribe to individual groupings of elements • #2 - Distribution Clusters • Similar to SESAR method • Group all defined elements of FO into clusters • Cluster published when any member element changed • Allow subscription by cluster(s) • “Key + versions” cluster is always included • Version numbers (specific to flight) are associated with each publish, per Cluster • SESAR model - 13 clusters for an ATC based FO • #3 - Individual/traditional messages • Transaction based grouping of information (highly specialized) • Likely driven by controller commands or events that occur • Similar idea to current NAS CMS messages • Consumer would subscribe to messages of interest • Examples – Departure message, Hold message

  7. Other Messaging Considerations • #A – Consumer receives every field of the “grouping” (whether it be the whole FO or cluster or message) • #B – Consumer receives the grouping with a change mask which identifies changed elements • Fields with changed content or optional fields that have been removed are identified • #C – Consumer receives only those fields (within the grouping) that have changed • #D – Consumer receives only those fields (within the grouping) in which it has specified an interest in receiving

  8. Other Messaging Considerations • For data that is temporary or short-lived in nature such as a position update, there is another option to consider : • Consumer receives a subset of the updates associated with the FO’s position element • For example, the consumer receives every 5th position update such that an update is received once a minute (This kind of data is not reconstituted – if lost, simply wait for the next delivery to show up)

  9. Combinations to be evaluated • Are there other combinations that we can rule out? • Transaction Model: • What would be used to detect loss? How would one catch up/recover? • (With Distribution Clusters, versions cluster is included with each publication - for fast detection of missed updates / recovery ) • Can we rule out transaction approach all together?

  10. Measurement Criteria • Simplicity for Publisher • Amount of code required for implementation • Simplicity for Consumer • Amount of code required for implementation • Network bandwidth consumption • Resource utilization on Publisher side • CPU, memory • Resource utilization on Consumer side • Extensibility of the FO • Relative consumer/publisher effort related to adding something or changing something • Ability to hide/encrypt “private” information from payload • For example – aircraft weight • Ease of reconstitution of a consumer (small failure) • Ability to detect a missed message • Ability to recover • Impact on FIXM schema in its current format

  11. Reviewers • We already met with Volpe, MIT/LL • Active involvement from key world-wide representatives is needed: your points of view must be addressed so that the recommendations will be acceptable to FIXM users as a whole • Paul Chisholm of ASA has been an active, willing participant with respect to the FIXM schema – may we contact you? • Do we have volunteers? Please let us know if you would like to be involved and how we contact you. • Can the FAA recommend other key representatives to consult, include in review of draft materials?

  12. Next Steps • Firm up which alternatives to evaluate based on feedback from new team members • Determine system exchanges to use as examples to study • Meet with team members as needed to collect input • Compare alternatives, make recommendation(s) and publish results • Refine white paper based on team FIXM feedback • Make final recommendation

More Related