Smarte Fabrik

Fahrerlose Transportsysteme mit MQTT – aber wie?

26. Mai 2020, 9:07 Uhr | von Anja Helmbrecht-Schaar

In einer intelligenten Fabrik interagieren verschiedenen Akteure miteinander und tauschen kontinuierlich Daten aus. So zum Beispiel fahrerlose Transportfahrzeuge. Wie eine sichere Kommunikation klappt, zeigt HiveMQ.

Fahrerlose Transportsysteme (FTS) und Fahrerlose Transportfahrzeuge (FTF) spielen eine Schlüsselrolle in allen Planungsszenarien für automatisierte und vernetzte Fabriken. Der Trend zu hochgradig individualisierten Produkten erfordert neue Ansätze sowohl beim Planen von Produktionsstationen als auch bei der Organisation der Materialversorgung.

Es ist nötig, die Schnittstellen und Datenstrukturen für den durchgängigen Einsatz der Techniken rechtzeitig zu standardisieren. Deshalb definiert die VDA-5050-Spezifikation die Kommunikationsschnittstelle für FTS unter anderem zum Austausch von Auftrags- und Statusdaten zwischen einer zentralen Leitsteuerung und FTF für intralogistische Prozesse.

MQTT – das Standard-Kommunikationsprotokoll im Internet der Dinge (IoT) – ist heute im Industrie-4.0-Umfeld nicht mehr wegzudenken und wurde mit der VDA-5050-Spezifikation zum Standard für fahrerlose Transportsysteme (FTS) und fahrerlose Transportfahrzeuge (FTF) erklärt.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Inhalt der VDA 5050 Spezifikation

Zusammengefasst umfasst die Spezifikation folgende Ideen:

Die Definition einer Basis für die Integration von Transportsystemen in eine kontinuierliche Prozessautomatisierung.
Eine Erhöhung der Flexibilität durch mehr Autonomie der Fahrzeuge.
Eine Reduktion der Implementierungszeit über »Plug & Play«-Mechanismen.
Das Verwenden eines zentralen Steuerungssystems mit der entsprechenden Logik für alle Fahrzeugtypen und Hersteller.
Eine gemeinsame Schnittstelle zwischen Fahrzeug und Steuerungssystem.
Die Möglichkeit der Integration proprietärer Steuerungssysteme.

Zur Umsetzung der Ziele legt VDA 5050 MQTT als Kommunikationsprotokoll zwischen Akteuren, sowie JavaScript Object Notation (JSON) als Datenformat fest.

Herausforderungen und Voraussetzungen

Die Herausforderung besteht darin, einen soliden Lösungsansatz zu finden. Derzeit sind eine Reihe von MQTT-Implementierungen, die eine unterschiedliche Anzahl an Features bieten, auf dem Markt erhältlich. Neben der Unterstützung des MQTT-Protokolls selbst, sind wichtige zusätzliche Features essenziell, um ein sicheres und stabiles System betreiben zu können.

Herausforderungen sind:

Die VDA-Spezifikation beschreibt einige datenbezogene Merkmale, die mit dem MQTT-5-Standard perfekt zu beschreiben sind. Daher sollten die MQTT-spezifischen Teile der Anwendung MQTT 5 unterstützen.
Sicherheit ist eine sehr wichtige Schlüsselfunktion, die sowohl vom Client als auch vom Broker unterstützt werden sollte.
Um Systemänderungen ohne Ausfallzeiten zu unterstützen, muss die Anwendung hoch verfügbar sein und fortlaufende Upgrades und Migrationsszenarien unterstützen.
Der MQTT Broker muss skalierbar sein und eine wachsende Anzahl von Geräten oder Nachrichten unterstützen.
Um andere Systeme zu integrieren oder business-spezifische Funktionen per Plug & Play hinzuzufügen, sollte der MQTT Broker erweiterbar sein.
Das Datenformat der Nachrichten ist durch die VDA spezifiziert (JSON) und es sollte die Möglichkeit geben, das vor dem Veröffentlichen einer Nachricht zu verifizieren, um das Produkt robuster und sicherer zu machen.
Die zentrale Überwachung und Nachverfolgung für bestimmte Geräte, Topics oder Nachrichten ist in der Produktionsumgebung unerlässlich und sollte immer möglich sein.

Komponenten einer MQTT-Plattform

Für ein robustes, MQTT-basiertes Produkt, das ein Anwender zum Implementieren der VDA-Spezifikation verwendet, benötigt er folgende Komponenten:

Es bedarf eines MQTT Message Brokers, der sich ideal für die Umsetzung von Geschäftsanforderungen aus IoT-Anwendungsszenarien nutzen lässt. Der MQTT-Broker bietet eine schnelle, effiziente und zuverlässige Übertragung von Nachrichten zu und von verbundenen IoT-Geräten. Er stellt die zentrale MQTT-Infrastrukturkomponente dar und muss ausfallsicher, robust und skalierbar sein, um die erforderlichen Leistungsgarantien zu bieten. Es sollte sichergestellt werden, dass das MQTT-Protokoll in den Versionen 5 und 3 zu 100 Prozent unterstützt wird und der Betrieb von Szenarien mit gemischten Versionen möglich ist, so wie es beispielsweise beim HiveMQ Enterprise MQTT Broker vorzufinden ist.

Der Broker muss wie bei HiveMQ über ein Public Extension Software Development Kit (SDK) verfügen. Die offene API, ermöglicht es so, Plug-Ins zu erstellen, die für ihre spezifischen Infrastrukturen geeignet sind. Das Extension-Framework kann der Anwender nutzen, um den Broker mit benutzerdefinierter Geschäftslogik zu erweitern oder in praktisch jedes System zu integrieren.

MQTT Clients umfassen alle Geräte und Software, die über eine MQTT-Schnittstelle kommunizieren. In dem Szenario befinden sich folgende Clients: das Steuerungssystem (CS) und jedes automatisierte geführte Fahrzeug (AGV).

MQTT 5 Client-Bibliotheken sind für verschiedene Sprachen verfügbar, zum Beispiel Eclipse PAHO. Sie bieten MQTT-5-Unterstützung für C und C#, MQTTnet für .net-Umgebungen und den HiveMQ MQTT Client. Der Client ist eine Open-Source-MQTT-Java-Bibliothek, für das Verwenden in Hochleistungs-Szenarien mit geringen Speicheranforderungen.

Administratoren benötigen für das Überwachen und Protokollieren der MQTT-Infrastruktur ein Monitoring, um ein effektives Troubleshooting für die Gesamtanwendung zu garantieren. Auf das Monitoring Dashboard sollte nur über vertrauenswürdige IP-Adressen zugreifbar sein. Die Zugriffsregeln sind zum Beispiel bei HiveMQ, mithilfe der Enterprise Security Extension definiert.

Der HiveMQ Enterprise Broker verfügt über ein solches Kontrollzentrum, in dem Administratoren insbesondere den MQTT-Nachrichtendurchsatz oder bestimmte Fehler für verlorene MQTT-Nachrichten verfolgen können. Neben den Kern-Metriken, die im Dashboard angezeigt werden, bietet HiveMQ hunderte Metriken, die sehr hilfreich für ein zentrales Monitoring zu verwenden sind, da das Überwachen ein wichtiger Bestandteil des Betreibens jeder Anwendung ist. HiveMQ unterstützt zentrales Monitoring für Anwendungen wie Prometheus, InfluxDB und Grafana. Dafür stehen Open-Source-Erweiterungen zur Verfügung, sodass die erforderlichen Funktionen problemlos anzuschließen sind.

Zusammenspiel der Komponenten im MQTT Szenario

Bild 1 zeigt die Komponenten der Architektur, die miteinander in Beziehung stehen. Alle Clients (Leitstelle und Transportfahrzeuge) kommunizieren idealerweise über eine Adresse – via Load Balancer mit dem Broker. Aus externer Sicht betrachtet, arbeitet der MQTT Message Broker als eine logische Einheit, aus interner Sicht als Cluster von Broker-Instanzen. Der Broker verwendet eine Security Extension für die Authentifizierung und Autorisierung sowie eine Extension für die Validierung des JSON payloads und eine weitere Extension für das Monitoring der Anwendung.

Die Akteure des Brokers sind die MQTT Clients. Als Hauptanwendungsfall sendet der Client des Steuerungssystems (CS) Informationen an die fahrerlosen Transportfahrzeuge (AGV) und erwartet Informationen zum relevanten Status oder mögliche Fehlerinformationen der Fahrzeuge.

Die Daten für das zentrale Steuerungssystem werden in Form einer Grundkonfiguration und der Gerätekonfigurationen für jedes Fahrzeug (FTF) bereitgestellt. Zu verwendende JSON-Formate werden in JSON-Schemata definiert. So sind die Schemata verfügbar und sind sowohl vom Broker als auch vom Kontrollsystem zu Validierungszwecken zu verwenden.

Sicherheit mit dem HiveMQ Broker

Es ist herausfordernd, für Anwendungen, die der VDA 5050-Spezifikation genügen sollen, eine optimale Lösung zu finden. Ein Produkt ist mit Hilfe von MQTT 5 und der Verwendung eines MQTT Message Brokers, beispielsweise HiveMQ, implementierbar, da die Plattform alle erforderlichen Schlüsselfunktionen für den Betrieb eines sicheren und stabilen Systems bietet.

Für den Einsatz von MQTT 5 spricht, dass datenbezogene Funktionen wie der Einsatz definierter Formate und deren Validierung sowie das Verwenden von Metadaten perfekt zu beschreiben sind. Es gibt bereits Implementierungen des neuen Protokollstandards in verschiedene Sprachen. HiveMQ unterstützt sowohl MQTT 5- als auch MQTT 3-Clients in gemischten Szenarien.

Sicherheit ist eine wichtige Eigenschaft – das Verwenden von Standard-Anwendungen, die die Sicherheit in verschiedenen Varianten unterstützen, ist optimal. Gerade wenn die Möglichkeit bestehen soll, verschiedene Hersteller in ein Steuerungssystem zu integrieren.

Um Systemanpassungen ohne Ausfallzeiten zu unterstützen, muss die Anwendung hoch verfügbar sein und laufende Upgrades und Migrationsszenarien unterstützen. HiveMQ ist hoch skalierbar, im laufenden Betrieb aktualisierbar oder erweiterbar und unterstützt problemlos eine hohe Anzahl von Automated Guided Vehicles. Außerdem bringt HiveMQ mit dem Control Center eine Monitoring-Anwendung zur Überwachung und Verfolgung bestimmter Clients, Themen oder Nachrichten in der Produktionsumgebung mit.

Um andere Systeme wie ein zentrales Log-System zu integrieren oder Geschäftsfunktionen hinzuzufügen, ist HiveMQ über sein Extension System erweiterbar. Eine große Anzahl von Open-Source- und Standard-Anwendungen für Extension ist bereits verfügbar. Mit Hilfe der HiveMQ Extension API ist nahezu jede geschäftsspezifische Anwendung implementierbar. Die Kombination von HiveMQ mit MQTT 5 zur Implementierung der VDA 5050-Anwendungsfälle bietet einen guten Ansatz. HiveMQ zeigt im VDA 5050 Whitepaper ein detaillierten Architekturvorschlag für Anwendungsfälle auf. Das Whitepaper können Sie auf der Homepage von HiveMQ einsehen.