FREQUENTIS

Established Company

Show all Videos

Drones Swim

Thomas Lutz von Frequentis zeigt in seinem devjobs.at TechTalk welche Rahmenbedingungen geschaffen werden, um in Zukunft mit einer hohen Zahl an Drohnen umgehen zu können.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "Drones Swim", Thomas Lutz of FREQUENTIS explains how drones force legacy control‑center domains (ATM, public safety, maritime, public transport) to interoperate at scale, showcased via EU U‑space/CESAR work like the Gulf of Finland project. He frames the core challenge as information management and advocates ICAO SWIM with technology‑agnostic service specifications (data model, interfaces, behavior) to exchange geofences, telemetry, and flight plans reliably so all stakeholders share the same situational picture. Viewers learn a practical system‑of‑systems method—decoupled documentation, common data models (e.g., position), and lightweight adapters—to add new services without rewriting existing systems.

Drones Swim: How FREQUENTIS tames information for U‑space — SWIM, service specifications, and system-of-systems in the wild

Real-life systems, not hype: why “Drones Swim” matters

“Drones Swim” sounds odd by design. In his talk “Drones Swim” (Speaker: Thomas Lutz, Company: FREQUENTIS), system architect Thomas Lutz argues that the real story isn’t about real-time in the abstract, but about real-life systems that quietly keep towers, emergency rooms, rail control, and maritime operations running. Drones force these worlds to connect. When they do, the hard part isn’t piloting a UAV — it’s getting information to the right people, in the right quality, at the right time.

This is a story without a single line of code, on purpose. What we heard is an architecture and operations narrative pulled straight from European U-space research: how a single malformed record can stall a mission; how common language beats technology wars; and how System-Wide Information Management (SWIM) and decoupled specifications help multiple domains see the same truth.

FREQUENTIS context: control centers for moving things

FREQUENTIS lives “everywhere — with a focus on control centers.” The domains vary, the pattern doesn’t:

Air Traffic Management (ATM): towers and area control that separate and manage flights, increasingly IP-driven.
Defense: same safety goals under military constraints.
Public Safety: 112/911 call-taking, dispatch, resource coordination.
Public Transport: communications and situational awareness for metros and rail; knowing which train or even which wagon is where.
Maritime: shoreline and port management at scale.

The unifying idea: whether it’s an aircraft, a police car, or a ship, it’s a moving object that must be managed and communicated about. Drones slot into this pattern — and connect domains that rarely had to talk before.

The task: drones bring domains together while traffic grows

Drones are cheap, portable, and effective — a police drone launched from a trunk can deliver a crash scene overview in seconds; a port operator can inspect a hull without sending a boat; a rail work train can scout five kilometers ahead. Meanwhile, legacy air traffic doesn’t vanish. Before the pandemic, Europe saw around 30,000 flights per day. Forecasts for 2035 mention on the order of 16.8–17 million flights across Europe. The precise number is unknowable — the trend is not: significantly more. And no current system was designed for that.

Europe’s answer is “U-space”: not a physical airspace, but a set of services and procedures to enable safe, efficient, secure access to airspace for a large number of drones. That drags ATM into the mix with public safety and maritime control rooms — all must cope with the load and still do their day jobs.

From paper to IP — now add drones: iterate, don’t rebuild

ATM systems evolved since the 1910s from paper to IT to IP-based architectures. Drones are simply the next pressure wave. Do you rip and replace? Lutz advocates an integrate-and-learn approach — and, crucially, doing it together.

SESAR: the public‑private backbone

Within the EU, SESAR (Single European Sky) unites academia, startups, established vendors, ANSPs, and authorities in research projects. About 3,000 people across roles contribute — developers, PMs, and business case teams. The point: bring inventors, builders, users, and later operators to one table so that solutions survive reality.

Use-case first: the Gulf of Finland U‑space trials

A centerpiece in the talk is the Gulf of Finland project (GoF). Nineteen partners — ANSPs, new U‑space service providers, drone operators, drone “airlines,” established ATM tech vendors like FREQUENTIS, consultancies, and local entities — were given a deceptively simple goal: “Make everyone aware of what’s going on.” In practice: deliver a common traffic picture across multiple systems so that “simple dots” for aircraft and drones mean the same thing to different roles.

Real scenarios, not paperwork

The project started from use cases:

Police intervention: launch a drone from the patrol car and fly — usually in a hurry.
Maritime search and rescue: drone acquires the person, then a helicopter and a ship must be coordinated with the drone — three vehicles, one dynamic volume.
Parcel delivery: huge numbers in forecasts; perhaps more viable in the US than in Europe’s old cities.
Inspections: power lines, harbors, infrastructure — long ranges, high-quality sensors, fewer people nearby, and much cheaper than helicopter hours.

Stakeholders include ATM, UTM, operators, coast guards, police, cities (approvals). And they all have existing IT. Some call it legacy; Lutz calls it “proven.” If it works, don’t randomly touch it — but you do have to integrate it.

The hard part: information management in a system of systems

U‑space providers are software‑first, internet‑native, and explicitly working under different aviation safety assumptions (no people onboard). On the other side sit closed networks, hardware‑dependent systems, and older protocols. All of them must talk — ground control stations (GCS), the UAV itself, authorities, and even the general public (“Is this drone allowed here?” is a real concern around stadiums and airports).

The team mapped the interactions for a single flow: telling a drone operator to turn around due to a potential conflict. That animation spanned many services — flight planning, weather, geofencing, telemetry, tactical deconfliction, and more. After four weeks of work with 35 people, a blunt conclusion emerged: if one record is misunderstood or wrong, things can go bad. A classic: swapping latitude and longitude can teleport an Austrian position into Saudi Arabia — with knock‑on effects.

What must be shared?

Rather than dictating internals of, say, tactical deconfliction, the team identified the information that must cross boundaries:

Geofences — “walls in the sky” that must not be crossed.
Telemetry — position, speed, status.
Flight plans — a declaration of intent (“I intend to fly from here to here”).

From roughly 50 use cases and dozens of connectors, a pattern emerged: define system‑to‑system interfaces around information, not around monolith internals.

SWIM: a standard that enforces common understanding

The team borrowed from a known aviation standard: SWIM (System‑Wide Information Management), described in about 80 pages by ICAO. Lutz’s one‑sentence summary:

“Managing information means assuring commonly understood information is provided in high quality to the right people at the right time.”

That “commonly understood” clause is the hard part. A police officer and an ATC controller must not cross‑train into each other’s jobs — but they must agree on what “position” means and how to act on it. SWIM forces shared semantics, quality, and timeliness.

The approach that worked: decouple documentation from implementation

FREQUENTIS’ playbook is pragmatic: talk, then write, then map, then implement. The key is a three‑layer model that separates concerns and defuses technology wars.

1) Service specification (technology‑agnostic)

Audience: everyone — operators, engineers, managers.
Content: requirements (why the service exists), logical data model, behavior.
Form: any written medium (wiki, doc) — as long as it’s unambiguous.
Behavior examples: roles, login, authorization; for flight planning, flows like “request → approve → propose alternative → retry.”
Mapping: existing APIs (web services, SOAP, file drops, etc.) are mapped to this spec.

Outcome: once two teams anchor on the same written spec, misunderstandings fade. “My stack is cooler than yours” stops mattering — both map to the same least common denominator.

2) Technical design (specific, yet swappable)

Choose an interface style: REST, GraphQL, SOAP — anything that cleanly maps to the spec.
Bridging: when two designs coexist, a translator/adapter is enough as long as both trace back to the same service spec.

3) Service instance (running and discoverable)

Deploy the service, publish how to reach it, and specify subscription mechanics.
Lutz’s illustrative thought experiment: the “Iceberg Service.” Define an iceberg with size, risk, position, and drift. Then implement it three ways with identical semantics:
Voice comms: a ship captain calls, asks “Is there danger?”, leaves a call sign, and gets called back — request/response plus publish/subscribe via voice.
Modern sockets (e.g., Node.js): push updates for on‑board integrations.
Human‑readable map layer: a visual web map service.

Same model, three technical expressions — and all are valid.

The data model that lasts: “Position” beyond lat/lon

Lutz shows a UML view for a “Position” record. It’s more than lat/long:

Mandatory core (upper left): at least one position and one or more altitudes.
Optional enrichments: classification (is it a bird, a plane, a drone?), aviation‑specific metadata useful for traffic management.

This model is the distilled outcome of long discussions among public safety, ATM, U‑space providers, and operators — the least common denominator with the right aviation extras. It has been used, with only minor changes, for about five years. The benefit is alignment: C‑level, testers, and developers read the same diagram. With tooling generating UML artifacts, modeling errors drop, and implementation becomes straightforward. Testing aligns to the spec, not to guesswork.

Proof in practice: one mission, four screens, one truth

Why all this? Because shared semantics show up at the edges. Lutz shares a mission from Estonia to Finland: the same drone flight shows up as a spiraling climb in a Google view; as a corridor overlay in a tower ATC screen; and as a domain‑tuned web view for UTM operators — all with the same underlying truth. As he quips: “Five‑ish million projects to achieve the same display on four different screens.” The exact figure aside, the technical message is clear: without disciplined information management, cross‑system consistency is luck.

Lessons learned: weeks of talking, hours of adapters, and better tests

The GoF experience yielded a pragmatic cadence:

Three to four weeks of conversations and documentation across stakeholders.
Then adapter/bridge implementation — often a matter of hours once the spec is solid.
Testing becomes easy because it’s anchored in a common spec.

There’s also safety realism. A single bad record can halt operations. In UTM, people don’t die immediately — but losing the traffic picture is a severe, critical situation. In the more safety‑critical FREQUENTIS domains, testing is extremely rigorous — because it genuinely matters how we code and how systems behave. That’s why concepts like SWIM and spec‑first design are not academic; they are necessary.

Architecture takeaways

Focus on information artifacts, not black‑box internals: What must be shared? With what semantics and quality?
Force common language: a written, technology‑agnostic service spec.
Model first: a logical data model (UML/ERM) that executives, testers, and developers can all read.
Decouple tech choices: multiple interface styles are fine if they map cleanly.
Make instances discoverable: where is the service, how to subscribe, and who needs which information when.

Memorable lines that stick

“Need‑to‑know” and “just in time” apply to systems: deliver only what’s necessary — on time.
Technology cycles every 2–3 years; concepts endure: XML, CSV, SOAP, REST, JSON — the medium changes. The concept of a moving object’s position survives centuries, from wagons to ships to aircraft to drones.
“Proven” beats “legacy”: don’t stigmatize functioning systems; integrate them well.
The public is a stakeholder: people want to know if a drone near a stadium is authorized — public interaction is part of the system.

A practical playbook for engineering teams

Distilled from the session, here’s a method you can apply beyond aviation:

1) Start from concrete flows:

Describe end‑to‑end sequences (e.g., “tactical deconfliction: tell the operator to turn back”).
List actors and systems.

2) Identify information artifacts:

Which data must cross boundaries (geofences, telemetry, plans)?
Which fields are mandatory vs. optional?

3) Write the service spec (technology‑agnostic):

Logical data model plus behavior.
Roles/permissions, sequences, and failure modes (e.g., invalid positions).

4) Derive technical designs:

Choose one or more styles (REST/GraphQL/SOAP/File) and document mappings.
If multiple coexist, define translators/adapters.

5) Stand up service instances:

Endpoints, contact, subscription mechanics.
Monitoring/tracing to surface quality issues.

6) Test against the spec:

Positive/negative paths, boundary conditions (e.g., altitudes), and classic pitfalls (lat/lon swaps).

What “Drones Swim” teaches us

The talk “Drones Swim” (Speaker: Thomas Lutz, Company: FREQUENTIS) is refreshingly frank: there’s no radical novelty, and no code on the slides — yet the lessons are foundational. In a multi‑domain, safety‑influenced environment, scale and safety are primarily information problems. If you treat SWIM seriously, write technology‑agnostic service specs, and commit to a shared data model, you can connect proven control rooms with internet‑native U‑space services without tech wars or big‑bang rewrites.

As Lutz sums it up:

Managing information — especially the flow — is super important. Equally important: everybody must understand. And decoupled documentation lets you keep parts at different speeds.

Drones “swim” in a sea of information. The craft is to structure that sea so that tower controllers, police, coast guards, operators, and the public all see the same truth — and act safely.

More Tech Talks

More Tech Lead Stories