Service Description

 

 

asrv.aero

Helicopter Data Set Service

 

 

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

 

Namespace: http://www.asrv.aero/webservices/1.0/HelicopterDataSetService

 

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 an interface to set helicopter oriented data. All data elements are defined by the Airport Data Dictionary.

The service is primarily designed to meet the need of an helicopter operator/organizer to inform an airport of helicopter related activity.

While the entity definitions stay the same, the data they contain related to one flight will change as time goes by. Initially only schedule data will be available. The data content should then steadily increase as the flight progresses, until it is as complete as the provider can make it.

1.2. Implementation considerations

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

It is however up to the service provider to decide which data elements to actually update.

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

    • the address of the service.
    • any limitations in the implementation.
    • any limitations on how often a client can use the service.

1.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 WSDL and 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.

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 Helicopter Data Set Service. The operations are described in detail in Service operations.

The operations can set the following types of data:

  • Helicopter flight data

3. Service operations

3.1. SubmitHeliFlightData( transData: TransData, heliFlightData: HeliFlightData )

Sets data regarding a helicopter flight. A flight can include multiple stops, but the start and end are handled more extensively than any stops in the middle of the flight. Often the helicopter flies from the airport requesting the information, does some stops, and return to the same airport. The alternative is that the helicopter flies from or to the airport requesting helicopter information.

Parameters: 

Returns: ResponseStatus  - See definition under Data entities.

4. Data entities

4.1. HeliFlightData

Airport Data Dictionary Element Description
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).
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.
OperatingAirlineICAO
Use the ICAO code for the helicopter operator if that is available.
The ICAO code of the airline operating the flight.  See AirlineICAO for definition of term.
OperatingAirlineCode Some code, typically neither IATA nor ICAO, for the operating airline. System specific content.
OperatingAirlineName The name of the operating airline.
FlightRouteOperator
The party operating the flight route. This will often be a company that has hired the airline to operate a given route.
HelicopterType A code indicating which type of helicopter this is. Not standardized.
HelicopterTypeDescription Descriptive text for HelicopterType
AircraftICAOType
3-4 character code as designated by International Civil Aviation Organisation (ICAO) to uniquely designate Aircraft Type. Local (non-ICAO) codes can be added as required as long as they are unique for aircraft types within the defined context.
Reference Document: ICAO document 8643.
AircraftConfigVersion
Detailed information about the aircraft configuration, received in the aircraft_conf_version field in the ASM and SSM IATA messages.
AircraftTailNumber
Tail number painted on the tail used by some carriers as an aircraft identifier. Often the last 3 characters of AircraftRegistration.
HelicopterFlightStatus A code indicating the status of the whole helicopter flight, from departure to final arrival if this was a multi hop flight. Not strictly standardized.
FlightLegStatus The status of a "FlightLeg". The following values are defined: "SCH", "FPL", "FLS", "ACT", "CAN", "LAN", "RER", "DIV", "DEL", "UNK"
FlightIsCancelled Set to true if the flight operation is cancelled. For flight as with code share it's possible to only cancel the code shared flight.
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.


First departure The following elements are for the first departure (if multi hop)
DepartureAirportIATA

Either the departure airport or the arrival airport must be a "proper" IATA airport.

Departure airport IATA code (see AirportIATA for description of term).
DepartureHeliportName Name of the departure heliport.
DepartureHeliportType Type of the departure heliport. Not strictly defined.
SOBT Scheduled Off-Block Time. The time that an aircraft is scheduled to depart from its parking position. Always UTC time.
EOBT Estimated Off-Block Time. The estimated time at which the aircraft will start movement associated with departure. Always UTC time.
TOBT Target Off-Block Time. The time that an Aircraft Operator or Ground Handler estimates that an aircraft will be ready, all doors closed, boarding bridge removed, push back vehicle available and ready to start up / push back immediately upon reception of clearance from the TWR. 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.
ETOT Estimated Take Off Time. The estimated take off time taking into account the EOBT plus EXOT. Always UTC time.
ATOT Actual Take Off Time. The time that an aircraft takes off from the runway. (Equivalent to ATC ATD–Actual Time of Departure, ACARS = OFF). Always UTC time.
CheckInOpen

The time (UTC) when the first check-in desk opened against this flight.
CheckInClose

The time (UTC) when the last check-in desk against this flight closed.
Gate Uniquely defines one gate at the airport.
MailWeightLoaded Weight in Kilos of mail loaded onto the aircraft.
CargoWeightLoaded Weight in Kilos of cargo (freight) loaded onto the aircraft at the current airport.
PaxBoarding The number of "seated passengers" boarding the aircraft, infants excluded.
PaxBoarding = PaxAdultBoarding + PaxChildBoarding 


Last arrival The following elements are for the last arrival (if multi hop)
ArrivalAirportIATA

Either the departure airport or the arrival airport must be a "proper" IATA airport.

Arrival airport IATA code (see AirportIATA for description of term).
ArrivalHeliportName Name of the arrival heliport.
ArrivalHeliportType Type of the arrival heliport. Not strictly defined.
SIBT Scheduled In-Block Time. The time that an aircraft is scheduled to arrive at its first parking position. Always UTC time.
EIBT Estimated In-Block Time. The estimated time that an aircraft will arrive in-blocks. (Equivalent to Airline/Handler ETA –Estimated Time of Arrival). 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.
ELDT Estimated Landing Time. The estimated time that an aircraft will touchdown on the runway. (Equivalent to ATC ETA–Estimated Time of Arrival = landing). Always UTC time.
ALDT Actual Landing Time. The time that an aircraft lands on a runway. (Equivalent to ATC ATA –Actual Time of Arrival = landing, ACARS=ON). Always UTC time.
MailWeightUnloaded Weight in Kilos of mail unloaded off the aircraft.
CargoWeightUnloaded Weight in Kilos of cargo (freight) unloaded off the aircraft at the current airport.
PaxDisembarking The number of passengers and passive crew disembarking the plane, infants excluded.
PaxDisembarking = PaxAdultDisembarking + PaxChildDisembarking


Vias If multi hop the structure below describe the via helipads
FlightRouteIATA

FlightRouteIATA should contain at least 2 entries, the first departure and the last arrival, for a helicopter flight without any additional hops.

List of airports a multi leg flight will land on before arriving at the destination. The list consists of AirportIATA codes. The list should contain all airports including first departure airport and last destination airport. The list should be ordered by the actual sequence the aircraft uses the airports.

4.2. ResponseStatus


 
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.

For the operations defined her the following values can be used:

  • "OK": Operation succeded.
  • "ERR01":
  • "ERR02":
  • "":
  • "":
  • "ERR99": Other error. "statusText" should describe the error

 

 

The possible values must be decided and documented as coding progresses.
ResponseStatusText
A textual description of ResponseStatusCode.

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

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

 

  • No labels