AIXM Seminar AIXM Procedure Modeling Some proposals Brussels

AIXM Seminar 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

AIXM Seminar 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

AIXM Seminar 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

AIXM Seminar 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 4 x 4=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

AIXM Seminar First Proposal • Add the <<object>> Procedure. Path 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

AIXM Seminar 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

AIXM Seminar 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

AIXM Seminar 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

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

AIXM Seminar Second Proposal • Add the <<object>> Segment. Use to the model PPG/2010/0110

AIXM Seminar 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

AIXM Seminar 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

AIXM Seminar 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 Nav. Eq providing the course? PPG/2010/0110 All rights reserved to IDS

AIXM Seminar Third Proposal • Add a specific relation from Segment. Leg to Navaid.

AIXM Seminar 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