NORMALIZE
Translate source-specific observations into a common model.
Understand
PILOT / INTEGRATEMultiple traffic sources. One reliable operational picture.
Flyvercity develops provider-agnostic traffic-data technology for Fleet Management, UTM/U-space and operational platforms that need to reconcile heterogeneous surveillance sources.
PROVIDER-AGNOSTIC DATA LAYER
The integration problem
Low-altitude operational systems increasingly consume traffic information from several technologies and providers.
The same aircraft can appear through multiple identities. Sources may update at different rates, disagree on state, become stale or disappear.
Without a dedicated fusion and quality layer, this complexity moves into the Fleet Management or UTM application itself.
The product
Flyvercity Traffic Data Fusion normalizes heterogeneous observations, associates reports belonging to the same trajectory, combines them into a common representation and exposes information about source and track quality.
Translate source-specific observations into a common model.
Determine when observations from different sources represent the same aircraft.
Combine observations into coherent tracks.
Expose stale, inconsistent or degraded information.
Reconstruct data and decisions for testing and analysis.
Architecture
Traffic inputs remain replaceable. The operational platform receives a consistent interface, fused tracks and explicit quality signals.
PROVIDER-AGNOSTIC DATA LAYER
Regulatory context
Regulation (EU) 2021/664 makes traffic information a mandatory U-space service and requires interoperable exchange with defined data quality, latency and protection.
EASA AMC and GM describe composite traffic information elaborated from several sources, uniqueness of delivery, timeliness and monitoring. Flyvercity provides a fusion layer that can support those technical workflows; it is not itself a claim of USSP certification.
Articles 5, 7 and 11 establish interoperability, data-quality and traffic-information requirements for the U-space context.
OPEN SOURCE ↗EASA / AMC + GMEasy Access Rules for U-spaceConsolidated AMC and GM explain traffic-information sources, uniqueness, timeliness, monitoring and operator responsibility.
OPEN SOURCE ↗EASA / ARTICLE 11Traffic information serviceThe service includes known manned and UAS traffic, position, report time, speed/direction and emergency status when known.
OPEN SOURCE ↗EASA / U-SPACEU-space implementation overviewOfficial overview of the services, certified actors and operating context for U-space airspace.
OPEN SOURCE ↗The relevant obligations depend on whether the consuming organisation is a UAS operator, USSP, CIS provider, ATSP, fleet platform or integrator. System responsibility remains with the regulated actor and its approved service context.
Who it is for
Integrating surveillance sources into a common traffic service.
Giving operators a coherent picture without embedding source logic in the fleet application.
Adding consistent traffic context to command-and-control environments.
Connecting multiple providers through one quality-aware data layer.
Market + compliance trajectory
The market is moving from source-by-source display integration toward traffic information that can be reconciled, qualified and tested as part of an operational system.
Operational platforms ingest individual surveillance feeds and provider APIs through source-specific integrations.
UTM, U-space and fleet platforms need a common representation across heterogeneous providers and technologies.
Systems must prevent duplicate traffic, manage disagreement and detect stale or disappearing observations.
Fleet automation increasingly depends on traffic information that is observable, testable and resilient to source change.
Define the service context, authoritative inputs and the operational responsibility attached to the resulting traffic picture.
Support interoperable exchange, traceability and the data-quality, latency and protection expectations applicable to the service context.
Demonstrate how traffic is elaborated from several sources and how uniqueness, timeliness and degraded inputs are handled.
Maintain service evidence, records, monitoring and change impact as providers, airspace requirements and interfaces evolve.
Source assessment: inventory formats, identities, timing, quality signals and consuming-system decisions.
Pilot: build the common model, adapters, provenance and repeatable replay environment.
Integration: association, fused tracks and explicit source/track quality delivered through one interface.
Operational layer: health signals, anomaly detection, replay, performance evaluation and controlled change.
PILOT / INTEGRATE
PILOT / INTEGRATEA useful pilot begins with the sources, consuming system and operational decisions that the traffic picture needs to support.
Discuss a Data Fusion pilotSources, identities, interfaces, update rates and expected operating conditions.
A common observation model and a controlled output interface.
Representative datasets for repeatable testing and tuning.
Track coherence, quality behaviour and integration fit.

REAL PROGRAMME CONTEXT
Flyvercity contributes positioning data fusion for the Helicus Command-and-Control Center in SAFIR-Ready, alongside work in European UAS research programmes.
Programme participation is evidence of applied work, not an authority endorsement.
Start with the operation
Show us the input feeds, consuming platform and operational decisions the traffic picture needs to support.
Discuss a Data Fusion pilot ↗