AMQP

Wat is AMQP?

AMQP (Advanced Message Queuing Protocol) is een open, binair applicatieprotocol voor betrouwbare, asynchrone uitwisseling van berichten tussen applicaties, meestal via een message broker, en is in versie 1.0 gestandaardiseerd door OASIS (2012) en als ISO/IEC 19464:2014. Binnen OT, het Industrial Internet of Things en OT-convergentie verbindt AMQP vooral systemen op enterpriseniveau: SCADA, historians, MES, ERP en cloudplatformen. Waar MQTT en CoAP zijn geoptimaliseerd voor lichte telemetrie vanaf kleine apparaten, ligt de kracht van AMQP in gegarandeerde aflevering, flow control en flexibele routering.

🧠 Waar komt AMQP vandaan en welke versies bestaan er?

AMQP ontstond begin jaren 2000 bij JPMorgan Chase. Banken gebruikten veel message-oriented middleware, maar elk product had een eigen, gesloten protocol. Wie een broker koos, zat vast aan de bibliotheken van die leverancier. AMQP moest een open protocol worden waarmee componenten van verschillende leveranciers, talen en besturingssystemen berichten kunnen uitwisselen.

Belangrijk voor de praktijk: “AMQP” zijn eigenlijk twee verschillende protocollen die niet compatibel zijn.

Wie “we gebruiken AMQP” hoort, moet dus altijd vragen welke versie. Een Azure-koppeling spreekt AMQP 1.0, een klassieke RabbitMQ-installatie meestal 0-9-1. RabbitMQ ondersteunt sinds versie 4.0 (2024) beide protocollen native op dezelfde poort 5672; de protocolheader van de client bepaalt welke versie de verbinding gebruikt.

🔧 Hoe werkt AMQP 0-9-1 met exchanges en queues?

Het model van AMQP 0-9-1 is het bekendste beeld van AMQP. De bouwstenen zijn:

Er zijn vier standaardtypen exchanges:

Zo ondersteunt één broker zowel point-to-point (één queue, meerdere consumers die het werk verdelen) als publish/subscribe (één bericht, meerdere queues). Een routing key als temperatuur.fabriek1.lijn3 maakt fijnmazige filtering mogelijk zonder de producer aan te passen.

🔄 Wat is er anders aan AMQP 1.0?

AMQP 1.0 beschrijft geen broker, maar alleen hoe twee partijen veilig en betrouwbaar berichten overdragen. Een connection (TCP, optioneel met TLS) bevat sessions, en binnen een session lopen links: eenrichtingskanalen van een bron naar een doel, aangeduid met een adres. Wat er achter dat adres zit, een queue, een topic of een andere applicatie, is aan de implementatie.

Drie eigenschappen maken AMQP 1.0 interessant voor industriële integratie:

• Credit-based flow control - de ontvanger geeft per link aan hoeveel berichten hij aankan, zodat een trage cloudverbinding of een overbelaste consumer de afzender afremt in plaats van berichten kwijt te raken.
• Afleveringsgaranties per bericht - van “fire-and-forget” (at-most-once) tot bevestigde aflevering (at-least-once) en exactly-once via tweefasige afhandeling (settlement).
• Multiplexing - over één TLS-verbinding lopen meerdere sessions en links. Azure IoT Hub raadt AMQP daarom aan voor veld- en cloudgateways die namens veel apparaten, elk met een eigen identiteit, berichten doorsturen.

⚡ Welke betrouwbaarheidsmechanismen biedt AMQP?

Een deel van de betrouwbaarheid zit in het protocol, een deel in de broker. Dat onderscheid is belangrijk bij het ontwerp.

Bij RabbitMQ zijn de oude “classic mirrored queues” in versie 4.0 verwijderd; voor hoge beschikbaarheid zijn quorum queues op een cluster van drie of vijf nodes nu de standaard. Een oneven aantal nodes is aanbevolen: met drie nodes mag er één uitvallen en met vijf twee, omdat een meerderheid (quorum) beschikbaar moet blijven; een vierde node voegt geen extra fouttolerantie toe.

📡 Hoe verhoudt AMQP zich tot MQTT en Kafka?

AMQP, MQTT en Apache Kafka worden vaak in één adem genoemd, maar lossen verschillende problemen op.

In de praktijk vullen ze elkaar aan. Een veelvoorkomende keten is: PLC naar edge-gateway via OPC UA of Sparkplug B, van de gateway naar de cloud via AMQP of MQTT, en in het datacenter een Kafka-cluster voor langetermijnopslag en analyse. Een Unified Namespace draait meestal op MQTT; AMQP komt vaker voor bij de koppeling met bedrijfsapplicaties.

🏭 Waar wordt AMQP gebruikt in industriële automatisering?

Binnen industriële automatisering zit AMQP zelden op het veldniveau. Het protocol is te zwaar voor sensoren en niet deterministisch genoeg voor realtime regelen. Het speelt een rol hogerop in het Purdue Model:

Het voordeel van de broker in deze OT-architectuur is ontkoppeling: een historian die even offline is, mist geen berichten, omdat de queue ze bewaart. De architectuur wordt wel afhankelijk van de broker zelf, die daarom redundant moet zijn.

🔐 Hoe beveiligt u een AMQP-omgeving?

AMQP biedt de bouwstenen voor security en cybersecurity, maar de standaardinstellingen van een broker zijn niet automatisch veilig. Een gecompromitteerde broker geeft een aanvaller controle over alle berichtstromen.

RabbitMQ staat het standaardaccount guest sinds versie 3.3 alleen toe vanaf localhost, maar dat account hoort in productie verwijderd te worden. Voor AMQP 1.0 eist RabbitMQ altijd SASL.

Passend bij IEC 62443 hoort een broker in een eigen zone, vaak de IDMZ tussen OT en IT, met netwerksegmentatie en een industriële firewall die alleen de benodigde poorten toelaat. Hardening, logging van verbindingen en toegangsfouten en security monitoring maken het geheel af. NIST SP 800-82 en ISO 27001 geven het bredere kader. Organisaties die onder de Cyberbeveiligingswet vallen, moeten zo’n broker als onderdeel van hun kritieke keten meenemen in de risicoanalyse.

🛠️ Hoe zet u AMQP stapsgewijs op in een OT-omgeving?

Een praktische aanpak voor een eerste AMQP-koppeling tussen productie en IT:

1. Kies de versie bewust - AMQP 1.0 voor koppelingen met Azure en voor interoperabiliteit tussen leveranciers; 0-9-1 als u al een RabbitMQ-ecosysteem heeft met bestaande clients.
2. Ontwerp de routering - leg een naamgeving vast voor routing keys of adressen, bijvoorbeeld site.gebied.lijn.signaal, en houd die gelijk aan de ISA-95-hiërarchie die u elders gebruikt.
3. Plaats de broker in de juiste zone - niet in het besturingsnetwerk zelf, maar in een DMZ-segment waar OT publiceert en IT consumeert.
4. Regel beschikbaarheid - een cluster van drie nodes met quorum queues, persistente berichten en dead-letter queues voor berichten die niet te verwerken zijn.
5. Beveilig vanaf dag één - TLS met certificaten onder certificaatbeheer, een account per applicatie en minimale rechten.
6. Monitor actief - queue depth, aantal unacked berichten, geheugen- en schijfalarmen van de broker en certificaatverloopdata.
7. Neem de broker op in het beheer - lifecyclemanagement, patchmanagement, configuratiebeheer van de definities (exchanges, queues, gebruikers), een back-up daarvan en een disaster recovery-plan.

Typische vuistregel: een gezonde queue staat bijna leeg. Een queue die gestaag groeit, betekent dat consumers het tempo niet bijhouden, en dat is een vroege waarschuwing voordat de broker zijn geheugengrens bereikt.

❓ Veelgestelde vragen

Is AMQP hetzelfde als RabbitMQ?

Nee, AMQP is een protocol en RabbitMQ is een broker die dat protocol implementeert. RabbitMQ is gebouwd rond AMQP 0-9-1 en ondersteunt sinds versie 4.0 ook AMQP 1.0 native. Andere producten zoals Azure Service Bus en ActiveMQ Artemis spreken AMQP 1.0.

Welke poort gebruikt AMQP?

AMQP gebruikt standaard TCP-poort 5672 voor onversleuteld verkeer en poort 5671 voor AMQP over TLS. In omgevingen waar alleen HTTPS naar buiten mag, kan AMQP via WebSockets over poort 443 lopen, zoals Azure ondersteunt. In OT-netwerken hoort alleen de versleutelde variant open te staan.

Is AMQP 1.0 compatibel met AMQP 0-9-1?

Nee, AMQP 1.0 en AMQP 0-9-1 zijn verschillende protocollen met een ander model. AMQP 0-9-1 legt exchanges en queues vast, terwijl AMQP 1.0 alleen de berichtoverdracht via connections, sessions en links beschrijft. Een client voor de ene versie kan niet zonder meer met een broker van de andere versie praten.

Wanneer kiest u AMQP in plaats van MQTT?

AMQP is de betere keuze wanneer berichten tussen bedrijfsapplicaties gegarandeerd en geordend moeten aankomen, wanneer u rijke routering nodig heeft of wanneer een gateway veel apparaten over één verbinding bundelt. MQTT past beter bij kleine apparaten, sensoren en een Unified Namespace, omdat de client lichter is. Veel architecturen gebruiken beide.

Is AMQP geschikt voor realtime besturing?

AMQP is niet geschikt voor deterministische realtime besturing van een proces. De brokerarchitectuur, buffering en TCP-verbindingen geven variabele latency. Voor regelen blijven veldbussen en industrieel Ethernet zoals PROFINET de juiste keuze; AMQP hoort op het niveau van data-integratie.

Is AMQP veilig?

AMQP ondersteunt TLS-versleuteling en SASL-authenticatie, maar is alleen veilig als die ook zijn ingeschakeld en goed geconfigureerd. Standaardaccounts, onversleuteld verkeer op poort 5672 en een open beheerinterface zijn de meest voorkomende zwakke plekken. Een AMQP-broker hoort in een gesegmenteerde zone met minimale rechten per applicatie.

📌 Samengevat

AMQP is het open messagingprotocol voor betrouwbare, ontkoppelde berichtuitwisseling tussen industriële systemen, bedrijfsapplicaties en de cloud. Het onderscheid tussen AMQP 0-9-1 (RabbitMQ, exchanges en queues) en de ISO-norm AMQP 1.0 (Azure, links en flow control) is essentieel bij elke keuze. Gebruik AMQP op het integratieniveau naast MQTT, niet voor realtime besturing, en beveilig de broker met TLS, SASL, minimale rechten en een eigen zone in uw OT/IT-architectuur.