CCS FlightDataManagement

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 FlightDataManagement service is consistent with the other CCS services. It addresses the CWP manual interactions for managing Flight Plan updates related to inputs made by the controller or by the Flight Data Operator:

- The CWP can request several functions of this service to process controller inputs related to Initial Flight Plan Data.

- The CWP can request another functions of this service to process controller's instructions that modifies Flight Plan Data. - The FDO position can request the correction of AFTN messages.

- The CWP will receive a reply when the service request has been completed, indicating the status of the request.

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. Please note that the use of CCS FlightDataManagement service implies the use of CCS FlightDataDistribution Service to get the output Flight Plan Data.

Service retired from 20/03/2023

Categorisation

Service Type

SERVICE_DESCRIPTION

Life Cycle Stage

RETIRED

Business Activity Type

INFORMATION_MANAGEMENT

Intended Consumer

CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER

Information Exchange Category

FLIGHT_INFORMATION_EXCHANGE

Provider

DSNA&ENAV

Description

DSNA: the French air navigation service provider

ENAV; the Italian air navigation service provider

Type

CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER

Point of Contact

Restricted

Contact Information

Restricted

Name

1 General operational need

Description

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, Non tactical modifications and Segment regression, -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.

Name

Process a Cleared Flight Level instruction

Description

Process a Cleared Flight Level instruction

Real World Effect

The trajectory of the flight is updated accordingly.

Name

Process a Direct instruction

Description

Process a Direct instruction

Real World Effect

The trajectory of the flight is updated with the direct clearance.

Name

Process an en-route cruise Flight Level instruction

Description

Process an en-route cruise Flight Level instruction

Real World Effect

The trajectory of the flight is updated accordingly.

Name

Process an Entry Flight Level instruction

Description

Process an Entry Flight Level instruction

Real World Effect

The Exit Flight Level related to the concerned coordination is updated and the trajectory of the flight is updated.

Name

Process an Exit Flight Level instruction

Description

Process an Exit Flight Level instruction

Real World Effect

The Exit Flight Level related to the concerned coordination is updated and the trajectory of the flight is updated.

Name

Process a Heading instruction

Description

Process a Heading instruction

Real World Effect

The trajectory of the flight is updated with the heading clearance.

Name

Process a Holding instruction

Description

Process a Holding instruction

Real World Effect

The trajectory of the flight is updated with the holding clearance.

Name

Process a modification of Route

Description

Process a modification of Route

Real World Effect

The route and the trajectory of the flight are updated with the route amendment.

Name

Process a Requested Flight Level instruction

Description

Process a Requested Flight Level instruction

Real World Effect

The trajectory of the flight is updated accordingly.

Name

Process an ROCD instruction

Description

Process an ROCD instruction

Real World Effect

The trajectory of the flight is updated with the ROCD clearance.

Name

Process a Speed instruction

Description

Process a Speed instruction

Real World Effect

The trajectory of the flight is updated with the speed clearance.

Name

Process an abbreviated SFPL creation

Description

Process an abbreviated SFPL creation

Real World Effect

The APL is created.

Name

Process an SFPL cancelation

Description

Process an SFPL cancelation

Real World Effect

The SFPL status is set to TERMINATED.

Name

Process an SFPL creation

Description

Process an SFPL creation

Real World Effect

The SFPL is created in CCS.

Name

Process an SFPL deletion

Description

Process an SFPL deletion

Real World Effect

The SFPL is deleted from CCS.

Name

Process an SFPL update

Description

Process an SFPL update

Real World Effect

The impacted SFPL fields are updated in CCS.

Name

Process an SFPL(s) consultation request

Description

Process an SFPL(s) consultation request

Real World Effect

A summary of the SFPL(s) matching the given criteria are provided to the requestor.

Name

Process an AFTN message correction

Description

Process an AFTN message correction

Real World Effect

The corrected message is sent to the system for processing.

Name

Process an SFPL segment regression

Description

Process an SFPL segment regression

Real World Effect

The SFPL segment is turned from live or pending into monitored status.

Information ownership

IPRIn 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 ServiceThis 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.
Alignment to SESAR Virtual Centre activity

This service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities
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 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 monitoring

Services management reviews 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.

AC

Airspace Configuration
ACC

Area Control Centre
ACH

ATC Change Message (ICAO format, CFMU special)
ADEP

Aerodrome of Departure
ADES

Aerodrome of Destination
ADEXP

ATS Data Exchange Presentation
ADS

Automatic Dependent Surveillance
ADSP

ATM Data Service Provider
AFTN

Aeronautical Fixed Telecommunication Network
ALRS

Alerting Service
ALTN

ALTerNate (Aerodrome)
AMQP

Advanced Message Queuing Protocol
ANSP

Air Navigation Service Provider
AOI

Area Of Interest
APL

Abbreviated Flight Plan
APOC

Airport Operator
APP

Approach
ARR

Arrival
ATC

Air Traffic Control
ATCO

Air Traffic Control Officer
ATCS

Air Traffic Control Services
ATFCM

Air Traffic Flow and Capacity Management
ATM

Air Traffic Management
ATS

Air Traffic Services
ATSU

Air Traffic Service Unit
AWY

Airway
CCS

Coflight Cloud Services
CFL

Cleared Flight Level
CHG

ICAO ATS Change Message
CLDM

Consolidated Logical Data Model
CNL

ICAO ATS Cancel Message
COP

Coordination Point
CWP

Controller Working Position
DCB

Demand and Capacity Balancing
DCT

Direct Routing
DEP

Departure
DLA

ICAO ATS Delay Message
DOF

Date of Flight
DSNA

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

Extended ATC Planner
EATMA

European ATM Architecture
ECL

En-Route Cruise Level
EET

Estimated Elapsed Time
EFL

Entry Flight Level
ENAV

Ente Nazionale Assistenza al Volo (Italian ANSP)
EOBT

Estimated Off-Block Time
EQPT

Equipment
ETO

Estimated Time Over
FDD

Flight Data Distribution
FDM

Flight Data Management
FDO

Flight Data Operator
FDPS

Flight Data Processing System
FL

Flight Level
FNM

Flight Notification Message
FP

Flight Plan
FPL

Flight Plan
GAT

General Air Traffic
GEO

Geographical
HMI

human machine Interface
IACH

Individual ATC Modification Message
IAP

Instrument Approach Procedure
IAPL

Individual ATC Flight Plan Message
IARR

Individual Arrival Message
IAS

Indicated Airspeed
ICAO

International Civil Aviation Organization
ICD

Interface Control Document
ICHG

Individual Modification Message
ICNL

Individual Cancellation Message
ID

Identifier
IDEP

Individual Departure Message
IDLA

Individual Delay Message
IER

Interface Exchange Requirement
IFPL

Individual Flight Plan Message
IFR

Instrument Flight Rules
IKE

Internet Key Exchange
INAP

Integrated Network Management and ATC planning
IOP

Interoperability
IP

Internet Protocol
IPSEC

Internet Protocol Security protocol
IPV4

Internet Protocol version 4
JU

Joint Undertaking
KPI

Key Performance Indicator
LTM

Local Traffic Manager
MB

Mega byte
MEP

Message Exchange Pattern
MIME

Multipurpose Internet Mail Extensions
MSA

Multi-sector area
NOP

Network Operation Plan
NTP

Network Time Protocol
OAT

Operational Air Traffic
OCSP

Online Certificate Status Protocol
OE

Operational Entity
OLDI

On-Line Data Interchange
PBN

Performance Based Navigation
PKCS

Public-Key Cryptography Standards
RFL

Requested Flight Level
RNAV

Area Navigation
ROC

Rate of Climb
ROCD

Rate of Climb Descend
SDD

Service Definition Document
SESAR

Single European Sky Air Traffic Management Research
SFL

Supplementary Flight Level
SFPL

System Flight Plan
SID

Standard Instrument Departure
SLA

Service Level Agreement
SSD

SWIM Service Description
SSI

Synchronous Serial Interface
SSR

Secondary Surveillance Radar
STAR

Standard Instrument Arrival
SWIM

System Wide Information Management
TBC

To Be Confirmed
TBD

To Be Defined
TCP

Transfer Control Protocol
TI

Technical Infrastructure
TIP

Tactical Instructions Proposal message
TLS

transport level security
TP

Trajectory Prediction
UHF

Ultra-High Frequency
UTC

Coordinated Universal Time
VC

Virtual Centre
VFR

Visual Flight Rules
VRCD

Vertical Rate Climb Descent
XFL

Exit Flight Level

Name

Service Information Definition

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 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.
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, 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 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 management

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.
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

ATCCommandsManagementProvider

This Service Interface encompasses the different operations performed by the ATCO and modifying the Flight Plan Data. These operations can be divided in two sets of operations: the tactical instructions and the system inputs performed to modify the planed route:- ATC tactical Instructions: Holding, Heading, Speed, Cleared Flight Level (CFL),Rate Of climb/Descend (ROCD), Direct To and Cleared To,- System inputs: entry FL (EFL), exit FL (XFL), enCruiseFL (ECL) and requested Flight Level (RFL).

PROVIDER_SIDE

SYNCHRONOUS_REQUEST_RESPONSE
- requestProcessCFL
  
  Operation to process the input of a Cleared Flight Level given the flight identifier and the value of the level to be applied.The input may contain applicationStart data that can be a route point, distance before/after a route point or after current position..
  git
  Messages
  
  ClearedFlightLevel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessDirect
  
  Operation to process the input of a direct instruction given the flight identifier and the target point of the direct (not overflown point already belonging to the route). The input may contain application data that can be a route point, distance before/after a route point or after current position..
  git
  Messages
  
  ProceedDirectTo
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessHeading
  
  Operation to process the input of a heading clearance.It allows to assign either:-an absolute heading. To do this:-routePointId should not be filled-continueHeading should be either not filled or set to FALSE-either assignedHeading or application end point shoud be filled. If filled, the application end point should be expressed in the geographical point type-a relative heading. To do this:-routePointId should not be filled-continueHeading should be either not filled or set to FALSE-directionOfTurn and assignedHeading shoud be filled-a maintain order. To do this:-routePointId should not be filled-continueHeading should be set to TRUE-a resume own navigation order. To do this, routePointId should be filled..
  git
  Messages
  
  FlightHeading
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessRoute
  
  Operation to process the modification of a route portion for a specified flight. The input shall contain:-the flight identifier,-the new portion of route.The input may contain either an application end point (routePoint not overflown used to rejoin the old route) or a new destination aerodrome.The input may also contain application start data that can be a route point, distance after/before a route point, distance after current position..
  git
  Messages
  
  ClearedTo
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessSpeed
  
  Operation to process the input of a speed clearance..
  git
  Messages
  
  FlightSpeed
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessEFL
  
  Operation to process the input of the Entry Flight Level used for coordination between two logical positions.
  git
  Messages
  
  EntryFlightLevel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessXFL
  
  Operation to process the input of the Exit Flight Level used for coordination between two logical positions.
  git
  Messages
  
  ExitFlightLevel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessECL
  
  Operation to process the input of an En-Route cruise level (ATC planning constraint) given the flight identifier and the value of the level to be applied.
  git
  Messages
  
  EnRouteCruiseLevel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessRFL
  
  Operation to process the input of a Requested Flight Level given the flight identifier and the value of the level to be applied.
  git
  Messages
  
  RequestedFlightLevel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessROCD
  
  Operation to process the input of an ROCD (Rate Of Climb or Descent) instruction..
  git
  Messages
  
  ClearedROCD
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestProcessHolding
  
  Operation to process the input of a holding clearance a holding exit clearance or a holding cancellation clearance.The input shall contain the flight identifier..
  git
  Messages
  
  FlightHolding
  
  IN
  
  FlightDataManagementResponse
  
  OUT
Endpoints

Restricted
FlightPlanModificationManagementProvider

This Service Interface encompasses the different operations performed by the ATCO and modifying the Flight Plan Data: tactical instructions and system inputs performed to modify the planed route.

PROVIDER_SIDE

SYNCHRONOUS_REQUEST_RESPONSE
- requestCancelSFPL
  
  Operation to process the input of a manual SFPL cancellation..
  git
  Messages
  
  CancelSFPL
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestCreateAbbreviatedSFPL
  
  Operation to process the creation of an abbreviated SFPL. .
  git
  Messages
  
  CreateAPLInfo
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestCreateSFPL
  
  Operation to process the creation of a full SFPL whatever is the type of flight (OAT/GAT, VFR/IFR), according to the given initial FP fields..
  git
  Messages
  
  CreateSFPLInfo
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestDeleteSFPL
  
  Operation to process the deletion of a specified Flight Plan from ADSP.
  git
  Messages
  
  DeleteSFPL
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- requestRetrieveSFPL
  
  Operation to process an SFPL(s) consultation request..
  git
  Messages
  
  ConsultInfo
  
  IN
  
  FlightDataConsultationResponse
  
  OUT
- requestNonTacticalModification
  
  Operation to process the modification of one or several SFPL fields. The input shall contain the flight identifier, the originator and at least a field to modify.The fields that can be modified through this operation are related to static SFPL information (information of the SFPL independent of the modifications triggered by tactical instructions) such as: callsign aircraftIdentification (F7a), departureAerodromeDesignator (F13a), destinationAerodromeDesignator (F16a), flightType (F8b), flightRules (F8a), numberOfAircraft (F9a), aircraftTypeICAOIdentifier (F9b), wakeTurbulenceCategory (F9c), NCAEquipment (F10a), surveillance equipment (F10b), equipment status (F81), estimatedOffBlockTime (F13b), requestedFlightLevel (F15b), icaoRoute, enRouteCruiseSpeed (TAS or Mach) (F15a), totalEstimatedElapsedTime (F16b), alternativeDestinationAerodromeDesignator (F16c), ssrCodeData, otherInformation (F18), supplementaryInformation (F19), sidDesignator, starDesignator..
  git
  Messages
  
  NonTacticalModificationInfo
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- revertToPending
  
  Allows the operator to make a segment regression.It turns a controlled segment from live or pending status into monitored statusThe system keeps the segment in monitored state until a notification or activation message is received.The input shall contain the flight identifier, the segment identifier and optionally the segment entry time (estimated time over the segment entry point).When filled, the segment entry time adjusts the time estimates over the trajectory points.Caveat: The operation name (coming from SESAR) is misleading in CCS context..
  git
  Messages
  
  RevertToPending
  
  IN
  
  FlightDataManagementResponse
  
  OUT
Endpoints

Restricted
AFTNCorrectionManagementProvider

The AFTNCorrectionManagementProvider Service Interface manages the operations performed by the FDO to correct erroneous AFTN messages concerning in-coming flight plan that cannot be processed automatically by the system. It covers the following cases:-AFTN Modification messages: CHG, CNL, DLA, ARR, DEP (ICAO format), ICHG, ICNL, IDLA, IARR, IDEP, IACH (ADEXP format). In this case, it may be necessary to associate a FP to these messages to be able to correct them successfully.-AFTN Creation messages: FPL (ICAO format), IFPL, IAPL (ADEXP format).

PROVIDER_SIDE

SYNCHRONOUS_REQUEST_RESPONSE
- correctAFTNChange
  
  This operation allows the operator to correct the erroneous fields upon the reception of a CHG or ICHG message. Whenever a change is made to the data contained in a Flight Plan message already sent to the ATSUs concerned with the flight, they must all be notified. It is particularly important to notify changes of Flight Level or Flight Rules, whether the change is made before departure or en-route. Such notification may be done by phone or ATS/DS when possible; otherwise it must be done by means of a modification message sent to AFTN.The following CHG fields can be corrected through this operation:CHG content: callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), destinationAerodromeDesignator (F16a), totalEstimatedElapsedTime (F16b), otherInformation (F18), amendments of other ICAO fields (F22), alternativeDestinationAerodromeDesignator (F16c).In CHG, F22 should only amend F7b/c, F8, F9, F10, F13b, F14, F15, F16, F18, F19.The following ICHG fields can be corrected through this operation via decoded data: departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD),estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR).Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNChange
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNFlightPlan
  
  This operation allows the operator to correct the erroneous fields upon the reception of an FPL or IFPL message. The FPL message is the flight plan as filed with an ATS unit by the pilot or a designated representative, without any subsequent changes.The following FPL fields can be corrected through this operation:callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), flightRules (F8a), flightType (F8b), numberOfAircraft (F9a), aircraftTypeICAOIdentifier (F9b), wakeTurbulenceCategory (F9c), NCAEquipment (F10a), surveillance equipment (F10b), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), enRouteCruiseSpeed (TAS or Mach) (F15a), requestedFlightLevel (F15b), icaoRoute (F15c), destinationAerodromeDesignator (F16a), totalEstimatedElapsedTime (F16b), alternativeDestinationAerodromeDesignator (F16c), otherInformation (F18), supplementaryInformation (F19).The following IFPL fields can be corrected through this operation via decoded data: departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR). Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNFlightPlan
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNAbbreviatedFlightPlan
  
  This operation allows the operator to correct the erroneous fields upon the reception of an IAPL message (ICAO format message APL is not applicable CCS).The following IAPL fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR).Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNAPL
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNAirborneChange
  
  This operation allows the operator to correct the erroneous fields in the SFPL upon the reception of an IACH message (ICAO format message ACH is not applicable CCS). It is the modification message type distributed by the IFPS upon receipt and successful processing of an FNM, MFS, and AFP for which a valid associated flight plan exists in the IFPS.The following IACH fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR).Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNAirborneChange
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNArrival
  
  This operation allows the operator to correct the erroneous fields upon the reception of an ARR or IARR message. Where an Arrival message is required for an IFR/GAT flight or part thereof operating within the IFPZ, the appropriate air traffic services unit shall submit such to the IFPS for processingThe following ARR fields can be corrected through this operation:callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), destinationAerodromeDesignator (F16a), destinationAerodromeDesignator and actualLandingTime (F17), date of flight in otherInformation (F18).The following IARR fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), actualLandingTime (ATA), destinationAerodromeDesignator (ADARR)Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNArrival
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNCancel
  
  This operation allows the operator to correct the erroneous fields upon the reception of an CNL or ICNL message. When a schedule flight or a flight for which a Flight Plan Message has been sent, is subsequently cancelled, the ATSU at the point where the flight is cancelled shall send a Cancellation Message.The following CNL fields can be corrected through this operation:callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), destinationAerodromeDesignator (F16a), otherInformation (F18).The following ICNL fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE)Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNCancel
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNDelay
  
  This operation allows the operator to correct the erroneous fields upon the reception of an DLA or IDLA message. When a scheduled flight, or a flight for which a FPL was despatched, has not left the loading apron within 30 minutes after the scheduled or estimated time of departure; or where there is reason to believe that such a flight will not be in a position to leave within the 30 minutes due to the late arrival of the aircraft on the previous sector or for any other reason.The following DLA fields can be corrected through this operation:callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), destinationAerodromeDesignator (F16a), otherInformation (F18).The following IDLA fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR).Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNDelay
  
  IN
  
  FlightDataManagementResponse
  
  OUT
- correctAFTNDeparture
  
  This operation allows the operator to correct the erroneous fields upon the reception of a DEP or IDEP message. Departure message shall be sent immediately after take-off in respect of all flights for which a Flight Plan Message has been sent.The following DEP fields can be corrected through this operation:callsign aircraftIdentification (F7a), assignedSSRCode /Mode (F7b/c), departureAerodromeDesignator (F13a), estimatedOffBlockTime (F13b), destinationAerodromeDesignator (F16a), otherInformation (F18).The following IDEP fields can be corrected through this operation via decoded data:departureAerodromeDesignator (ADEP), destinationAerodromeDesignator (ADES), aircraftIdentification (ARCID), aircraftTypeICAOIdentifier (ARCTYP), NCAEquipment (CEQPT), estimatedOffBlockDate (EOBD), estimatedOffBlockTime (EOBT), fillingTime (FILTIM), ifplid (IFPLDID), numberOfAircraft (NBARC), surveillance equipment (SEQPT), dataSourceId (SRC), assignedSSRCode/Mode (SSRCODE), wakeTurbulenceCategory (WKTRC), totalEstimatedElapsedTime (TTLEET), flightRules (FLTRUL), flightType (FLTTYP), alternativeDestinationAerodromeDesignator (ALTRN1/2), icaoRoute (ROUTE), requestedFlightLevel (RFL), enRouteCruiseSpeed (SPEED / MACH), rtepts (RTEPTS), sidDesignator (SID), starDesignator (STAR), actualTakeOffTime (ATD)Other fields managed by this operation are included in specificADEXPField, otherInformation and supplementaryInformation, and listed in previous section "Operations"..
  git
  Messages
  
  CorrectAFTNDeparture
  
  IN
  
  FlightDataManagementResponse
  
  OUT
Endpoints

Restricted

CCS AIRM mapping FDM service

AIRM traceability for CCS Flight Data Management service payload

AIRM_TRACE

1.0
CCS Validation evidence document - FlightDataManagement

Validation evidence for CCS Flight Data Management service

SERVICE_VALIDATION_REPORT

1.0
CCS_flightDataManagement.proto

Protobuf files describing the exchanged information

MACHINE_READABLE_SERVICE_DESCRIPTION

5.1.0.4
CCS_common.proto

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

MACHINE_READABLE_SERVICE_DESCRIPTION

5.5.1.2
metadata.proto

Protobuf file describing the metadata used by the CCS Services

MACHINE_READABLE_SERVICE_DESCRIPTION

v1.2.0.0
CCS FlightDataManagement Service Description

Complete service specification

SERVICE_SPECIFICATION

5.3.0.7
CCS Errors Management Document

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

SERVICE_SPECIFICATION

2.0

Title

EUROCONTROL Specification for SWIM - Service Description

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_SERVICE_DESCRIPTION

Conformance Statement

Description of Service according to EUROCONTROL specifications

Version

2.0

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

Title

EUROCONTROL Specification for SWIM - Information Definition

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_INFORMATION_DEFINITION

Conformance Statement

Information definition according to EUROCONTROL specifications

Version

1.0

Description

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.

Title

EUROCONTROL Specification for SWIM - Technical Infrastructure (TI) Yellow Profile

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_TECHNICAL_INFRASTRUCTURE

Conformance Statement

Implementation of service and network bindings

Version

1.0

Description

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

CCS FlightDataManagement v 2.0.0

Categorisation

Provider