14 Pattern
folgt.
15 Publish/Subscriber
Beim Publish / Subscriber oder kurz, PubSub, können Clients Daten in ein Netzwerk einspeisen (Publisher) oder beziehen (Subscriber) - aktuell bekanntester Vertreter ist MQTT. Es existiert keine direkte, logische Verbindung zwischen den Clients, was auch zeitliche Einflüsse bei der Datenverarbeitung mit sich bringt. Die Lücke zwischen den Clients wird durch eine Middleware geschlossen. Diese fungiert als Poststelle und koordiniert die Weiterleitung aber auch Themen wie Zugänglichkeit, Redundanz usw. Wichtig: Die Middleware hat keine Prozesslogik, kümmert sich daher rein um Kommunikation. Sie unterhält aber Topics, als Sinnbild: Postfächer, in denen Publisher Daten hinterlegen und Interessenten bei Veränderung benachrichtigt werden können. Dabei können mehrere Publisher das selbe Postfach, oder auch mehrere Subscriber die gleichen Daten nutzen.
Mit diesem Prinzip kann das grosse Problem von Datensilos adressiert werden. Stellen wir uns einen Client als Auftragsverwaltung und einen weiteren als Maschinen-SPS vor, können diese ihre Daten über Topics austauschen. Möchte man nun ein HMI installieren, auf dem Mitarbeitende vor Ort die nächsten Aufträge sehen, bedarf dies klassisch der Einrichtung einer Schnittstelle zur Auftragsverwaltung. Mit dem Publish/Subscriber Prinzip, kann das HMI nun aber lediglich das Topic der Auftragsdaten abonnieren und wird automatisch über alle Aufträge informiert. Ohne das die ursprüngliche Kommunikation und Systeme angepasst werden mussten. Es konnte also Mehrwert durch bestehende Daten ermöglicht werden.
15.1 Brokerbasierte Middleware
Von Protokollen wie MQTT oder AMQP kennt man vor allem Brokerbasierte Ansätze. Dabei übernimmt ein Serverdienst die zentrale Verwaltung der Kommunikation. Jeder Client verbindet sich mit dem Broker, um an der Datenkommunikation teilzunehmen. Aus Benutzersicht ist dies ein sehr angenehmes Prinzip. Man kann auf dem Broker sein Netzwerk in Bezug auf Sicherheit, Zugänglichkeit oder auch Lastverteilung konfigurieren und kann den Netzwerkverkehr an einer zentralen Stelle nachvollziehen. Ein weiterer Vorteil ist die Netzwerkfreundlichkeit. Jeder Client verbindet sich mit dem Serverdienst - aus Netzwerksicht bedeutet dies, dass die Verbindung immer vom Inneren nach aussen aufgebaut wird. Denkt man dabei an sein Heimnetzwerk, sind Teilnehmer oft hinter einem NAT - Die Verbindung von Innen nach Aussen verhindert dabei eine Aufwändige Konfiguration von Firewall und Router, da Verbindungen von Innen nach Aussen vertrauenswürdiger angeschaut werden. Ein Broker kann dabei sehr nahe an der Maschine, aber auch sehr weit weg in der Cloud arbeiten. Ganz angepasst an die Bedürfnisse für den Prozess.
Vorteile:
- Einrichten eines Serverdienstes an einem passenden Ort (Steuerung, Unternehmensnetz, Cloud..)
- Zentrale Verwaltung für Benutzer- oder Zugriffssteuerung
- Netzwerkfreundlich (Firewall, NAT)
- Last pro Teilnehmer immer gleich (Nur eine Verbindung)
- Gut skalierbar
- Einfach mit vielen OpenSource Vertretern (z.B. Mosquitto)
- Broker unterhält QoS (Sichere Ankunft von Daten, Umgang mit Clients die Offline sind)
Nachteil:
- Zentrale Stelle = Single Point of Failure, es sind also IT-Lösungen für Backup/Redundanz gefragt (z.B. Cluster)
- Schwierig den Kommunikationsverlauf nachzuvollziehen
- Je nach Zeitanforderung kann ein Broker auch zu langsam sein
15.2 Brokerless Middleware
Die Kommunikation zwischen den Clients muss nicht zwingend über einen Serverdienst funktionieren. Gerade wenn man an IO-Kommunikation in einem Maschinennetzwerk denkt, möchte man die Daten sehr schnell verfügbar haben und nicht unbedingt über eine zentrale Stelle schicken. Ein einfaches aber starkes Konzept sind dabei Multicasts. Anstatt Daten auf einem Topic zu hinterlegen, werden Daten direkt in einem Kanal publiziert, auf den alle Subscriber Zugriff haben.
Vertreter die dieses Prinzip anbieten sind zum Beispiel OPC UA Pub/Sub oder auch die Kommunikation mittels DDS (Data Distribution Service, z.B. FastDDS). Aber auch bei klassischen Feldbussen findet man solche Prinzipien wie bei EthernetIP oder auch Profinet, wenn auch selten verwendet.
Vorteil:
- Schnelle Datenverarbeitung, keine Wasserträger
- Einfach, keine zusätzliche Software benötigt
Nachteil:
- Multicast, meist nur in der direkt angeschlossenen Broadcastdomäne möglich (Routing benötigt mehr Netzwerkthemen)
- Nahezu kein QoS (Wenn eine Nachricht verpasst wurde ist das pech)
- Keine Verwaltung von Clients
- Keine zentrale Verwaltung von Sicherheitsthemen wie Verschlüsselung und Authentifizierung
16 Producer/Consumer
Das Prinzip von Producer/Consumer verfolgt weniger die Idee einer einfachen Datenzugänglichkeit wie bei Publish/Subscriber, sondern eher das verwaltete Balancing der Datenverarbeitung. Das Stichwort bei diesem Prinzip ist Warteschlange / Queue. Die Umsetzung davon kann sehr variieren, aber bei diesem Prinzip ist immer eine Entkopplung zwischen Producer und Consumer nötig.
In der Softwarewelt findet das Producer/Consumer Prinzip oft bei schnellen IO Daten Anwendung. Ein Sensor mit einer hohen Abtastfrequenz liefert entsprechend schnell Daten an eine Software. Die Software kann aber nicht im selben Takt die Daten annehmen, verarbeiten und Darstellen, weshalb eine Entkopplung stattfinden muss. Im einfachsten Fall speichert der Sensor die Daten in einer Queue - Er speichert schnell aber immer nur wenig Daten. Auf der anderen Seite holt die Software einen nächsten Batch aus der Queue, sobald die nötigen Ressourcen vorliegen. Dabei können es aber direkt 1000 Sensorwerte sein.
In der Integrationswelt finden wir genau das gleiche Pattern. Auf einem Edge-Device (z.B. SPS) werden Daten erfasst und müssen in einer Cloud gespeichert werden. Würde nun die SPS jeden Messwert an eine Datenbank schicken, würde dies zu viel Netzwerkoverhead und Verwaltungsaufwand in der Software führen. Schöner wäre, wenn die Daten in eine Queue gehen und die verarbeitende Software entsprechend der eigenen Möglichkeiten
16.1 Vertreter in der Industrie
Aktuelle Vertreter in der Industrie sind Protokolle wie AMQP oder auch Software wie Apache Kafka. Diese bilden die Möglichkeit zur Bildung von Queuekanälen zwischen Sender und Empfänger. AMQP ist dabei z.B. mit RabbitMQ ein einfacherere Vertreter. Apache Kafka ist dabei deutlich komplexer, kann aber mehr als 1’000’000 Datenpunkte/s verwalten.