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 AirspaceStatusDistribution service is consistent with the other CCS services. It supports the distribution of the following airspace configuration data to CWP and operational supervisor consumers according to their subscription to the service:
- The on-line updates of the ARES/CDR activation status.
- The on-line updates of the ARES/CDR planning. The dynamic updates of the airspace status are computed taking into account off-line airspace definition, e-AMI messages from CFMU and supervisor inputs.
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
Categorisation
SERVICE_DESCRIPTION
RETIRED
- INFORMATION_MANAGEMENT
- CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
- FLIGHT_INFORMATION_EXCHANGE
Provider
DSNA&ENAV
DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
- CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Restricted
Restricted
1 General operational need
CCS AirspaceStatusDistribution Service supports the distribution of the following airspace configuration data to CWP and operational supervisor consumers according to their subscription to the service: -The on-line updates of ARES (Airspace Reservation) and CDR (Conditional Route) activation status. ARES designates all military areas types: TSA (Temporary Segregated Area), CBA (Cross Border Area), TRA (Temporary Restricted Area)...-The on-line updates of ARES (Airspace Reservation) and CDR (Conditional Route) planning.
Publish ARES activation status
Publish ARES activation status
All subscribers (Control positions, operational supervisor...) are informed of any change on the ARES activation status.
Get Airspace activation status
Get Airspace activation status
On request, a subscriber gets the current state of Airspace (ARES and/or CDR) status data
Publish CDR activation status
Publish CDR activation status
All subscribers (Control positions, operational supervisor...) are informed of any change on the CDR status.
Get airspace planning
Get airspace planning
On request, a subscriber gets the current state of Airspace (ARES and/or CDR) planning data.
Publish ARES planning
Publish ARES planning
All subscribers (Control positions, operational supervisor...) are informed of new or updated planning of this ARES.
Publish CDR planning
Publish CDR planning
All subscribers (Control positions, operational supervisor...) are informed of new or updated planning of this CDR.
-
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 ServicesIf 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.
-
Alignment to SESAR Virtual Centre activityThis service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities
-
Service versioningBoth 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 candidate2: 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 monitoringServices 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 integrityThe 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 authorisationThe 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.
Subscription filter for AirspaceStatusSubscriber interface///~~///~~///62a852e0236ad
Subscription filter for AirspacePlanningSubscriber interface///~~///~~///62a852e0236af
-
ACCArea Control Centre
-
ADESAirport of Destination
-
ADSPATM Data Service Provider
-
AIRMATM Information Reference Model
-
AMCAirspace Management Cell
-
AMQPAdvanced Message Queuing Protocol
-
ANSPAir Navigation Service Provider
-
ARESAirspace Reservations
-
ASDAirspace Status Distribution
-
ASMAirspace Status Management
-
ATCAir Traffic Control
-
ATCSAir Traffic Control Services
-
ATMAir Traffic Management
-
ATSUAir Traffic Service Unit
-
CBACross Border Area
-
CCSCoflight Cloud Services
-
CDRConditional Route
-
CFMUCentral Flow Management Unit
-
CWPController Working Position
-
DSNADirection des Services de la Navigation A0xC3 0xA9rienne (French ANSP)
-
ENAVEnte Nazionale Assistenza al Volo (Italian ANSP)
-
FABFunctional Airspace Block
-
FABECFunctional Airspace Block Europe Central
-
FDOFlight Data Operator
-
FDPSFlight Data Processing System
-
FPFlight Plan
-
FUAFlexible Use of Airspace
-
HMIhuman machine Interface
-
ICAOInternational Civil Aviation Organization
-
IDIdentifier
-
IKEInternet Key Exchange
-
IPInternet Protocol
-
IPSECInternet Protocol Security protocol
-
JUJoint Undertaking
-
KPIKey Performance Indicator
-
MBMegaByte
-
NTPNetwork Time Protocol
-
OCSPOnline Certificate Status Protocol
-
OPSUPOperational Supervision
-
PKCSPublic Key Cryptography Standards
-
SDDService Definition Document
-
SESARSingle European Sky Air Traffic Management Research
-
SFPLSystem Flight Plan
-
SLAService Level Agreement
-
SSDSWIM Service Description
-
SSISynchronous Serial Interface
-
SWIMSystem Wide Information Management
-
TADTechnical Architecture Description
-
TCPTransfer Control Protocol
-
TDATemporary Danger Area
-
TITechnical Infrastructure
-
TLSTransport Level Security
-
TPATemporary Prohibited Area
-
TRATemporary Restricted Area
-
TSATemporary Segregated Area
-
UTCCoordinated Universal Time
Service Information Definition
-
Time synchronisationCCS 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 patternsEach 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 TopicsConcerning 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-Connection managementThe 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.
-
Provider-Customer interface-Queue managementThe 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
-
AirspaceStatusProviderThis Service Interface exposes the technical operation that allows the consumer (operational supervisor, technical supervisor...) to get the current state of Airspace status data on request. It is typically used when starting the Service, for initialisation.PROVIDER_SIDESYNCHRONOUS_REQUEST_RESPONSE
-
getAirspaceStatusIf airspaceStatusRequested is filled, this operation allows a consumer to get the applicable airspace status data related to all the relevant airspaces (ARES and/or CDR according to its request).If airspaceName is filled, this operation allows a consumer to get the applicable airspace status data related to the designated airspace (ARES or CDR)..gitMessages
-
GetAirspaceStatusIN
-
AirspaceListOUT
-
EndpointsRestricted
-
-
AirspaceStatusSubscriberThis service Interface exposes the operations for publishing on-line updates of Airspace Status data on a specific airspace immediately when updated.PROVIDER_SIDEFIRE_AND_FORGET
-
publishARESStatusIn case of dynamic modification of an ARES activation status, this operation performs the publication of the new status and data related to the updated ARES to the subscribed service consumers..gitMessages
-
ARESStatusNotificationIN
-
voidOUT
-
-
publishCDRStatusIn case of dynamic modification of a CDR status, this operation performs the publication of the new status and data related to the updated CDR to the subscribed service consumers.The publication message contains the description of the status of the given CDR.The CDR status is based on 2 attributes of the publication message:-cdrStatus (its value is Open or Closed)-cdrLockStatus (its value is Locked or Unlocked)cdrStatus is provided only if cdrLockStatus is Locked. If cdrLockStatus is Unlocked, the Open/Closed status of the CDR can be deduced from the timetable..gitMessages
-
CDRStatusNotificationIN
-
voidOUT
-
EndpointsRestricted
-
-
AirspacePlanningSubscriberThis Service Interface exposes the operations for publishing on-line updates of Airspace planning data on a specific airspace immediately when updated.PROVIDER_SIDEFIRE_AND_FORGET
-
publishARESPlanningIn case of dynamic modification of an ARES planning, this operation performs the publication of the new or updated planning of this ARES to the subscribed service consumers.The publication message contains the description of the planning of the given ARES (upper and lower flight levels, timesheet period, periodicity, ...)..gitMessages
-
AirspacePlanningNotificationIN
-
voidOUT
-
-
publishCDRPlanningIn case of dynamic modification of a CDR planning, this operation performs the publication of the new or updated planning of this CDR to the subscribed service consumers.The publication message contains the description of the planning of the given CDR (the Open/Closed status, upper and lower flight levels, timesheet period, periodicity, ...)..gitMessages
-
AirspacePlanningNotificationIN
-
voidOUT
-
EndpointsRestricted
-
-
AirspacePlanningProviderThis Service Interface exposes the technical operation that allows the consumer (operational supervisor, technical supervisor...) to get the current state of Airspace planning data on request. It is typically used when starting the Service, for initialisation.PROVIDER_SIDESYNCHRONOUS_REQUEST_RESPONSE
-
getAirspacePlanningIf airspaceStatusRequested is filled, this operation allows a consumer to get the applicable airspace planning data related to all the relevant airspaces (ARES and/or CDR according to its request).Only the ARES and CDR having at least 1 timesheet are received as a response to this request.If airspaceName is filled, this operation allows a consumer to get the applicable airspace planning data related to the designated airspace (ARES or CDR).If the designated airspace doesnt have any timesheet, no airspace planning data is received..gitMessages
-
GetAirspacePlanningIN
-
AirspacePlanningListOUT
-
EndpointsRestricted
-
-
CCS AIRM mapping ASD serviceAIRM traceability for CCS Airspace Status Distriubtion service payloadAIRM_TRACE1.0
-
CCS Validation evidence document - AirspaceStatusDistributionValidation evidence for CCS Airspace Status Distribution serviceSERVICE_VALIDATION_REPORT1.0
-
CCS_airspaceStatusDistribution.protoProtobuf files describing the exchanged informationMACHINE_READABLE_SERVICE_DESCRIPTION3.1.1.1
-
CCS_common.protoProtobuf file describing the exchanged information common to two or more CCS ServicesMACHINE_READABLE_SERVICE_DESCRIPTION5.5.1.2
-
metadata.protoProtobuf file describing the metadata used by the CCS ServicesMACHINE_READABLE_SERVICE_DESCRIPTIONv1.2.0.0
-
CCS Airspace Status Distribution Service DescriptionComplete service specificationSERVICE_SPECIFICATION3.1.1.3
-
CCS Errors Management DocumentDocument that includes the list of all applicable error messages for CCS servicesSERVICE_SPECIFICATION2.0
EUROCONTROL Specification for SWIM - Service Description
EUROCONTROL_SPECIFICATION_FOR_SWIM_SERVICE_DESCRIPTION
Description of Service according to EUROCONTROL specifications
2.0
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
EUROCONTROL_SPECIFICATION_FOR_SWIM_INFORMATION_DEFINITION
Information definition according to EUROCONTROL specifications
1.0
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.
EUROCONTROL Specification for SWIM - Technical Infrastructure (TI) Yellow Profile
EUROCONTROL_SPECIFICATION_FOR_SWIM_TECHNICAL_INFRASTRUCTURE
Implementation of service and network bindings
1.0
This specification contains requirements for system interfaces (e.g. protocols) and for IT infrastructure capabilities required to enable a reliable, secure and efficient exchange of information in the context of Initial System Wide Information Management (iSWIM).This contributes to technical interoperability