Entering data in TAKEOFF REF

[Will]

TAKEOFF REF (for the legacy FMC) and TAKEOFF REF 2/2 (for the NG FMC) let you enter wind, slope, and runway conditions (wet vs. dry, also wet/skid-resistant in the NG). These entries affect the FMC-calculated V-speeds.

But in real world ops, many (most?) crews disregard the FMC-calculated V-speeds, and instead use V-speeds provided by their dispatch office (because the dispatcher would know about factors that the FMC knows nothing about, such as obstacles at the far end of the runway or various company limitations).

The dispatch office would also theoretically know about wind, slope, and runway conditions.

So here is my question: when you get V-speeds provided by your dispatch office, do you bother entering wind, slope, and runways conditions in TAKEOFF REF?

I can see two answers: (A) Yes, because you can compare the FMC-calculated V-speeds to the dispatcher's V-speeds, and maybe that's interesting; or (B) No, because you disregard the FMC-calculated V-speeds anyway, so this extra step is pointless.

Thoughts?

[Mariano]

Will,

Speaking for our 767 fleet only.

We do not enter wind, slope, or runway condition on the TAKEOFF REF pages. We do this on the specific ACARS pages that we use to request real-time performance through a vendor (to answer your first question). Actually, we do not enter slope since the vendor's database has them.

Our FMC V speeds are inhibited (all three). With the paperwork we receive from Dispatch, we always get a TLR (Takeoff and Landing Report). During our panel scan, we set the TLR (expected) V speeds on our electromechanical airspeed/Mach indicators, and V2 in the MCP.

When the loadsheet arrives, we load fuel onboard, ZFW, and takeoff CG on the already preloaded performance request ACARS pages (preloaded with expected runways, runway condition, wind velocity, OAT, and QNH from the latest ATIS).

Once results arrive, we check them, and enter the ZFW, takeoff flaps, assumed temperature (if applicable), takeoff CG, and V speeds into the FMC. We then compare these latest V speeds with the expected ones we set earlier on the electromechanical airspeed/Mach indicators as a basic cross check. If we are lighter than OFP/TLR expected, then we expect V speeds to be lower, and if we are heavier, we expect them to be higher (with some exceptions such as with wet runways or slight tailwinds/less headwinds from TLR forecast, of course). This should answer your second question.

Since our 747-400s are now all NG-equipped, the 744/748 fleet is starting to use some of the request features from the FMC pages (PERF INIT was the first step).

I believe that they might start using the TAKEOFF REF request next, but that's just a guess.

Since our airline was started with 747s, most changes begin there and slowly trickle down to other fleets. I would love for us to use the full request features of the NG/Pegasus FMCs some day, but that remains to be seen. These consequential regulatory changes can take quite some time.

Best regards,

Mariano

[United744]

Not 747, but one airline uses dispatch speeds, and doesn't use the FMS calcs at all.

[DougSnow]

The dispatch office would also theoretically know about wind, slope, and runway conditions.

I can see two answers: (A) Yes, because you can compare the FMC-calculated V-speeds to the dispatcher's V-speeds, and maybe that's interesting; or (B) No, because you disregard the FMC-calculated V-speeds anyway, so this extra step is pointless.

Thoughts?

As a dispatcher I could care less about runway slope - our performance software's airport database, however does know.  When I enter the field conditions (our FPS can read the TAF for sked time of operation and use those conditions automatically);  I click a button and get a weight, which is the max allowable weight this airplane can lift today with these MEL/CDL items, bleed configuration, and conditions.  I can play with it a bit, but the weight returned is the max available MTOW, which as a DX is all I care about. If the crew wants to derate or play ATM, that's a crew procedure.

For our crews, they have a laptop with the same software - so if they enter the same conditions as I used on the flight plan they'll get the same results.  Soon we'll be starting to uplink the takeoff data directly into the FMC.  With the manual process, crews can fat finger the weights and speeds in and get less then desired results (like tail strikes).  With uplink, the system knows the actual ZFW, we can read the fuel on board, the system knows the flight plan and the weather and current conditions, all the crew will have to do is to determine which runways they want a solution for, and our performance server will uplink the data (the crew will of course be able to accept or reject the uplink) directly into the FMC. 

We have no procedure where the crews compare the box to our performance software.

[744]

In my airline, we would use CARD, obtained via ACARS or SATCOM giving direct access to an electronic version of the Airplane Flight Manual.

Here we would input all the data, Airfield, OAT, RWY, WND, Pressure etc. We would use the dispatch estimate of the TOW. Once sent, this would generate a print out showing TOPL with the computed V Speeds. Once the loading was complete, we would then carry out the critical data procedure, where we both check and enter the ZFW into the CDU.

We would then check that the FMC speeds were within 3 knots of CARD.

[Will]

Thanks, everyone.

There are two issues here; one is where the flight V-speeds come from, and the other is what data are entered on TAKEOFF REF 2/2 with regards to OAT, wind, slope, and condition.

It's clear that it's rare for operators to use FMC-calculated V-speeds. And some operators don't even have FMC-calculated V-speeds enabled.

Thus for most operators, the TAKEOFF REF 2/2 OAT, wind, slope, and condition entries are irrelevant unless the pilot wants to compare the FMC-calculated values with the OFP values. But for operators that don't even show FMC-calculated V-speeds, the entries are completely irrelevant.

Thanks again!

[United744]

Thus for most operators, the TAKEOFF REF 2/2 OAT, wind, slope, and condition entries are irrelevant unless the pilot wants to compare the FMC-calculated values with the OFP values.

Pretty much!

The reason is pretty simple: the FMC can only take generic data and produce a generic result, whereas airlines pay for specific airport/runway performance data, which is tailored down to the specific airframe (some being heavier than others, by quite some margin in some cases). It allows them to squeeze every last ounce out of the aircraft load capability for a given runway and conditions.

[dhob]

Unless using improved climb speeds, V2 will be the same speed whether using the FMC speed or a performance program. V2 is a minimum flying speed and has no relation to V1 or whether the field is balanced or unbalanced. V2 must be at least 1.1 X VMCA and 1.13 X VS1G. Pressure altitude and flap setting are the only factors that affect V2, and both parameters are provided to the FMC. VR is tied closely to V2, and moves closer to V2 when a reduced thrust or assumed temperature method is used (increased temperature) for a given flap setting.
As such, flap setting and pressure altitude affect V2 and VR, and additionally thrust and temperature affect VR. Again the FMC knows these factors and thus the FMC V2 and VR will be the same (plus or minus a knot) as the operator generated performance. 
All the above factors affect V1, as well as slope, wind, and runway friction (wet/contamination). The field limit weight relative to the runway available determines whether the V1 speed may be unbalanced or a reduced thrust can be used or a combination of both.
Our company performance will reduce thrust as much as possible, then unbalance the field if any usable runway is available. If available, V1 is always unbalanced toward V1MIN to provide an increase in Accel-stop safety margin. On initial implementation, the TAKEOFF REF page 1 and 2 values for wind, slope and OAT etc were left blank. A reasonability check was still viable for VR and V2, but since V1 may be an unbalanced V1, the FMC V1 was ignored.
The takeoff performance is now uplinked to the FMC, and a requirement to uplink the data is, all blank TAKEOFF REF fields must be filled. However, this doesn't change the FMC speeds versus the operator performance data. V2 and VR can be compared as discussed above, and V1 is still disregarded due to the possibility of an unbalanced V1.
Having the fields filled in creates a new set of problems however. Since our performance uses the current METAR, the OAT that is entered on TAKEOFF REF pg 2 may differ slightly from the actual OAT temperature at the airplane. If this difference exceeds 1 degree C, when the third engine is started, the V-Speeds are deleted.