Coordination in VATSIM (Vorsicht SEEEEEEEHR viel text)

[Andy Würde]

Hallole!

Wie dem Kollegen Söllner in einem anderen Thread versprochen, will ich hier mal ein paar Worte zum Thema Coordination verlieren. Der Post könnte etwas länger werden, aber ich hoffe es ist etwas drin, was der eine oder andere Gebrauchen kann.

Coordination im RL ist eine Notwendigkeit, da ATC ein hochdynamisches medium ist. Flieger, die plötzlich vom upper in den Lower oder anderstrum wollen müssen mit Point outs (bei uns Positions) übergeben werden, FPL-Details ausgetauscht werden, Directs koordiniert werden, Revisions gegeben,...
All das geschieht nur, damit der angrenzende Sektor über Flugbewegungen in seinen oder durch seinen Sektor informiert ist.
Im RL hapert es daran, daß das System Daten übermittelt, wenn bestimmte Zeitparameter unterschritten sind. Außerdem wird im RL Vorplanung, vor allem im CTR, GROSS geschrieben , was bei VATSIM mangels Tools (MTCD, CV oder MINSEP) oder auch mangels Strips und deren Handling nicht stattfindet.... obwohl es manchmal nötig wäre
Hier ist VATSIM weiter, weil jeder Lotse, alle Daten eines bestimmten Fliegers in Echtzeit vorliegen hat.


Okay, weg vom RL, hin zur virtuellen Welt.
Ich beschreibe mal ein paar Procedures, von denen ich denke, daß sie in VATSIM vorkommen und gebraucht werden sollen. Alle diese procedure sind Absprachen, die eine eigene Phraseology haben. Die gilt in ATC auch bei derKommunikation Ground - Ground.

1.Approval Request: Dies stellt eine Anfrage an den ANNEHMENDEN Sektor da, ob man mit einem einzelnen Flieger oder mehreren von abgesprochenen Verfahren abweichen darf. Meistens handelt es sich um Directs.
Bsp:
EDMM_CTR ruft EDFF_CTR:
EDMM"Approval Request, Position MIQ DLH1234"
EDFF"Identified, go ahead"
EDMM" Can You accept DLH1234 from MIQ direct to PSA?"
EDFF"Approved"
EDMM" Consider"

Die Ausgangssituation: DLH1234 möchte gerne direkt nach dem Start in EDDM nach PSA. EDFF erwartet sie allerdings über ALB (ich streite mich jetzt nicht über Standard Routen und Fixe... hier geht es nur ums prinzip :P ) das kann seine Staffelung schon etwas Stören, wenn der Flieger jetzt so weit südlich kommt. Deswegen die Anfrage von München. Um es EDFF bildlich zumachen, um wen es geht zeigt er ihm die DLH mit Position. EDFF bestätigt den Contact durch "Identified". jetzt kommt der eigentliche request von EDMM (DCT PSA). EDFF prüft das (geht es oder geht es nicht) und approved ihn. Als Rückbestätigung sagt EDMM "consider" was so viel bedeutet wie "dann rechne mal damit".
Sollte es nicht gehen, dann muß man entweder anfangen zu handeln (anderer Level, Headings,...) oder der Flieger muß bei einem negativ von EDFF auf seiner Standard Route weiter fliegen.
Auch hier ist übrigens die Sprache Englisch wie man merkt :shock:
Das ganze geht auch mit mehreren Fliegern. Beispiel wäre eine Situation, in der 2 Maschinen nur 10 NM hintereinander her fliegen, der hintere aber schneller ist. Macht die abgebende Stelle aber auch nur, wenn sie sicher sein kann, daß die annehmende dem auch zustimmt. Das geht nur, wenn sich die Wege der Maschinen im anderen Luftraum trennen. (Einer ein Inbound und muß eh demnäxt descenden, verschiedene Routen bald nach der Boundary...)
Dann sähe ein Bsp so aus:
EDFF ruft EDMM
EDFF"Approval Request AUF123 and DLH456"
EDMM"go ahead"
EDFF"Distance 12 NM in between. AUF123 in front at 230kts and DLH456 280kts. can You accept?"
EDMM"approved, request release for descend for AUF123"
EDFF"released upon contact"

Hier fehlt z.B. die Positionsangabe. Das kann daran liegen, daß die noch so weit weg sind, daß man den Nachbarn da nicht zum verstellen seiner Range verleiten will oder auch daran, daß es für den eigentlichen Approval gar nicht wichtig ist, wo die sind.
Das bringt uns allerdings auch gleich zum nächsten Thema...


2. Release oder release request
Ein release bedeutet, daß die annehmende Unit den Flieger bewegen darf, obwohl er sich noch im Zuständigkeitsbereich der abgebenden Stelle befindet. Die annehmende Stelle requestet den release, die abgebende Stelle gibt ihn. Normalerweise dürfen Flieger erst bewegt werden (drehen, descenden, Speed Change, Squawk change) wenn sie die Grenze zwischen den Units überflogen haben (auch vertikal natürlich). Auch wenn der Funkkontakt schon besteht, darf ich ohne die Erlaubnis des Abgebenden, den Flieger nicht im fremden Luftraum anfassen....

Bsp. DLH1234 auf em Weg von MIQ nach PSA
EDFF ruft EDMM
EDFF"Request Release for climb DLH1234 [Position ALB]"
EDMM"Released"

Das war ja einfach In diesem Fall darf die Lufthansa unter der Kontrolle von Frankfurt steigen, obwohl er noch über ALB im Luftraum von EDMM ist.

Request
Das kann quasi alles sein. Die annehmende Stelle verlangt irgendwas von der abgebenden. Contact, direct (so kann man auch den Flieger im anderen Luftraum bewegen... ohne ihn auf der freq zu haben )...

Position
Das kommt ins Spiel, wenn es mit der Übergabe etwas knapp wäre. Also der angrenzende Sektor bei einem einfachen Handover ziemlich schnell entscheiden muß. Da will man ihm vorher den Flieger noch einmal zeigen. Diese Procedure ist oft auch als Point-out bezeichnet
BSP: unsere Lufthansa überlegt es sich kurz vor ALB anderst und möchte nach Nürnberg diverten. Leider kennt der Herr aus Nürnberg den Flieger ja nicht. EDMM ruft EDDN
EDMM"Actual Diversion, Position TALAL, DLH1234"
EDDN" Identified"
EDMM"A320 EDDM to EDDF, now diverting to EDDN"
EDDN"Identified, is acceptd inbound ERL, descending FL130"
EDMM"consider"

Wieder das Zeigen der Position der Maschine und warum ich das mache (actual Diversion). Dann die Details, weil der Nürnberger ja keinen Flugplan hat und dessen bestätigung, daß er ihn sieht. jetzt kommen seine Anweisungen, wie er den Flieger gerne hätte und wieder das berühmte "Consider als Rückbestätigung"

Da der Flieger kurz vor der Grenze zu EDFF Steht, muss der Münchner die DLH hier noch abmelden und eventuell noch einen release for descend holen.
EDMM ruft EDFF
EDMM"Position TALAL DLH1234"
EDFF"Identified, go ahead"
EDMM"Is diverting to EDDN You my disregard. He is descending FL130 to ERL, request release for descend through Your airspace"
EDFF"roger released"

Auch das ist, wie man sieht eine position, weil es ja auch eine sehr kurzfristige Änderung für den Frankfurter Kollegen ist. ZUr Psoition kann man auch "Expedite Clearance sagen" da es eine so kurzfristige Änderung ist (im Falle des Nürnbergers jetzt), daß ich quasi eine neue clearance der annehmenden Stelle einhole.


So, mehr fällt mir VATSIm Spezifisch erst mal nicht ein. Wenn noch Fragen sind... immer gerne.

Gruß aus den oberen Luftschichten

Andy

[Dieter Brugger]

Andy,

seeeehr interessant. Als ich letztens bei euch im ACC sein durfte dachte ich immer: Was macht denn der zweite Mann da? Total falsche Phraseologie. "Consider, Release", sowas?! Naja, dachte ich, er spielt ein anderes Spiel....

Nee im Ernst, vielen Dank für die Ausführungen. Ich glaube man kann das durchaus bei uns verwenden. Besonders das "Position" finde ich sehr nützlich, denn manchmal kommt ein Request von irgendwoher und ich fang dann an zu suchen wo der Flieger gerade ist.

Schönen Sonntag wünscht...

[Martin Georg]

Moin Andi.


vielen Dank für die Ausführungen. Ich kann dazu noch einige technische Tips mitliefern, wie man das von Andi gesagte mit ASRC auch praktisch umsetzen kann.

Allerwichtigstes Hilfsmittel ist der Pointout, also das Zeigen eines Fliegers für den anderen Controller. Im ASRC sind ja (außer im Tower/Ground Modus) alle Datablocks "fremder Flieger" generell nicht sichtbar. Ein Pointout öffnet nun einen Datenblock eines Fliegers auf dem Bildschirm des Nachbarcontrollers und stellt ihn blinkend, also wie bei einem Handoff dar. Die entsrechende Syntax ist "F1 <CID>", wobei <CID> die Controller-ID des anderen Sektors ist. Man sollte in jedem Fall seinen Coordination Request mit einem solchen Pointout einleiten, egal, ob über Voice oder über Text.

Dann die Details, weil der Nürnberger ja keinen Flugplan hat ...

Dieser Umstand läßt sich in VATSIM mit ASRC allerdings leicht umgehen, wir müssten ja nur den Arrival-Airport ändern. Dazu dient der Befehl ".am rte <ICAO-CODE>@" (Beispiel: ".am rte EDDN@"). Damit wird der Arrival-Airport auf EDDN geändert. Die Position des "@" bestimmt, ob der Departure- oder der Arrival Airport gemeint sein soll. ".am rte @EDDM" würde z.B. den Departure Airport auf EDDM setzen. Hat man z.B. den Arrival Airport entsprechend editiert, dann erscheint der Flieger mit seinem Flugplan auch umgehend beim zuständigen Controller in seiner Arrival Liste.

[Christoph Piel]

Hi,

kurze Frage, wann wird ASRC 1.1 released? Wir wollen diese tollen VSCS dann endlich ausprobieren

Bis jetzt mußte dafür immer mein Telefon herhalten

Ciao
Chris

[Christoph Winkler]

Zitat von Christoph Piel

kurze Frage, wann wird ASRC 1.1 released? Wir wollen diese tollen VSCS dann endlich ausprobieren

Also der Release-Termin ist doch schon lange bekannt: wenn er fertig ist!

Bis jetzt mußte dafür immer mein Telefon herhalten

Heute schlägt der XXL-Tarif ja wieder zu - da können wir das gerne mal machen. Allerdings habe ich als Münchner mit Bremen nicht so richtig viel zu koordinieren, hehehe ;-)

[Christoph Winkler]

Hier noch eine kleine Ergänzung zur Koordination und gleich dazu ein Vorschlag wie man die RL-Procedures für VATSIM verwenden könnte.

In RL funktioniert das Telefon zur Koordination wie ein normales Telefon ;-) Man nimmt den Hörer, drückt eine Taste, auf der Gegenseite klingelt es, dort nimmt man ebenfalls den Hörer in die Hand und drückt eine Taste um das Gespräch anzunehmen. Danach meldet sich die angerufene Stelle mit ihrem Namen, dann meldet sich der Anrufer mit seinem Namen und los geht's wie oben beschrieben.

Der "Name" ist hierbei die Sektorbezeichnung, also z. B. "Langen Süd 4" (oder auch SC4 - C = Coordinator), "Frankfurt Tower" oder "Rhein Radar Frankfurt Top Upper Planner" *g*. In der Praxis wird das aber meistens abgekürzt. Wenn Approach beim Tower anruft dann meldet der sich nur mit "Tower", Wenn Frankfurt bei Rhein anruft genügt auch mal ein "Rhein", und wenn innerhalb von einer Niederlassung koordiniert wird meldet man sich auch mal nur mit "ja". Am "Telefon" sieht man ja, welcher Sektor da gerade anruft - also genau wie auch bei ASRC.

Am Ende jedes Gespräches schliesslich sagen beide Seiten ihre Initials. Zum einen weiss dann die Gegenseite, dass jetzt nichts mehr kommt und das Gespräch beendet ist, und zum anderen werden alle Telefongespräche aufgezeichnet und so kann nachvollzogen werden, wer denn da gesprochen hat. Eine Aufzeichnung gibt es bei VATSIM (noch? *g*) nicht, aber zu wissen wann der andere fertig ist kann sicherlich auch nicht schaden.

So, nun zur praktischen VATSIM-Anwendung. Prinzipiell gibt es zwei Methoden mit ASRC+VSCS zu koordinieren. Einmal die Intercom-Funktion - die funktioniert quasi genau wie das reale Vorbild, und dann gibt es da noch den Override-Modus, der hauptsächlich in USA eingesetzt wird. Da ein Gespräch per Intercom sehr aufwendig ist (VSCS-Fenster aktivieren, Gespräch annehmen, PTT drücken) und der Angerufene dann auch nicht mehr auf seiner Frequenz sprechen kann, kann ich diesen Modus für den Einsatz bei VATSIM nicht empfehlen - oder zumindest nur dann, wenn gerade nichts los ist. Dazu bräuchte man dann wie in RL einen Coordinator neben sich.

Bleibt also noch der Override-Modus. Ein Approval Request wie oben beschrieben könnte dann z. B. so ablaufen:

EDMM_CTR aktiviert Override zu EDFF_CTR (entweder per ".ov FC" oder Button im VSCS-Panel) und wartet dann bis EDFF_CTR sich meldet (denn nur EDFF weiss, wann Zeit ist zum Sprechen - also nicht einfach drauf losreden!).

In der Zwischenzeit macht EDMM_CTR bereits einen Pointout des betreffenden Fliegers mit "F1 FC DLH1234 <ENTER>" oder "F1 FC <ASEL>".

EDFF: "Langen Radar"
EDMM: "München Radar, Approval request, position MIQ, DLH1234"
EDFF: "Identified, go ahead"
EDMM: "Can you accept DLH1234 from MIQ direct to PSA?"
EDFF: "Approved, MG"
EDMM: "Consider, CW"

EDMM_CTR trennt die Verbindung mit .RLS oder dem entsprechenden Button.

Falls EDFF_CTR den Override nicht bemerkt hat, kann man in einer Pause auch mal selbst rufen: "Langen Radar, München Radar" - oder auch abgekürzt "Langen - München". Und wenn der Angerufene gerade keine Zeit hat ist es auch kein Problem mal zu sagen "standby" oder "I call you back". Evtl. muss er ja auch erst selbst etwas koordinieren, wenn man z. B. ein Direct quer durch Deutschland haben möchte *g*.


So, ich habe fertig :-)

[Julius Berger]

Servus,

Dankeschön für die ausführlichen Ausführungen!

Zitat von Christoph Winkler

Falls EDFF_CTR den Override nicht bemerkt hat, kann man in einer Pause auch mal selbst rufen: "Langen Radar, München Radar" - oder auch abgekürzt "Langen - München". Und wenn der Angerufene gerade keine Zeit hat ist es auch kein Problem mal zu sagen "standby" oder "I call you back". Evtl. muss er ja auch erst selbst etwas koordinieren, wenn man z. B. ein Direct quer durch Deutschland haben möchte *g*.

Beispiel: Lufthansa will nach Abflug aus München direkt zum Hamburg VOR. Ruft München dann Frankfurt an, der wiederrum Berlin und jener dann Bremen? Oder ruft München alle Stationen selbst an?

Julius

[Andy Würde]

Guten Morgen!

Zitat von Julius Berger

Beispiel: Lufthansa will nach Abflug aus München direkt zum Hamburg VOR. Ruft München dann Frankfurt an, der wiederrum Berlin und jener dann Bremen? Oder ruft München alle Stationen selbst an?

Hier heißt das Zauberwort aus der Fachsprache LINE OF COORDINATION
Das heißt jeder ruft nur den nächsten betreffenden Sektor an. Also wenn die DLH nach von MIQ direct 10NM/RWY23 EDDH will, dann sagt EDMM das EDFF, der fragt EDBB, der wieder EDWW...
Da das ziemlich umständlich ist, gibt es auch kaum Directs über mehr als 2 units
Das Problem besteht halt darin, daß wenn ich als EDMM EDWW frage, ob das geht und er sagt mir nein, er möchte den inbound LBE haben, dann muß ich meine ganzen Absprachen mit den vorhergehenden Sektoren neu aufziehen... aufwendig so was. Wenn ich zuerst EDWW frage und dann rückwärts koordiniere, dann braucht nur ein Sektor nein zu sagen und ich habe schon wieder den Salat.... deswegen... immer nur von einem zum anderen koordinieren.
Beispiel aus der Praxis. Ich wollte einmal wissen,was machbar ist. Anhand eines AVA Fly ins in Wien bei VATSIM wollte ich dem Spätheimkehrer AUA aus EHAM im RL mal was Gutes tun. Also ich war auf dem Frankfurt Sektor (entspricht so lose den Nord 1/2/3/6 und Süd1 bei Langen), der Flieger war nordwestlich Germinghausen. Also fing ich bei Prag an: "Request direct WGM". Wurde approved. Dann den Erlangen Sektor von uns... auch approved. Dann den Fulda Sektor für Durchflug ... approved... dann den release von Maastricht. Alles in allem war das fast 15 Minuten Beschäftigung, keiner hatte einen FPL, alle brauchten eine position... Im Endeffekt sparte es der AUA 8min Flugzeit. Hätte einer zwischendrin "nein" (oder besser "negative"wegen Englisch ) gesagt... dann wäre die Vorstellung geplatzt. Nur als Beispiel, damit man sich das mal bildlich vorstellen kann.


Und @Christoph W.
Das heißt am Telefon nicht einfach nur "ja" Das heißt "go ahead", weil wir telefonieren ja in englisch
Wenn man anhand eines anonymen Anrufs (eine auf der entsprechenden Position nicht gespeicherten Nummer) mal nicht weiß, wer anruft, dann immer mit der Unit melden. Bei uns wird gelehrt: Unit und Position. Also "Rhein, Würzburg Lower Planner" z.B. .... Aber in der Praxis hapert es an der Zeit, deswegen sagt man halt einfach nur "RHEIN"... entspricht aber nicht den Vorschriften 8)

Gruß

Andy

[Christoph Winkler]

Zitat von Andy Würde

Da das ziemlich umständlich ist, gibt es auch kaum Directs über mehr als 2 units

Ausser nachts und vor allem bei Hospital Flights. War vor kurzem mal wieder der Fall bei uns: "cleared to EDDE, climb on runway heading FL200, when passing 4000ft proceed direct ROBEL" :-)

Und @Christoph W.
Das heißt am Telefon nicht einfach nur "ja" Das heißt "go ahead", weil wir telefonieren ja in englisch

Achso, stimmt ja - hätte ich fast vergessen. Immer alles in Englisch

[Andy Würde]

Nur ROBEL Direct? Mann, ist der Langener schlecht