Stroje mohou vytvářet tisíce hodnot za hodinu. Teplota ložiska, vibrace čerpadla, proud motoru nebo provozní hodiny ale samy o sobě ještě nejsou informací pro údržbu. Hodnotu získají až ve chvíli, kdy je lze přiřadit ke konkrétnímu zařízení, správně interpretovat a navázat na odpovídající reakci.
V IBM® Maximo® Application Suite lze tuto cestu postavit mezi Maximo Monitor a Maximo Manage. Nejde přitom o prosté přeposílání všech vzorků. Návrh musí určit, která data zůstanou v časové řadě, která se agregují a která se stanou odečtem Meteru používaným v procesech údržby.
Zjednodušený řetězec vypadá takto:
senzor → Device → Metric → agregace nebo výpočet → Asset či Location + Meter → Measurement Point → alert nebo pracovní příkaz
Právě význam a mapování dat rozhodují o tom, zda propojení pomůže údržbě. Samotné připojení senzoru nestačí.
Snímky v článku pocházejí z českého rozhraní pilotní instance Maximo Monitor 9.2 zachycené 16. 10. 2026. Zobrazené hodnoty vibrací a teploty jsou simulovaná data nahraná z CSV. Snímky dokládají konfiguraci Monitoru a ingest dat; nedokládají dokončené propojení s Maximo Manage.
Od provozního signálu k datovému modelu
Zdrojem nemusí být pouze samostatný senzor. Data mohou přicházet z PLC, SCADA, gateway, historizačního systému nebo jiného provozního zdroje. Jeden elektromotor může poskytovat teplotu ložiska, vibrace, proud, otáčky i dobu běhu.
Maximo Monitor seskupuje zařízení podle Device Type. Na této úrovni se definují společné vlastnosti a Metrics; konkrétní Device pak představuje jednotlivý zdroj dat. Metric je měřená nebo odvozená veličina, například BearingTemperature, VibrationRMS nebo RuntimeHours.
Architektura Maximo Monitor 9.2 se proti starším verzím změnila. Původní IoT Platform je volitelnou součástí a Monitor spravuje zařízení, gateway i jejich autentizaci přímo. IoT komponenta zůstává použitelná například pro existující MQTT toky, ale pro standardní správu zařízení a ingest událostí už není povinná. Přehled dalších změn verze 9.2 najdete v článku o IBM Maximo Application Suite 9.2.
Pilotní Device Type a Device připravené pro načtení simulovaných dat.
Metric není totéž co Meter
Podobné názvy označují odlišné vrstvy řešení.
Metric v Maximo Monitor
Metric popisuje provozní veličinu přijatou od zařízení nebo výsledek výpočtu nad těmito daty. Monitor ukládá hodnoty v čase, zobrazuje je a umožňuje nad nimi vytvářet batch data metrics. Ty mohou například počítat hodinové maximum, denní průměr nebo jinou agregaci s určenou časovou granularitou.
Od verze 9.1 už dokumentace Monitoru nepočítá se streaming data metrics jako s aktuální funkcí. Pro nové výpočty se používají batch data metrics. To je důležitý rozdíl při přebírání starších návrhů nebo návodů.
Metrics definují veličiny, které Monitor přijímá nebo z nich odvozuje.
Meter v Maximo Manage
Meter je logické měřidlo přiřazené k Assetu nebo Location v Maximo Manage. Organizace je používá ke sledování využití a stavu zařízení. IBM rozlišuje tři typy:
| Typ Meteru | Co zaznamenává | Typické použití |
|---|---|---|
| Continuous | průběžně rostoucí hodnotu | motohodiny, kilometry, počet cyklů |
| Gauge | kolísající číselnou hodnotu | teplota, tlak, vibrace |
| Characteristic | kvalitativní stav z definovaných hodnot | barva oleje, čistota, stav zařízení |
Continuous Meter se typicky používá pro údržbu podle využití. Gauge a Characteristic Meter lze použít v Condition Monitoring. Stručně řečeno: Metric popisuje data zařízení; Meter vyjadřuje hodnotu, kterou Maximo Manage používá v kontextu údržby.
Propojení není jen shoda názvů. V Asset nebo Location Meteru se Metric ID přiřadí k metrice ze systému provozního monitoringu. Integrace Asset Data Dictionary a úloha IOTCONNECTOR potom mohou načítat vybraná data jako Meter Readings. Je proto nutné navrhnout identifikátory, časové značky, jednotky, interval načítání i pravidla pro historii.
Proč neposílat každý vzorek do Maximo Manage
Senzor, který odešle jednu hodnotu za sekundu, vytvoří 86 400 vzorků denně. Detailní časová řada může být důležitá pro diagnostiku, ale technik obvykle nepotřebuje každý vzorek jako samostatný Meter Reading.
Pro rozhodnutí údržby může být užitečnější například:
- hodinové maximum vibrací,
- průměr a rozptyl v určeném intervalu,
- trend nebo rychlost změny,
- počet překročení provozní hranice,
- vypočtené skóre anomálie.
Maximo Monitor může uchovat surová data podle nastavené doby retence a současně vytvářet odvozené metriky. Do Manage se pak přenáší pouze hodnota odpovídající konkrétnímu procesu. Tím se neztrácí diagnostický detail, ale provozní časová řada se nezaměňuje za historii Meter Readings.
Volba agregace musí odpovídat jevu. Průměr může skrýt krátkou, ale závažnou špičku; samotné maximum zase nemusí popsat dlouhodobé zhoršování. Granularita proto není jen technický parametr. Je součástí významu dat.
Tři příklady různých rozhodnutí
Vibrace čerpadla
U vibračního senzoru může tok vypadat takto:
senzor → VibrationRMS → Maximo Monitor → hodinové maximum → Gauge Meter → Measurement Point
Monitor zachová detailnější průběh pro analýzu. Do Manage se v pravidelném intervalu zapíše agregovaná hodnota, pokud právě ta odpovídá zvolenému pravidlu údržby. Measurement Point potom může porovnat odečet s warning a action limity.
Simulovaná minutová data vibrací v pilotu; nejde o důkaz vytvořeného Meter Readingu v Manage.
Teplota ložiska elektromotoru
Hodnota 72 °C bez kontextu neříká, zda je motor v pořádku. Je třeba znát zařízení, provozní režim, běžné rozpětí, trend a podmínky měření.
Tok může být:
teplotní senzor → BearingTemperature → Maximo Monitor → Gauge Meter → Measurement Point
Pro jeden motor může být 72 °C běžná teplota, pro jiný odchylka. Limity se proto nemají kopírovat mezi zařízeními bez posouzení jejich konstrukce a provozu.
Simulovaná minutová teplota ukazuje průběh veličiny v Monitoru, nikoli sama o sobě stav zařízení.
Provozní hodiny dopravníku
Doba běhu popisuje využití, nikoli přímo stav:
PLC → RuntimeHours → Continuous Meter → PM po 2 000 provozních hodinách
Meter-based PM může generovat práci podle skutečného využití zařízení. Liší se tak od čistě kalendářového plánu, například jednou za šest měsíců. Maximo umožňuje oba principy také kombinovat, například „po 2 000 hodinách nebo po šesti měsících podle toho, co nastane dříve“.
Condition Monitoring: limit sám pracovní příkaz nevytvoří
V aplikaci Condition Monitoring se vytvářejí Measurement Points pro Assety nebo Locations. Measurement Point určuje přijatelné hodnoty Gauge nebo Characteristic Meteru a pravidla následné reakce.
U Gauge Meteru lze nastavit warning limity pro alert a action limity pro pracovní příkaz. Pro automatické vytvoření pracovního příkazu však nestačí pouze action limit. Konfigurace musí obsahovat také odpovídající Job Plan nebo PM a musí být správně nastaven mechanismus generování. U Characteristic Meteru se podobně pracuje s action values.
Řetězec tedy není „překročení = vždy pracovní příkaz“, ale:
Meter Reading → vyhodnocení Measurement Pointu → nakonfigurovaný alert a/nebo pracovní příkaz
To umožňuje rozlišit informativní odchylku, požadavek na kontrolu a situaci, která má skutečně založit práci.
Kalendář, využití, stav, anomálie a predikce
Tyto přístupy řeší různé otázky:
- kalendářová preventivní údržba spouští zásah po uplynutí času;
- údržba podle využití používá Continuous Meter, například motohodiny nebo cykly;
- údržba na základě stavu reaguje na aktuální stav, například překročený action limit;
- detekce anomálií hledá odchylku od obvyklého chování i bez jediné pevné hranice;
- prediktivní údržba používá historii, provozní a údržbová data k odhadu budoucí degradace nebo poruchy.
Maximo Predict může pracovat například s odhadem času do poruchy, pravděpodobností poruchy v určeném okně nebo vývojem anomaly score. Jednoduchá podmínka teplota > 80 °C proto není prediktivní údržba. Je to užitečné pravidlo condition monitoring, které popisuje současný stav, nikoli pravděpodobný budoucí vývoj.
Historická data jako bezpečný začátek
Pilot nemusí začínat živým připojením celé výroby. Maximo Monitor 9.2 podporuje ingest časových řad z CSV souborů přes uživatelské rozhraní, API nebo externí systém včetně Edge Data Collectoru. CSV obsahuje časovou značku, identifikátor zařízení a nejméně jednu metriku; data se validují proti definici Device Type.
Historie pilotních importů ukazuje stav zpracování souborů a počty záznamů.
Ruční upload přes rozhraní je určen především pro menší nebo jednorázové dávky a má limit 50 MB na soubor. Pro větší či pravidelné přenosy dokumentace popisuje API a objektové úložiště. Edge Data Collector může při výpadku konektivity ukládat data do CSV a později je předat ingest pipeline. CSV tedy není univerzální náhradou online integrace, ale plnohodnotnou dávkovou cestou s jasnými provozními omezeními.
Ruční upload v rozhraní Monitoru uvádí maximální velikost souboru 50 MB.
Praktický pilot může postupovat takto:
- vybrat jeden typ zařízení a jedno rozhodnutí údržby;
- připravit několik relevantních veličin a jejich jednotky;
- vytvořit Device Type, Devices a Metrics;
- načíst historická data a ověřit jejich kvalitu;
- vyzkoušet vhodnou granularitu a batch data metrics;
- přiřadit zařízení k Assetu nebo Location;
- určit, která metrika má být navázána na Meter;
- otestovat Meter Readings, limity a následnou reakci.
Pokud historická data pocházejí ze staršího CMMS nebo EAM, je vhodné současně řešit jejich význam a kvalitu, ne pouze formát exportu. Stejný princip popisuje článek o migraci dat do IBM Maximo.
Nejtěžší část je rozhodnout, co data znamenají
Technické připojení bývá jen první krok. Pro provozní návrh jsou důležitější otázky:
- Který signál patří ke kterému Assetu nebo Location?
- Je hodnota surovým měřením, agregací, nebo stavovou informací?
- Jaká časová granularita zachová podstatný jev?
- Co má zůstat v Monitoru a co se má stát Meter Readingem v Manage?
- Kdy stačí alert a kdy má vzniknout pracovní příkaz?
- Patří případ do PM podle využití, Condition Monitoring, detekce anomálií, nebo skutečné predikce?
Dobře navržený tok nevytváří co největší databázi. Vytváří důvěryhodný vztah mezi měřením, konkrétním zařízením a rozhodnutím údržby.
Začněte pilotem s jasným rozhodnutím
Není nutné začínat rozsáhlým IoT projektem. Pilot lze postavit na jednom typu zařízení, několika veličinách a historických datech. 12servis může pomoci s návrhem datového modelu, mapováním Devices a Metrics na Assety a Metery, volbou agregací i nastavením návaznosti na Condition Monitoring.
Prvním cílem nemá být připojit co nejvíce senzorů. Má jím být ověření, že vybraná data vedou k jednoznačnému a užitečnému rozhodnutí údržby.
Zdroje
Technické informace byly ověřeny proti dokumentaci IBM dne 19. 10. 2026.
- 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