STDDS Web Service Description Document - nsrr.faa.gov TDES... · Web viewThis JAVA Messaging ... FAA-STD-073 and satisfies that the implementation of the STDDS TDES complies with

NAS-JMSDD-4307-005 Rev BJune 28, 2018

U.S. Departmentof Transportation

Federal AviationAdministration

JAVA Messaging Service Description Document

SWIM Terminal Data Distribution System (STDDS)

Tower Departure Event Service (TDES)


JAVA Messaging Service Description DocumentSTDDS Tower Departure Event Service

Approval Signatures

Name Organization Signature Date SignedAJM Enterprise ProgramsANG NAS Requirements and Interface

Management Group


JAVA Messaging Service Description DocumentSTDDS Tower Departure Event Service

Revision Record

Revision Description RevisionDate

Entered By

Updated baseline for R3.2 (CCD N35889) 11/30/2015 KingA Updated for R3.3 1/19/2017 KingB Updated for R4:

- Message header namespace update (v4)

- Direct publication to NEMS Solace appliances

- Addition of msgSeqID to message header to help detect lost messages

- Integration of SFDPS flight plan data to enhance TowerDepartureEvent messages

- Publication of filtered TowerDepartureEvent messages

- Publication of DATISData messages- Removal of NEMS error checking of

airport values in reconstitution requests

6/28/2018 King


Table of Contents1 SCOPE........................................................................................................11.1 Background..................................................................................................................11.2 Intended Use................................................................................................................12 APPLICABLE DOCUMENTS..........................................................................22.1 Government Documents..............................................................................................22.2 Non-Government Standards and Other Publications....................................................23 DEFINITIONS..............................................................................................43.1 Terminology.................................................................................................................4

3.1.1 Client........................................................................................................................43.1.2 Service.....................................................................................................................43.1.3 Service Interface Implementation............................................................................43.1.4 NEMS........................................................................................................................4

3.2 Abbreviations and Acronyms.......................................................................................54 SERVICE PROFILE.......................................................................................74.1 Service Provider...........................................................................................................7

4.1.1 Point of Contact........................................................................................................74.2 Service Consumers......................................................................................................74.3 Service Functionality....................................................................................................74.4 Security........................................................................................................................84.5 Qualities of Service......................................................................................................84.6 Service Policies............................................................................................................94.7 Environmental Constraints...........................................................................................95 SERVICE INTERFACES..............................................................................115.1 Interface....................................................................................................................115.2 Operations.................................................................................................................11

5.2.1 Processing Considerations......................................................................................115.3 Messages...................................................................................................................12

5.3.1 TowerDepartureEventMessage Data Elements......................................................135.3.2 TowerDepartureEventReconstitutionStartMessage Data Elements........................155.3.3 TowerDepartureEventReconstitutionCompleteMessage Data Elements.................165.3.4 ReconstituteRequestStatusMessage Data Elements..............................................175.3.5 DATISData Data Elements......................................................................................175.3.6 ReconstituteSubscriptionToDepartureDataMessage Data Elements.......................19

5.4 Exception Handling....................................................................................................195.5 Data...........................................................................................................................196 SERVICE IMPLEMENTATION......................................................................216.1 Bindings.....................................................................................................................21

6.1.1 Data Bindings.........................................................................................................216.1.1.1 Data format....................................................................................................216.1.1.2 Message Protocol............................................................................................216.1.1.3 Transport Protocol..........................................................................................21

6.2 End Points..................................................................................................................216.3 Subscribe Flow...........................................................................................................216.4 PublishReconRequest Flow.........................................................................................23


List of Figures

Figure 1: Subscribe Flow..............................................................................................................22Figure 2: Reconstitution Sequence..................................................................................................24


List of Tables

Table 1 : Quality of Services Parameters.............................................................................................9Table 2 : Environmental Constraints................................................................................................10Table 3 : List of Published Messages...............................................................................................12Table 4 : Consumed Message.........................................................................................................13Table 5 : TowerDepartureEventMessage Header.................................................................................13Table 6 : TowerDepartureEventMessage Data Elements........................................................................14Table 7 : TowerDepartureEventReconstitutionStartMessage Header.........................................................15Table 8 : TowerDepartureEventReconstitutionStartMessage Data Elements................................................16Table 9 : TowerDepartureEventReconstitutionCompleteMessage Header...................................................16Table 10 : TowerDepartureEventReconstitutionCompleteMessage Data Elements........................................16Table 11 : ReconstituteRequestStatusMessage Header..........................................................................17Table 12 : ReconstituteRequestStatusMessage Data Elements.................................................................17Table 13 : DATISData Header.......................................................................................................18Table 14 : DATISData Data Elements..............................................................................................18Table 15 : ReconstituteSubscriptionToDepartureDataMessage Header......................................................19Table 16 : Simple Data Types........................................................................................................20Table 17 : Complex Data Types......................................................................................................20


1 SCOPEThis JAVA Messaging Service Description Document (JMSDD) describes the System Wide Information Management (SWIM) Terminal Data Distribution System (STDDS) Tower Departure Event Service (TDES) for SWIM. The TDES publishes controller entered departure events (e.g. taxi start, takeoff) received from the Electronic Flight Strip Transfer System (EFSTS) and clearance delivery information received from Tower Data Link Services (TDLS) to authorized SWIM service consumers via the National Airspace System (NAS) Enterprise Messaging Service (NEMS). The TDES also publishes Digital Automatic Terminal Information System (D-ATIS) information received from TDLS. D-ATIS data contains essential information required by aircraft operators, such as current weather information, active runways, important NOTAMs, etc. In addition, the service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup. This JMSDD was prepared in accordance with Federal Aviation Administration (FAA) Standard (STD) FAA-STD-073 and satisfies that the implementation of the STDDS TDES complies with the STDDS Web Services Requirements Document (WSRD), developed in accordance with FAA-STD-070.

1.1 BackgroundSTDDS provides Service Oriented Architecture (SOA) interfaces for tower and Terminal Radar Approach Control (TRACON) systems to send terminal events to the NEMS for subscription by NAS and non-NAS consumers using SWIM compliant infrastructure and interface standards.

STDDS interfaces with Runway Visual Range (RVR) system, EFSTS, Airport Surface Detection Equipment Model X (ASDE-X) system, Airport Surface Surveillance Capability (ASSC) system, and TDLS system at airports to accept, derive and publish airport information.

STDDS also interfaces with the STARS General NAS User Services (GeNUS) interface at TRACONs.

STDDS receives and retains flight plan data by interfacing with the SWIM Flight Data Publication Service (SFDPS) via NEMS. The retained flight plan data is used by STDDS to enhance a subset of published outputs including some TDES messages.

The Infrastructure, System Monitor and Control (ISMC) service publishes status information for all external links at a STDDS site. This service also publishes detailed information about the overall STDDS status.

1.2 Intended UseThis JMSDD is intended to be used by clients of the STDDS TDES to facilitate the development and operation of service client applications. It may also be used by the FAA staff who may administer these services.


2 APPLICABLE DOCUMENTS

2.1 Government Documents

[FAA-STD-063] XML Namespaces, 1 May 2009. http://www.tc.faa.gov/its/worldpac/standards/faa-std-063.pdf

[FAA-STD-073] Preparation of Java Message Service Description Document, W3C Working Draft, 29 January 2014. http://www.tc.faa.gov/its/worldpac/standards/faa-std-073.pdf

[FAA-STD-066] Web Service Taxonomies, 26 February 2010. http://www.tc.faa.gov/its/worldpac/standards/faa-std-066.pdf

[FAA-STD-068] Preparation of Standards, 4 December 2009.http://www.tc.faa.gov/its/worldpac/standards/faa-std-068.pdf

[NAS-WSRD-4307-001] SWIM Terminal Data Distribution System (STDDS) Web Services Requirements Document (WSRD), Rev B, June 28, 2018.

[NAS-IC-XXXXXXXXX] NAS Enterprise Messaging Service (NEMS) Asynchronous Messaging Interface Control Document (ICD), Rev 4 Draft, 17 June 2013.

[NAS-IR-22034307] Interface Requirements Document (IRD) STDDS to Tower Data Link Services (TDLS), Revision B, February 6, 2018.

[NAS-IR-82514307] IRD STDDS to Electronic Flight Strip Transfer System (EFSTS), Revision A, January 11, 2016.

[NAS-JMSDD-4307-002] JMSDD STDDS Infrastructure System Monitor and Control (ISMC), Revision B, 6 February, 2018.

2.2 Non-Government Standards and Other Publications[W3C XML Recommendation] World Wide Web Consortium eXtensible Markup Language (XML) Version 1.9, Fifth edition, 26 Nov 2008. http://www.w3.org/TR/2008/REC-xml-20081126/

[IEE 802.3] Information Technology – Telecommunication & Information Exchange between Systems – LAN/MAN – Specific Requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 2002.

[WSDR] Web Services Description Requirements, W3C Working Draft, 28 October 2002.

http://www.w3.org/TR/2008/REC-xml-20081126/

http://www.w3.org/TR/2008/REC-xml-20081126/

http://www.tc.faa.gov/its/worldpac/standards/faa-std-068.pdf





http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/

[RFC 2119] Key words for Use in RFCs to Indicate Requirement Levels, Network WorkingGroup, March 1997. http://www.rfc-editor.org/rfc/rfc2119.txt

[ISO/IEC 11179-1] Information Technology – Metadata Registries (MDR) – Part 1:Framework, 15 September 2004. http://metadata-standards.org/11179/

[WS Glossary] Web Services Glossary, W3C Working Draft, 14 November 2002. http://www.w3.org/TR/2002/WD-ws-gloss-20021114/

[WSA] Web Services Architecture, W3C Working Group Note, 11 February 2004.http://www.w3.org/TR/ws-arch

http://www.w3.org/TR/ws-arch

http://www.w3.org/TR/2002/WD-ws-gloss-20021114/

http://www.w3.org/TR/2002/WD-ws-gloss-20021114/

http://metadata-standards.org/11179/

http://www.rfc-editor.org/rfc/rfc2119.txt

http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/


3 DEFINITIONS

3.1 TerminologyWithin the SWIM service-oriented architecture (SOA) environment, there are key elements that must be defined to properly identify boundaries, functionality, and components. The key high-level entities are identified in the list below:

Client Service Service Interface Implementation NAS Enterprise Messaging Service (NEMS)

3.1.1 ClientA client is an external entity that interacts with a service. A client makes a request of a service and receives a response from the service. The client may also request a subscription and receive messages when a service publishes information. A client may be a software system, software application, or another service. A client may be a NAS client or a non-NAS client. It should be noted that the terms “consumer” and “end-user” can be and are used interchangeably with “client”.

3.1.2 ServiceIn the most general sense, a service is a set of functionality that is performed upon demand based upon a defined interface. A defined request must be provided by the client that invokes the service, and the service returns a defined response to the client. For the STDDS environment, a service is a combination of software components running on the STDDS Application Server and the NEMS. At a minimum, the service requires an XML message that is transported over TCP/IP. In this context, "service" refers to all of the implementation components including the service interface implementation and the service logic.

3.1.3 Service Interface ImplementationThe service interface implementation is the hardware and software that handles the interaction between the client and the rest of the service. The definition and the implementation are independent of each other. It is possible to maintain the same service interface definition and replace the implementation. The Publish/Subscribe service interface implementation is based on the software in the NEMS.

3.1.4 NEMSNEMS provides two communication platforms:

• The NEMS Legacy Server provides support for ActiveMQ and WebLogic publication and subscription. • The NEMS Solace Appliance is a hardware appliance used for routing messages for both publication and subscription.

STDDS publishes data to the NEMS Solace Appliance.


Consumers can be configured to receive TDES data on any NEMS end-point (ActiveMQ, WebLogic, or Solace).


3.2 Abbreviations and Acronyms

AIM Aeronautical Information Manual

AIG

API

ARTCC

Application Interface Gateway

Application Programming Interface

Air Route Traffic Control Center

ASCII American Standard Code for Information Interchange

ASDE-X

ASSC

Airport Surface Detection Equipment Model X

Airport Surface Surveillance Capability

CID Computer Identification Number

D-ATIS

EFSTS

ERAM

Digital Automatic Terminal Information System

Electronic Flight Strip Transfer System

En Route Automation Modernization

FAA

FNTB

FTI

GUFI

Federal Aviation Administration

FTI National Test Bed

FAA Telecommunications Infrastructure

Globally Unique Flight Identifier

ICAO

ICD

International Civil Aviation Organization

Interface Control Document

IP Internet Protocol

IRD Interface Requirements Document

ISMC Infrastructure System Monitor and Control

ISO International Standards Organization

JMS

JMSDD

MEP

MTBF

NA

NA

Java Messaging Service

Java Messaging Service Description Document

Message Exchange Pattern

Mean Time Between Failures

Not Applicable

Not Adapted (airport)

NAS National Airspace System

NDRB NAS Data Release Board

NEMS NAS Enterprise Messaging Service


NSRR NAS Service Registry Repository

PM

R&D

Program Manager

Research and Development

RVR

SFDPS

SOA

Runway Visual Range

SWIM Flight Data Publication Service

Service Oriented Architecture

SSD

SSI

STD

System Specification Document

Sensitive Security Information

Standard

STARS

STDDS

SUI

Standard Terminal Automation Replacement System

SWIM Terminal Data Distribution System

Sensitive Unclassified Information

SWIM System-Wide Information Management

TCP Transmission Control Protocol

TDES

TDLS

Tower Departure Event Service

Tower Data Link Service

TRACON

URL

Terminal Radar Approach Control facility

Uniform Resource Locator

UTC Universal Time Coordinated/ Coordinated Universal Time

WJHTC

WSRD

William J. Hughes Technical Center

Web Services Requirements Document

XML eXtensible Markup Language


4 Service ProfileThis section provides the information needed to discover and use the STDDS TDES.

Service ProfileName STDDS Tower Departure Event Service Description The Tower Departure Event Service sends departure events for all

flights from select towers associated with a TRACON. In addition, the service publishes D-ATIS information sent automatically to aircraft and operators at airports associated with STDDS TRACONs. The service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup.

Namespace urn:us:gov:dot:faa:atm:terminal:entities:v4-0:tdesVersion 4.0Service category FAA-STD-066 category 1.3.1.2.1, Air Traffic Command and

Control Information Exchange ServiceLifecycle stage ProductionService criticality Essential

4.1 Service Provider The STDDS TDES is provided by FAA Air Traffic Organization (ATO), Enterprise Programs.

4.1.1 Point of Contact

Point of ContactName Melissa MatthewsOrganization Federal Aviation Administration

Enterprise ProgramsTitle SWIM Capabilities ManagerPhone 202-267-0764Email [email protected]

4.2 Service ConsumersThe potential clients for the STDDS TDES services are authorized NAS and non-NAS end-users. STDDS will provide sample client applications as reference models, however clients are responsible for implementing their own applications to consume TDES data.

4.3 Service FunctionalityThe STDDS TDES publishes the data listed below. For more information about individual message types see section 5.3.


o Publishes clearance delivery time, start taxi time and takeoff time (TowerDepartureEventMessage)

o Receives Reconstitution Request message (ReconstituteSubscriptionToDepartureDataMessage)

o Publishes Reconstitution Request Response message (ReconstitutionRequestStatusMessage)

o Publishes Reconstitution Start message (TowerDepartureEventReconstitutionStartMessage)

o Publishes Reconstitution Complete message (TowerDepartureEventReconstitutionCompleteMessage)

o Publishes D-ATIS data (DATISData)

4.4 Security NEMS manages all security features for Publish/Subscribe services for authorized NAS and non-NAS consumers and NAS producers.

Access controls are supported through the use of username and password credentials supplied when establishing connections to NEMS interfaces. Username and password credentials are unique to each NEMS client and established during on-ramping.

STDDS obtains updated Sensitive Flight Data (SFD) identification files via the FAA Aeronautical Data Exchange (ADX) website on a periodic basis or as directed by System Operations Services (AJR) for time critical requirements. Following the FAA-approved Security Program for Sensitive Flight Data Identification, the STDDS TDES uses the information in those files to mark, or tag, service messages as containing sensitive or non-sensitive flight data. During the SWIM on-ramping process, each client is authorized to receive either sensitive or non-sensitive flight data and is configured accordingly when on-ramped to NEMS. NEMS uses the client configuration and each message’s “sendTo” tag to ensure messages with sensitive flight data are only sent to clients authorized to receive sensitive flight data. Messages tagged as sendTo=all are considered non-sensitive and can be sent to all subscribed users. Messages tagged as sendTo=authorized are considered sensitive data and are only sent to authorized NAS users. Flight data marked as sensitive under this FAA Security Program is Sensitive Security Information (SSI) in accordance with 49 CFR 15.5(a)(16) and 49 USC 40119(a) and must be protected in accordance with FAA Order 1600.75, Protecting Sensitive Unclassified Information (SUI).

4.5 Qualities of ServiceThe STDDS TDES Quality of Service parameters are listed in the following table.


Table 1 : Quality of Services Parameters

QoS Parameter

Value Unit Definition Calculation

Availability 0.999 ratio The probability that a system or constituent piece may be operational during any randomly selected instant of time. (Definition from NAS-RD-2012)

MTBF/(MTBF + MDT)

Data Latency 1 second (mean) and 5 seconds (95th percentile)

seconds Time interval from the time an input message is received and a corresponding message is published to NEMS.

Note: Some EFSTS messages do not result in a corresponding published message, however some of the data in that message may be utilized in a subsequent published message.

Continuous measurement

Reconstitute Response Time

2 Minutes Time interval from the time a reconstitution request message is received and when a reconstitution complete message is sent


NEMS Re-connection Time

3 Minutes Maximum time interval from the time a connection failure to NEMS occurs to the time that the STDDS has reconnected to NEMS.


4.6 Service Policies

No specific service policies are applied to the STDDS TDES.

4.7 Environmental ConstraintsThis service covers three NEMS operating environments:

1) Research & Development (R&D) NEMS at Melbourne, Florida2) FAA Telecommunications Infrastructure (FTI) National Test Bed (FNTB) NEMS at

WJHTC3) NAS-OPS NEMS deployed to ARTCCs.


Table 2 : Environmental Constraints

Service Constraints FTI environmentDeployed NEMS Environment R&D, FNTB and NAS-OPSMessage Producer Type NAS applicationRecord Type Live


5 Service InterfacesThe following sections provide detailed information about the types and content of messages that the STDDS TDES publishes. The service is also described in terms of the interfaces that it communicates with.

5.1 InterfaceThe STDDS TDES follows the “point to point” messaging model and employs a single queue interface to NEMS, through which all published data can be subscribed to and received. Each client interested in subscribing to STDDS TDES data establishes a connection to a custom endpoint provided by NEMS and defined during on-ramping.

In addition, for internal NAS end-users only, the STDDS TDES supports the “PublishReconRequest” message flow. These users can send a data reconstitution request via NEMS. The STDDS TDES then publishes at most 30 minutes of the most recent TDES data along with new updates.

5.2 OperationsThe STDDS TDES publishes departure events derived from TDLS and EFSTS for all flights from towers associated with a STDDS TRACON. In addition, the service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup. TDES also publishes D-ATIS data received from TDLS.

5.2.1 Processing ConsiderationsWhile processing input from TDLS and EFSTS, the STDDS TDES determines if the given input contains sensitive information. Sensitive data includes military flights, and flights operated on behalf of foreign dignitaries, state governors, and law enforcement agencies. NEMS uses the routing information in the output message header to determine the authorized recipient of the data.

Input TDLS and EFSTS tower event data is evaluated for sensitivity and tagged accordingly:

Messages that do not contain sensitive information are published with a designation of “all” in the “sendTo” message header field and are sent to all end-users, NAS and non-NAS.

Messages containing sensitive information are published with a designation of “autho-rized” in the “sendTo” message header field and are sent only to authorized users, gener-ally NAS users.

The STDDS TDES provides a reconstitution mechanism for internal NAS end-users to request a reconstitution of departure events for a particular airport. This should be done by the end-user upon the start of a subscription or detection that a message in a sequence is lost. NEMS provides a specific reconstitution endpoint for the reconstitution request message. To start the process, an end-user must request data reconstitution by sending a reconstitution request message to the


reconstitution endpoint. If the airport in the reconstitution request is invalid STDDS will not provide a response. If the airport is valid, then the STDDS TDES will validate the rest of the request and send a response to the end-user indicating success or failure of the request. The STDDS TDES will reject a reconstitution request sent by an end-user for an airport if a reconstitution for that airport to the same end-user is currently in process. Each valid request contains data identifying the end-user and an airport code. This data is included in the published reconstituted messages and is used by NEMS to route the messages to the requesting end-user. Reconstituted data is published in the same message flow as current TDES messages.

The reconstitution mechanism is not available for end-users external to the NAS.

5.3 MessagesThe foundation for the external message format for the STDDS TDES is based upon the W3C XML standard. Publish/Subscribe services deliver messages using an asynchronous message exchange pattern. The reconstitution request message is consumed by the STDDS TDES using an In Only Message Exchange Pattern (MEP).

The following messages are published by the STDDS TDES via NEMS. Each message has a header and a payload. The header contains routing data used by NEMS to deliver messages to the correct subscriber. Note that the MsgType column defines the two-character abbreviation that is used in the JMS header to delineate the message type.

Table 3 : List of Published Messages

Name Definition MsgTypeTowerDepartureEventMessage Sent upon the receipt of a corresponding

event from EFSTS and/or TDLS. The MsgType indicates if this event is new (DE) or reconstituted (DR). Both types of messages may be enhanced with SFDPS flight plan data.Note: The DR messages are available only for internal NAS consumers.

DE, DR

TowerDepartureEventReconstitutionStartMessage

Indicates the beginning of a set of reconstituted messagesNote: This message is available only for internal NAS consumers.

RS

TowerDepartureEventReconstitutionCompleteMessage

Indicates the end of a set of reconstituted messagesNote: This message is available only for internal NAS consumers.

RC


Name Definition MsgTypeReconstitutionRequestStatusMessage

Response to a reconstitution request. The MsgType indicates if the reconstitution request has been accepted (RA) or rejected (RF).Note: This message is available only for internal NAS consumers.

RA, RF

DATISData Sent upon the receipt of D-ATIS data from TDLS and repeated periodically per D-ATIS message data type (nominally every 60 seconds).

Note: The D-ATIS message data type is contained in the first character of the dataHeader field. Possible values: ‘C’ for Combined, ‘D’ for Departure, ‘A’ for Arrival.

DD

The following message is consumed by the STDDS TDES.

Table 4 : Consumed Message

Name Definition MsgTypeReconstitutionSubscriptionToDepartureDataMessage

End-user request for a reconstitution of tower departure events

TR

5.3.1 TowerDepartureEventMessage Data ElementsThe following table lists the header for a TowerDepartureEventMessage.

Table 5 : TowerDepartureEventMessage Header

Data Element Description Cardinality TypemsgType Defines the type of message 1 stringversion Version number of the STDDS schema 1 stringtimestamp UTC date and time of message generation 1 dateTimetracon FAA location identifier (three alphanumeric

characters) of the producer STDDS installation

1 string

airport ICAO code of the source airport 1 string


Data Element Description Cardinality TypeclientID End-recipient username, present only as part

of a reconstitution (msgType is set to “DR”). Reconstituted messages are available only for internal NAS consumers.

0…1 string

sendTo Authorization flag; permissible values: “all”, and “authorized”.

1 string

msgSeqID Message sequence identifier within a data stream. A data stream is defined by msgType “DE” or “DR”, airport, sensitivity as defined by the authorization flag, and clientID. This field can be used to determine out of order and missing messages. Missing messages can be recovered through reconstitution.

1 long

The following table lists the data elements in the payload of a TowerDepartureEventMessage.

Table 6 : TowerDepartureEventMessage Data Elements

Data Element Description Cardinality

Type

eventTime UTC date and time at which the departure event occurred.

1 dateTime

flightID En Route Automation Modernization (ERAM) generated Global Unique Flight Identifier (GUFI) as reported by TDLS

0..1 string

aircraftID Aircraft callsign 1 AircraftIdentifiercomputerID NAS computer identification number

(CID)/ERAM ID. 1 string

departureAirport ICAO departure airport code as determined by the EFSTS or TDLS link.

1 AirportIdentifier

destinationAirport ICAO destination airport code 0..1 AirportIdentifierclearanceDeliveryTime

UTC date and time at which a departure clearance was issued as reported by TDLS.

Note: TDLS sends a Clearance Delivery message after the Airlines Operations Center acknowledged receiving the clearance.

0..1 dateTime

parkingGate Aircraft parking gate information. 0..1 stringtaxiStartTime UTC date and time at which taxi start

event was detected by STDDS TDES.0..1 dateTime



Type

takeoffTime UTC date and time at which takeoff event was detected by STDDS TDES.

0..1 dateTime

takeoffRunway Runway identifier as reported by EFSTS

0..1 RunwayIdentifier

enhancedData Collection of correlated fields derived from SFDPS flight plan data including ERAM GUFI, SFDPS GUFI, Departure Airport, Destination Airport, Aircraft Type and Beacon Code. The TowerDepartureEventMessage message may contain all of the fields in the enhancedData collection. The boolean attribute “s” can be set to indicate that the enhanced data is potentially stale due to a disruption in the flight plan data flow.

0..1 enhancedData

5.3.2 TowerDepartureEventReconstitutionStartMessage Data Elements

The following table lists the header for a TowerDepartureEventReconstitutionStartMessage. This message is available for internal NAS consumers only.

Table 7 : TowerDepartureEventReconstitutionStartMessage Header



1 string

clientID End-recipient username 1 stringsendTo Authorization flag; permissible value: all. 1 stringmsgSeqID Message sequence identifier within a data

stream. A data stream is defined by msgType and clientID.

1 long

The following table lists the data elements in the payload of a TowerDepartureEventReconstitutionStartMessage.


Table 8 : TowerDepartureEventReconstitutionStartMessage Data Elements


Type

airportID ICAO airport ID for which a reconstitution is being started

1 AirportIdentifier

5.3.3 TowerDepartureEventReconstitutionCompleteMessage Data Elements

The following table lists the header for a TowerDepartureEventReconstitutionCompleteMessage. This message is available for internal NAS consumers only.

Table 9 : TowerDepartureEventReconstitutionCompleteMessage Header



1 string

clientID End-recipient username 1 stringmsgSeqID Message sequence identifier within a data

stream. A data stream is defined by msgType and clientID.

1 long

sendTo Authorization flag; permissible value: all. 1 string

The following table lists the data elements in the payload of a TowerDepartureEventReconstitutionCompleteMessage.

Table 10 : TowerDepartureEventReconstitutionCompleteMessage Data Elements


Type

airportID ICAO airport ID for which reconstitution has completed

1 AirportIdentifier

numberOfReconMessagesToAuthorized

Total number of sensitive reconstitution messages sent

1 int

numberOfReconMessagesToAll

Total number of non-sensitive reconstitution messages sent

1 int


5.3.4 ReconstituteRequestStatusMessage Data Elements

The following table lists the header for a ReconstituteRequestStatusMessage. This message is available for internal NAS consumers only.

Table 11 : ReconstituteRequestStatusMessage Header



1 string

clientID End-recipient username. 1 stringsendTo Authorization flag; permissible value: all. 1 stringmsgSeqID Message sequence identifier within a data

stream. A data stream is defined by msgType “RA” or “RF”, and clientID.

1 long

The following table lists the data elements in the payload of a ReconstituteRequestStatusMessage.

Table 12 : ReconstituteRequestStatusMessage Data Elements


Type

airportID Airport ID for which a reconstitution status is being sent.

1 AirportIdentifier

reasonForFailure The reason for a reconstitution request failure. Sent if msgType is set to “RF”.

0..1 ReconstitutionRequestFailureReason

5.3.5 DATISData Data Elements

TDLS sites can be configured as combined or split. STDDS receives and publishes one DATISData message per reporting interval from combined TDLS sites and more than one DATISData messages per reporting interval from split TDLS sites. Split TDLS sites usually publish two D-ATIS message data types, one targeting arrival traffic and the other departure traffic. STDDS repeats periodically (nominally every 60 seconds) the latest combined, arrival or departure DATISData message(s) received from either type of TDLS configuration until a new update is received from TDLS. The D-ATIS message data type is contained in the first character


of the dataHeader field. Possible values for the message data type are as follows: ‘C’ for Combined, ‘D’ for Departure, ‘A’ for Arrival.

The following table lists the header for a DATISData message.

Table 13 : DATISData Header



1 string

airportID ICAO code of the source airport stringsendTo Authorization flag; permissible value: all. 1 stringmsgSeqID Message sequence identifier within a data

stream. A data stream is defined by msgType, and airport.

1 long

The following table lists the data elements in the payload of a DATISData message.

Table 14 : DATISData Data Elements


Type

airportID ICAO code of the source airport 1 AirportIdentifiersrcAddr The source (TDLS) International Air

Transport Association (IATA) address.

1 string

DATISTime Date and time of controller-initiated transfer of the D-ATIS message to TDLS. Numeric characters in the format "ddhhmm" indicating a valid time where "dd" is the two-digit day of the month, "hh" is the two-digit hour in 24-hour format, and "mm" is the two-digit minute.

1 string

dataHeader Message header for the D-ATIS data. The first character contains the data type. Possible values: ‘C’ for Combined, ‘D’ for Departure, ‘A’ for Arrival.

1 string

dataBody Contents of D-ATIS message containing a description of airport

1 string


conditions at the message creation time. Maximum of 2000 characters. See the Abbreviations/Acronyms in Appendix 3 of the FAA Aeronautical Information Manual (AIM) for further information.

5.3.6 ReconstituteSubscriptionToDepartureDataMessage Data Elements

The following table lists the header for a ReconstituteSubscriptionToDepartureDataMessage. This message is available for internal NAS consumers only.

Table 15 : ReconstituteSubscriptionToDepartureDataMessage Header

Data Element Description Cardinality TypemsgType Defines the type of message 1 stringtimestamp UTC date and time of message generation 1 dateTimeairport ICAO code of the source airport 1 stringclientID Identification of the end-user requesting a

reconstitution.1 string

The payload of the ReconstituteSubscriptionToDepartureDataMessage consists of a root element with no contents or attributes.

5.4 Exception HandlingThe TowerDepartureEventServiceStatus message described in the ISMC JMSDD contains status information for each external TDLS and/or EFSTS link at a STDDS site. A degraded or failed external link may result in loss of data.

5.5 DataThe following tables describe the data types defined in the STDDS TDES messages.

Specific formats required for any data types will be included in the types’ definition text. The detail for the obligation and maximum occurrences of the data types and elements is included in the schema definitions within the NSRR.

A type listed as complex means that the entity consists of one or more sub-entities, which are detailed in the entity’s definition.


Table 16 : Simple Data TypesName Definition Permissible Values Data

TypeFormat

dateTime This type defines the date and time. It is a primitive data type.

Valid date and time primitive

yyyy-mm-ddThh:mm:ss.sssZ

AircraftIdentifier This type defines an aircraft identifier

NA string .{1,8}

ReconstitutionRequestFailureReason

This provides the reason for reconstitution request failure. NA (Not adapted airport), CR (client already receiving reconstitution)

NACR

string NA

Table 17 : Complex Data TypesName Definition Permissible

ValuesData Type Format Obligation

RunwayIdentifier This type defines a runway identifier

NA Complex NA NA

RunwayIdentifier.numericRunwayID

The numeric value of the runway

NA Integer NA Required

RunwayIdentifier.runwaySubID

The orientation of the runway

NA string NA Required

enhancedData Data derived from SFDPS flight plan to enhance TDES messages.

NA Complex NA NA

enhancedData.eramGufi

ERAM GUFI derived from SFDPS flight plan data

NA string NA Optional

enhancedData.sfdpsGufi

SFDPS GUFI derived from SFDPS flight plan data


enhancedData.departureAirport

Departure ICAO airport ID derived from SFDPS flight plan data


enhancedData.destinationAirport

Destination ICAO airport ID derived from SFDPS flight plan data



Name Definition Permissible Values

Data Type Format Obligation

enhancedData.aircraftType

Aircraft type derived from SFDPS flight plan data.


enhancedData.beaconCode

Beacon code derived from SFDPS flight plan data.


6 Service ImplementationThe STDDS TDES is implemented as a JMS Publisher service. All access points to the service are wholly contained within NEMS. The STDDS TDES publishes data to NEMS via a JMS queue and receives reconstitution requests via another JMS queue. Clients connect to an endpoint established by NEMS in order to receive STDDS TDES data. Internal NAS clients connect to a different endpoint established by NEMS in order to send reconstitution requests.

6.1 Bindings

6.1.1 Data BindingsAll STDDS TDES messages published to NEMS are bound to the Solace Message Application Programming Interface (API).

Consumer bindings are determined by their end-point configuration. TDES data can be bound to the NEMS JMS interface through ActiveMQ, WebLogic or the Solace API.

6.1.1.1 Data formatAll STDDS TDES data is published to NEMS in XML format.

6.1.1.2 Message ProtocolThe message protocol for the STDDS TDES is JMS.

6.1.1.3 Transport ProtocolThe transport protocol is Transmission Control Protocol (TCP).

6.2 End PointsThe TCP/IP addresses are not included in this document for security reasons. Please refer to NEMS On-Ramping forms and section 4.1.1 Point of Contact for more details.

6.3 Subscribe FlowA STDDS TDES client may subscribe to a NEMS specified endpoint to obtain distributed departure events. The endpoint associated with an individual subscriber will be identified as part of a client’s on-ramping process.


The message flow to publish a message is asynchronous and starts with the client requesting a connection and a subscription from NEMS. As data becomes available from the STDDS TDES, it is published to the NEMS. The NEMS stores the messages on each client’s registered endpoint. If the client is connected to its endpoint, the messages will be delivered from the client’s endpoint to the client. If the client is not connected to its endpoint, the message is purged from the endpoint after its time-to-live has expired. The subscription request (steps 1 and 2 below) is performed once for each desired subscription, and the messages are published to the client until the subscription is cancelled.

A detailed message flow for receiving a message is shown below:

1. The client connects to the NEMS and requests a subscription.2. The NEMS accepts the connection, validates the client’s security, and replies with the

status of the subscription. 3. The STDDS TDES transforms legacy external data to XML messages.4. The STDDS TDES publishes the messages to the assigned queue on the NEMS.5. The NEMS publishes the message to each of the endpoints associated with clients that

have registered for the message.6. Each client connected to the NEMS pulls the message out of its endpoint.7.

Figure 1: Subscribe Flow

Client

STDDSNEMS

Input System1. The Client connects to NEMS

2. NEMS accepts the connection

6. The Client consumes the message from its endoint

5. NEMS publishes the message on the client endpoint

3. Data is received from an external input source

4. An XML message is published on the queue to NEMS

Client connection flow

Data flow


6.4 PublishReconRequest Flow

The PublishReconRequest flow is available only for internal NAS consumers and includes the creation and publication of a reconstitution start (TowerDepartureEventReconstitutionStart) message, publication of the retained tower departure event (TowerDepartureEvent) message, and then creation and publication of a reconstitution complete (TowerDepartureEventReconstitutionComplete) message. Messages published during a reconstitution process are interleaved in the steady state publication stream of tower departure event messages.

In the event that a client does not receive a response or an incomplete reconstitution is received, a client will need to re-request a reconstitution. Incomplete or missing responses may be the result of a given STDDS TDES site failure or a NEMS node failover that is currently occurring. Detection of a NEMS connection failure and recovery by the STDDS TDES can take up to 3 minutes; during that time, a response to a reconstitution request cannot be guaranteed. A client should wait the maximum failure detection time (3 minutes) before re-requesting a reconstitution for a given airport.

An example of the reconstitution flow is as follows:

1. A consumer is already connected to NEMS using the Subscribe flow2. The consumer sends a ReconstituteSubscriptionToDepartureData on the PublishRecon-

Request endpoint to NEMS3. NEMS forwards request to all attached STDDS TDES instances4. The STDDS TDES associated with the requested airport receives the reconstitution re-

quest and checks its validitya. If a reconstitution is currently occurring for this client for the airport requested a

ReconstituteRequestStatusMessage indicating failure is returned via the Subscribe flow

b. Otherwise the STDDS TDES will publish ReconstituteRequestStatusMessage in-dicating the request was accepted and begin a reconstitution using the supplied clientID to mark messages

5. The consumer listens on the Subscribe endpoint for the following in this sequence:a. A TowerDepartureEventReconstitutionStart messageb. One or more TowerDepartureEvent with the reconstitution identifierc. A TowerDepartureEventReconstitutionComplete message


Figure 2: Reconstitution Sequence