CCS MonitoringAidsDistribution 2.0.0
Current JSON Original JSON

Abstract

This Service is part of Coflight Cloud Services (CCS), which are primarily designed to support the Virtual Centre concept. As such, these CCS Services support the interactions between the CCS ATM Data Service Provider (ADSP) and Virtual Centre Air Traffic Service Units (ATSUs). The CCS MonitoringAidsDistribution service is consistent with the other CCS services. It addresses the distribution of the Conformance Monitoring Aids to the CWP, providing the whole picture of the trajectory adherence status of a flight. The adherence status, seen as a composition of detected deviations, is usually determined by monitoring flight behaviour (i.e. lateral, vertical, speed) and intents against thresholds determined on elements of the ground system trajectory and issued clearances. The deviations are of different natures. They may be relative to: - Track conformance with controller clearances. e.g. checking that the track altitude corresponds to the CFL - Track conformance with holding plans. e.g. checking that a track is exiting a hold at the planned time - Track conformance with the planned or tactical trajectory in the lateral, vertical and longitudinal dimensions This version of the service is intended to be used in 'test mission', which aims at providing services and support to the Customer(s) to enable them to test any version of their ATM system during development.

 

Service retired from 20/03/2023

Service Type
SWIM_COMPLIANT
Life Cycle
RETIRED
Business Activity Type
INFORMATION_MANAGEMENT
Intended Consumer
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Information Exchange Category
FLIGHT_INFORMATION_EXCHANGE
Application Message Exchange Pattern
BROKERED_PUBLISH_SUBSCRIBE_WITH_PUSH_MECHANISM
SYNCHRONOUS_REQUEST_REPLY
In-Operation Date
24-Jun-2022
Provider
DSNA&ENAV

DSNA: the French air navigation service provider

ENAV; the Italian air navigation service provider

Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Point of Contact
1 General operational need

CCS MonitoringAidsDistribution Service supports the distribution of monitoring aids for each flight in the area of interest of the system instance when it is updated.

Information ownership

IPR
In accordance with their internal contractual rules on IPRs, DSNA, ENAV and skyguide retain exclusive ownership of the information contained in this document, which is to be deemed as foreground of the Coflight Cloud Services project (aiming at delivering remote flight data processing).

Access to the Service
This service is provided to Service Consumers under a contractual basis signed between the CCS Service Provider and the Service Consumer.

Dependencies with other CCS Services

If the service consumer also consumes other CCS services, this Service shall be consumed simultaneously with the other CCS SWIM Services that are part of the contractual agreement between the service consumer and CCS service provider.

Service versioning

Both the SWIM Service Description documents / Protobuf files and the CCS Services are versioned.
The version assigned to SSDs and to Protobuf files is composed by four digits in the form x.y.z.w.
New releases are numbered according to the following rule (compared to the previous version):
- w increased by one: means that some content that could be ignored by the developers changed and the changes do not affect the protobuf files generation. For example, changes in the comments or in the descriptions of services, fields and data structures.
- z increased by one: means that some content is changed by adding (but not changing or removing) some messages and/or data types. The generated protobuf files are expected to be an extension of the previous one and as result they are backward compatible.
- y increased by one: means that the file is changed by changing or removing some operations. The generated protobuf files are not expected to be compatible with the previous one.
- x increased by one: means that the file contains a new baseline. Major changes are expected to be present.

The service version is composed by 3 digits a.b.c assigned according to the following rule:
- a could be 0,1,2 depending on the status of the service with respect to the SWIM registration phase:
0: before the service application (as candidate)
1: if candidate
2: if compliant
- b Increments if major changes have been done with respect to the previous version (modify/remove). No backward compatibility.
- c Increments if minor changes have been done with respect to the previous version (addition/description modified). Full backward compatibility.

KPIs monitoring

Services management review are regularly organized with CCS customers to monitor the usability of the services and the KPI related to the quality of service described in the SLA.

Confidentiality and integrity

The interface of CCS business services is accessible from outside DSNA premises through Internet using IPV4. An IPSEC link (IKE v1 or IKE v2) is used between CCS provider and CCS customer terminal network equipment.

Authentication and authorisation

The CCS provider acts as a certificate authority to provide and validate X.509 certificates. Before service operation, a package including X509 certificate and private key, will be delivered to the customer using the PKCS#12 archive file format.
Mutual authentication with X509 certificates is used between the AMQP broker and its client. Prior to any exchanges of AMQP Messages, the CCS customer shall establish with CCS Provider a TLS session using TLS 1.2 version.
- CCS customer shall provide its certificates when establishing the connection. The certificates shall be valid (nor corrupted, nor revoked). The certificates of the CCS customer allow its identification for the use of the different CCS services (CCS business services at lower level).
- The CCS provider transmit its complete certificate during the connection phase and allow OCSP stapling to allow the CCS customer to check if it is valid or not.
- For the cryptographic algorithms, the authorized cipher suites must be agreed between the CCS provider and the customer based on the standards.
As an ATSU, the CCS business services customer, once identified, has access to all CCS services.
In the case of a Customer that would fail to authenticate 3 times in less than 3 minutes, the IP address would be ban and has to trigger the incident management procedure.

Services level objectives

The service level objectives regarding the availability, response time, throughput and recoverability of CCS Services depend on the purpose (mission) for which the Customer intend to use them (e.g. integration, test, training, operational purpose).
These service level objectives are therefore negotiated with the Customers, based on their safety analysis, and are detailed in the specific Service Level Agreement established with each CCS Customer.

Network performance

The minimum Bandwidth required to consume CCS services (hypothesis for the technical integration service of 300 simultaneous flight managed by the system) is 10MB/s.

Rate limitation

Customer ATSU shall restrict the overall rate of requests to a maximum of 720 request/minutes. The detailed rate limitation per services is detailed in the associated swim service description of each service.

ACC

Area Control Centre

ADSP

ATM Data Service Provider

AMQP

Advanced Message Queuing Protocol

ANSP

Air Navigation Service Provider

ATCS

Air Traffic Control Services

ATM

Air Traffic Management

ATS

Air Traffic Services

ATSU

Air Traffic Service Unit

CCS

Coflight Cloud Services

CWP

Controller Working Position

DSNA

Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)

ENAV

Ente Nazionale Assistenza al Volo (Italian ANSP)

FDO

Flight Data Operator

FDPS

Flight Data Processing System

FP

Flight Plan

HMI

human machine Interface

ICAO

International Civil Aviation Organization

ID

Identifier

IER

Interface Exchange Requirement

IKE

Internet Key Exchange

IP

Internet Protocol

IPSEC

Internet Protocol Security protocol

JU

Joint Undertaking

KPI

Key Performance Indicator

MONAD

Monitoring Aids Distribution

NTP

Network Time Protocol

OCSP

Online Certificate Status Protocol

OE

Operational Entity

PKCS

Public Key Cryptography Standards

RAM

Route Adherence Monitoring

ROCD

Rate of Climb Descent

SESAR

Single European Sky Air Traffic Management Research

SFPL

System Flight Plan

SLA

Service Level Agreement

SSD

SWIM Service Description

SSI

Synchronous Serial Interface

SWIM

System Wide Information Management

TCP

Transfer Control Protocol

TI

Technical Infrastructure

TLS

Transport Level Security

UTC

Coordinated Universal Time

Information
TLS 1.2

TLS 1.2 is used to provide confidentiality and integrity at transport layer.

IPsec v4

IPsec is used to provide confidentiality, authentication and integrity at network (internet) layer

Time synchronisation

CCS provider and CCS customer use the date and time for the operation of each service and they must be able to date the traces and the information passed to the SSI log collector.
NTP is the standard solution to synchronize time accurately. So, CCS Provider and CCS Customer should use, each of them, at least one NTP server (stratum N), integrated in a NTP network containing a stratum 0 reference time clock.

Provider-Customer interface-Exchange patterns

Each services interface of the CCS business services relies on the concept of AMQP queues and topics.
- The CCS customer shall use an implementation of the AMQP 1.0 specification to connect to the CCS provider AMQP 1.0 endpoint.
- The CCS provider endpoint is an AMQP 1.0 broker managing queue and topics.
The message payloads are encoded following a protobuf format.
The message exchange patterns used by the CCS services are request/reply and publish/subscribe. The CCS customer acts as requester and subscriber. The CCS provider acts as responder and publisher.
Concerning publish-subscribe, the CCS customer subscribes to a CCS distribution service by directly listening to an appropriate AMQP topic, which name follows the CCS derivation rules.
The subscription to CCS Distribution Services is not performed via subscription operations, but by connecting to the appropriate AMQP Topic described in the .protobuf files as topic://..
The subscribers can filter the messages they want to receive by using the filter parameters defined for each subscription operation.
Please note that, after subscribing to a CCS Distribution Service, the current repository of messages needs to be obtained from CCS via the get operation defined for each CCS Distribution Service (see "Subscription" section of the distribution operation of the service).
N.B:
- If the CCS platform restarts while the Customer is connected to the AMQP Broker, the current repository of messages is published again.
- The acknowledgement that a Customer receives to his request ("RequestReport") may be received after the data distribution that this request has triggered, as these two messages are managed asynchronously by AMQP Queues and Topics

Concerning request-reply the CCS customer sends a request by sending a message to an appropriate AMQP queue, which name follows the CCS derivation rules, to make a request. The request message contains the name of the queue into the CCS customer listens and in which the reply from the CCS provider is expected.

Provider-Customer interface-Queue management

The AMQP broker creates the physical resources associated with a destination (queue, topic) on demand when messages are actually sent to them.
Permissions on queues and topics (read/write access) are granted based on intended usage. The CCS customer will have:
- Write access on the request queue
- Read access on the reply queue
- Read access on the topic for distribution service

MonitoringAidsSubscriber

This Service Interface exposes the operation for publishing monitoring aids information for a flight, when this information is updated.

PROVIDER_SIDE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
FIRE_AND_FORGET
Operations
publishMonitoringAids

This operation sends the monitoring aids information of a flight when it is updated. As long as there is no update, the monitoring aids information of the last received message remains applicable.
A first notification is sent when the flight correlate for the 1st time (1st progression report), and then a notification is sent each time a deviation is created, removed or modified (ex: when the deviation amplitude is changed).
The evaluation of each deviation being made by the system in a cyclic pattern, its update (creation, removal, modification) can be delayed by a few seconds regarding the event itself. The maximum delay is determined by the cycle value defined in the dataset..

Synchronous
SYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
MonitoringAidsData

Information is exchanged in Protobuf format. Protocol buffers or Protobuf are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data similar to XML, but smaller, faster, and simpler.

Service behaviour

The detailed behavior of the service is provided in each operation dedicated section

MonitoringAidsProvider

This Service Interface exposes the technical operation that allows the consumer to get the current monitoring aids information of all flights on request. It is typically used when starting the Service, for initialisation.

PROVIDER_SIDE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
requestMonitoringAidsData

Allows a consumer to get all the deviations related to all the flights known by the System.
All the request parameters are ignored by CCS.

All the flights, except the ones that have never been correlated, are received as a response to this request (even the flights without any deviation on-going)..

Synchronous
SYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
MonitoringAidsDataRepositoryRequest

Information is exchanged in Protobuf format. Protocol buffers or Protobuf are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data similar to XML, but smaller, faster, and simpler.

Service behaviour

The detailed behavior of the service is provided in each operation dedicated section

References
CCS AIRM mapping MONAD service

AIRM traceability for CCS Monitoring Aids Distribution service payload

Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Monitoring+Aids+Distribution+Service
Note: to request access to Confluence, please refer to the point of contact section
CCS_monitoringAidsDistribution.proto

Protobuf files describing the exchanged information

Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Monitoring+Aids+Distribution+Service
CCS_common.proto

Protobuf file describing the exchanged information common to two or more CCS Services

Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Monitoring+Aids+Distribution+Service
metadata.proto

Protobuf file describing the metadata used by the CCS Services

Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Monitoring+Aids+Distribution+Service
CCS Errors Management Document

Document that includes the list of all applicable error messages for CCS services

Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+Documents
EUROCONTROL Specification for SWIM - Service Description

This specification contains requirements for describing information services in the context ofInitial System Wide Information Management (iSWIM). The requirements prescribe the minimum set of elements a service descriptionhas to contain

EUROCONTROL Specification for SWIM - Information Definition

This specification contains requirements forinformation definitions, meaning the formal descriptions of exchanged information, in the context of Initial System Wide Information Management (iSWIM). This contributes to semantic interoperability of information.

Revision Save Date
Mon, 03/25/2024 - 23:20
Schema version
v2