<<< Previous topic - Next topic >>> |
|
Author |
Message |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 24.03.2016, 16:08 Post subject: Predictive Maintenance ... |
|
|
Hallo Forum.
Auf der Hannover-Messe 2016 zeigen wir als Thinglyfied-Live-Demo Predictive Maintenance für ein pneumatisches Subsystem.
Eine wichtige Voraussetzung für Predictive Maintenance ist ein Condition Monitoring mit Cloud-basierter Datenspeicherung. Dazu sollten möglichst viele Datenpunkte in einer Antriebsbaugruppe oder Maschine erfasst werden. Teilweise sind dafür zusätzliche Sensoren notwendig. Die anfallenden Daten werden in regelmäßigen Abständen an die Cloud übermittelt. Aus der gesamten Historie entsteht dann später auch ein Vorhersagemodell für Predictive Maintenance-Anwendungen.
Ebenfalls sehr wichtig ist die Qualität der Condition Monitoring-Daten. Bei einem pneumatischen Subsystem, z. B. einem Führungszylinder mit einem Druckluft-bewegten und SPS-gesteuerten Schlitten zum Materialtransport, lässt sich durch das Condition Monitoring der Stoßdämpfer an beiden Führungszylinderenden und den damit möglichen Service- und Wartungskonzepten die Lebensdauer der gesamten Baugruppe erheblich steigern. Im einfachsten Fall befindet sich an den Endpunkten des Führungszylinders jeweils ein Näherungssensor mit einem Schaltpunkt, um der SPS die Position des Schlittens anzuzeigen. Will man nun die Wirkung der Stoßdämpfer messen, könnten zusätzlich oder alternativ spezielle Näherungssensoren mit zwei Schaltkontakten verwendet werden, die eine Zeitmessung für die Schlittenbewegung innerhalb der Stoßdämpfer-Hubstrecke zulassen.
Mit anderen Worten: Für die Stoßdämpfer an beiden Enden entstehen jeweils zwei für das Condition Monitoring relevante Zeitmessungen (Anfang der Hubstrecke, Ende der Hubstecke). Zusammen mit der Schlittengeschwindigkeit lässt sich daraus eine Kennzahl ermitteln. Diese wird sich bei längerer Betriebsdauer und damit einhergehenden nachlassendem Stoßdämpferöldruck verändern. Um nun eine vorausschauende Wartung (Predictive Maintenance) für den Führungszylinder zu ermöglichen, wird die Kennzahl zusammen mit anderen aus der SPS ausgelesenen Daten (z. B. wie oft wurde ein Ventil oder eine Hydraulikeinheit benutzt) in bestimmten Zeitabständen an eine Cloud übertragen und dort gespeichert.
Gruß KDW
P.S.: Siehe auch www.ssv-embedded.de/doks/pm/pm_ssv_thinglyfied_predictive.pdf
Last edited by kdw on 10.04.2016, 12:44; edited 1 time in total |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 10.04.2016, 09:23 Post subject: SPS und Datenschnittstelle … |
|
|
Hallo Forum.
Das pneumatische Subsystem der Thinglyfied-Live-Demo Predictive Maintenance wird von einer Siemens S7-1200 SPS angesteuert. Dafür werden an der SPS zwei Ausgänge und vier Eingänge genutzt. Die folgende Abbildung zeigt die Zusammenhänge:
Zwei SPS-Ausgänge schalten die beiden Ventile zur Druckluftzufuhr, um den Schlitten auf dem Führungszylinder jeweils von rechts nach links bzw. links nach rechts zu bewegen.
Je zwei SPS-Eingänge sind mit den Schaltkontakten der beiden Näherungsschalter an den Endpunkten des Führungszylinders verbunden. Damit lassen sich insgesamt vier Schlittenpositionen bestimmen:
X1: Linker Schlittenrand am Ende der Stoßdämpfer-Hubstrecke
X2: Linker Schlittenrand am Anfang der Stoßdämpfer-Hubstrecke
X3: Rechter Schlittenrand am Anfang der Stoßdämpfer-Hubstrecke
X4: Rechter Schlittenrand am Ende der Stoßdämpfer-Hubstrecke
Die kritischen Komponenten des pneumatischen Subsystems in der Thinglyfied-Live-Demo sind die Stoßdämpfer an den beiden Enden. In den Datenblättern dieser Bauteile findet man zwar Angaben zu Werkstoff, Temperaturbereich, Auffahrgeschwindigkeit, Festanschlagsposition, max. Energieaufnahme pro Hub, max. Energieaufnahme pro Stunde usw., hingegen keine Daten zur Bestimmung der Lebensdauer. Reicht die Dämpfung allerdings nicht mehr aus, kann es am gesamten Subsystem zu irreparablen Schäden kommen (=> durch einen defekten Stoßdämpfer fährt der Schlitten ungebremst an den Anschlag des Führungszylinders).
Die genaue Messung der Schlittengeschwindigkeit für die Wegstrecken X2-X1 (Zeitspanne t1) und X3-X4 (Zeitspanne t2) lässt Rückschlüsse auf die Stoßdämpfer-Wirksamkeit zu. Die einzelnen Messwerte für t1 und t2 haben in der Regel allerdings keine nennenswerte Aussagekraft. Hilfreich ist hingegen die permanente Aufzeichnung der Messwerte in einer Datenbank (z. B. durch einem SPS- oder Prozess-Datenlogger), um im Rahmen eines Condition Monitorings den Trend in der Messwertveränderung über einen längeren Zeitraum zu bewerten.
Das Berechnen der Schlittengeschwindigkeit bzw. der Zeitspannen t1 und t2 erfolgt in einem IGW/936 per Node-RED (siehe Thinglyfied „Things Config WebUI“ = TCW). Dafür sind die S7-1200 und das IGW/936 per Ethernet-LAN direkt miteinander verbunden. Über diese Schnittstelle kommt das ISO-on-TCP-Protokoll (RFC1006-Protokoll) zum Einsatz, um dem IGW/936 den Zugriff auf die Ein- und Ausgänge der S7-1200 zu ermöglichen, die die SPS mit den Ventilen und Schaltkontakten des pneumatischen Subsystems verbinden.
Die errechneten Zeitspannen für t1 und t2 werden vom IGW/936 als Condition Monitoring-Daten an einen Cloud-Service weitergebenen und dort gespeichert (SPS-Datenlogger in der Cloud). Hierfür kommt das RTDC-MQTT-API zum Einsatz. Auf Grund der Datenmenge, die alleine für t1 und t2 bei normalen Betrieb anfallen kann, werden die Daten vor der Weitergabe an die Cloud im IGW/936 vorverarbeitet, zum Beispiel durch eine geeignete Mittelwertbildung für t1 und t2 über eine bestimmte Zeitspanne. Dadurch werden beispielsweise pro Stunde lediglich zwei t1/t2-Messungen in der Cloud gespeichert, obwohl in dieser Zeitspanne max. einige tausend Messwerte anfallen können.
Gruß KDW
P.S. - Sicherheitshinweis: Der Zugriff auf eine S7-SPS per RFC1006-Protokoll ist aus IT-Security-Sicht sehr kritisch, da über eine solche Verbindung auf nahezu alle SPS-Funktionen zugegriffen werden kann. Aus diesem Grund sollten in die LAN-Verbindung zwischen S7 und IGW/936 keine weiteren Teilnehmer eingebunden werden. RFC1006 basiert S7-seitig auf einer völlig offenen TCP/IP-Schnittstelle, auf die über den TCP-Port 102 zugegriffen werden kann. Aus diesem Grund sollte die Firewall-Funktionalität des IGW/936 genutzt werden, um weiteren Systemen nur über die IGW/936-Firewall den RFC1006-basierten Zugriff auf die S7-SPS zu ermöglichen. |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 15.04.2016, 15:00 Post subject: Berechnungen … |
|
|
Hallo Forum.
Sowohl vor Ort im IGW/936 als auch in der Cloud finden verschiedene Berechnungen statt. Die aus der S7-1200 gewonnenen Daten dienen dabei als Input. Über die errechneten Daten lässt sich in einem Dash Board eine ausführliche Ansicht zur „Condition“ des pneumatischen Subsystems darstellen. Die in der Cloud gespeicherten bzw. errechneten Condition Monitoring-Daten lassen sich per Webbrowser im Dash Board betrachten.
In der Cloud wurden zusätzliche Daten zu verschiedenen Komponenten im Rahmen eines Anlagen-Engineerings gespeichert. So wurden beispielsweise die max. Nutzungswerte für die Stoßdämpfer (Shock absorber) bestimmt und in der virtuellen Repräsentanz des pneumatischen Subsystems als Variable hinterlegt. Gleiches gilt für die maximale Laufleistung des Schlittens (Barrel mileage), die max. Anzahl der Ventilbetätigungen (Valve usage) usw. Durch das Zählen der Stoßdämpferaktivitäten lässt sich dann im Usage Indicator des Dash Boards darstellen, wie lange der Stoßdämpfer noch halten wird und wann ein Servicemitarbeiter diesen austauschen sollte, um einen Anlagenstillstand zu vermeiden.
Da vom IGW/936 aus auch auf die beiden S7-Ausgänge zugegriffen werden kann, mit denen die Ventile zur Druckluftzufuhr des Schlittens angesteuert werden, lässt sich die Lebensdauer der Ventile in das Condition Monitoring einbeziehen.
Alle in der Cloud gespeicherten Daten sind über RTDC-APIs für andere Anwendungen (z. B. einem Predictive Maintenance Service in einer SaaS-Cloud) zugänglich. Um ein RTDC-API zu nutzen, ist ein entsprechender API-KEY erforderlich. Siehe hierzu auch http://www.ssv-comm.de/forum/viewforum.php?f=42
Gruß KDW
Hinweis: Die Abbildungen zu diesem Beitrag basieren auf realen Baugruppendaten. Da sich das pneumatische Subsystem aber im Hause SSV befindet und nur sporadisch in Betrieb ist, ergeben sich unrealistische Restlaufzeiten für die einzelne Komponenten – z. B. die noch möglichen Betriebsstunden für Stoßdämpfer und Ventile. |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 16.04.2016, 10:19 Post subject: Zusätzliche Sensoren … |
|
|
Hallo Forum.
Der reale Praxiseinsatz einer Predictive Maintenance-Lösung für vergleichbare pneumatische Subsysteme erfordert zusätzliche Sensoren, die in unserer Messe-Demo fehlen. So lässt sich z. B. mit Hilfe eines Drucksensors ermitteln, ob das pneumatische Subsystem mit einem Überdruck betrieben wird. In diesem Fall bewegt sich der Schlitten mit einer höheren Geschwindigkeit, was zu einer besseren Anlagen-Performance führen kann. Auf der anderen Seite reduzieren sich dadurch die Laufleistung des Schlittens und die Lebensdauer der Stoßdämpfer (der Stoßdämpfer muss bei jedem Anschlag eine größere Energiemenge absorbieren).
Durch zusätzliche Temperatursensoren kann darüber hinaus die jeweilige Umgebungstemperatur und die aktuelle Betriebstemperatur der Stoßdämpfer einbezogen werden usw. Da Stoßdämpfer die mechanische Energie in Wärme umwandeln, lässt sich auch hier ein Erkenntnisgewinn sowohl für das Condition Monitoring als auch die Predictive Maintenance erreichen.
Da Druck-und Temperatursensoren in der Regel analoge Ausgangsgrößen liefern, benötigt das IGW/936 in der Messe-Demo eine Erweiterungsbaugruppe. Diese muss die analogen Sensorsignale digitalisieren und über ein geeignetes Protokoll für den IGW/936-Zugriff zur Verfügung stellen. Hierfür eignet sich die I/O-Erweiterung IO/5640 (siehe auch http://www.ssv-comm.de/forum/viewtopic.php?t=1313). Sie bietet u.a. vier analoge Eingänge (0 – 10 V, 4 – 20 mA, umschaltbar) und einen integrierten Modbus-RTU-Slave. Auf diesen kann vom IGW/936 aus per Node-RED zugegriffen werden, um die Sensordaten zu lesen.
Gruß KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 16.04.2016, 12:35 Post subject: MES-Anbindungen … |
|
|
Hallo Forum.
Die Darstellung eines Valve Usage Indicators in einem Dash Board wird in der Praxis nur einen rein informativen Mehrwert bieten. Die in der Informationskachel enthaltenen Angaben zur bisherigen Nutzung, den möglichen Restlaufzeiten usw. sind nur dann von nutzen, wenn sie ein Serviceverantwortlicher wahrnimmt und die erforderlichen vorbeugenden Instandhaltungsmaßnahmen in die Wege leitet. Das ist bei einem Dash Board nicht sicher garantiert.
Um die Anlagenverfügbarkeit zu optimieren und die Wartungstermine so zu platzieren, dass der normale Produktionsbetrieb nicht oder nur minimal beeinträchtigt wird, sollten die Daten eines pneumatischen Subsystems direkt in ein MES (Manufacturing Execution System) integriert werden. Dafür können beispielsweise das SSV-RTDC-API genutzt werden. Siehe hierzu auch http://www.ssv-comm.de/forum/viewforum.php?f=42.
Gruß KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 14.08.2016, 10:01 Post subject: Schnelle Zeitmessungen … |
|
|
Hallo Forum.
Bei der Übertragung der Thinglyfied-Demo Predictive Maintenance in erste praktische Anwendungen mit Kundenanlagen hat sich inzwischen herausgestellt, dass die Messungen der Zeitspannen t1 (Schlitten-Wegstrecke X2-X1) und t2 (Schlitten-Wegstrecke X3-X4) nicht ganz einfach ist.
Zur Bewertung des Stoßdämpferzustands benötigen wir für t1 und t2 eine Zeitauflösung von einer Millisekunde. In der Thinglyfied-Demo berechnen wir diese Zeiten im IGW/936 mit der erforderlichen Genauigkeit aus Zeitstempeln der S7-1200, die jeweils bei Eingangssignalveränderungen durch die beiden Näherungssensoren erzeugt werden.
In einer Kundenanlage haben wir in der Regel keine S7-1200, sondern eine Steuerung, die dem IGW/936 weder Zeitstempel noch sonst irgendwelche Hilfestellung bei der Millisekunden-genauen Zeitmessung für t1 und t2 liefern kann.
Wir werden daher die Funktionen unserer I/O-Baugruppe IO/5640 (siehe auch http://www.ssv-comm.de/forum/viewtopic.php?t=1313) um schnelle 16-Bit-Zeitmessregister erweitern, die mit einer Millisekunde Auslösung x-beliebige Zeitspannen messen können. Über einen digitalen IO/5640-Eingang wird bei einem 0/1-Übergang jeweils eine Zeitmessung gestartet, ein weiterer Eingang stoppt die Zeitmessung beim 0/1-Übergang wieder. Der Näherungssensor-Eingang X2 kann dann z. B. jeweils eine Zeitmessung starten, der Eingang X1 stoppt die gleiche Zeitmessung wieder usw. Ausgelesen werden die Zeitmessregister vom IGW/936 per Modbus-RTU.
Gruß KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 13.11.2017, 12:25 Post subject: Informationen aus Maschinendaten ... |
|
|
Hallo Forum.
Aus den Daten, die mit der hier beschriebenen Lösung beispielhaft gewonnen werden, lassen sich wertvolle Informationen für die unterschiedlichen Interessengruppen in einer Wertschöpfungskette gewinnen. Siehe hierzu auch den Aufsatz "Wissen ist Macht" in der IoT Design:
https://ssv-comm.de/forum/dokumente/FB_Wissen_ist_Macht_1117.pdf
VG KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 06.03.2018, 12:48 Post subject: Edge oder Cloud? |
|
|
Hallo Forum.
Im Zusammenhang mit dem Predictive-Maintenance-Thema kommt immer mal wieder die Frage auf, wo genau eine Datenanalyse erfolgen soll: Auf einem Edge-Gateway oder in der Cloud?
Die Entscheidung zwischen den beiden Optionen hängt von verschiedenen Parametern bzw. Voraussetzungen ab. Man muss daher für jeden Anwendungsfall zunächst einmal folgende Detailfragen klären:
Dürfen die Daten überhaupt in die Cloud oder gibt es Firmen- bzw. Datenschutzvorgaben, die dagegen sprechen?
Lässt sich die jeweilige Menge an Maschinen- und Anlagendaten überhaupt ökonomisch sinnvoll an eine Cloud übermitteln (die Nutzung einer Cloud ist z. T. nicht gerade günstig, daher Capex ./. Opex für den jeweiligen Anwendungsfall abgleichen)?
Gibt es Echtzeitvorgaben, die gegen eine Datenanalyse in der Cloud sprechen?
Im einen oder anderen Fall ist auch ein Mix (ein Teil der Datenanalyse erfolgt „@theEdge“, ein anderer Teil in der Cloud) die beste Lösung. Um zum Beispiel in einem pneumatischen System schnelle Ereignisse wie schlagartigen Entlüftungen oder Druckspitzen sicher zu erkennen, kommt eigentlich nur „@theEdge“ in Frage. Hierfür lassen sich zum Beispiel die Application-specific Code Functions (ACF) der IO/5640 nutzen. Zur Langzeitdatenaufzeichnung, um auch Trends in der Visualisierung darzustellen, wäre dann wieder die Cloud die besser geeignete Plattform.
VG KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 18.03.2018, 08:40 Post subject: Predictive Maintenance II ... |
|
|
Hallo Forum.
Zurzeit ergänzen wir unsere Predictive Maintenance-Lösungen durch weitere statistische Methoden zur Datenauswertung und Machine Learning. Auf der Hannover Messe 2018 gibt es mehr zu sehen: Siehe https://ssv-comm.de/forum/viewtopic.php?t=1429
VG KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
kdw
![](images/avatars/10.png)
Joined: 05 May 2006 Posts: 1460
|
Posted: 15.02.2020, 21:55 Post subject: Remote Maintenance Gateway (RMG) ... |
|
|
Hallo Forum.
Unsere Predictive-Maintenance-Aktivitäten gehören inzwischen zu der RMG-Produktfamilie. Siehe z. B. "embedded Machine Learning (eML)" des RMG/941 unter:
https://ssv-comm.de/forum/viewforum.php?f=48
Die hier beschriebene Aufgabenstellung würden wir aktuell per Supervised Machine Learning lösen. Die dafür erforderlichen Algorithmen können wir sowohl direkt auf dem Gateway (@Edge) oder in der Cloud (@Cloud) ausführen. Auch Kombinationen sind möglich: Zum Beispiel: Sensordaten mit dem Gateway erfassen, an eine IoT-Cloud übertragen und dort das Modell bauen. Das Modell dann zurück auf das RMG übertragen und dort den Datenstream in Echtzeit analysieren.
VG KDW |
|
Back to top |
|
![](templates/ssv_2016/images/spacer.gif) |
|