Wat is MQTT en hoe kunnen industriële automatiseringsbedrijven het gebruiken?

Als u zich al met het industriële Internet of Things (IIoT) bezighoudt, zult u vast en zeker een nieuw acroniem zien dat overal wordt gebruikt:MQTT. Hoewel MQTT vrij nieuw is op het gebied van automatisering, bestaat het al meer dan 20 jaar. Het werd oorspronkelijk ontwikkeld als een protocol om gegevens van afgelegen olievelden te verkrijgen, maar tot voor kort werd het buiten deze nichetoepassing nooit veel gebruikt. Het komt nu naar voren als een van de belangrijkste protocollen voor digitale transformatieprojecten voor productie.

Wat is MQTT?

MQTT staat voor Message Queuing Telemetry Transport. Het is een client-server publish/subscribe messaging transport protocol, beschouwd als een lichtgewicht messaging protocol voor het verzenden van kleine pakketjes informatie in toepassingen met beperkte bandbreedte. In de kern wordt het beschouwd als een OASIS-standaard in het hart voor IoT-connectiviteit.

Geschiedenis

Aan het eind van de jaren negentig was er behoefte aan een lichtgewicht communicatieprotocol dat gegevens van afgelegen olielocaties zou kunnen verzenden met extreem lage verbindingssnelheden, misschien wel 300 baud. De strategie was om te profiteren van de mogelijkheden die al werden geboden in de transportlaag, die gebruikmaakte van het TCP-protocol. Het voorgestelde toepassingsprotocol zou alle redundantie verwijderen die aan de transmissielading heeft toegevoegd. Het moest ook stateful zijn en alleen bij uitzondering rapporteren. Met deze beperkingen in gedachten werkte Phillips 66 samen met Arlen Nipper van Cirrus Link Solutions en Andy Stanford-Clark van IBM om wat nu bekend staat als het MQTT-protocol te ontwikkelen.

Vroeg commercieel gebruik

Terwijl automatiseringsbedrijven begin jaren 2000 werden benaderd met het MQTT-protocol, was het enige andere commerciële gebruik ervan met de toepassingen Facebook Messenger en Apple Messages. Het belangrijkste kenmerk dat van belang was, is dat het protocol een staat en kwaliteit van de gegevens garandeert. Wanneer een afzender aan het typen was, zou de ontvanger dan de nu al te bekende drie stippen op het scherm zien. Het werd ook gebruikt in sommige toepassingen voor thuismonitoring en weergegevens, maar op dat moment was het gebruik van MQTT vrij beperkt.

Automatisering adoptie

Halverwege de jaren 2010 benaderde Arlen Nipper automatiseringsbedrijven opnieuw om het gebruik van MQTT te promoten. Er ontstond een behoefte om aanvullende productiegegevens te verzamelen zonder noemenswaardige netwerkvraag. Er waren echter enkele extra mogelijkheden die moesten worden ontwikkeld om acceptatie in de productie te krijgen. Cirrus Link Solutions ging samen met Inductive Automation verder met de ontwikkeling van wat nu de Sparkplug-standaard is, die attributen bevat die nodig zijn voor automatisering, namelijk een gedefinieerde set onderwerpen, een standaard payload en berichtcompressie.

Structuuroverzicht

MQTT gebruikt een structuur die vergelijkbaar is met de mappenstructuur van een computer. Ik zal het Windows-bureaublad als voorbeeld gebruiken. Het bureaublad heeft een map met de naam Mijn documenten. In Mijn documenten is er nog een map met de naam Familie, en in die map is een map voor elk gezinslid. Het pad naar mijn map zou Desktop/Mijn documenten/Familie/David zijn. Ik zou al mijn documenten aan David bewaren (publiceren). Iedereen die mijn documenten wilde lezen, zou David openen (abonneren).

Apparaten die het MQTT-protocol gebruiken, publiceren en abonneren zich op een vergelijkbaar onderwerppad dat een naamruimte wordt genoemd. Net als een computer, is het georganiseerd van meest algemeen naar meest specifiek. Hoe hoger het niveau waarop ik geabonneerd ben, hoe meer gegevens ik ontvang. Er zijn ook jokertekens die kunnen worden gebruikt om een ​​onderwerppad te definiëren. Een asterisk (*) omvat alles van het huidige niveau en lager. Een plus (+) verplaatst het pad een niveau lager. Ik heb verderop in het artikel een aantal voorbeelden opgenomen.

Afstemming met ISA-standaarden

De ISA-95-standaard is goed begrepen binnen de productie. Het beschrijft een standaardmodel en terminologie voor de interface tussen ondernemings- en controlesystemen. Hoewel het over het algemeen wordt gerealiseerd als een hiërarchie, te beginnen met een ERP bovenaan en apparaten onderaan, behandelt de standaard voornamelijk productiegegevens en hoe deze moeten worden gestructureerd. Omdat MQTT een onderwerpnaamruimte gebruikt, kunnen deze gemakkelijk worden afgestemd op de ISA-95-hiërarchie. Het wordt aanbevolen dat een onderwerpnaamruimte de Enterprise, Site, Area, Line en Cell volgt wanneer deze wordt samengesteld. De hoofdmap van de uitgever/abonnee moet ook op het juiste niveau aanwezig zijn. Een PLC die een cel bestuurt, zou bijvoorbeeld zijn gegevens moeten publiceren in een onderwerp van Enterprise/Site/Area/Line/Cell. Als een proceshistoricus specifiek is voor een gebied, moet hij alle gegevens op Enterprise/Site/Area-niveau abonneren.

Architectuur

Een van de veelvoorkomende vragen die voortkomen uit het gebruik van MQTT is wat er gebeurt als de connectiviteit wegvalt. Er zijn verschillende opties die kunnen worden gebruikt om deze situaties te verminderen. Een veelvoorkomende oplossing is om een ​​"store-and-forward"-methode te gebruiken. SCADA-systemen die zich in de controlelaag bevinden, blijven bijvoorbeeld gegevens verzamelen totdat de verbinding met de MQTT-broker wordt hervat. Opgemerkt moet worden dat wanneer de broker-verbinding wordt hervat, de tijdstempels van alle opgeslagen gegevens intact blijven.

MQTT ondersteunt ook het gebruik van back-upbrokers. Hoewel er een primaire broker is, schakelen de verbonden nodes automatisch over naar een andere broker als deze verbinding wordt verbroken. De relatie wordt over het algemeen geconfigureerd via een applicatie (zoals een SCADA-systeem) die deze functie ondersteunt.

Een andere oplossing wordt bereikt door het gebruik van clustering. Dit is typisch voor toepassingen die zich geen gegevensverlies kunnen veroorloven. Een veelvoorkomende opzet is om meerdere MQTT-makelaars in een cluster te hebben gerangschikt. Al deze brokers kennen elkaar en zullen berichten binnen het cluster delen. Wanneer de connectiviteit wegvalt, zullen uitgevers en abonnees van gegevens naadloos gegevens naar een andere broker routeren zonder enig verlies.

Het is gebruikelijk dat een bedrijfstoepassing gegevens van al zijn fabrieken gebruikt. Voor dit scenario ondersteunt MQTT het gebruik van bridging, vergelijkbaar met een store-and-forward-systeem. In deze architectuur zal de ene broker een deel van of de gehele naamruimte publiceren of overbruggen naar een andere broker. Anders gezegd, een plantenmakelaar zou een brug slaan naar een ondernemingsmakelaar. Zowel de gepubliceerde onderwerpen als de naamruimtestructuur kunnen worden gedefinieerd. Dit beperkt zowel de hoeveelheid gepubliceerde gegevens als context voor de ontvangende makelaar.

Alle gegevens publiceren zoals ze zijn met een asterisk (*) en geen structuur definiëren is de eenvoudigste manier, maar dit kan resulteren in veel onnodige en mogelijk verwarrende gegevens. Om wat gegevenscontext te bieden, kan een onderwerp worden toegevoegd aan het begin van de gepubliceerde onderwerpnaamruimte. Enterprise/Site kan bijvoorbeeld worden toegevoegd aan de plant Area/+/Cell-naamruimte, wat ertoe zou leiden dat Enterprise/Site/Area/+/Cell naar de Enterprise-broker wordt verzonden. Het resultaat is dat de gegevens op celniveau van alle lijnen beschikbaar zouden zijn vanuit dit systeem (let op het gebruik van de + wildcard).

Al deze scenario's kunnen worden ingezet. Een SCADA-systeem kan store-and-forward naar een MQTT-cluster gebruiken. Er kunnen primaire en back-upclusters zijn, maar dit zou waarschijnlijk onnodige complexiteit toevoegen. Ten slotte kan een fabriekscluster een brug slaan naar een bedrijfscluster om de integriteit van de gegevens te maximaliseren. Dit is geweldig voor bedrijfsanalyses en machine learning, omdat hiervoor aanzienlijke hoeveelheden gegevens van goede kwaliteit nodig zijn.

Beveiliging

Een van de grootste zorgen bij het verzenden en ontvangen van productiegegevens via internet is cyberbeveiliging. Hoewel de enige manier om echt veilig te zijn het gebruik van een luchtspleet is, verhindert dit het vermogen van een organisatie om digitaal te transformeren. Een van de belangrijkste voordelen van MQTT is de beveiliging. Terwijl andere communicatieprotocollen het openen van netwerkpoorten vereisen, vereist MQTT alleen een uitgaande verbinding met de broker. Fabrieken hoeven geen inkomende poorten te openen, wat erg aantrekkelijk is voor IT-organisaties.

Toekomstige overwegingen

In toekomstige artikelen zal ik algemene toepassingen met MQTT onderzoeken. Hoewel het de bedoeling is dat het protocol redelijk plug-and-play is, zal er waarschijnlijk interesse zijn in aanvullende technische details. Bedrijfsleiders willen misschien overwegen hoe MQTT hun huidige inspanningen op het gebied van digitale transformatie zal beïnvloeden. En natuurlijk willen technische leiders zeker weten welke impact MQTT op hen zal hebben.

Tot slot moet MQTT niet worden beschouwd als een vervanging voor bestaande architectuur. Afgestemd op de vereisten van Industrie 4.0, maakt het gebruik van wat al aanwezig is. Er zal behoefte blijven aan OPC UA en andere protocollen, aangezien deze uitgebreider zijn voor besturingstoepassingen. Als het echter gaat om het verzamelen van aanzienlijke hoeveelheden gegevens, is MQTT een uitstekende keuze.