View
30
Download
0
Category
Tags:
Preview:
DESCRIPTION
AIXM Procedure Modelling Seminar Additional topics for discussion. Brussels – 01/02 Sept 2010. NOTAM for Procedures. - PowerPoint PPT Presentation
Citation preview
The European Organisation for the Safety of Air Navigation
AIXM Procedure Modelling SeminarAdditional topics for discussion
Brussels – 01/02 Sept 2010
2
NOTAM for Procedures
• If a navaid is used for several airports, then the current practice in many States is to publish a "navaid u/s" NOTAM for each airport that is affected, with the corresponding airport in item A.
• Proposed way forward, to be stated as a note in the event specification:• the Event could be translated into a NOTAM with the FIR in
item A and• separate Event and separate NOTAM should be published
for the affected procedures having the airport identifier in item A
• The information about which procedures are affected by a navaid u/s should be available as static data
3
NOTAM for Procedures
• A good NOTAM ?
(A3547/07 NOTAMNQ) LFEE/QNVAS/IV/BO /AE/000/999/4848N00727E025A) LFST B) 0710010630 C) 0710011303 E) PART VOR OF VOR DME 'SAV' OUT OF SERVICE : DO NOT USE - FALSE INDICATIONS POSSIBLE -STAR GTQ 6V, ET LUL 6V, HLDG PROCEDURE OVER SAV, SID EPIKO 7J NOT AVBL. -IAF FOR ARRIVALS RWY 23 WILL BE BERUG (483723.877N
0065737.195E). LUPEN AND 'SE' ONLY UNDER INSTRUCTION. -INTERCEPTION OF INTERMEDIATE AND FINAL PHASES RWY 23 IS PERFORMED AFTER AN INITIAL PHASE UNDER RADAR
GUIDANCE.)
4
NOTAM for Procedures
• A bad one, because it does not say exactly what "affected" means ?
A1249/10 NOTAMN (EBBR A1249/10) Q) EBBU/QFALT/IV/NBO/A/000/999/5054N00429E005 A) EBBR B) 1006160700 C) 1007101600 E) DURING OUTAGE OF HUL DVOR/DME FOLLOWING ATC PROCEDURES ARE
AFFECTED1)EBBR ILS PROCEDURES RWY 02, VOR PROCEDURES RWY 07R2)EBBR STANDARD MISSED APPROACH PROCEDURE RWY 203)EBBR SID CIV4J, CIV6F, DENUT2N, DENUT3C, DENUT3L, HELEN2N, HELEN3C, HELEN3L, LNO2C, LNO2D, LNO2H, LNO2J, LNO2Q, LNO3F, LNO3Z, LNO4L, PITES3C, PITES3D, PITES3F, PITES3H, PITES3L, PITES3Z, ROUSY3C, ROUSY3D, ROUSY3F, ROUSY3H, ROUSY3J, ROUSY3L, ROUSY3Z, SOPOK2H, SOPOK2J, SOPOK2L, SOPOK3C, SOPOK3D, SOPOK3F, SOPOK4Z, SPI2C, SPI2D, SPI2J, SPI2Q, SPI3F, SPI3H, SPI3L, SPI4Z4)EBBR STAR ARVOL3B, TULNI3BPILOTS UNABLE TO COMPLY WITH THESE PROCEDURES SHALL REQUEST ALTERNATIVE INSTRUCTIONS TO ATC. PERIODS OF OUTAGE OF HUL DVOR/DME ARE ANNOUNCED BY SEPARATE NOTAM AND ATIS
5
NOTAM for Procedures
• The information about which procedures are affected by a navaid u/s should be available as static data
• Unless the procedure designer accepts to be called at 3am on a Sunday morning by the NOTAM office to tell them which procedures are unusable because of VOR/DME X outage …
• By which extent this information can be provided from the design phase and who has the responsibility to decide for announcing that the procedure is unusable?
6
Recommended navaidAIXM Seminar
• 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.
Providing guidance Navaid
PPG/2010/0110 All rights reserved to IDS
AIXM Seminar
• Consider the case of a “Course to a Radial” (CR) Segment Leg:
• The “Recommended Navaid” field refersto the Navaid defining the Radial (170°),not the one providing the guidancealong the CR Leg (120°)
• How can we deduce the NavEqproviding the course?
CR Segment Legs
PPG/2010/0110 All rights reserved to IDS
7
Recommended navaidThe current AIXM 5.1 encoding solution
ArrivalLeg<<feature>>
DepartureLeg<<feature>>
ApproachLeg<<feature>>
TerminalSegmentPoint
role : CodeProcedureFixRoleTypeleadRadial : ValBearingTypeleadDME : ValDistanceTypeindicatorFACF : CodeYesNoType
(from Point Reference)
<<object>>SegmentLeg<<feature>>0..1
+startPoint
0..1
beginsAt
0..1
+endPoint
0..1
terminatesAt
0..1
+arcCentre
0..1 has
PointReference
role : CodeReferenceRoleTypepriorFixTolerance : ValDistanceSignedTypepostFixTolerance : ValDistanceSignedType
(from Point Reference)
<<object>>SegmentPoint
reportingATC : CodeATCReportingTypeflyOver : CodeYesNoTypewaypoint : CodeYesNoTyperadarGuidance : CodeYesNoType
(from Point Reference)
<<object>>
0..*
+facilityMakeup
0..*isFoundUsing
8
Recommended navaid
Point Reference Role
9
Recommended navaidThe current AIXM 5.1 encoding solution
ArrivalLeg<<feature>>
DepartureLeg<<feature>>
ApproachLeg<<feature>>
TerminalSegmentPoint
role : CodeProcedureFixRoleTypeleadRadial : ValBearingTypeleadDME : ValDistanceTypeindicatorFACF : CodeYesNoType
(from Point Reference)
<<object>>SegmentLeg<<feature>>0..1
+startPoint
0..1
beginsAt
0..1
+endPoint
0..1
terminatesAt
0..1
+arcCentre
0..1 has
PointReference
role : CodeReferenceRoleTypepriorFixTolerance : ValDistanceSignedTypepostFixTolerance : ValDistanceSignedType
(from Point Reference)
<<object>>SegmentPoint
reportingATC : CodeATCReportingTypeflyOver : CodeYesNoTypewaypoint : CodeYesNoTyperadarGuidance : CodeYesNoType
(from Point Reference)
<<object>>
0..*
+facilityMakeup
0..*isFoundUsing
= RECNAV
10
Recommended Navaid
• Change proposal?AIXM Seminar
• Add a specific relation from SegmentLeg to NavaidEquipment:
Third Proposal
PPG/2010/0110 All rights reserved to IDS
<<feature>>
SegmentLeg
<<feature>>
NavaidEquipment
0..* 0..1
providingGuidanceFacility
isGuidedBy
11
“Multi-branch” proceduresAIXM Seminar
• 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
Multi-branch Procedures
PPG/2010/0110 All rights reserved to IDS
Runway Transitions Enroute TransitionsCommonTransition
12
“Multi-branch” procedures
• ICAO Annex 11, Appendix 3
“The coded designator of a standard departure or arrival route instrument or visual, shall consist of:
a) the coded designator or name-code of the significant point described in 2.1.1 a); followed by
b) the validity indicator in 2.1.1 b); followed by
c) the route indicator in 2.1.1 c), where required.”
Example: ADOLA 5 B
13
“Multi-branch” procedures
14
“Multi-branch” procedures
15
“Multi-branch” procedures
According to Annex 11, AIPs: multi-branch procedures do not exist?-“common route” transitions have been introduced for FMS database size reasons- AIXM 5 tries to support both views: individual procedures and multi-branch
16
“Multi-branch” procedures
• Procedure encoding workflow with AIXM• Each leg belongs to one procedure• No sequence number because it was
assumed that start/end point data is sufficient to identify the order of the segments
• VEROR4A and VEROR4B are two different Procedure instances
ApproachLeg<<feature>>
InstrumentApproachProcedure(from 1 - Approach)
<<feature>>
1..*
0..1
1..*
+approach
0..1
isPartOfSegmentLeg<<feature>>
Procedure<<feature>>
17
“Multi-branch” procedures
• Procedure transitions can also be encoded “top-down”, using the pre-defined legs.
ProcedureTransitionLeg
seqNumberARINC : NoSequenceType
<<object>>
ProcedureTransition
transitionId : CodeDesignatedPointDesignatorTypetype : CodeProcedurePhaseTypeinstruction : TextInstructionTypevectorHeading : ValBearingType
<<object>>
0..*
0..*
0..*
+transitionLeg
isComposedOf
1
0..*
+flightTransition
0..*
0..*
contains
1Procedure
<<feature>>
SegmentLeg<<feature>>
ApproachLeg<<feature>>
InstrumentApproachProcedure(from 1 - Approach)
<<feature>>
1..*
0..1
1..*
+approach
0..1
isPartOfSegmentLeg<<feature>>
Procedure<<feature>>
18
“Multi-branch” procedures
AIXM Seminar
• Add the <<object>> ProcedurePath to the model
First Proposal
PPG/2010/0110 All rights reserved to IDS
<<feature>>
Procedure
<<object>>
ProcedurePath
<<object>>
ProcedureTransition
1
1
0..*
0..*
0..*
<<object>>
PathTransition(seqNumber)
• A Procedure would be an unordered collection of Paths.
• A Path would be an orderedsequence of Transitions
• A Transition is an orderedsequence of Legs:
• Change proposal?
19
Curve associated with the procedure
• Who will generate the “curve” associated with the procedure leg/transition?• Procedure designer to charting / AIS office?• Chart designer based on the information provided by the
procedure designer?• Procedure encoding client of AIS, based on the leg
information provided by AIS?
20
Other topics raised during registration
• Protection areas• The way From procedure design to Coding• The place of the protection areas in the P&T coding• What is the integrity/correctness of a coding regarding P&T• ARINC coding in the AIXM 5.1 model• AIXM 5.1 model compatibility with PANS-OPS• Topologcally Correct Geo-Spatial Data Management (Segment
Legs, Protected Areas etc)• Mapping between ARINC 424 / DAFIF procedure model & AIXM
5.1 procedure model• How to encode conventional procedures• How to handle multiple arrival segments
Recommended