https://www.globalair.com/articles/faas-mobile-clearance-lets-pilots-skip-the-radio-for-ifr-clearances/12533?fbclid=iwy2xjawtvypvlehrua2flbqixmabicmlkete0ofbsdvz4zkriu1hkwfhlc3j0ywzhchbfawqqmjiymdm5mtc4odiwmdg5mgabhgte4ipxc0nwcf-ok4kxodw9ai3pw9mbp1nhbq80skt4omviu1qg2ryonyct_aem_mjskwrbblkvaqw2nz2netw&utm_campaign=faa-mobile-clearance-ifr&utm_medium=social&utm_source=facebook

Ob das Luftfahrtbehinderungsamt Schnappatmung bekäme?

Die easa denkt bestimmt schon dran...die infrastruktur ist ja schon da

Ja leider sind die meisten "schönen und praktischen" Garmin Funktionen leider nur in USA möglich.

Ich denke da ins besondere an SMART CHARTS und auch diese IFR Freigabe.

Ich sehe den Hauptvorteil eher bei der ATC (Arbeitsbelastung). Für Pilotierende gehen diese 20 Sekunden aufm Vorfeld unter, finde ich.

... zumal im Eurocontrol-Airspace die SID und (selten noch) der Transponder-Code die einzigen Variablen sind.

Mein wurstblinker ist auch vari-abel...

"Für Pilotierende gehen diese 20 Sekunden aufm Vorfeld unter"

Ich fände eine solche Lösung bei VFR-IFR-Wechselverfahren sinnvoll, so dass die 20 Sekunden dann wirklich auf dem Vorfeld und nicht in der Luft passieren, sprich ein reibungsloser Pickup damit ermöglicht wird und so Dinge wie Pickup Frequenz, First Cleared Altitude und Squawk am Boden geklärt werden können.

Es gab dazu wohl auch schon mal einen Versuch in D, allerdings habe ich jetzt länger nichts mehr davon gehört.

Letztes Jahr hatte ich mir dazu auch mal ein paar eigene Gedanken gemacht, wie eine generelle Kommunikationsarchitektur in dem Bereich aussehen könnte (PGP-Signierung mit Schlüsselübermittlung per Flugplan). Damit könnte eine Datenübermittlung zwischen Piloten und ATC unabhängig von Übertragungsweg und Hardware in gesicherter Form stattfinden. Ich hatte dazu ein Whitepaper bei der DFS eingereicht. Das ist allerdings in deren "Innovationsmanagement" versandet...

Vielleicht weis der FISprofi was...

Bei VFR departure/ IFR pick-up sieht die Sache aber ein bisschen anders aus!

Aber nur ein klitzekleines Bisschen. Am Boden sucht man sich aus der alten AIP-Karte die Frequenz vom Radar, dann startet man und verlässt die Platzrunde, räumt den Flieger auf, setzt den AP auf einen Vektor in den Raum, der weder Luftraum noch Gelände streift und klingelt mal rein. Dann kommt ers mal gemütlich der Squawk, dann ist man identified, dann muss man sich nur noch den ersten Fix (irgendwo aufm FPL) merken, die Höhe und das "IFR starts...". Viel einfacher als am Boden, da brauch ich nicht mal was zu schreiben, weils auf zwei Mal kommt. Ein Approach Briefing oder ne ATIS abhören lenkt einen IMHO viel mehr vom Fliegen ab, als schnell die IFR-Freigabe zurückzulesen.

Wobei es für die erste Hälfte eine einfache Telefonnummer am Boden auch tun würde. Da braucht man keine neuen Kommunikationswege, zertifizierte Apps, ...

Bei der zweiten Hälfte habe ich glaube ich noch nicht verstanden, welches Problem damit gelöst wird. Haben wir tatsächlich ein Thema mit gefälschten IFR-Clearances, weswegen man signierte Freigaben/Plänen braucht?
Man muss bei so was ja auch immer die Nachteile im Kopf behalten: Mir ist keine public key / hierarchical trust architectur bekannt, die nicht schon mal mehrere Stunden wenn nicht Tage down war, weil irgend ein Fehler bei der Erneuerung der Master-Keys/Root-Zertifikate passiert ist (einschliesslich größerer Teile des DNS, ...).
Ok - das wär dann natürlich gerade wieder für die Kleinfliegerei ein Sicherheitsplus: Mit abgelaufenen Charts/Karten in der Avionik kann man dann auch rein praktisch nicht mehr Fliegen, weil damit auch die Zertifikate für die Freigaben abgelaufen sind und man schlicht schon technisch keine mehr bekommen kann. Ich bin mir nur nicht sicher, ob alle Piloten diesen Sicherheitsgewinn so toll finden?!?

Das es Smart Charts in Europa nicht gibt hat aber nix mit der Regulatorik zu tun, sondern schlicht damit, dass Garmin den Europäischen Markt nicht für so wichtig/ertragreich hält, dass sie das hier mit Priorität anbieten.

Zudem bin ich mir gerade dabei gar nicht sicher, ob der Vorteil so groß ist. Ich zahle (wie einige andere auch) im Moment vergleichsweise sehr viel Geld dafür, um das exakte Gegenteil von Smartcharts zu haben: Der wesentliche Nutzen von Jeppesen-Charts im vergleich zu denen aus den nationalen AIP, ist, dass sie absolut standardisiert sind. Für jeden Approach hat man die gleichen Informationen und das immer an der gleichen Stelle. Kein Suchen, keine Verwirrung.
Fairerweise hab ich nur so etwa 2 Stunden mit Smart-Charts am Simulator "rumgespielt" um das mal auszuprobieren. Ich war aber nach diesen 2 Stunden weit weg davon, dass ich gesagt hätte, ich würde gerne einen kritischen Approach damit fliegen. Viel zu oft ist noich der "und wo finde ich das jetzt" Effekt aufgetreten.
Sicher kann man das lernen - aber ich für mich habe festgestellt, dass ich dafür sehr viel mehr als 2 Stunden echtes Training bräuchte. Deswegen wäre ich zumindest kein Kunde dafür, wenn das in Europa rauskommt (und habe es auch nicht genutzt, als ich letztes Jahr in USA war).

Ich habe das Whitepaper mal angehängt. Mir ging es darum, bei der Datenkommunikation etwas unabhängiger von proprietärer und zertifizierter Hardware zu werden. Bisher basiert CPDLC hauptsächlich auf einer Authentifzierung per Hardware und einem festgelegten Übermittlungsweg. Alle anderen Wege wurden meist von Seiten ATC mit dem Totschlagargument der Angreifbarkeit der Kommunikation und der nicht erfolgten Zertifizierung belegt. Das nutzt hauptsächlich Hardware-Herstellern, die dann für entsprechende Kleinserien astronomische Preise aufrufen, was die Verbreitung in der GA meist auch gering hält.

Hier war mein Gedanke, eine standardisierte und softwarebasierte Kommunikationsmöglichkeit zu schaffen, die dementsprechend unabhägig von (teurer) Hardware und festgelegten (teuren) Übertragungswegen ist.

Mit Sicherheit ist das nicht der Stein der Weisen, der in jedem Anwendungsfall anderen Techniken überlegen ist. Allerdings hätte ich es interessant gefunden, das mal mit der DFS zu diskutieren, ggfls. zu optimieren oder bei Nichtgefallen wieder in der Tonne verschwinden zu lassen... Aber es wurde bisher noch nicht mal diskutiert.

Zur PDC per App bei VFR/IFR-Wechseln: Klar ist die telefonische Lösung sehr einfach umsetzbar. Dies wird bisher von der DFS nur für die Bundespolizei vorgehalten und für alle anderen auf Grund von Personalmangel abgelehnt. Hier war die Überlegung, dies per App zu optimieren, so dass im Idealfall ein Lotse nur noch auf eine Art "Release-Button" drückt und die Clearance automatisch versandt wird.

Ein weiterer Gedanke war, die Systematik auf weitere Bereiche anzupassen. So könnte z. B. ein tief fliegender VFR-Pilot in einem Tal ohne Radar- und Funk-Abdeckung einen standardisierten Hilferuf über solch ein System per GSM oder Starlink versenden, der direkt beim zuständigen FIS-Lotsen aufschlägt. Ein Frequenz-An- und Abmeldung bei FIS könnte darüber erfolgen.

Da die Übertragungswege nicht festgelegt sind, könnte auch eine Art "Netzwerkrelay" erfolgen: Ein Datenburst, der auf einer frei zugänglichen Frequenz ausgesandt wird, kann von anderen Flugzeugen weitergeleitet werden. Das könnte für den Drohnenbetrieb evtl. hilfreich sein bei kleinen Sendeleistungen.

Ich bin allerdings weder Programmierer noch Lotse. Insofern lasse ich mich da von Praktikern gerne belehren.

Ich kann leider immer noch nicht erkennen, welches Problem hier gelöst wird, ausser der Vermeidung von Angriffen durch gefälschte Nachrichten. War mir aber wie gesagt nicht bekannt, dass dies beim heutigen System ein Problem ist.

Insbesondere kann ich nicht erkennen, wie das die Beschränkung auf bestimmte Übermittlungswege verbessert.
ATN B1 ist heute schon im Prinzip unabhängig von der Übertragungsschicht definiert. Dass im EASA-Raum praktisch nur VDL Mode 2 unterstütz wird, ist eine Entscheidung der EASA und keine technische Einschränkung.
Auch ATN/IPS ist ja schon stadardisiert - es fehlt "nur noch" an der Zulassungsvorschriften.

Schliesslich die Frage der "Software- vs. Hardware-Implementierung".
Grundsätzlich gibt es in den CS-ACNS und erst Recht in den dahinter liegenden Standards wenig, was gegen eine SW-Implementierung sprechen würde. Allerdinbgs gibt es einige aus meiner Sicht sehr sinvolle Anforderungen, die zumindest in der zertifizierten Luftfahrt nur mit zertifizierter Hardware lösbar sind.
Zum Beispiel: Was ist denn Deine Position zu der Anforderung aus den AMC zu ACNS.B.DLS

"When CPDLC messages are displayed:

(a) such location should be in the Primary Field of View.

...

(c) messages from the ATS should remain displayed until responded, cleared or the flight crew selects another message.

(d) means should be provided for the flight crew to clear uplinked messages from the display. However, this capability should be protected against inadvertent deletion."

Ist das nicht prizipiell im Sinne der Flugsicherheit sinnvoll? Wenn ja, wie stellt man das mit einer reinen SW-Lösung sicher?
Wie kann eine reine SW-Lösung dafür sorgen, dass das IPad nicht nur an ist, wenn ATC was vom Piloten will, sondern der Pilot auch sicher darauf aufmerksam wird.

Und ich glaube, hier das Kernthema zu erkennen: DLS/CPDLC ist darauf ausgelegt, eine echte Zweiwege-Kommunikation zwischen ATC und der Flightcrew zu sein und damit eine vollwertige Alternative für Sprechfunk. Das setzt voraus, dass nicht nur der Pilot jederzeit ATC kontaktieren kann, sondern auch ATC jederzeit den Piloten.
Dein Vorschlag scheint sehr stark auf das Thema "Der Pilot will was von ATC" fokussiert zu sein...

"Ich kann leider immer noch nicht erkennen, welches Problem hier gelöst wird, ausser der Vermeidung von Angriffen durch gefälschte Nachrichten. War mir aber wie gesagt nicht bekannt, dass dies beim heutigen System ein Problem ist."

Bei den bisherigen Systemen besteht das Probem tatsächlich (noch) nicht. Das liegt m. E. an den bisherigen hohen Hürden der erforderlichen spezialisierten Hardware. Etwas anders sieht es z. B. im Bereich FANS aus. Dort werden die Nachrichten im Klartext übermittelt und könnten gezielt angegriffen werden, was m. E. nur noch eine Frage der Zeit ist. Von Seiten der DFS wurde bei Vorschlägen zu günstigeren Methoden immer diese Angreifbarkeit ins Feld geführt. Das wäre m. E. aber mit der vorgeschlagenen Systematik jedoch nicht der Fall.

Das grundsätzliche Ziel meiner Systematik ist, einen Standard zu schaffen, der eine sichere, günstige und authentifizierte Kommunikation zwischen ATC und Flugzeug ermöglicht. Diese sollte frei von Hardware-Beschränkungen sein, so dass einfache "off-the-shelf" Technik verwendet werden kann. Diese muss dann auch nicht mehr fest im Flugzeug verbaut sein. Damit entfällt die Zertifizierung zusammen mit dem Flugzeug. Das bereitet momentan nämlich Probleme: Die Lebensdauer von Flugzeugen übersteigt meistens die Lebensdauer anderer technischer Systeme. Ich kenne einen Operator, der gerade für viel Geld weltweit 3,5-Zoll-Disketten kauft, um seine FMS weiter mit Daten zu versorgen...

Wenn ein sinnvoller Kommunikationsstandard etabliert ist, entwickelt sich daraus evtl. auch ein entsprechendes "Öko-System". So könnten auch z. B, Maintenance-Daten in Echtzeit übermitttelt werden, Voranmeldungen für Handling, Zoll, Einreise etc. während des Fluges verschickt werden, ohne dass eine Authentifizierung für jeden Anwendungszweck erneut erforderlich ist.

Leider scheint der Trend jedoch gerade in die andere Hardware-basierte Richtung zu gehen: https://www.ldacs.com/

"Insbesondere kann ich nicht erkennen, wie das die Beschränkung auf bestimmte Übermittlungswege verbessert.
ATN B1 ist heute schon im Prinzip unabhängig von der Übertragungsschicht definiert. Dass im EASA-Raum praktisch nur VDL Mode 2 unterstütz wird, ist eine Entscheidung der EASA und keine technische Einschränkung.
Auch ATN/IPS ist ja schon stadardisiert - es fehlt "nur noch" an der Zulassungsvorschriften."

Mein klassisches Beispiel ist hier die Pre-Departure-Clearance. Diese kann ich elektronisch momentan nur per ACARS mit entsprechend zertifizierten Geräten abrufen. Die Kosten der Hardware übersteigen dabei den Zeitwert von so manchem GA-Flugzeug und die laufenden Kosten eines ACARS-Abos manches Avgas-Budget...

Hier wäre in meiner Systematik die Nutzung im Prinzip mit einem iPad möglich. Auch wäre es egal, ob die Übermittlung per ACARS, GSM, Starlink, GoGo oder Winktelegraphen erfolgt.

"Schliesslich die Frage der "Software- vs. Hardware-Implementierung".
Grundsätzlich gibt es in den CS-ACNS und erst Recht in den dahinter liegenden Standards wenig, was gegen eine SW-Implementierung sprechen würde."

Wenn diese Möglichkeiten auch genutzt werden, wunderbar! Allerdings scheint mir dies momentan kaum der Fall zu sein.

"Allerdinbgs gibt es einige aus meiner Sicht sehr sinvolle Anforderungen, die zumindest in der zertifizierten Luftfahrt nur mit zertifizierter Hardware lösbar sind.

Zum Beispiel: Was ist denn Deine Position zu der Anforderung aus den AMC zu ACNS.B.DLS

"When CPDLC messages are displayed:

(a) such location should be in the Primary Field of View.

...

(c) messages from the ATS should remain displayed until responded, cleared or the flight crew selects another message.

(d) means should be provided for the flight crew to clear uplinked messages from the display. However, this capability should be protected against inadvertent deletion."

Ist das nicht prizipiell im Sinne der Flugsicherheit sinnvoll? Wenn ja, wie stellt man das mit einer reinen SW-Lösung sicher?
Wie kann eine reine SW-Lösung dafür sorgen, dass das IPad nicht nur an ist, wenn ATC was vom Piloten will, sondern der Pilot auch sicher darauf aufmerksam wird.

Und ich glaube, hier das Kernthema zu erkennen: DLS/CPDLC ist darauf ausgelegt, eine echte Zweiwege-Kommunikation zwischen ATC und der Flightcrew zu sein und damit eine vollwertige Alternative für Sprechfunk. Das setzt voraus, dass nicht nur der Pilot jederzeit ATC kontaktieren kann, sondern auch ATC jederzeit den Piloten.
Dein Vorschlag scheint sehr stark auf das Thema "Der Pilot will was von ATC" fokussiert zu sein...

Diese Anforderungen halte ich grundsätzlich für sinnvoll für genau den Einsatzzweck "Zwei-Wege-Echtzeit-Kommunikation". Das ist allerdings m. E. der allerletzte Einführungsschritt. Ich halte eine Einführung z. B. über die PDC für sinnvoll. Hier kann ich ein solches System gut ohne das Risiko von verbogenem Blech ausprobieren. Wenn eine Nachricht nicht ankommt oder nicht bestätigt wird, wird eine von zwei Seiten aufmerksam. Ein zeitliches Risiko besteht nicht.

Wenn das ganze dann irgendwann Richtung CPDLC gehen sollte, so wäre z. B. auch eine Art AMoC möglich: Die Nachrichten könnten über eine AppleWatch o. ein ähnliches Device per Vibration signalisiert werden. Das erzeugt ebenfalls angemessene Aufmerksamkeit. Auch eine Verbindung zum Headset für ein Signalton für eine hereinkommende Nachricht wäre möglich. Insgesamt halte ich das für ein lösbares Problem, aber eher als einen Schritt für einen weit späteren Zeitpunkt.

Und nochmal: Glaube ich, damit den Stein der Weisen gefunden zu haben? Definitiv nein! Was ich aber sicher weiß: Wenn wir uns als Community keine Gedanken darum machen, was wir in Zukunft für Systeme haben wollen, dann werden es andere, mit evtl. ganz anderen Interessen, tun. Das wird dann für die GA nicht unbedingt günstiger oder besser...

Just my two cents...

Danke für die ausführliche Antwort. Ich bin weiterhin der anderen Meinung, dass das kein Problem der bestehenden Standards ist, sondern "nur" ihrer Anwendung. Deswegen finde ich einen weiteren Standard genau der falsche Weg.
Und wenn es nur um die PDC geht, dann ist Handy (vielleicht ganz modernistisch mit SMS/Whatapp ;-)) aus meiner Sicht die beste und bei vorhandenem Willen der DFS heute schon mögliche Lösung.

Aber man muss ja nicht immer einer Meinung sein!

Mit der SMS-Lösung für die PDC rennst Du bei mir offene Türen ein! Je günstiger, einfacher und etablierter eine Lösung ist, umso lieber ist mir das. Ich glaube nur nicht, damit bei einem ATC-Provider durch die Tür zu kommen. Wenn soetwas auf ATC-Seite akzeptiert würde, wäre ich mehr als zufrieden! Mein Gedanke war ein Standard, auf dem dann weitere Anwendungen aufsetzen können, aber vielleicht läuft das dann auch hierauf hinaus: https://xkcd.com/927/ ...;-))

Ich würde das Problem mit Authentifizierung komplett weglassen. Seriously. Jeder kann beliebige Flugpläne aufgeben, ein ILS Sender ist extrem einfach zu bauen, gleiches gilt für ADS-B-Störsender, GPS Jamming, Drohnen, die vorprogrammierte Routen abfliegen, etc. Bis hin simply zu fake-Funksprüchen. Wenn man damit anfängt, muß man feststellen, dass die ganze Aviation extrem unsicher ist, aus rein technischer Sicht. Bis auf GPS Jamming ist das in der Praxis aber offenbar kein großes Problem (wahrscheinlich auch, weil man dafür in den Knast geht, wenn einen der Peilsender findet). Ist zwar ehrenwert, dem Problem nicht noch ein weiteres Problem danebenstellen zu wollen, aber über Verschlüsselung nachzudenken hier ist aus meiner Sicht der falsche Weg. PGP ist hier völlig am falschen Platz, insbesondere da GPG/PGP auch ganz andere Schwachstellen hat, die aber alle nicht technischer Natur sind.

Genau wie man mit einer einfachen Web-Registrierung digital Flugpläne aufgeben kann, muß es einfach nur ein simples API geben, über das man nach Registrierung einfach die Daten kriegt und bestätigen kann. Technisch gesehen ziemlich einfach überall zu integrieren. Ob man daraus dann ein Iridium/Starlink/5G/SMS/Telegram/ForeFlight/iOS-App/Autorouter/…-Gateway baut, ist weitestgehend trivial.

KISS. Keep it simple, Stupid.

Herzlichen Dank für den Input! Ich würde das ganze auch lieber simpler halten, habe nur die Befürchtung, damit keinen Fuß in die Tür bei den ATC-Providern zu bekommen. Mein Gedanke war, über die Authentifizierung und Verschlüsselung dort den Wind aus den Segeln zu nehmen. Wenn die einfachere Variante auch akzeptiert wird, freue ich mich sehr!

Ich frage mich, was in diesem Bereich ein gangbarer Weg wird, um vernünftige Lösungen einzuführen? M. E. müsste dies beiden Seiten Vorteile bringen (Vereinfachung von Verfahren auf beiden Seiten). Dann könnte auch das Interesse an einer Einführung steigen. Momentan dringe ich aber bei der DFS überhaupt nicht vor. Ich erhalte noch nichtmal eine Ablehnung...

Ja, das wäre mal was - Vorbild (Kassen)medizin:

du brauchst:

- eine Kocobox (so eine Art Fritzbox für Reiche)

- eine Zertifikatkarte für jeden Kartenleser

- eine Karte für die Praxis

- und für jeden Arzt einen elektonischen Arztausweis

und dann noch jede Menge Software-Zwischenlayer die wohl immer noch eine Verschlüsselung obendrauf zimmern.

Im Ernst:

Wir funken mit AM-geräten, haben keine Ahnung wer am jeweiligen Ende sitzt; ich kann nicht beurteilen ob mir gerade ein kleiner Russen-Troll eine tödliche Anweisung erteilt, jeder kann die Gespräche mithören oder sich einklinken

Erstaunlich, dass das bisher noch nicht ausgenutzt wurde.

Analog zur KAssenmedizin bräuchte dann jedes Flugzeug eine SIM-Karte, jeder Pliot eine elektrnische Lizenz; dazu sündhaft teure Elektronik, ebenfalls mit Zerifikaten ausgestattet. Die müssen alle 5 Jahre durch kompletten Hardwaretausch erneuert werden.

Auf dass allle zu Fuß gehen mögen!

Und wenn irgendwas fehlt oder abgelaufen ist, springt die Karre gar nicht erst an. Wie bei der F-35 :-)

Moinsen,

also AM funken von uns hier wohl die allerwenigsten, und nur ganz ganz selten. Und wenn du da Überlagerungen von Russen bekämst, wäre das bei den Interferenzen in Windeseile offenkundig, so dass man sich auf den Ausweichfrequenzen zum nächsten Flugplatz /-hafen begibt, weil gerade der dritte Weltkrieg startet. So starke Sender bauen die bei uns (oder AM über den Horizont) nicht auf, ohne das auffällt.

Ist der Sprechfunk nicht AM?

Na dann

der komplette Flugfunk weltweit ist AM (A3E)

https://de.wikipedia.org/wiki/Amplitudenmodulation

AM noch z. B. für Kommunikation beim Flugsprechfunk, bei maritimen und Flug-Funknavigationsanlagen (z. B. NDB, VOR, ILS), sowie Rundfunk und in manchen Ländern noch beim analogem Fernsehen.

;-)

https://www.reddit.com/r/amateurradio/comments/18lzb6s/why_do_aeroplanes_use_am_instead_of_ssb/?tl=de

mea maxima culpa an alle, das habe ich mir komplett falsch gemerkt, als ich mich in HF eingearbeitet habe.