Connectivity across all levels is at the heart of Industry 4.0, IIoT, smart factories, and intelligent devices. The rigid, hierarchical automation pyramids with dividing layers are increasingly being replaced by more comprehensive network structures in which individual nodes are linked and exchange data with each other.

In order to realize such networking, the devices must be IIoT-capable. This means that they must be standardized and scalable, capable of interoperability between IT and OT systems, and ensure secure communication. Various communication protocols are available here—such as MQTT, OPC UA, AMQP, and REST API. In our multi-part blog article series, you can find out more about the key features of these IIoT communication protocols and for which use cases they are especially suitable. The third part of this article series is about AMQP.

What is AMQP and how does it work?

The Advanced Message Queuing Protocol (AMQP) is an interoperable asynchronous publish/subscribe communication protocol. It was originally developed in 2003 by the JPMorgan Chase Bank. In 2005, a working group was formed consisting of several companies, including RedHat, Microsoft, Software AG, and Cisco. After several experimental publications (0.8, 0.9.1, 0.10), version 1 of AMQP was finally published in 2011 and was also defined as an OASIS standard. Since then, it has undergone advanced development by OASIS. In 2014 it received ISO/IEC certification (19464:2014).

AMQP is primarily used in the enterprise and finance sectors, but also has the potential to become part of the industrial sector. It is very often compared to MQTT. At a higher level, the standards are similar, but below the surface, AMQP defines a complete ecosystem, unlike MQTT (more on this in the following sections). In the AMQP topology, both clients and brokers are referred to as containers (Figure 1). Containers are elements that form multiple nodes. A node can be a producer, consumer, or queue. Producers generate, consumers receive, and brokers store and forward messages. This means that a client can play the roles of both a consumer and producer. Within an application, these nodes can be either flat or hierarchically connected. On the outside, the nodes are connected by links. A link is a one-way route between two nodes that is formed at a higher level to a session. Each link has its unique identifier and if the connection between the two containers is interrupted, the links can be restored after resumption.

Another interesting aspect of AMQP is that in addition to brokers, routers can also be integrated into the network. The routers only implement the AMQP transport layer and perform the transmission tasks without queuing the messages. This means that the router establishes a synchronous connection between the producer and the consumer. The consumer and producer then communicate with each other using a standard request/response path. This feature is useful when the producer and consumer are in separate geographical locations. Within an AMQP topology, brokers and routers can exist in parallel and do not need to (but can) be integrated into a device. With regard to message transmission, AMQP has two transmission mechanisms: “settled” (at most once) and “unsettled” (at least once). The transmission format for the entire (annotated) message is XML, but the message body can use various encoding formats such as binary, JSON, Avro, or XML.

Interoperability: AMQP vs MQTT

AMQP is also relatively compact and defines only one interoperability feature: data types. In addition, using the links can ensure that a specific producer node is available, making this standard a little better suited to computer-machine interactions. However, this sounds more like a guessing game and less like a scenario in which the devices can communicate freely with each other. In terms of human-machine interaction, AMQP and MQTT are quite similar. The human should search the manual for the available producer data.

Real-time behavior: AMQP vs MQTT

Relatively short transport times are also possible since AMQP is also a publish/subscribe communication protocol. Due to the larger payloads, it does not achieve the speed of MQTT, but “almost in real-time” should also be possible with it.

Security of AMQP

AMQP does not provide integrated security as a protocol, but security can be achieved through several measures. This allows the underlying network connection to be encrypted with TLS and authentication of subscribers to be used with SASL.

Implementation: AMQP vs MQTT

Like MQTT, AMQP is based on publish/subscribe, but it delivers more options for transmitting messages. As a result, the resource requirements for the application are significantly higher and the implementation is considerably more complex. If the extended functionality requires the use of AMQP, the use of libraries is recommended for implementation. The AMQP transport protocol should be implemented in this way.

Application of AMQP

AMQP is primarily used in the business and enterprise sectors, but has its strengths in light implementations where a complete solution must be implemented independently of external application layer protocols such as HTTPS or WebSockets. Similar to MQTT, but more general, it is useful for functions such as:

• monitoring and globally releasing updates
• delivering data to offline clients at a later date
• monitoring risk-related data or controlling internal operations
• distributing events internally