Single-Engine Taxi Intelligence: Maximizing Eligible Opportunity and Measuring the Result

Single-engine taxi is already an established airline fuel-efficiency practice. The challenge is not awareness. It is identifying when a usable opportunity exists for one specific flight, updating that estimate as the airport operation changes and showing afterwards what actually happened.

In Single-Engine Taxi-Out (SETO), an eligible aircraft may taxi with one engine for part of the route to the runway, with the airline-required start and warm-up period for the second engine preserved before takeoff. In Single-Engine Taxi-In (SETI), an eligible arrival may use one engine once the applicable cooldown requirement has been met. Eligibility and timing vary by airline, aircraft, engine, airport and condition, and not every flight is suitable.

TripAI adds a flight-specific advisory and measurement layer. It combines route and aircraft context with predictive congestion intelligence, follows the operation as conditions change and creates a post-flight learning record.

Challenge: A Planned Taxi Time Is Only the Starting Point

A planned taxi time is an estimate made before the operation begins. The expected runway can change, a departure queue can grow or clear, and the aircraft may be given a different route. Surface traffic, runway configuration, stops, crossings and ramp activity all alter the time remaining, while weather, visibility or airport restrictions change the operating context. Airline-defined aircraft and engine requirements may reduce or remove the window altogether.

So a long taxi does not automatically mean a valid single-engine taxi opportunity, and an airport average cannot show whether a specific aircraft still has enough usable taxi time at a specific point in the operation.

The same gap appears afterwards. A taxi-time report can show how long the aircraft was moving or stopped, but it cannot by itself show which engine was operating or what fuel was actually saved.

The challenge is to identify a conservative usable window, keep it current and separate modeled opportunity from validated performance.

Solution: Combine Operational Physics with Predictive Congestion Intelligence

TripAI works in four stages alongside the airline's approved procedures.

Identify

A controlled operational layer establishes whether a flight can be considered at all. It uses airline-approved information: aircraft and engine configuration, technical eligibility, gate or stand, expected runway, likely route and airport geometry, the airline-defined start, warm-up and cooldown requirements, weather or airport restrictions and any operational exclusions. Approved aircraft requirements and airline procedures define the operating boundaries.

Predict

TripAI estimates the usable window rather than treating the whole planned taxi time as available. The first layer establishes the physical route context from the gate or stand, expected runway, taxiway geometry, plausible route distance, aircraft progress and configuration, and it protects the airline's controlled operating requirements.

The second layer is predictive. Where suitable live and historical data exist, models estimate expected taxi duration, remaining taxi time, likely queue delay, runway-configuration effects and the confidence attached to each estimate, using signals such as surface traffic, recent movement, departure and arrival queues, runway configuration, airport restrictions, weather and visibility, time of day and comparable historical operations.

This is a route-specific operating baseline first and a prediction second, so models must be calibrated by airport, fleet and operating context. If the remaining time is too short, the data are stale or confidence is insufficient, the correct output is no advisory.

Update

The recommendation is not fixed at pushback or touchdown. It responds to actual movement, elapsed time, stops, speed, route and runway changes, queue growth or clearance, revised remaining distance and any loss of data quality. The advisory can be updated, shortened or withdrawn when the operation changes.

For taxi-out the estimate ends early enough to preserve the airline-required engine start and warm-up before takeoff. For taxi-in the airline-required cooldown after landing is preserved first, and only the remaining eligible period is offered.

Reconcile

Surface movement data supports the actual route, timestamps, stops, observed taxi duration and a reconstruction of the modeled opportunity against the prediction. It cannot prove which engine was operating, the exact engine start or shutdown time, actual engine fuel flow or a realised fuel saving. Authorised airline evidence may include engine-state data, Aircraft Communications Addressing and Reporting System messages, Out-Off-On-In milestones, fuel messages and Quick Access Recorder or Flight Data Monitoring records.

Movement data identifies and reconstructs the opportunity. Airline engine and fuel data validates whether it was captured and what the realised result was.

Validated outcomes then feed calibration: predicted against observed taxi time, advisories shown, revised or withdrawn, modeled against validated fuel impact and recurring airport and fleet patterns. Machine learning can improve future taxi-time and congestion estimates from these results, but model updates remain monitored, versioned and subject to airline review.

What the Airline Receives

• Flight-specific SETO and SETI opportunity screening
• A conservative window that follows changing airport conditions
• Clear reasons for showing, changing or withholding an advisory
• Post-flight comparison of predicted and observed taxi performance
• Modeled or validated fuel impact, depending on the evidence available

The output is a traceable record from the initial opportunity to the completed taxi, not simply a theoretical fuel counter.

TripAI identifies, updates and measures the opportunity. The airline's approved procedures and crew remain in control.

• Airline-defined eligibility
• Aircraft-specific configuration
• Approved warm-up and cooldown requirements
• Advisory only
• Crew and dispatch authority unchanged
• Stale or unreliable data produces no advisory
• Shadow-mode validation before operational release
• Fuel claims require authorised airline evidence

Model outputs are versioned and auditable. TripAI does not operate aircraft systems, replace Standard Operating Procedures, replace dispatch or replace crew judgement.

“Azul Linhas Aéreas had the opportunity to work with the TripAI team on two analytical tracks: Single Engine Taxi Out (SETO/EOTO) optimization and On-Time Performance (OTP) analysis. Throughout this process, the TripAI team demonstrated strong technical depth, professionalism, and a genuine effort to understand Azul's operational data and context. Deliverables included predictive ML models applied to real Azul operational data, a dedicated simulation environment, and detailed analytical presentations covering fuel efficiency opportunities and OTP drivers.”
— Azul Linhas Aéreas management