Drones Swim: Wie FREQUENTIS Informationsflüsse für Drohnenverkehr beherrscht – SWIM, Service-Spezifikationen und System-of-Systems in der Praxis

Warum „Drones Swim“? Ein Blick auf reale Systeme statt Echtzeit-Hype

„Drones Swim“ klingt paradox. Thomas Lutz, Systemarchitekt bei FREQUENTIS, nutzt den Titel, um einen Punkt zu setzen: Es geht nicht um ein weiteres Buzzword zu Echtzeitsystemen, sondern um reale Systeme – die still und zuverlässig in Leitständen weltweit laufen. In seiner Session „Drones Swim“ (Speaker: Thomas Lutz, Company: FREQUENTIS) legt er offen, wie Drohnen als neues Verkehrselement ATM, Public Safety, Maritime, Defense und Public Transport zusammenbringen – und warum das eigentliche Problem nicht die Steuerung eines einzelnen UAV ist, sondern das Management der Information darüber.

Wir haben zugehört und mitgeschrieben. Ohne eine einzige Codezeile – ganz bewusst, denn Lutz betont: „Es gibt nichts radikal Neues, aber es lohnt sich zuzuhören.“ Was folgt, ist eine praxisnahe Architektur-Story aus europäischen Forschungsprojekten, in denen eine falsche Koordinate zum ernsthaften Störfall werden kann – und in denen Systemweite Informationsverwaltung (SWIM) und sauber entkoppelte Spezifikationen den Unterschied machen.

FREQUENTIS im Kurzprofil: Leitstände für bewegte Objekte

FREQUENTIS ist „überall – mit Fokus auf Leitstände“. Die Beispiele sind greifbar:

• Air Traffic Management (ATM): Tower und Area Control Centers, separieren und steuern Flugverkehr, heute IP-basiert und stark automatisiert.
• Defense: Militärische Flugverkehrssysteme mit denselben Sicherheitsanforderungen – Separation und sichere An-/Abflüge.
• Public Safety: 112/911-Calltaking, Einsatzleitsysteme, Ressourcenführung – vom Headset der Disponentin bis zur Einsatzübersicht.
• Public Transport: Kommunikation und Lagebilder für U-Bahn, Bahn und Bahnhöfe; wissen, welcher Zug, welcher Wagen wo ist.
• Maritime: Verkehrssicherung an Küstenlinien, Lagebilder in Häfen und Seegebieten.

Die Leitidee dahinter: Es ist egal, ob sich ein Flugzeug, ein Polizeifahrzeug oder ein Schiff bewegt – das System orchestriert Verkehrsfluss, Kommunikation und Lagebild. Genau hier steigen Drohnen ein – als Katalysator, der Domänen zusammenschaltet.

Die Aufgabe: Drohnen bringen die Domänen zusammen – und die Systemlast explodiert

Drohnen sind leicht zu beschaffen, günstig und vielseitig – von der Unfallaufnahme aus dem Kofferraum eines Streifenwagens bis zur Hafen-Inspektion oder der Vorerkundung auf Bahnbaustellen. Gleichzeitig laufen die klassischen Flugsysteme weiter. Vor der Pandemie wurden in Europa im Schnitt etwa 30.000 Flüge pro Tag gezählt. Für 2035 nennen Prognosen Größenordnungen von 16,8–17 Millionen Flügen über Europa. Sicher ist nur: Es wird deutlich mehr – und kein bestehendes System ist dafür gebaut.

Europa beantwortet diese Skalierungsfrage mit „U-space“: kein physischer Raum, sondern ein Set aus Diensten und Verfahren für sicheren, effizienten, sicheren Zugang zum Luftraum – speziell für große Drohnenzahlen. Die Konsequenz: Die Welt der „großen“ Luftfahrt (ATM) muss mit neuen U-space-Akteuren und bestehenden Leitständen in Public Safety und Maritime kooperieren.

Vom Papier zur IP – und jetzt Drohnen: Modernisieren ohne Neuaufbau

Die ATM-Systeme wuchsen seit den 1910er-Jahren vom Papier zur IT, dann IP-basiert. Heute kommen Drohnen hinzu. Abriss und Neuaufbau? Lutz’ nüchterne Einschätzung: Besser lernen, iterieren, integrieren – vor allem nicht alleine.

SESAR: Öffentliche-private Partnerschaft als Träger

Das EU-Programm SESAR (Single European Sky) bündelt Universitäten, Unternehmen, Startups, Navigationsdienstleister (ANSPs) und Behörden in Forschungs- und Validierungsprojekten. Rund 3.000 Menschen arbeiten in Europa an solchen Vorhaben – vom Entwickler über den Projektmanager bis zu Business-Case-Teams. Diese Mischung aus Erfindern, Bauenden, Nutzern und späteren Betreibern schafft das Umfeld, in dem tragfähige Lösungen entstehen.

Use-Case-getrieben: Das „Gulf of Finland“-Projekt (GoF)

Ein prägendes Beispiel ist das „Gulf of Finland“-Projekt. 19 Partner – ANSPs, neue U-space Service Provider (USS/USSP), Drohnenbetreiber, Airlines für Drohnen, etablierte ATM-Technologielieferanten (darunter FREQUENTIS), Beratungen und lokale Organisationen – verfolgten ein klares Ziel: „Alle sollen wissen, was gerade passiert.“ Übersetzt: ein gemeinsames Lagebild über mehrere Systeme hinweg, also „einfach Punkte“ für Flugzeuge, Drohnen und weiteres Verkehrsgeschehen – doch in der Praxis mit vielen Akteuren und heterogenen IT-Landschaften.

Reale Use Cases statt Papier

Die Projektarbeit startete nicht mit Papier, sondern mit realen Szenarien:

• Polizeieinsatz: Drohne aus dem Streifenwagen starten, Sekunden bis zum Lagebild.
• Search & Rescue auf See: Drohne findet die Person, koordiniert mit Schiff und später eintreffendem Hubschrauber – drei Vehikel, ein Raum, hohe Dynamik.
• Paketlieferung: In Europa umstritten, aber großvolumig; in den USA plausibel für die „letzte Meile“.
• Inspektionen: Energie, Häfen, Infrastruktur – lange Strecken, Sensoren, 3D-Checks aus 10 Metern Abstand statt Helikostunden.

Dazu kommen Stakeholder: ATM, UTM, Betreiber, Küstenwache, Polizei, Städte (Genehmigungen) – alle mit existierender IT. „Legacy“ nennt man das gerne; Lutz bevorzugt „bewährt“. Denn: Was funktioniert, fasst man ungern an.

Die eigentliche Herausforderung: Informationsmanagement in einem System-of-Systems

U-space-Provider sind „Software-first“, internetbasiert, in der Luftfahrt bewusst mit anderen Safety-Annahmen: kein Mensch an Bord, also andere Risikokriterien. Daneben existieren geschlossene Netze, Hardware-gebundene Systeme, alte Protokolle – kurz: andere Welten. Und alle müssen reden – Ground Control Station (GCS), Drohne (UAV), Behörden, Öffentlichkeit (z. B. „Darf die Drohne hier fliegen?“), ANSPs.

Ein Blick auf die Interaktionen reicht, um das Risiko zu sehen. Im Projekt zeichnete das Team den Informationsfluss, der einem Operator sagt: „Dreh um, Konflikt voraus.“ Daran hängt eine Kette von Diensten: Flugplanung, Geofencing, Telemetrie, taktische De-Konfliktion und mehr. Vier Wochen, 35 Leute, hitzige Abende – und am Ende eine pragmatische Einsicht: Eine einzige falsch interpretierte Koordinate (klassischer Fehler: vertauschte Breite/Länge) kann ein System aus dem Tritt bringen.

Was muss geteilt werden?

Statt in die Black Box „taktische De-Konfliktion“ hineinzusehen, fokussierte das Team auf Informationsartefakte:

• Geofences: „Wände am Himmel“, die nicht durchflogen werden dürfen.
• Telemetrie: Position, Geschwindigkeit, Status.
• Flugpläne: Absichtserklärungen („Ich fliege von hier nach dort“).

Aus rund 50 Use Cases und Dutzenden Schnittstellenverbindungen leitete das Team ein Muster ab: System-zu-System-Schnittstellen definieren – ohne die Innereien der beteiligten Services zu normieren.

SWIM: System-Wide Information Management als Leitplanke

Die Lösung lehnt sich an einen existierenden Standard: SWIM (System-Wide Information Management), in der ICAO-Welt als etwa 80-seitiges Regelwerk beschrieben. Lutz’ Ein-Satz-Definition:

Das klingt simpel, ist aber die harte Arbeit zwischen Domänen: Polizist und Flugverkehrsleiter sollen ihre Jobs tun – und trotzdem dasselbe unter „Position“ verstehen. Genau das erzwingt SWIM: gemeinsame Begriffe, klares Verhalten, robuste Datenmodelle.

Die Architektur, die funktioniert: Entkoppelte Spezifikation, dann Implementierung

Der hebelwirksame Schritt – und Kern der FREQUENTIS-Erfahrungen – ist die Entkopplung von Dokumentation und Implementierung. Das passiert in drei Schichten:

1) Service-Spezifikation (technologieagnostisch)

• Zielgruppe: alle Beteiligten, von Operator bis Entwickler.
• Inhalt: Anforderungen („Warum brauchen wir den Dienst?“), Logisches Datenmodell, Verhaltensbeschreibung.
• Form: Wiki, Word, egal – Hauptsache schriftlich, eindeutig.
• Beispielverhalten: Rollen, Login, Rechte; bei Flugplänen z. B. „Request – Approve – Alternative vorschlagen – Retry“.
• Mapping: Existierende APIs (Webservices, SOAP, Dateischnittstellen) werden auf diese Spezifikation abgebildet.

Ergebnis: Sobald zwei Teams über dieselbe schriftliche Spezifikation reden, klären sich Missverständnisse. Technologiekriege („Java vs. .NET“, „Linux vs. Microsoft“) verlieren Relevanz – man mappt gemeinsame Begriffe.

2) Technischer Entwurf (konkret, aber variabel)

• Mögliche Stile: REST, GraphQL, SOAP – alles erlaubt, solange es sauber auf die Service-Spezifikation abbildet.
• Brücken: Wenn zwei technische Designs existieren, genügt ein Übersetzer – beide hängen an derselben Spezifikation.

3) Service-Instanz (laufend, auffindbar)

• Deployen, erreichbar machen, Kontaktinformationen bereitstellen.
• Beispiel (aus der Session): „Iceberg Service“ – ein bewusst schlichtes Gedankenmodell, das drei unterschiedliche technische Spielarten illustriert:
• Voice: Kapitän ruft an, fragt nach Eisbergen, bittet um Rückruf – Request/Response plus Pub/Sub per Sprache.
• Modernes Socket-Backend (z. B. Node.js): Updates per Push zur Bordintegration.
• Menschliches Web-Lagebild (z. B. WMS): reine Visualisierung.

Gemeinsamer Nenner: dieselbe Semantik, dasselbe Datenmodell.

Das Datenmodell, das trägt: „Position“ mit Luftfahrt-Details

Lutz zeigt ein UML-Fragment für „Position“. Es ist umfangreicher als „Lat/Lon“:

• Pflichtfelder oben links: mindestens eine Position und eine (oder mehrere) Höhe(n).
• Optional: Objektklassifizierung (Vogel, Flugzeug, Drohne …), Metadaten für Verkehrsmanagement.

Das Modell ist das kondensierte Ergebnis der Debatten zwischen Public Safety, ATM, U-space-Providern und Drohnenbetreibern – „kleinster gemeinsamer Nenner“ mit Luftfahrt-spezifischen Extras. Und es hat Bestand: in kleiner Anpassung seit fünf Jahren im Einsatz. Vorteil: C‑Level liest dasselbe Diagramm wie Testerinnen und Entwickler. Implementierung wird zum „Spaziergang“, weil die Modellierungsfehler minimiert sind und Tests klar gegen die Spezifikation schreiben.

Vom Schema zur Wirkung: Ein Lagebild, vier Bildschirme – gleiche Wahrheit

Wozu der Aufwand? Lutz zeigt das Resultat: dieselbe Drohnenmission – ein Flug vom estnischen in den finnischen Luftraum – erscheint konsistent auf:

• einem ATC-Display im Tower (Separation, Luftraumstruktur),
• einem UTM-Web-Client (fokussiert auf Drohnen-Operationen),
• einer Google-Ansicht (Spiral-Start sichtbar),
• weiteren Oberflächen mit jeweils domänenspezifischer Darstellungslogik.

Er nennt das augenzwinkernd „Five-ish million projects to achieve the same display on four different screens.“ Kosten hin oder her – technisch ist die Botschaft klar: Ohne sauberes Informationsmanagement bleibt Multisystem-Konsistenz ein Lotteriespiel.

Praxislektionen aus dem Projekt: Gespräche, dann Adapter – Stunden statt Wochen

Ein wiederkehrendes Muster aus den GoF-Erfahrungen:

• Drei bis vier Wochen Diskussion und Dokumentation – mit allen Stakeholdern.
• Dann: Adapter/Bridges implementieren – oft in Stunden.
• Und: Testbarkeit steigt drastisch, weil alles auf der Spezifikation basiert.

Dazu ein Sicherheitsrealismus: Ein kaputtes Record kann Systeme blockieren. In UTM sterben nicht sofort Menschen, aber der Ausfall eines Lagebilds ist kritisch. Deshalb gelten in den sicherheitskritischen FREQUENTIS-Systemen „viele Stellen hinter dem Komma“ bei Tests – und deshalb ist Informationsdisziplin kein Luxus, sondern Notwendigkeit.

Architekturmuster zusammengefasst

• Fokus auf Informationen statt Implementierungsdetails: Was genau muss geteilt werden? In welcher Qualität? Mit welcher Semantik?
• Gemeinsames Vokabular erzwingen: Schriftliche, technologieagnostische Service-Spezifikation.
• Datenmodell zuerst: UML/ERM, das C‑Level, Tests und Entwicklung gleichermaßen verstehen.
• Technologiewahl entkoppeln: Mehrere technische Designs sind okay – solange sie sauber mappen.
• Instanzen auffindbar machen: Wo läuft der Dienst? Wie erfolgt die Subscription? Wer ist „der richtige Empfänger zur richtigen Zeit“?

Leitgedanken, die hängen bleiben

• „Need-to-know“ und „just in time“ gelten auch für Systeme: Liefere nur die notwendige Information – aber rechtzeitig.
• Technologie rotiert im 2–3‑Jahres-Takt; Konzepte bleiben: JSON, XML, CSV, SOAP, REST – alles kommt und geht. Das Positionskonzept gilt seit der Antike – mal 2D, mal 3D.
• „Proven“ schlägt „Legacy“: Funktionierende Altsysteme nicht stigmatisieren, sondern sorgfältig anbinden.
• Öffentlichkeit ist Stakeholder: Wer eine Drohne vor dem Stadion sieht, will wissen, ob sie dort sein darf – Interaktion mit der Öffentlichkeit ist Teil des Gesamtsystems.

Ein mögliches Vorgehen für Engineering-Teams

Aus der Session destillieren wir ein praxistaugliches Vorgehen, das über Luftfahrt hinaus anwendbar ist:

1) Use Cases statt Papier erfinden:

• Konkrete Flüsse beschreiben (z. B. „taktische De-Konfliktion: Drohne muss drehen“).
• Betroffene Akteure und Systeme auflisten.

2) Informationsartefakte identifizieren:

• Welche Datentypen sind kritisch (Geofences, Telemetrie, Pläne)?
• Welche Felder sind Pflicht, welche optional?

3) Service-Spezifikation schreiben (technologieagnostisch):

• Datenmodell in UML/ERM, plus Verhaltensbeschreibung.
• Rollen/Rechte, Sequenzen, Fehlerszenarien (z. B. ungültige Positionen).

4) Technische Designs ableiten:

• Einen (oder mehrere) Stile wählen (REST/GraphQL/SOAP/File), Mapping belegen.
• Wenn mehrere notwendig: Übersetzer/Adapter definieren.

5) Service-Instanzen bereitstellen:

• Endpunkte, Kontakt, Subscription/Unsubscription klären.
• Monitoring/Tracing so gestalten, dass Qualitätsverletzungen sichtbar werden.

6) Teststrategie auf die Spezifikation aufbauen:

• Positiv-/Negativpfade, Grenzwerte (z. B. Höhen), Koordinatenfallen (Lat/Lon-Verwechslung).

Was „Drones Swim“ uns lehrt

Die Session „Drones Swim“ (Speaker: Thomas Lutz, Company: FREQUENTIS) ist keine Code-Demo – und genau deshalb wertvoll. Der Kern ist die Einsicht, dass Sicherheit und Skalierung in vernetzten, domänenübergreifenden Systemen vor allem Informationsprobleme sind. Wer die Bedeutung von SWIM und sauber entkoppelter Spezifikation ernst nimmt, kann heterogene Welten verbinden – alte, bewährte Leitstände und neue, internetnative U-space-Dienste – ohne Technologiekriege und ohne Big-Bang-Rewrites.

Oder, mit Lutz’ pragmatischer Zusammenfassung:

Wenn Drohnen „schwimmen“, dann in einem Meer aus Informationen. Die Kunst besteht darin, dieses Meer zu strukturieren, damit alle – Tower, Polizei, Küstenwache, Betreiber und Öffentlichkeit – dieselbe Wahrheit sehen und sicher handeln können.

• 

  

  Safety-critical Software Solutions

  Djamel Sahnine von Frequentis zeigt in seinem devjobs.at TechTalk mit welchen Herausforderungen sich die Software Entwicklung im Unternehmen auseinandersetzt.

  Jetzt ansehen
• 

  

  CCR

  Richard Draxelmayr von Frequentis spricht in seinem devjobs.at TechTalk darüber, welche Vorteile eine gute Review-Kultur im Devteam hat.

  Jetzt ansehen

• 

  

  Günter Graf, VP New Business Development von Frequentis

  Der VP New Business Development von Frequentis Günter Graf umreißt im Interview die Inhalte des Unternehmens, was der Fokus bei New Business Development ist und erläutert auch, warum gutes Domain Knowledge den Unterschied macht.

  Jetzt ansehen
• 

  

  Karl Wannenmacher, Head of Public Safety Products von Frequentis

  Der Head of Public Safety Products von Frequentis Karl Wannenmacher erzählt im Interview über die Organisation des Devteams der Abteilung Public Safety, wie dort das Recruiting geschieht und welche technischen Challenges es gibt.

  Jetzt ansehen