A prediktív karbantartás érzékelők, mesterséges intelligencia és adatelemzés kombinációjával optimalizálja a berendezések karbantartását. A berendezések karbantartására való felkészülésnek a karbantartási költségek minimalizálása és az üzemidő maximalizálása jelentős értéket jelent a gyártók számára.
Az adatok a megoldás középpontjában rejlik. Az adatoknak megfelelő hibamutatókkal, valamint a kontextust leíró egyéb szempontokkal kell rendelkezniük. Több forrásból is származhat, például érzékelőkből, gépnaplókból és gyártási alkalmazásnaplókból.
Ez a cikk prediktív karbantartási megoldás készítésének lehetőségeit mutatja be. Különböző perspektívákat mutat be, és meglévő anyagokat mutat be az első lépésekhez. A prediktív karbantartási megoldások követelményei berendezésenként, környezetenként, folyamatonként és szervezetenként eltérőek. Alternatív megközelítéseket és technológiákat biztosítunk, amelyek végigvezetik Önt az igényeinek megfelelő megoldás meghatározásának folyamatában.
Kezdjük egy prediktív karbantartási megoldás magas szintű összetevőivel.
Ebben a részletezésben a következő magas szintű tevékenységek történnek:
- Betanítási adatok gyűjtése, beleértve a hibaadatokat is.
- Ezekkel a betanítási adatokkal betanítsa a Machine Learning (ML) modellt a jövőbeli eszközhibák előrejelzéséhez adott feltételek mellett.
- Folytassa az adatgyűjtést folyamatosan.
- Adja meg az összegyűjtött adatokat a ML modellhez, amely általában bizonyos szintű megbízhatósággal előrejelzi a hibát. (Például: "85%-os a valószínűsége annak, hogy a gép a következő 24 órában meghibásodik.")
- Az előrejelzett hibaeseteket feltárja.
- Tervezze meg és járjon el az adatokban látható megállapítások alapján.
A ML modell betanítása
Egy ML modell létrehozásához elegendő, helyes és teljes adatra van szükség. A prediktív karbantartás emellett egyedi kihívásokat is felvet, amelyek közül a legfontosabb a hibaadatok rendelkezésre állása. A meghibásodások viszonylag ritkán fordulnak elő, különösen nagy tőkebefektetésű berendezésekben, például számítógépes numerikus vezérlő (CNC) gépekben vagy olajfinomítók összetevőiben. Előfordulhat, hogy még akkor sem rendelkezünk elegendő hibaadatokkal, ha hosszú ideje gyűjtünk érzékelőadatokat. Gondolja át, hogyan van definiálva a "hiba". Mi jelent pontosan hibát? Akkor működik váratlanul az eszköz? Akkor működik, ha az eszköz olyan szintre csökken, ahol már nem a kívánt szinten teljesít? A meghibásodási eset egy darabológépet semmisít meg, a fémfáradtság által okozott alkatrészhiba vagy más, meghibásodásra utaló jelek miatt, mielőtt katasztrófa történne?
A ML szükséges adatok figyelembevételével
Fontolja meg azt is, hogy elegendő adatot rögzítünk a hibák megfelelő rögzítéséhez? Sok esetben előfordulhat, hogy az érzékelő adatai önmagukban nem elegendőek a hiba azonosításához. Előfordulhat, hogy külső adatokra van szükség ahhoz, hogy a gép állapotát hibaállapotként jelöljük meg, vagy másodlagos információforrásként, például egy másik rendszeren keresztül rögzítsük a hibaesetet. Ezek az adatok külső rendszerekben, például ERP-ben, gyártási végrehajtási rendszerekben (MES), történészekben stb. találhatók. Előfordulhat, hogy az adatok átlépik a gyártó cégeknél elterjedt IT/OT-osztást, ami kihívást jelent a szükséges adatok védelme során.
A prediktív karbantartás természete szerint dinamikus probléma, ezért a kapcsolódó gépi tanulási modelleket folyamatosan frissíteni kell (vagy újra be kell tanítani). Ha jól működik, a prediktív karbantartásnak csökkentenie kell a hibák előfordulását, ami jó dolog, de ez kevesebb hibaadatot eredményez. Emellett a meghibásodást befolyásoló funkciók is megváltozhatnak, ami érvényteleníti a korábbi gépi tanulási modelleket. Javasoljuk, hogy rendszeresen betanítási modelleket végezzenek a hibaállapotok változásaival.
A "friss" adatok olyan új feltételeket is jelentenek, amelyeket a modell betanításához korábban használtaktól eltérően hoztak be a modellbe. Más szóval modellezhetjük a hibát x1,x2,⋯,xn, f(x1,x2,⋯,xn) változók függvényeként, de végül felfedezhetjük az x(n+1),⋯,x(m+n) változók működését is, ezért előfordulhat, hogy módosítani kell az f(x1) modell betanítását, x2,⋯;x(m+n))). Előfordulhat, hogy a modell nem működik megfelelően a hibák észleléséhez. Új modell hozható létre, amely a gép MES-naplóiból származó adatpontokat is tartalmazza a következő iterációhoz.
A gépi tanulási modellek betanításához szükséges adatok még a modern IoT-környezetek felhőbe streamelt adatai nélkül is lehetnek a MES-ben, a történészekben vagy más éles rendszerekben. Csak az adatok előkészítése a gépi tanulási modellek betanításához használható.
Az alábbi ábra egy ML modell betanításának tipikus munkafolyamatát szemlélteti. Az "ismétlés" feliratú nyíl azt sugallja, hogy ez egy iteratív folyamat. Folyamatosan újratanítjuk a modelleket, amint friss adatok érkeznek, és megváltoznak a feltételek. A ciklus ismétlődésének időpontja és gyakorisága az implementáció adott feltételeitől függ. Gondosan monitoroznia kell a korábban létrehozott modellek teljesítményét a hibák előrejelzéséhez, hogy észlelje, ha a modellek "elöregednek" vagy "romlanak".
Az új modellek folyamatos betanítása és üzembe helyezése szintén kihívást jelent a kezelésükhöz. A Microsoft Azure Machine Learning Modellkezelési szolgáltatást kínál a modellek CI/CD-hez (folyamatos integráció és folyamatos teljesítés).
A Microsoft részletes útmutatót tett közzé az adatok előkészítéséről és a gépi tanulási modell betanításairól. Három tipikus karbantartási kérdés és a kapcsolódó gépi tanulási algoritmusok állnak rendelkezésre:
- Az objektum esetében mekkora annak a valószínűsége, hogy a következő X órán belül hiba történik? Válasz: 0-100%
- A bináris besorolás egy olyan gépi tanulási módszer, amely adatokat használ egy elem vagy adatsor kategóriájának, típusának vagy osztályának meghatározásához a két osztály egyikének tagjaként. Többféle besorolási algoritmus létezik, a Microsoft közzétett egy algoritmuskészletet, amely Machine Learning studiomodulok formájában érhető el.
- Mi az eszköz fennmaradó hasznos élettartama? Válasz: X óra
- A regresszió a gépi tanulási algoritmusok egy olyan osztálya, amely előrejelzi egy változó értékét más változók halmaza alapján. Machine Learning Studio modulként tartalmaz regressziós algoritmusokat.
- Hosszú távú memória (LSTM): Az LSTM-hálózatok mély neurális hálózatok (DNN) típusai. A DNN-k ihletése az agyban lévő egyes neuronok viselkedésének modellezéséből származik. A Microsoft részletes útmutatót tett közzé az LSTM prediktív karbantartáshoz való használatáról
- Melyik eszközhöz van szükség a legsürgetőbb karbantartásra? Válasz: X objektum
- A többosztályos besorolás egy olyan gépi tanulási módszer, amely adatokat használ egy elem vagy adatsor kategóriájának, típusának vagy osztályának meghatározásához két osztálynál több osztály tagjaként.
Az adatok behozása több csatorna használatát is jelentheti. Először tömegesen inicializálja, majd folytatja a streamelési adatok fogadását a hibák előrejelzéséhez. A modell későbbi buildjeihez is használhatja.
Adatok betöltése az Azure-ba
Microsoft Azure számos különböző szolgáltatást nyújt az adatok betöltéséhez és tárolásához. Ha még nem tette meg, kötegelt metódusokat ajánlunk az adatok Azure-ba való átviteléhez. Ha az adatokat fájlként exportálhatja jól ismert formátumokba, például csv, json, xml stb. ezek a jó lehetőségek. A feltöltés előtt tömörítheti is őket, és tovább dolgozhatja őket a felhőoldalon.
- Feltöltés az AzCopyval blobtárolóba (Windows és Linuxra egyaránt).
- Blobtároló csatlakoztatása fájlrendszerként Linux rendszeren.
- Használjon Import/Export szolgáltatást, ha az adatméret nagy, és túl sok időt vesz igénybe a feltöltés.
- Azure-fájlmegosztás csatlakoztatása Windows, Linux és macOS.
Ha az adatok egy SQL Server-adatbázisban találhatóak, Data Migration Assistant használatával is feltöltheti az adatokat egy Azure SQL Database.
Az Azure platformon számos eszköz és szolgáltatás áll rendelkezésre az ETL-műveletek kinyerése, átalakítása és betöltése céljából. A legkiemelkedőbb szolgáltatás a Azure Data Factory, amely az adatok kezeléséhez szükséges funkciók teljes készletét biztosítja. Az azure-ban elérhető számos ML szolgáltatásban az nyílt forráskód kódtárakon keresztül más lehetőségek is rendelkezésre állnak az adatok kezelésére.
Ami a ML mód betanítását illeti, a Microsoft Azure számos lehetőséget kínál, amelyek mindegyike különböző kombinációkban használható.
- Azure Machine Learning-szolgáltatások
- Azure Machine Learning Studio
- Adatelemzési virtuális gép
- Spark MLLib a HDInsightban
- Batch AI Training szolgáltatás
A használni kívánt eszköz kiválasztása a műveletek összetettségétől, a csapat élményétől és az adatok méretétől függ.
A felhőalapú megoldások költségegyenlete számos változót tartalmaz a felhőszolgáltatás költségei mellett, például a további mérnöki, adminisztrációs, adatátviteli stb. Ezeket a változókat a költségek értékelésekor és tájékozott döntés meghozatalához használja. A szolgáltatások nem alkotják a teljes költségegyenletet.
Az adatok elemzésére és a modell közzétételére szolgáló folyamat megtervezése részletes téma, és a használt technológiák eltérnek egymástól. Ezek a témakörök nem tartoznak a cikk hatókörébe. A modell létrehozásához használható folyamatot és Azure-szolgáltatásokat bemutató cikkek sorozata érhető el. A Microsoft emellett szisztematikus megközelítést biztosít olyan megoldások létrehozásához, amelyek lehetővé teszik az adattudósok csapatai számára, hogy hatékonyan működjenek együtt az adatok életciklusa során.
A Microsoft Machine Learning dokumentációja jó kiindulási pont a ML és AI-modellek felhőbeli létrehozásának, üzembe helyezésének és kezelésének lehetőségeinek megismeréséhez.
A Microsoft Azure platform bőséges választási lehetőségeket kínál az adatok nagy léptékű feldolgozásához és ML modellek létrehozásához. A felhőplatformokon szinte végtelen, skálázható számítási és tárolási teljesítmény áll rendelkezésre, így ML és AI-modelleket hozhat létre. Így az adatfolyam implementálásakor a leglogikusabb lehetőség az Azure-szolgáltatások használata a modellek létrehozásához.
A modell használata
Ha már rendelkezünk egy ML modellel, egy olyan mechanizmusra van szükségünk, amely felhasználja (vagy "használja" azt) a berendezés karbantartásának szükségességének előrejelzéséhez. Az adatok a berendezéstől való fogadása után egy feldolgozási rétegen haladnak át, hogy előre jelezhesse a jövőbeli meghibásodási eseteket. Ezután különböző eszközöket mutat be a karbantartási csapatok számára.
Az adatok betöltése történhet online az élő érzékelő adatainak a megoldásba való streamelésével, vagy offline is, ha rendszeresen importálja az érzékelőadatokat a megoldásba.
Microsoft Azure platform különféle szolgáltatásokat nyújt az adatok betöltéséhez, feldolgozásához és tárolásához, például:
A ML modell létrehozásának folyamatától eltérően a felhasználása nem igényel sok számítási erőforrást. Az igényeitől függően a modell üzembe helyezhető egy felhőbeli szolgáltatásban, vagy helyileg a gyár szintjén.
A ML modell végrehajtásának két fő alternatívája van: csak helyileg vagy felhőben.
Helyi végrehajtás
A ML modell helyileg lesz felhasználva, míg az adatok a felhőbe kerülnek betöltés, tárolás és további feldolgozás céljából. Ez a lehetőség olyan forgatókönyvekhez ideális, ahol a korai észlelés kritikus fontosságú.
Felhőbeli végrehajtás
A ML modell betöltése, feldolgozása és tárolása, valamint végrehajtása az Azure-felhőben történhet. Ez a lehetőség akkor lehet jobb, ha a ML modell végrehajtásának eredményeit több bérlő vagy földrajzi hely között osztja meg (és ahol a késés nem kritikus). A munka egy részét helyileg is hozzáadhatja egy választható összetevőhöz, amelyet gyakran "peremátjárónak" is neveznek. Ez a munka magában foglalja az adatösszesítést és a leképezést, a streamelemzést stb. A "Nagykövet" mintát követi.
A modell többféleképpen is használható az Azure-ban. Azure Machine Learning webszolgáltatás a legegyszerűbb, és a Azure Machine Learning Studiót használja a modell létrehozásához. Választhatjuk a Azure Machine Learning Modellkezelést is, amely átfogó szolgáltatásokat biztosít a modellek kezeléséhez, valamint REST API-végpontokat biztosít hitelesítési, terheléselosztási, automatikus felskálázási és titkosítási funkciókkal. A modell üzembe helyezhető egyetlen gépen (például Data Science Virtual Machine, IoT-eszközön, helyi PC-n) vagy az Azure Container Service-ben. Miután a modellt egy REST API-val elérhetővé tette, a használatának lehetőségei végtelenek lesznek, az egyéni alkalmazásoktól a vállalati megoldásintegrációig.
A csak felhőalapú üzembe helyezés nem feltétlenül jelenti azt, hogy csak az adatok élő gőzölése lesz elérhető. Egy lehetséges stratégia az adatok rendszeres exportálása egy helyi rendszerből (például egy történészből vagy MES-ből), az adatok a felhőrendszerbe való importálása és az eredmény bemutatása. Ez a lehetőség megvalósítható megközelítés lehet, ha az eszközök nem képesek közvetlenül a rendszerbe adatokat leküldeni, a meglévő rendszerek már gyűjtik az adatokat, vagy nincs szükség közel valós idejű adatfeldolgozásra. Ezekben az esetekben nincs szükség peremhálózati átjáróra.
Prediktív karbantartás az IoT-környezetben
Számos IoT-megoldás betölti és tárolja az adatokat a funkciókészlet részeként. Mivel a prediktív karbantartási megoldások gyakran támaszkodnak az IoT-adatokra, az IoT-megoldások természetes funkciói lehetnek. Ebben a kontextusban kiemelten fontos kiemelni, hogy a meglévő adatokban rögzített hibák fontos szerepet játszanak egy prediktív modell betanítása érdekében.
Egyes használati esetekhez közel valós idejű adatfeldolgozásra van szükség. Ezekben az esetekben nagy adatbetöltési sebességgel rendelkező, méretezhető IoT-megoldásra van szükségünk. A Microsoft Azure platform számos olyan szolgáltatást kínál, amely lehetővé teszi a nagy mértékben skálázható IoT-igények megoldását. A Microsoft Azure platformon futó IoT-megoldásarchitektúrája három fázisban rendelkezik logikai összetevőkkel:
- Eszközkapcsolatok
- Adatfeldolgozás és -elemzés
- Megjelenítés
Az Azure IoT-megoldásarchitektúra részletei elérhetők online. Vannak azonban egyedi kihívások, amelyek a háttérszolgáltatásokhoz csatlakozó eszközök potenciálisan jelentős száma miatt merülhetnek fel.
Adatbetöltés és streamfeldolgozás
Az eszközökről történő adatbeadás két különálló szolgáltatás közötti kommunikáció problémája; azaz az adatokat létrehozó rendszerek (eszközök) és az adatokat feldolgozó rendszerek (azaz a ML modell betanítása, a bejövő adatpontok futtatása a betanított modellen a fennmaradó hasznos élettartam előrejelzése érdekében).
Az elosztott rendszerek definíció szerint különálló összetevőkből állnak, és eredendően szükségük van egymással való kommunikációra. A kommunikáció engedélyezésének egyik lehetősége lehet, hogy a kapcsolódó összetevők közvetlenül kommunikálnak egymással. Ez egy nehezen karbantartható és skálázható rendszert hoz létre. Az összetevők számának növekedésével a kommunikációs kapcsolatok O(n2) összetettségét fogja eredményezni. Jobb megközelítés, ha az adatokat egy közös központba küldik és onnan olvassák be.
Ha új összetevőt injektál az adatbetöltéshez, az skálázhatóbbá teszi a kommunikációt. Ennek az összetevőnek méretezhetőnek, biztonságosnak és valószínűleg globálisan elérhetőnek kell lennie az adatbetöltési folyamat geoparticionálásának lehetőségével.
A prediktív karbantartás figyelembe vétele az IoT-megoldás egyik funkciója. Mivel az adatstreamek az átjárón haladnak át, azokat a prediktív karbantartási funkciókkal kapcsolatos szolgáltatásokhoz kell irányítani. Egy másik megfontolandó minta az átjáró-útválasztás.
Mindkét minta implementálható az Azure-szolgáltatás, a IoT Hub és az Azure Stream Analytics használatával.
Peremhálózati és felhőfeldolgozási együttműködés
Nem minden eszköz és berendezés tud közvetlenül és következetesen hozzáférni az internethez. Előfordulhat, hogy az adataikat egy közös átjáróból kell kinyerni. Az MTConnect-ügynökök például csak REST-felületet biztosítanak az adatok lekéréséhez.
Más szempontok is lehetnek, például a késés, az eszközadatok helyi megtisztításának szükségessége a felhőbe való küldés előtt (több-bérlős esetek), valamint az eszközadatokon végzett leképezések vagy összesítések végrehajtása. A nagykövet minta jó megközelítés ezeknek az igényeknek a kielégítésére. Microsoft Azure IoT Edge egy olyan implementáció, amely proxyként működhet a Microsoft Azure IoT Hub, valamint helyi feldolgozási képességeket biztosíthat a távoli felügyelethez.
Egy gyakori üzembe helyezés tartalmazhat közel valós idejű riasztásokat az üzlethelyiségben, miközben továbbra is megtisztítja és közzéteheti az adatokat egy több-bérlős felhőbeli megoldásban archiválás, modellbetanítás és nem idő szempontjából kritikus jelentéskészítés céljából. Az Azure IoT Edge és IoT Hub képességeivel az ügyfelek szabályozhatják az adatszűrési lehetőségeket a peremeszközön, valamint más üzlethelyiségi rendszerekkel is kommunikálhatnak a riasztások kézbesítéséhez.
Több-bérlős perspektíva
Ahogy korábban említettük, egyes gyártók vagy harmadik felek esetleg prediktív karbantartási szolgáltatásokat szeretnének nyújtani ügyfeleiknek. Ezeket a szolgáltatásokat nagy valószínűséggel több-bérlős felhőbeli üzemelő példányokban fogják kínálni, amelyek a saját kihívásaikat mutatják be:
Adatbiztonság és elkülönítés
A szolgáltatást nyújtó félnek biztosítania kell ügyfelei bizalmas információinak azonosítását és megfelelő biztonságát vagy megtisztítását. Microsoft Azure az adatok titkosítására szolgáló képességeket biztosít a használt tárolási szolgáltatástól függően.
Az eszközök által az adatok előállításának és elküldésének módját is biztonságossá kell tenni, olyan jól ismert módszerekkel, mint az eszközönkénti tanúsítványok, az eszközönkénti engedélyezés/letiltás, a TLS-biztonság, az X.509-támogatás, az IP-engedélyezési/feketelistára vételi és a megosztott hozzáférési szabályzatok. A szolgáltatást nyújtó félnek biztosítania kell az ügyfelek bizalmas információinak azonosítását és megfelelő biztonságát vagy megtisztítását. Az Azure Data Lake Store, az Azure Storage, az Azure Cosmos DB és a Azure SQL Database olyan szolgáltatások, amelyek az inaktív adatok titkosítására használhatók. A megoldásszolgáltatóknak azt is meg kell fontolniuk, hogyan particionálják az adatokat ugyanabban az erőforrásban (például adatbázisban) vagy többen.
Földrajzi szempontok
Valószínű, hogy az adatokat létrehozó eszközök földrajzilag el lesznek szórva. A megoldásnak egy, az adatforráshoz legközelebbi betöltési pontot kell biztosítania. Előfordulhatnak olyan esetek is, amikor a folyamatos kapcsolat problémát jelent, és előfordulhat, hogy az adatokat tömegesen kell beszúrni, vagy helyi tárolási és továbbítási mechanizmusra van szükség.
Méretezhetőség
A ML modellek létrehozásához rugalmasan méretezhető számítási erőforrásokra van szükség. A megoldásszolgáltatónak olyan folyamatokat kell kidolgoznia, amelyek hatékonyan használják a számítási erőforrásokat, és a megoldás igény szerinti skálázásához használják a folyamatokat.
Bérlők kiépítése és biztonságos hozzáférés
A szolgáltatónak ki kell dolgoznia az új bérlők hatékony előkészítésére szolgáló módszereket, és eszközöket kell biztosítania a fiókok önálló kezeléséhez. Ez az a szakasz is, amikor döntést hozunk a kizárólagos vagy megosztott erőforrások üzembe helyezéséről.
A szoftverminőség felülvizsgálatának alappillérei
Az összetett rendszerek a funkcionális követelmények teljesítésén kívül további vizsgálatot igényelnek. A sikeres felhőmegoldások ezen öt pillérre, a méretezhetőségre, a rendelkezésre állásra, a rugalmasságra, a felügyeletre és a biztonságra összpontosítanak. Az öt pillér mellett a megoldás költséghatékonyságát is szeretnénk elérni.
A részletekért tekintse meg az Azure Well-Architected Framework szoftverminőségi alappilléreit .
| Pillér | |
|---|---|
| Méretezhetőség | A legtöbb Azure-szolgáltatás támogatja a vertikális és horizontális skálázási lehetőségeket. Kihasználhatja az erőforrások igény szerinti üzembe helyezésének előnyeit az Azure platformon, és automatizált szolgáltatásokon keresztül szabályozhatja azok méretét (a példányok méretét és számát). |
| Rendelkezésre állás és rugalmasság | A számítási és tárolási erőforrások igény szerint rugalmasan, számos Azure-szolgáltatás használatával építhetők ki. Az összes Azure-szolgáltatás különböző szintű SLA-kat biztosít, azonban a megoldásoknak a megfelelő tervezési alapelvek alkalmazásával figyelembe kell venniük és ki kell használniuk az SLA-szinteket. |
| Kezelés | Az Azure-erőforrások különböző eszközökkel helyezhetők üzembe és kezelhetők, például ARM-sablonokkal, parancssori eszközökkel, PowerShell-parancsmagokkal és Azure Management API-kkal. Fontolja meg automatizált megoldások létrehozását az Azure-erőforrások kezelésekor a felhasználói felülettel rendelkező eszközök használata helyett. |
| Biztonság | Azure IoT Hub támogatja a szimmetrikus és aszimmetrikus kulcsokat (X509-tanúsítványok és TPM) TLS-en keresztül. Az adattárak identitás- és hozzáférés-kezelési (IAM) beállításokkal vannak védve, és az inaktív adatok titkosítását is támogatják. Általános, magas szintű biztonsági ellenőrzőlistaként érdemes lehet áttekinteni az engedélyezési, hitelesítési, átviteli és inaktív állapotú titkosítási és naplózási mechanizmusokat. |
| Költséghatékony. | Szükség esetén fontolja meg az erőforrások kiépítését és elvetését, ha az automatizálás nem használja őket. |
Összegzés
A prediktív karbantartás már régóta vita tárgya. Az olyan felhőplatformok közelmúltbeli fejlesztései, mint Microsoft Azure lehetővé teszik a prediktív karbantartás implementálói számára, hogy leküzdjék a múltban az adatok kezelése során jelentkező számos akadályt. A számítási és tárolási kapacitás rugalmas skálázásával a felhőplatformok új lehetőségeket kínálnak a prediktív karbantartás megvalósítására, valamint új bevételi lehetőségeket is kínálnak. A Microsoft Azure platformja számos különböző képességet kínál a prediktív karbantartási megoldás üzleti céljainak eléréséhez. Ez a cikk elképzelést nyújtott az adatok gyűjtéséről és az adatmodellek betanításáról, valamint a betanított modell használatáról az előző szakaszokban előrejelzett eredmények alapján.
Következő lépések
- Jövőközpontú: Ne gondolkodjon a múltban, és előrébb járjon a váratlan IoT-vel
- A berendezések megbízhatóságának növelése IoT-kompatibilis prediktív karbantartással
- Érték rögzítése az eszközök internetes hálózatából: Prediktív karbantartási projekt megközelítése
- Partneri perspektívák: Prediktív karbantartás az előtérvonalakon
- A árucikk-készítéstől a servitizálásig: A vállalkozás átalakítása az IoT-vel való versenyre a helyszíni szolgáltatás új korszakában