Zum Inhalt

Migration

Diese Seite wurde aus der AirSimTech MediaWiki migriert.

Trajectory Calculation

Overview

The trajectory engine produces a 4D profile (latitude, longitude, altitude, time, fuel) of the flown flight path. It runs inside TrajectoryActor on its own Akka.NET actor thread and publishes two independent artefacts:

  1. A raw TrajectoryResult — three ordered ProfilePoint lists (climb, cruise, descent) at 5 NM intervals with CurvePoint steps at 5° intervals around turn arcs.
  2. A two-layer BuildResult produced by ComputedFlightPlanBuilder.Build() in KernelActor — combining the raw trajectory with the navigational flight plan into:
    • Layer 1 (Display) — navigational waypoints at database coordinates plus VNAV pseudo-markers (T/C, T/D, SPDLIM, DECEL) and structural legs. No 5 NM steps, no curve points.
    • Layer 2 (Path) — pure geometry — all Internal and CurvePoint steps from the trajectory, enriched with perpendicular-abeam waypoint name projection for side/map view labelling.

The two-layer model was introduced in Phase 27. Before it, a single merged list interleaved intermediate points with named waypoints and the MCDU had to walk the entire list even for a short-route summary. The split decouples "what the MCDU displays" from "what the side/map views render".

See Trajectory Computation Chain for the upstream message flow (KernelTick → TrajectoryActor → EventStream).

Profile Computation Flow

TrajectoryActor.StartComputation runs three sequential phases on the actor thread. Typical total cost is 0.3–5 ms because all performance data (FMGCPERF1.MDB, engine table) is preloaded at PreStart — no I/O during computation.

Phase 1: Climb Profile

ComputeClimbProfile iterates forward from departure in 5 NM steps:

  1. Start at AdepAltFt, initial fuel FobKg, weight ZfwKg + FobKg, elapsed 0 s.
  2. At each step: interpolate position along the route, look up fuel flow and vertical speed from PerfDataStore, compute IAS/MACH crossover via SpeedCalculations, apply wind component.
  3. Below FL100 (10,000 ft) IAS is capped at 250 kt. The sub-step at the exact FL100 crossing (see FL100 sub-step splitting) ensures the transition happens at the correct altitude, not one step early or late.
  4. Vertical speed is energy-modulated when IAS is changing by ≥10 kt between steps (see energy modulation); max IAS change is capped at 30 kt per 5 NM step.
  5. Climb terminates when cruise altitude is reached or route distance is exhausted.
  6. TopOfClimbDistanceNm = last climb point's DistanceFromDepartureNm.

At each step the engine performs a waypoint boundary check: if any leg boundary (cumulative distance) falls inside the step window [stepStart, distFromDep], the Internal point is suppressed and replaced by a WaypointFix point plus a run of CurvePoints from the appropriate arc generator.

Phase 2: Cruise Profile

ComputeCruiseProfile iterates forward from T/C to T/D at constant altitude using fuel and time state from the end of climb as starting conditions. The section uses cost-index-optimised IAS or MACH.

Cruise arc generation includes a guard: legBndDist < tdDistNm. Without it, a waypoint lying within a fly-by turn that straddles T/D would get CurvePoints from both the cruise and descent phases. See key design decisions below.

When a fly-by turn arc straddles T/D, cruise passes the boundary parameters into GenerateFlyByArc and the generator performs a phase-boundary arc split (Phase 29 — see below). The remaining arc after the split is re-parameterised to descent V/S, IAS and fuel flow without changing the arc's geometry (same center, same radius).

If T/C ≥ T/D (short route), the cruise profile is empty and the system activates short-route altitude capping (see 05-trajectory-computation-chain).

Phase 3: Descent Profile

ComputeDescentProfile iterates backward from the destination in 5 NM steps:

  1. Start at AdesElevFt + 1000 ft (VAPP clearance) working up toward cruise altitude.
  2. InterpolatePositionBackward walks legs in reverse to compute lat/lon at each step.
  3. Below FL100 IAS is capped at 250 kt. The approach deceleration ramp models a 0.1 g horizontal deceleration from descent IAS to VAPP over ~1,000 ft AGL (see DECEL).
  4. Turn arcs are emitted with descendingDistance=True: arc distances decrease inside the arc so that the subsequent single points.Reverse() of the whole descent produces correctly ordered ascending distances. See design decision below.
  5. Descent terminates when cruise altitude is reached.
  6. After the backward loop the points list is reversed — it now flows from T/D (lowest DistanceFromDepartureNm) to ADES (highest).
  7. TopOfDescentDistanceNm = first descent point's DistanceFromDepartureNm after reversal.

Phase 4: Fuel Correction Rebuild

Because descent is computed backward, its fuel and time values are provisional. After all three profiles are computed, descent points are rebuilt with correct fuel state in a forward pass from T/D:

  1. Starting fuel at T/D = fuel remaining at end of cruise (or end of climb for no-cruise routes).
  2. Each descent point's FuelRemainingKg, CumulativeFuelBurnedKg, EtaFromDeparture, and UtcTime are recomputed in forward order.
  3. CRITICAL: each rebuilt ProfilePoint must carry dp.PointType and dp.CurveWaypointIdent from the source point. Failing to preserve these causes all descent CurvePoints to be treated as Internal, which breaks every downstream renderer.

The rebuild uses an idle fuel flow of 900 kg/h (CFM56 approximate) applied uniformly across descent steps.

Point Types (TrajectoryPointType Enum)

Defined in TrajectoryModels.vb:

Value Name Description Exported to ND
0 Internal Regular 5 NM forward step. The backbone of the profile on straight segments. Suppressed at waypoint boundaries where arc generation takes over. No
1 CurvePoint Turn arc step at 5° intervals. Generated by GenerateFlyByArc, GenerateFlyOverArc, or GenerateRfArc. Carries an optional CurveWaypointIdent tag linking the arc back to its parent waypoint, which the builder later uses for deduplication and abeam-projection scoping. Yes
2 WaypointFix Point exactly at a navigation waypoint. Emitted by trajectory before the arc is generated so the Layer 1 display has a point it can match on. Yes
3 VnavMarker Reserved for pseudo-waypoints (T/C, T/D, SPDLIM, DECEL). The trajectory itself never emits VnavMarker — the builder inserts these into Layer 2 when it materialises the path. Yes

Internal points are excluded from ND rendering to avoid cluttering the map with dense 5 NM dots along straight segments. Only CurvePoints, WaypointFix points and VnavMarkers are forwarded to the Navigation Display.

Turn Arc Generation

Boundary Detection

At each 5 NM computation step, the engine checks whether a waypoint boundary falls within the step range [stepStart, distFromDep]:

  1. cumulativeLegDist(i) is precomputed — the total distance from departure to waypoint i.
  2. For each leg boundary index (1 to legs.Count - 2), if legBndDist > stepStart AndAlso legBndDist <= distFromDep, a boundary is detected.
  3. The Internal point for that step is suppressed. Instead the engine emits:
    1. A WaypointFix at the exact waypoint position.
    2. CurvePoints from the appropriate arc generator (fly-by / fly-over / RF).

Phase ownership of arc generation:

Phase Condition Why
Climb legBndDist > stepStart AndAlso legBndDist <= distFromDep Standard boundary check
Cruise legBndDist > cruzStepStart AndAlso legBndDist <= distFromDep AndAlso legBndDist < tdDistNm The legBndDist < tdDistNm guard prevents cruise from generating arcs at waypoints at or past T/D (descent owns those)
Descent legBndDist > stepStart AndAlso legBndDist <= distFromDep (after reversal) Standard boundary check; descent covers T/D → ADES

GenerateFlyByArc

Standard fly-by turn where the aircraft cuts the corner:

Step Operation Detail
D-01 Bank angle GeoCalculations.CalcMaxBankAngle(tasKts). Returns early if bank < 1°.
D-02 Turn radius GeoCalculations.CalcTurnRadius(tasKts, bank). Returns early if radius ≤ 0.
D-03 Turn data CalcTurnData(inboundTrack, outboundTrack) — turn angle and direction (L/R). Skips turns < 1° or > 179° (no-turn and U-turn).
D-06 COT / EOT CalcCot and CalcEot — Change-of-Turn and End-of-Turn on the inbound/outbound tracks.
D-07 Turn center Perpendicular from COT toward the turn side at the turn-radius distance.
D-04 Arc steps 5° intervals from COT bearing. Step count = Ceiling(turnAngle / 5), capped at 72 (T-25-02).
D-05 Point emission Each arc step emits a CurvePoint at the computed lat/lon with cumulative arc-distance tracking. runningAlt is updated every step using the current V/S (this also applies when no split has occurred).

Signature (from TrajectoryActor.vb:1411):

Private Function GenerateFlyByArc(
    fixLat As Double, fixLon As Double,
    inboundTrack As Double, outboundTrack As Double,
    tasKts As Double,
    lastPoint As ProfilePoint,
    Optional descendingDistance As Boolean = False,
    Optional waypointIdent As String = Nothing,
    Optional boundaryDistNm As Double = Double.MaxValue,  ' Phase 29
    Optional newPhase As FlightPhase = FlightPhase.Cruise,  ' Phase 29
    Optional newPhaseIasKts As Integer = 280,              ' Phase 29
    Optional weightKg As Double = 60000,                   ' Phase 29
    Optional oatC As Double = -30                           ' Phase 29
) As List(Of ProfilePoint)

Phase 29: Phase-Boundary Arc Split

When a fly-by turn arc sweeps across a T/C or T/D boundary, the arc is split at the boundary distance and the post-split portion uses the new flight phase's IAS, TAS, Mach, V/S, and fuel flow — without changing the underlying geometry (same center, same radius).

Algorithm:

  1. Before the arc loop, capture "split state" variables from lastPoint: phase, IAS, TAS, Mach, GS, V/S, fuel flow, PerfSourceMdb. These are used for every arc step until a split occurs.
  2. For each step, compute the tentative new position along the circle and the cumulative arc distance.
  3. Compute currentDist = lastPoint.DistanceFromDepartureNm + distSign * arcDistNm, where distSign = -1 when descendingDistance=True.
  4. Detect crossing:
    • Forward direction: currentDist >= boundaryDistNm
    • Backward direction: currentDist <= boundaryDistNm
  5. Interpolate exact split point: compute the fraction frac of the 5° arc segment where the boundary distance is reached, convert to a split arc angle, and resolve the split lat/lon via PointAtDistanceBearing(center, radius, splitArcAngle).
  6. Emit split point with the originating phase parameters (IAS/Mach/TAS/GS/VS/FF/PerfSource from before the crossing), using DistanceFromDeparture = boundaryDistNm.
  7. Look up new-phase performance: _perfData.GetPerformanceCached(runningAlt, weightKg, newPhase, newPhaseIasKts) returns the fuel flow and V/S for the post-boundary phase. For descent entries, V/S is negated.
  8. Compute new-phase newTas and newMach from newPhaseIasKts and splitOat = EstimateOat(runningAlt).
  9. Update split state variables: phase, IAS, TAS, Mach, V/S, FF, PerfSource all switch to new-phase values. GS is approximated as newTas - lastPoint.WindComponentKts.
  10. Continue the arc loop with the updated state. All subsequent points use new-phase flight parameters but the same geometry.
  11. Mark splitOccurred = True so the split does not re-trigger.

The running altitude field (runningAlt) is updated every arc step — not only after the split — using runningAlt += splitVs * stepTimeHrs * 60. splitVs carries the originating V/S sign before the split and the new-phase V/S sign after.

TODO (noted in TrajectoryActor.vb:1606): GenerateFlyOverArc and GenerateRfArc still have the single-phase assumption the fly-by generator had before Phase 29. If a fly-over or RF leg is found at T/C or T/D, the same split mechanism must be applied. Deferred because these leg types at phase boundaries are extremely rare in practice.

GenerateFlyOverArc

Fly-over waypoint turn — the aircraft flies directly through the fix and then curves back to rejoin the outbound track:

  1. Path passes through the exact fix position.
  2. Turn center is perpendicular from the fix along the inbound track toward the turn side (D-09).
  3. Arc sweeps from the fix bearing to a 30° intercept heading past the outbound track (D-08). Capped at 360° (T-25-06).
  4. At roll-out, a short straight run of CurvePoints is emitted from the roll-out point to a capture point on the outbound track (3–5 points, ~1 NM each, D-10).
  5. RadialRadialIntersection computes the capture point; if intersection fails, a 5 NM projection along the intercept heading is used as a fallback (T-25-06).
  6. At the capture point, a recursive GenerateFlyByArc applies a standard fly-by turn to rejoin the outbound track (D-10 → D-11).
  7. If descendingDistance=True the result list is reversed before returning.

GenerateRfArc

RF (Radius-to-Fix) leg arc using center lat/lon from the navigation database:

  1. CenterLatitude, CenterLongitude and the radius come from the ProcedureQueryHandler database lookup.
  2. Arc sweeps from the start bearing to the end bearing around the fixed center.
  3. Turn direction determines sweep computation: right turn = NormalizeDegrees(endBrg - startBrg); left turn = 360 - sweep.
  4. Step count capped at 72 (T-25-05).
  5. Returns an empty list if radius ≤ 0 or the center is at (0, 0).

descendingDistance Semantics

The descendingDistance parameter controls the sign of arc distance tracking inside the arc loop. It is True only when the arc is emitted during the descent profile (while descent is still computed backward). In that case arc distances decrease — then the descent profile's points.Reverse() at the end flips the whole list to ascending order and the result is correctly sequenced.

For climb and cruise, descendingDistance=False: distances increase directly.

Computed Flight Plan — Two-Layer Architecture

ComputedFlightPlanBuilder.Build() in ComputedFlightPlanBuilder.vb merges the raw FlightPlan legs with the trajectory ProfilePoint data and returns a single immutable BuildResult containing two independent lists.

BuildResult

Defined in ComputedFlightPlanModels.vb:

Public Class BuildResult
    Public ReadOnly Property Display As IReadOnlyList(Of ComputedFlightPlanLeg)
    Public ReadOnly Property Path    As IReadOnlyList(Of TrajectoryPathPoint)
    Public ReadOnly Property ComputedAt            As DateTimeOffset
    Public ReadOnly Property HasTrajectory         As Boolean
    Public ReadOnly Property ComputationDurationMs As Double
End Class
Layer Type Contents Consumers
Display ComputedFlightPlanLeg list Navigational waypoints (database coordinates) + VnavMarker pseudo-waypoints (T/C, T/D, SPDLIM, DECEL) + structural legs (Discontinuity, EndOfFlightPlan, EndOfAlternateFPln, PresentPosition). No 5 NM Internal points, no CurvePoints. MCDU FPLN page, RAW FPLN diagnostic, Side/Map View label overlay
Path TrajectoryPathPoint list All Internal and CurvePoint geometry points from the trajectory, enriched with abeam-projected waypoint names. Includes VnavMarker injection for T/C, T/D, SPDLIM, DECEL. Side View line rendering, Map View path rendering

TrajectoryPathPoint

Immutable geometry point used only in Layer 2. Fields (ComputedFlightPlanModels.vb:325):

Field Type Meaning
Latitude / Longitude Double Decimal degrees
AltitudeFt Double Altitude in feet
DistanceFromDepartureNm / DistanceToGoNm Double Cumulative distance from ADEP / remaining distance to ADES
Phase FlightPhase Climb / Cruise / Descent
PointType TrajectoryPointType Internal / CurvePoint / VnavMarker
WaypointName String Nothing by default; populated for CurvePoints carrying a parent waypoint and for points that a navigational waypoint projects onto via perpendicular abeam

Build() Phases

The builder runs 6 ordered phases. The list below is the current implementation — call it the "Phase 27 pipeline" (named after the two-layer architecture phase):

Phase 1 — Combine and Deduplicate Profile Points

  1. Concatenate all three profile point lists (climb + cruise + descent) into allPoints.
  2. Stable-sort by DistanceFromDepartureNm.
  3. CurvePoint deduplication: walk the list and detect adjacent CurvePoints within ~0.15 NM and ~0.002° lat/lon of each other. Cruise and descent both generate arcs at waypoints near T/D because the descent profile owns post-T/D waypoints. Deduplication keeps the one carrying CurveWaypointIdent and drops the untagged duplicate. See ComputedFlightPlanBuilder.vb:62-81.

Phase 2 — Match Navigational Legs (Layer 1)

  1. For every raw leg with IsNavigationalLeg(legType) = True and a valid position, find the nearest ProfilePoint by geographic haversine distance.
  2. The matched point provides altitude, IAS, Mach, fuel remaining, cumulative fuel burn, ETA, UTC, ground speed, fuel flow, vertical speed, wind component, and phase.
  3. Matched points are flagged in a HashSet so the same point cannot back a second leg.
  4. Constraint matching: computes spdMatch (Y/N within 5 kt) and altMatch (Y/N within 200 ft, respecting @/+/- modifiers).
  5. The resulting ComputedFlightPlanLeg carries database lat/lon, not the matched trajectory coordinates.

Phase 3 — Insert VNAV Pseudo-Waypoints (Layer 1)

Four pseudo-waypoint markers are inserted into the Display layer:

Marker Ident Source Notes
Top of Climb (T/C) Last climb ProfilePoint Uses the exact point's IAS, Mach, GS, FF, VS
Top of Descent (T/D) First descent ProfilePoint Snaps to nearest CurvePoint within 5 NM. If T/D falls inside a turn, this ensures the T/D marker lies on the arc rather than on the straight post-waypoint track
Speed Limit (SPDLIM) Detected by InsertAltitudeCrossingMarker at the FL100 crossing One in climb (ascending), one in descent (descending); IAS always 250 kt
Deceleration (DECEL) InsertDecelMarker scans descent for the point just before IAS starts falling (> 3 kt drop on a 5 NM step, below FL100) Speed constraint is vAppKts

All four are marked IsPseudoWaypoint=True with OriginalLeg=Nothing.

Phase 4 — Materialise Layer 2 Path

  1. Walk allPoints in distance order. For each Internal or CurvePoint, materialise a TrajectoryPathPoint carrying lat/lon, altitude, distances, phase, point type, and (for CurvePoints) the parent CurveWaypointIdent as an initial WaypointName.
  2. Insert VnavMarker path points at the positions of the four Layer 1 VNAV markers (T/C, T/D, SPDLIM, DECEL) and re-sort the path by distance.

Phase 4 fix A — Remove Overshoot Internals Before CurvePoint Blocks

At high speeds the turn radius is large and COT can lie ≥2 NM before the waypoint. The last Internal before the arc block may have been projected along the straight post-waypoint track past the actual COT position. The builder detects this by checking the sign of the dot product of (segment direction) vs (arc start direction) and removes the offending Internal.

Phase 4 fix A2 — Remove Internals Sandwiched Inside a Curve

When a turn arc crosses a phase boundary (T/C or T/D), the descent/climb profile may emit a 5 NM step whose DistanceFromDepartureNm lands inside the curve's sweep range, but whose lat/lon is projected along the straight post-waypoint track. This creates a false backward segment that zig-zags through the arc.

Detection (ComputedFlightPlanBuilder.vb:331-376): any Internal point whose immediate non-VnavMarker neighbours in pathPoints are CurvePoints tagged with the same WaypointName. Indexes are collected in reverse order and removed in reverse order to preserve earlier indexes.

Phase 4 fix B — Duplicate-Distance Collapsing

Two consecutive points less than 0.01 NM apart often indicate a climb/cruise boundary artefact. If the second one is Internal, it is dropped.

Phase 4 fix C — Post-T/D Phase/Altitude Correction

CurvePoints emitted by the cruise profile for a turn arc that sweeps past T/D inherit cruise phase and cruise altitude. After T/D, the builder rewrites those points to Phase=Descent and interpolates their altitude from the descent profile (using a lookup table built from descent points).

This is the Layer-2 analogue of the GenerateFlyByArc phase split — the arc generator handles live flight parameters for the step it emits at the boundary, but earlier CurvePoints (emitted by cruise before the split) need retroactive correction.

Phase 5 — Abeam Projection of Waypoint Names

For each navigational waypoint (the Layer 1 named legs with a valid position and DistFromDepartureNm >= 0), the builder projects its identifier onto the nearest Layer 2 path point via perpendicular abeam:

  1. Search neighbouring Layer 2 segments within a distance window.
  2. For each segment [p1, p2], compute the perpendicular drop from the waypoint to the segment.
  3. The candidate path point is the projection foot (or the nearer endpoint if the projection falls outside the segment).
  4. Reject if the cross-track distance exceeds ABEAM_MAX_CROSS_TRACK_NM (50.0 NM).
  5. Update the matched TrajectoryPathPoint with WaypointName = navLeg.WaypointIdent (unless it is already tagged as a curve point for a different waypoint — curve tags are preserved).

This is how the side view renders labels like "NATOR" at the actual curved flight path position rather than at the database coordinate. Note: the guard uses < 0 (not <= 0) so that ADEP at distance 0 participates in abeam tagging.

Phase 5b — PPOS Label Tagging

PresentPosition legs are structural (non-navigational) so Phase 5 skips them. A dedicated pass tags the nearest path point to the PPOS leg with WaypointName = "PPOS". This ensures the PPOS point appears with a label in side view and map view even for bare PPOS plans.

Phase 6 — Compute DistToNext, TrackToNext, and Structural Re-Insertion (Layer 1)

  1. For each consecutive pair of Layer 1 items with valid lat/lon: distToNext = great-circle distance, trackToNext = initial bearing.
  2. Discontinuities, EndOfFlightPlan, EndOfAlternateFPln and PresentPosition markers are spliced back into the sorted Display list at their structural positions relative to the raw plan order.

Key Design Decisions

Why descendingDistance Is True During Descent

The descent profile computes backward (from ADES toward T/D) and then calls points.Reverse() once at the end. Turn arcs emitted during descent pass descendingDistance=True so their arc distances decrease inside the arc — after the final list reversal the whole descent profile runs in ascending-distance order with correctly sequenced arc points. Climb and cruise always use descendingDistance=False.

Why Cruise Arcs Use legBndDist < tdDistNm

Without the strict-less-than guard, a waypoint whose cumulative distance falls at or very near T/D would trigger arc generation in both the cruise phase and the descent phase. Descent already generates arcs at all boundaries within its range (post-reversal). The cruise guard ensures descent has exclusive ownership of that waypoint's arc and prevents CurvePoint duplication. The deduplicator in Phase 1 of the builder also catches any residual overlaps as a safety net.

Why Fuel-Correction Rebuild Must Preserve PointType

The descent fuel-correction forward pass creates new ProfilePoint instances with corrected fuel, time, and distance values. It must carry dp.PointType and dp.CurveWaypointIdent through from the original point. If PointType defaults to Internal:

  • The builder treats all former CurvePoints as Internal and applies Internal-suppression rules.
  • The Layer 2 path loses the curve arcs entirely for the descent phase.
  • The abeam-projection logic has nothing curved to project labels onto.
  • The side/map views render descent as a straight zig-zag of 5 NM steps.

Why Two Layers

Before Phase 27, the builder produced a single merged list that interleaved named waypoints, VNAV markers, 5 NM steps and CurvePoints in distance order. The MCDU F-PLN page had to scan it linearly (skipping Internal / InternalCurve / pseudo-waypoints) to render even the simplest summary. Side/map views needed the same list minus the filtering.

The two-layer split cleanly separates concerns:

  • Layer 1 (Display) — the "navigational view". Consumers that care about named waypoints, VNAV markers and constraint matches use this list directly. It is what the F-PLN page scrolls through.
  • Layer 2 (Path) — the "geometry view". Consumers that draw the actual flown trajectory use this list. Abeam projection lets them attach waypoint labels to the real flown position.

Why frmComputedFpln Was Removed

The old frmComputedFpln diagnostic form rendered the pre-Phase-27 merged list in a single ListView. After the two-layer split it became redundant: frmRawFpln already showed the raw FlightPlan.GetAllLegs() output, and the Layer 1 Display list is the merged-plus-VNAV view that the F-PLN page uses. frmRawFpln was extended with a Test menu and Display tab instead of maintaining two overlapping forms.

Map View Rendering (frmMapView)

frmMapView now renders the lateral flight path from Layer 2 TrajectoryPathPoints with waypoint labels drawn from the abeam-projected WaypointName field:

  • Phase-colored scatter lines: Climb (green), Cruise (blue), Descent (red/amber).
  • CurvePoints carrying a CurveWaypointIdent (curve labels like **NATOR) are not labelled on the map — the abeam-projected nav waypoints are.
  • Named waypoints are drawn as 8 px dots with idents, pseudo-waypoints (T/C, T/D, SPDLIM, DECEL) as magenta markers.
  • Internal path points contribute to the track line but are not individually labelled.

See Trajectory Visualization for full details.

FlightPlanLegType Values

Complete enumeration from FlightPlanModels.vb:

Value Name Description
1 Discontinuity Route discontinuity (DISC) — structural
2 Normal Standard navigational waypoint
3 Adep Departure airport
4 Ades Destination airport
5 Sid Standard Instrument Departure
6 SidTransition SID transition
7 Star Standard Terminal Arrival Route
8 StarTransition STAR transition
9 Approach Approach procedure
10 Transition Approach transition
11 RunwayExtension Runway extension
12 MissedApproach Missed approach procedure
13 PresentPosition Current aircraft position — structural
14 Artificial System-generated artificial leg
15 ArtificialMissedApproach Artificial missed approach leg
16 EndOfFlightPlan End-of-plan marker — structural
17 EndOfAlternateFPln End-of-alternate — structural
18 VnavMarker Pseudo-waypoint: (T/C), (T/D), (SPDLIM), (DECEL)
19 VnavMarkerMissedApproach VNAV marker in missed approach
20 Curve Curve point in raw plan (rarely used)
21 CurveMissedApproach Curve point in missed approach
22 Hold Holding pattern leg
23 Internal (Legacy — no longer in Display layer)
24 InternalCurve (Legacy — no longer in Display layer)

Values 23 and 24 were added in Phase 25 for the pre-Phase-27 merged list. They are kept in the enum for binary compatibility but the current builder never emits them into Layer 1 — intermediate 5 NM steps and turn-arc CurvePoints now live exclusively in Layer 2 TrajectoryPathPoints.

Source Files

  • A320_FMGC/Trajectory/TrajectoryActor.vb — StartComputation, ComputeClimbProfile, ComputeCruiseProfile, ComputeDescentProfile, GenerateFlyByArc (including Phase 29 split), GenerateFlyOverArc, GenerateRfArc, fuel correction rebuild
  • A320_FMGC/Trajectory/TrajectoryModels.vb — TrajectoryPointType enum, ProfilePoint class (fields include PointType and CurveWaypointIdent)
  • A320_FMGC/Trajectory/GeoCalculations.vb — CalcMaxBankAngle, CalcTurnRadius, CalcTurnData, CalcCot, CalcEot, PointAtDistanceBearing, RadialRadialIntersection
  • A320_FMGC/FlightPlan/ComputedFlightPlanBuilder.vb — 6-phase merge, curve deduplication, overshoot / sandwich removal, abeam projection, VNAV marker insertion, post-T/D phase/altitude correction
  • A320_FMGC/FlightPlan/ComputedFlightPlanModels.vb — ComputedFlightPlanLeg, ComputedFlightPlan, TrajectoryPathPoint, BuildResult
  • A320_FMGC/FlightPlan/ComputedFlightPlanMessages.vb — ComputedFlightPlanResult, BuildResultPublished, TmpyComputedFlightPlanResult, TmpyBuildResultPublished
  • A320_FMGC/FlightPlan/FlightPlanModels.vb — FlightPlanLegType enum
  • A320_FMGC/Kernel/KernelActor.vb — dual-publishes ComputedFlightPlanResult + BuildResultPublished at every Build call site; parallel TMPY pipeline publishes TmpyBuildResultPublished
  • A320_FMGC/Forms/frmSideView.vb — ScottPlot altitude profile; subscribes to BuildResultPublished for Layer 2 path
  • A320_FMGC/Forms/frmMapView.vb — GDI+ lateral map; subscribes to BuildResultPublished for Layer 2 path
  • A320_FMGC/Forms/frmRawFpln.vb — raw FPLN view + Display tab from Layer 1