Good evening,
maybe a question for the dispatchers ...
We have a V1 for dry and a V1 for wet conditions. What V1 do we need if we have a wet "skid resistant" runway? Is it equal to the dry V1, or is it somewhere between the dry and the wet V1? The difference is very small anyway.
Regards,
|-|ardy
Hardy,
I *think* I recall once reading in our FOM that a wet skid-resistant runway should be treated as any other wet runway, thus using wet (lower) V1 values (in our operation, of course).
I will try to find this paragraph again.
Best regards,
Mariano
The key phrase for us is whether the runway appears "reflective." Having said that, in my opinion, it's not often that a grooved runway appears reflective. In my 32 year airline career, I've never heard an ATIS report the percentage or depth of water on a specific runway at a specific time. So it's pretty subjective. Do what you want.
(http://www.hoppie.nl/forum/var/wet-runway(1).jpg)
Thank you. I'm asking because the NG FMC allows three valid entries: wet, dry, and now also wet skid resistant. I don't know if the FMC itself takes this nuance into account in its own V1 speed computations, or if this info is just used for the data uplink request so that the dispatcher's computation can be more specific. However, the dispatcher should know the runway conditions anyway. So I assume this variable is applied in the FMC's own V speed computations.
Regards,
|-|ardy
QuoteSo I assume this variable is applied in the FMC's own V speed computations.
Operationally, we never use the V-speeds generated by the FMC for takeoff. The
pilots input the zero fuel weight, takeoff CG, runway/intersection and runway condition into the CDU and send it off to Aerodata.
We use this page below to select the runway condition. There are sub-menus at 1R through 5R for depth of clutter and braking action reports. I've never used it because you don't know what the depth is until you get out there and even then it's almost impossible to tell. Plus, by then it's too late because you've been cleared into position on the runway. For the engineer-pilots who want to knock themselves out, this would be the micrometer/grease-pencil/chainsaw (measure/mark/cut) in action.
(http://www.hoppie.nl/forum/var/runway-conditions.jpg)
It takes a few seconds and Aerodata will ping us back with the takeoff flap setting, assumed temp, if any, takeoff N1 and V-speeds. The other current conditions like wind, temperature and altimeter will auto-populate in real-time without even having to enter them.
Just to add for readers not so familiar with these things:
All the nice features above are not part of any FMC or other standard box in any aircraft off the Boeing manufacturing line. They are all implemented per-airline and usually can be programmed in the CMU as part of the per-airline ACARS section. In between airlines there is a huge, if not staggering difference in how they use ACARS in daily operations. In general, the larger the airline, the more customized their ACARS menus and the associated server backend. Some airlines are very, very proficient in doing all this magic in-house. Others rely on contractors to build it all, usually sharing common options with other customers of the same contractor.
Hoppie
Quote from: Jeroen Hoppenbrouwers on Mon, 13 May 2019 10:00
Just to add for readers not so familiar with these things:
All the nice features above are not part of any FMC or other standard box in any aircraft off the Boeing manufacturing line. They are all implemented per-airline and usually can be programmed in the CMU as part of the per-airline ACARS section. In between airlines there is a huge, if not staggering difference in how they use ACARS in daily operations. In general, the larger the airline, the more customized their ACARS menus and the associated server backend. Some airlines are very, very proficient in doing all this magic in-house. Others rely on contractors to build it all, usually sharing common options with other customers of the same contractor.
Hoppie
Interesting Jeroen! I wasn't aware of all these details, and I wonder if it can't be problematic .. I mean, since this can be taillored to operator specifications, someone has to program it - can't it interfere with the overall FMC / CDU performance?
We use Aerodata as well, which affords us no option for skid-resistant/grooved runways. Runways are considered dry, wet or contaminated, construction surface not becoming part of the equation.
Dispatch uses basically the same system, only difference being that we request data via ACARS as opposed to a PC. In case ACARS becomes inoperative, we always carry a TLR (part of the dispatch documents). A "Live Calc" with dispatch over the phone is also a possibility.
Regards,
Mariano
Hi Mariano,
When I rode with you guys on the DHL plane a few weeks ago, there was no ACARS so the crew just used the TLR. We were 37,000 pounds lighter than planned. I asked if there was a ZFW limit below the planned ZFW and they said no -- no limit as to the difference under the planned ZFW. I like this approach rather than using the Aerodata. At least you have TLR in-hand and don't have to screw around sending free text messages to dispatch with the new payload, hoping they update Aerodata so you can get numbers back.
We have a limit of no more than 10,000 pounds lower than the planned ZFW but we have oral permission to ignore the limit at captain's discretion and just use TLR. For that reason, I usually don't even screw with Aerodata, except to show my students how to use it, just in case they end up flying with a guy who thinks they're going to ball up in flames if they don't get the exact numbers for the actual weight. I like Atlas's approach-- no limit on the low side. That's how it should be.
Jon
Aerodata? There's a company called "Aerodata" in Germany. You probably mean a different service?
|-|
Jon,
Yeah, none of our DHL -200s have ACARS, which actually makes them quicker to pre-flight, although the departure message to dispatch via (mostly) San Francisco Radio increases the PM's workload later on ;-)
I too am fond of TLRs; although when in the -300s, an ACARS calculation is always a good "CYA" precaution in case something goes wrong later on ("So, tell us, why did you elect NOT to obtain more accurate performance numbers via ACARS?").
Hardy, Aerodata's website shows a U.S. contact number, although that might just be a routable number to Germany.
Moreover, I had recurrent training today. Instructor confirmed that (for us) a wet grooved/skid-resistant runway is to be treated as any other wet runway.
Best regards,
Mariano
This AeroData Inc. is based in Phoenix, Arizona.
https://www.aerodata.aero/Official/
https://ecorp.azcc.gov/BusinessSearch/BusinessInfo?entityNumber=07041276
I think they do a significant portion of the domestic US carriers' performance data.
Hi,
A few questions, if I may ask. ;-)
QuoteOperationally, we never use the V-speeds generated by the FMC for takeoff. The pilots input the zero fuel weight, takeoff CG, runway/intersection and runway condition into the CDU and send it off to Aerodata.
I assume that you typically use the ,,4 eyes principle" before sending the data out into cyberspace, right?
But what happens next?
Do the pilots rely entirely on the speeds transmitted back to you or do you compare them with own calculations or FMC generated speeds? Even if the database at Aerodata is accurate (and most probably certified I guess), no one can rule out the possibility that a computer makes a wrong calculation.
And do you have to manually enter the speeds into the FMC (i.e.transfer them from one CDU to another) or does this work automatically?
Is there any 744 in the world where the pilots make all their calculations themselves like the procedure in the famous Virgin 19 video? (I really admire the F/O for his dedication when he explained the whole stuff in great detail).
Best regards,
Dirk
As soon as I sit down in my seat, I set the V2 speed from the TLR into the MCP. This is based on the
planned takeoff weight. That's one check. We do rely entirely on Aerodata if that's what we are using. In fact, none of our 767 aircraft have the feature to even suggest V-speeds.
Another backup is experience. I know what the speeds should look like based on past experience. Also, on the 767, Vref30 at 260,000 pounds is 130 knots and every +/- 20,000 pound deviation means 5 knots from 130. Vref30 is very very close to V1 at flaps 5. Vref30+5 is close to Vr and Vref30+10 is usually the same as V2.
So, at 360,000, Vref30 = 155, which is going to be pretty close to V1 for flaps 5. Vr will be 160 and V2 will be 165.
QuoteAnd do you have to manually enter the speeds into the FMC (i.e.transfer them from one CDU to another) or does this work automatically?
Once the V-speeds are manually inserted into one CDU, they're automatically in the other. On both our fleets, the flying pilot takes off on the takeoff page (press INIT REF), which shows the V-speeds and flap setting. The non-flying pilot is on the LEGS page for takeoff. This isn't our procedure, but at the first movement of flaps after takeoff, if I'm the non-flying pilot, I will select VNAV on the flying pilot's CDU, although I prefer the LEGS page when I'm flying because the next thing that's going to happen is we're going to be given direct somewhere. Since it's not our procedure anyway (it's Polar's/Atlas's), I usually have to select what I want when I'm flying.
Quote from: Dirk Schepmann on Tue, 14 May 2019 07:17
And do you have to manually enter the speeds into the FMC (i.e.transfer them from one CDU to another) or does this work automatically?
The 744 NG FMC provides new PERF INIT and TAKEOFF REF pages with data uplink functions, similar to the uplink function on the DES FORECAST page, but more detailed: Uplinked data are displayed in small font for your preview, and then you accept or reject all displayed values by pushing a certain single key.
Regards,
|-|ardy
Dirk,
Our procedure is very similar to Jon's. During preflight (before loadsheet arrives) we "bug" the speeds indicated on the TLR for the planned takeoff weight, runway, runway condition and flap setting (and set V2 in the MCP).
Once Aerodata prints out (after we receive loadsheet and populate Aerodata fields with information derived from it and the latest ATIS), I always check that the tail number, weights, CG, DDG items and meteorological conditions displayed on the printout are the same ones that I entered into the ACARS request.
Next (after load verification with loading agent takes place) all operating crew members participate in the PERF INIT and TAKEOFF REF pages data entry procedure of information derived from the loadsheet and Aerodata printout (SIC reads loadsheet and printout numbers out loud and monitors the PIC enter the data correctly, while the relief crew member watches both).
As we "bug" the Aerodata V speeds in the electromechanical airspeed indicator and MCP (V2), we can quickly assess wether they are different from those in the TLR that we "bugged" earlier. This is a good cross-check. If we have to move the bugs by a few knots, then we look for a reason(s) (Are we heavier or lighter than planned? Did the runway or runway condition change from the time we bugged the TLR speeds? Are meteorological conditions different than TLR expected conditions?, etc.).
Basically, we are comparing planned conditions calculated by dispatch hours ago with actual conditions recently sent out via ACARS by the crew.
Also, as Jon said, you have an idea of what V speed values to expect (as an unofficial tertiary check).
Best regards,
Mariano
Hardy,
The question is begging to be asked.
Can we assume that PSX will soon come with a built-in takeoff performance calculator? Or will the data sent to the FMC have to be manually entered in the instructor pages?
Please say it's the former, please! ;-)
Best regards,
Mariano
Why should it come if it's already there? FMC V-speed computation (balanced field) has been available in Precision Simulator for over 20 years.
|-|
I meant adding allowed takeoff weight, flap setting, assumed temperature data, etc. (like a full-time performance engineer department).
It was an improbable shot, but worth asking.
Best regards,
Mariano.
Jon, Mariano,
thank-you very much for the explanations!
Quote from: emerydc8 on Tue, 14 May 2019 08:27
Once the V-speeds are manually inserted into one CDU, they're automatically in the other. On both our fleets, the flying pilot takes off on the takeoff page (press INIT REF), which shows the V-speeds and flap setting.
The automatic synchronisation of R and L CDUs is clear. I referred to the uplinked data and wanted to know whether they are automatically inserted into the TAKEOFF REF page? Looking at your answers I can see that this is not the case.
So basically you have to make sure that you 1.) transmit the correct data to your company and 2.) that you copy the correct figures from the printout into the TAKEOFF REF page.
The workflow makes sense but there are still lots of data entry steps involved. On the other hand, if everything would be completely automatic, pilots would probably lose their common sense whether the transmitted data are correct. That's always the pitfall of automation - regardless in which environment people are working.
Best regards,
Dirk
Quote from: Mariano on Tue, 14 May 2019 15:13
I meant adding allowed takeoff weight, flap setting, assumed temperature data, etc. (like a full-time performance engineer department).
PSX already takes gross weight (takeoff weight in the NG FMC), flaps, thrust derate, pressure altitude, OAT, slope, wind, runway condition into account. All these parameters are to be set in the FMC by the crew (or by uplink in the NG FMC). The V speeds you get in PS since version 1.0 are no fake speeds :-) PSX includes dedicated algorithms and databases (balanced field) for that.
If you don't mean the math itself but just a new graphic interface for a flight planner console -- no, PSX will not get something like that. There are already enough external programs for that job.
In PSX the math sits in the FMC, and the control sits in the CDUs. And the uplink model will use the same math. Add-ons can intercept the uplink though, and uplink different data.
|-|
Problem is that FMC-derived speeds are based on a level dry runway at sea level with a balanced field length as the V1 policy. The FMC doesn't know about clearways and stopways (which can unbalance the field), obstacles off the departure end, your V1 policy, if you're using alternate forward CG for takeoff, MELs requiring an adjustment to the V-speeds, if the runway is narrow or standard width (for aircraft that can do that), the list goes on.
Most airlines don't fly that way anymore. We use systems like AeroData (who I am very familiar with - I helped set up and train the TLR at my last now-defunct airline (RYN). My current carrier does this in-house - our crews currently use a performance laptop, but that will be changing soon to an ACARS solution). By using a more advanced system we can lift more weight off a runway by better optimizing the V-speeds and unbalancing the field as long as the AFM permits it. We can also use reduced and derate thrust to the fullest extent (within the limits of the AFM) by using more advanced speed systems.
Our system also knows if the runway is grooved or PFC overlay, or not (I can also set the calculation to ungrooved if there are NOTAMs saying so). I never see if there is any real change in grooved/PFC or not for takeoff as most of the places we go runway length (outside of KSNA - 5701 ft TORA) is never a problem. But performance engineers like their numbers :)
None of our procedures on any of our fleets use the FMC-derived V-speeds for anything.
I guess most, if not all airlines, nowadays don't select the FMC computed V speeds on the TAKEOFF REF page. Some even use the option to hide them, as we know. I think that those that don't hide them don't select them either but just use them for comparison before entering the dispatcher's values. For this reason the NG FMC has a comparison feature that can be toggled on and off; it can display the FMC computed speeds in the center of the page and the entered values on the right side as usual. This is just for comparison.
QuoteProblem is that FMC-derived speeds are based on a level dry runway at sea level with a balanced field length as the V1 policy. The FMC doesn't know about clearways and stopways (which can unbalance the field), obstacles off the departure end, your V1 policy, if you're using alternate forward CG for takeoff, MELs requiring an adjustment to the V-speeds, if the runway is narrow or standard width (for aircraft that can do that), the list goes on.
It's clear that all these unbalancing parameters are not in the FMC. But I would exclude three of them: The dry/wet parameter can be added in the FMC optionally (plus "skid resistant" in the NG FMC). And the FMC does know the pressure altitude from the ADC. The slope can be entered as well.
Cheers,
|-|ardy
Quote from: Hardy Heinlin on Sat, 11 May 2019 15:42
Good evening,
maybe a question for the dispatchers ...
We have a V1 for dry and a V1 for wet conditions. What V1 do we need if we have a wet "skid resistant" runway? Is it equal to the dry V1, or is it somewhere between the dry and the wet V1? The difference is very small anyway.
Regards,
|-|ardy
Hardy,
Not sure you had your question answered, so I'll take a crack at it.
The certification rules permit the OEM to furnish wet runway takeoff data for a skid resistant surface (i.e., a grooved for PFC runway surface). The braking coefficient of friction on these surfaces is better than on a wet smooth runway surface, but not as good as on a dry skid resistant surface. Accelerate stop distance could be shorter on a wet skid resistant surface verses a wet, smooth runway, and could result in a different (higher) V1 speed. The V1 speed will be specific to the skid resistant surface accelerate stop distance data in the AFM.
The operating rules in the US permit the operator of a turbine engine powered, transport category airplane to use data, if the OEM furnishes it in the approved performance section of the AFM (it's not "advisory data like contaminated runway data), provided the runway is designed, constructed, and maintained in manner acceptable to the FAA Administrator. And, that's a loaded question depending on who you speak with.
Speaking with some of the Boeing performance engineering training people who I work with in industry groups, some operators are using the skid resistant performance data, while other are not.
How the data is furnished to flight crew, I believe has been answered.
Hope this helped.
Rich Boll
Wichita KS
Thank you for the good tips, Rich.
Regards,
|-|ardy
The NG FMC was developed for the 747-8, and then offered as a retrofit to the 744. As such, the 747-8 performance is all digital (not in the AFM) and was certified with skid resistant performance data. Thus AeroData, using the 747-8 SCAP files from Boeing, incorporate the airport runway surface condition and use skid-restraint surface data if the runway is grooved etc.
The 747-400 was never certified with skid-resistant data. Thus, this NG FMC capability is not functional on the 744, much like the Vertical RNP/ANP, or Quiet Climb.