DSNA&ENAV
DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
CCS FlightDataDistribution 2.0.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 FlightDataDistribution service is consistent with the other CCS services. It supports: - the distribution of Flight Plan information every time an update of a relevant Flight Plan is processed by the ADSP. The modifications of the Flight Plans can be triggered from several sources (other CWPs or functionality of the ADSP). - The distribution of Erroneous AFTN messages information referred to FDO for manual correction, every time an AFTN message reception fails Coflight checks. Note: Only civil flights are handled by CCS services. 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
Business Activity Type
INFORMATION_MANAGEMENT
Intended Consumer
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Information Exchange Category
FLIGHT_INFORMATION_EXCHANGE
In-Operation Date
01-Jul-2020
Provider
Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Point of Contact
General
Operational Needs
CCS FlightDataDistribution Service supports:
- the distribution of Flight Plan information every time an update of a relevant Flight Plan is processed by the ADSP,
- the distribution of Erroneous AFTN messages information every time an AFTN message reception fails Coflight checks.
Functionality
Publish flight data
Publish erroneous AFTN messages
Get erroneous AFTN messages
Get flight data
Access and Use
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.
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.
This service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities
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.
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.
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.
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.
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
Abbreviations
Advanced Boundary Message
Airspace Configuration
Area Control Centre
ATC Change Message (ICAO format, CFMU special)
Accept Message
Activate Message
Airport of Departure
Airport of Destination
ATS Data Exchange Presentation
Automatic dependent surveillance
ATM Data Service Provider
Abbreviated Flight Plan
Aeronautical Fixed Telecommunication Network
ATM Information Reference Model
Alerting Service
Advanced Message Queuing Protocol
Air Navigation Service Provider
Area Of Interest
Approach
ATC Flight Plan Message (ICAO)
Airport Operator
Approach
Authorisation Required
Arrival
Air Traffic Control
Air Traffic Control Officer
Air Traffic Control Services
Actual Time of Departure
Air Traffic Flow and Capacity Management
Automatic Tracking Initiation
Air Traffic Management
Aeronautical Telecommunication(s) Network
Actual Time Over
Actual Take-Off Time
Air Traffic Services
Air Traffic Service Unit
Coflight Cloud Services
Coordination Message
Conditional Route
Cleared Flight Level
ICAO ATS Change Message
Consolidated Logical Data Model
ICAO ATS Cancel Message
Change of Frequency Message
Coordination Point
Correlation Distribution
Controller Pilot Datalink Communications
Controller Working Position
Dialogue and Distribution
Demand and Capacity Balancing
Direct Routing
Departure
ICAO ATS Delay Message
Date of Flight
Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)
Extended ATC Planner
European ATM Architecture
En-Route Cruise Level
Estimated Elapsed Time
Entry Flight Level
Ente Nazionale Assistenza al Volo (Italian ANSP)
Environment
Estimated Off-Block Date
Estimated Off-Block Time
Equipment
Estimated Time of Arrival
Estimated Time of Entry
Estimated Time of Exit
Functional Airspace Block
Future Air Navigation Systems
Flight Data Distribution
Flight Data Management
Flight Data Operator
Flight Data Processing System
Flight Level
Flight Notification Message
Flight Plan
Flight Plan Message (ICAO)
General Air Traffic
Ground Ground Data Communications
human machine Interface
Hand Over Proposal message
Individual ATC Modification Message
Instrument Approach Procedure
Individual ATC Flight Plan Message
Individual Arrival Message
Indicated Airspeed
International Civil Aviation Organization
Interface Control Document
Individual Modification Message
Individual Cancellation Message
Identifier
Individual Departure Message
Individual Delay Message
Interface Exchange Requirement
Individual Flight Plan Message
Integrated initial flight plan processing system
Instrument Flight Rules
Internet Key Exchange
Integrated Network Management and ATC planning
Interoperability
Internet Protocol
Internet Protocol Security protocol
Internet Protocol version 4
Joint Undertaking
Key Performance Indicator
Logical Acknowledgment Message
Letter of Agreement
Logon Forward
Logical Position
Local Traffic Manager
Manual Assumption of Communications Message
Mega byte
Message Exchange Pattern
Multi-sector area
Medium Term Conflict Detection
Next Data Authority
Network Manager
Network Operation Plan
Network Time Protocol
Operational Air Traffic
Oceanic Control Area
Oceanic Clearance
Oceanic Clearance Message
Online Certificate Status Protocol
Operational Entity
On-line Data Interchange
Preliminary Activate Message
Performance Based Navigation
Public-Key Cryptography Standards
Profile
Planned time of Arrival
Requested Flight Level
Reject Message
Area Navigation
Rate of Climb
Rate of Climb Descend
Request on Frequency
Repetitive Flight Plans
Request Tactical Instructions message
Reduced Vertical Separation Minima
System Area Code
Service Definition Document
Supplementary Data Message
Single European Sky Air Traffic Management Research
System Flight Plan
System Identification Code
Standard Instrumental Departure
Service Level Agreement
SWIM Service Description
Synchronous Serial Interface
Secondary Surveillance Radar
Secondary Surveillance Radar Management
Standard Arrival Route
System Wide Information Management
To Be Confirmed
To Be Defined
Transfer Control Protocol
Technical Infrastructure
Transfer Initiation Message
Tactical Instructions Proposal message
transport level security
Trajectory Prediction
Ultra High Frequency
Coordinated Universal Time
Virtual Centre
Visual Flight Rules
Vertical Rate Climb Descent
Exit Flight Level
Information
Information Definition
For the exchanged data model, please refer to the SWIM Service Description document (sections 2.1 and 2.2)
Data Structures
Schema Language
Protocol buffer
Reference
CCS_flightDataDistribution.proto 5.2.0.2
Schema Language
Protocol buffer
Reference
CCS_flightDataDistribution.proto 5.2.0.2
Schema Language
Protocol buffer
Reference
CCS_flightDataDistribution.proto 5.2.0.2
Schema Language
Protocol buffer
Reference
CCS_flightDataDistribution.proto 5.2.0.2
Schema Language
Protocol buffer
Reference
CCS_flightDataDistribution.proto 5.2.0.2
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 shall use, each of them, at least one NTP server (stratum N), integrated in a NTP network containing a stratum 0 reference time clock. CCS customer may use a CCS provider server as a NTP server, however this usage is restricted to time synchronization test or monitoring purpose.
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, if any, defined for the 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.
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
Interfaces
This Service Interface exposes one operation for publishing updates of flight plan data on a specific flight immediately when updated.
Operations
This operation sends the flight plan data of a flight when it is updated..
Synchronous
ASYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
Endpoints
Url
For security reasons, the addresses will be communicated only to Customers
Addressable Resource
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.
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
This Service Interface exposes one operation for publishing the erroneous AFTN message information for FDO correction.
Operations
This operation sends the erroneous AFTN messages information for FDO correction.
Upon reception of an AFTN erroneous message associated to a given SFPL, this message is referred to FDO.
Only the following AFTN messages are referred to FDO by CCS (the other are not yet within the scope of PJ16): ACH, APL, ARR, CHG, CNL, DEP, DLA, FPL, IACH, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL.
The consumer can receive two other kinds of referred message: blocked and not checked.
The information referralType is used to differentiate an erroneous message referred for correction from a message "blocked" by FDM since an erroneous message for the same SFPL was already referred to FDO.
Synchronous
ASYNCHRONOUS
Precondition
The consumer has to define off-line the priority for each kind of external message:
- 1: the message is referred.
- 0: the message is not referred.
- 1: the message is referred.
- 0: the message is not referred.
TI Protocol Methods
transfer
Operation Message
Endpoints
Url
For security reasons, the addresses will be communicated only to Customers
Addressable Resource
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.
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
This Service Interface exposes the technical operation that allows the consumer to get the current flight plan data of all flights on request. It is typically used when starting the Service, for initialisation.
Operations
Allows a consumer to get the applicable flight plan data related to all relevant flights concerning this consumer.
In the request, the parameter oe allows to filter the flights to be received in return (the criteria is fulfilled if oe is part of the list of servedController.controller.identifier for the flight). If no oe is filled, no fliter is applied to the response (all flights known by the system are expected). The parameter wpId is ignored by CCS..
Synchronous
SYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
Processing Consideration
Endpoints
Url
For security reasons, the addresses will be communicated only to Customers
Addressable Resource
Name of the queue
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.
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
This Service Interface exposes two technical operations that allows the consumer to get the erroneous AFTN message information for FDO correction, on request. It is typically used when starting the Service, for initialisation.
Operations
Allows a consumer to get the erroneous AFTN messages referred to FDO for manual correction, either for a specific erroneous message by filling the messageId, or all the erroneous messages if the messageId attribute is empty.
Refer to publishErroneousAFTNMessageData description for more details about the list of errors that can be enc.
Synchronous
SYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
Allows a consumer to get the summary of erroneous AFTN messages referred to FDO for manual correction.
Refer to publishErroneousAFTNMessageData description for more details about the list of errors that can be encountered
.
Synchronous
SYNCHRONOUS
TI Protocol Methods
transfer
Operation Message
Endpoints
Url
For security reasons, the addresses will be communicated only to Customers
Addressable Resource
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.
Behaviour
The detailed behavior of the service is provided in each operation dedicated section
References
Service Documents
AIRM traceability for CCS Flight Data Distribution service payload
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Note: to request access to Confluence, please refer to the point of contact section
Note: to request access to Confluence, please refer to the point of contact section
Validation evidence for CCS Flight Data Distribution service
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Note: to request access to Confluence, please refer to the point of contact section
Note: to request access to Confluence, please refer to the point of contact section
Protobuf files describing the exchanged information
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Protobuf file describing the exchanged information common to two or more CCS Services
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Protobuf file describing the metadata used by the CCS Services
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Complete service specification
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Flight+Data+Distribution+Service
Document that includes the list of all applicable error messages for CCS services
Reference
https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+Documents
Implemented Standards
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
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.
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
Revision Save Date
Mon, 03/25/2024 - 23:20
The service description has currently reached the "PUBLISHED" status.
Schema version
v2