Maschinen können pro Stunde Tausende Werte erzeugen. Lagertemperatur, Pumpenschwingung, Motorstrom und Betriebsstunden werden jedoch nicht allein durch ihre Erfassung zu Instandhaltungsinformationen. Nutzbar werden sie erst, wenn sie dem richtigen Betriebsmittel zugeordnet, im Kontext interpretiert und mit einer angemessenen Reaktion verknüpft sind.
IBM® Maximo® Application Suite kann diesen Weg mit Maximo Monitor und Maximo Manage abbilden. Dabei geht es nicht darum, jedes Sensormuster weiterzuleiten. Der Entwurf muss festlegen, welche Daten in einer Zeitreihe verbleiben, welche Werte aggregiert werden und welche als Meter Readings in Instandhaltungsprozesse eingehen.
Eine vereinfachte Kette lautet:
Sensor → Device → Metric → Aggregation oder Berechnung → Asset oder Location + Meter → Measurement Point → Warnung oder Arbeitsauftrag
Die Bedeutung und Zuordnung der Daten entscheiden über den Nutzen. Der Anschluss eines Sensors ist nur der erste Schritt.
Die Screenshots zeigen die tschechischsprachige Oberfläche einer am 16. Oktober 2026 erfassten Pilotinstanz von Maximo Monitor 9.2. Die dargestellten Schwingungs- und Temperaturwerte sind simulierte, aus CSV-Dateien geladene Daten. Die Screenshots belegen die Konfiguration von Monitor und den Daten-Ingest, nicht jedoch eine abgeschlossene Integration mit Maximo Manage.
Vom Betriebssignal zum Datenmodell
Die Quelle kann ein Sensor, eine SPS, ein SCADA-System, ein Gateway, ein Historian oder ein anderes Betriebssystem sein. Ein einzelner Elektromotor kann Lagertemperatur, Schwingung, Strom, Drehzahl und Laufzeit liefern.
Maximo Monitor gruppiert Geräte nach Device Type. Gemeinsame Eigenschaften und Metrics werden auf dieser Ebene definiert; ein Device stellt eine einzelne Datenquelle dar. Eine Metric ist ein gemessener oder abgeleiteter Wert wie BearingTemperature, VibrationRMS oder RuntimeHours.
Die Architektur von Maximo Monitor 9.2 unterscheidet sich von früheren Versionen. Die ursprüngliche IoT Platform ist optional. Monitor verwaltet Devices, Gateways und deren Authentifizierung direkt. Die IoT-Komponente kann weiterhin bestehende MQTT-Datenströme unterstützen, ist für die normale Geräteverwaltung und Ereignisaufnahme aber nicht mehr zwingend erforderlich. Einen breiteren Überblick bietet unser Artikel zu IBM Maximo Application Suite 9.2.
Ein Pilot-Device-Type und ein Device, vorbereitet für den Ingest simulierter Daten.
Eine Metric ist kein Meter
Die ähnlich klingenden Begriffe bezeichnen unterschiedliche Ebenen der Lösung.
Metric in Maximo Monitor
Eine Metric beschreibt einen vom Gerät empfangenen Betriebswert oder ein daraus berechnetes Ergebnis. Monitor speichert Werte über die Zeit, visualisiert sie und unterstützt Batch Data Metrics. Damit lassen sich etwa ein Stundenmaximum, ein Tagesmittel oder eine andere Aggregation mit festgelegter zeitlicher Granularität berechnen.
Seit Version 9.1 führt die Monitor-Dokumentation Streaming Data Metrics nicht mehr als aktuelle verfügbare Funktion. Für neue Berechnungen werden Batch Data Metrics verwendet. Das ist relevant, wenn ältere Entwürfe oder Anleitungen übernommen werden.
Metrics definieren die Werte, die Monitor empfängt oder ableitet.
Meter in Maximo Manage
Ein Meter ist ein logischer Zähler, der in Maximo Manage einem Asset oder einer Location zugeordnet ist. Unternehmen verfolgen damit Nutzung und Zustand von Betriebsmitteln. IBM unterscheidet drei Typen:
| Meter-Typ | Erfasster Wert | Typische Verwendung |
|---|---|---|
| Continuous | ein im Zeitverlauf steigender Wert | Betriebsstunden, Kilometer, Zyklen |
| Gauge | ein schwankender numerischer Wert | Temperatur, Druck, Schwingung |
| Characteristic | ein qualitativer Zustand aus definierten Werten | Ölfarbe, Sauberkeit, Gerätezustand |
Ein Continuous Meter wird typischerweise für nutzungsabhängige Instandhaltung eingesetzt. Gauge und Characteristic Meters können Condition Monitoring unterstützen. Kurz gesagt: Eine Metric beschreibt Gerätedaten; ein Meter bildet einen Wert ab, den Maximo Manage im Instandhaltungskontext verwendet.
Die Verbindung ist mehr als eine Namensgleichheit. Die Metric ID eines Asset- oder Location-Meters verknüpft diesen mit einer Metric aus einem Betriebsüberwachungssystem. Die Asset-Data-Dictionary-Integration und der Task IOTCONNECTOR können ausgewählte Daten anschließend als Meter Readings abrufen. Kennungen, Zeitstempel, Einheiten, Abrufintervalle und Regeln für historische Werte müssen ausdrücklich festgelegt werden.
Warum nicht jedes Sensormuster in Maximo Manage gehört
Ein Sensor mit einem Wert pro Sekunde erzeugt 86.400 Messwerte am Tag. Die detaillierte Zeitreihe kann für die Diagnose wertvoll sein. Ein Techniker benötigt jedoch selten jeden Wert als separates Meter Reading.
Für eine Instandhaltungsentscheidung sind oft nützlicher:
- das stündliche Schwingungsmaximum,
- Mittelwert und Streuung in einem festgelegten Intervall,
- Trend oder Änderungsgeschwindigkeit,
- Anzahl der Überschreitungen einer Betriebsgrenze,
- ein berechneter Anomaly Score.
Maximo Monitor kann Rohdaten entsprechend der festgelegten Aufbewahrungsdauer vorhalten und zugleich abgeleitete Metrics erzeugen. Manage erhält dann den Wert, den ein bestimmter Prozess benötigt. So bleibt der diagnostische Detailgrad erhalten, ohne eine betriebliche Zeitreihe mit der Historie von Meter Readings gleichzusetzen.
Die Aggregation muss zum physikalischen Phänomen passen. Ein Mittelwert kann eine kurze, aber kritische Spitze verdecken. Ein Maximum allein beschreibt möglicherweise keine schleichende Verschlechterung. Die Granularität ist daher Teil der Datenaussage und nicht nur eine technische Einstellung.
Drei Beispiele für unterschiedliche Entscheidungen
Schwingung einer Pumpe
Ein möglicher Datenfluss lautet:
Sensor → VibrationRMS → Maximo Monitor → Stundenmaximum → Gauge Meter → Measurement Point
Monitor bewahrt einen detaillierteren Verlauf für Analysen auf. Manage erhält in einem definierten Intervall einen aggregierten Wert, wenn dieser zum Instandhaltungsfall passt. Ein Measurement Point kann ihn anschließend mit Warning und Action Limits vergleichen.
Simulierte Schwingungsdaten im Minutenraster; dies ist kein Nachweis für ein in Manage erzeugtes Meter Reading.
Lagertemperatur eines Elektromotors
Ein Wert von 72 °C sagt ohne Kontext nicht aus, ob ein Motor in Ordnung ist. Entscheidend sind das konkrete Betriebsmittel, der Betriebszustand, der Normalbereich, der Trend und die Messbedingungen.
Der Datenfluss kann so aussehen:
Temperatursensor → BearingTemperature → Maximo Monitor → Gauge Meter → Measurement Point
72 °C können bei einem Motor normal und bei einem anderen auffällig sein. Grenzwerte sollten deshalb nicht ohne Prüfung von Konstruktion und Betriebsbedingungen zwischen Assets kopiert werden.
Die simulierte Temperatur im Minutenraster zeigt den zeitlichen Verlauf in Monitor, bestimmt aber allein noch nicht den Zustand des Betriebsmittels.
Betriebsstunden eines Förderers
Die Laufzeit beschreibt Nutzung und nicht unmittelbar den Zustand:
SPS → RuntimeHours → Continuous Meter → PM nach 2.000 Betriebsstunden
Eine meterbasierte PM kann Arbeit anhand der tatsächlichen Nutzung erzeugen. Das unterscheidet sich von einem rein kalenderbasierten Plan, etwa alle sechs Monate. Maximo kann beide Prinzipien kombinieren, zum Beispiel alle 2.000 Stunden oder sechs Monate, je nachdem, was zuerst eintritt.
Condition Monitoring: Ein Grenzwert allein erzeugt keinen Arbeitsauftrag
Die Anwendung Condition Monitoring verwendet Measurement Points für Assets oder Locations. Ein Measurement Point definiert zulässige Werte für einen Gauge oder Characteristic Meter und die Regeln für die anschließende Reaktion.
Bei einem Gauge Meter können Warning Limits eine Warnung und Action Limits die Erzeugung eines Arbeitsauftrags unterstützen. Ein Action Limit allein genügt jedoch nicht. Für die automatische Erzeugung sind auch der passende Job Plan oder PM-Datensatz und ein korrekt konfigurierter Generierungsmechanismus erforderlich. Characteristic Meters verwenden vergleichbare Regeln mit Action Values.
Die Kette lautet daher nicht „Grenzwert überschritten = immer Arbeitsauftrag“, sondern:
Meter Reading → Auswertung des Measurement Point → konfigurierte Warnung und/oder Arbeitsauftrag
So lassen sich eine informative Abweichung, eine erforderliche Prüfung und ein Ereignis unterscheiden, das tatsächlich Arbeit auslösen soll.
Kalender, Nutzung, Zustand, Anomalie und Prognose
Diese Ansätze beantworten unterschiedliche Fragen:
- kalenderbasierte vorbeugende Instandhaltung löst Arbeit nach einer verstrichenen Zeit aus;
- nutzungsabhängige Instandhaltung verwendet einen Continuous Meter, etwa Betriebsstunden oder Zyklen;
- Instandhaltung auf Basis des Zustands reagiert auf den aktuellen Zustand, etwa ein überschrittenes Action Limit;
- Anomalieerkennung erkennt Abweichungen vom üblichen Verhalten auch ohne einen einzelnen festen Grenzwert;
- vorausschauende Instandhaltung nutzt historische Betriebs- und Instandhaltungsdaten, um künftige Verschlechterung oder Ausfälle abzuschätzen.
Maximo Predict kann beispielsweise die geschätzte Zeit bis zum Ausfall, die Ausfallwahrscheinlichkeit in einem gewählten Prognosefenster oder Trends von Anomaly Scores berechnen. Eine Regel wie Temperatur > 80 °C ist daher keine vorausschauende Instandhaltung. Sie ist eine nützliche Condition-Monitoring-Regel zum aktuellen Zustand, aber keine Aussage über einen künftigen Ausfall.
Historische Daten als kontrollierter Einstieg
Ein Pilotprojekt muss nicht mit der Live-Anbindung eines ganzen Werks beginnen. Maximo Monitor 9.2 unterstützt den CSV-Ingest von Zeitreihen über die Benutzeroberfläche, APIs oder externe Systeme einschließlich Edge Data Collector. Eine CSV-Datei enthält einen Zeitstempel, eine Device-Kennung und mindestens eine Metric. Die Daten werden gegen die Definition des Device Type validiert.
Die Importhistorie des Piloten zeigt den Verarbeitungsstatus und die Anzahl der Datensätze.
Der manuelle Upload über die Benutzeroberfläche ist vor allem für kleinere oder einmalige Datenmengen vorgesehen und auf 50 MB pro Datei begrenzt. Für größere oder regelmäßige Übertragungen beschreibt IBM APIs und Object Storage. Bei Verbindungsunterbrechungen kann Edge Data Collector Daten in CSV-Dateien puffern und später an die Ingestion Pipeline übergeben. CSV ist damit ein unterstützter Batch-Weg mit definierten Betriebsgrenzen, aber kein universeller Ersatz für eine Online-Integration.
Die Monitor-Oberfläche nennt für den manuellen Upload eine maximale Dateigröße von 50 MB.
Ein praktikabler Pilot kann so vorgehen:
- einen Betriebsmitteltyp und eine Instandhaltungsentscheidung auswählen;
- wenige relevante Werte und ihre Einheiten festlegen;
- Device Type, Devices und Metrics erstellen;
- historische Daten einlesen und ihre Qualität prüfen;
- geeignete Granularität und Batch Data Metrics testen;
- Devices einem Asset oder einer Location zuordnen;
- festlegen, welche Metric mit einem Meter verbunden wird;
- Meter Readings, Grenzwerte und die resultierende Reaktion testen.
Stammen historische Werte aus einem älteren CMMS oder EAM, sind Bedeutung und Qualität ebenso wichtig wie das Exportformat. Dasselbe Prinzip erläutert unser Artikel zur Migration von Daten nach IBM Maximo.
Die schwierigste Aufgabe ist die Bedeutung der Daten
Die technische Verbindung ist nur der Anfang. Der Betriebsentwurf muss beantworten:
- Welches Signal gehört zu welchem Asset oder welcher Location?
- Ist der Wert eine Rohmessung, eine Aggregation oder eine Zustandsinformation?
- Welche zeitliche Granularität erhält das relevante Verhalten?
- Was bleibt in Monitor und was wird in Manage zu einem Meter Reading?
- Wann genügt eine Warnung und wann soll ein Arbeitsauftrag entstehen?
- Gehört der Anwendungsfall zu einer nutzungsabhängigen PM, zu Condition Monitoring, Anomalieerkennung oder einer echten Prognose?
Ein guter Datenfluss erzeugt nicht die größtmögliche Datenbank. Er schafft eine verlässliche Beziehung zwischen einer Messung, einem konkreten Betriebsmittel und einer Instandhaltungsentscheidung.
Mit einem Pilotprojekt für eine klare Entscheidung beginnen
Ein umfangreiches IoT-Programm ist kein notwendiger erster Schritt. Ein Pilot kann sich auf einen Betriebsmitteltyp, wenige Größen und historische Daten konzentrieren. 12servis kann beim Entwurf des Datenmodells, bei der Zuordnung von Devices und Metrics zu Assets und Meters, bei der Wahl von Aggregationen und bei der Anbindung an Condition Monitoring unterstützen.
Das erste Ziel sollte nicht sein, möglichst viele Sensoren anzuschließen. Der Pilot soll nachweisen, dass ausgewählte Daten zu einer klaren und nützlichen Instandhaltungsentscheidung führen.
Quellen
Die technischen Angaben wurden am 19. Oktober 2026 anhand der IBM Dokumentation geprüft.
- IBM Documentation: Technical overview of Maximo Monitor 9.2
- IBM Documentation: Creating device types
- IBM Documentation: CSV file ingestion
- IBM Documentation: Defining calculations
- IBM Documentation: IoT device data integration overview
- IBM Documentation: Meters
- IBM Documentation: Condition Monitoring
- IBM Documentation: Condition Monitoring measurement point field rules
- IBM Documentation: Master Preventive Maintenance records
- IBM Documentation: IBM Maximo Predict