"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...
