CCS CorrelationDistribution 1.2.0

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 CorrelationDistribution service is consistent with the other CCS services. It supports the distribution of correlation information for flights when it is updated and periodically, if required, for all flights to increase the resilience of the service. 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 Type
SWIM_CANDIDATE
Lifecycle Stage
PROSPECTIVE
Business Activity Type
INFORMATION_MANAGEMENT
Intended Consumer
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Information Exchange Category
FLIGHT_INFORMATION_EXCHANGE
Application Message Exchange Pattern
PUBLISH_SUBSCRIBE
SYNCHRONOUS_REQUEST_REPLY
Aerodrome ICAO Location Indicator
No Information Provided
FIR ICAO Location Indicator
No Information Provided
State ICAO Nationality Letters
No Information Provided
In-Operation Date
No Information Provided
Provider
DSNA&ENAV

DSNA: the French air navigation service provider

ENAV; the Italian air navigation service provider

Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Support
No Information Provided
Point of Contact
Guillaume Ramonet
Coflight Cloud Services Program Director - To request access to the CCS service
Email
Guillaume.Ramonet@aviation-civile.gouv.fr
Telephone
No Information Provided
Service Desk
- For Incidents on services in operation, contact the Service desk [working hours/opening days] as described in the related support service (incident management) supplied by CCS provider to CCS customer during the procurement phase
Email
No Information Provided
Telephone
No Information Provided
1
Operational Need

CCS FlightDataManagement Service addresses the CWP manual interactions for managing Flight Plan updates related to inputs made by the controller or by the Flight Data Operator. It addresses operations related to:

- the System Flight Plan Data: Create, Cancel, Delete, Retrieve, Create Abbreviated and Non tactical modifications,

- to ATC Instructions: Holding, Heading, Speed, CFL, ROCD, EFL, XFL, DirectTo, ClearedTo, RFL and ECL,

- the correction of erroneous AFTN messages,

- WhatIf: Accept/Reject and Open/Close.

Note: in this version of the document, CCS FDM contains all the operations listed above except those related to WhatIf.

Functionality 1
Description
Process a Cleared Flight Level instruction
Real World Effect
The trajectory of the flight is updated accordingly.
Functionality 2
Description
Process a Direct instruction
Real World Effect
The trajectory of the flight is updated with the direct clearance.
No Information Provided
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.
Concepts
No Information Provided
No Information Provided
Information
BooleanType
AIRM Conformant
Off
AIRM Version
No Information Provided
Boolean
FlightIdentifier
AIRM Conformant
Off
AIRM Version
No Information Provided
Flight Identifier
FlightIdentifierType
AIRM Conformant
Off
AIRM Version
No Information Provided
Type supporting a unique flight identifier that can be : an internal flight Id assigned by the FDPS, an IFPLIdentifier, an aircraftRegistration, a flightNumber...
SystemAreaCodeType
AIRM Conformant
Off
AIRM Version
No Information Provided
The System Area Code (SAC) centrally maintained and allocated to a specific region. Hexa value on 2 chars.
SystemIdentificationCodeType
AIRM Conformant
Off
AIRM Version
No Information Provided
The System Identification Code (SIC) allocated nationally by the responsible Air Traffic Services Organisation. 0 to 256 range.
SystemTrackIdentifierType
AIRM Conformant
Off
AIRM Version
No Information Provided
Identification of a track as defined by Asterix062.
TimeStampDateType
AIRM Conformant
Off
AIRM Version
No Information Provided
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
TrackIdentifier
AIRM Conformant
Off
AIRM Version
No Information Provided
Radar track identifier
AllCorrelationDataMessage
AIRM Conformant
Off
AIRM Version
No Information Provided
The AllCorrelationDataMessage contains the correlation status of all flights in the system.
CodeCorrelationAmbiguityType
AIRM Conformant
Off
AIRM Version
No Information Provided
Define the types of ambiguity that may be detected during the automatic correlation process.
CodeCorrelationStatusType
AIRM Conformant
Off
AIRM Version
No Information Provided
This defines the correlation status of a flight. If the flight is UNCORRELATED it indicates that the automatic correlation process has not started, has been initiated but not completed or has failed.
CodeReasonAutomaticallyDecorrelatedType
AIRM Conformant
Off
AIRM Version
No Information Provided
This provides the reason that a flight has been automatically decorrelated: - FLIGHT_TERMINATED: De-correlation performed when the SFPL flightPlanStatus becomes TERMINATED. - TRACK_DROP: De-correlation performed upon loss of the system track. UNEXPECTED_CODE: De-correlation performed when the system track SSR code changes to a code that is not the current SSR code, nor the following SSR code, nor an emergency SSR code.
CorrelationAmbiguityData
AIRM Conformant
Off
AIRM Version
No Information Provided
This class is present when the automatic correlation process failed because it was unable to identify a unique relationship between a single SFPL and a single system track via the SSR code assigned to the SFPL. This would occur under the following circumstances: ONESFPL_MANYTRACKS - multiple tracks within the SFPL's correlation search volume are squawking the SSR code assigned to the SFPL. MANYSFPL_ONETRACK - A track update is received whose received SSR code is assigned to multiple SFPLs that meet the correlation criteria. MANYSFPL_MANYTRACKS - there are multiple SFPLS and tracks that meet the correlation criteria, i.e. the SFPLs are assigned the same code and multiple tracks are squawking that same code in the region where If there are multiple tracks that meet the correlation criteria for an SFPL then the relevant track identifiers are provided in the correlation ambiguousTrackData. If there are multiple flights that meet the correlation criteria for an SFPL then the relevant flight identifiers are provided in the correlation ambiguousFlightData. Ambiguous correlation issues usually require manual intervention by a controller. For example, the ONESFPL_MANYTRACKS case means that at least one aircraft is squawking the wrong code. This may be a transient situation because the transponder of an aircraft was not put into Standby mode when changing codes or simply that an aircraft has entered the wrong code. In the former case it may resolve itself but in the latter case a controller will have to identify the aircraft involved and resolve the situation manually.
CorrelationData
AIRM Conformant
Off
AIRM Version
No Information Provided
The CorrelationData class consists of the correlation information related to a given flight: correlationStatus, FlightIdentifier, optionally the TrackIdentifier, and CorrelationAmbiguityData (present in case of ambiguity only)... CCS starts distributing correlation data for an SFPL when this SFPL is eligible for correlation or if it is MANUALLY_CORRELATED. An SFPL is eligible for correlation if the following conditions are satisfied: - it is not CORRELATED, - at least one internal segment of the system instance is PENDING or LIVE (e.q "pre-active" or "active" in Coflight) or one external segment of the system instance is LIVE (e.q "in-use" in Coflight), - it has at least an SSR Code to be correlated (in the SSR Code sequence computed for this SFPL, an SSR Code has not yet been used for correlation or has been used, then decorrelated). Notes: - To be eligible for correlation with Mode S tracks, an SFPL has to be Mode S equipped. - An SFPL without controlled segments cannot have an SSR code to be correlated, therefore it is not eligible for correlation.
CorrelationDataMessage
AIRM Conformant
Off
AIRM Version
No Information Provided
The correlationDatamessage is sent when a flight is correlated or decorrelated to/from a system track as a result of an AUTOMATIC or MANUAL correlation or decorrelation
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. 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
CCS services are supervised in real time by trained and licensed ATSEPS.

A dedicated service to supervise the complete CCS swim services portfolio is available to the customer.
For more information, please refer to the swim service description of the CCS technical supervision distribution service
CorrelationDistributionProvider

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

PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
getRepository
Allows a consumer to get the applicable data related to flight correlation status
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.
No Information Provided
Service behaviour
The detailed behavior of the service is provided in each operation dedicated section
CorrelationDistributionSubscriber

This Service Interface exposes two operations for publishing updates of correlation status, either immediately on a specific flight when updated, or periodically for all flights.

PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
FIRE_AND_FORGET
Operations
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.
No Information Provided
Service behaviour
The detailed behavior of the service is provided in each operation dedicated section
References
No Information Provided
Revision Save Date
Wed, 07/01/2020 - 10:34
Revision Number
46171