Prädiktive Wartung für Bergbaumaschinen: LoRaWAN als Telemetrieebene für bessere Entscheidungen

Prädiktive Wartung klingt oft größer, als sie im Alltag beginnt. In der Praxis geht es selten darum, dass ein Algorithmus den nächsten Ausfall mit dramatischer Genauigkeit vorhersagt. Es geht zuerst um bessere Zustandsdaten: Vibrationen, Temperaturen, Betriebsstunden, Lastprofile, Hydraulikdruck, Ölzustand, Motorstrom, Förderbandlauf, Pumpenzyklen oder ungewöhnliche Schaltmuster. Wenn diese Daten regelmäßig und nachvollziehbar vorliegen, können Instandhaltungsteams Trends erkennen, Wartungen priorisieren und Ersatzteile planbarer beschaffen. Erst auf dieser Basis entstehen Modelle, Prognosen und automatisierte Hinweise.

Im Bergbau ist dieser Ansatz besonders wertvoll, aber auch besonders anspruchsvoll. Maschinen arbeiten in Staub, Feuchtigkeit, Vibration, Temperaturwechseln und engen Zeitfenstern. Mobile Geräte wechseln ihren Standort. Stationäre Anlagen wie Förderbänder, Pumpen, Lüfter, Brecher oder Bohranlagen sind für den Betrieb kritisch. Ein ungeplanter Stillstand kostet nicht nur Produktion, sondern kann auch Sicherheit und Logistik belasten. LoRaWAN kann hier eine Rolle spielen, wenn verteilte Sensoren kleine Zustandsdaten aus schwer zugänglichen Punkten übertragen sollen. Es ist jedoch nicht die Analyseplattform selbst und auch kein Ersatz für Wartungsprozesse. Es ist eine mögliche Telemetrieebene.

Kurz zusammengefasst: Prädiktive Wartung im Bergbau beginnt mit verlässlichen Zustandsdaten und klaren Wartungsentscheidungen. LoRaWAN eignet sich für kleine, vorverarbeitete Telemetriedaten wie Temperatur, Betriebsstunden, Grenzwertstatus oder einfache Vibrationskennwerte. Hochfrequente Rohdaten sollten meist lokal erfasst und verdichtet werden. Modelle sind nur so gut wie Sensorplatzierung, Datenqualität, historische Vergleichsdaten und die Instandhaltungsorganisation, die daraus handelt.

Warum Wartung im Bergbau anders ist

Bergbaumaschinen arbeiten nicht in einer sauberen Produktionshalle. Förderbänder laufen über lange Strecken. Pumpen stehen an feuchten Orten. Mobile Maschinen sind schwer, teuer, sicherheitsrelevant und manchmal weit von der nächsten Werkstatt entfernt. Staub setzt Sensoren zu, Vibration belastet Steckverbindungen, Wasser beschädigt Gehäuse, und mechanische Schläge gehören zum Alltag. Dazu kommen eingeschränkte Sicht, Nähe zu großen Maschinen und enge Räume. Die NIOSH-Fachseite zu Maschinenunfällen im Bergbau beschreibt unter anderem struck-by- und caught-in-Risiken sowie die Bedeutung von Proximity- und Sicherheitssystemen. Wartung ist deshalb nicht nur Kostenoptimierung, sondern Teil eines sicheren Betriebs.

Klassische Wartung arbeitet oft zeit- oder betriebsstundenbasiert: alle x Stunden schmieren, alle y Wochen inspizieren, nach Herstellerintervall tauschen. Das ist robust, aber nicht immer fein genug. Eine Pumpe, die unter ungewöhnlicher Last läuft, altert anders als eine identische Pumpe im Normalbetrieb. Ein Lager kann auffällig werden, bevor es heiß läuft. Ein Förderband kann sich durch zunehmende Schieflaufereignisse ankündigen. Prädiktive Wartung versucht, solche Muster früher sichtbar zu machen. Der Begriff sollte dabei nicht überdehnt werden. Zwischen einfacher Schwellenwertüberwachung, zustandsorientierter Wartung und statistischer Prognose gibt es Abstufungen.

Welche Rolle LoRaWAN übernehmen kann

LoRaWAN ist dann interessant, wenn viele Sensorpunkte kleine Datenmengen senden müssen und Batteriebetrieb oder einfache Nachrüstung wichtig sind. Die LoRa Alliance beschreibt LoRaWAN als LPWAN-Standard für IoT-Anwendungen mit vielen verteilten Endgeräten. Für Bergbaumaschinen heißt das: Ein Sensor an einem Förderbandlager muss nicht permanent Rohdaten streamen. Er kann in festen Abständen Temperatur, RMS-Vibrationswert, Batteriestatus und Alarmflag senden. Ein Hydraulikaggregat kann Druckbereich, Laufzeit und Temperatur melden. Ein Pumpenschacht kann Laufzyklen, Stromaufnahmebereich und Feuchte übermitteln. Solche Daten passen zur Stärke von LoRaWAN.

Nicht passend sind große Datenströme. Hochfrequente Vibrationsanalyse erzeugt Datenmengen, die besser lokal verarbeitet werden. Ein Edge-Gerät kann Rohdaten auswerten und nur Kennwerte senden: Spitzenwert, Frequenzband-Indikator, Trend, Alarmstatus oder Diagnosecode. The Things Network weist in seiner Dokumentation zu den LoRaWAN-Limitierungen auf die niedrige Bandbreite und kleine Payloads hin. Wer diese Grenze respektiert, kann LoRaWAN sinnvoll einsetzen. Wer versucht, es als drahtlosen Ersatz für jede Maschinenkommunikation zu verwenden, wird schnell unzufrieden.

Typische Sensoren, Datenpunkte und Messintervalle

Ein Predictive-Maintenance-Konzept sollte nicht mit der Frage beginnen, welcher Sensor sich kaufen lässt. Besser ist die Frage: Welcher Ausfallmodus soll früher erkannt werden? Ein Lagerproblem braucht andere Messdaten als ein Filterproblem, ein Hydraulikleck oder eine Überlastung. Ausfallmodus, Messwert und Entscheidung müssen zusammenpassen. Sonst entstehen Daten, aber keine bessere Wartung.

Messwert	Typischer Einsatz	LoRaWAN-Eignung	Hinweis
Temperatur	Lager, Motoren, Getriebe, Hydraulik	Sehr gut als periodischer Kennwert	Trend wichtiger als Einzelwert; Umgebungstemperatur berücksichtigen
Vibrationskennwert	Lager, Pumpen, Lüfter, Brecher, Förderbandrollen	Gut, wenn lokal verdichtet	Rohdaten lokal analysieren; nur Kennwerte und Alarme senden
Betriebsstunden und Zyklen	Pumpen, Fördertechnik, mobile Maschinen	Sehr gut	Hilft bei zustandsorientierter Wartungsplanung
Hydraulikdruck und Öltemperatur	Bohrgeräte, Lader, Pressen, mobile Maschinen	Gut für Intervalle und Ereignisse	Sensorik muss mechanisch geschützt sein
Stromaufnahmebereich	Motoren, Pumpen, Förderanlagen	Gut als verdichteter Wert	Für genaue Analyse oft lokale Messung mit Vorverarbeitung nötig
Feuchte, Staub, Gehäusezustand	Schaltschränke, Sensorboxen, Außenstellen	Sehr gut	Hilft, Sensorausfälle und Umwelteinflüsse zu erkennen

Praxis-Hinweis: Ein Vibrationssensor, der nur einmal pro Stunde einen groben Kennwert sendet, ist kein vollwertiges Schwingungsdiagnosesystem. Er kann trotzdem wertvoll sein, wenn er früh Trends an schwer erreichbaren Punkten sichtbar macht.

Von Condition Monitoring zu Predictive Maintenance

Condition Monitoring bedeutet: Der Zustand wird gemessen und überwacht. Predictive Maintenance geht einen Schritt weiter: Aus Zustand, Historie, Betriebsbedingungen und bekannten Ausfallmustern wird eine Wartungsempfehlung abgeleitet. Das NIST-Programm zu Smart Manufacturing Operations ordnet Prognostics and Health Management, Diagnostik und Wartung in den Kontext smarter Produktions- und Betriebssysteme ein. Das NASA Prognostics Center of Excellence arbeitet ebenfalls mit dem Gedanken, Systemzustände und Prognosen auf Basis von Daten und Modellen zu verbessern. Für den Bergbau heißt das: Ein Modell ist kein Selbstzweck. Es muss zu einer konkreten Entscheidung führen.

Diese Entscheidung kann einfach sein: „Lager X bei nächstem Stillstandsfenster prüfen.“ Sie kann mittelkomplex sein: „Pumpe Y läuft heißer als vergleichbare Pumpen bei gleicher Last; Ersatzteil bereitstellen.“ Oder sie kann organisatorisch sein: „Sensorgruppe Z zeigt steigende Fehlerraten, daher Montage und Schutzgehäuse prüfen.“ Gute prädiktive Wartung reduziert nicht jeden Ausfall, aber sie kann aus überraschenden Ereignissen planbarere Aufgaben machen. Dafür braucht sie Datenqualität. Ein schlecht montierter Sensor, eine unklare Maschinen-ID oder ein nicht gepflegtes Wartungsprotokoll zerstört mehr Vorhersagekraft als ein fehlender Algorithmus.

Architektur: Sensor, Gateway, Netzwerkserver, Wartungssystem

Sensor- und Edge-Ebene

Sensoren im Internet der Dinge sind für Wartung nur dann wertvoll, wenn sie einen konkreten Ausfallmodus adressieren. Montageort, Messintervall, Signalqualität und Wartungshistorie entscheiden darüber, ob ein Messwert zu einer besseren Entscheidung führt oder nur ein weiterer Datenpunkt bleibt.

Funk- und Gateway-Ebene

LoRa-Gateways bringen die Pakete der Maschinen- und Anlagensensoren in das IP-Netz. Im Bergbau ist entscheidend, ob Gateways die relevanten Maschinenbereiche tatsächlich erreichen. Für Tagebauflächen können erhöhte Standorte und wetterfeste Gateways sinnvoll sein. Unter Tage können Repeater, Gateways an Knotenpunkten oder hybride Backhaul-Lösungen nötig werden. In beiden Fällen sollten Kommunikationsausfälle als eigener Betriebszustand sichtbar sein.

Datenintegration

LoRaWAN-Fernwartung bedeutet in diesem Kontext vor allem Fernsichtbarkeit: Sensorstatus, Maschinenzustand, Alarmhistorie und Wartungsbedarf werden verfügbar, ohne dass jeder Messpunkt lokal ausgelesen werden muss. Fernwartung ist dabei nicht automatisch Fernsteuerung.

Technischer Merksatz: LoRaWAN transportiert Zustandsdaten. Die prädiktive Wartung entsteht erst durch Kontext: Maschine, Last, Historie, Wartungsereignisse, Ausfallmuster und Menschen, die den Hinweis bewerten.

Vorteile im Betrieb

Der naheliegende Vorteil ist weniger ungeplanter Stillstand. Aber seriöser ist die Formulierung: LoRaWAN-basierte Zustandsdaten können helfen, ungeplante Stillstände früher zu erkennen und Wartungsfenster besser zu planen. Ersatzteile müssen nicht immer erst beschafft werden, wenn die Maschine bereits steht. Instandhalter können Anlagen priorisieren. Sensoren an schwer zugänglichen Punkten reduzieren Wege und Sichtprüfungen, ohne diese vollständig zu ersetzen. Bei FörderbÄndern können auffällige Rollen oder Lagerbereiche früher markiert werden. Bei Pumpen können Laufzyklen, Temperatur und Feuchte Hinweise auf Verschleiß oder ungünstige Betriebsbedingungen geben.

Ein weiterer Vorteil ist die Dokumentation. Wartungsentscheidungen werden nachvollziehbarer, wenn sie auf Messdaten, Trends und Historie beruhen. Das hilft bei Schichtübergaben, Audits und Budgetdiskussionen. Es kann auch die Arbeitssicherheit unterstützen, weil Teams weniger häufig in ungünstige Bereiche müssen, nur um Routinewerte abzulesen. Trotzdem bleibt der Mensch wichtig. Sensoren können Hinweise geben, aber sie ersetzen nicht die Erfahrung von Instandhaltern, die Geräusche, Gerüche, Vibrationen, Verschmutzung und Betriebskontext einschätzen.

Grenzen und typische Fehler

Ein häufiger Fehler ist die Sammlung zu vieler Daten ohne Entscheidungspfad. Wenn niemand weiß, was bei einem steigenden Vibrationskennwert passiert, ist der Wert nur ein weiterer Graph. Ein zweiter Fehler ist die Übertragung zu vieler Rohdaten über LoRaWAN. Das führt zu Netzlast und enttäuschten Erwartungen. Ein dritter Fehler ist fehlende Stammdatenpflege: Sensor A gehört zu Maschine B, wurde aber nach einer Reparatur an Maschine C montiert. Solche Details wirken banal, sind aber für Modelle tödlich.

Auch die Umgebung setzt Grenzen. Ein Sensor an einer schlecht geschützten Stelle kann mechanisch beschädigt werden. Batterien altern anders bei Kälte, Hitze oder hoher Last. Unter Tage kann Funkabschattung auftreten. Im Tagebau können Wetter, Staub und weite Flächen die Gateway-Planung beeinflussen. Für sicherheitsrelevante Maschinenfunktionen gilt außerdem: LoRaWAN-Zustandsmonitoring darf nicht mit funktionaler Sicherheit verwechselt werden. Wenn eine Maschine sicher stoppen muss, gehört diese Funktion in eine dafür geeignete Steuerungs- und Sicherheitsarchitektur.

Implementierung in sechs Schritten

• Ausfallbild wählen: Mit einem bekannten, wiederkehrenden Problem beginnen.
• Baseline erfassen: Gesunden Betrieb bei unterschiedlichen Lasten dokumentieren.
• Kennwerte bilden: Rohdaten lokal verdichten und nur entscheidungsrelevante Werte senden.
• Rückmeldung nutzen: Wartungsbefund und Sensorwarnung nach jedem Fall miteinander vergleichen.

1. Kritische Anlagen auswählen: Nicht mit allem beginnen, sondern mit Maschinen, deren Stillstand teuer, häufig oder sicherheitsrelevant ist.
2. Ausfallmodi definieren: Welche Schäden sollen früher erkennbar werden? Lager, Hydraulik, Überhitzung, Schieflauf, Verstopfung, Feuchte?
3. Messdaten zuordnen: Jeder Ausfallmodus braucht passende Sensoren, Montagepunkte und Messintervalle.
4. LoRaWAN-Eignung prüfen: Kleine Kennwerte und Zustände eignen sich; Rohdaten und harte Echtzeit nicht.
5. Wartungsprozess anbinden: Alarm, Ticket, Ersatzteil, Schichtübergabe und Rückmeldung müssen definiert werden.
6. Modelle pflegen: Grenzwerte und Prognosen müssen mit realen Wartungsergebnissen abgeglichen werden.

Wann LoRaWAN sinnvoll ist und wann nicht

LoRaWAN ist sinnvoll für verteilte Sensoren, Nachrüstung, Batteriebetrieb, moderate Intervalle und kleine Zustandsdaten. Es eignet sich besonders für Nebenaggregate, entfernte Messpunkte, mobile Hilfseinrichtungen, Pumpen, Förderbandabschnitte, Schaltschränke, Lagerstellen oder Umweltbedingungen rund um Maschinen. Nicht sinnvoll ist es als Ersatz für Maschinenbusse, Safety-Steuerungen, Videoüberwachung, hochfrequente Schwingungsanalyse über Funk oder permanente Echtzeitregelung.

Damit ist LoRaWAN kein kleineres, sondern ein spezifischeres Werkzeug. Es kann die Lücke zwischen gar keinen Daten und voll verkabelter Maschinenüberwachung schließen. Gerade im Bergbau ist diese Zwischenebene interessant, weil viele relevante Zustände nicht dort entstehen, wo bereits eine perfekte Dateninfrastruktur liegt.

Datenqualität entscheidet über den Nutzen

Viele Predictive-Maintenance-Projekte scheitern nicht an Funktechnik, sondern an Datenhygiene. Ein Sensorwert braucht eine eindeutige Maschinenzuordnung, einen Montageort, eine Einheit, einen Zeitstempel, eine Kalibrierhistorie und einen bekannten Betriebszustand. Eine hohe Temperatur kann normal sein, wenn die Maschine unter Last läuft, und auffällig, wenn sie im Leerlauf steht. Eine Vibration kann durch Verschleiß entstehen, aber auch durch geänderte Last, lockere Montage oder eine andere Fahrweise. Ohne Kontext wird aus Telemetrie schnell Rauschen.

Deshalb sollten Betreiber schon im Pilotprojekt festlegen, welche Daten in welcher Qualität gebraucht werden. Dazu gehören Namenskonventionen für Maschinen, Sensoren und Baugruppen, Regeln für Sensorwechsel, Dokumentation von Wartungsereignissen und eine Rückmeldung, ob ein Alarm tatsächlich zu einem Befund geführt hat. Diese Rückkopplung ist entscheidend für Modelle: Nur wenn bekannt ist, welche Warnungen berechtigt waren, können Grenzwerte und Prognosen verbessert werden.

Pilotprojekt statt Vollausbau

Ein sinnvoller Einstieg ist ein begrenzter Pilot mit wenigen kritischen Anlagen. Beispielsweise können drei Pumpen, ein Förderbandabschnitt und ein entfernter Schaltschrank überwacht werden. Das Ziel ist nicht, sofort das gesamte Bergwerk zu digitalisieren, sondern Datenfluss, Funkabdeckung, Sensorbefestigung, Alarmregeln und Wartungsreaktion zu prüfen. Nach einigen Wochen oder Monaten lässt sich bewerten, welche Messwerte wirklich geholfen haben, welche Alarme zu häufig waren und welche Sensoren zu viel Wartung verursachten.

Erst danach lohnt der Ausbau. So entsteht eine Instandhaltungsarchitektur, die aus Betriebserfahrung lernt. LoRaWAN bleibt dabei ein Werkzeug für die Datenübertragung. Der eigentliche Fortschritt liegt darin, dass Wartungsteams früher sehen, wo sich ein Problem entwickelt, und ihre Arbeit planbarer machen können.

Wichtig ist außerdem die Trennung von Diagnose und Entscheidung. Ein Modell kann einen Hinweis erzeugen, aber die Wartungsentscheidung muss Betriebsrisiko, Ersatzteilverfügbarkeit, Produktionsplan und Sicherheit berücksichtigen. Gerade im Bergbau kann ein technisch auffälliger Wert bewusst bis zum nächsten sicheren Stillstandsfenster beobachtet werden, wenn eine sofortige Reparatur mehr Risiko erzeugen würde als die kontrollierte Weiterfahrt.

Ein guter Pilot hat deshalb ein klares Entscheidungskriterium. Vor dem Start sollte feststehen, welche Stillstände, Befunde oder Wartungsentscheidungen das Projekt verbessern soll. Nur dann lässt sich beurteilen, ob die Sensorik Kosten, Risiko oder Reaktionszeit wirklich reduziert hat. Das schützt vor Scheinfortschritt.

Häufige Fragen

Kann LoRaWAN Predictive Maintenance allein ermöglichen?

Nein. LoRaWAN kann Daten liefern. Predictive Maintenance entsteht durch Sensorik, Datenqualität, Historie, Modelle, Wartungsprozesse und Rückmeldungen aus realen Reparaturen.

Welche Maschinen eignen sich zuerst?

Gute Startpunkte sind Pumpen, Förderbänder, Lüfter, Motoren, Getriebe, Brecher, Hydraulikaggregate und entfernte Schaltschränke. Entscheidend ist, ob ein messbarer Zustand mit einer klaren Wartungsentscheidung verbunden werden kann.

Sollten Vibrationsrohdaten per LoRaWAN übertragen werden?

Meist nicht. Besser ist lokale Vorverarbeitung: Der Sensor oder Edge-Knoten berechnet Kennwerte und sendet nur verdichtete Daten, Trends oder Alarmstatus.

Wie entsteht aus Zustandsdaten eine belastbare Prognose?

Durch eine dokumentierte Baseline, passende Kennwerte, bekannte Ausfallbilder und die Rückmeldung aus realen Wartungsfällen. Ein Modell wird erst besser, wenn Fehlalarme und übersehene Schäden systematisch ausgewertet werden.

Was passiert bei einer Funkunterbrechung?

Der letzte Kontakt muss als eigener Zustand sichtbar sein. Wo es sinnvoll ist, puffert das Edge-Gerät Messwerte lokal und überträgt sie später mit ihrem ursprünglichen Zeitstempel. Schutzfunktionen dürfen nicht von dieser Nachübertragung abhängen.