Kommentar von Dmitry Baykov, DataArt ML in Höchstgeschwindigkeit – prädiktives Wartungssystem in vier Monaten

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Sinequa

Fivetran Germany GmbH

DataArt

Unser Team machte sich an die ehrgeizige Aufgabe, eine Plattform für die vorausschauende Wartung zu entwickeln, um Ausfälle und Störungen von Anlagen vorherzusagen. Dieses Projekt brachte IoT und maschinelles Lernen (ML) zusammen und integrierte sowohl Software- als auch Hardwarekomponenten. In diesem Artikel erörtern wir die Herausforderungen, auf die wir beim Aufbau eines serverlosen ML-Systems mit Scikit-learn auf AWS gestoßen sind, und die zeitsparenden Strategien, die wir eingesetzt haben.

Das große Sortierzentrum des Kunden mit Förderbändern, Sensoren und Robotern riskierte einen Stillstand aufgrund eines möglichen Komponentenausfalls. Dieser Ausfall könnte bis zu 1,5 Millionen US-Dollar pro Stunde kosten.

SPS und Sensoren

Unser anfänglicher Prototyp verfügte über etwa 90 Sensoren, aber eine Vergrößerung erforderte fast 550 Sensoren für nur einen kleinen Teil des Sortierzentrums des Kunden.

Wir setzten speicherprogrammierbare Steuerungen (SPS) ein, um Prozesse zu automatisieren und Daten von verschiedenen Sensormodellen zu sammeln, darunter auch Ultraschallsensoren. Diese Sensoren maßen Parameter wie Beschleunigung, Geschwindigkeit, Spannungspegel, Vibration und Temperatur, insgesamt 17 verschiedene Indikatoren.

Erste Phase: Anbringen von Sensoren, Sammeln von Daten

Unser Datenerfassungssystem umfasste ein Gateway, eine SPS und daran angeschlossene Sensoren. Um potenzielle Risiken im Zusammenhang mit Unterbrechungen des mobilen Internets zu minimieren, implementierten wir ein Caching auf dem Gateway.

Wir haben uns für Athena als Datenbanklösung entschieden, weil die zukünftigen Benutzer des Systems dessen Funktionen gegenüber DynamoDb bevorzugten. Athena eignet sich besser für die Abfrage von Daten für maschinelles Lernen, Analysen und das Lesen/Schreiben von Parquet- und CSV-Daten.

Zweite Phase: Was haben wir analysiert?

In der zweiten Phase analysierten wir drei Gigabyte an Rohdaten, wobei wir uns auf die Temperatur-, Vibrations- und Axialbeschleunigungsmessungen der Motoren konzentrierten.

In nur vier Monaten brachten wir die erste Softwareversion heraus, indem wir diese zeit- und kostensparenden Ansätze nutzten:

• 1. Nutzung der Amazon Web Services (AWS) Cloud zum Hosten und automatischen Skalieren unseres Systems bei steigenden Benutzerzahlen.

• 2. Sicherung der Daten mit der standardmäßigen AWS-Verschlüsselung.

• 3. Verwendung einer ereignisgesteuerten Architektur, um den Echtzeitbetrieb des Systems zu ermöglichen.

• 4. Verwaltung großer Datenmengen durch die Erstellung von Backup-Pipelines und spätere Umstellung auf die Speicherung von Rohdaten im reinen Lesemodus, um die Kosten zu senken.

• 5. Erzielung einer hohen Erkennungsgenauigkeit mit einem benutzerdefinierten neuronalen Netzwerkmodell auf Keras und TensorFlow nach dem anfänglichen Einsatz von vorgefertigten Containern auf SageMaker.

• 6. Implementierung der kontinuierlichen Integration und Bereitstellung, die es uns ermöglicht, das System mit verschiedenen AWS-Services zu erweitern und diese während der Build- und Bereitstellungsphasen automatisch zu verwalten.

Projektdetails

Unsere Arbeit basierte in den ersten Monaten auf grundlegenden mathematischen Prinzipien und statistischen Ansätzen, bis wir neuronale Netze einsetzten. Wir überwachten Metriken, wie die Durchschnittstemperatur, und implementierten einfache Warnsysteme zur Erkennung von Anomalien.

Wir sammelten, verarbeiteten und bereinigten die Daten und bereiteten so die Erstellung eines Modells vor.

Wir verwendeten S3-Buckets, um Ereignisse zu starten und „Partitionen“ zu erstellen, um die Kosten für Athena-Abfragen zu optimieren. Wir verfügten über einen Downsampler und Amazon EMR, was eine schnelle Datenerfassung ermöglichte, während die Analysten das Feature Engineering mit Cloud-basierten Jupyter Notebooks durchführten.

SageMaker vereinfachte den Prozess, indem es die Cluster- und Modellverwaltung vereinfachte und die Bereitstellung von Modellen und die automatische Skalierung für anspruchsvollere Algorithmen ermöglichte.

Erstellen eines Trainingsjobs

Wir haben SageMaker-Trainingsaufträge verwendet, um das Modell anhand von sechs bis acht Stunden aggregierter Telemetriedaten zu trainieren. AWS Sagemaker bietet eine Liste verfügbarer Algorithmen und Bilder, sodass wir mit mittelgroßen Instanzen für das Training einfacher Modelle begannen und später zu benutzerdefinierten Instanzen übergingen.

Um eine SageMaker-Instanz einzurichten, musste ihre Rolle definiert werden, um den Ressourcenzugriff zu beschränken. So sollte beispielsweise ein Analyst, der an zwei verschiedenen Produktionen arbeitet, nur auf einen Bucket zugreifen können, ohne einen anderen zu sehen.

Das angepasste Modell wurde zur weiteren Verwendung auf S3 gespeichert. Die Trainingsaufträge wurden mithilfe von Triggern in die KI integriert, konnten aber auch über die API aufgerufen werden.

Erstellen eines Endpunkts

Nach dem Training wurde das Modell auf S3 gespeichert. Wir brauchten nur minimalen Code, um einen SageMaker-Endpunkt einzurichten, der von jeder Lambda-Funktion aus oder von außen aufgerufen werden konnte. Ein Ereignis, das den Endpunkt auslöste, wurde alle zwei Stunden „abgefeuert“, sodass das Team für die nächsten zwei Stunden eine neue Vorhersage eines möglichen Ausfalls hatte.

Produktionseinrichtung

Das Analystenteam nutzte Git, um die Python-Codedateien mit Änderungen zu pushen und den Trainingsjob automatisch mit einer neuen Codeversion auszulösen. Nach dem Training wurde das Modell automatisch auf SageMaker Endpoint bereitgestellt. Analysten erhalten die Vorhersagen von Modellen, indem sie einen S3-Ordner mit Eingabedaten auswählen und die Parameter über eine grafische Oberfläche aktualisieren. Wenn Motoranomalien festgestellt werden, alarmiert das Benachrichtigungssystem die Benutzer auf ihren Geräten, um den Zustand des Motors zu überprüfen.

Wie geht's weiter?

Wenn eine Panne auftrat, war es das Ziel des Mechanikers, das Teil so schnell wie möglich zu ersetzen. Der hohe Papieraufwand veranlasste uns jedoch, ein Content-Management-System für den Kunden einzuführen, das eine effizientere Protokollierung von Pannenereignissen ermöglichte und die Interaktion mit den Mechanikern erheblich verbesserte. Das System wurde so konzipiert, dass es modular und Cloud-agnostisch ist, sodass es in jeder Cloud-Infrastruktur wieder aufgebaut werden kann. Um das System zu verbessern, konnten Ultraschallsensoren an den Motoren installiert werden, um den Schall zu lesen und eine Spektralanalyse durchzuführen.

Dank der Implementierung der Plattform konnte der Kunde die Lebensdauer der Maschinen um bis zu 40 Prozent erhöhen und den Ersatzteilbestand um bis zu 20 Prozent reduzieren.

(ID:49441273)