Tulip’s frontline operations platform supports native machine connectivity, bringing your machine data in context with data from people, devices, and systems. Machine state changes can be monitored through networked connections or with sensors and our edge devices.

In this post, we will explore how our team retrofit a legacy machine, connected it to the cloud, and estimated its state using a simple ML model and Edge IO. At our Somerville headquarters, we have an espresso machine and a water dispenser that were perfect candidates for measuring utilization.

If this sounds familiar, we “launched” a new product on April Fools day from this experiment →

Keeping it as simple as possible, we connected a current and vibration sensor using an Edge IO and PhidgetHub sensor. For the espresso machine, we ran an ML model that detects whether the machine is running, idle, or stopped. This allows us to monitor the usage of the machine and potentially optimize its maintenance and performance.

Read on as we cover the required hardware and software components, as well as the steps to set up and run the machine learning model.

Einrichten der Hardware

Um die Kaffeemaschine zu überwachen, haben wir einen handelsüblichen Stromsensor an einen Edge IO angeschlossen. Außerdem haben wir einen Piezo-Vibrationssensor hinzugefügt, um Hochgeschwindigkeitsvibrationen zu überwachen. Der Edge IO unterstützt die Hochgeschwindigkeitsüberwachung durch seine integrierten ADC-Eingänge.

Wir haben uns dafür entschieden, einen PhidgetHub an den Edge IO für den Stromsensor anzuschließen, um die analogen Signale des Sensors in den Edge IO zu konvertieren.

https://tulip.widen.net/content/fabniydivf
Edge IO über USB mit einem PhidgetsHub verkabelt, der über ein Verlängerungskabel mit einer Stromzange verbunden ist. Ein VIbrations-Sensor ist mit Klebstoff befestigt.
https://tulip.widen.net/content/z9tpdodsrd

Um die vom PhidgetHub kommenden Daten in Tulip zu sammeln, verwenden wir die Standard Phidgets Node-RED Knoten für VoltageInput. Der PhidgetHub der Espressomaschine ist direkt mit dem Edge IO verbunden, während der PhidgetHub des Wasserspenders über WiFi mit demselben Gerät verbunden ist, so dass wir die Nutzung beider Geräte mit einem einzigen Edge-Gerät verfolgen können.

https://tulip.widen.net/content/pfttfcio2v

Sammeln und Verarbeiten von Daten

Um die Daten von Edge IO in die Cloud zu übertragen, haben wir den Onboard Tulip Table Node-RED Node verwendet. Mit diesem Knoten können Daten vom Edge-Gerät zu einer Tabelle in Tulip hinzugefügt werden. Wir haben jeden Datensatz so konfiguriert, dass er einen Zeitstempel, einen Namen und einen Zahlenwert vom Sensor speichert, und haben die Daten von allen Sensoren in einer einzigen Tabelle gesammelt.

https://tulip.widen.net/content/de4qsnquvv

Sobald sich die Daten in einer Tabelle befanden, haben wir sie in eine CSV-Datei exportiert, um die Daten mit Pandas zu laden und mit der Visualisierung der Daten und der Erstellung unseres machine learning Modells zu beginnen.

https://tulip.widen.net/content/ednrgrzrv6

Zunächst haben wir die Daten der Sensoren der Espressomaschine sortiert und schnell die drei Zustände der Maschine identifiziert:

  • Aus

  • Leerlauf/Standby

  • Laufen/Kaffee kochen

Unsere erste Beobachtung war recht interessant, als wir feststellten, wie viel Strom die Maschine im Leerlauf verbraucht. Alle 30 Sekunden gibt es eine kurze Spitze, die wieder auf Null abfällt. Wir haben festgestellt, dass dies mit dem Heizelement zusammenhängt, das die Kaffeemaschine auf einer angemessenen Temperatur hält.

Bei der Modellierung der Staaten waren unsere Hauptziele:

  • Wir möchten vermeiden, dass wir umfangreiche Daten beschriften müssen.

  • Eine Kaffeemaschine hat eine endliche Anzahl von Dingen zu tun: Bohnen mahlen, erhitzen, einen Schuss ziehen, Milchschaum herstellen. Aus diesem Grund sehen unsere Sensordaten für jeden Arbeitsschritt anders aus, was es uns ermöglichen sollte, generische Merkmale in unseren Daten zu finden, die es uns erlauben, diese Teile des Programms in separate Zustände zu gliedern.

  • Diese Zustände können dann von einem Bediener mit Hilfe von standardmäßigen Tulip Maschinenauslösern auf Stoppen/Laufen/Leerlauf gesetzt werden.

Um diesen Prozess zu starten, haben wir einen gleitenden Durchschnitt berechnet, um die von uns identifizierten Erhitzungszyklen zu glätten. Aufgrund der Länge der Zyklen haben wir einen gleitenden Durchschnitt von 1 Minute gewählt. Die Aufheizzyklen dieser Maschine dauern in der Regel etwa 30 Sekunden, und der gesamte Kaffeezyklus dauert etwa 2-3 Minuten, je nach der Temperatur der Maschine zu Beginn des Einschaltens.

Zusätzlich haben wir verzögerte Merkmale einbezogen: gleitender Durchschnitt von vor einer und zwei Minuten. Dies ist eine Standardmethode in der Zeitreihenanalyse, die es dem Modell ermöglicht, steigende oder fallende Muster in den Daten zu erkennen.

Erstellung des machine learning Modells

Für das Clustering-Modell wollten wir ein Modell mit möglichst wenigen Parametern und einer integrierten Methode zur Schätzung der "richtigen" Anzahl von Clustern. Wir entschieden uns für ein Bayes'sches Gauß'sches Mischmodell.

Dies half uns bei der Einschätzung, dass die Dimensionalität der Sensordaten unserer Kaffeemaschine proportional zu den 6 verschiedenen Arbeitsschritten (Ausschalten, Bohnen mahlen, Erhitzen, Ziehen eines Schusses, Milchschaum herstellen, manuelle Handhabung) ist. Daher haben wir 6 für die Anzahl der separaten Komponenten im Clustermodell gewählt.

Da es sich um ein unbeaufsichtigtes Modell handelt, haben wir einen Tag lang Daten gesammelt, die dann zum Trainieren des Modells verwendet wurden. Die Validierung erfolgte visuell - wir überprüften, ob die Cluster, die das Modell erkannte, mit dem Zustand übereinstimmten, der aus den Sensordaten ersichtlich war.

https://tulip.widen.net/content/exx8gnf2wj

Aus diesen Diagrammen können wir ersehen, dass Status 1 Aus ist, 4,5 Leerlauf und 0,2,3 anscheinend verschiedene Stadien der Kaffeezubereitung sind (Mahlen, Ziehen eines Schusses und Milchschaum machen/abkühlen).

Einsatz des Modells und Erstellung einer Tulip App

Nachdem wir unser Clustering-Modell machine learning erstellt und getestet hatten, war es an der Zeit, das Modell zur Verwendung bereitzustellen. Wir haben das Modell mit MLflow wie folgt in S3 gespeichert: mlflow.sklearn.save_model(s3://bucket_name/registry_prefix/model_name/version).

Für die Ausführung des Modells haben wir uns für ein AWS-Gateway und eine AWS Lambda-Funktion entschieden, um das Modell im MLflow-Format aus S3 zu holen. Der Endpunkt war gateway-address.com/inference/{model_name}, wobei die Daten aus dem gleitenden Durchschnitt zeitverzögerter Merkmale bestehen.

Um das Modell bei neu eingehenden Daten auszuführen, hatten wir zwei Möglichkeiten: einen HTTP-Connector einzurichten und ihn innerhalb eines Tulip App auszuführen, was voraussetzen würde, dass die App jederzeit auf einem Gerät läuft, oder einen HTTP-Post von Node-RED aus auszuführen und die Cluster-ID als Attribut des Zustandsautomaten mit den Standardknoten Tulip Node-RED zu posten. Wir haben uns für die letztere Option entschieden und das Modell erfolgreich zur Nutzung bereitgestellt.

Der Node-RED Ablauf zur Berechnung der Merkmalsdaten und Ausführung des Modells sieht wie folgt aus:

https://tulip.widen.net/content/3myllvffs1
Der obige Ablauf ist derselbe für Vibrations- und Stromsensoren. Die Sensordaten werden alle in einen Join-Knoten eingespeist.
https://tulip.widen.net/content/qlsgtjkcs3
Der Knotenpunkt Join:
https://tulip.widen.net/content/hps2qttbmq
Der Join-Knoten weist das verknüpfte Objekt msg.value zu. timestamp, name und value müssen entfernt werden, um dem erwarteten Datenformat für die Modellinferenz zu entsprechen.
https://tulip.widen.net/content/ifginqbiux
Bei der Erstellung der Maschine und der erforderlichen Attribute haben wir der Einfachheit halber nur Merkmale ohne Zeitverzögerung als Attribute hinzugefügt, da die anderen Merkmale nur in Node-RED
https://tulip.widen.net/content/oakpcpzd6y
Wir prüfen dann, wie das aktuelle Maschinenattribut "Status" lautet und schalten den Maschinenstatus in einem Tulip Maschinenauslöser um. Die Maschinenauslöser für das Setzen des Zustands auf Leerlauf/Aus werden ähnlich konfiguriert, allerdings mit den unterschiedlichen Zustandswerten.
https://tulip.widen.net/content/tnbl8cjcus

Jetzt ist die Maschine vollständig eingerichtet und Tulip sammelt die Daten mit unserem Modell, damit wir berechnen können, wie viele Kaffees pro Tag produziert werden und wie viel Zeit die Maschine im Betrieb, im Leerlauf oder im ausgeschalteten Zustand verbringt.

https://tulip.widen.net/content/jn3tdttmnc

Wie Sie oben sehen können, war das Modell noch nicht ganz ausgereift. Deshalb haben wir Tulip Player auf einem iPad neben der Espressomaschine eingerichtet, auf dem eine Tulip App läuft, mit der die Benutzer Feedback zur Genauigkeit des Modells geben können. Außerdem erinnert die App die Benutzer daran, die Maschine nach der Zubereitung auszuschalten, um Energie zu sparen.

https://tulip.widen.net/content/ezmykdeyki

Mit den Daten aus dem Modell können wir dann Dashboards erstellen, um unsere Ergebnisse und die Nutzung anzuzeigen:

https://tulip.widen.net/content/bzimlph3kh

Außerdem haben wir einige der Rohdaten analysiert, um den Stromverbrauch pro Zustand für einen normalen Arbeitstag zu berechnen. Wir haben festgestellt, dass die Espressomaschine 80 % des Stroms (was in etwa dem Energieverbrauch entspricht) im Leerlauf verbraucht und nur 20 % des Stroms für die Zubereitung von Kaffee verwendet wird. Da es sich um eine kleine Maschine in einer nicht-industriellen Umgebung handelt, ist die Verschwendung nicht besonders groß.

In der Produktion kann es jedoch viele Situationen geben, in denen durch Maschinen im Leerlauf eine große Menge an Energie verschwendet wird. Die Überwachung der Maschinenauslastung kann entscheidend dazu beitragen, dass Sie auf Zustandsänderungen aufmerksam gemacht werden und schneller auf eine Maschine im Leerlauf reagieren können, was Ihrem Team Zeit spart und die Energieverschwendung reduziert.

Fazit

Um diesen Beitrag zusammenzufassen, haben wir untersucht, wie man ältere Maschinen nachrüsten und mit der Cloud verbinden kann, um ihre Verfügbarkeit mithilfe eines einfachen ML-Modells abzuschätzen.

Wir haben eine Espressomaschine in unserem Büro in Somerville, Massachusetts, verwendet. Wir haben die erforderlichen Hardware- und Softwarekomponenten sowie die Schritte zum Einrichten und Ausführen des ML-Modells behandelt. Das Modell verwendete ein Bayes'sches Gaußsches Mischungsmodell für das Clustering (mit gleitenden Durchschnitten und verzögerten Merkmalen) und wurde auf einem Edge IO berechnet und ausgeführt.

Eine App für Kaffeemaschinen in unserem Büro bietet eine Schnittstelle, über die Sie eine Rückmeldung erhalten, wenn das Modell nicht erkannt hat, dass ein Kaffee zubereitet wird oder zu langsam reagiert hat.

Außerdem ein dashboard , das die Kaffeezubereitung im Tulip HQ kontinuierlich überwacht. Wir haben den Gesamtstromverbrauch der Kaffeemaschine für jeden Zustand geschätzt und festgestellt, dass nur 20% für die Kaffeezubereitung verwendet werden, der Rest wird im Leerlauf verbraucht!

Dieses Experiment gehört zu einer Reihe von Experimenten, die wir im Zusammenhang mit der Zustandserkennung für Maschinenüberwachung durchgeführt haben. Dazu gehört auch ein Experiment, das wir bei der Erstellung von Edge IO im Autodesk Technology Centers, Boston, durchgeführt haben. Wir haben weiterhin Modelle zur Zustandserkennung an CNC-Maschinen, die von Herstellern verwendet werden, sowie an anderen Haushaltsgeräten und Anlagen wie einer Waschmaschine untersucht. Für jedes Gerät müssen die Komponenten des Modells und die gleitenden Durchschnitte ein wenig angepasst werden, aber wir erkennen weiterhin Zustände über verschiedene Zyklen hinweg.

Diese Arbeit trägt nun Früchte und wir freuen uns, Ihnen im Laufe dieses Jahres einige neue Angebote von Tulip vorstellen zu können.