As discussed in Parts 2 and 3, the purpose of the common data layer is to provide ATM data services for all area control centres, but also to airports and airlines. In this blog Maribel Tomás Rocha explores two specific aspects:
- Firstly, the technical requirements of the common data layer; and
- Secondly, the potential organisational structures that could be used to meet those requirements.
Requirements for the common data layer
The objective of the common data layer is to ensure that current flight data for all flights can be accessed by the network manager, ANSPs, airports and even the airlines.
Synchronised access to the common data is essential to enable gate-to-gate trajectories that are predictable, cost-efficient and sustainable throughout the entire flight. The common data layer integrates data from the physical layer into the ATM data services required by the ATS services (see the figure below).
For virtual centres to work efficiently, the common data layer must be robust to allow seamless operations from any stakeholder.
The physical layer contains radio, radars and sensors which are geographically dependent to provide the raw data for Communications, Navigation, Surveillance, MET and AIS. In the common data layer, this raw data is processed in two steps:
1. The raw data from the auxiliary services is processed by the integration services – e.g. combining surveillance data to transform radar plots to flight tracks.
2. ATM Data Services then gather all the data from the integration services and play with it to provide useful data and information such as trajectory prediction to the Air Traffic Services. This data is updated in real-time and stored in the cloud so any stakeholder can subscribe.
These two services ensure that the common data layer contains current data. All centres subscribe to the same data services, hence it is synchronised across all centres. If one ANSP, airline or airport changes any flight data in the common data layer then all actors that are connected to it are able to see the updated flight. This promotes negotiation of the trajectory in real time between all the stakeholders including airlines and airports – flight management decisions that really involve everybody. However, the industry has to resolve the conditions that define who is responsible for a flight and who can change it. For example, an airline may propose to delay a flight due to a late inbound service, but who needs to approve the change? Or if an approach controller wants to slow down a particular inbound flight to optimise the approach sequence, do the planners of all affected sectors need to agree?
Potential models for providing the common data layer
In the current system, a single ANSP is typically in charge of all layers – from the auxiliary services to the ATS. However, there is already the possibility to outsource the auxiliary services (in the integration and physical layers) – for example SITA for Communications, ESSP for Navigation, Aireon for Surveillance, EADS for AIS or national met offices for MET services.
The proposed architecture, however, has the potential to create contestable markets at three levels:
– ATS;
– ATM Data services; and
– Auxiliary services in the physical and integration layers.
The different service provider models discussed below enable competition in the different layers.
- Alliance model
The alliance model is the easiest transition from the current model, especially when adopted by a FAB. The main change is that a group of ANSPs operate their ACCs as a single virtual centre, leading to internal resilience and collaborative decision making. The virtual centre is then supported by a Joint Venture of the ANSPs, to provide all the necessary ATM data, integration and auxiliary services. In this model, it is consolidation rather than competition that drives efficiency.
- Competitive ADSP model
In the competitive ADSP model, one or more specialist organisations are created to provide ATM Data Services – the so called ADSP. The ADSPs ensure access to the common data layer. The virtual centre, usually an ANSP or FAB, can select the ADSPs they want to subscribe to leading to competition. However, there is also a need for collaboration between ADSPs so that data is accessible by all ATSPs, airports and airlines.
In this model, the auxiliary services market would remain unchanged, with existing ANSPs being responsible for their provision and integration.
- Competitive auxiliary services model
In the competitive auxiliary services model, a single ADSP is responsible for contracting all the necessary services in the layers below.
Competition would then exist for the auxiliary services (CNS, AIS, MET) and integration services ANSPs may continue to provide these services (by winning the contract), but consolidation and new entrants are much more likely – particularly when new technologies are deployed.
This model could also be used to introduce competition for ATS, with ANSPs requiring additional capacity able to buy from any ANSP with spare capacity. Or even with the ADSP acting as a capacity broker, procuring capacity from ANSP as required by the daily forecast.
It may be that the model adopted should be left to the industry and that different models could be supported as long as the overall objective is achieved. Experience suggests however that this may not be the quickest way to achieve the transition – and the European Commission should look at approaches to accelerate the availability of the common data layer as a perquisite to other optimisations.
Future blogs
In Part 5 of this blog series my colleagues Diana Toma and Jonathan Twigger explore how the role of controllers and engineers will need to evolve to support the future ATM system.
Author: Maribel Tomás Rocha
Recent Comments