DSNA&ENAV
DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
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 OperationalConfigurationDistribution service is consistent with the other CCS services. It supports the distribution of the following operational configuration data to CWP and operational supervisor consumers according to their subscription to the service: - the on-line updates of the mapping of the couples of control roles and responsibilities (control volume, ADES, set of runways,...) on the logical positions. 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
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
Support
No Information Provided
Point of Contact
Coflight Cloud Services Program Director - To request access to the CCS service
Email
Guillaume.Ramonet@aviation-civile.gouv.fr
Telephone
No Information Provided
- 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
General
Operational Needs
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
Description
Process a Cleared Flight Level instruction
Real World Effect
The trajectory of the flight is updated accordingly.
Description
Process a Direct instruction
Real World Effect
The trajectory of the flight is updated with the direct clearance.
Access and Use
No Information Provided
Quality of Service
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.
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.
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
Concepts
No Information Provided
Abbreviations
No Information Provided
Information
Information Definition
AIRM Conformant
Off
AIRM Version
No Information Provided
Boolean
AIRM Conformant
Off
AIRM Version
No Information Provided
Indicates the type of instance used to activate this sector mapping. The original mapping is either an off-line predefined mapping or a next mapping
AIRM Conformant
Off
AIRM Version
No Information Provided
This data type may be used to distinguish the instance of sectorConfiguration, that can be the Current or the Next ones.
AIRM Conformant
Off
AIRM Version
No Information Provided
It is used to indicate the role concerned. The role represents the various ATM operation functions in an ATSU.
ACC_APP_SUPERVISOR: ACC/Approach Supervisor
AIRSPACE_MANAGER: Airspace Manager
COMPLEXITY_MANAGER: Complexity Manager
EXECUTIVE_CONTROLLER: ATC Executive Controller
EXTENDED_ATC_PLANNER: Extended ATC Planner (EAP)
FLIGHT_DATA_OPERATOR: Flight Data Operator
FLOW_MANAGER: Flow Manager
LOCAL_CAPACITY_MANAGER: Local Capacity Manager
LOCAL_TRAFFIC_MANAGER: Local Traffic Manager
MULTI_SECTOR_PLANNER: Multi-Sector Planning Controller
PLANNING_CONTROLLER: ATC Planning Controller
TECHNICAL_SUPERVISOR: Technical Supervisor
INSTRUCTOR: Instructor
AIRM Conformant
Off
AIRM Version
No Information Provided
Generic type to address comment/description/remark attributes within a medium length frame
AIRM Conformant
Off
AIRM Version
No Information Provided
Identification of a specific controller (originator of a request, served for SFPL distribution, target/originator of a PointSession...).
AIRM Conformant
Off
AIRM Version
No Information Provided
String to identify a controller.
AIRM Conformant
Off
AIRM Version
No Information Provided
A Logical CWP is used to define a set of control Responsibilities (e.g. control sectors "S1", "S2", "S3") to be managed by a role (e.g. "Tactical") on a controller working position.
A logical CWP may have no associated role/responsibility, but when it is operationally used, it is always defined by a list of Responsibilities (e.g. control sectors, set of STARs...) and an associated role ("Tactical", "Planner"...).
A Responsibility cannot be mapped to more than one Logical CWP for the same role.
Off-line defined parameters identify which Logical CWP is mapped to which actual "physical" CWP.
AIRM Conformant
Off
AIRM Version
No Information Provided
LogicalCWP identifier
AIRM Conformant
Off
AIRM Version
No Information Provided
String to identify a logicalCWP.
AIRM Conformant
Off
AIRM Version
No Information Provided
String to identify the name of a sector mapping.
AIRM Conformant
Off
AIRM Version
No Information Provided
Other operational entity mapped on the originator working position.
Note: Even if the originator is a single controller, he may belong to a logical position composed of several operational entities (several Role/Responsibility couples).
AIRM Conformant
Off
AIRM Version
No Information Provided
A Responsibility defines a domain assigned to a controller. Typically, a control Responsibility might be a control volume dealing with GAT & IFR traffic, but it can also be, for example, an ACC AOR, an aerodrome, a runway, a set of runways, a set of stands at an aerodrome or any identifiable set of flights.
In EnRoute context, a control Responsibility is often a control volume composed of several unitary control sectors.
AIRM Conformant
Off
AIRM Version
No Information Provided
The unique identifier of the ASTUSectorConfiguration
AIRM Conformant
Off
AIRM Version
No Information Provided
ID to support the identification of the ATSUSectorConfiguration.
AIRM Conformant
Off
AIRM Version
No Information Provided
The designator of the SectorMapping.
AIRM Conformant
Off
AIRM Version
No Information Provided
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
AIRM Conformant
Off
AIRM Version
No Information Provided
Message definition for the sector configuration publication after an on-line update from the operational supervisor.
For each ATSU Sector Configuration, the current Sector Mapping, and possibly a next Sector Mapping, are defined.
Generally, only one ATSU Sector Configuration is defined to cover the entire AoR of the ATSU. However, more than one ATSU Sector Configuration can be defined if needed, for instance if different qualification areas exist for this AoR: it allows to manage independently different Sector Mappings for each part of the AoR (these different Sector Configurations must cover the whole AoR, and not overlap).
ATSU Sector Configurations are defined off-line, and cannot be updated on-line. Each Sector Mapping refers to a given ATSU Sector Configuration (unless only one is defined for the ATSU, in which case in can be omitted)
Note: This message can contain the description of all the SectorMappings (except the pre-defined, which are off-line provided) of the concerned ATSUSectorConfiguration.
AIRM Conformant
Off
AIRM Version
No Information Provided
Message definition for the operation of the same name.
Note: CCS never considers the originator of the request getSectorConfiguration, as no eligibility is performed on this request.
AIRM Conformant
Off
AIRM Version
No Information Provided
Class supporting:
- the payload required to perform the operations publishSectorConfiguration and publishRadioFrequencyAllocation.
and
- the input parameters of the operations getSectorConfiguration andgetRadioFrequenciesAllocation.
AIRM Conformant
Off
AIRM Version
No Information Provided
Message definition for the operations that allow the consumer to get the current state of Operational Configuration data on request.
AIRM Conformant
Off
AIRM Version
No Information Provided
The Sector Mapping is defined as a list of Logical CWPs and the composition of each Logical CWP in terms of Role and Responsibilities. It is associated to a given ATSU Sector Configuration, and contain all Logical CWPs associated to this mapping (including logical CWPs mapped to a Role and a Responsibility, and those without any role/responsibility mapped).
In operational terms, the Sector Mapping corresponds to the need of identifying which sectors are to be controlled on each active CWP by a controller with a specific Role (Tactical, Planner, ...) at a given time in the ATSU (or in an ATSU partition). Two types of Sector Mappings can be defined:
· the current Sector Mapping : it is the only one which is currently active for an ATSU Sector Configuration (assignment of roles/sectors on the CWPs currently used in the operational room managed by the supervisor).
· the next Sector Mapping: it is a mapping planned to be applied as current configuration in the future. Only one Sector Mapping can be defined as next at a given time for an ATSU Sector Configuration.
Data Structures
No Information Provided
Schema Language
Protocol buffer
Reference
CCS_operationalConfigurationDistribution.proto v3.0.0.1
No Information Provided
Schema Language
Protocol buffer
Reference
CCS_operationalConfigurationDistribution.proto v3.0.0.1
Technical
Security Mechanism
Mutual authentication with X509 certificates is used between the AMQP broker and its client established within a TLS session
TLS 1.2 is used to provide confidentiality and integrity at transport layer.
IPsec is used to provide confidentiality, authentication and integrity at network (internet) layer
Technical Constraint
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.
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.
- More generally, since the distribution events from different services are asynchronous (independent CORRD/FDD... topics), they may be received in an unexpected sequence during a short time (a few ms) before reaching consistency.
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.
The Customer is the one that initiates the TCP connection and in case of a Network / Connection failure, it is the responsibility of the CCS customer to try to reconnect regularly.
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
Monitoring Description
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
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
Interfaces
This Service Interface exposes the operations that allow the consumer (operational supervisor, technical supervisor...) to get the current state of Sector Configuration data on request.
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
Allows a consumer to get the applicable data related to sectorMappings.
This operation returns the SectorMappings: the current SectorMapping and the next SectorMapping (if available) of the requested ATSUSectorConfiguration.
Endpoints
Address
For security reasons, the adresses will be communicated only to Customers
Description
No Information Provided
Interface Binding Description Overview
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.
Interface Binding Configurations
No Information Provided
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
This Service Interface exposes one operation for publishing on-line updates of Sector configuration data
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
FIRE_AND_FORGET
Operations
In case of operational configuration change, this operation performs the publication of the new status and data related to the updated ATSUSectorConfiguration to the subscribed service consumers.
Endpoints
Address
For security reasons, the adresses will be communicated only to Customers
Description
No Information Provided
Interface Binding Description Overview
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.
Interface Binding Configurations
No Information Provided
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
References
Service Documents
Service Description Document (SDD) from PJ.16-03 on which the CCS Service is based
Protobuf files describing the exchanged information
Complete service specification
Implemented Standards
No Information Provided
Revision Save Date
Wed, 07/01/2020 - 10:57
Revision Number
46241
The service description has currently reached the "PUBLISHED" status.