Service Description



asrv.aero

Flight Data Submit Service v 2.0



Namespace: http://www.asrv.aero/webservices/2.0/FlightDataSubmitService/


Previous versions

Document revisions

Date

Description

Author

2022-05-22First complete version of the documentation.

Ole Nymoen

2024-10-04SubmitRmsData has been added. 

Ole Nymoen 

2024-10-04AtmData has been changed. TouchAndGoData added.

Ole Nymoen 




1. Service facts

2. Introduction

2.1. Overview

This service description defines one service with a set of operations to submit flight leg oriented data. All flight related data elements are defined by the Airport Data Dictionary.

The service is primarily designed to meet the need of airport partners, but availability is the decision of the service provider.

Version 2.n of FDSS is implemented as a REST service. Previous versions were SOAP based.

2.2. Implementation considerations

Any implementation of this service MUST use the XSD files provided here: XSDs

It is however up to the service provider which data elements to support, and how to prioritize between data sources. The reason for a service provider to not support all elements might be business rules related to updating data, that it doesn't use the information, or that it wants the information updated in other (more restricted) ways.

Any service provider should make available documentation about the actual implementation, including:

    • the address of the service.
    • any limitations in the implementation.
    • recommended and allowed polling intervals.

2.3. Purpose of this service description

This service description has the following purpose:

      • Describe of service in enough detail for a service provider to implement it.
      • Describe the service so that a client (of this service) developer can use it.
      • Make available the XSD files necessary to implement and use the service.
      • Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available functionality and then to decide if to implement/use it or not.

2.4. Intended readership

    • IT architects
    • Developers
    • Business architects
    • Interested parties in the aviation community

3. Service overview

The figure below shows the available operations on the Flight Data Submit Service v 2.0. The operations are described in detail in Service operations. 

The operations can submit a variety of flight leg oriented data, as indicated by the service operations.

The service uses the following HTTP return codes:

In addition standard HTTP return codes might be used, typically generated by frameworks.

4. Service operations

4.1.1. SubmitAtmData ( AtmDataIn )

Submits ATM specific flight leg data (AtmData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

4.1.2. SubmitBaggageData ( BaggageDataIn )

Submits baggage data (BaggageData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

4.1.3. SubmitCheckInData ( CheckInDataIn )

Submits check-in data (CheckInData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

4.1.4. SubmitFlightLegData ( FlightLegDataIn )

Submits general flight leg data (FlightLegData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

4.1.5. SubmitGateData ( GateDataIn )

Submits gate data (GateData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

4.1.6. SubmitRmsData ( RmsDataIn )

Submits RMS data (RmsData). 

Parameters

Returns

  • 200 OK if everything went well. The data is sent on for further processing.
  • 400 Bad Request if there were any issues with the input data. The text string returned will give more information about the actual problem.
  • Other error/warning returns are possible.

5. Data entities

5.1. AtmData
UniqueFlightLegId If UniqueFlightLegId is included it is used as the only identification element. It must have been received previously by data from the airport system responsible for allocating it, typically an AODB.

IFPLID
If UniqueFlightLegId isn't available.
Strongly preferred if available, but must be used with other identifiers like Callsign, DepartureAirportICAO, ArrivalAirportICAO and some of the time elements.
Callsign
If UniqueFlightLegId isn't available.
Strongly preferred if available, but must be used with other identifiers like IFPLID, DepartureAirportICAO, ArrivalAirportICAO and some of the time elements.
AircraftRegistration
Strongly preferred if available, but must be used with other identifiers like IFPLID, DepartureAirportICAO, ArrivalAirportICAO and some of the time elements.
NILABLE
SSRCode
NILABLE
DepartureAirportICAO
Required if available.
ArrivalAirportICAO
Required if available.
AtmCdmStatus

AtmFlightLegStatus

FlightLegStatus

AircraftInZone
NILABLE
TSAT
NILABLE
TOBT
NILABLE
IOBT
NILABLE
Required if available.
EOBT
NILABLE
Required if available.
AOBT
NILABLE
EXOT
NILABLE
AXOT
NILABLE
CTOT
NILABLE
ETOT
NILABLE
ATOT
NILABLE
ELDT NILABLE
Required if available.
ELDTAccuracy

NILABLE

ALDT
NILABLE
EXIT
NILABLE
AXIT
NILABLE
EIBT
NILABLE
Required if available.
AIBT
NILABLE
AircraftICAOType
NILABLE
WakeTurbulenceCategory
NILABLE
OperatingAirlineICAO
NILABLE
FlightServiceTypeICAO
NILABLE
FlightServiceTypeExtended 
NILABLE
MilitaryFlightOwner
NILABLE
NumberOfAircraft
NILABLE

TouchAndGoData

 To remove touch&go data set the TouchAndGoCount to '0' (zero) for the given airport.

NILABLE
FlightRule
NILABLE
SIDRoute
NILABLE
STARoute
NILABLE
RunwayDeparture
NILABLE
RunwayArrival
NILABLE
DiversionAirportICAO

NILABLE

DiversionAirportICAO is the airport the flight diverted from. A value here means that the aircraft has been diverted. ArrivalAirportICAO further up is the new destination for this flight leg.




5.2. AtmDataIn

TransData
AtmData


5.3. BaggageData

Identification

If UniqueFlightLegId is included it is used as the only identification element. It must have been received previously by data from the airport system responsible for allocating it, typically an AODB.

Required if UniqueFlightLegId isn't included.

Required if UniqueFlightLegId isn't included.

Required if UniqueFlightLegId isn't included.

Strongly preferred if UniqueFlightLegId isn't included.

Departure baggage data 
NILABLE
NILABLE
NILABLE
  • BaggageBinData
 NILABLE



Arrival baggage data
NILABLE
NILABLE
NILABLE
NILABLE
NILABLE
NILABLE


BaggageBinData



5.4. BaggageDataIn

TransData

BaggageData


5.5. CheckInData

Contains the data elements to set check-in data.

Identification

If UniqueFlightLegId is included it is used as the only identification element. It must have been received previously by data from the airport system responsible for allocating it, typically an AODB.
Required if UniqueFlightLegId isn't included.
Required if UniqueFlightLegId isn't included.
Required if UniqueFlightLegId isn't included.
Strongly preferred if UniqueFlightLegId isn't included.
Check-in data
NILABLE
NILABLE
NILABLE
NILABLE


5.6. CheckInDataIn

TransData

CheckInData


5.7. ArrivalData

AircraftParkingPositionArrival

NILABLE
PaxCanDisembark NILABLE
PaxBusIsNeededArrival NILABLE
PaxBusRemarkArrival NILABLE
FlightIsDomesticTransfer NILABLE
ELDT
NILABLE
TLDT NILABLE
ALDT NILABLE
SIBT NILABLE
EIBT NILABLE
AIBT NILABLE


5.8. DepartureData
AircraftParkingPositionDeparture
PaxCanEmbark
PaxBusIsNeededDeparture
PaxBusRemarkDeparture NILABLE
ASBT
ASRT NILABLE
ASAT NILABLE

ARDT
NILABLE
SOBT
EOBT NILABLE
AOBT NILABLE
ETOT
NILABLE
TTOT NILABLE
ATOT
FuelRampRequested NILABLE


5.9. FlightLegData

UniqueFlightLegId

IFPLID

Callsign
FlightId
FlightDepartureDate
AircraftRegistration NILABLE
AircraftIATAType NILABLE
DepartureAirportIATA
ArrivalAirportIATA
departureData See DepartureData
arrivalData See ArrivalData
OperatingAirlineIATA
OperatingAirlineICAO
OperatingAirlineName
FlightServiceTypeIATA
FlightServiceTypeExtended


5.10. FlightLegDataIn

TransData
FlightLegData


5.11. GateData

Contains the data elements to set gate data.

Identification

If UniqueFlightLegId is included it is used as the only identification element. It must have been received previously by data from the airport system responsible for allocating it, typically an AODB.
Required if UniqueFlightLegId isn't included.
Required if UniqueFlightLegId isn't included.
Required if UniqueFlightLegId isn't included.
Strongly preferred if UniqueFlightLegId isn't included.
Gate data

Required.

NILABLE
NILABLE
NILABLE
NILABLE
NILABLE
NILABLE


5.12. GateDataIn

TransData

GateData


5.13. RmsData

Resource Management Data in this setting is data a RMS / Apron Management / Aircraft Parking system updates for one flight leg. A RMS system is by nature airport oriented and will often operate on turnarounds. In this setting it's usual to update two flight legs, the inbound flight leg and the outbound flight leg.

Please remember that arrival and departure data on a flight leg is on two airports, but when viewed as a turnaround arrival and departure data is on the same airport, but on two flight legs.

A RMS system will typically only update:

  • Arrival data, including linked departure, for the incoming flight leg.
  • Departure data, including linked arrival, for the outgoing flight leg.

Contains the data elements to set RMS data.

Identification

UniqueFlightLegId
UniqueFlightLegId is required to identify the relevant flight leg. 
NB! This will be either the inbound flight leg or the outbound flight leg of a turnaround.

Departure data Departure data for the outgoing flight leg. If used, arrival data is not expected to be present.
GateDeparture NILABLE
AircraftParkingPositionDeparture NILABLE
UniqueFlightLegIdLinkedArrival NILABLE
Arrival data Arrival data for the incoming flight leg. If used, departure data is not expected to be present.
GateArrival NILABLE
AircraftParkingPositionArrival NILABLE
UniqueFlightLegIdLinkedDeparture NILABLE


5.14. RmsDataIn

TransData
RmsData


5.15. TransData
CorrelationId
Identifier that can be used to correlate messages, transactions, log entries etc. The identifier should be unique across all relevant systems. It is the responsibility of the creator of the message/transaction/log entry/...  to guarantee uniqueness. The CorrelationId can for instance be a GUID, or something shorter based on site specific rules.
SourceOrganization
Name of the organization/company that created the original data. This will typically be an airline company or an handler. The value set are site specific.

SourceTimestamp
UTC timestamp for when the source was updated. If unknown, use current (UTC) time.
SourceData
SourceData will only exist when the source data is something else than XML or JSON. SourceData will typically be the IATA message or an EFD message from Eurocontrol.


6. XSDs


File Created Comment

FlightDataSubmitService_v2_3.107.1.zip

 2024-10-29 17:53  

FlightDataSubmitService_v2_3.108.0.zip

 2024-11-08 08:53 kommentar

flight_data_submit_service_2_0.zip

 2022-08-11 10:16  


  • No labels