AI Traffic in LSZH (AFCAD2)

[Walter Oberholzer]

Hallo, ich hätte dazu eine Frage:

 

Hat es jemand geschafft, in LSZH mit dem neuen AFCAD2 eine vernünftige Separation des Ground-Traffics zu erreichen?

 

Bei mir ist im Nomralfall immer nur die Rwy16 aktiv (für Starts und Landungen), was natürlich bei etwas mehr Traffic (mit dem UT-update) auf dem Taxiway E sehr grosse Probleme gibt.

 

Das Schliessen/Oeffnen von Runways im AFCAD2 hilft leider nichts (wie das im FS2002/AFCAD1 sehr einfach möglich war).

 

Es wäre schon mal super, wenn ich wenigstens die Landungen auf die Rwy 14 brächte und die Starts auf die Rwy16, von einer Benützung der Rwy28 mal abgesehen (da diese die Rwy 16 kreuzt, vermutlich sowieso schwierig zu erreichen). Das würde meinen Ground-Traffic doch schon ganz gut separieren.

 

Hat jemand von Euch in dieser Hinsicht "gepröbelt" und ev. bessere Resultate erzielt?

 

Danke

[Renato]

Würde mich auch brennend interessieren, ich glaube jedoch, dass es zur Zeit nicht oder eben "noch" nicht möglich ist bei nicht Paralellen Rwy's...

[Walter Oberholzer]

Okay, nachdem zum Thema hier kein grosser Feedback kam, habe ich mal selber ziemlich detaillierte Tests am Beispiel von LSZH durchgeführt.

 

Basierend auf den bereits vorhandenen, gesicherten Erkenntnissen bei PAI (Afcad Forum) zum Thema "Multiple Runways" im FS2004 mit AFCAD2, wollte ich wissen, wie es bei Airports mit nicht-parallelen Runways steht. Dafür ist LSZH ein ausgezeichnetes Test-Beispiel.

 

Hier die grundsätzlichen Kenntnisse:

- "multiple" Runways werden nur bei parallelen (bis ca. 5° Abweichung) von ATC genutzt

- bei grösseren Abweichungen haben Versuche mit kleinen "Geister"-Runways (mit Abstand von ca. 5°) nicht die erhoffte Verbesserung gebracht, bzw. dies führt zu unvorhersehbaren Zufallsergebnissen. Meine Versuche mit solchen fiktiven Runways in LSZH haben praktisch keine Wirkung gezeigt.

- es sind immer beide Runway-Seiten für Starts bzw. Landungen als 'closed' oder 'open' zu definieren, eine Seite 'closed' und die andere 'open' führt ebenfalls zu eigenartigen und unvorhersehbaren Ergebnissen.

- wenn sich ein Flugzeug längere Zeit auf dem Boden nicht bewegen kann (ca. 5-10 Min.) wegen Stau, Gegenverkehr, zu langes Warten beim Take-off, etc. verschwindet es plötzlich (was grundsätzlich gut ist um 'head to head' Situationen aufzulösen).

- die ATC-Führung am Boden ist im FS2004 ziemlich clever, head-to-head Situationen werden möglichst vermieden.

- die Flugzeuge nutzen den kürzest möglichen Weg vom Standplatz zu der aktuell offenen Runway (bzw. zur Näheren von zwei parallelen Rwys).

- bei der Landung auf (zwei) parallelen Runways erfolgt die Zuweisung auf Basis der Anflugrichtung.

 

Meine Tests haben auf dieser Basis gezeigt, dass an einem Aiport wie LSZH (keine parallelen Rwy's, die sich z.T. auch kreuzen) immer nur eine Runway von ATC genutzt wird (für Starts und Landungen). In keiner der Einstellungen habe ich je gesehen, dass zwei Runways genutzt wurden.

 

Dies ist ein klarer Rückschritt gegenüber FS2002/Afcad1 wo es mit der Definition der Länge der Rwy (ändert die visuelle Abbildung nicht) und dem "Closed/Open" Eintrag sehr einfach war, in LSZH z.B. die 16/34 für Starts und die 14/32 für Landungen zu nutzen, was eine ziemlich gute Separation des Taxiway-Verkehrs ergab und obendrein auch der Realität mindestens teilweise entspricht.

 

Meine Tests mit FS2004/Afcad2:

Ich habe versucht, praktisch alle Kombinationen von "closed/open" für die Rwy's 14/32, 16/34 und 28/10 bei Windstille und leichtem Wind aus verschiedenen Richtungen (270°, 130° und 80°) zu simulieren und zu schauen, welche Rwy's von ATC dann genutzt werden.

 

Meine Tabelle über die Resultate ist recht umfangreich, hier nur die Haupt-Ergebnisse:

 

in der 'default' Einstellung von FS2004 sind alle drei Rwy's in LSZH offen für Starts und Landungen. Bei Windstille wird 16 genutzt, bei 270° die 32, bei 130° und 80° die 14.

- diese Nutzung gibt diverse, grössere Probleme:

16: Gegenverkehr auf Taxiway E, somit viele Staus, zudem viele Go-arounds

32: Landung entspricht nicht Realität, langer Weg auf der Runway bis zum Turn-off (gibt viele Go-Arounds)

14: sehr problematisch: Starts in der Realität nicht üblich, zudem gehen die Flieger auf dem Runway noch zum Endpunkt und machen eine 180°-Wendung, was weitere Staus und Go-Arounds provoziert

 

- die für den Bodenverkehr weitaus beste Nutzung ist die Einstellung, wenn nur die 28/10 genutzt wird. Obwohl dies auch nicht der Realität entspricht (Nutzung der 10 bei Wind 130° und 80°) sind die Bewegungen am Boden (auch bei hohem Verkehrsaufkommen) sehr gut, da die Distanzen zu den Gates und Parkings sehr klein sind und ausserdem bei den Landungen viele Abfahrten zu Verfügung stehen, sodass es wegen der raschen Turn-offs für alle Aircraft-Kategorien (unabhängig von der Landestrecke) zu wenig Go-Arounds kommt. Diese Nutzung (28/10) kann man in Afcad2 mit folgenden Einstellungen „provozieren“:

28/10 offen für Starts und Landungen, 14/32 offen nur für Landungen, 16/34 offen nur für Starts

 

- eine weitere, interessante Einstellung ist diejenige, bei welcher bei jeder Wind-Situation (no wind, Wind aus den 3 getesteten Richtungen) immer die Rwy 16/34 genutzt wird:

Einstellung: 28/10 und 16/34 beide offen für Starts und Landungen, 14/32 ganz geschlossen

Diese Situation kommt wenigsten der Nutzung in der Realität etwas entgegen, gibt aber wie oben bereits erwähnt auf dem Taxiway E (zur 16) ziemlich grosse Probleme.

Das kann man damit etwas beheben, dass man zwischen der jetztigen Taxiway E und der Rwy 16/34 einen zusätzlichen (fiktiven) Taxiway einbaut, welcher nur für Abfahrten ab der Rwy 16/34 nach der Landung genutzt wird und die ankommenden Flieger zur Ramp zurückführt, ohne dass diese den Fliegern die auf dem Taxiway E zum Startpunkt 16 unterwegs sind, begegegnen (Head-on situations).

 

 

Fazit:

1) An Airports mit nicht-parallelen und sich kreuzenden Runways ist es derzeit äusserst schwierig (auch mit dem neuen AFCAD2) die Realität vernünftig abzubilden.

 

2) Dieser bedauerliche Rückschritt gegenüber FS2002/Afcad1 wird sich eventuell noch etwas verbessern, wenn Microsoft den SDK für den ATC-Bereich endlich publiziert, was den Guru’s (sprich Lee Swordy) eventuell erlauben wird, die ATC-Logik von FS2004 besser zu verstehen, um in einem Update von Afcad allenfalls die Möglichkeit zu bieten, dass wir die Runway-Nutzung auch bei Airports mit nicht-parallelen Runways doch noch besser beinflussen können.

 

3) Im Moment bleibt nichts anderes übrig, dass wir uns teilweise mit etwas unrealistischen Szenarien abfinden (z.B. in LSZH alles auf 28/10) oder dass wir sonst mit ‚Behelfs-Massnahmen‘ (zusätzliche, fiktive Taxiways) den Bodenverkehr etwas optimieren, um grosse Staus und massive Go-Arounds wenigsten etwas abzuschwächen.

 

4) Ich habe nur in der Default-Szenerie getestet. Es wäre noch zu prüfen, ob mit AFCAD2 und in Addon-Szenerien ev. die Aenderung der Rwy-Länge etwas bringt (analog zu FS2002 und AFCAD1). Dies ist bei Addon-Szenerien möglich, weil sich die visuelle Erscheinung der Runway-Länge durch Anpassungen mit AFCAD2 nicht ändert wie in der Default Szenerie.

[Mike Strasser]

Hallo Walter

 

Vielen Dank für Deine Bemühungen. Auch ich ärgere mich ständig über diese Situation mit dem neuen AFCAD2/FS2004.

Bin auch ständig am basteln und ausprobieren und bin etwa gleich weit gekommen wie Du. Momentan offensichtlich eine Sackgasse.

Ich vertehe einfach nicht, dass Microsoft hier einen solch derartigen Rückschritt gemacht hat. Es hatte ja so schön funktioniert im FS2002. Warum nun also dies?

 

Nun ja, warten wir halt bis das SDK draussen ist, wer weiss....

hoffen darf man ja immer. ;)

[Renato]

Danke Walter für diese Detailierten Testresultate. Habe auch alles mögliche versucht auch mit den 5° fiktiven Rwy's, aber leider mit den selben schlechten Erfahrungen wie Du...

Die 28/10 Lösung macht in meinen Augen auch keinen Sinn, da zumindest bei mir viele Heavys bei 28 T/O weit über die Piste hinausrollen, bevor sie abheben :-(

Da bleibt uns wohl nichts anderes übrig, als auf das SDK von MS zu warten in der Hoffnung, damit dann eine Lösung zu finden...

[Walter Oberholzer]

Hallo Renato

 

Bei mir heben auch die Heavies von der 28 sauber ab (soweit ich das bisher gesehen habe).

Welche Flight Dynamic Files verwendest Du?

 

Bei PAI Fliegern musst Du im FS2004 unbedingt auf die Version 6 FD's wechseln, da das späte Abheben einiger Heavies offenbar eine Folge der älteren FD's ist (v2 / v5).

 

Die v6 FD's von PAI sind dort im Forum zu finden (Abschnitt 'Flight Dynamics').

[Renato]

Danke, an dem wirds wohl liegen. Habe bei den meisten FDEv5 und bei anderen, hatte ich damals als es noch keine v6 gab die Default FS9 aus dem Templates Ordner genommen.

Gehe ich richtig in der Annahme, dass der PAI Installer die FDEv5 installiert und man die nachher alle von Hand auf die v6 updaten muss ?

 

Dann hab ich noch ein anderes Problem: Habe LSZH Default und die von Avsim zur Verfügung stehende AFCAD2 downgeloadet. Nur leider parkieren jetzt alle A332 nicht mehr an den Gates sondern verschwinden nach der Landung auf den RWY. Wie kann ich das beheben wenn ich nicht alle Heavy Standplätze vergrössern will ?

Danke schon mal!

[Walter Oberholzer]

Hallo Renato

 

Das ist richtig, soweit mir bekannt ist beinhalten die PAI-Installer immer noch die v5 files.

Man muss also manuell in den aircraft.cfg files nachbessern, was natürlich ziemlich aufwändig ist. Ich habe das auch mal für all meine PAI-Flieger gemacht (meine AI-Traffic ist eine Kombination von UT sowie PAI / FSP und AiA Fliegern / Flugplänen).

 

Hast Du den von mir publizierten File von AVSIM genommen (gepostet am 2.11.03)? Davon gibt es nun eine leicht verbesserte Version bei den PAI-AFCAD files (Datum 15.11.03).

 

http://afcad.projectai.com/afcads_all.asp

 

Die Gates wurden noch etwas korrigiert (Flieger stehen beim Midfield) nicht mehr mit der Nase im Gebäude) und W. Stuerzinger hat noch (geschlossene) Taxiways für den Bodenverkehr (Fahrzeuge) dazu getan, was ziemlich cool aussieht.

 

Mit diesem File habe ich ziemlich viele A332's und MD11's an den Gates und habe bis jetzt wenig verschwindende Flugzeuge gesehen. Allenfalls muss man eben die Traffic-Einstellung etwas herunternehmen.

[Renato]

Danke für den Tip. Habe ich nun gerade ausprobiert. Leider ohne Erfolg. Das grösste was es nun gibt sind die MD-11's. Keine 747 und auch keine 332, von welchen es ja von Swiss eiige geben sollte.

Erst wenn ich mit AFCAD2 die Heavy Standplatze vergrössere, kommen auch die 332 und die 744....

Das kann ja auch nicht an den FDE's liegen oder...

[Walter Oberholzer]

Hallo Renato

 

Jetzt weiss ich, woran es liegen dürfte:

Hast Du all Deine AI-Flugzeuge schon FS2004/Afcad2-mässig angepasst?

 

Man kann das mit dem "Aircraft Parking Manager" (apcmv151.zip) machen, oder auch andere Programme beinhalten die Funktion (AFCAD2, AITM).

 

Alle Flugzeuge sollten im aircraft.cfg file (für jedes einzelne repaint) folgende Einträge haben:

 

atc_parking_codes=xxx (airline ICAO code)

atc_parking_types=GATE, etc.

 

Ausserdem habe ich für alle Flugzeuge die Radii gemäss Vorgabe PAI gesetzt. Das ist eine Aenderung im .mdl file, die mit den erwähnten Progammen vorgenommen werden kann (MD11 hat z.B. 39m, A330 40m, B777 41m, A340 42m und B747 43m).

Diese Radii für die A330 und B747 sind bei Dir zu gross, weshalb diese Flieger in LSZH gar kein Parking finden.

[Renato]

Danke ! Oh Gott, da hab ich ja noch viel zu tun...

[Walter Oberholzer]

Die Anpassung mit dem Aircraft Parking Manager geht ziemlich schnell. Da muss man mal 2-3 Std. Zeit investieren und dann ist alles ok.

 

Uebrigens habe ich soben gesehen, dass es eine neuere Version gibt als die oben angegebene: apcmv16.zip

 

Gruss

[Renato]

Alles i.o. Habe soeben alles geändert. Jetzt hab ich auch endlich 332er auf LSZH !

Die neuen FDE's sind zwar immer noch nicht optimat. Die ERJ-145 hebt beim T/O ergendwo im Dorf Rümlang ab und landet bei der Tankstelle in Kloten :-) Aber sonst siehts schon viel besser aus. Der 332 hebt jetzt wenigstens nur noch ganz knapp nach dem RWY 28 ab...