The future Air Traffic Management (ATM) systems will use service oriented architectures (SOA) and could be cloud-based. Skyguide pioneered this new approach with their Virtual Centre project and now SESAR has included it in the new Master Plan under the “new service delivery model” name. To get a better understanding of what this means and of what will change, I had a discussion with Arnaud Thézé, who is Head of the Software Factory at SkySoft.
Before discussing the future, we started by looking at the present situation. From a software point of view, ATM systems are organised in three categories: surveillance data processing systems (SDPS), flight plan data processing systems (FDPS) and general information systems, all interconnected together. Arnaud explained that this model with direct, proprietary connections has become increasingly hard to maintain over time.
Services, integration bus and cloud
With an SOA, each service will encapsulate as little functionality as required and communicate with other services in a standardised manner. Minimising the functionality allows for easier maintenance and evolution as new versions can be deployed for only one service and not for the full category.
Safety nets are a good example: they require information from the surveillance system and the flight plan system, plus some operational information about sectors being grouped together, for example. In a legacy architecture, the redundant safety nets servers would have dedicated interfaces to all the required systems and provide different types of alerts, like Short Term Conflict Alert (STCA), Minimum Safe Altitude Warning (MSAW), and Area Proximity Warning (APW).
With the new approach, different services are created for STCA, MSAW and APW, and they each have one single connection to a so-called integration bus. This is a software layer which services use to ask for whatever information they need from other services, without knowing any specific details about them. Additional software adapters allow services to use any integration bus, separating the service’s functionality from the way it communicates with others. Services are also independent from physical servers, which simplifies their management, deployment and redundancy.
The new software delivery model combines SOA with cloud technologies, decoupling the location of the services and of the users.
A challenging change requiring experience
As always, the devil hides in the details and Arnaud confirmed that moving to the new service delivery model is not easy. One important aspect is to decide on what “as little functionality as possible” means. If services are too large, there are few benefits compared to legacy solutions and if they are too small, the amount of inter-service communication becomes unmanageable.
There are no strong rules there, it is one topic where experience matters a lot. Arnaud explained how some services created by SkySoft are created from scratch and others are based on the source code of legacy projects. As SkySoft accompanies Skyguide on their transition towards SOA, Arnaud and his team learn along the way. One challenge is that the change does not happen all at once and when the first services are brought in operation, adapters are also required to allow legacy equipment to communicate with the integration bus.
The importance of standardisation
Another challenge that SkySoft had to overcome is the lack of standardisation. Surveillance data is typically encoded using the All-purpose STructured EUROCONTROL suRveillance Information eXchange (ASTERIX) standard, which is also used for safety nets alerts and a few other applications. Flight plan data can be represented using ADEXP and OLDI, which is really minimalistic. But when it comes to interactions between a Controller Working Position (CWP) and an FDPS, or direct interaction between CWPs for coordination, there are no standards.
Arnaud explained that providers like SkySoft can define ways of encoding data, for example using Flight Information Exchange Model (FIXM), and share them with the users of their services. But if a conflict arises between providers, having an internationally defined standard would be a better option.
Strong integrators required
This brought us to the next part of the discussion: the role of the integrator. In theory, one could imagine an Air Navigation Services Provider (ANSP) procuring services from various providers and even developing some of their own, plug all of them into their integration bus, and voilà.
This is however quite a naive view. SkySoft’s experience confirms the importance of having a strong partner taking the role of integrator, to avoid service providers starting pointing fingers at each other when something does not work. An integrator must be both knowledgeable and able to delegate.
Arnaud did state it clearly: “The integrator can be the ANSP, or one service provider, or even a third party. It is important for the integrator to have the knowledge and authority to drive problem solving discussions. If the ANSP does not want to be the integrator and prefers a single point of contact, they can delegate this responsibility.”
Software components and consulting services
SkySoft acquired significant experience in implementing SOA-based services in accompanying Skyguide over the last 10 years, but also in their work with other companies like Tern Systems. It is no surprise that both companies work well together: both are backed by ANSPs and working closely with them was precious in gaining initial experience.
Arnaud closed the discussion saying: “Our experience makes SkySoft a strong partner to ANSPs needing support on their journey towards the new service delivery model. We are ready to provide software services but also guidance regarding the transition itself.”
Written by Global Airspace Radar.
