Die Integrationsplattform Manufacturing Integration Platform (MIP) sorgt für mehr Interoperabilität in der Smart Factory. Damit das funktioniert, basiert die MIP auf standardisierten Technologien. Über einen Teil dieser Technologien spricht Bernd Berres, Chief Product Management bei MPDV, im Interview.
Herr Berres, eine der wichtigsten Technologien, die in Verbindung mit der MIP zum Einsatz kommen, ist REST Webservices. Warum ist das so?
Bernd Berres: Webservices sind die wohl am weitesten verbreitete Technologie, wenn es um die Kommunikation zwischen Anwendungen geht. Nahezu jede aktuelle Programmiersprache und jede Art von digitalem System kennt Webservices. Daher eignet sich diese Technologie hervorragend für eine Integrationsplattform wie unsere MIP. REST beinhalten, dass die Kommunikation „stateless“ ist. Das bedeutet, dass jede Anfrage für sich steht und nicht auf eventuell vorangehende Kommunikation Rücksicht genommen werden muss. Das vereinfacht die Kommunikation enorm. Webservices basieren auf dem Request-Response-Prinzip. Das bedeutet, dass auf jede Anfrage eine Antwort folgt. Das kann im einfachsten Fall ein OK sein. Bei komplexeren Anfragen kann die Antwort auch mal ein größeres Datenpaket sein, das die anfragende Anwendung dann weiterverarbeiten kann. Auch der Umfang einer Anfrage variiert von einer einfachen Statusabfrage bis hin zur Aufforderung, einen umfangreichen Datensatz zu verarbeiten oder in der MIP zu speichern.
Neben den Webservices kann die MIP auch per MQTT kommunizieren. Wo ist der Unterschied und warum gibt es diese beiden Möglichkeiten?
Wie gesagt, bei Webservices braucht es immer eine konkrete Anfrage, um eine Antwort zu bekommen. Wir nennen diese Schnittstelle zur MIP übrigens auch Service Interface. Die zweite wichtige Schnittstelle der MIP nennen wir Factory Collaboration Hub (FCH). Hier setzten wir auf MQTT, ein schlankes Protokoll aus dem Umfeld des Internet of Things (IoT). Im Gegensatz zum Service Interface funktioniert der Factory Collaboration Hub nach dem Prinzip Publish-Subscribe. Das bedeutet, dass der FCH Informationen zu bestimmten Themen in Echtzeit publiziert – also immer dann, wenn diese Informationen entstehen.
Zum Beispiel wird der Maschinenstatus einer bestimmten Maschine immer dann veröffentlicht, wenn dieser sich geändert hat. Publizieren bzw. veröffentlichen heißt in diesem Zusammenhang, dass der FCH die Information an alle Empfänger schickt, die sich für dieses Thema registriert haben, bzw. das Thema abonniert haben. Jeder Abonnent bzw. Subscriber bekommt nur die Informationen, die für ihn relevant sind. Dafür bekommt er die Informationen sofort nach deren Meldung an die MIP. Fällt eine Maschine aus, werden sofort alle Abonnenten dieser Maschine informiert. Würde man diese Information über das Service Interface anfragen, dann würde man zwar auch die Info bekommen, dass die Maschine ausgefallen ist – allerdings erst zum Zeitpunkt der Anfrage … und das kann in manchen Fällen zu spät sein.
Außerdem erzeugt Polling einen großen Overhead, weil der Server ständig Anfragen beantworten muss, obwohl sich nichts geändert hat. Zusätzlich kann es beim Polling passieren, dass man einen kurzen Zwischenstatus verpasst. Da das Publish-Subsrcibe-Prinzip nur in eine Richtung funktioniert, kann man die beiden Arten der Kommunikation auch miteinander verbinden. Zum Beispiel verteilt der FCH die Information, dass die Maschine ausgefallen ist. Anschließend kann eine andere Anwendung via Service Interface Informationen zum aktuell produzierten Auftrag abfragen.
Alle Daten sind in der MIP in Form von Business Objects abgelegt. Welche Vorteile hat das?
Das Denken in Objekten ist immer dann von Vorteil, wenn eine Vielzahl an Abhängigkeiten abgebildet werden sollen. Die klassische Listendarstellung, wie man sie aus Excel kennt, kann da nicht mithalten. Business Objects, wie wir sie für die MIP definiert haben, lassen sich beliebig miteinander verknüpfen und bilden so ein Informationsmodell. Zusätzlich sind die Business Objects sematisch beschrieben, sodass jeder die Bedeutung der einzelnen Eigenschaften nachlesen kann. Somit weiß jede MIP-basierte Anwendung, welche Daten es zu einem Objekt gibt und wie diese zu verstehen sind. Wie die einzelnen Instanzen der Business Objects in einer Datenbank persistieren, darüber muss sich weder der Anwender noch der Entwickler Gedanken machen. Ein Set von Content Access Services sorgt dafür, dass alle Anwendungen nur mit den Business Objects in Berührung kommen. Neben dem einfacheren Handling sorgt diese Art der Implementierung auch für mehr Konsistenz und Sicherheit der Daten.
Normalerweise läuft die MIP auf einem Windows Server und nutzt eine Microsoft SQL Datenbank. Warum beschäftigt sich MPDV aktuell auch mit Linux und PostgreSQL?
Nicht immer ist die MIP die Basis für ein großes IT-System. In manchen Fällen wollen Fertigungsunternehmen klein anfangen und erst einmal wenige Anwendungen mit einem überschaubaren Datenaufkommen nutzen. Auch läuft die MIP nicht immer in der Cloud oder im Rechenzentrum. Wir hatten bereits einen Fall, in dem ein kleiner Edge-PC die Hardwarebasis für die MIP bildet. Da läuft weder ein Windows Server noch eine MS SQL Datenbank. Vielmehr braucht es in diesem Umfeld einen schlanken Unterbau für unsere Plattform. Auch die Tatsache, dass sowohl Linux als auch PostgreSQL Open Source Projekte sind, hat Vorteile. Gerade in kleineren Unternehmen stehen nicht immer die Budgets für eine kostenintensive Serverinfrastruktur von Microsoft zur Verfügung. Mit Open Source Software kann man schnell mal einen Use Case umsetzen.
Vielen Dank für den Blick hinter die Kulissen der MIP.
