- 注册时间
- 2009-12-25
- 最后登录
- 2021-7-10
- 在线时间
- 3302 小时
- 阅读权限
- 200
- 积分
- 10
- 帖子
- 13416
- 精华
- 1
- UID
- 2036
 
|
10-11-12-13 September 2002-Morocco ARAB INSTRUMENT PROCEDURE DESIGN SEMINAR
Navigation & flight planning
by FMS-equipped aircraft
AI/EE-A 441.0144/01
Table of contents
P.3 Navigation & flight management
P.4An overview of aircraft avionics
P.5GPS PRIMARY navigation
P.8RNP navigation
P.10 Flight management
P.11 Flight planning
P.12 Vertical navigation
P.13 Navigation database : ARINC 424 format
P.14 Path terminator concept
P.15 IF leg type
P.16 TF leg type
P.17 RF leg type (new leg type)
P.18 CF leg type
P.19 DF leg type
P.20 FA leg type
P.21 FC leg type
P.22 FD leg type
P.23 FM leg type
P.24 CA leg type
P.25 CD leg type
P.26 CI leg type
P.27 CR leg type
P.28 AF leg type
P.29 VA leg type
P.30 VD leg type
P.31 VI leg type
P.32 VM leg type
P.33 VR leg type
P.34 PI leg type
P.35 HA, HF, HM leg types
P.36 ARINC 424 leg transitions
P.37 Navigation database related issues
P.38 Compatibility...
P.39 Production process
P.40 Some top level issues
P.44 Recommendations
P.45 Issues summary
P.46 Short term
P.52 Medium term
P.54 Longer term
10-11-12-13 September 2002-Morocco ARAB INSTRUMENT PROCEDURE DESIGN SEMINAR
Navigation & flight management
An overview of aircraft avionics ...
Modern avionics have considerably improved flight
safety on non-precision approaches :
accurate position (RNP 0.3)
flight plan display on EFIS
reference approach path
automated lateral guidance
automated vertical guidance
ground proximity warning system (GPWS)
terrain display on EFIS (EGPWS)
terrain clearance floor warnings (EGPWS)
An overview of aircraft avionics ...
700’
500’ AGL AGL
5 NM 12 NM15 NM
3 degrees
GPS PRIMARY navigation
AIRBUS is promoting GPS PRIMARY navigation
All new A318/A319/A320/A321/A330/A340 production
aircraft are fitted with GPS PRIMARY capable equipment
Ground navaids are only used as a backup
VOR, DME
ADF is not used for navigation
only for procedural navigation check
Hybrid (A320 family & A340 family)
AIRBUS system GPS architecture
MMR
or
GPSSU
ADIRS FMS
IRS position
GPIRS position
GPS raw data
GPS position FMS position
EGPWS
Autonomous (A300-600/A310 family, retrofit solution
for A320 family with older ADIRS)
AIRBUS system GPS architecture
MMR
IRS
FMS
IRS position
GPS position
FMS position
EGPWS
In GPS PRIMARY mode, on-board system integrity has
a confidence greater than 99.9%, so the FMS position
can be relied upon without any additional navigation
cross check (using ground based navaids)
Clear status of GPS PRIMARY is therefore provided to
the crew
GPS PRIMARY crew interface
GPS PRIMARY GPS PRIMARY LOST
GPS PRIMARY crew interface
CLB FLT4567890
CRZ OPT REC MAX
FL350 FL370 FL390
<REPORT
UPDATE AT
*[ ]
BRG /DIST
---° /----.- TO [ ]
PREDICTIVE
<GPS GPS PRIMARY
REQUIRED ACCUR ESTIMATED
2.1NM HIGH 0.16NM
GPS PRIMARY
CLB FLT4567890
CRZ OPT REC MAX
FL350 FL370 FL390
<REPORT
UPDATE AT
*[ ]
BRG /DIST
---° /----.- TO [ ]
PREDICTIVE
<GPS
REQUIRED ACCUR ESTIMATED
2.1NM HIGH 0.28NM
GPS PRIMARY LOST
+ triple click during approach
RNP navigation
AIRBUS is promoting RNP (required navigation
performance)
All A318/A319/A320/A321/A330/A340 aircraft are
fitted or have been retrofitted with RNP capable
equipment
RNP allows crew awareness of estimated aircraft
position accuracy compared to procedure designer’s
required performance assumptions
NAV ACCUR UPGRAD
RNP management provides HIGH and LOW navigation
accuracy system monitoring against the Required
Navigation Performance
The system estimated accuracy has a 95% confidence
RNP crew interface
NAV ACCUR UPGRAD NAV ACCUR DOWNGRAD
RNP crew interface
CLB FLT4567890
CRZ OPT REC MAX
FL350 FL370 FL390
<REPORT
UPDATE AT
*[ ]
BRG /DIST
---° /----.- TO [ ]
PREDICTIVE
<GPS
REQUIRED ACCUR ESTIMATED
0.3NM HIGH 0.28NM
NAV ACCUR UPGRAD
CLB FLT4567890
CRZ OPT REC MAX
FL350 FL370 FL390
<REPORT
UPDATE AT
*[ ]
BRG /DIST
---° /----.- TO [ ]
PREDICTIVE
<GPS
REQUIRED ACCUR ESTIMATED
0.3NM LOW 0.56NM
NAV ACCUR DOWNGRAD
AIRBUS flight management details
Multi-sensor navigation & automatic navaid tuning
triple IRS, dual VOR & DME, GPS
nIRS only, nIRS/VOR/DME, nIRS/DME/DME, nIRS/GPS
LOC updating
RNP management
GPS primary navigation
RAIM or AIME on-board integrity monitoring
certified for RNP 0.3 NM use
Datalink
including F-PLN, T/O DATA and WIND uplink capability from
AOC (Airline Operational Control)
AIRBUS flight management details
4D flight planning & predictions
runway to runway 4D pre-computed optimized flight profile
real time optimization
decelerated approach profile, 3D non-precision approaches
full autopilot coupling capability (dual FMS, dual monitored
AP)
time resolution 1 minute, guidance accuracy around 2 minutes
planned improvement to 1 second resolution, accuracy better
than 30 s
Flight planning
Origin
Departure SID
Engine out SID
En-route
Arrival STAR
Approach
Destination
Missed approach
Alternate flight plan
Vertical flight management
D
SPEED
LIMIT
SPEED
CONSTRAINTS
ALTITUDE
CONSTRAINTS ALTITUDE
CONSTRAINTS
ORIGIN
DESTINATION
SPEED
CONSTRAINTS
SPEED
LIMIT
ACCELERATION ALT
THRUST REDUCTION ALT
CRUISE FL STEP FL
IDLE path
geometric path
approach path
pressurization
segment
TAKEOFF CLIMB CRUISE DESCENT APPROACH
APPROACH
SPEEDS
TAKE-OFF
SPEEDS
TIME
CONSTRAINT
10-11-12-13 September 2002-Morocco ARAB INSTRUMENT PROCEDURE DESIGN SEMINAR
Navigation database : ARINC 424
ARINC 424 path terminator concept
The Path and Terminator concept is a means to permit
coding of Terminal Area Procedures, SIDs, STARs and
Approach Procedures
Charted procedure are translated into a sequence of
ARINC 424 legs in the Navigation Database
Flight plans are entered into the FMS by using
procedures from the navigation database and chaining
them together
ARINC 424 path terminator concept
23 leg types have been created to translate into computer
language (FMS), procedure designed for clock &
compass manual flight
It’s high time to implement RNAV, using only DO236
preferred leg types: IF, TF, RF which are fixed and
without possible interpretation
The leg type is specified at the end point : “path
terminator concept”
IF leg type
The Initial Fix or IF Leg defines a database fix as a point
in space
It is only required to define the beginning of a route or
procedure
TF leg type
Track to a Fix or TF Leg defines a great circle track over
ground between two known databases fixes
Preferred method for specification of straight legs
(course or heading can be mentioned on charts, but
designer should ensure TF leg is used for coding)
RF leg type (new leg type)
Constant Radius Arc or RF Leg defines a constant radius
turn between two database fixes, lines tangent to the arc
and a center fix
CF leg type
Course to a Fix or CF Leg defines a specified course to a
specific database fix
TF legs should be used instead of CF whenever possible
to avoid magnetic variation issues
DF leg type
Direct to a Fix or DF Leg defines an unspecified track
starting from an undefined position to a specified fix
Procedure designers should take into account the FMS
flight path depends on initial aircraft heading as well
FA leg type
Fix to an Altitude or FA Leg defines a specified track
over ground from a database fix to a specified altitude at
an unspecified position
FC leg type
Track from a Fix from a Distance or FC Leg defines a
specified track over ground from a database fix for a
specific distance
FD leg type
Track from a Fix to a DME Distance or FD Leg defines a
specified track over ground from a database fix to a
specific DME Distance which is from a specific database
DME Navaid
FM leg type
From a Fix to a Manual termination or FM Leg defines a
specified track over ground from a database fix until
Manual termination of the leg
CA leg type
Course to an Altitude or CA Leg defines a specified
course to a specific altitude at an unspecified position
CD leg type
Course to a DME Distance or CD Leg defines a specified
course to a specific DME Distance which is from a
specific database DME Navaid
CI leg type
Course to an Intercept or CI Leg defines a specified
course to intercept a subsequent leg
CR leg type
Course to a Radial termination or CR Leg defines a
course to a specified Radial from a specific database
VOR Navaid
AF leg type
Arc to a Fix or AF Leg defines a track over ground at
specified constant distance from a database DME Navaid
VA leg type
Heading to an Altitude termination or VA Leg defines a
specified heading to a specific Altitude termination at an
unspecified position
VD leg type
Heading to a DME Distance termination or VD Leg
defines a specified heading terminating at a specified
DME Distance from a specific database DME Navaid
VI leg type
Heading to an Intercept or VI Leg defines a specified
heading to intercept the subsequent leg at an unspecified
position
VMleg type
Heading to a Manual termination or VM Leg defines a
specified heading until a Manual termination
VR leg type
Heading to a Radial termination or VR Leg defines a
specified heading to a specified radial from a specific
database VOR Navaid
PI leg type
Procedure Turn or PI Leg defines a course reversal
starting at a specific database fix, includes Outbound Leg
followed by a left or right turn and 180 degree course
reversal to intercept the next leg
HA, HF, HMleg types
Racetrack Course Reversal or HA, HF and HM Leg
Types define racetrack pattern or course reversals at a
specified database fix
HA = Altitude Termination
HF = Single circuit terminating
at the fix (base turn)
HM = Manual Termination
ARINC 424 - allowable leg transitions
* = The IF leg is coded only
when the altitude constraints at
each end of the “FX”, “HX” or
“PI” leg are different.
& = A CF/DF, DF/DF or FC/DF
sequence should only be used
when the termination of the first
leg must be over flown,
otherwise alternative coding
should be used.
# = The IF/RF combination is
only permitted at the start of the
final approach for FMS, GPS or
MLS coding and only when a
straight line, fixed terminated
transition proceeds the start of
the final.
10-11-12-13 September 2002-Morocco ARAB INSTRUMENT PROCEDURE DESIGN SEMINAR
Navigation database related issues
Compatibility...
Navigation data production process
Procedure design
by Civil Aviation Authorities
Data Supplier
FMS Database Processing
FMS
AIP
ARINC 424 “master” file
Packed Data
operator
responsibility
Some top level issues
Navigation database process is *not* certified
Transcription of procedures in “computer” language
(ARINC 424) requires interpretation
Procedure designer intent is currently only published under
“pilot language” format
Each FMS implementation & logic is different
May results in different flight paths and SOP
Charts and aircraft navigation displays differ
Increased risk of Human error
Training costs
Reminder - flight plan construction
Charted procedure are translated into a sequence of
ARINC 424 legs in the Navigation Database
Flight plans are entered into the FMS by calling
procedures from the navigation database
Procedure segments are chained together (or melded) to
form the FMS flight plan
Example : F-PLN procedure melding
Procedures are chained together to form the FMS flight
plan. Example :
Arrival chart
Airways chart
Approach chart
Enroute
(airways)
STAR-enroute
transition
STAR Approach
STAR-approach
transition (VIA)
Example : procedure compatibility ?
Possible procedure misconnects between en-route,
arrival, and approach charts
Possible discontinuities between or inside procedures
Incompatible or conflicting altitude requirements
between arrival and approach charts
10-11-12-13 September 2002-Morocco ARAB INSTRUMENT PROCEDURE DESIGN SEMINAR
Navigation database recommendations
Waypoint naming issues
Different approach procedure types (ILS/LOC/RNAV…)
use different trajectories and/or waypoint names without
reason
Unnamed waypoints on charts are assigned default names
Same waypoint names used at different locations
Chart wording leading to usage of leg types which cause
the FMS to create its own waypoints, with names which do
not match chart
Coding constraints lead to creation of waypoints not on the
chart
Procedure trajectory issues
Chart wording and/or coding rules lead to coding of
magnetic course leg types such as CF legs
Chart wording and/or coding rules lead to bad coding of
vertical descent angles, which are critical to a correct
vertical path
IFR minimum altitudes often coded as “AT” constraints
Overfly waypoints trajectories are not repeatable
Barometric temperature limitations should be indicated
on charts
Overfly waypoints : depending on wind, aircraft speed,
bank angle limitation etc… the FMS trajectory will be
different
Why not use overfly waypoints ?
trajectory
not repeatable
overfly wpt
Fly-by waypoints : better trajectory control is achieved
as the FMS will track a pre-computed curve
Why use fly-by waypoints ?
controlled
trajectory
fly-by wpt
CF leg magnetic course angles may mismatch :
excessive roll
maneuvering
Why not use CF legs ?
N N
TF legs always fit, independently of magnetic variation :
Why use TF legs ?
IDLE segment
Why code FPA constraint on each
FINAL leg ?
FPA smaller than
altitude constraint
FPA greater than
altitude constraint
No FPA
FPA matches altitude
constraint
Why not use AT altitude constraints ?
Using AT constraints may cause undesired vertical path :
navigation database vertical angle
navigation database vertical angle
MAP
approach profile
MDA
Why use AT_OR_ABOVE altitude
constraints ?
Using AT_OR_ABOVE constraints and FPA constraint
on each leg ensures seamless path
MDA
navigation database vertical angle
navigation database vertical angle
MAP
approach profile
Medium term - recommendations
Implementation of DO201A by civil aviation authorities for
procedure publication
Implementation of DO200A by data providers
Implementation of RTCA DO236 / EUROCAE ED-75
Implementation of ATA Chart, Data and Avionics Harmonization
Top Priorities
Improved transatlantic coordination between working groups,
authorities & industry
ARINC 424, ATA FMS/RNAV Task Force, TARA, RTCA SC-
181 & 193, Eurocae WG-13 & 44, FAA, JAA, Eurocontrol,
ICAO…
Medium term - ATA CDAH priorities
Redesign of existing non-precision approaches to accommodate
VNAV
Altitudes at precision FAF’s
Unnamed step-down fixes
Waypoints on EFIS but not in database or charts
Waypoint names longer than five characters
Duplicate navaid and waypoint identifiers
Different altitude for same point on STAR’s and approaches
Magnetic variation tables used in course calculations
VNAV angle depiction on charts
Longer term - goals
Fully resolve the disconnect between :
the procedure design by the Airspace Planner,
the coded description in the navigation database,
and the way it is displayed and flown by the FMS
End-to-end certified process with integrity guidelines
and criteria
A worldwide, common process with Airworthiness
Authorities involvement under an ICAO mandate
Longer term - recommendations
Publication of a single standard/language for procedure
design, database coding, and FMS
Reduced ARINC 424 set
Improved charts-database-FMS compatibility
Design of “FMS-friendly” procedures
Publication of these procedures using FMS compatible
language (in addition to charts)
Publications of standards for navigation database
integrity and certification
Longer term - common language
Comprehensive worldwide commonality requires rules at
ICAO level
A common coding Standard should be :
clearly defined,
including rules for use by both the aircraft and the RNAV
Airspace Planner,
the minimum capability of any "FANS RNAV system”,
the maximum set usable by the RNAV Airspace Planner
This would ensure a unique unambiguous coding of
routes and procedures
Longer term - FMS friendly procedures
Use only fixed, named waypoints
For straight segments use only TF legs
For large course changes (>30°) use RF legs
Use only fly-by waypoint transitions (no overfly)
Put a waypoint at each vertical path change
Use descent gradients between 2.5° and 3.5°
Start the missed approach at or before the runway
Use same waypoint names and approach path for all approach types
to a given runway
Use unique waypoint names (max 5 characters)
Longer term - integrity
Integrity must concern the entire process, from
procedure design to the loading of the FMS
Ultimate goal should be a fully digital process
Process should be under direct supervision of airspace
management authorities
Worldwide implementation requires ICAO rules
End of presentation :
Any question? |
|
IP卡
狗仔卡
发表于 2010-7-31 16:14:09
分享
收藏
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2010-8-2 13:52:13
