CCS services integration in the SWIM Registry: lesson learned

A few months ago, Coflight Cloud Services became the first to publish its services in the SWIM Registry. These services are developed within the context of the Single European Sky, the SESAR Deployment Manager and the Airspace Study Architecture. This registration in the SWIM registry is an important step for CCS, which required a strong involvement and significant investments from the teams. Today we are telling you about this step, the difficulties and challenges we have encountered.

The SWIM Service Description team

In order to complete this stage CCS has set up a dedicated team: the SWIM Service Description (SSD) Team. The SSD Team is responsible for the specification of CCS Services in terms of service and data model definition and description, according to SWIM governance requirements for the SWIM Service Description and in compliance with SESAR specifications for Virtual Centre.

The team is composed of two poles: 

• Service Design by DSNA : take SESAR specifications and tune them to match Coflight’s specificities (identify technical parameters and extensions to SESAR model, map SESAR’s data model to Coflight’s one)
• SWIM Service Description Documents by ENAV: maintain the UML (Unified Model Language) CCS Model, generate the Protocol Buffers files( Service Contract used by customer’s and provider’s development teams), the SWIM Service Description Documents (one for each CCS Service) and the JSON file required for the SWIM Registry.

The team has now succeeded in publishing 8 out of 11 CCS services as candidate into the SWIM registry and is close to complete its service description and reaches fully compliancy.

In order to achieve this objective, the team has been collaborating with three different entities:

• SWIM Governance: to address the initial concerns about the translation of its Service Description documents into the required format.

• SSCONE-SITCOM working group:
  • SSCONE : SWIM Service Community of Interest to discuss the SWIM Service Description Specification
  • SITCOM: The SWIM Information Community of Interest to discuss the SWIM Information Definition Specification
• SWIM Registry: to provide in advance the services to allow the SWIM Registry technical team to check, validate and publish them in its test environment. To solve some technical issues that the SSD team has encountered for the automatic upload of the CCS Services into the SWIM Registry. Identify and notify about some discrepancies between the expected schema and the form for the manual registration of the service.

Our opinion on the integration to the SWIM registry

Following this first experience with the different entities and the integration of the majority of our services in the SWIM registry, here is our feedback and advice on the subject.

What SWIM brings us:

• Interoperability: at various levels (infrastructure, service description, data model) due to the applicability of the SWIM requirements and standards.
• Market opportunity: give opportunity to others customers to joins us on a common European base
• Anticipation : have a learning curve and a vision for the future of Air Traffic Management

What are the challenges we have encountered:

• Data: Stability of data model of the SWIM registry.
• Cost of being pioneer on the subject: Requires agility, times and significant investment to understand and launch processes.
• No standardised exchange schemas: Required traceability to the reference data model (AIRM) can be time consuming in case of large service payload with no existing standardised exchange schemas to reuse.
• Rhythm of quick technology change compare to ATM reference catalogue: New technologies are evolving every day, while the ATM system is still based on tools that lack flexibility and interoperability.

Our recommendations:

• Service design and development: Service Contracts and SWIM Service Descriptions are the main artefacts to achieve, as the corner stones of all teams (development, validation, etc.). These actions are to be carried out first.
• A common repository : this tool should be used to capture and store all service “meta-data” (e.g. Point of contact, Policies, URL, etc…), and then to generate SWIM Service Descriptions, Service Contracts and JSON files for the SWIM Registry, as they have many data in common. This would save time and facilitate exchanges.
• Agile mind-set: an Agile approach is a plus to enhance team flexibility and efficiency, even if is an important investment.
• Technology watch: maintain a regular technology watch to keep a list of SWIM compatible technologies up to date.

Being the first to register its services in the SWIM Registry was not an easy thing to do. Indeed, having no reference on which to rely, the teams had to work hard to face some difficulties in order to build jointly the right documents with the different entities.

What are the next step for CCS

Our work around the SWIM Registry is not finished yet. In the coming period the SSD Team will monitor the potential evolutions of Service Description document schema in order to always be aligned to the latest version.

Starting from January 2021, when the second step of CCS begins, the SSD team will be engaged in the definition of new services and operations and, if needed, in the enhancement of existing ones. The SSD Team foresees to publish CCS services into the SWIM registry on a regular basis in order to provide their latest available version.

Among others, one key milestones is the publication of the first CCS compliant service into the SWIM Registry for which the SSD Team plans to complete the related tasks during the step 2 (2021).

These actions will still been taken within the framework of the Digital Sky and the SESAR Virtual Centre, in coordination with EUROCONTROL, SESAR and SWIM governance. We will also be happy to share our work within the EUROCAE WG12.