NextGen · ATM Console
Performance & GANP

Virtual Centre and ADSP

GovernsEASA Reg (EU) 2017/373EditionSESAR ATM Master Plan 2020StatusactiveRegionsEUR · GlobalReviewed2026-06-02

Virtual Centre and ADSP — decoupling ATM data processing from the physical ATC centre to enable cross-border ATS, contingency resilience, and capacity-on-demand

Virtual Centre and ADSP

Definition

The Virtual Centre concept decouples ATM data processing from the physical location of the Air Traffic Control centre. An Air Traffic Service Unit (ATSU) receives processed flight data, surveillance data, and supporting tools from an ATM Data Service Provider (ADSP) that may be located anywhere on the network. The ADSP is a distinct organisational and technical entity that processes real-time ATM data — flight data processing, surveillance fusion, conflict detection, arrival sequencing — on behalf of one or more ATSUs under a Service Level Agreement. The controller working position (CWP) at the ATSU consumes these processed data services without hosting the processing infrastructure locally.

SESAR defines the virtual centre formally as "a single ATSU or a grouping of collaborative ATSUs using data services provided by ATM Data Service Providers (ADSPs), providing geographical decoupling between ADSP(s) and some ATSU(s) through service interfaces defined in Service Level Agreements." ICAO Doc 10057 (ATSEP Training Manual) lists virtual centre (remote CWP) as a training example under the competency element for concepts of virtualisation in ATM (ATSEP.BAS.DPR_1.2.3), confirming it as an ICAO-recognised ATM concept.

Regulatory Basis

The ATS provision framework is Annex 11 (Air Traffic Services), Chapter 2. Standard §2.1.1 establishes that States shall arrange for ATS to be provided, and that by mutual agreement a State may delegate to another State the responsibility for establishing and providing ATS in FIRs, control areas, or control zones over its territory. The Note to §2.1.1 confirms that delegation does not derogate national sovereignty and that the providing State's responsibility is limited to technical and operational considerations. Standard §2.10.2 requires ATC units to be established; it does not prescribe that data processing occur locally. Annex 11, §2.32 and Attachment C mandate contingency plans for disruption of ATS — the virtual centre architecture directly enables cross-site contingency continuity.

In EU law, Commission Implementing Regulation (EU) 2017/373 lays down common requirements for all ATM/ANS providers. It explicitly recognises "data services providers" as a distinct regulated entity class under EASA oversight as the competent authority. The regulation specifies that data services providers and the Network Manager are pan-European, making EASA their competent authority. The ADSP certification pathway became applicable from 1 January 2019.

PANS-IM (Doc 10199, §2.1.4) requires information exchange through services in a service-oriented architecture (SOA), providing the normative SWIM backbone on which virtual centre connectivity rests. Doc 10039 (SWIM Concept) and Doc 10203 (SWIM Service Description) give guidance on the SOA principles.

The EU Airspace Architecture Study (March 2019) — commissioned as input to SES2+ reform — introduced a three-layer service model: ATM data production, ATM data processing, and Air Traffic Services. The ADSP occupies the data processing layer and can be contracted and certified independently of the ANSP delivering the air traffic service.

Operational Meaning

The virtual centre concept separates three previously co-located functions:

  • Data service provision: flight data processing, surveillance fusion, conflict detection, sequencing, departure management — performed by the ADSP.
  • Air traffic service provision: the controller issuing clearances, managing traffic, and exercising separation responsibility — performed by the ATSU.
  • Controller working position: the CWP interface through which the controller accesses ADSP-processed data — which may be at any network-connected location.

This separation enables the following operational scenarios:

Night-time consolidation. A single ADSP serves multiple ATSUs, and low-traffic ATSUs reduce overnight staffing by connecting to a consolidating ATSU without replicating local systems.

Cross-border ATS delegation. One ATSU provides ATS for airspace legally belonging to a neighbouring State by consuming data from an ADSP whose coverage includes the delegated airspace. This is enabled by Annex 11 §2.1.1 delegation and is the primary operational use case for cross-border Single European Sky service consolidation.

Contingency continuity. If a primary control centre is lost, controllers move to a contingency location and reconnect to the same ADSP network, restoring service without replicating local data infrastructure.

Capacity-on-demand. The ADSP's compute resources are scaled to traffic demand, reducing fixed infrastructure costs at each ANSP.

Disaggregated supply chain. ADSPs can be contracted from commercial or cross-border providers and certified independently, unbundling the historically vertically integrated ANSP model.

The COOPANS alliance (Austria, Croatia, Denmark, Ireland, Portugal, and Sweden) demonstrated multi-ADSP, multi-ATSU virtual centre architecture in the EXODUS project, showing inter-vendor interoperability between ATSUs and ADSPs. The iTEC alliance (DFS, ENAIRE, NATS) cooperated with EUROCONTROL on a Flight Object Manager and SWIM node as a building block for multi-centre trajectory data sharing.

Architecture and Service Structure

SESAR identifies three primary delegation architectures:

D architecture. One ADSP delivers services to multiple ATSUs; in a failure scenario, ATSUs switch data provision between ADSPs for resilience. This is the primary contingency model.

Y architecture. One ADSP serves multiple ATSUs with traffic delegation; supports night-time consolidation, fixed-time delegation, and contingency without relocating controllers.

U architecture. Supports delegation between ATSUs where one ATSU covers another's airspace, consuming shared ADSP services.

A further Triangle architecture disaggregates a monolithic ADSP into functionality-oriented ADSPs — separate entities for departure management, arrival sequencing, and conflict detection — with a composed service presented to the ATSU.

The SWIM connectivity layer (PANS-IM Doc 10199; EUROCONTROL SPEC-170 Yellow Profile, Edition 2.0) is the technical fabric for distributing ADSP services across the network. The SWIM Blue Profile (currently in research phase, not yet published) targets very high-availability real-time flight-object exchange between ATC centres and is the candidate profile for intra-virtual-centre communication.

External Sources

References

  1. Annex 11 (Air Traffic Services), Chapter 2, §2.1.1 — States shall provide ATS; by mutual agreement a State may delegate responsibility for ATS in FIRs, control areas or control zones to another State; delegation does not derogate sovereignty.

  2. Annex 11, Chapter 2, §2.10.2 — Air traffic control units shall be established to provide ATC service; no prescription that data processing be co-located with the controlling unit.

  3. Annex 11, Chapter 2, §2.32 and Attachment C — States shall develop contingency plans for disruption of ATS; virtual centre architectures are a key enabler of contingency continuity.

  4. Annex 11, Chapter 3, §3.1 — Responsibility for control of aircraft in a block of airspace vested in a single ATC unit; control may be delegated to other units provided coordination is assured.

  5. Doc 10199 (PANS-IM), Chapter 2, §2.1.4 — Information exchange shall be performed through information services in a service-oriented architecture; underpins SWIM-based ADSP connectivity.

  6. Doc 10057 (ATSEP Training Manual), Module DPR_1.2.3 — Virtual centre (remote CWP — SESAR) cited as a training example under concepts of virtualisation in ATM.

  7. Doc 9854 (Global ATM Operational Concept), Chapter 2, §2.2.3 and §2.1.9 — ATM service delivery seamless across all service providers gate to gate; regional ATM service providers and independent private sector providers recognised as ATM community members.

  8. Commission Implementing Regulation (EU) 2017/373 — Common requirements for ATM/ANS providers; data services providers as a distinct regulated entity class; EASA as competent authority (authoritative source — not in local library; see eur-lex.europa.eu).

  9. EU Airspace Architecture Study (March 2019) — Three-layer service model: ATM data production, ATM data processing (ADSP), Air Traffic Services; ADSP certification framework and capacity-on-demand concept (authoritative source — not in local library; see sesarju.eu).

  10. SESAR ATM Master Plan, element MP 3.4.2 — Layered approach to service delivery; virtual centre as a key element of the Digital European Sky (authoritative source — not in local library; see atmmasterplan.eu).

  11. SESAR Virtual Centres FAQ — Definition of virtual centre and ADSP; D/Y/U/Triangle architectures; delegation models (authoritative source — not in local library; see sesarju.eu).

Related topics