Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata

This is an example of Service Description for a fictitious service, with the intention to illustrate the EUROCONTROL SWIM specifications.

Service Description Identification

title

Donlon TOBT Setting Service Description

edition

0.93

reference date

23/10/2018

General service elements

Service Identification

name

TargetOffBlockTimeSetting Service

version

1.0.0

Service Abstract

The TargetOffBlockTimeSetting service supports the Airport CDM concept and its implementation by allowing A-CDM Partners, typically aircraft operators and ground handlers, with the capability to set the Target Off-Block Time (TOBT) that indicates the target time for the aircraft to be ready for Off-Block.

It is part of a set of services supporting the Airport CDM concept and its implementation by providing the A-CDM partners with Common Situation Awareness about flights at a CDM airport.

Service Provider

organisation

Donlon Airport Operator

points of contact


To request access to the service: http://www.donlon-airport.com/swim/service-request

For Incidents on services in operation, contact the Service desk [24/7]: +693 555 01 service-desk@donlon-airport.com

 Table of Contents [+]

 detailed TOC [+]

Service Categories

information exchange area

flight information exchange

availability status

operational

business activity

airport operations management

intended service consumer

airspace user
airside ground handler

geographical extent

EADD (Donlon/Intl.)

Service standard reference

This service conforms to the TargetOffBlockTimeSetting service as defined by SESAR in the ISRM 2.0, published within the 5th element of the Initial system-wide information management (SWIM) technology solution pack (http://www.sesarju.eu/node/2255,  05_ISRM_Solution_46_SWIM_Technological_Solution.zip, file 0542DEL_08.03.10_D65_European_ATM_Service_Description_for_TargetOffBlockTimeSetting_Service.pdf

Deviations: the original payload has been adapted in order to better fulfil the role of example.

Operational Needs

Operational and Business context

The context is the Airport Collaborative Decision Making (A-CDM) concept as defined in Airport CDM Implementation Manual v4.

In A-CDM it is important to allow A-CDM Partners to set the value of some milestones when necessary.

The classical example is to allow the Aircraft Operator or the Ground Handler to set the Target Off-Block Time (TOBT) that indicates what is the target time for the aircraft to be ready for off-block.

Not any value can be accepted. There may be many business rules for validating the value. As for example: value cannot be in the past, value can no longer be changed, too many changes, etc.

Setting the TOBT value is possible at many stages during the A-CDM process, as early as Milestone 2 (EOBT-2hr) up to and including Milestone 11 (Boarding starts).

The Business Logic may involve validations such as:

  • not accepting values in the past
  • not accepting a new value too close the existing one (there is a minimum change involved)
  • Limiting the number of changes after TSAT has been issued.

Information Exchange Requirements

The service is defined to satisfy two IERs, which were derived from the A-CDM Implementation Manual :


IER 1

To allow the Aircraft Operator or Ground Handler to set, update or delete the value of the Target Off-Block Time of a departing flight. This is done in accordance with the operations involving Target Off-Block Time that take place between A-CDM Milestones 2 and 11 (derived from: Airport CDM Implementation Manual v4)

IER 2

To allow the competent authority to set the value of the Target Off-Block Time for a given aircraft in specific circumstances. In other words, under adverse conditions or special circumstances this service allows the competent authorities to set the Target Off-Block Time value of the flight. (derived from: Airport CDM Implementation Manual v4)

Service identification process of the A-CDM services

Airport CDM is about partners (airport operators, aircraft operators/ground handlers, ATC and the Network Operations) working together more efficiently and transparently, with a special focus on information sharing. These A-CDM Partners often have their own information systems, which must be integrated in order to support the A-CDM processes. There is a need for establishing modern techniques and standardisation across the industry for maximising the benefits of the automation required at each airport, using approaches like Service Oriented Architecture (SOA), web services, and XML data exchanges that are known to help and support interoperability.

The designed A-CDM services result from a joint service activity between SESAR and ACI. Within ACI (Airport Council International), the ACRIS (Airport Community Recommended Information Services) working group had set up the project AACO (ACRIS Airport CDM Operational project). Within SESAR the Service Coordination Group had set up the FT10 Service Activity.

As AACO and FT10 were quite similar, it was decided to run a joint service activity, with common objective, scope and deliverable. This joint service activity has been run with close and effective collaboration, following the SESAR Method on Services.

Four A-CDM services have been identified:  AirportFlightInformationPublication, TargetOffBlockTimeSetting, PreDepartureSequenceSetting, and  CalculatedPreDepartureSequenceDelivery.

Service Functionality

function

real world effect

Allow the service consumer to set (i.e. define or update) the TOBT value for a specific flight.


The Target Off-Block Time (TOBT) value is defined

Allow the service consumer to delete the TOBT value for a specific flight.

The Target Off-Block Time (TOBT) value is undefined

The A-CDM Implementation Manual defines the impact of the TOBT value at various stages of the A-CDM process.

Access and Use Conditions

Legal constraints

TBD

Service Policies

Business policy

TBD

Operational policy

TBD

Technical policy

TBD

Service consumption constraints

TBD

Security constraints

Confidentiality

TBD

Integrity

TBD

Authentication

Consumer side authentication: TBD

Provider side authentication: Authentication is required

Authorisation

TBD

Quality of Service

availability

99.95 % outside the planned outages
Schedule of planned outages: http://www.donlon-airport.com/swim/planned-outages

capacity

2000 service requests per hour

response time

2s delay for 95% of messages

Technical Constraint

No known technical constraint.


Service interfaces

Interfaces overview

The service is based on the single provided interface TOBTSettingReceiver.

The following diagram summarises the service and its provided interface

Message exchange pattern

The service follows the Synchronous Request/Response Message Exchange Pattern.

TOBTSettingReceiver Interface

name

TOBTSettingReceiver

description

The interface allows setting or deleting the TOBT of the specified flight.

role

Provider side interface

network address

http://www.swim.donlon-airport.com/swim-ops/gateway

message exchange pattern

SynchronousRequestReply


Additional network addresses:

Service Interface Binding

SWIM TI Profile and interface bindings

XML requests and replies embedded into SOAP messages, themselves embedded into HTTP requests and responses. Operation names are associated to SOAP requests.

profile name

TI Yellow Profile specification

profile version

Edition Number 1.0

selected binding

WS SOAP

supported optional requirements

-

Service interface protocols and data format

transport / messaging protocols

HTTP 1.1

SOAP1.1, SOAP1.2

Protocol implementation compliant with WSI Basic Profile 2.0

protocol configuration

HTTP Messages will indicate the payload content type using the content-type header

HTTP Messages that transport compressed payloads will use deflate/gzip/exi as expressed in the content-encoding header  (compression ratio is around 20%)

HTTP will use the chunked transfer encoding and indicate this in the transfer-encoding header.

HTTP will use the status header to indicate the status of the response using a code and corresponding meaning phrase. (see exception handling)

HTTP post method is supported

security

Server authentication based on  X.509 certificates

Client authenticates based on HTTP Basic

TLS1.2

Cypher Suites: AES_128_GCM_SHA256, AES_256_CCM

exception handling

The services make use of the standard HTTP 400 error [Bad Request] in any of the following cases:

  • The request is for an unsupported release
  • The request is not a well-formed XML
  • The request is a well-formed XML but it is not valid with respect to the XSD (i.e. it does not conform to the type and attribute names defined in the XSD and documented in the reference manuals). Examples of causes for invalid XML documents are:
    • Unexpected element or attribute
    • Element order violation
    • Incorrect primitive value
    • Unexpected enum value

Machine-readable service interface definition

Service description in WSDL 1.1 <<add reference>>

Message description by XML Schema  <<add reference>>

Service Operations

setTOBT

operation

setTOBT

The setTOBT Service Operation receives the Target Off-Block Time for a specific flight. The operation returns a confirmation of the validity of the provided Target Off-Block Time taking into account these business rules:

  • Not accepting values in the past
  • Not accepting a new value too close to the existing one (there is a minimum change involved)
  • Limiting the number of changes after TSAT has been issued

input

TOBTSettingRequest

Message which provides the Target Off-Block Time value of a specific flight.

output

TOBTSettingResponse

Message which responds the validity of a previously sent TOBTSettingRequest message.

error



deleteTOBT

operation

deleteTOBT

The deleteTOBT Service Operation receives a request for deleting the Target Off-Block Time for a specific flight. The operation returns a confirmation of the validity of such request taking into account this business rule:

  • Not accepting request affecting a flight with no Target Off-Block Time set yet.

input

TOBTDeleteRequest

Message which requests deleting the last TOBT value of the specified flight.

output

TOBTDeleteResponse

Message which responds the validity of a previously sent TOBTDeleteRequest message.

error



Service behaviour

Each operation of the interface can be called independently.

The following diagram illustrates the interaction between the service consumer and the service:

Figure 1: Sequence diagram

Model view

The model is published as an XMI file that can be imported in Sparx Enterprise Architect.

<<add reference>>

 

Information Definition

AIRM conformance

Conformant with AIRM version 1.0.0.

Message Types

TOBTSettingRequest

Message which provides the Target Off-Block Time value of a specific flight.

 

Attributes:

tobt

Type

TargetOffBlockTime


Description

The Target Off-Block Time value to be set
TOBT is the time that an operator / handling agent estimates that an aircraft will be ready, all doors closed, boarding bridge removed, push back vehicle present, ready to start up / push back immediately upon reception of clearance from the TWR.


Note

Mandatory


AIRM Definition Trace

urn:aero:airm:1.0.0:ConceptualModel:Subjects:Flight:FlightEvent:TargetOffBlockTime


AIRM Semantic Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Flight:FlightEvent:OffBlockReady@time


AIRM Context Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Common:Codelists:CodePlanningStatusType@TARGET

flightID

Type

ICAOFlightIdentification


Description

The ICAO identifier of the specified flight


Note

Mandatory


TOBTSettingResponse

Message which responds the validity of a previously sent TOBTSettingRequest message.

Attributes:

responseStatus

Type

ResponseStatus


Description

Status of the response to the service request


Note

Mandatory

TOBTDeleteRequest

Message which requests deleting the last TOBT value of the specified flight.

Attributes:

flightID

Type

ICAOFlightIdentification


Description

The ICAO identifier of the specified flight


Note

Mandatory

TOBTDeleteResponse

Message which responds the validity of a previously sent TOBTDeleteRequest message.

Attributes:

responseStatus

Type

ResponseStatus


Description

Status of the response to the service request


Note

Mandatory


Complex Types

ICAOFlightIdentification

Flight identification structure based on usual ICAO fields present in the Flight Plan.


Attributes:

aircraftIdentification

Type

AircraftIdentification


Description

Name used by ATS units to identify and communicate with the aircraft.


Note

Mandatory


AIRM Semantic Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Flight:FlightIdentifier:AircraftIdentification

estimatedOffBlockTime

Type

EstimatedOffBlockTime


Description

Date and time at which the aircraft will off-block according to ICAO flight plan field.


Note

Mandatory


AIRM Definition Trace

urn:aero:airm:1.0.0:ConceptualModel:Subjects:Flight:FlightEvent:EstimatedOffBlockTime


AIRM Semantic Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Flight:FlightEvent:OffBlock@time


AIRM Context Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Common:Codelists:CodePlanningStatusType@ESTIMATED

icaoDepartureAerodrome

Type

ICAODepartureAerodrome


Description

ICAO code of the scheduled departure aerodrome.


Note

Mandatory


AIRM Semantic Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:BaseInfrastructure:AerodromeInfrastructure:Aerodrome@locationIndicatorICAO


AIRM Context Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Flight:Flight@departureAerodrome

icaoArrivalAerodrome

Type

ICAOArrivalAerodrome


Description

ICAO code of scheduled destination aerodrome.


Note

Mandatory


AIRM Semantic Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:BaseInfrastructure:AerodromeInfrastructure:Aerodrome@locationIndicatorICAO


AIRM Context Trace

urn:aero:airm:1.0.0:LogicalModel:Subjects:Flight:Flight@destinationAerodrome

ResponseStatus

General structure of responses of an A-CDM service.

Attributes:

reasonForRejection

Type

ReasonForRejection


Description

Code or textual description on the reason for rejection


Note

Mandatory when status = REJECTED


AIRM Semantic Trace

AIRM_out_of_scope

status

Type

Status


Description

Specifies whether the related request has been accepted or not.

Values:

  • ACCEPTED
  • REJECTED


Note

Mandatory


AIRM Semantic Trace

AIRM_out_of_scope


Simple Types

TargetOffBlockTime <<DateTime>>

The time that an operator / handling agent estimates that an aircraft will be ready, all doors closed, boarding bridge removed, push back vehicle present, ready to start up / push back immediately upon reception of clearance from the TWR.

AircraftIdentification <<string>>

Name used by ATS units to identify and communicate with the aircraft.

String of 1 to 7 alphanumeric characters.

EstimatedOffBlockTime <<DateTime>>

Date and time at which the aircraft will off-block according to ICAO flight plan field.

ICAODepartureAerodrome <<ICAOAerodromeLocationIndicator>>

ICAO code of the scheduled departure aerodrome.

ICAOArrivalAerodrome <<ICAOAerodromeLocationIndicator>>

ICAO code of scheduled destination aerodrome.

ICAOAerodromeLocationIndicator <<string>>

ICAO code of scheduled destination aerodrome.

String of 4 alphabetic uppercase character.s

ReasonForRejection <<string>>

Code or textual description on the reason for rejection

Status <<enumeration>>

Specifies whether a request has been accepted or not.

Values:

  • ACCEPTED
  • REJECTED

Other service elements

Service validation

The service has not been validated yet.

Service monitoring

There is no service monitoring mechanism available to service consumers.

Examples of code

No code example available.

Abbreviations & Acronyms

abbreviation

term

AACO

ACRIS Airport CDM Operational project

A-CDM

Airport Collaborative Decision Making

ACI

Airport Council International

ACRIS

Airport Community Recommended Information Services

AIRM

ATM Information Reference Model

ATM

Air Traffic Management

CDM

Collaborative Decision Making

FT10

SESAR A-CDM Service Activity

IATA

International Air Transport Association

ICAO

International Civil Aviation Organisation

IER

Information Exchange Requirement

IFPL

Individual Flight Plan message

IFPS

Integrated Initial Flight Plan Processing System

ISRM

Information Service Reference Model

SESAR

Single European Sky ATM Research Programme

SOA

Service Oriented Architecture

SWIM

System Wide Information Management

TOBT

Target Off-Block Time

TSAT

Target Start Up Approval Time

UML

Unified Modeling Language

WSDL

Web Services Definition Language

XSD

XML Schema Definition

  • No labels

2 Comments

  1. Asuming that the description is providing what the specification recommends, this is a good and understandable example.

    The question remains, for what such an artefact could be used?

    In my eyes,  such a presentation is a Provider internal documentation (which of course could be given to the potentiell consumer)  , which maybe is iterativly evolved during a process of Service design. To strive for SWIm compliance,  a XML file still has to be generated out of such human readable Service Descriptions.

    It could be considered to provide a teamplate for such human readable descriptions and a script to generat a SWIm Governance conform XML file out of it.   

  2. The pieces of information provided here are quite detailed and well structured. However, looking at this actually only partly complete example, it strikes me as a lot of information, which would require a lot of effort to produce and maintain, even for this fairly simple service. I simply fear that the acceptance will be low by the community. This comes back to Oliver's question above about the purpose of such documentation.

    I noticed that a machine-readable version of the service description and payload syntax is available. I would argue that many people would just look in the machine readable files as they contain most of the information and are binding. The description of each element and attribute can also be provided as annotation in the XML schema.