Daten sind die Grundlage vieler I4.0-Applikationen und auch für die Anwendung der Module der AKKORD AI-Toolbox. Es gibt viele verschiedene Arten von Daten, zum Beispiel Kundendaten, Auftragsdaten oder Rezepte in der Produktion. Dieser Artikel befasst sich speziell mit Prozessdaten. Prozessdaten sind digitale oder analoge Werte, wie beispielsweise Temperatur, Druck, Maschineneinstellungen, die relevante prozessbezogene Informationen darstellen bzw. einen Prozess beschreiben. Die Erfassung von Daten aus Prozessen ist keine triviale Aufgabe, da Anlagen oft geschlossene Systeme sind oder historisch gewachsen und dementsprechend heterogen aufgebaut sind. Hat man es mit einem geschlossenen System zu tun, ist zum Beispiel ein Problem, durch nachgerüstete Datenerfassung die Herstellergarantie nicht zu verletzen. Bei gewachsenen Systemen stellen unterschiedliche Schnittstellen und Protokolle sowie gegebenenfalls Synchronisierung und Datenzusammenführung Herausforderungen dar. Der Artikel beschreibt diese Herausforderungen, wie heterogene Datenquellen und Protokolle, bei der Akquisition von Daten im Allgemeinen, gibt Tipps zur Datenerfassung und geht beispielhaft auf die Umsetzung der Datenerfassung im Anwendungsfall des Projektpartners PolyMerge sowie dem Autorenn-Demonstrator und den Ansatz der AKKORD-Lernstation ein. Grundlegende Kenntnisse zu gängigen industriellen Protokollen und Komponenten industrieller Anlagen sind Voraussetzung, um die Schwierigkeiten und zugehörigen Tipps zu verstehen.
14.1 Motivation
Bei der Umsetzung von Projekten im Kontext von Industrie 4.0 (I4.0) ist meist die erste Aufgabe, Daten aus der Produktion (Operations Technology; OT) in dafür vorgesehene Verarbeitungsinfrastruktur (Information Technology; IT) zu transferieren. Dieser Schritt entspricht der ersten Phase der Prozesskette der Industriellen Datenanalyse (siehe Kap. 4). Diese Aufgabe bringt zum einen Herausforderungen in Bezug auf die Sicherheit der OT mit (s. z. B. Hardt et al., 2021, S. 40 f.; Hengel & Hardt, 2020, S. 58 f.) und zum anderen weitere verschiedene Herausforderungen, die direkt mit der Datenerfassung zusammenhängen und die im nächsten Abschnitt aufgeführt werden.
Ein Problem bei der Datenerfassung stellen heterogene Datenquellen dar. In modernen Anlagen werden viele relevante Daten in der Speicherprogrammierbaren Steuerung (SPS) der Anlage erfasst und können von dort ausgelesen werden. Es gibt mehrere Möglichkeiten, Daten aus einer SPS auszulesen. Eine besonders einfache Methode ist z. B. bei SPS-Systemen der Firma SIEMENS möglich. Hier kann über das S7 Protokoll direkt auf alle SPS-Variablen (z. B. Merker, Datenbausteine, Eingänge, Ausgänge, Zähler) lesend und schreibend zugreifen, sofern die jeweilige SPS nicht im sogenannten „optimierten Modus“ läuft. Eine potenzielle Folge, die dabei allerdings beachtet werden muss, ist eine eventuell resultierende Verlängerung der Zykluszeit. Generell hat jeder Hersteller für den Zugriff auf eine SPS sein eigenes proprietäres Protokoll. Darüber hinaus kann auch z. B. über Standards wie modbus oder OPC UA auf viele SPS-Systems zugegriffen werden. Allerdings muss der Zugriff über OPC UA speziell eingerichtet werden und kann z. B. nach einem Update der SPS durch den Hersteller wieder überschrieben werden. Außerdem erhöht diese Art des Zugriffs die CPU-Last und kann die Echtzeitfähigkeit beeinträchtigen.
Anzeige
In älteren Anlagen oder wenn z. B. die Datenlage in der SPS nicht ausreichend ist, müssen Daten zusätzlich aus verbauter oder externer Sensorik/Aktorik oder aus Feldbussen ausgelesen werden. Beim Anbringen von externer Sensorik oder auch beim Zugriff auf die SPS ist übrigens stets darauf zu achten, dass keine Aktionen durchgeführt werden, die die Garantie des Herstellers verletzen.
Liegen verschiedene Datenquellen in einem System vor, bringt dies wiederum weitere Herausforderungen mit sich. Zum einen haben diese Datenquellen meist unterschiedliche physikalische Schnittstellen (z. B. LAN, seriell, Funk, …) mit denen man sich physikalisch verbinden können muss und zum anderen herrschen für gewöhnlich in unterschiedlichen Produkten auch unterschiedliche Protokolle und Schnittstellen zur Datenkommunikation (z. B. OPC UA, MQTT, modbus, CoAP, RS485, S. 7, 5G, LoRaWAN, LTE, WLAN, …), die man wiederum „sprechen“ können muss, um die Daten abzugreifen. Außerdem müssen die Daten unter Umständen bei nichtechtzeitfähigen Systemen oder Transportwegen zeitlich synchronisiert werden, um zu passenden Datensätzen zu einem Event zusammengestellt werden zu können. D. h. es sind entweder zeitsynchronisierte Datenquellen notwendig, die einen Erfassungszeitpunkt zum erfassten Wert mitliefern oder bei der Abtastung durch z. B. ein Gateway muss dieses einen Zeitstempel vergeben.
Ebenso kann es vorkommen, dass ein Prozess unterschiedliche Datensenken hat (Datenbanken, wie z. B. mySQL, SQlite Influx-DB, CSV-Dateien, ERP-Systeme, …), auch mit diesen muss man kommunizieren können, um die Daten dort ablegen zu können. Eventuell ist auch eine Visualisierung der Daten oder eine Darstellung historischer Daten in Linien-Diagrammen notwendig, die umgesetzt werden muss.
Unter Umständen stellen zudem die Schnelligkeit bzw. Abtastrate sowie die Auflösung bzw. Bittiefe der benötigten Daten, ein Problem dar. Es muss sichergestellt werden, dass alle Komponenten, aus denen Daten erhoben werden, die Daten schnell genug erheben und auch kommunizieren können und die gewünschte Genauigkeit liefern. Ist dies nicht der Fall, müssen Strategien erarbeitet werden und gegebenenfalls zusätzliche Komponenten recherchiert werden, mit denen das betrachtete System nachgerüstet werden kann, um die vorliegenden Anforderungen an Schnelligkeit und Genauigkeit zu erfüllen. Weiterhin müssen Daten zwischengespeichert werden können, falls es zu kurzen Unterbrechungen und Verzögerung beim Schreiben der Daten kommt.
Anzeige
Dieser Abschnitt hat zusammenfassend aufgezeigt, wie vielfältig die Probleme und Herausforderungen zur Bereitstellung der benötigten Datengrundlage für I4.0-Prozesse sind. Im folgenden Abschnitt werden praktische Tipps und Lösungsstrategien für die Erfassung von Daten vorgestellt.
14.1.2 Gateways und Retrofitting im produzierenden Gewerbe
Maschinen und Anlagen, die nicht über entsprechende Technologien zur Vernetzung verfügen, können bei Bedarf mithilfe vom sogenannten Retrofitting auch nachträglich in I4.0-Prozesse integriert werden (Wöstmann et al., 2019, S. 94 ff.). Zur Erfassung und Anbindung von Daten verschiedener Quellen sind typischerweise industrielle Netzwerkknoten erforderlich, die Systeme mit unterschiedlichen Übertragungsprotokollen miteinander verbinden und auch als Gateways bezeichnet werden. Diese haben in der Regel mehrere physikalische Schnittstellen und beherrschen verschiedene Protokolle, um so Daten aus diversen Quellen auslesen zu können. Einige Gateways ermöglichen die Vorverarbeitung von Daten und können so erhobene Daten z. B. auf gewünschte Formate vor der Datenweitergabe transformieren oder diverse Kenngrößen wie beispielsweise Minima, Maxima, Durschnitt oder Varianz berechnen. Durch letzteres kann die Übertragung von Rohdaten entfallen und der Datenverkehr mitunter erheblich reduziert werden. Aus der Kombination von unterschiedlichen Rohdaten können auch neue Informationen generiert werden.
Bietet ein betrachtetes industrielles System an sich nicht genügend oder nicht hinreichende Sensorik für gewünschte Analysen, müssen Komponenten nachgerüstet werden. Beim Einsatz von Gateways sowie beim Nachrüsten von Komponenten muss darauf geachtet werden, dass die Herstellergarantie nicht gefährdet wird. Außerdem ist es bei der Anschaffung zusätzlicher Sensorik u. U. hilfreich darauf zu achten, dass diese nicht nur benötigte Genauigkeit und Schnelligkeit erfüllen, sondern idealerweise auch Protokolle beherrschen, die schon im System vorherrschen. Weiterführend liefern Hardt et al., (2021, S. 31–34) nützliche Hinweise zur Auswahl von Sensorik. Integriert man zusätzliche Sensorik, ist es oft ratsam, die erhobenen Werte über Gateways zu erfassen und nicht in die SPS weiterzugeben, um dort nicht in die Konfiguration und Programmierung eingreifen zu müssen.
Kann man auf vorhandene Sensorwerte in einem System nicht einfach über die SPS zugreifen, bieten sich Signalverdoppler an. Diese können für gewöhnlich zwischen Sensor und SPS geklemmt werden und am Verdoppler kann dann das Signal z. B. mit einem Gateway abgegriffen werden. Ebenso sind Schütze ein einfaches Hilfsmittel, um digitale Daten aus einem Schaltschrank ohne Eingriff in die Anlage abzugreifen. Nach der Prozessdatenerfassung schließt sich unter Umständen die Zusammenführung mit anderen Daten an, eventuell die Einspeisung in ein Datenbackend-System (siehe Kap. 5).
14.2 Datenerfassung in AKKORD
Nachdem der vorige Abschnitt die allgemeinen Probleme und Lösungsmöglichkeiten bei der Erfassung von Daten in industriellen Prozessen umrissen hat, wird in diesem Abschnitt speziell auf die Umsetzung der Datenerfassung in drei Szenarien aus dem Forschungsvorhaben AKKORD eingegangen (siehe Kap. 1). Dabei kam das industrielle Edge-Gateway ARENDAR des Projektpartners Real-Time-Systems GmbH (RTS) zum Einsatz.
14.2.1 Die Testanlage von PolyMerge
Im Anwendungsfall des Projektpartners PolyMerge (siehe Kap. 12) bestand in einer Pilotanlage das Problem, dass die Daten für die Auswertung in höherer Frequenz aus dem Prozess benötigt wurden, als die integrierte SPS sie bereitstellen kann. Hier wurde versucht, mit einem Switch und einem Profinet Gateway der Klasse 2 an den IO-Link-Master im Prozess anzuknüpfen. Das Edge-Gateway ARENDAR sollte dann über MQTT auf die Daten des Profinet Gateways zugreifen. Es stellte sich in einem Testszenario heraus, dass dieser Weg zur schnelleren Datenerfassung mit den integrierten Komponenten so nicht umsetzbar ist (da der integrierte Master keine „shared devices“ unterstützt, d. h. es sind keine 2 Master im Szenario einsetzbar). Zwei Alternativen wurden recherchiert, leider mit nicht unerheblichem Programmieraufwand sowie hohen Kosten für andere Komponenten (z. B. schnellere SPS). Die Arbeiten resultierten also lediglich in zwei aufwendigeren Lösungsansätzen, eine kostengünstige schnelle Lösung war hier nicht umsetzbar.
In einer anderen Anlage ist die integrierte SPS leistungsfähig genug. Hier werden 15 Werte vom ARENDAR über das Protokoll S7 mit einer Abtastrate von 100 ms aus der SPS ausgelesen. Zudem ist ein zusätzlicher Drucksensor ins Szenario integriert, der direkt mit der IO-Karte des ARENDAR verbunden ist. Alle 15 Werte werden im ARENDAR in einem JSON-Datensatz zusammengefasst und in eine Influx-Datenbank geschrieben. Zudem werden die aktuellen Werte über den Webserver in einer Applikationswebseite angezeigt. Diese Seite ermöglicht auch den Start-Stop der Aufzeichnungen, die Eingabe von Kommentaren in die Datenbank, die Möglichkeit eine Datenbank für die Ablage auszuwählen und die Anzeige von historischen Werten in Line-Charts. Weitere Informationen zu den Daten und zur Auswertung finden sich in Kap. 12.
14.2.2 Der AKKORD-Autorenn-Demonstrator
Eine ausführliche Beschreibung des Demonstrators findet sich in Kap. 17 und Kap. 18. Während Kap. 18 das Datenbackend-Systems den Autorenn-Demonstrator vorstellt und Kap. 17 die modularen Datenanalysen behandelt, werden in diesem Kapitel die Arbeiten zur Erfassung von Daten als Retrofit-Szenario beschrieben.
Es existiert ein Python-Skript des Projektpartners VPE zur Datenerfassung im Demonstrator. Dieses wurde dahingehend erweitert, dass es sich parallel zu mehreren MQTT-Brokern verbinden kann. Somit kann sich der ARENDAR an die bereits in der Bahn implementierte Datenerfassung über MQTT anschließen. Zudem wurden Erweiterungen vorgenommen, die die Berechnung und Erfassung der Sektorzeiten umsetzen (Erzeugung von neuen Informationen aus den Rohdaten). Die Sektorzeiten werden alle 250 ms abgefragt. Limitierende Faktoren für eine schnellere Abtastung war hier ein Overhead des Kommunikationsprotokolls, der eine Kommunikation in Echtzeit an den Server nicht zuließ.
Ein Temperatur- und Umweltsensor zur Erfassung von Temperatur, Luftfeuchte und Luftdruck wurde zur Demonstration von Retrofitting nachgerüstet. Der Umweltsensor wurde mit einem separaten Raspberry Pi verbunden, der die Daten über MQTT an den ARENDAR weiterleitet. Hier wurde eine langsame Abtastrate gewählt, da nicht mit schnellen Veränderungen der erfassten Werte zu rechnen ist. Erfasste und berechnete Werte werden über eine Webseite angezeigt (siehe Abb. 14.1).
Abb. 14.1
Visualisierung erfasster Werte im Autorenn-Demonstrator
×
In diesem Szenario konnte also durch eine Skriptänderung über das leichtgewichtige Protokoll MQTT mit einem Gateway Daten erfasst und verarbeitet werden. Durch einen nachträglich angebrachten Sensor wurden zusätzliche Informationen im Szenario erzeugt, mit den übrigen Daten im Gateway zusammengeführt und über eine Webseite visualisiert.
14.2.3 Die AKKORD Lernstation
Die AKKORD-Lernstation ist vor dem Hintergrund entstanden, Schulen und Ausbildungsbetrieben ein kompaktes, preiswertes Hilfsmittel zum Erlenen von I4.0-Szenarien an die Hand zu geben (Hardt & Klupak, 2022, S. 271 ff.). Der hardwaretechnische Aufbau und eine Abbildung der Station sind im Kap. 19) beschrieben.
Abb. 14.2 zeigt den schematischen Aufbau der Lernstation geordnet nach Szenarien und Kommunikation. Der obere linke Teil (grün hinterlegt), stellt eine alte Anlage ohne Steuerung und Vernetzung dar. Die zugehörige Sensorik ist direkt an die IO-Karte des ARENDAR angeschlossen und soll somit das Retrofitting einer Anlage abbilden. Sechs digitale Eingänge können über die drei Wechselschalter vorne links an der Station angesteuert werden. Die Potenziometer in der Mitte der Station sind über Analogeingänge an den ARENDAR angebunden, sie liefern eine Spannung im Bereich 0–10 V. Die IO-Karte des ARENDAR tastet die Werte mit der Rate 1 kHz ab. Der ARENDAR fragt in einem einstellbaren Zeitintervall die aktuellen Werte ab und kommuniziert diese von der Karte über den I2C-Bus in die Hauptplatine des ARENDAR zur weiteren Verarbeitung.
Abb. 14.2
Schematischer Aufbau der Lernstation
×
Der rechte Bereich der Abb. 14.2 (gelb hinterlegt) zeigt eine moderne Anlage mit Steuerung und zugehöriger Vernetzung. Auch hier stehen drei Schalter vorne rechts an der Station zur Verfügung. Diese sind an die Digitaleingänge der SPS angeschlossen. Die Lichtschranken der beiden im Produktionsbereich befindlichen Motoren sind ebenfalls mit Digitaleingängen der SPS und mit Digitaleingängen des ARENDAR verbunden. Zum Stirlingmotor gehören zwei Temperatursensoren, eine Lichtschranke, eine Heizplatte und ein Lüfter mit Windkanal zur Kühlung des Stirlingmotors. Bei den zwei Temperatursensoren handelt es sich um zwei PT100 Thermoelemente, diese sind über jeweils einen Messumwandler (0–10 V = 0–100 °C) mit der SPS verbunden. Sie dienen zur Regelung des Stirlingmotors. Der Messumwandler des unteren PT100 ist zusätzlich noch auf einen Analogeingang des ARENDAR geführt. Alle in die SPS geführten Daten werden vom ARENDAR über die Schnittstelle LAN2 von der SPS über das Protokoll S7 eingelesen. Standardmäßig findet die Abfrage alle 100 Millisekunden statt, ist aber auf andere Werte konfigurierbar.
Über die digitalen Ausgänge der SPS lassen sich die Kontrollleuchten, zwei Relais und das Motorsteuerboard ansteuern. Mit Hilfe eines Relais wird eine Heizung geschaltet, die als Wärmequelle für den Stirlingmotor dient, mit einem weiteren Relais wird der Lüfter des Stirlingmotors geschaltet.
Der Bereich rechts unten in Abb. 14.2 (blauer Bereich) steht für die im Kofferboden integrierte Office-IT einer Firma. Diese ist über die LAN1-Schnittstelle mit dem ARENDAR verbunden und die Kommunikation ist z. B. über MQTT oder OPC-UA möglich. Die Office-IT ermöglicht Zugang zum Internet und damit verbundene Möglichkeiten wie Zugang zu Cloud-Services (AWS, Telekom-IoT, Azure IoT) und Darstellung von Werten über den integrierten Webserver. Durch die zwei getrennten LAN-Anschlüsse des ARENDARS ist eine Netzwerksegmentierung zwischen IT und OT gegeben, sodass die Komponenten der OT nicht den Gefahren des Internets ausgesetzt sind.
14.3 Fazit
Die Prozessdatenerfassung ist ein komplexes Thema. Technische Herausforderungen, Lösungsansätze und beispielhafte Umsetzungen wurden hier beschrieben. Daneben ist der Schutz der OT vor Angriffen von außen (Attacken, Spionage) ein weiteres großes Feld, das hier zu Anfang nur erwähnt wurde. Gateways stellen ein mächtiges Werkzeug bei der Datenerfassung dar. RTS konnte durch das Projekt AKKORD wichtige Erkenntnisse bezüglich der Weiterentwicklung des Gateways ARENDAR sowie auch Grenzen bei der Datenerfassung sammeln. Diese werden in die Weiterentwicklung des Produkts in den Bereichen Datenbankanbindung, Datenvisualisierung, Konnektivität und Nutzerfreundlichkeit einfließen.
Für einen umfassenderen Blick auf die derzeit stattfindende Entwicklung industrieller Datenanalysen im Zusammenhang mit Mensch, Technik und Organisation, verweisen wir abschließend auf Kap. 20.
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
