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:

• SELECT: Dieser Teil der Abfrage gibt an, welche Spalten oder Berechnungen zur Anzeige oder Verwendung ausgewählt werden sollen. Verwenden Sie ein Sternchen (*), um alle Spalten auszuwählen, oder geben Sie die gewünschten Spaltennamen durch Kommas getrennt an.
• FROM: Hier geben Sie den Namen der Tabelle an, aus der die Daten abgerufen werden sollen.
• WHERE: Dies ist optional, aber wenn Sie bestimmte Zeilen aufgrund von Bedingungen auswählen möchten, verwenden Sie den WHERE-Ausdruck. Hier können Sie Bedingungen angeben, die erfüllt sein müssen, damit eine Zeile ausgewählt wird. Die Bedingungen werden oft mit logischen Operatoren wie AND und OR kombiniert.

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.

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.

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.

Relevante Begriffe einfach erklärt

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

• Broker: Ein Server, der MQTT-Nachrichten von Publishern empfängt und an die entsprechenden Abonnenten weiterleitet.
• Client: Ein Gerät oder eine Anwendung, die MQTT verwendet, um Nachrichten zu veröffentlichen oder zu abonnieren.
• Pusblish (Veröffentlichen): Beim Veröffentlichen sendet ein MQTT-Client (Publisher) eine Nachricht in einem bestimmten Kanal an den MQTT-Broker. Die Payload der Nachricht enthält die eigentlichen Daten, die übertragen werden sollen, z.B. Sensormesswerte, Statusinformationen oder Befehle.
• Subscribe (Abonnieren): Beim Abonnieren teilt ein MQTT-Client (Subscriber) dem Broker mit, dass er Nachrichten zu einem bestimmten Thema erhalten möchte. Der Client kann mehrere Themen gleichzeitig abonnieren. Sobald der Broker eine Nachricht mit einem abonnierten Thema erhält, leitet er diese an den entsprechenden Abonnenten weiter. Die Verwendung von Abonnements ermöglicht es, nur relevanten Informationen zu erhalten, anstatt alle veröffentlichten Nachrichten zu erhalten.
• Payload: Die Payload ist der eigentliche Nutzdatenteil einer MQTT-Nachricht. Die Payload kann verschiedene Formate haben, abhängig von der Art der zu übertragenden Daten. Beispielsweise kann es sich um Temperaturwerte, Textnachrichten, Steuerbefehle oder andere relevante Informationen handeln.
• Overhead: Der Overhead umfasst die zusätzlichen Daten, die durch das Protokoll selbst während der Nachrichtenübertragung eingeführt werden, einschließlich Header, Steuerungsinformationen und alle zusätzlichen Bytes neben den eigentlichen Nutzdaten.
• Topic (Kanal): Das Veröffentlichen und Abonnieren von Nachrichten wird mit Hilfe von Topics organisiert. Topics ermöglichen es, Nachrichten nach ihrem Inhalt oder ihrer Bedeutung zu gruppieren. Beispiele für Topics könnten sein: “sensoren/temperatur” oder “halle1/spritzguss/zustand”.
• QoS (Quality of Service): Die Stufe der Nachrichtenübertragungsgarantie, die angibt, wie zuverlässig die Zustellung von Nachrichten sein soll (QoS 0, QoS 1, QoS 2). Mehr zum Thema QoS in den nachfolgenden Abschnitten.

Wildcard

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

• Single-Level Wildcard (+): Das Pluszeichen wird in einem Abonnement verwendet, um ein einzelnes Level des Topics zu ersetzen. Zum Beispiel, wenn ein Subscriber “halle1/+/licht” abonniert, empfängt er Nachrichten von Themen wie “halle1/decke/licht” und “halle1/buero/licht”.
• Multi-Level Wildcard (#): Das Rautenzeichen wird verwendet, um mehrere Ebenen eines Topics zu ersetzen. Wenn ein Subscriber “halle1/#” abonniert, empfängt er Nachrichten von allen Themen, die mit “halle1/” beginnen, unabhängig von den nachfolgenden Ebenen. Das bedeutet, er erhält Nachrichten, wie “halle1/decke/licht” oder “halle1/spritzguss/temperatur”.

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:

• QoS 0 – höchstens einmal eine Nachricht versenden
• QoS 1 – mindestens einmal eine Nachricht versenden
• QoS 2 – genau einmal eine Nachricht versenden

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.

Entscheidungshilfe: QoS-Stufen

• QoS 0, wenn: Stabile Verbindung zwischen Sender und Empfänger bspw. bei einer verkabelten Verbindung, Manche Nachrichten dürfen verloren gehen, Es müssen keine Daten in einer Warteschlange bei fehlender Verbindung aufgestaut werden auf Sender-Seite
• QoS 1, wenn: Jede Nachricht muss empfangen werden und die Anwendung kann mit Duplikaten umgehen
• QoS 2, wenn: Jede Nachricht muss genau einmal empfangen werden und der zusätzliche Overhead im Vergleich zu QOS1 ist handhabbar.

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

• Benutzername und Passwort: MQTT ermöglicht die Authentifizierung von Clients durch die Verwendung von Benutzernamen und Passwörtern. Diese Informationen werden bei der Verbindungsherstellung verwendet.
• TLS/SSL-Verschlüsselung: MQTT unterstützt die Verschlüsselung des Datenverkehrs über das Transport Layer Security (TLS) oder das Secure Sockets Layer (SSL) Protokoll. Dies schützt die Daten während der Übertragung.
• Client-Zertifikate: Statt nur Benutzername und Passwort können auch Client-Zertifikate verwendet werden, um die Authentizität von MQTT-Clients sicherzustellen.
• Quality of Service (QoS): Wie oben beschrieben, beeinflusst die QoS-Stufe (0, 1, 2) die Nachrichtenübermittlung und -bestätigung. Höhere QoS Levels bieten mehr Sicherheit bei der Nachrichtenzustellung, erfordern aber auch mehr Overhead.
• Keep Alive und Timeout: MQTT verwendet Keep Alive Mechanismen, um die Verbindung zwischen Client und Broker aufrecht zu erhalten. Timeout-Einstellungen können unautorisierten Zugriff oder persistente Verbindungen einschränken.

Sicherheitsmöglichkeiten auf Broker-Ebene

• Verbindungssicherheit: Broker können so konfiguriert werden, dass unbenutzte oder nicht authentifizierte Verbindungen automatisch getrennt werden, um Sicherheitslücken zu minimieren.
• Access Control Lists (ACL): MQTT-Broker können Zugriffskontrolllisten verwenden, um festzulegen, welche Clients auf welche Themen (Topics) zugreifen dürfen. Dadurch ist eine feingranulare Zugriffskontrolle gegeben.

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

• Leichtgewichtig und effizient: MQTT ist auf Effizienz ausgelegt und hat einen geringen Overhead. Dies ermöglicht eine effiziente Nutzung von Netzwerkbandbreite und Ressourcen, was besonders in ressourcenbeschränkten Umgebungen wie IoT-Geräten wichtig ist.
• Flexibles Publish-Subscribe-Modell: Das Publish-Subscribe-Modell ermöglicht eine flexible und lose gekoppelte Kommunikation zwischen verschiedenen Clients, was die Skalierbarkeit und Erweiterbarkeit erleichtert.
• Topics und Wildcards: Die Verwendung von Topics und Wildcards ermöglicht eine einfache Organisation und Filterung von Nachrichten, was die Effizienz und Flexibilität der Kommunikation erhöht.
• Offline-Nachrichten: MQTT-Broker können Nachrichten für Clients speichern, die offline sind. Sobald ein Client wieder online ist, erhält er die zwischengespeicherten Nachrichten.
• Einfache Integration: MQTT ist in eine Vielzahl von Plattformen und Anwendungen integrierbar. Es gibt zahlreiche MQTT-Bibliotheken und Implementierungen für verschiedene Programmiersprachen und Betriebssysteme. Insbesondere Implementierungen mit niedrigen QoS Levels sind sehr einfach zu implementieren.

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

• Komplexere Implementierung bei hohem QoS-Level: Die Implementierung von QoS 2 (Exactly Once) erfordert einen komplexeren Nachrichtenaustausch, der zusätzlichen Overhead verursachen kann.
• Abhängigkeit vom Broker: In einem Publish-Subscribe-Modell sind die Clients von einem Broker abhängig, was bedeutet, dass der Broker ein Single Point of Failure sein kann.
• Echtzeitimplementation nicht empfehlenswert: MQTT bietet eine effiziente Kommunikation, ist aber nicht immer die beste Wahl für Anwendungen, die extrem niedrige Latenzzeiten erfordern, wie z.B. Echtzeitsysteme.
• Datentyp und Formatierung: Das Format der Nutzlast muss sowohl dem Sender als auch dem Empfänger bekannt und durch beide implementiert sein, damit der Austausch korrekt stattfindet.

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:

• Siemens
• Beckhoff
• Bachmann Electronic

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:

• Automatisierte Überwachung: Die Einführung von drahtlosen Sensor-Gateways und MQTT ermöglicht eine automatisierte Überwachung der Motoren in Echtzeit. Die manuelle Datenerfassung entfällt und das Logistikzentrum kann den Zustand der Motoren jederzeit überwachen.
• Vorausschauende Wartung: Die gesammelten Daten ermöglichen die Analyse von Vibrationen und Laufzeiten, was eine vorausschauende Prognose des Verschleißzustands der Motoren ermöglicht. Die Wartungsabteilung kann potenzielle Probleme frühzeitig erkennen und proaktive Maßnahmen ergreifen.
• Automatisierte Ticket-Erstellung: Bei Anzeichen von Verschleiß oder ungewöhnlichen Vibrationen wird automatisch ein Wartungsticket generiert. Dies beschleunigt die Reaktionszeit und optimiert den Instandhaltungsprozess.

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

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.

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:

• Energiezähler
• Druckluftkompressoren
• Speicherprogrammierbare Steuerungen (SPS, z.B. Siemens Logo)

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:

• Einfachheit: Modbus ist ein vergleichsweise einfaches Protokoll, das leicht zu implementieren und zu verstehen ist. Die einfache Struktur erleichtert die Integration in verschiedene Geräte und Systeme.
• Weit verbreitet: Modbus ist ein offenes Protokoll und wird von einer Vielzahl von Herstellern unterstützt. Dies führt zu einer hohen Interoperabilität zwischen verschiedenen Geräten und ermöglicht es, Komponenten verschiedener Hersteller in einem System zu integrieren.
• Kosten: Aufgrund seiner Einfachheit und langjährigen Verbreitung ist Modbus oft kostengünstiger als andere komplexe Protokolle.
• Flexibilität: Modbus bietet sowohl serielle (Modbus RTU) als auch TCP/IP-basierte (Modbus TCP/IP) Kommunikationsvarianten, was es ermöglicht, das Protokoll in verschiedenen Netzwerktopologien einzusetzen.

Nachteile:

• Sicherheit: Das Protokoll wurde ursprünglich nicht mit Sicherheitsmerkmalen (z.B. User-/Passwortschutz) entwickelt, und die älteren Versionen des Protokolls haben keine eingebauten Sicherheitsmechanismen. Dies kann in modernen Umgebungen ein Sicherheitsrisiko darstellen. Seit 2019 existiert zwar eine Spezifikation für den Einsatz des Verschlüsselungsprotokoll TLS, dies betrifft jedoch nur Geräte neueres Baujahres.
• Datenmenge: Die Datenkapazität pro Nachricht ist begrenzt, was die Übertragung großer Datenmengen ineffizient machen kann.
• Fehlererkennung: Im Protokoll ist keine Fehlererkennung oder Fehlerkorrekturmechanismen integriert, was bedeutet, dass die Zuverlässigkeit der Datenübertragung in hohem Maße von der zugrunde liegenden physischen Verbindung abhängt.
• Keine Adressenvergabe: Das Protokoll bietet keine dynamische Adressvergabe für Geräte, was in großen Netzwerken oder bei der Hinzufügung neuer Geräte problematisch sein kann.
• Geschwindigkeit: Obwohl RTU schneller als TCP/IP sein kann, ist es im Vergleich zu einigen modernen Protokollen langsam und könnte für Anwendungen mit sehr hohen Geschwindigkeitsanforderungen ungeeignet sein.

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.

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:

• Schreiben der Register mit der Funktion 16 “Write Multiple Registers” oder 06 “Write Single Register”.
• Lesen der Register mit der Funktion 03 “Read Holding Registers”. Nicht beschriebene Register haben den Inhalt “0”.

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:

• Netzdruck; Protokolladresse: 41; Holding Register: 40298; Einheit: mbar, Format: Int
• Energiezähler; Protokolladresse: 46; Holding Register: 40323; Einheit: kWh; Format: Int

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

• Offizielle Modbus Dokumentataion
• Spezifikation für die TLS Verschlüsselung für Modbus

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.

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:

• Whiteboard oder Flipchart
• Filzstifte
• Post-Its für die möglichen Einflussgrößen (leicht zu verschieben)

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.

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:

• Physische Assistenzsysteme unterstützen bei anspruchsvollen körperlichen Tätigkeiten und dienen der Kompensation körperlicher Leistungseinbußen. Dabei gibt es Anwendungen von mechanisch-motorischer Kraftunterstützung und personalisierten Montagearbeitsplätzen für einfache, Arbeitssituationen bis hin zu kollaborativen Robotersystemen für hochvariable Produktions- und, Montageprozesse. Dabei steht die Unterstützung des Muskel-Skelett-Systems im Vordergrund.
• Sensorische Assistenzsysteme dienen der Kompensation funktionaler, oft altersbedingter Veränderungen der Sinnesorgane. Fortgeschrittene Systeme adressieren vor allem hör- und sehbedingte Einschränkungen und bieten eine kombinierte kognitiv-sensorische Unterstützung (z. B. Augmented-Reality-Brillen).
• Kognitiv unterstützende Assistenzsysteme dienen vor allem der anwendungsgerechten, echtzeitnahen Informationsbereitstellung zur Entscheidungsunterstützung der Beschäftigten. Die funktionale Unterstützung zielt je nach Unterstützungsgrad vor allem auf die Reaktions-, Denk-, Erinnerungs- und Schlussfolgerungsfähigkeit. Kernelemente der Assistenzsysteme sind vor allem mobile Endgeräte und interaktive Visualisierungssysteme.

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.

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.

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.

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.

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:

• Export von Vorgabedaten (z.B. Prüfpläne, Spezifikationen, Prüfaufträge) aus SAP (sog. Download)
• Importieren von Ergebnisdaten (z.B. Messwerte, Freigaben) nach SAP (sog. Upload).

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