Message Brokers und SMARTUNIFIER

Dies ist das Schema eines Message Brokers. Seine Verwendung für die Industrial Connectivity scheint ein ungeschriebenes Gesetz zu sein. Einige würden es als „Low Brainer“ bezeichnen, denn die Zentralisierung von Daten von Fertigungsanlagen erscheint als selbstverständlich. Weitere Konzepte und Ansätze wie die Asset Administration Shell, Unified Namespace oder Digital Twin scheinen diesen Ansatz zu unterstützen oder sogar zu fördern.

Weil er gut und effizient ist? Weil er alle Probleme der IIoT-Connectivity löst? Weil es keine andere Lösung gibt? Sicher nicht. In den meisten Fällen, weil ein Message Broker eine oft bereits installierte Softwarekomponente ist, viel Geld in der Einführung kostete und immer noch kostet. Betriebswirte nennen das Investitionsschutz.

Vorteile einer zentralisierten Data-Connectivity-Architektur

Es gibt mehrere Beschreibungen im Internet, die sehr gut aufzeigen, wie eine zentralisierte Architektur eines Message Brokers funktioniert. Kurz und knackig: Daten aus verschiedenen Quellen werden an eine zentrale Softwarekomponente gesendet. Datenkonvertierungen, Konsolidierungen, Transformationen, Sicherheitsfunktionen und Protokollkonvertierungen werden durchgeführt. Danach werden die gesammelten Daten an Zielsysteme (wie MES) oder Datenbanken verteilt.

Der einfache Aspekt dieses Ansatzes besteht darin, dass der Message Broker auf einem Server bereitgestellt wird und daher zentral verwaltet und konfiguriert werden kann. Es ist jedoch ein Irrglaube, dass Sie eine zentralisierten IT-Architektur benötigen, um dies effizient zu tun.

In diesem Zusammenhang ist es entscheidend, den Unterschied zwischen einer zentralisierten IT-Architektur und einer zentralisierten Enterprise Architektur zu verstehen. Während zentralisierte IT die Bereitstellung einer einzelnen Instanz (redundante Systeme zur Bereitstellung höherer Verfügbarkeit nicht mitgezählt) von (virtueller) Hardware und Software bedeutet, bedeutet zentralisierte Enterprise Architektur hingegen die zentrale Bereitstellung von Konzepten und Data Governance. Sehen Sie den Unterschied?

Unterschiede zu einer dezentralen Architektur

Lassen Sie uns testen, wie Kernfunktionen einer Data-Connectivity-Lösung dezentralisiert werden könnten.

Dieser Auszug einer Funktionsliste dient als Beispiel für eine kombinierte zentralisierte und dezentrale funktionale Architektur, wie sie in SMARTUNIFIER implementiert ist. Alle Funktionen, wie die Verwaltung von Information Models (z. B. Unified Namespace, Asset Administration Shell, Digital Twin) und die Teil der Enterprise Architektur sind, sind zentralisiert und sollten dies auch sein. Alle anderen Funktionen zur Konnektivität und Datenverarbeitung werden in einer dezentralen, wo auch immer bereitgestellten Communication Instance ausgeführt.

Aber warum? Was ist der Hauptvorteil der Dezentralisierung dieser Funktionen? Am Ende kommt es auf Performance, Verfügbarkeit, Stabilität und schließlich Skalierbarkeit an. Verbindungen zu Kommunikationspartnern müssen stabil laufen, idealerweise über Monate und Jahre hinweg ohne Unterbrechung und Datenverlust. Set it and forget it!

Eine dezentralisierte Architektur kümmert sich nicht darum, wie viele Communication Channels konfiguriert werden, wie viele Anlagen mit wie vielen Business Applications kommunizieren. Lassen Sie die Bottlenecks dort, wo sie schon immer waren, nämlich bei den Datenquellen, Datenzielen und Netzwerkkomponenten und nicht bei der Connectivity-Lösung.

Nachteile einer zentralisierten Architektur

Das Bild ganz oben in diesem Blog ist nur die halbe Wahrheit. Um etwas mehr Realismus in diesen Ansatz zu bringen, fügen wir nur ein Detail hinzu.

Es gibt nicht die eine Datenquelle, sondern mehrere. Wenn man dieses Detail dem Bild hinzufügt, wird etwas offensichtlich: Jeder Message Broker ist ein Single Point of Failure und darüber hinaus ein Bottleneck, der zwischen den Datenquellen und den übergeordneten Systemen positioniert ist. Sicher, entscheidende Funktionalitäten eines Message Brokers sind implementiert, um Datenverluste zu verhindern und das asynchrone Übertragen von Daten zu ermöglichen. Dies und alle anderen Logikfunktionen machen ihn jedoch zu einer riesigen, ressourcenintensiven und teuren Business Application. Fast sofort denkt ein IT-Architekt bzw. eine IT-Architektin an Load Balancing und Redundanz – zusätzliche Positionen in seiner oder ihrer CAPEX-Planung.

Lassen Sie uns nun den zentralen und dezentralen Ansatz nebeneinanderstellen und betrachten, wie Datenpakete übertragen werden.

Auf der linken Seite ist der zentrale Message Broker zu sehen, der Datenpakete verarbeitet, Shopfloor-Protokolle meist in einen Standard wie MQTT konvertiert, Nachrichten in die Warteschlange stellt und sie an übergeordnete Business Applications liefert.

Auf der rechten Seite ist die dezentrale SMARTUNIFIER-Architektur abgebildet, die aus mehreren Communication Instances mit eigenem Datenpakethandling, eigener Protokollkonvertierung von Shopfloor-Standards zu Business-Application-Standards oder mit einer Emulation von Geräten besteht, indem z. B. OPC-UA-Server bereitgestellt werden, die eine Fertigungsanlage simulieren können.

Und es gibt noch mehr. Je nach Inhalt der Datenpakete kann jede Instanz eine Real-Time Datenkontextualisierung durchführen, indem sie entsprechende Daten aus anderen Quellen (z. B. Fertigungsauftragsinformationen aus einem MES) sammelt, mit Anlagendaten (z. B. Daten eines Temperatursensors) kontextualisiert und diese kontextualisierten Daten (z. B. Produktionsaufträge, die mit bestimmten Temperaturen produziert wurden) Analysesystemen zur Verfügung stellt. Dies ist für zentralisierte Systeme, wie sie derzeit implementiert sind, nahezu unmöglich.

Ein weiterer Aspekt: Sobald mehr als eine Handvoll Datenpakete übertragen werden sollen, wird das Performance Bottleneck deutlich. Stellen Sie sich vor, der Message Broker stürzt im Falle eines unvorhergesehenen Ereignisses ab und vergleichen Sie dies mit einer abgestürzten SMARTUNIFIER Communication Instance (rot gefärbt). Im zweiten Fall können nur die Datenpakete (grün eingefärbt), die von dieser einen Instanz verarbeitet werden, verloren gehen. Alle anderen Instanzen und Verbindungen funktionieren völlig unbeeindruckt weiter. Das ist SMARTUNIFIERs Anteil an Stabilität und Verfügbarkeit in der Industrial Connectivity.

Wie eine dezentrale Architektur implementiert wird

Jeder, der bereits eine dezentrale Architektur implementiert hat, fürchtet nun das, was auf der Entwicklungsseite notwendig ist. Eine wichtige Entscheidung ist die Verwendung der richtigen Entwicklungsarchitektur.

Mit dem SMARTUNIFIER Manager werden Mappings, die mit dem Low-Code-Mapping-Editor konfiguriert werden, sofort in nativ ausführbaren Code übersetzt, in ein Communication-Instance-Entwicklerprojekt eingebunden, kompiliert (ja, mit einem richtigen Compiler) zu einem geschlossenen Paket, das ausschließlich für den Zweck dieser Datenkonnektivität optimiert ist, indem die konfigurierten Communication Channels, Information Models, Mappings, Datenkontextualisierung usw. verwendet werden. Diese spezialisierte Communication Instance kann dann mit dem SMARTUNIFIER Manager auf einem Edge-Device, in einem Cloud-Service (z. B. AWS) oder auf einem (virtuellen) Server bereitgestellt werden. Ihre einzige Daseinsberechtigung besteht darin, Konnektivität auf die stabilste, leistungsfähigste und einfachste Art und Weise bereitzustellen – dezentral.

SMARTUNIFIER leistet Pionierarbeit bei diesem dezentralen Ansatz und gewährleistet eine nahtlose Integration über verschiedene Industrieanlagen und IT-Systeme hinweg. Diese innovative Architektur eliminiert Single Points of Failure und erhöht die Zuverlässigkeit und Leistung in der industriellen Konnektivität. Alle unsere Kunden würden dies sofort unterschreiben.

Nachteile einer dezentralen Architektur

Es gibt keine Nachteile.

Warten Sie. Es gibt einen!

Wie bereits erwähnt, ist ein zentralisierter Message Broker oft bereits im Einsatz, manchmal schon seit Jahrzehnten. Selten möchten IT-Abteilungen dieses Investitions- und OPEX-Planungsartefakt vollständig eliminieren. Obwohl bei der Integration von immer mehr Fertigungsanlagen immer höhere Lizenzgebühren anfallen, soll der Status quo beibehalten werden. Einen bereits vorhandenen zentralisierten Message Broker durch eine dezentralisierte Lösung ersetzen? Das ist zu riskant und schützt nicht unsere Investition!

SMARTUNIFIER unterstützt Sie hier. Niemand hindert Sie daran, Ihren Message Broker als „südseitige Anlage“ oder „nordseitige Business Application“ zu betrachten. Stellen Sie die jeweilige Verbindung einfach mit SMARTUNIFIER her und binden Sie damit einfach entweder die Fertigungsanlage oder die Geschäftsanwendung an oder – noch intelligenter – verbinden Sie die Komponenten direkt Stück für Stück und bauen Sie eine dezentrale Architektur on-the-fly auf. Dies wird von vielen unserer Kunden als Brownfield-Ansatz durchgeführt.

SMARTUNIFIER unterstützt hybride Architekturen, sodass Sie im Laufe der Zeit reibungslos die eine Architektur in die andere transformieren können, risikominimiert und kosteneffizient.

Fassen wir zusammen:

Smarte Industrial Connectivity mit SMARTUNIFIER: Leistung, Sicherheit und einfache Skalierung

Unübertroffene Leistung und Sicherheit: SMARTUNIFIER wurde entwickelt, um sich in anspruchsvollen Industrial-Connectivity-Umgebungen zu bewähren, und bietet beispiellose Datenübertragungsgeschwindigkeiten und robuste Sicherheitsprotokolle. Vertrauen Sie auf SMARTUNIFIER, um sicherzustellen, dass kritische Prozesse reibungslos ablaufen und gleichzeitig die Datenintegrität gewahrt bleibt.

Mühelose Skalierbarkeit: Mit der Weiterentwicklung Ihres Unternehmens steigen auch Ihre Anforderungen an die Industrial Connectivity. SMARTUNIFIER lässt sich mühelos skalieren, um wachsenden Datenvolumina und komplexen Integrationsanforderungen gerecht zu werden, ohne die Effizienz oder Leistung der industriellen Konnektivität zu beeinträchtigen.

Intuitive Benutzeroberfläche: Im Gegensatz zu vielen anderen Industrielösungen verfügt SMARTUNIFIER über eine benutzerfreundliche Oberfläche, die auf die Industrial Connectivity zugeschnitten ist. Geben Sie Ihrem Team die Möglichkeit, Integrationen nahtlos zu verwalten und zu überwachen, um die Abhängigkeit von spezialisiertem IT-Personal bei der industriellen Konnektivität zu verringern.

Was SMARTUNIFIER in der Industrial Connectivity auszeichnet

Während Wettbewerber ebenfalls starke Integrationsfunktionalitäten bieten, zeichnet sich SMARTUNIFIER durch seine dezentrale Architektur und sein benutzerorientiertes Design von der Industrial Connectivity aus. Verabschieden Sie sich von zentralisierten Engpässen – der verteilte Ansatz von SMARTUNIFIER sorgt für einen kontinuierlichen, schnellen Datenfluss in der Industrial Connectivity. Darüber hinaus führt die unkomplizierte Benutzeroberfläche zu einer schnelleren Implementierung und kürzeren Schulungszeiten, was Ihrem Unternehmen einen Wettbewerbsvorteil bei der Industrial Connectivity verschafft.

Erfahren Sie die Zukunft der Industrial Connectivity mit SMARTUNIFIER

SMARTUNIFIER ist nicht nur ein Datenintegrationstool. Es ist eine revolutionäre Plattform, die entwickelt wurde, um industrielle Prozesse zukunftssicher zu machen und die Industrial Connectivity zu verbessern. Seine Mischung aus Dezentralisierung, hoher Leistung, Skalierbarkeit und Benutzerfreundlichkeit macht ihn zur ultimativen Wahl für Unternehmen, die ihre Industrial-Connectivity-Infrastruktur verbessern möchten. Gestalten Sie die Zukunft der Industrial Connectivity mit SMARTUNIFIER und erschließen Sie beispiellose Effizienz und Zuverlässigkeit in Ihren Prozessen. Transformieren Sie Ihre Industrial Connectivity mit dem fortschrittlichen Integrationssystem von SMARTUNIFIER und erleben Sie nahtlose Datenintegration, unübertroffene Leistung und mühelose Skalierbarkeit für Ihre industriellen Abläufe.