1. AIXM Procedure Modeling
Some proposals
Brussels, 1-2 Sept 2010
Davide Catsgani Fabbri
PPG/2010/0110
All rights reserved to IDS

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

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

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

12. 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

13. 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

14. 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

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

16. 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