787-900 Turnaround Times

Dear AS

Like many, I was super happy to see the addition of the 787-9 to the aircraft order books.

As a large user of the 787-8 on Stapleton (Thai Wings) I have longed for a capacity increase on certain routes...

But with a turnaround time of 2:00 compared to the 787-8's 1:30, I was soon disspointed as none of the new aircraft will fit my exisiting schedules due to slot constraints..

Subsequently, the 11 I have ordered are wasted.

My understanding was the the -9 wasn't that much larger then the -8, so is the 2 hour turnaround time accurate reflection on the aircraft type?

(On a side note....still waiting for the 737-400SF for cargoMAX...)

Cheers

There is another thread here in English forums, plus one in the German forums, and they will not be adjusting turnaround time much more.

I think the 787-900 should have a turnaround time the same as A340-200, as both can carry 420 pax.

TA ---- 342 / 789

IAD--- 1.30 / 1.45

LHR---1.45 / 2.30

JFK---1.45 / 2.00

DFW--1.45 / 2.30

HHN---1.00 / 1.30

An with a turnaround time of 2 hours, your B787-9 is even half an hour faster than mine, which take 2.5 hours to turnaround!!

Can we get an update to this....?

2:30 turnaround is just too long for this aircraft type.

KLM yesterday released real world schedules between AMS and UIO with 1:15 turn around...just like the 787-8.

First of all, there are no turnaround times in AS, but gross time on ground (incl. time for taxi etc.), hence you get different times pending on airport size.

As far as net turnarounds are concerned, Boeing states a difference of 1-9min between 788 and 789 for a usual config, pending on if it’s just a route or full station turnaround. That’s 28 vs 29min for the first and 42 vs. 51min for the latter. Of course these times are idealized, but their differences should be roughly what should be reflected in AS. A difference of 30mins IMO is too long, but I’d be ok with 15.

Thank you for posting this, I was about to compose something myself.

As stated above, Boeing says the TA between 787-8 and 787-9 is only aproximately 5 minutes. This makes sense as the aircraft is of course almost identical except for the fuselage stretch and resultant increased capacity.

In the past when asking the AS team about TA times, they attempt to justify the discepancy by saying that real world airlines using the aircraft/s in question have TA times similar to what they have implemented. This logic seems to be flawed, as the particular reasons a real world airline keeps an aircraft on the ground longer than its minimum TA time may have absolutely nothing to do with the actual speed in which they can effectively turn around an aircraft. For example a real world airline may leave an aircraft longer than minimum turnaround:

  1. In order to perform maintenance (not possible in AS during TA time).

  2. To leave “buffer time” time for delayed arrivals (not modeled in AS).

  3. Match slots restrictions or waves at arrival airport.

  4. Time of departure not in line with ideal travel times as per passenger preference (not modeld in AS).

Therefore using real world airlines “time on ground” (AS teams definition of TA time) is not a good data point… A 30 minute increase between 787-8 and 787-9 ground time makes about zero sense.

Please note as AK stated above, I am aware of the difference between the industries definition of TA times versus how AS defines them. In this case the taxi time AS adds in addition to normal TA is an irrelevant factor as both aircraft take the same amount of time to get to/from the runway.

Can we get an update to this....?

 

2:30 turnaround is just too long for this aircraft type.

 

KLM yesterday released real world schedules between AMS and UIO with 1:15 turn around…just like the 787-8.

+1

Really wish I knew where they were getting their data…

I'd really like to add capacity on a number of gameworlds, but this ridiculous TA time means I need 2x 789's on a route served by just 1x 788

The 789 really isn't that much bigger!

It sounds like that this is all going to disappear with http://www.airlinesim.aero/blog/2015/04/11/dynamic-turnaround-delays/

If you read carefully, existing servers will not change in turnaround times, it will only affect new gameworlds.

If you read carefully, existing servers will not change in turnaround times, it will only affect new gameworlds.

The actual quote:

All legacy game worlds will be patched with the new version, but all turnarounds will consist of a single dummy activity which simply uses the static turnaround times in use today. Random factors will stay disabled.

Although a completely offtopic tangent, is the process called ‘boarding’ for an aircraft, or is it embarkation? The ‘de-boarding’ in the blog’s example screenshot just looks wrong to me, but I’ve been working with archaic English dialects lately.

The actual quote:

All legacy game worlds will be patched with the new version, but all turnarounds will consist of a single dummy activity which simply uses the static turnaround times in use today. Random factors will stay disabled.

Which means that on legacy worlds the turnaround times will stay the same as they are now. That is my understanding until somebody from AS explicitly states otherwise.

Although a completely offtopic tangent, is the process called 'boarding' for an aircraft, or is it embarkation? The 'de-boarding' in the blog's example screenshot just looks wrong to me, but I've been working with archaic English dialects lately.

Boarding and deboarding are commonly used aviation terms. Deplane can also be used.

....Although a completely offtopic tangent, is the process called 'boarding' for an aircraft, or is it embarkation? The 'de-boarding' in the blog's example screenshot just looks wrong to me, but I've been working with archaic English dialects lately.

Going by what’s used in manufacturer documents, I’d go with board/deplane. Deboard sounds strange to my ears as well.

Which means that on legacy worlds the turnaround times will stay the same as they are now. That is my understanding until somebody from AS explicitly states otherwise.

But you need read on... I guess the implementation would be like what happened for cabin config.

Quote:

At a later point, when the new system has matured, we might decide to introduce it in old game worlds. But that’s something we’ll decide when the time comes