130 likes | 261 Views
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.
E N D
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
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
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
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
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
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)
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?
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
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?
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