Service Description

 

 

asrv.aero

DeIce Data Set Service

 

 

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

 

Document revisions

Date

Description

Author

2020-03-22 First complete version of the documentation

 

 

  

1. Introduction

1.1. Overview

This service description defines one service with one operation to set de-ice data. The service is primarily designed for de-ice operators to inform the airport about the de-ice process for one aircraft.

All data elements are defined by the Airport Data Dictionary.

The service is primarily designed to be used by de-ice operators.

1.2. Implementation considerations

Any implementation of this service MUST use the WSDL and 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 operation on the DeIce Data Set Service. The operation is described in detail in Service operations.

3. Service operations

3.1. SubmitDeIceData( transData : TransData, deIceData : DeIceData)

Submits the de-ice data for further processing.

4. Data entities

4.1. DeIceData

DeIceData describes the current de-ice status of the flight leg (aircraft).

ADD element Description
FlightLegIdentifier
FlightLegIdentifier is a set of attributes that uniquely can identify a FlightLeg in different contexts. It consists of the following:

None are required, but enough have to be present to actually uniquely identify a FlightLeg

DeIceIsRequested A boolean value indicating that de-icing, or anti-icing, is requested for the relevant aircraft.
DeIceProcessStatus Indicates the status of the de-icing process.
DeIcePlatform

The platform where the de-icing occurred. The names are airport specific. De-icing is typically done either on stand or on a dedicated de-icing platform.

DeIceParkingPosition Indicates the AircraftParkingPosition where de-icing was done. See also DeIcePlatform.
DeIceConditionCode

The code for the (weather) condition that led to de-icing being requested, and possibly performed. The codes listed under "Legal values" should always be supported. Additional codes can be defined if necessary. Codes defined here are always two digits.

DeIceAirTemperature

The air (ambient) temperature where the de-icing process occurs.

ERZT Estimated Ready for De-icing Time. The estimated time when the aircraft is expected to be ready for de-icing operations. Always UTC time.
ARZT Actual Ready for De-icing Time. The time when the aircraft is ready to be de-iced. Always UTC time.
ECZT Estimated Commencement of De-icing Time. The estimated time when de-icing operations on an aircraft are expected to start. Always UTC time.
ACZT Actual Commencement of De-icing Time. The time when de-icing operations on an aircraft starts. Always UTC time.
EEZT Estimated End of De-icing Time. The estimated time when de-icing operations on an aircraft are expected to end. Always UTC time.
AEZT Actual End of De-icing Time. The time when de-icing operations on an aircraft end. Always UTC time.
EDIT Estimated De-icing Time. Metric: EEZT ECZT.
ADIT Actual De-icing Time. Metric: AEZTACZT
MechanicalDeIceIsUsed A boolean value indicating that mechanical de-icing in some form is used on the relevant aircraft.
AntiIceStartHoldoverTime

The start of the anti-ice holdover time. This will typically be when the first truck started to apply anti-ice fluid. Always UTC.

HandlerCode Identifies a Handler.
HandlerName Name of a Handler.
DeIceFluidUsage Entity
Indicates which de-ice fluid type, including water, that has been used on the relevant aircraft. Each fluid type is specified separately, typically with the volume used.
Indicates the volume used of the relevant DeIceFluidType.

4.2. FlightLegIdentifier

This is the standard Airport Data Dictionary FlightLegIdentifier. None of the elements are required, but enough have to be present to actually uniquely identify a flight.

 


IFPLID

Defined by Eurocontrol as "A unique flight plan identifier, assigned by the IFPS". Two letters followed by eight digits.
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).
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.
ssrCode
Secondary Surveilence Radar Code

A four-digit octal number received from the aircraft transponder when it is interrogated by a secondary surveillance radar (SSR).

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.

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

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.

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

Status codes must be documented by the service implementation.

statusText : ResponseStatusText
A textual description of ResponseStatusCode.

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

de-ice-data-set-service-wsdl-20200624.zip

2020-06-26 08:04  

7. Examples

7.1. Introduction

The following are example invocations of the service.

7.2. Example SOAP templates

SOAP template
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:deic="http://www.asrv.aero/webservices/1.0/DeIceDataSetService" xmlns:dat="http://www.asrv.aero/webservices/1.0/DeIceDataSetService/datadefinitions">
   <soapenv:Header/>
   <soapenv:Body>
      <deic:submitDeIceDataRequest>
         <dat:transData>
            <dat:correlationId>TEST_MEB_1970-01-01T01:02:00Z </dat:correlationId>
            <dat:sourceOrganization>MEB</dat:sourceOrganization>
            <dat:sourceTimestamp1970-01-01T01:02:00Z </dat:sourceTimestamp>
         </dat:transData>
         <dat:deIceData>
            <flightLegIdentifier>
               <dat:ifplId>AA12345678</dat:ifplId>
               <dat:callsign>ABC1234</dat:callsign>
               <dat:aircraftRegistration>CD12345678</dat:aircraftRegistration>
               <dat:ssrCode>1234</dat:ssrCode>
               <dat:flightId>AB1234</dat:flightId>
               <dat:flightDepartureDate>1970-01-01</dat:flightDepartureDate>
               <dat:departureAirportIATA>ABC</dat:departureAirportIATA>
               <dat:arrivalAirportIATA>DEF</dat:arrivalAirportIATA>
               <dat:departureAirportICAO>ABCD</dat:departureAirportICAO>
               <dat:arrivalAirportICAO>DEFG</dat:arrivalAirportICAO>
            </flightLegIdentifier>
            <deIceIsRequested>true</deIceIsRequested>
            <deIceProcessStatus>DeIceRequested</deIceProcessStatus>
            <deIcePlatform>alfa nord</deIcePlatform>
            <deIceParkingPosition>ABCD1234</deIceParkingPosition>
            <deIceConditionCode>01</deIceConditionCode>
            <deIceAirTemperature>0</deIceAirTemperature>
            <erzt>1970-01-01T01:02:04Z</erzt>
            <arzt>1970-01-01T01:02:05Z</arzt>
            <eczt>1970-01-01T01:02:06Z</eczt>
            <aczt>1970-01-01T01:02:07Z</aczt>
            <eezt>1970-01-01T01:02:08Z</eezt>
            <aezt>1970-01-01T01:02:09Z</aezt>
            <edit>PT1M</edit>
            <adit>PT2M</adit>
            <mechanicalDeIceIsUsed>true</mechanicalDeIceIsUsed>
            <antiIceStartHoldoverTime>1970-01-01T01:03:02Z</antiIceStartHoldoverTime>
            <deIceFluidUsage>
               <deIceFluidType>Type 1</deIceFluidType>
               <deIceFluidVolume>123</deIceFluidVolume>
            </deIceFluidUsage>
         </dat:deIceData>
      </deic:submitDeIceDataRequest>
   </soapenv:Body>
</soapenv:Envelope>


  • No labels