GROUND-SERVICE INTEGRATION NEEDS ONE COHERENT LOADING STATE
Decide whether the exercise uses standalone Fenix services or the documented GSX integration, then configure that choice before loading. GSX is a separate third-party product with its own version and settings. The official integration workflow begins from the EFB mass-and-balance plan and uses Load Aircraft followed by GSX; manually requesting unrelated services does not automatically establish the same synchronised loading path. Compare the reported passengers, cargo and fuel with the aircraft's achieved state before accepting the final preparation. [133, Requirements, mass-and-balance workflow and synchronisation]
Automation conditions are part of the ground scenario. The guide describes options for service sequencing, pushback requests and GPU connection/disconnection. Know which settings are active before using a beacon, brake or engine-state change as part of the flow. Regardless of the automation request, verify actual electrical-source readiness and bus supply before the previous source is removed. An APU being commanded or audible is not a substitute for the electrical handover check. Ground movement also remains subject to the applicable clearance and coordinated brake instructions. [133, Service sequence, auto-pushback and GPU options] [62, PDF p. 6] [23, PDF pp. 1034–1038]
At the destination, distinguish arrival automation from completion of the deboarding state. The documented auto-deboard workflow progressively updates the load and warns against importing the next plan before completion. Preserve that sequence for a turnaround, then verify the resulting quantities before preparing the next sector. If the external service and EFB lose synchronisation, use the relevant current recovery instructions and re-establish the actual aircraft load. Do not continue with a visually plausible passenger count while the mass used by the next calculation belongs to another state. [133, Auto-deboard, next-flight import and recovery] [93, Load reconciliation]
Verify integration functions against the current V3 documentation and actual provider versions before depending on them in a scenario. This review does not establish complete V3 de-icing modelling or every abnormal-arrival automation branch. Neither a vehicle animation nor an automatically requested service independently verifies a physical treatment or safety condition. For a failure lesson, establish which routine service automations are active and observe how they interpret the injected state. Keep any unverified branch in the coverage matrix rather than replacing current instructions with an old integration limitation or workaround. [132, V3 GSX, de-icing and abnormal-arrival branch verification] [21, PDF pp. 277–283]
For a reproducible ground-service test, retain the stand, panel state, load plan, provider versions and relevant automation preferences. Change one service or setting and record the event that requested it and the state it produced. The normal pre-start and after-landing checks still need to reconcile the actual aircraft and ground arrangement. A well-integrated service workflow reduces workload by keeping those states coherent; it does not remove the need to observe power, doors, brakes, steering release and completed loading before the next phase. [133, Integration configuration and workflow] [23, PDF pp. 1034–1038,1048–1053,1159–1165]