SWIM Demo Server-AMQP Data Subscriptions
SWIM Weather Public Demonstration >

AMQP Subscriptions

Connections

Clients who wish to receive data over AMQPS need an AMQP 1.0 client that supports SSL connections.

SWIM Weather listens on two AMQPS ports:

  1. swim.iblsoft.com:5671 – implements Mutual TLS.
    1. Clients must send an EACP client certificate, which will be verified by the server.
    2. The Organisation, Email, and Common Name parts of the client certificate must be listed in a whitelist on the SWIM Weather server.
    3. A username and password must be sent using SASL PLAIN over a secure TLS connection. 
  2. swim.iblsoft.com:5674 – implements Server TLS, where users authenticate only using usernames and passwords.
    1. Usernames and passwords are sent using SASL PLAIN over the secure TLS connection.

See also the section Authentication for more details about the different authentication modes.

Subscription Addresses (Topics)

There are the following 3 source addresses a client can subscribe to:

Topic Description
weather.aviation.metar IWXXM METAR and SPECI
weather.aviation.taf IWXXM TAF
weather.aviation.sigmet IWXXM SIGMET

When the client subscribes to the address, the AMQP broker automatically creates a queue for the client. There are two queue types:

  • Non-durable: exists only as long as the connection lasts and is removed when the client disconnects.
  • Durable: A durable queue for a user is also created automatically when the client connects for the first time. However, even when the client disconnects, messages will still be added to the queue, waiting for the client to receive them. The durable queues are identified using a combination of:
    • Container ID: This is essentially an ID that identifies the client; however, if the client establishes multiple connections, then this ID should be unique.
    • Link name (subscription to a particular topic/address).

AMQP Message Structure for IWXXM Data

The content of the AMQP messages that are used to distribute meteorological data follows the document AMQP Message Structure in MET-SWIM published on EUROCONTROL's SWIM wiki:

The most important facts from the guidance document:

  1. The meteorological data is sent as one report per AMQP message.
    1. A single AMQP message will only contain one METAR, SPECI, TAF, or SIGMET.
    2. MET SWIM implementations are not expected to distribute multiple reports encapsulated into a GTS-like bulletin using the collect:MeteorologicalBulletin  mechanism, which is generally deprecated.
  2. The IWXXM report XML is stored directly in the AMQP body (payload).
  3. There are various AMQP application properties included that contain the observation time or validity interval from the IWXXM reports, the ICAO code of the affected aerodrome or airspace, and other details. These can be used by clients to gain insight into the contents of the payload without having to decode the XML.

If you see any other properties on the AMQP messages that are not covered by the "AMQP Message Structure in MET-SWIM" guidance document, these should be considered experimental, and might be removed in future versions, for example:

  • geometry.* 
  • properties.integrity.* 
  • links.* 
  • topic 

WMO heading extension

When the data ingested into SWIM Weather contained a WMO heading, it is extracted and sent in the AMQP application property properties.ext.wmo-heading which contains a single string in the TTAAii CCCC YYGGgg BBB format (for example, "LPSQ31 LZIB 151200").

Note that if there was a collect:MeteorologicalBulletin on input to SWIM Weather containing, for example, 4 different IWXXM METAR reports, there will be 4 independent AMQP messages sent - one per report. However, the properties.ext.wmo-heading value will be the same for all four AMQP messages and equal to the WMO heading of the source bulletin.

AMQP Heartbeat Messages

This is an extension of the "AMQP Message Structure in MET-SWIM" guidance document. Heartbeat messages are currently not considered in the EUROCONTROL MET3SG documents; however, multiple MET SWIM providers use this mechanism.

Regular heartbeat messages are sent to the weather.aviation.metar, weather.aviation.taf, and weather.aviation.sigmet addresses at approximately 30-second intervals. Arrival of the heartbeat message indicates that the main subsystems of the SWIM Weather solution are running (data ingestion into Open Weather, AMQP broker, web server).

The heartbeat message structure is like this:

  • Message property subject  is set to "technical"
  • AMQP property properties.technical_message_type is set to "heartbeat"
  • AMQP property properties.issue_datetime  is set to RFC 3339 time of issue of the heartbeat message.
  • There is no payload.

AMQP Clients 

IBL Public Demo Client

A Python client that works with SWIM Weather is freely available on Github, licensed under Apache License, Version 2.0: https://github.com/iblsoft/swimdemo

The client might also work with systems based on MET SWIM software from other vendors or organisations. It was successfully tested with the DWD implementation of MET SWIM services.

IBL Moving Weather

IBL's Moving Weather can connect and download the IWXXM reports, allowing users with a license for Moving Weather (including the File Relay, Publish/Subscribe, and AMQP license modules) to set up data downloads using a File Relay or File Assembly communication channels.