Data Subscriptions using AMQP

Connections

You will need an AMQP 1.0 client that supports SSL connections.

1. Only SSL connections are allowed on ports 5671 and 5672.
2. amqp.swim.iblsoft.com:5672 – implements server TLS and does not verify the client's certificate. However, clients can verify the server's authenticity using the HARICA testing certificate.
3. amqp.swim.iblsoft.com:5671 – implements mutual TLS and verifies the client certificates.
   1. In this case, you need to get a client certificate signed by the HARICA root testing certificate.

Please see also Working with Certificates for more details. The connection to 5672 will work even without the HARICA certificate, in which case the server authenticity verification will be bypassed.

	Note
	Under normal circumstances, port 5672 of the AMQP protocol is reserved for unencrypted connections. While the Artemis ActiveMQ broker supports such an unencrypted connection mode, we have chosen to disable it and only allow SSL connections. As explained above, the connection to 5672 requires SSL but does not require client or server certificate verification and can work without either.

Subscription Addresses (Topics)

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

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 into the queue, waiting for the client to receive them. The durable queues are identified using a combination of:
  • Container ID (basically an ID that identifies the client, but if the client makes multiple different connections, then this 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 (CP1), which is the current version of agreed AMQP guidance between MET3SG members and represents the state as of EUROCONTROL MET3SG/08 meeting in October 2025. Most importantly:

1. The IWXXM data is sent as one report per AMQP message
2. The IWXXM data is stored in the AMQP payload
3. There are various AMQP application properties included that contain the observation time or validity of IWXXM reports, affected aerodrome or airspace ICAO code, and others.

If you see any other properties on the AMQP messages that are not covered by the MET3SG guidance, these are experimental extensions, which might be removed in future versions, for example:

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

AMQP Heartbeat Messages

Regular heartbeat messages are sent to the weather.aviation.metar, weather.aviation.taf, and weather.aviation.sigmet addresses at approximately 60-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 

Python Client Example

A Python example client that connects to amqp.swim.iblsoft.com  is on Github, licensed under Apache License, Version 2.0:
https://github.com/iblsoft/swimdemo

IBL Moving Weather (Message/File Switching System)

IBL's Moving Weather can connect to amqp.swim.iblsoft.com  and download the IWXXM reports, so the users who have a license for Moving Weather can set up the data download using a communication channel.