Pexon Consulting | 10 Min. Lesezeit | 16.07.2026
TL;DR
Alte Maschinen liefern keine Daten, aber sie liefern Geräusche und Vibrationen. Ein Sensor-to-Cloud-Retrofit mit Industrial Raspberry Pi, Edge-ML und Azure IoT Hub macht daraus Anomalie-Signale, bevor die Maschine ausfällt. Pexon Consulting (80 Mitarbeiter, Microsoft-Partner, Deutschland) baut das als standardisierten Blueprint, der sich von der ersten Maschine auf die ganze Halle übertragen lässt.
Das Problem: Alte Maschinen schweigen
In den meisten Fabriken läuft Technik, die Jahrzehnte alt ist und nie für digitale Ausgänge gebaut wurde. Sie hat keine SPS-Schnittstelle, keinen OPC-UA-Server, kein Datenblatt für die Cloud. Wenn so eine Maschine ausfällt, merkt es die Produktion erst, wenn das Band steht. Wartung läuft nach Kalender oder nach Bauchgefühl, nicht nach Zustand.
Das Frustrierende daran: Die Maschine sendet die ganze Zeit Signale, nur hört niemand hin. Ein Lager, das ausschlägt, klingt anders. Ein Motor, der überlastet, vibriert anders. Diese physikalischen Signale lassen sich abgreifen, auch ohne dass die Maschine eine digitale Schnittstelle hat. Genau hier setzt ein Retrofit an.
Dieser Artikel zeigt drei Dinge: wie ein Sensor-to-Cloud-Retrofit aufgebaut ist, warum die Anomalie am Sensor erkannt werden muss und nicht erst in der Cloud, und warum Sie die Erkennung selbst bauen sollten statt auf einen auslaufenden Dienst zu setzen.
Sensor-to-Cloud in vier Schichten
Der Blueprint ist bewusst schlicht, damit er sich wiederholen lässt. Ein Industrial Raspberry Pi hängt mit Audio- und Beschleunigungssensoren an der Maschine, wertet die Signale lokal aus und streamt nur die Ergebnisse in die Cloud.
Der Charme liegt darin, dass die Maschine selbst unangetastet bleibt. Der Sensor sitzt außen, der Pi macht die Arbeit, die Cloud sieht nur noch verdichtete Signale. So wird aus einer stummen Alt-Maschine ein Datenlieferant, ohne sie umzubauen. Wie sich solche Maschinendaten in die gesamte Wertschöpfung einordnen, zeigt unser Überblick zur KI-Wertschöpfungskette in der Fertigung.
Edge-ML: die Anomalie entsteht am Sensor
Die kurze Antwort auf die Frage „warum nicht alles in die Cloud streamen“: Latenz, Bandbreite und Ausfallsicherheit. Ein Audiosignal in voller Auflösung dauerhaft in die Cloud zu schicken, ist teuer und langsam. Die Anomalie-Erkennung gehört deshalb auf das Edge-Gerät, direkt am Sensor.
Auf dem Pi laufen Signalverarbeitung, etwa eine FFT zur Frequenzanalyse, und ein leichtgewichtiges ML-Modell über ONNX Runtime oder TensorFlow Lite. Die Erkennung passiert in Millisekunden, und sie funktioniert auch, wenn die Netzwerkverbindung kurz weg ist. Nur wenn das Modell eine Auffälligkeit sieht, geht ein verdichtetes Signal in die Cloud.
# Anomalie-Inferenz auf dem Edge-Geraet (Raspberry Pi, ONNX Runtime)
import onnxruntime as ort
import numpy as np
sess = ort.InferenceSession("anomaly_model.onnx")
def bewerte_fenster(features: np.ndarray) -> bool:
# features: FFT- und Statistik-Merkmale aus dem Sensorfenster
score = sess.run(None, {"input": features.astype(np.float32)})[0]
return bool(score > SCHWELLE) # nur Auffaelligkeiten in die Cloud meldenUnsere klare Empfehlung: Halten Sie die Modelle auf dem Edge-Gerät klein und interpretierbar. Ein einfaches Modell, das der Instandhalter versteht, schlägt ein komplexes, dem niemand glaubt.
Warnung: der Azure Anomaly Detector wird eingestellt
Ein wichtiger Hinweis, der viele Retrofit-Projekte 2026 betrifft: Der Azure Anomaly Detector Service wird zum 1. Oktober 2026 eingestellt. Wer seine Anomalie-Erkennung auf diesen Managed-Dienst gebaut hat, muss migrieren. Wir raten deshalb dazu, die Erkennung von Anfang an auf portable Modelle über ONNX Runtime zu setzen, die auf dem Edge-Gerät laufen und unabhängig von einem einzelnen Cloud-Dienst sind.
Das ist kein Nachteil, sondern ein Vorteil. Ein eigenes, auf Ihre Maschinen trainiertes Modell erkennt Ihre spezifischen Fehlerbilder besser als ein generischer Dienst, und es läuft weiter, egal was Microsoft mit einem einzelnen Service macht. Die Datenbasis dafür ist derselbe Sensor-Stream, den Sie ohnehin schon erfassen. Wie Fertigungsdaten insgesamt zum Hebel werden, zeigt unser Beitrag zu KI in der Fertigung für den Mittelstand.
Der standardisierte IoT-Blueprint
Der eigentliche Wert entsteht nicht an der ersten Maschine, sondern an der zehnten. Ein Retrofit als Blueprint bedeutet: gleiche Sensorik, gleiches Edge-Gerät, gleiche Cloud-Anbindung, gleiche Dashboards. Was an der Pilotmaschine in einigen Wochen steht, lässt sich danach schnell und günstig ausrollen.
Ein typischer Brownfield-Retrofit an der ersten Maschine dauert in der Regel sechs bis acht Wochen, von der Sensorwahl bis zum Dashboard. Der Wiederholfall danach ist ein Bruchteil davon, weil die Architektur steht. Genau diese Standardisierung ist der Unterschied zwischen einem netten Pilotprojekt und einem Programm, das die ganze Halle absichert. Sie planbar zu machen, ist der Kern unserer Arbeit in der Fertigung.
Häufig gestellte Fragen
Kann man alte Maschinen ohne digitale Schnittstelle überwachen?
Ja. Alte Maschinen liefern zwar keine digitalen Daten, aber physikalische Signale wie Geräusch und Vibration. Diese lassen sich mit externen Audio- und Beschleunigungssensoren abgreifen, ohne die Maschine umzubauen. Ein Edge-Gerät wertet die Signale aus und meldet Auffälligkeiten. So wird auch eine jahrzehntealte Maschine zum Datenlieferanten.
Warum läuft die Anomalie-Erkennung auf dem Edge-Gerät statt in der Cloud?
Wegen Latenz, Bandbreite und Ausfallsicherheit. Rohdaten dauerhaft in die Cloud zu streamen ist teuer und langsam. Auf dem Edge-Gerät passiert die Erkennung in Millisekunden und funktioniert auch bei kurzer Netzunterbrechung. Nur verdichtete Signale gehen in die Cloud, was Bandbreite spart und die Reaktion beschleunigt.
Welche Technik steckt in einem Sensor-to-Cloud-Retrofit?
Audio- und Beschleunigungssensoren an der Maschine, ein Industrial Raspberry Pi als Edge-Gerät, Signalverarbeitung plus ein ML-Modell über ONNX Runtime oder TensorFlow Lite, sowie Azure IoT Hub mit MQTT für die Cloud-Anbindung. In der Cloud folgen Streaming, Dashboard und Alerting. Der Aufbau ist bewusst schlicht, damit er sich wiederholen lässt.
Was passiert mit dem Azure Anomaly Detector?
Der Dienst wird zum 1. Oktober 2026 eingestellt. Wer darauf aufgebaut hat, muss migrieren. Wir empfehlen ohnehin, die Anomalie-Erkennung auf portable Modelle über ONNX Runtime zu setzen, die auf dem Edge-Gerät laufen. Diese sind unabhängig von einem einzelnen Cloud-Dienst und lassen sich auf die eigenen Fehlerbilder trainieren.
Wie lange dauert ein IoT-Retrofit?
Ein Brownfield-Retrofit an der ersten Maschine dauert in der Regel sechs bis acht Wochen, von der Sensorauswahl über die Edge-ML bis zum Dashboard. Der große Vorteil kommt danach: Weil die Architektur als Blueprint steht, ist jede weitere Maschine deutlich schneller und günstiger angebunden.
Nächster Schritt
Wenn Sie Maschinen haben, die ohne Vorwarnung ausfallen, bauen wir den Retrofit an einer Pilotmaschine und zeigen den Weg zum Blueprint. Ehrlich, auch bei der Frage, welche Maschine sich überhaupt lohnt.
Verwandte Themen
→KI-Prozessverbesserung: Projektdokumente in der Fertigung
