AIXM Procedure Modeling Some proposals Brussels, 1-2 Sept 2010 Davide Catsgani Fabbri (d.fabbri@ids-spa.it) PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Abstract The purpose of this presentation is to: explain some modeling needs peculiar to the IFP Design world propose some changes to the AIXM 5 model, in order to fit these needs discuss pros & cons of the proposals PPG/2010/0110 All rights reserved to IDS

Multi-branch Procedures An IFP is not necessarily composed of a single sequence of consecutive Legs On the contrary, national AIPs publish into a single procedure chart a group of IFPs sharing a common portion PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS AIXM 5 modeling AIXM 5 models multi-branch procedures through the concept of Procedure Transition A Procedure is an unordered collection of Transitions. A Transition is an ordered sequence of Segment Legs: PPG/2010/0110 All rights reserved to IDS

The Procedure Path concept In this example: 4 possible starting RDNs 4 possible ending WPTs An aircraft flying this SID will follow just one of the 4x4=16 possible paths Should it communicate its flight plan, the Procedure designator would not be enough  need to identify the exact path PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS First Proposal Add the <<object>> ProcedurePath to the model A Procedure would be an unordered collection of Paths. A Path would be an ordered sequence of Transitions A Transition is an ordered sequence of Legs: PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Pros & Cons A possible objection to the proposal is: It would introduce redundant information in the model. Indeed the list of possible Paths can be deduced from the list of Transitions Counter-objection: Deducing the list of possible Paths from the list of Transitions requires a non-simple logic, relying on assumptions & constraints not explicit in AIXM about the role of the Transitions, type of Procedures, … PPG/2010/0110 All rights reserved to IDS

Procedure Design needs One of the purposes of AIXM 5 is to serve a wider class of AIM applications than previous AIXM versions This is the reason why AIXM 5 models several concepts concerning the IFP Design world: Obstacle Assessment Areas Terminal Arrival Areas Safe Altitude Areas Obstructions … We though perceive a lack of the model, from the IFP Design standpoint… PPG/2010/0110 All rights reserved to IDS

Obstacle Assessment Areas AIXM 5 models the relationship between Segment Legs and Obstacle Assessment Areas as a direct link: The shape of these Areas depends on plenty of parameters, most of them modeled as attributes of the Segment Leg feature or features/objects associated to it Actually, along with any Design criteria, it often happens that the Area geometry also depends on adjacent legs PPG/2010/0110 All rights reserved to IDS

Area dependece on adjacent Legs PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Second Proposal Add the <<object>> SegmentUse to the model PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Pros & Cons Cons: It would make the data scheme a little bit more complex Pros: The association OAA  Leg would include the information (fundamental from the Design perspective) regarding the Path which the OAA belongs to PPG/2010/0110 All rights reserved to IDS

Providing guidance Navaid From the IFP Design perspective, one fundamental information about a (conventional Procedure) Segment Leg is the location and type of the Navaid Equipment providing the guidance (if any). The design of the leg’s protection areas largely depend on it. Now, in ARINC 424 this information may be often (but not always!!) deduced from different attributes of the leg, such as the Path/Terminator, the Recommended Navaid and so on. Unfortunately there are cases where we are not able to infer the providing guidance Navaid from the ARINC 424 codification. Nor it seems things are going better with AIXM 5. PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS CR Segment Legs Consider the case of a “Course to a Radial” (CR) Segment Leg: The “Recommended Navaid” field refers to the Navaid defining the Radial (170°), not the one providing the guidance along the CR Leg (120°) How can we deduce the NavEq providing the course? PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Third Proposal Add a specific relation from SegmentLeg to NavaidEquipment: PPG/2010/0110 All rights reserved to IDS

All rights reserved to IDS Pros & Cons Cons: In many cases (not all) it would introduce redundant information in the model (the Recommended and Providing Guidance Navaids would often coincide) Pros: The “Providing Guidance” information (again, essential for the Design purposes) would be much more clear and easily accessed PPG/2010/0110 All rights reserved to IDS