Service Description

 

 

services.avinor.no

Avinor Daily Traffic Survey Service

 

 

Until this note is removed the documentation is a work in progress, and revisions to the documentation will not be tracked.

 

Namespace: http://services.avinor.no/webservices/1.0/AvinorDailyTrafficSurveyService

 

Document revisions

Date

Description

Author

yyyy-mm-dd First complete version of the documentation
Ole Nymoen

 

 

 

 

1. Introduction

1.1. Overview

This service description defines one service with a one operation to set DTS (Daily Traffic Survey) data. All operators on any Avinor airport are required to make DTS data available to Avinor, as defined in the "Forskrift om avgifter for bruk av lufthavner drevet av Avinor AS"

All data elements are defined by the Airport Data Dictionary.

The service is primarily designed to be used by airlines and handlers.

NB! This is an Avinor specific service to support invoicing of airlines. It is not expected to be implemented by other airport owners.

1.2. Implementation

The service is implemented by Avinor and is available upon request.

1.3. Purpose of this service description

This service description has the following purpose:

      • Describe the service so that a client (of this service) developer can use it.
      • Make available the WSDL and XSD files necessary to 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 use it or not.

1.4. Intended readership

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

2. Service overview

The figure below shows the available operations on the AvinorDailyTrafficSurveyService. The operations are described in detail in Service operations.

3. Service operations

3.1. SubmitDTSData( transData : TransData, dtsData : DTSData)

Submits the DTS (Daily Traffic Survey) data for further processing.

4. Data entities

4.1. DTSData

The DTSData entity must contain either the IATA based keys (FlightId, DepartureAirportIATA, ArrivalAirportIATA) or the ICAO based keys (Callsign, DepartureAirportICAO, ArrivalAirportICAO), or both. Both data sets are preferred. Please provide as much data as possible.

DTSData describes one flight leg with the following information (high level):

  • Identification of the flight leg
  • Identification of the aircraft
  • Information about which kind of flight this is
  • Number of passengers and crew on board at departure
  • Number of passengers boarding and number of passengers disembarking at the arrival airport
  • Number of passengers that sat in the aircraft from the previous flight leg (transit passengers)
  • The weight of cargo and mail loaded onto the aircraft at the departure airport
  • The weight of cargo and mail unloaded at the arrival airport. This might be different from loaded on multi leg flights.
ADD element Description
FlightId 
IATA based identifier for this flight, usually issued long before the flight actually takes place.

FlightId is normally the concatenation of OperatingAirlineIATA, FlightNumber and OperationalSuffix.

FlightId typically identifies a flight to the majority of systems, but it is not unique across time. It's unique only in conjunction with FlightDepartureDate.

Exception: Some airlines use their ICAO code (OperatingAirlineICAO) instead of OperatingAirlineIATA. This might be because they aren't an IATA member or because they just prefer the ICAO code. Regardless, this means that it is allowed to use OperatingAirlineICAO as part of FlightId.

FlightId is then defined as the concatenation of AirlineIATAorICAO, FlightNumber and OperationalSuffix.
Callsign
A call sign is used to uniquely identify an aircraft using the airspace around a particular airport.  Call signs in aviation are derived from several different policies, depending upon the type of flight operation. In most countries, unscheduled general aviation flights identify themselves using the call sign corresponding to the aircraft's registration number.  Commercial operators, including scheduled airline, air cargo and air taxi operators, will usually use an ICAO or FAA-registered call sign for their company. These will typically consist of the ICAO code of the operating airline followed by a flight identification.  The flight identification is very often the same as the flight number, but could be different due to call sign confusion, if two or more flights close to each other have similar flight numbers (i.e. KLM649 and KLM645 or BAW466 and BAW646).
FlightDepartureDate
The scheduled date (based on UTC) of departure of flight. For flights with multiple legs this is the departure of the first leg. This date must not change once set as it is used to make the FlightIds unique.
DepartureAirportIATA
Departure airport IATA code (see AirportIATA for description of term).
ArrivalAirportIATA
Arrival airport IATA code (see AirportIATA for description of term).
DepartureAirportICAO
Departure airport ICAO code (see AirportICAO for description of term).
ArrivalAirportICAO
Arrival airport ICAO code (see AirportICAO for description of term).
FlightDIIndicator
Indicator showing what kind of flight (domestic, international, Schengen) this is. See also: AirportDIIndicator.
SOBT
Scheduled Off-Block Time. The time that an aircraft is scheduled to depart from its parking position. Always UTC time.
AOBT
Actual Off-Block Time. Time the aircraft pushes back / vacates the parking position. (Equivalent to Airline / Handlers ATD – Actual Time of Departure & ACARS=OUT). Always UTC time.
SIBT
Scheduled In-Block Time. The time that an aircraft is scheduled to arrive at its first parking position. Always UTC time.
AIBT
Actual In-Block Time. The time that an aircraft arrives in-blocks. (Equivalent to Airline/Handler ATA –Actual Time of Arrival, ACARS = IN). Always UTC time.
AircraftRegistration 
An aircraft registration is a unique alphanumeric string that identifies an aircraft. In accordance with the Convention on International Civil Aviation all aircraft must be registered with a national aviation authority and they must carry proof of this registration in the form of a legal document called a Certificate of Registration at all times when in operation.

An aircraft can be re-registered in special cases, for instance if it's sold to an operator in another country.
FlightServiceTypeIATA
IATA SSIM Appendix C Service Types.
FlightServiceTypeExtended
Installation/customer specific set of flight service types. Typically used when the defined set in FlightServiceType isn't specific enough. Encoded as integer to clearly separate it from FlightServiceType.
PersonsOnboard
All persons on board the plane. Often known as souls on board.

PersonsOnboard = CrewActiveOnBoard + PaxSeatedOnBoard + PaxInfantOnBoard
CrewActiveOnBoard
Number of working crew members (cockpit, cabin and jump seat) on board the aircraft.
CrewPassiveBoarding
Number of passive crew boarding the aircraft. Often called "DHC" (Dead Head Crew). Included in PaxAdultBoarding.
DutyTravelBoarding
Number of duty travelers (employees of the relevant airline on business trip) boarding the aircraft. Included in PaxAdultBoarding.
PaxInfantBoarding
The number of infants boarding the plane.
PaxBoarding
The number of "seated passengers" boarding the aircraft, infants excluded.
PaxBoarding = PaxAdultBoarding + PaxChildBoarding 
PaxTransferBoarding
The number of transfer passengers boarding the flight. These passengers are also included in the PaxBoarding number.
PaxTransit

PaxTransit is the number of passengers that were transit-passengers at the start of the flight leg defined by DTSData.
PaxDisembarking
The number of passengers and passive crew disembarking the plane, infants excluded.
PaxDisembarking = PaxAdultDisembarking + PaxChildDisembarking
PaxInfantDisembarking
The number of infants disembarking the plane.
CargoWeightLoaded Cargo weight loaded at the departure airport.
CargoWeightUnloaded Cargo weight unloaded at the arrival airport.
MailWeightLoaded Mail weight loaded at the departure airport.
MailWeightUnloaded Mail weight unloaded at the arrival airport.

4.2. ResponseStatus

4.3. ResponseStatus
statusCode : ResponseStatusCode

ResponseStatusCode indicates if the operation succeeded or failed, and if it failed - why. ResponseStatusText is a textual description of ResponseStatusCode. For all operations the set of response codes must be defined. The actual set is dependent upon the context.

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

    5. XML Usage

    5.1. Nil Values in Schema

    For any particular data element, there is an important distinction between the following cases:

    (a) the element is missing
    (b) the element is present but has a 'nil' attribute assigned to it

    In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.

    In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.

    The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.

    Message contents

    Expected action by recipient

    aircraftRegistration element missing

    Does not set or change aircraft registration value

    <aircraftRegistration>ABC123</aircraftRegistration>

    Sets the value to ABC123

    aircraftRegistration element missing

    Does not change the value

    <aircraftRegistration xs:nil=’true’>

    Clears the aircraftRegistration value

    Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.

    Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.

    6. WSDL and XSDs

    File Created Comment

    avinor-daily-traffic-survey-service-3.9.0.zip

    		 2021-04-22 14:43  

    7. Examples

    7.1. Introduction

    The following are example invocations of the service.

    7.2. Example SOAP templates

    7.2.1. xxxx SOAP template

    xxxx SOAP template 
    <soapenv:Envelope
   
</soapenv:Envelope>


    • No labels