Schnittstellen zu Prüfmitteln

Typische Schnittstellen zu Prüfmitteln

Schnittstellen zu Prüfmitteln gibt es wie Sand am Meer. Sicherlich gibt es n+1 Möglichkeiten. Wir haben uns daher auf eine Auswahl gängiger Varianten beschränkt. Das AQDEF-Format mit .dfq-Dateien wird von vielen Herstellern verwendet. Das QML-Format überträgt die gleiche Struktur in die XML-Technologie. Messmittelboxen werden häufig dann eingesetzt, wenn das Prüfmittel keinen direkten Ethernetanschluss besitzt. Den Abschluss bilden die protokollbasierten Schnittstellen, die herstellerspezifisch implementiert sind und daher sehr spezifische, auf das Prüfmittel zugeschnittene Funktionen bieten können. Natürlich gibt es neben diesen Schnittstellen noch weitere, die auf OPC UA, Modbus oder anderen Protokollen basieren. Mit den hier genannten Möglichkeiten ist jedoch aus unserer Erfahrung bereits ein großer Teil abgedeckt.

Advanced Quality Data Exchange Format (AQDEF)

Das Format AQDEF wurde gemeinsam von einem Konsortium aus Automobil OEMs und Zulieferern entwickelt. Die Schnittstelle zur Prüfmitteln definiert dabei ein Datenmodell, dass aus den folgenden drei Komponenten besteht: Bauteilen, Merkmalen und Messwerten. Die Informationen werden über Dateien ausgetauscht. Diese gliedern sich in eine Beschreibungsdatei, welche wie der Name schon sagt, Meta-Informationen beinhaltet. Die realen Messwerte finden sich in der Werte-Datei. Alle Informationen können auch über eine gemeinsame Datei mit der Endung „.dfq“ abgerufen werden.

Die Daten werden dabei zeilenweise in die Dateien geschrieben und werden über einen Schlüssel im Format „Kxxxx“ identifiziert. Im AQDEF-Standard können die einzelnen Schlüssel nachgelesen werden.

Hier ist ein Beispiel für den Übertrag eines Messwertes (Schlüssel K0001) zum Zeitpunkt (K0004) mit einer Chargennummer (K0006).

K0001 19.8
K0004 25.08.23/13:08:34
K0006 Charge0815

Quality Markup Language (QML)

QML ist eine XML-basierte Sprache, die speziell für die Beschreibung von Messdaten und Messprozessen entwickelt wurde. Sie ermöglicht die detaillierte Definition von Messaufgaben und -ergebnissen. QML wird häufig in Verbindung mit Prüfgeräten und MES-Systemen verwendet, um Messdaten zu beschreiben und zu übertragen. Es bietet eine hohe Flexibilität bei der Konfiguration von Messprozessen. QML basiert auf der XML-Technologie. Damit bietet sich mehr Flexibilität in der Übertragung und Auswertung als zum Beispiel das AQDEF-Format.

Das Ergebnis einer Messung wird dabei wie folgt beschrieben:

<V id="{F50BC552-3A1F-4E12-A057-5C665F67E78C}" k0001=" 6.70000000000000E+0002" k0002="0" k0004="1992-05-07T13:43:08" k0006="Charge Nummer1"/>

Weitere Informationen finden Sie in der Dokumentation von der Firma Q-DAS, die Sie hier finden.

Messmittelboxen

Prüfgeräte haben oft individuelle physikalische Stecker als Schnittstellen und sind auf eine besondere Art der Kommunikation angewiesen. Die Messmittelbox ist eine Gerät, das dazu dient, verschiedene Prüfgeräte miteinander zu verbinden. Sie kann als Hub fungieren, um die Kommunikation zwischen Prüfgeräten und übergeordneten Systemen zu erleichtern. Die Boxen haben zum Messgerät hin standardisierte Stecker und zum Erfassungsprogramm hin oft eine USB- oder Ethernet-Schnittstelle. Sie bildet also eine Schnittstelle für Prüfmittel. Für die Kommunikation zwischen Messmittelbox und Prüfgerät liefern die Hersteller der Box oft direkt passende Treiber mit. Somit muss nur der Treiber für die Messmittelbox konfiguriert werden. Häufig wird auch ein Fuß- oder Handschalter an die Box angeschlossen, der die Messwertübertragung vom Prüfgerät zur Anwendungssoftware auslöst.

Protokollbasierte Schnittstellen

In vielen industriellen Anwendungen und Kommunikationssystemen sind protokollbasierte Schnittstellen wie das ASCII-Protokoll weit verbreitet. Diese Schnittstellen definieren klare Regeln und Strukturen, die den Geräten ermöglichen, zueinander zu kommunizieren. Eines der ältesten und am weitesten verbreiteten Kommunikationsprotokolle ist das ASCII-Protokoll (American Standard Code for Information Interchange). Es verwendet lesbare Textzeichen, um Daten zwischen Geräten auszutauschen, wodurch es einfach zu implementieren ist. ASCII-Protokolle werden in Bereichen wie Maschinensteuerung, Datenerfassung und Sensorintegration eingesetzt. Sie ermöglichen die zuverlässige Übertragung von Informationen in einem von Menschen lesbaren Format, was die Fehlersuche und -behebung erleichtert. Als Nachteil ist ein fehlender Standard zu sehen, so kann jeder Hersteller ein eigenes Protokollsystem aufbauen. Ebenfalls ist es oft nicht notwendig die Datenübertragung zu quittieren, was womöglich zu einem Datenverlust führen kann.

Art der Übertragung

Kabelgebunden

Bei den kabelgebundenen Lösungen gibt es eine Vielzahl von Ausführungen. Bei größeren Prüfgeräten (z.B. Härteprüfmaschinen, Zugprüfmaschinen) ist eine Ethernet-Schnittstelle üblich. Bei kleineren Geräten, wie z.B. Schieblehren, wird oft eine Verbindung wie RS232 verwendet.

Kabellos

Für den kabellosen Betrieb von Prüfmitteln spricht die höhere Flexibilität und das Wegfallen von möglichen Stolperfallen. Für diverse Messgeräte gibt es Adapter, die Signale via Bluetooth weiterleiten. Dies kann zum Beispiel ein Dongle für die Messmittelbox sein. Als Ersatz zu Bluetooth existieren auch Funklösungen auf eigen entwickelten Standards. Ebenfalls wird WLAN als Kommunikationsmittel von zum Beispiel einer Messmittelbox zum Server eingesetzt.

Auswahl der richtigen Schnittstelle für Prüfmittel

Bei der Auswahl der Schnittstelle sind verschiedene Faktoren zu berücksichtigen. Zum einen die Ausrichtung der Schnittstelle – sollen „nur“ Messdaten empfangen werden oder benötigt das Prüfgerät auch Informationen wie z.B. eine Auftragsnummer? Im letzteren Fall ist es sicherlich sinnvoll, direkt in Richtung AQDEF zu denken. Darüber hinaus ist zu berücksichtigen, wie die Prüfung durchgeführt wird. Hat der Mitarbeiter eine Hand frei für einen Handschalter oder wird ein Fußschalter benötigt? Natürlich muss auch das Gespräch mit dem Prüfgerätehersteller gesucht werden. Wir empfehlen dies immer vor dem Kauf eines neuen Gerätes, da es dann oft einfacher ist, gemeinsam eine Lösung zu finden. Aus der vom Hersteller angegebenen Auswahl muss dann die passende Schnittstelle gefunden werden.

Prüfdaten mit der smartPLAZA abspeichern

Die DatenBerg smartPLAZA ermöglicht die Erfassung von Prüfwerten aus unterschiedlichen Quellen. Für die Kommunikation mit dem Prüfgerät stehen verschiedene Standard-Konnektoren zur Verfügung, um die oben beschriebenen Schnittstellen abzudecken. Bei der Erstellung eines Prüfplans wird ein zu prüfendes Merkmal mit der Schnittstelle verbunden. Bei der Ausführung eines Prüfauftrages genügt dann ein Klick oder eine Schalterbetätigung, um die Messwerte zu übernehmen. Liegen Daten z.B. im AQDEF-Format oder als .xml vor, können diese auch im Hintergrund in definierten Intervallen eingelesen werden.

SQL-Datenbanken in der Produktionsumgebung

Grundlagen von SQL-Tabellen

Eine SQL-Tabellen verwaltet Daten in einer strukturierten Form. Dafür werden relationale Datenbanken wie zum Beispiel PostgreSQL verwendet. Die Tabellen bestehen aus Zeilen und Spalten, wobei jede Zeile einen Datensatz und jede Spalte eine gewisse Datenkategorie (z.B. Ganzzahl, Text, Datum) beinhaltet. Diese Tabellen sind nach einem vordefinierten Schema organisiert, das die Art der gespeicherten Daten festlegt. Mit Hilfe von SQL (Structured Query Language) können Abfragen erstellt werden, um Daten zu suchen, hinzuzufügen, zu ändern oder zu löschen. Primärschlüssel dienen als eindeutige Identifikatoren für Zeilen, während Fremdschlüssel Beziehungen zwischen verschiedenen Tabellen herstellen können. Dies ermöglicht komplexe Abfragen, Berichte und Analysen. Insbesondere ist der Zugriff durch weitere Systeme zur Weiterverarbeitung möglich. Die Abfragesprache SQL ist standardisiert, einzelne Anbieter von Datenbanksystemen implementieren den Standard verschieden.

Es gibt verschiedene Anbieter von SQL-Datenbanken. Von Open-Source Software wie die PostgreSQL zu kommerziellen Anbietern wie Oracle. Unterschiede existieren bei Themen wie Lizenzierung, unterstützten Datentypen und Betriebssystemen.

Struktur einer SQL-Abfrage

Doch wie sieht der Aufbau einer SQL-Abfrage konkret aus? Eine SQL-Abfrage besteht aus den folgenden Hauptkomponenten:

SQL stellt eine große Anzahl von Funktionen zur Verfügung, die in komplexeren Abfragen zum Einsatz kommen können. Die genaue Syntax und Verwendung kann je nach verwendetem Datenbankmanagementsystem leicht variieren.

Nehmen wir das obige Beispiel: Eine Tabelle mit den Spalten Produktionsauftrag, Losgröße und Gutteile.  Die Abfrage könnte wie folgt aussehen, um die Zeilen auszuwählen, für die die Anzahl der Gutteile größer als die Losgröße ist:

SELECT Fertigungsauftrag, Losgröße, Gut-Teile
FROM Fertigungsdaten
WHERE Gutteile > Losgröße;

Diese Abfrage gibt alle Zeilen zurück, in denen die Anzahl der Gutteile größer als die Losgröße ist. Dazu gibt die Abfrage die Spalten Fertigungsauftrag, Losgröße und Gut-Teile zurück.

Wo finden sich SQL-Tabellen in der Produktion?

SQL-Tabellen können in verschiedenen Systemen und Anlagen in der Produktion entstehen. Spannend ist es, wie kann darauf zugegriffen werden? Wir haben die drei großen Kategorien IT-Systeme, Anlagen und Schatten-IT bewertet.

Nahezu alle IT-Systeme wie ERP, CAQ, MES oder SCADA arbeiten im Hintergrund mit SQL-Tabellen. Häufig hat die hauseigene IT bereits Erfahrung mit Datenzugriffen auf diese Systeme und kann diese selbst erstellen. Aus unserer Erfahrung bringt der Großteil der Hersteller auch die Offenheit für einen Austausch der Daten mit beziehungsweise bietet hierfür Lizenzbausteine an.

Einzelne Anlagen oder Prüfmaschinen können auch eine SQL-Tabelle zur Datenspeicherung verwenden. Insbesondere bei komplexeren Anlagen mit eigenem Rechner ist oft eine eigene Datenbank enthalten. Für den Zugriff ist oft eine Absprache mit dem Anlagenhersteller notwendig bzw. empfehlenswert. Bei einer Integration kann eine separate Lizenz für den Datenzugriff erforderlich sein.

Eine weitere Quelle ist die sogenannte Schatten-IT. Selbstgestrickte und historisch gewachsene Tabellen, die nicht direkt von der IT freigegeben wurden. Ein Beispiel sind Datenbanken, die mit Microsoft Access verwaltet und gefüllt werden. Hier fallen zwar keine Lizenzkosten für den Zugriff an, aber die Systeme sollten gut verstanden und dokumentiert sein, um einen stabilen Datenabruf zu gewährleisten. Natürlich existieren auch genug Anwendungen, die erfolgreich auf MS Access aufbauen und nicht zur Schatten-IT zählen, dies ist nur als illustratives – aber reales – Beispiel gedacht.

ODBC-Verbindungen für SQL-Tabellenzugriffe

ODBC (Open Database Connectivity) ist eine standardisierte Schnittstelle, die den Zugriff auf Datenbanken unabhängig von der zugrunde liegenden Datenbanktechnologie ermöglicht. Die Schnittstelle fungiert als Brücke zwischen Anwendungen und Datenbanken, indem es eine einheitliche Kommunikationsmethode bereitstellt. Dies geschieht über ODBC-Treiber, der für jede Datenbank spezifisch implementiert ist. Mit einem Treiber und einem datenbankspezifischen ODBC-Connection-String kann auf die Daten zugegriffen werden. Auf dieser Website sind typische Verbindungsstrings gelistet.

Die Verwendung von ODBC bietet Vorteile wie leichte Anbindung, da Anwendungen nicht direkt an eine bestimmte Datenbank gebunden sind, sondern über den Treiber kommunizieren. Dies erleichtert den Wechsel zwischen verschiedenen Datenbanken. Daneben ist eine hohe Stabilität gegeben. ODBC unterstützt ebenfalls eine Vielzahl von Datenbankmanagementsystemen.

Um eine Verbindung über ODBC herzustellen, muss eine Anwendung den entsprechenden ODBC-Treiber installieren und konfigurieren. Dies beinhaltet die Definition von Datenquellen (Data Sources), die die Verbindungsinformationen enthalten. Danach kann die Anwendung über ODBC SQL-Abfragen an die Datenbank senden und Ergebnisse empfangen.

Der ODBC-Zugriff auf SQL-Tabellen ist dargestellt. Es werden die Komponenten Anwendung, ODBC-Treiber und SQL-Tabelle gezeigt. Ebenfalls ist ein Beispel für einen ODBC-Connection-String gegeben.

Fallstudie: SQL-Tabellen in der Gummimischerei

Problem: Effiziente Verwaltung von Maschinen- und Labordaten in Echtzeit in der Gummimischerei

Bei der Compoundierung von Kautschukmischungen besteht die dringende Notwendigkeit, Maschinen- und Labordaten in Echtzeit zu erfassen, zu verarbeiten und zu verwalten. Diese Daten sind für die Überwachung der Produktionsprozesse, die Qualitätskontrolle und die schnelle Reaktion auf Qualitätsschwankungen von entscheidender Bedeutung. Da die Überwachung in Echtzeit kritisch ist, stellt sich die Frage, wie eine effiziente Erfassung und Verarbeitung realisierbar ist.

Herausforderungen sind dabei die Echtzeitfähigkeit, die permanente Speicherung der Daten sowie die Flexibilität, neue Datenpunkte (z.B. Sensoren) einfach in die Infrastruktur zu integrieren.

Lösung: Verwendung von separaten SQL-Tabellen für Maschinendaten und Labordaten, Konsolidierung durch ODBC-Schnittstelle

Um das Problem der Echtzeitdatenverwaltung in der Gummimischtechnik zu lösen, bietet sich eine sorgfältig strukturierte SQL-Datenbank an. Für Maschinen- und Labordaten ist jeweils eine Tabelle zu definieren. Dadurch findet eine Trennung der verschiedenen Datentypen statt und die Datenstruktur ist optimiert. Die Befüllung der SQL-Tabellen findet durch ein Transferskript aus der Steuerung statt.

Die Konsolidierung und Auswertung dieser Daten erfolgt dann über eine ODBC-Schnittstelle in der Software DatenBerg SmartPlaza im Data Warehouse. Über diese Schnittstelle werden die Daten aus den verschiedenen Tabellen gesammelt und in einer zentralen Plattform zusammengeführt. Hier finden Vergleiche der Daten und Analysen statt. Über einen Knopfdruck wird ein definierter Berichten ausgegeben.

Ergebnis: Verbesserte Echtzeitüberwachung, Qualitätskontrolle und Rückverfolgbarkeit

Die Implementierung dieser Lösung bietet zahlreiche Vorteile. Durch die Verwendung von getrennten SQL-Tabellen für Maschinendaten und Labordaten kann bei Ausfall eines Systems (Recorder, Maschinendaten, Prüfmittel) das andere System die Daten weiter aufzeichnen. Auch Änderungen des Schemas (z.B. zusätzliche Prüfmerkmale) sind leicht umsetzbar.

Die Datenkonsolidierung und -analyse in DatenBerg SmartPlaza ermöglicht eine umfassende Überwachung und Steuerung der Produktionsprozesse. Qualitätsschwankungen sind so bis auf Einzelwerte zurückverfolgbar und Reaktionen sind unmittelbar ableitbar.

Durch die Entkopplung der Tabellen sind die Maschinendaten bereits drei Sekunden nach Produktionsende im Auswertesystem smartPLAZA sichtbar. Dies ermöglicht eine Überwachung nahezu in Echtzeit und ein sofortiges Eingreifen bei Abweichungen oder Problemen.

Die gewählte Lösung ermöglicht auch einen Handshake zwischen den verschiedenen Systemen. Dabei schreibt das Lesesystem in der Herkunftstabelle in einer definierten Spalte (z.B. „Handshake“) z.B. eine „0“ in eine „1“. Mit einem definierten Job können in der Herkunftstabelle alle Zeilen mit einer „1“ in der Spalte „Handshake“ gelöscht werden, da diese bereits vom Folgesystem gelesen wurden.

Insgesamt führt diese Lösung zu einer effizienten und zuverlässigen Produktionsüberwachung in Echtzeit, ermöglicht die schnelle Erkennung und Behebung von Qualitätsproblemen und trägt zur kontinuierlichen Verbesserung der Prozesse in der Gummimischanlage bei.

Fazit & Bewertung SQL in der Produktion

SQL-Datenbanken bieten einen strukturierten Aufbau. Wenn Daten einmal in eine Tabelle weggeschrieben werden, können diese einfach abgelesen werden. Damit kann ein stabiler Austausch zwischen Systemen ermöglicht werden. Somit eignen sich die Datenbanken sowohl für den Transfer zwischen Systemen bzw. Geräten, jedoch auch für einen historischen Speicher. Die Tabellen wollen jedoch gefüttert werden. Hierzu bedarf es wiederum anderer, maschinennäheren Schnittstellen wie zum Beispiel OPC UA oder Modbus.

MQTT in der Industrie

Einführung in Aufbau & Struktur von MQTT

MQTT (Abkürzung für Message Queuing Telemetry Transport)  ist ein Datenaustauschprotokoll. Dabei tauschen zwei Geräte (dem “Client”) über einen sogenannten Broker Daten miteinander aus. Ein Client kann dabei Daten an einen Broker senden („publish“ – wir übersetzen dies mit veröffentlichen) und ebenfalls Daten von einem Broker erhalten („subscribe“ – wir übersetzen dies mit abonnieren). Beim Veröffentlichen gibt der Sender-Client neben der Nachricht (dem “Payload”) ein “Topic” (wir übersetzen dies mit Kanal) an, auf welches er es veröffentlichen möchte. Der Empfänger-Client abonniert diesen Kanal und bekommt die Nachricht aus diesem Kanal vom Broker weitergereicht.

Zu besseren Verständlichkeit haben wir das anhand eines Paketversands illustriert. Zwei Paketboten veröffentlichen auf den Topics „Grün“ bzw. „Rot“ ihre Pakete. Diese werden alle über den zentralen Broker versandt. Dieser sortiert die Pakete und verteilt diese. Zwei weitere Clients – zwei Warenhäuser – haben jeweils das rote bzw. grüne Topic abonniert. Also verteilt der Broker nur die jeweiligen Pakete an die Warenhäuser. Obwohl also beim Broker die Pakete bunt gemischt waren, kommen diese farbengetrennt bei den Clients an. Das Paket steht dabei für eine Nachricht. Der Paketinhalt steht für das sogenannte Payload, also die zu übermittelnden Nutzdaten.

Das Schaubild erklärt die Funktionsweise von MQTT anhand eines Pakettransportes. Es werden die Topic-Struktur, Payload, Client und Broker illustriert.

Relevante Begriffe einfach erklärt

In MQTT werden verschiedene Begrifflichkeiten verwendet. In der folgenden Liste haben wir die wichtigsten erklärt:

Wildcard

Wildcards sind spezielle Zeichen, die verwendet werden, um mehrere Topics zu abonnieren oder zu filtern. Es gibt zwei Arten von Wildcards in MQTT:

Quality of Service (QoS): Gewährleistung der Nachrichtenqualität und Zuverlässigkeit

QoS ist eine Vereinbarung zwischen dem Sender und Empfänger einer Nachricht in Bezug auf das Garantieren der Nachrichtenübermittlung. Es existieren drei verschiedene Level in MQTT:

Beide Kommunikationsarten (Publish/Subscribe) zum und vom Broker müssen berücksichtigt und getrennt voneinander betrachtet werden. Das QoS-Level, welches ein Client beim Publishen einer Nachricht verwendet, wird vom jeweiligen Client gesetzt. Wenn der Broker nun die Nachricht an einen Client weiterleitet, der entsprechend das Topic abonniert hat, wird das QoS-Level vom Subscriber verwendet, welches beim Herstellen des Abonnement angegeben wurde. Dies bedeutet, dass ein QoS-Level, welches vom Publisher vielleicht mit 2 angegeben wurde, vom Subscriber mit 0 „überschrieben“ werden kann.

Das Schaubild zeigt die einzelnen Quality of Service (QoS) Levels des MQTT-Protokolls und erklärt diese.

Entscheidungshilfe: QoS-Stufen

Sicherheit in MQTT: Schutz und Absicherung der Datenübertragung

Im Protokoll können verschiedene Sicherheitsmechanismen implementiert werden. Je nach Implementierung ist der Umfang der Sicherheitseinstellungen eingeschränkt oder vollständig implementiert. Die verschiedenen Möglichkeiten können auf die Protokollteilnehmer (Broker, Client sowie Netzwerk) verteilt werden.

Sicherheitsmöglichkeiten auf Client-Ebene

Sicherheitsmöglichkeiten auf Broker-Ebene

Auf Netzwerkebene kann der Zugriff auf MQTT-Broker auf autorisierte Clients beschränkt werden, indem Netzwerksegmente und Firewalls entsprechend konfiguriert werden.

Hinweis: Die Sicherheitsmöglichkeiten und Bedrohungen ändern sich mit der Zeit. Eine periodische Überprüfung der verwendeten Protokolle bietet sich an.

Vor- und Nachteile des Protokolls

Folgende Argumente sprechen für die Verwendung des Protokolls

Es gibt jedoch auch Nachteile, die mit diesem Protokoll verbunden sind:

MQTT to X – Schnittstelle zu Datenbanken und weiteren Anwendungen

Python Skript

Um Daten von einem MQTT-Broker zu abonnieren, existieren diverse Python-Skripte. Das folgende Skript verbindet sich mit einem Broker und gibt die Daten auf der Kommandozeile aus. Dazu verbindet sich das Skript mit einem definierten Broker auf Port 1883. Dort abonniert das Skript das Topic „sensoren/temperatur“ und gibt diese bei Nachrichtenempfang aus. Als Beispiel Bibliothek findet die MQTT Bibliothek von Paho Anwendung.

import paho.mqtt.client as mqtt
# Callback-Funktion, die aufgerufen wird, wenn eine Nachricht empfangen wird
def on_message(client, userdata, message):
    print(f"Empfangene Nachricht: {message.payload.decode()}")
# MQTT-Client erstellen
client = mqtt.Client()
# Callback-Funktion für Nachrichtenregistrierung festlegen
client.on_message = on_message
# Verbindung zum Broker herstellen (Broker-IP-Adresse oder Hostname angeben)
broker_address = "broker.example.com"
client.connect(broker_address, port=1883)
# Thema, das abonniert werden soll
topic = "sensoren/temperatur"
# Thema abonnieren
client.subscribe(topic)
# Auf eingehende Nachrichten warten
client.loop_forever()

MQTT mit DatenBerg smartPLAZA

Das DatenBerg Gateway hat MQTT-Funktionalitäten standardmäßig integriert. Zur Weiterverarbeitung kann direkt ein Python-Skript eingebunden werden. So kann die z.B. die Umrechnung von Rohsignalen vom Binär- ins Dezimalsystem direkt auf dem Gateway stattfinden. Das Gateway sendet die Daten dann verschlüsselt an die smartPLAZA. Falls keine Verbindung zum Server möglich ist, speichert das Gateway die Daten lokal ab und puffert diese. Somit ist ein Sicherheitspuffer vorhanden. In der smartPLAZA werden die Daten dann in einer Datenbank gespeichert und können visualisiert, auf Grenzwerte überwacht oder für weitere Berechnungen verwendet werden.

Integration von MQTT und IO-Link

IO-Link als standardisiertes Kommunikationsprotokoll setzt sich in der Industrie immer mehr durch. Damit können Sensoren und Aktoren nach dem Plug & Play-Prinzip an eine Steuerung, den sogenannten IO-Link-Master, angeschlossen werden. Die Konfigurationsdateien der einzelnen Geräte stehen als sogenannte IODD-Dateien online zur Verfügung. Hersteller wie IFM mit der DataLine oder Pepperl & Fuchs mit den IEC-Geräten bieten auf ihren IO-Link-Mastern direkt die Funktionalität zur MQTT-Kommunikation an. Damit kann der Master bidirektional Daten an einen Broker senden und von diesem empfangen. Durch den modularen IO-Link Ansatz entsteht auf einfache Weise ein kabelbasiertes Netzwerk. Die Kommunikation vom Sensor zum Master erfolgt über das IO-Link-Protokoll und die Kommunikation der Sensordaten findet über MQTT statt. Dies kann ohne Programmierung, sondern nur mit Webapplikationen erfolgen.

Verbindung zwischen MQTT und SPS

Neben der dezentralen Sensorik können auch Steuerungen von MQTT profitieren. Für folgende Hersteller haben wir die MQTT-Funktionalitäten exemplarisch recherchiert:

Bei Siemens gibt es den Funktionsbaustein „LMQTT“. Dieser ist für die Steuerungen S7-1500 und S7-1200 konzipiert und im TIA-Portal verfügbar. Sowohl Veröffentlichungs- als auch Abonnierfunktionien sind umgesetzt. Als Sicherheitsfeature wird TLS-Verschlüsselung angeboten. Mehr dazu hier in der offiziellen Siemensanleitung. In der Beckhoff-Welt gibt es auch einen vordefinierten Funktionsbaustein namens „FB_IotMqttClient“ für die MQTT-Kommunikation. Der Baustein ist in der Bibliothek „Tc3_IotBase“ enthalten. Außerdem gibt es ein Modul für den „Last Will“ des Clients und ein weiteres Modul für die TLS-Konfiguration. Hier gibt es eine Anleitung von Beckhoff zur Konfiguration. Auch von Bachmann Electronic gibt es eine vorgefertigte Software für die MQTT-Kommunikation in der M1-Steuerungswelt. Die Einbindung erfolgt hier über die SPS-Bausteinbibliothek oder als C/C++ Headerdatei. Für IEC 61331-3 API mit Headerdatei für C/C++. Weitere Informationen finden Sie hier.

Case Study: Automatisierte Überwachung von Motoren in einem Logistikzentrum mittels MQTT-Technologie

Problem: Manuelle Überwachung und fehlende Datenerfassung von dezentralen Motoren

In einem großen Logistikzentrum, das eine große Anzahl dezentraler Motoren für verschiedene Betriebsaufgaben betreibt, stand das Problem der manuellen Überwachung im Vordergrund. Die vorhandene Steuerungstechnik ermöglichte keine Überwachung der Vibrationen und Laufzeiten der Motoren, was zu ineffizienten Wartungsprozessen, unerwarteten Ausfällen und hohen Wartungskosten führte. Die fehlende Möglichkeit, den Zustand der Motoren frühzeitig zu erkennen, beeinträchtigte die Betriebskontinuität und erhöhte die Ausfallzeiten.

Lösung: Implementierung von kabellosen Sensor Gateways mit MQTT-Integration

Um dieses Problem zu lösen, entschied sich das Logistikzentrum für eine innovative Lösung: die Implementierung von drahtlosen Sensor Gateways mit integrierten Vibrationssensoren. Diese Sensoren sind an den Motoren angebracht und sammeln kontinuierlich Daten über die Vibrationen an den Motoren. Die gesammelten Daten werden über ein WLAN-Netzwerk an einen zentralen MQTT-Broker übertragen. Die MQTT-Technologie ermöglichte eine effiziente, zuverlässige und echtzeitfähige Kommunikation zwischen den Sensoren und dem Broker.

Die erfassten Daten sind mit Hilfe einer optimierten Topic-Struktur intelligent kategorisiert und organisiert. Diese Topic-Struktur ermöglichte es, die Sensorsignale den entsprechenden Motoren zuzuordnen und einen klaren Überblick über den Zustand jedes Motors zu erhalten. Das Logistikzentrum nutzte MQTT, um die Daten an die DatenBerg smartPLAZA zu senden, die als zentrale Plattform für die Verwaltung und Analyse von IoT-Daten dient. Hier findet die automatisierte Analyse der Sensordaten statt.

Outcome: Effiziente Automatisierung, Vorhersage und optimierte Instandhaltung

Durch die erfolgreiche Implementierung dieser Lösung konnte das Logistikzentrum mehrere positive Ergebnisse erzielen:

Die erfolgreiche Implementierung von MQTT zur Überwachung und Analyse von Motoren führte zu einer deutlichen Verbesserung der Betriebseffizienz, der Wartung und der Betriebskontinuität im Logistikzentrum. Durch die intelligente Kombination von drahtlosen Sensor-Gateways, MQTT-Kommunikation und prädiktiver Analyse konnte das Logistikzentrum Ausfälle minimieren, Ressourcen optimieren und letztendlich die Gesamtbetriebskosten senken.

Häufig gestellte Fragen

Für was ist MQTT die Abkürzung?

MQTT steht für Message Queuing Telemetry Transport und ist ein Protokoll zu Datenübertragung.

Welche MQTT-Broker gibt es?

Es existieren verschiedene MQTT-Broker, die sich hinsichtlich Stabilität, Skalierbarkeit und Funktionsumfang unterscheiden. Mosquitto ist eine verbreitete Open-Source Implementation. Weitere Broker sind unter anderem: Hive MQ, Eclipse Mosquitto, VerneMQ, ActiveMQ oder EMQ X.

Was ist die maximale Nachrichtengröße bei MQTT?

Maximal 64kB können mit einer Nachricht übertragen werden.

Wer hat MQTT erfunden?

MQTT wurde erstmals in den späten 1990er Jahren von Andy Stanford Clark und Arlen Nipper entwickelt.  2010 wurde der Standard von IBM als Open-Source-Projekt veröffentlicht und der Quellcode der Eclipse Foundation übergeben. Die aktuelle Version MQTT 5.0 wurde 2019 veröffentlicht.

Für was steht QoS bei MQTT?

QoS steht für Quality of Service. Die QoS-Stufen (0, 1, 2) beeinflussen die Nachrichtenübermittlung und -bestätigung. Höhere QoS-Stufen bieten mehr Sicherheit in Bezug auf die Nachrichtenzustellung, erfordern jedoch auch mehr Overhead.

Modbus: Aufbau, Funktion und Beispiel

Was ist Modbus?

Modbus ist ein weit verbreitetes Kommunikationsprotokoll in der Industrieautomatisierung und Prozesssteuerung. Es ermöglicht den Austausch von Daten zwischen elektronischen Geräten und Systemen, die in industriellen Umgebungen im Einsatz sind.

Das Modbus-Protokoll wurde in den späten 1970er Jahren von Modicon (gehört heute zu Schneider Electric) entwickelt und besteht aus mehreren Varianten, darunter die Varianten RTU (Remote Terminal Unit) und TCP/IP (Transmission Control Protocol/Internet Protocol). Es ist ein offenes Protokoll und daher sehr flexibel und einfach in der Implementierung.

Bei der Kommunikation werden die Kommunikationspartner in “Client” und “Server” unterschieden. Statt Server kann auch der Begriff “Master” verwendet werden. Der Client führt auf dem Master einen bestimmten Befehl aus. Ist dieser korrekt, verarbeitet der Master die Anfrage und gibt eine Antwort (z.B. einen Prozesswert) zurück.

Aufbau des Modbus Protokolls. Ein Client (z.B. Software) sendet eine Anfrage an den Master. Dieser prüft die Anfrage und gibt ein Ergebnis zurück.

Unterschied Modbus RTU und TCP/IP

RTU ist eine serielle Kommunikationsvariante, die üblicherweise über RS-485- oder RS-232-Schnittstellen läuft. Es verwendet eine binäre Datenrepräsentation, um Informationen zwischen Geräten zu übertragen.

TCP/IP hingegen ist eine Variante, die über Ethernet-Netzwerke läuft und auf dem Internet Protocol (IP) basiert. Diese Version erlaubt die Kommunikation über IP-Netzwerke, was sie in modernen industriellen Umgebungen sehr beliebt macht.

Anwendungsfälle von Modbus

Modbus wird häufig in verschiedenen industriellen Anwendungen eingesetzt, um Daten von Sensoren, Steuerungen und anderen Geräten zu sammeln und an eine zentrale Steuerungseinheit oder ein Überwachungssystem zu übertragen. Es ist weit verbreitet und wird von vielen Herstellern unterstützt.

Beispiele für Anwendungen:

Vor- und Nachteile von Modbus

In der industriellen Automatisierung und Prozesssteuerung ist Modbus ein weit verbreitetes Protokoll. Es bietet verschiedene Vor- und Nachteile, die berücksichtigt werden müssen, um zu entscheiden, welches Protokoll zum Einsatz kommt:

Vorteile:

Nachteile:

Datenmodell

In der Modbus-Spezifikation sind vier verschiedene Tabellentypen definiert. Diese werden in der folgenden Tabelle beschrieben. Jeder Anwender des Protokolls (z.B. Gerätehersteller) definiert auf Basis dieses Basisdatenmodells eigene Tabellen. Diese werden dann dem Endanwender in einem Handbuch zur Verfügung gestellt.

Primäre TabellenObjekttypZugriffstyp
Discrete Inputs (Einzelner Eingang)Single bitLesezugriff
Coils (Einzelner Ein-/Ausgang)Single bitLese-/Schreibzugriff
Input Registers (Eingänge)16-bit wordLesezugriff
Holding Registers (Ein-/Ausgänge)16-bit wordLese-/Schreibzugriff

Funktionsbausteine

Zur Erfüllung definierter Aufgaben existieren im Protokoll verschiedene Funktionen bzw. Funktionsbausteine. Die Funktionsbausteine haben eine numerische Kodierung und werden als Modbus Funktionen bezeichnet. Die gebräuchlichsten Funktionsbausteine im Protokoll sind:

  1. Funktion 01 (0x01) – Read Coils: Diese Funktion wird verwendet, um Ausgangszustände (Coils) von einem Server zu einem Client zu lesen. Der Client kann den Zustand von mehreren Ausgängen gleichzeitig anfordern.
  2. Funktion 02 (0x02) – Read Discrete Inputs: Diese Funktion ermöglicht es dem Client, den Zustand von digitalen Eingängen (discrete inputs) von einem Server zu lesen.
  3. Funktion 03 (0x03) – Read Holding Registers: Mit dieser Funktion kann der Client Holding-Register von einem Server lesen.
  4. Funktion 04 (0x04) – Read Input Registers: Diese Funktion erlaubt es dem Client, Input-Register von einem Server zu lesen.
  5. Funktion 05 (0x05) – Write Single Coil: Mit dieser Funktion kann der Client einen einzelnen digitalen Ausgangszustand (Coil) in einem Server setzen oder zurücksetzen.
  6. Funktion 06 (0x06) – Write Single Register: Diese Funktion ermöglicht es dem Client, einen einzelnen Wert in ein Holding-Register auf einem Server zu schreiben.
  7. Funktion 15 (0x0F) – Write Multiple Coils: Mit dieser Funktion kann der Client mehrere digitale Ausgangszustände (Coils) in einem Server gleichzeitig setzen oder zurücksetzen.
  8. Funktion 16 (0x10) – Write Multiple Registers: Diese Funktion erlaubt es dem Client, mehrere Werte in aufeinanderfolgende Holding-Register auf einem Server zu schreiben.

Die Verfügbarkeit und Unterstützung bestimmter Funktionen kann von der Protokoll-Variante (RTU oder TCP/IP) und den verwendeten Geräten abhängen. Jede Funktion hat eine spezifische Datenstruktur und verwendet spezifische Modbus-Registeradressen, um zu kommunizieren.

Praxisbeispiel: Modbus TCP auslesen

In einer Lebensmittelproduktion soll der Druckluftkompressor überwacht werden. Der Hersteller bietet hierfür das Modbus-Protokoll an. Zunächst wird der Kompressor über ein Ethernetkabel in das Maschinennetz eingebunden. In der Steuerung wird die IP-Adresse eingestellt, die für Zugriff relevant ist.

In der Anleitung des Herstellers finden sich folgende Hinweise:

Damit ist klar, mit welcher Funktion auf die Daten zugegriffen werden kann. Der Anwender möchte nur Daten lesen, daher wird nur die Funktion 03 weiter betrachtet. Der aktuelle Netzdruck und der Energiezähler sollen überwacht werden. Dazu stehen folgende Angaben zur Verfügung:

Mit diesen Informationen kann das DatenBerg Gateway konfiguriert werden. Zusätzlich wird das Abfrageintervall (in Sekunden) definiert. Das Gateway fragt dann z.B. alle 60 Sekunden die Daten ab und liest die Holding Register aus. Der Wert wird dann direkt an das Data Warehouse der smartPLAZA gesendet und kann dort auf Dashboards visualisiert oder mit Hilfe des Monitorings überwacht werden.

Weitere Quellen

Ishikiwa-Diagramm

Was ist ein Ishikawa-Diagramm?

Tritt ein Qualitätsproblem auf, stellt sich nach den ersten Maßnahmen zur Fehlerbehebung die Frage nach der Ursache. Im Rahmen der Analyse der Einflussfaktoren auf ein Qualitätsproblem kommen oft eine Vielzahl von Variablen als Ursachen in Betracht. Um Struktur in die Analyse zu bringen, müssen die einzelnen Ideen systematisch erfasst und für alle Beteiligten transparent dargestellt werden. Dazu wird das Ishikawa-Diagramm – auch Fischgrätendiagramm genannt – verwendet. Hierbei werden mögliche Einflussfaktoren auf eine Abweichung in logischen Gruppen zusammengefasst dargestellt. Die einzelnen möglichen Einflüsse werden den Gruppen zugeordnet und können dann auf ihren tatsächlichen Einfluss überprüft werden. Die Inhalte basieren zu Beginn noch stark auf Erfahrungen und Meinungen und werden nach und nach durch nachgewiesene Zusammenhänge ersetzt. Oft wird eine mögliche Ursache im Laufe der Zeit dann weiter präzisiert beziehungsweise ausgeschlossen.

Ishikawa-Diagramm Vorlage

5M,7M – Wie viele Kategorien im Ishikawa-Diagramm?

In Lehrbüchern wird das Ishikawa-Diagramm oft mit fünf Kategorien – den sogenannten 5Ms – dargestellt. Diese stehen für Mensch, Maschine, Material, Methode und Umwelt. Eine weitere Ausprägung ist die 7M-Kategorie – hier werden die Kategorien um Management und Messbarkeit erweitert. 

Die Kategorien sind als Orientierung zu verstehen. Je nach Analysefall bieten sich andere Gruppen an bzw. sind nicht alle Kategorien relevant.

Ishikawa anwenden im Workshop: Tipps & Tricks

Für das Ausfüllen eines Ishikawa-Diagramms bietet sich ein Workshop-Format an. Um möglichst ergebnisoffen zu arbeiten, sollten Kollegen aus verschiedenen Fachbereichen einbezogen werden. In cross-funktionalen Teams ist es wichtig, das Problem aus verschiedenen Blickwinkeln zu betrachten. Neben den Teilnehmern sollte ein Moderator ohne direkten Bezug zum Kernproblem eingebunden werden. Dieser „neutrale“ Moderator hat die Aufgabe, durch gezielte Fragen die möglichen Fehlerursachen zu präzisieren.

Zu Beginn wird das Problem möglichst klar definiert und die Auswirkung auf das Unternehmen (z.B. monetär, kapazitiv, Geschwindigkeit) beschrieben. Nachdem alle Teilnehmer mit der Problemstellung einverstanden sind, bietet sich eine stille Ideensammlung an. Anschließend ordnet der Moderator die Ideen der Teilnehmer den einzelnen Fischgräten (Kategorien) zu. Für einen schnellen Einstieg bietet sich die 5M-Einteilung (Mensch, Maschine, Material, Methode und Mitwelt) der Kategorien an. Diese kann im Verlauf des Workshops variiert werden.

Folgende Materialien können für den Workshop verwendet werden:

5-Why und Ishikwa-Diagramm

Ursache-Wirkungs-Zusammenhänge werden auch mit der 5-Why-Methode analysiert. Dabei wird eine Antwort immer wieder mit der Frage nach dem „Warum?“ neu hinterfragt. Ziel ist es, von der Symptomebene auf die Ursachenebene (engl. root causes) zu schließen. Die Zahl fünf ist dabei symbolisch zu verstehen, es können mehr oder weniger Fragen notwendig sein, um auf die eigentlichen Ursachen zu schließen.

Die Vorgehensweise mit 5-Why ist eher auf eine Ursache-Wirkungskette ausgerichtet. Beim Ishikawa-Diagramm besteht der Ansatz darin, zunächst Transparenz über mögliche Ursachen zu schaffen und diese systematisch zu untersuchen. Um jedoch einzelne mögliche Ursachen zu hinterfragen, bietet sich das 5-Why als Werkzeug an. Wie so oft im Leben – die Mischung macht’s.

Ishikawa Diagramm softwaregestützt ausfüllen

Im Rahmen eines Ishikawa-Workshops werden die ersten möglichen Ursachen oft durch Erfahrung ermittelt. Bei immer komplexeren Prozessen und immer mehr verfügbaren Daten in der Produktion kann Software unterstützen. Neuere Anlagen bieten Schnittstellen, um Daten abzugreifen und diese zentral abzuspeichern. Im Falle einer Reklamation oder eines Fehlerfalles, kann die Historie zur Analyse herangezogen werden. Hypothesen können so schnell validiert und mit Zahlen, Daten, Fakten untermauert werden.

Beispiel Schokoladenproduktion

Die Produktion hat relevante Anlagen wie Temperaturüberwachung, Klimaanlagen, Gebäudeautomation und Gießmaschinen an die Software DatenBerg smartPLAZA angeschlossen. Dort werden die Daten gespeichert, um die Einhaltung der Prozesse sicherzustellen und bei Abweichungen direkt gewarnt zu werden.

Am 22.07. sendet die Temperaturüberwachung der Lagerhalle eine E-Mail mit der Information „Temperatur zu heiß“.  Der Qualitätsbeauftragte kann den Verlauf sofort im System nachvollziehen. Wie aus dem Diagramm ersichtlich ist, liegt die Hallentemperatur seit 15 Minuten 2°C über dem definierten Grenzwert. Damit ist die Problembeschreibung für das Ishikawa-Diagramm eindeutig.

Jetzt ist Eile geboten, damit die Schokolade nicht schmilzt. Nun beginnt die Ursachenanalyse. Zuerst die Kategorie „Messgenauigkeit“: Sie überprüft die Kalibrierung der Sensoren – aber das System zeigt ein Kalibrierdatum von vor zwei Wochen an. Auch die Außentemperatur zeigt einen Verlauf von über 32°C an. So warm war es dieses Jahr noch nicht. Weiter geht es mit der Kategorie „Mensch“: Über die Daten der Gebäudeautomation findet sie heraus, dass das große Verladetor geschlossen ist. Auch hier kann keine warme Luft eindringen. Also überprüft sie die „Maschinen“: Hier wird schnell klar, dass eine Klimaanlage einen Fehler ausgibt – 0% Leistung. Über die Diagnosedaten findet sie heraus, dass die Anlage vor einem Tag eine Notabschaltung hatte. Das Wartungsintervall ist seit vier Monaten abgelaufen.

Um andere Ursachen auszuschließen, nutzt sie die automatische Ursachenanalyse der smartPLAZA. Dazu wählt sie den Zeit Bereich mit dem Fehlerbild aus und fragt die Software „Was war anders?“. Als Rückmeldung erhält sie die übereinstimmenden Informationen: Es ist wärmer als sonst, die Außentemperatur ist höher als erwartet und der Energieverbrauch der Klimaanlage in Halle 2 ist niedriger als erwartet. Weitere signifikante Einflussgrößen wurden nicht identifiziert. Mit Hilfe der Daten im System konnten die einzelnen Einflussgrößen schnell abgearbeitet und die Ursache zielgerichtet erarbeitet werden.

Fazit

Ein Ishikawa-Digramm unterstützt in der Fehlerursachenfindung. Mit Hilfe von vorgefertigten Kategorien, kann Struktur in die Ursachenfindung gebracht und gezielt Hypothesen validiert werden. Die vorgefertigten Kategorien sind dabei als flexibel zu betrachten.

Software kann Schnelligkeit in die Ursachenfindung bringen. Mit der DatenBerg smartPLAZA werden automatisiert alle vorhandenen Variablen hinsichtlich eines Fehlerbildes analysiert und mögliche Ursachen aufgelistet. Ebenfalls können manuell Hypothesen validiert und Zahlen, Daten, Fakten gesammelt werden.

Werkerassistenzsystem

Was ist ein Werkerassistenzsystem? Definition

Systeme zur Unterstützung von Arbeitern sind technologische Systeme, die entwickelt wurden, um menschliche Arbeiter in verschiedenen industriellen oder Produktionsumgebungen zu unterstützen. Diese Systeme sollen die Effizienz, Produktivität und Sicherheit von Arbeitern verbessern, indem sie relevante Informationen bereitstellen, bei der Ausführung von Aufgaben helfen oder sich wiederholende und ermüdende Tätigkeiten automatisieren.

Typen von Assistenzsystemen

Werkerassistenzsysteme können verschiedene Formen annehmen, je nach Anwendungsbereich und Aufgabenstellung. Hier sind einige Beispiele für solche Systeme:

Einstufung von Werkerassistenzsystemen

Assistenzsysteme unterstützen den Menschen bei der Ausführung einer Arbeit. Dabei kann die Arbeit in verschiedene Klassen eingeteilt werden. In der folgenden Abbildung werden Arbeitstypen nach der Art der Beanspruchung klassifiziert und die einzelnen Aufgabenkomplexitäten zugeordnet. Mit einer solchen Klassifizierung ist der erste Schritt in Richtung Assistenzsystem getan.

Ausgehend von der Klassifizierung der Arbeit kann dann die geeignete Art des Assistenzsystems ausgewählt werden. Für mechanische oder motorische Arbeiten, bei denen die körperliche Arbeit und Bewegung im Vordergrund steht, bietet sich die Unterstützung durch Hardware an. Exoskelette oder Tragehilfen entlasten den Menschen bei der Ausführung. Ein Beispiel: Der Werkzeughersteller HILTI bietet ein Exoskelett für Überkopfarbeiten auf der Baustelle an.

Bei reaktiven Aufgaben müssen Informationen aufgenommen und verarbeitet werden. Durch Augmented-Reality-Brillen oder visuelle Führung des Mitarbeiters wird dieser sowohl bei der Aufnahme als auch bei der Verarbeitung unterstützt. Ein Beispiel sind Montageplätze, die den Mitarbeiter in der Arbeitsdurchführung mit Displays oder anderen visuellen Anzeigen unterstützen. Hier findet sich ein Beispiel für einen solchen Montageplatz.

Bei kombinatorischen Aufgaben müssen Informationen ganzheitlich betrachtet werden, um richtige Entscheidungen treffen zu können. Hier kann ein softwarebasiertes System die Daten analysieren und mit passenden Empfehlungen unterstützen.

Bei kreativen Aufgaben muss aus einer vorhandenen Information eine neue Information erzeugt werden. Diese Art von Arbeit findet beispielsweise in der Rezepturentwicklung in der Lebensmittel-, Chemie- oder Pharmaindustrie statt. Hier werden neue Rezepturen entwickelt, um eine Kundenanforderung zu erfüllen. Andere Anwendungen finden sich in der Produktionsfeinplanung oder Logistikabwicklung.

Digitale Assistenz versus Vollautomatisierung

Automatisierung in der Produktion bezieht sich auf den Einsatz von Maschinen, computergesteuerten Systemen und Technologien, um Produktionsprozesse weitgehend oder vollständig zu automatisieren. Dabei werden menschliche Arbeitskräfte durch automatisierte Systeme ersetzt oder unterstützt, um die Effizienz, Qualität und Produktivität der Produktion zu verbessern.

Die Automatisierung kann verschiedene Formen annehmen, von einfachen mechanischen Vorrichtungen bis hin zu hochentwickelten robotergesteuerten Systemen. Sie umfasst die Automatisierung von Arbeitsabläufen, Aufgaben und Prozessen in der Produktion, z. B. die Automatisierung von Maschinen, die Integration einzelner Prozessschritte oder die Vernetzung.

Der Mensch als Teil des Produktionssystems bietet jedoch den Vorteil der Flexibilität. Bei variantenreicher Produktion mit kleinen Losgrößen, komplexen Wirkzusammenhängen (wie in der Chargenfertigung) oder schwer automatisierbaren Fällen ist eine Vollautomatisierung oft nicht möglich, nicht wünschenswert oder aus betriebswirtschaftlicher Sicht einfach nicht rentabel.

In diesen Fällen können Werkerassistenzsysteme den Menschen unterstützen. Dabei kann der Mensch sowohl physisch (z. B. Exoskelette), visuell (z. B. durch Lichtführung in der Montage) oder mit Hilfe von Informationen (z. B. Hinweise zur Prozessführung) unterstützt werden.

Als Beispiel nehmen wir wieder den Werkzeughersteller HILTI. Neben dem oben erwähnten Überkopf-Exoskelett für motorische Tätigkeiten, wird auch ein ein Robotor für Überkopfarbeiten angeboten. Beide Produktionssysteme erfüllen die gleiche Aufgabe. Eine Differenz gibt es bei der Flexibilität. Der Mensch ist dynamisch einsetzbar. Um den Roboter einzusetzen, muss ein digitales Abbild der Baustelle vorliegen, welches genau geplant werden muss.

Batch-Produktion: Assistent für die Prozessführung

Die Batch-Produktion ist eine Produktionsmethode, bei der Produkte in bestimmten Chargen oder Losen hergestellt werden. Im Gegensatz zur kontinuierlichen Produktion, bei der ein kontinuierlicher Produktstrom hergestellt wird, werden bei der Batch-Produktion einzelne Produktchargen nacheinander hergestellt.

Bei der Batch-Produktion durchläuft jede Batch den gesamten Produktionsprozess, bevor mit der nächsten Batch-Produktion begonnen wird. Dadurch kann jede Charge individuell eingestellt werden. Häufig werden Rohstoffe verarbeitet, die sehr empfindlich auf Umwelteinflüsse (z.B. Hallentemperaturen) reagieren oder deren Verarbeitbarkeit von Charge zu Charge variieren kann.

Ein typisches Beispiel für die Chargenproduktion findet sich in der Lebensmittelindustrie, insbesondere bei der Herstellung von Backwaren. Hier werden für jede Charge bestimmte Mengen an Zutaten abgemessen und verarbeitet.

Abhängig von der Außentemperatur müssen die Kombinationen der Zutaten aufeinander abgestimmt werden. Dies ist eine kombinatorische Aufgabe: Die aktuelle Zutatenliste muss mit der Information über die Außentemperaturen kombiniert werden. Ein Assistenzsystem kann hier unterstützen. Die Empfehlung zur Temperaturanpassung wird dann direkt an den Mitarbeiter weitergegeben.

Software für ein Assistenzsystem

Bei der Auswahl eines Assistenzsystems gibt es verschiedene Anforderungen, die berücksichtigt werden müssen, um sicherzustellen, dass das System effektiv und benutzerfreundlich ist.

Die erste Auswahl ergibt sich aus der Klassifizierung des Assistenzsystems als mechanisch/motorisch, reaktiv, kombiniert oder kreativ. Je nach Typ muss Hardware, Hardware und Software oder nur Software beschafft werden. Im Folgenden konzentrieren wir uns auf Software für kombinative und kreative Anwendungen.

Vorhandenes Expertenwissen sollte möglichst einfach und anpassbar digital abgebildet werden können, um das Assistenzsystem richtig aufzusetzen. Neben einfachen Wenn-Dann-Regeln ist es auch sinnvoll, komplexere Kombinationen über eine Skriptsprache wie Java eingeben zu können.

Das System sollte skalierbar und einfach um neue Anlagen erweiterbar sein. Dies kommt dann zum Tragen, wenn das System von einer Linie auf eine andere übertragen werden soll. Wie bei jeder Software spielen auch die Themen Sicherheit und Datenschutz eine Rolle.

Wir bieten mit smartPLAZA eine Software an, mit der ein Assistenzsystem modular aufgebaut werden kann. Hier können Prozessparameter in Echtzeit abgerufen und überwacht werden. Im Monitoring Modul können Domänenexperten können für bestimmte Szenarien direkt Handlungsempfehlungen hinterlegen, welche dem Mitarbeiter an der Linie zur Verfügung gestellt werden. Ebenfalls können in der Software KI-Modelle angelegt werden, um Empfehlungen für Maschineneinstellungen zu generieren. Gerne evaluieren wir gemeinsam mit Ihnen die Anwendungsfälle, wie die Software in Ihrer Produktion unterstützen kann.

Zugriff via REST-API

Verwalten von Schlüsseln

Schlüssel für den Abruf von Daten können unter im Menü unter Einstellungen / Keys eingesehen werden. Falls ein Verdacht besteht, ein Schlüssel ist in ungewollte Hände gekommen, kann hier ebenfalls der Schlüssel für eine Instanz zurückgesetzt werden.

Abfrage von Messwerten

Messwerte können mit Hilfe eines POST-Statements abgerufen werden. Hierzu wird der Servername und ein Schlüssel benötigt.

POST http://datenberg-server/data-get/?_key=key

Als Optionen stehen dabei zur Verfügung:

{
columns: [],
metadata: [],
filters: [],
limit: 1
}

Beispiele für Filter

Mit einem Wertfilter kann nach spezifischen Werten gefilter werden. Zum Beispiel nur Daten für einen Fertigungsauftrag.

{
   id: "",
   values: []
}

id: Messmerkmal oder Metadaten
values: Liste von Werten

Mit einem Bereichsfilter kann ein Bereich von Daten ausgewählt werden. Zum Beispiel alle Fertigungsaufträge mit Nummern von 1000 bis 1050. Dieser Filtertyp kann nicht auf Text angewandt werden.

{
   id: "",
   min: 0,
   max: 0
}

id: Messmerkmal oder Metadaten (außer Text)
min: Minimaler Wert
max: Maximaler Wert

Beispiel

Anfrage POST-Statement

import requests

myobj = {
   columns: ["c199283", "c853fe6", "cde71a7"],
   metadata: ["m66f36a"],
   filters: [
   {
      id: "m736ee2",
      values: ["Line 1"]
   }
   ],
   limit: 50
}

x = requests.post(http://datenberg-server/data-get/?_key=key, json = myobj) 

print(x.text)

Antwort bei Erfolg

Eine Antwort enthält eine Liste aller Zeilen, die den Filtern entsprechen. In jeder Zeile sind dieangefragten Messmerkmale und Metadaten enthalten.

{
   success: true,
   data: [
   {
      column: data,
      ...
   },
   ...
   ]
}

Antwort bei Fehler

Wurde ein ungültiger API-Key angegeben oder ist die Anfrage ungültig, wird eine Fehlermeldung zurückgegeben.

{
   success: false,
   error: "Fehlermeldung"
}

ExtruAI

What are extrusion processes?

Extrusion processes are used in a variety of industries. Extruders are used to form plastic products, such as sealing systems for car bodies. In addition to molding, extruders are also used for chemical processing and modification of materials. The food industry uses this principle to produce artificial meat substitutes, for example. In the plastics industry, this principle is used to produce rubber compounds such as thermoplastic elastomers. In both industries, single or twin screws are often used to feed a material through different zones in the elongated extruder. In the feed section, the materials are heated, compressed, degassed or mixed with other materials.

Challenges in extrusion processes

Overcoming these challenges requires a combination of process optimization, advanced control systems, and continuous monitoring to ensure consistent and high-quality extruded products.

Our solution with ExtruAI 

With ExtruAI, we will resolve these challenges. With the help of a scalable assistant, we will give the employee on the extrusion line recommendations on how to readjust the process. This will support the employee’s existing knowledge and minimise the number of necessary iterations. The plant operator benefits from less waste and increased machine capacity. Even less experienced employees can regulate the process independently with ExtruAI, which simplifies personnel allocation.
On a technical side, ExtruAI uses a prescriptive Artificial Intelligence, which consists of three components:

How ExtruAI works - self learning, detection of anomalies, notification and giving recommendations
How the ExtruAI component works

Access to extruder data

Extruders are controlled by PLCs. A PLC can provide data (e.g. sensors, setpoints) via the industry standard for machine communication, OPC UA. The OPC UA standard for data exchange is defined to better align communication between different vendors. EUROMAP standards are defined for extrusion applications. The extrusion standard EUROMAP 83 defines several standard parameters such as troughput, specific output, temperature in different zones, product speed and energy consumption. With the PLC as the OPC UA server and our ExtruAI component as the OPC UA client, the data can be easily collected and automatically analyzed.

The KITT4SME project has developed a managed platform for Kubernetes hosting. We can host our component within this platform.

Connection of extruder PLC and EUROMAP83 standard for extruder

KITT4SME Support

We want to say thank you to the whole KITT4SME team – here you find the official website.
Here you can find the KITT4SME platform for application hosting and managing.
This work was supported by the H 2020 project “Platform enable KITs of Artificial Intelligence for an Easy Uptake of SMEs (KITT 4 SME)” under GA 952119.
Furthermore, we want to thank HEXPOL Compounding AB for supporting us with data from their manufacturing processes during the project. 

Komponenten verknüpfen

Funktionsweise

Um Komponenten miteinander zu verknüpfen gibt es zwei Wegen:

  1. Filter dynamisch setzen: Mit einem Zeit-Filter oder einer Meta-Daten Komponente können dynamisch durch den Nutzer Filtereinstellungen gesetzt werden
  2. Messmerkmale dynamisch auswählen: Mit einer Messmerkmalsauswahlliste können einzelne Merkmale angewählt werden, welche an andere Komponenten weitergegeben wird.

Beide Komponenten können sich auch gegenseitig ergänzen.

Eine Anzeigekomponente (Liniendiagramm, Ampel, Statistiken) nutzt dabei die dynamische Komponente (Meta-Daten, Messmerkmale oder Zeitfilter) als Filter bzw. Inputgeber.

Aufbau

  1. Dynamische Komponente erstellen
    – Hinzufügen einer dynamischen Komponente (z.B. Meta-Daten Auswahlliste) zum Dashboard. Diese befinden sich unter dem Reiter “Steuerung und Auswahl”
    – Editieren der Komponente durch Doppelklick
    – Auswahl der Datenquelle und des Meta-Attributes
    – Ggf. Limit unter Reiter “Filter” erhöhen
    – Sprechenden Namen für Komponente vergeben (z.B. Auswahl Fertigungsauftrag)
  2. Liniendiagramm verknüpfen
    – Hinzufügen eines Liniendiagramms zum Dashboard
    – Auswahl des Messmerkmals (Achtung: Gleiche Tabelle wie Meta-Auswahlliste auswählen)
    – Filter hinzufügen (statt das Hashtagssymbol den Link Button auswählen)
    – Auswahlliste auswählen (Im Dropdown nach z.B. Auswahl Fertigungsauftrag suchen)

Dies kann beliebig für verschiedene Auswahllisten erweitert werden.

Messmittelanbindung

Was ist eine Messmittelanbindung?

Im Rahmen der Überwachung und Dokumentation von Produktionsprozessen müssen verschiedene Parameter mit Hilfe von Messmitteln gemessen und protokolliert werden. Die ISO9001 fordert, dass eine Organisation sicherstellt, dass das Personal, das die Messmittel bedient, über die notwendigen Kenntnisse und Fähigkeiten verfügt, um die Messungen korrekt durchzuführen und die Ergebnisse richtig zu interpretieren. Das Notieren der Messwerte von Hand auf Papier oder das Eingeben der Werte in einen Computer ist fehleranfällig. Außerdem ist es mit einem hohen Zeitaufwand verbunden. Mit Hilfe einer Messmittelanbindung werden die erfassten Messwerte direkt digital übertragen. Auf diese Weise wird das Fehlerpotential bei der Übertragung ausgeschlossen und die Messwerte können direkt einer automatisierten Überwachung und Auswertung übergeben werden.

Arten der Messmittelanbindung

Prüfplanbasierte Abfrage von Messmittel

Messwerte für die Stichprobenprüfung oder für einzelne Bauteile werden direkt für die Dokumentation in einem Prüfplan erfasst. Der Prüfplan gibt hier also die Abfrage vor. In diesem Fall müssen die Messdaten des Messmittels nicht kontinuierlich, sondern nur während einer Prüfung übertragen werden. In diesem Fall ist zu definieren, wie die Prüfwertübernahme ausgelöst wird. Dies kann durch die Verwendung eines Hand- oder Fußtasters erfolgen. Eine andere Möglichkeit ist der Datenabruf durch den Prüfplan. Nach Betätigung eines Buttons in der Eingabemaske ruft die Software im Hintergrund proaktiv den Messwert vom Prüfgerät ab.

Kontinuierliches On-Line-Monitoring

Werden Messwerte nicht stichprobenartig mit Hilfe eines Prüfplans erfasst, sondern sollen Prozesse kontinuierlich dokumentiert werden, hat dies auch Auswirkungen auf die Messmittelanbindung. Für die Datenabfrage wird ein Intervall festgelegt, z.B. sollen alle 5 Minuten die Temperaturwerte in der Produktionshalle abgespeichert werden.

Wie können Messmitteldaten übertragen werden? Lösung 1: Prüfplanbasiert über eine digitale Eingabemaske; Lösung 2: Über ein kontinuierliches Montioring

Schnittstellen zu Messmitteln

Schnittstellentypen

Welche Schnittstellen existieren nun? Prinzipiell gilt hierbei – viele Wege führen nach Rom. So ist auch die folgende Aufzählung nicht abschließend. Je nach Hersteller und Alter des Messmittels existieren weitere Schnittstellen. Mit der folgenden Aufzählung wird jedoch ein Groß der existierenden Schnittstellen abgebildet. Die Einstufung in Unidirektional und Bidirektional ist eine abstrahierte Einstufung – je nach Auslegung der Schnittstelle durch den Hersteller können mehr oder weniger Optionen gegeben sein.

NameBeschreibungÜbertragungTyp
DateiimportImport von Flatfiles wie z.B. csv/txt/datUnidirektionalPrüfplanbasiert,
On-Line Monitoring
MessboxenImport von Daten über Messmittelboxen wie z.B. Steinwald oder IBR MesstechnikUnidirektional,
Bidirektional
Prüfplanbasiert
DFQAustauschformat für Prüfwerte, auch Q-DAS ASCII Transferformat genannt. Standardformat mit Beschreibungsdaten (.DFD) und Messwertedaten (.DFX) – werden beide Daten gemeinsam übertragen, ist die Dateieindung .DFQUnidirektional,
Bidirektional
Prüfplanbasiert
Serielle SchnittstellenÜbertragung über ein serielles Kabel (wie z.B. RS232)Unidirektional,
Bidirektional
Prüfplanbasiert,
On-Line Monitoring
Ethernet-KommunikationÜbertragung über ein LAN-Kabel, wie zum Beispiel Modbus TCPUnidirektional,
Bidirektional
Prüfplanbasiert,
On-Line Monitoring
Analoge SystemeÜbertragung des analogen Sensorsignals, wie z.B. 4..20mA Signale UnidirektionalPrüfplanbasiert,
On-Line Monitoring
OPC UAÜbertragung digitaler Werte über Ethernet, Standard für MaschinendatenauswertungUnidirektional,
Bidirektional
Prüfplanbasiert,
On-Line Monitoring
IO-LinkHerstellerübergreifender Standard zum Austauschen von digitalen SensordatenUnidirektional,
Bidirektional
Prüfplanbasiert,
On-Line Monitoring
APIProgrammierschnittstelen zum Austausch von Daten zwischen IT-SystemenUnidirektional,
Bidirektional
Prüfplanbasiert,
On-Line Monitoring
Übersicht über Schnittstellen für Messmittelanbindungen

Messmittelboxen (Gateway)

Beim Anschluss eines Messmittels muss ein Schnittstellentyp ausgewählt werden. Der konkrete Typ hängt von den Möglichkeiten des Messgerätes ab. Einige Geräte verfügen bereits über eine digitale Schnittstelle. Ist dies nicht der Fall, kommen sogenannte Messmittelboxen zum Einsatz. Bekannte Hersteller sind z.B. Steinwaldboxen oder IBR-Messtechnik. Die Boxen sind in der Lage, die Signale von verschiedenen Messgeräten umzuwandeln und standardisiert verarbeitbar zu machen. Für verschiedene Schnittstellen werden passende Hardwareausführungen angeboten. Neben kabelgebundenen Ausführungen gibt es auch kabellose Möglichkeiten über WLAN oder Bluetooth. Weitere Möglichkeiten sind je nach Anwendungsfall Lösungen auf Basis von einer SPS-Steuerung, Mikrocontrollern wie z.B. Raspberry Pis oder auf Basis von IO-Link.

Bei der Auswahl des Gateways ist zu beachten, ob der Informationsfluss nur vom Messgerät zum Server oder auch vom Server zurück erfolgen soll. Letzteres ist dann sinnvoll, wenn Prüfprogramme oder Spezifikationsgrenzen an das Messgerät übertragen werden sollen.

Weiterleitung von Messdaten

Sind die Messmittel an einen Server angeschlossen, werden die Messwerte auch in der Regel weiterverarbeitet. Standardmäßig werden die Messwerte in einem CAQ- oder ERP-System den jeweiligen Prüfaufträgen zugeordnet und für die Losfreigabe verwendet. Die Daten können aber auch für eine Auswertung oder ein Monitoring interessant sein. Dazu werden die Messwerte in einer Datenbank gespeichert oder auf einem Echtzeit-Dashboard dargestellt.

Auch hier kann die Kommunikation bidirektional zwischen den IT-Systemen (z.B.: ERP / MES / CAQ) und dem Messmittelanbindungssystem erfolgen oder auch nur in eine Richtung. Zum Beispiel können einzelne Prüflose in das ERP-System zurückgemeldet und Prüfpläne im Erfassungssystem verwaltet werden. Unidirektional wäre auch der Übertrag von Vorgaben aus dem ERP-System, wie Prüfaufträge oder Spezifikationsdaten. Beim bidirektionalen Austausch werden in der Regel Vorgabedaten und Prüfaufträge aus dem ERP-System übertragen und Ergebnisse zurückgemeldet. Einzelne ERP-Systeme haben hierfür spezifische Schnittstellen (QM-IDI für SAP wird weiter unten beschrieben) oder die Daten werden zum Beispiel über eine SQL-Tabelle ausgetauscht.

Messmittelanbindung mit der DatenBerg smartPLAZA

Mit der smartPLAZA bieten wir ein System zur Kommunikation mit Messgeräten, zur Datenanalyse und zur Datenüberwachung an. Die smartPLAZA ist sowohl für den bidirektionalen als auch für den unidirektionalen Austausch auf allen Kommunikationswegen geeignet. Mit Hilfe des Data Gateways wird die Kommunikation mit den Messgeräten sichergestellt. Für die gängigen Messgeräte existieren Standardschnittstellen, die einfach angepasst werden können.

In der smartPLAZA können sowohl prüfplanbasierte Abfragen von Messmitteln als auch eine kontinuierliche Online-Überwachung von Messmitteln und Maschinen durchgeführt werden. Die Daten können anschließend direkt an weitere IT-Systeme übergeben werden – API-basiert oder über einen Datenbankexport. In der smartPLAZA können aber auch Analysen durchgeführt und die Messwerte auf Trends und Anomalien überwacht werden.

Die Prüfdatenerfassung findet in einer Webeingabemaske statt und kann mit Bildern sowie Prüfanweisungen versehen werden. Mit einem Knopfdruck werden dann die Daten vom Messmittel in die Eingabemaske übertragen.

Übernahme von Messmitteldaten in die smartPLAZA

Messmittelanbindung in SAP (R3/S4-HANA)

Eine direkte Anbindung von Messgeräten ist in SAP (sowohl R3 als auch S4-HANA) nicht möglich. Hierfür muss eine separate Software eingesetzt werden.

Mit dem Inspection Data Interface (QM-IDI) bietet das Qualitätsmanagement-Modul von SAP eine Schnittstelle für externe Systeme. Diese Schnittstelle bietet zwei grundlegende Funktionalitäten:

Für beide Funktionalitäten stellt die QM-IDI-Schnittstelle verschiedene Funktionsbausteine zur Verfügung, mit denen die erforderlichen Daten ausgetauscht werden. Je nach Konfiguration des SAP-Systems müssen die richtigen Bausteine ausgewählt und in die Schnittstelle eingebunden werden.

Projekt „Digitale Messmittelanbindung“ umsetzen

Um die digitale Messmittelanbindung in der Produktion umzusetzen, bietet sich ein methodisches Vorgehen an. Wir haben ein vier Stufen Projektvorgehen mit den relevanten Projektschritten für Sie zusammengefasst:

  1. Liste aller Messmittel mit Information über mögliche Schnittstellen erstellen
    Welche Messmittel existieren und wie werden Daten erfasst (On-Line, prüfplanbasiert)?
    Welche Messmittel bringen, bereits Schnittstellen mit sich?
    Wo bestehen bereits Messmittelboxen?
    Welche Prüfplätze benötigen Hardware zur digitalen Datenerfassung?
    Output Schritt 1: Liste mit Informationen zum Bestand an Messmitteln und Schnittstellen
  2. Informationsfluss der Messmittel zu relevanten IT-Systemen definieren
    Wie sollen die Daten vom Prüfgerät in welches IT-System fließen?
    Wie werden Prüfaufträge getriggert und wie wird die Prüfaufgabe an den Mitarbeiter kommuniziert?
    Wie sehen die konkreten Schnittstellen der beteiligten IT-Systeme aus?
    Output Schritt 2: Architektur für den Datenaustausch ist definiert
    Die IT-Abteilung kann nun parallel die benötigte Infrastruktur (Netzwerk, Firewalls) schaffen.
  3. Ranking der Messmittel hinsichtlich Kritikalität / Kosten Schnittstelle
    Welche Messmittel sind besonders kritisch hinsichtlich Fehleingaben?
    Welche Kosten (Hardware, Lizenzen) werden für die Einbindung der Messmittel anfallen?
    Output Schritt 3: Ranking der Messmittel hinsichtlich Priorisierung
  4. Anbindung einzelner Messmittel
    Welche Roll-Out Gruppen ergeben sich aus Schritt drei?
    Wie sollen die Daten pro Messmittel abgefragt werden (z.B. Auflösung einstellen)?
    Output Schritt 4: Angeschlossene Messmittel je Roll-Out Gruppe