Szia Habr! Csapatunk az ország egész területén felügyeli a gépeket és a különféle telepítéseket. Lényegében lehetőséget adunk arra, hogy a gyártónak ne kelljen még egyszer mérnököt küldenie, amikor „jaj, minden elromlott”, hanem a valóságban csak egy gombot kell megnyomnia. Vagy amikor nem a berendezésen ment tönkre, hanem a közelben.
Az alapvető probléma a következő. Itt egy olajkrakkoló egységet, vagy gépi szerszámgépet, vagy valamilyen más berendezést állít elő egy üzem számára. Maga az eladás általában rendkívül ritkán lehetséges: általában árubeszerzési és szolgáltatási szerződésről van szó. Vagyis Ön garantálja, hogy a hardver 10 évig megszakítás nélkül fog működni, és a megszakításokért vagy anyagi felelősséggel, vagy szigorú SLA-k megkötésével, vagy valami hasonlóval.
Valójában ez azt jelenti, hogy rendszeresen mérnököt kell küldenie a helyszínre. Amint azt gyakorlatunk mutatja, az utazások 30-80%-a szükségtelen. Az első eset - távolról ki lehet deríteni, mi történt. Vagy kérje meg a kezelőt, hogy nyomjon meg néhány gombot, és minden működni fog. A második eset a „szürke” sémák. Ilyenkor kimegy egy mérnök, ütemezi a cserét vagy az összetett munkát, majd a kompenzációt felére osztja valakivel a gyárból. Vagy egyszerűen csak élvezi a nyaralását a szeretőjével (valós eset), és ezért szeret gyakrabban kimenni. A növény nem bánja.
A monitorozás telepítéséhez szükség van a hardver módosítására adatátviteli eszközzel, maga az átvitel, valamilyen adattó a tárolására, elemzési protokollok és egy feldolgozó környezet, amely mindent megtekinthet és összehasonlíthat. Nos, ennek az egésznek vannak árnyalatai.
Miért nem nélkülözhetjük a távfelügyeletet?
Borzasztóan drága. Üzleti út egy mérnök számára - legalább 50 ezer rubel (repülőgép, szálloda, szállás, napidíj). Ráadásul nem mindig lehet szakítani, és ugyanarra a személyre lehet szükség különböző városokban.
- Oroszországban a szállító és a fogyasztó szinte mindig meglehetősen távol van egymástól. Amikor elad egy terméket Szibériának, semmit sem tud róla, csak azt, amit a szállító mond. Sem az, hogy hogyan működik, milyen körülmények között használják, sem az, hogy ki melyik gombot nyomta meg ferde kézzel - objektíve nem rendelkezik ezzel az információval, csak a fogyasztó szavaiból tudhatja meg. Ez nagyon megnehezíti a karbantartást.
- Alaptalan fellebbezések és követelések. Vagyis az Ön termékét használó vásárlója bármikor felhívhat, írhat, reklamálhat és elmondhatja, hogy a terméke nem működik, rossz, elromlott, sürgősen jöjjön és javítsa meg. Ha szerencséd van, és nem csak arról van szó, hogy „nem voltak feltöltve a fogyóeszközök”, akkor nem hiába küldött szakembert. Gyakran előfordul, hogy a hasznos munka kevesebb mint egy órát vett igénybe, és minden más - üzleti út előkészítése, repülőjáratok, szállás - mindez sok időt igényelt a mérnöktől.
- Vannak egyértelműen megalapozatlan követelések, ennek bizonyításához mérnököt kell küldeni, jegyzőkönyvet kell készíteni, és bírósághoz kell fordulni. Emiatt a folyamat késik, és ez nem hoz semmi jót sem az ügyfélnek, sem Önnek.
- Jogviták abból fakadnak, hogy például az ügyfél helytelenül üzemeltette a terméket, a vásárló valamilyen okból haragszik Önre, és nem mondja ki, hogy az Ön terméke nem működött megfelelően, nem a műszaki leírásban szereplő üzemmódokban, ill. az útlevélben. Ugyanakkor nem tudsz ellene tenni, vagy tehetsz, csak nehezen, ha például a terméked valahogy naplózza és rögzíti azokat a módokat. Meghibásodások az ügyfél hibájából – ez mindig előfordul. Volt olyan esetem, amikor egy drága német portálgép egy oszlopnak ütközés miatt elromlott. A kezelő nem állította nullára, ennek következtében a gép ott állt meg. Sőt, az ügyfél egészen világosan kijelentette: "Semmi közünk hozzá." De az információ naplózásra került, és meg lehetett nézni ezeket a naplókat, és megérteni, hogy melyik vezérlőprogramot használták, és aminek eredményeként ez az ütközés történt. Ezzel a beszállító nagyon sok garanciális javítási költséget takarított meg.
- Az említett „szürke” sémák összeesküvés a szolgáltatóval. Mindig ugyanaz a szerviztechnikus megy az ügyfélhez. Azt mondják neki: „Figyelj, Kolja, csináljuk úgy, ahogy akarod: írd, hogy itt minden elromlott, kártérítést kapunk, vagy hozol valami cipzárt javításra. Mindezt csendben megvalósítjuk, a pénzt elosztjuk.” Nem marad más hátra, mint hinni, vagy valahogy kitalálni néhány bonyolult módszert mindezen következtetések és megerősítések ellenőrzésére, ami nem jár hozzá sem időhöz, sem ideghez, és ebben semmi jó nem történik. Ha tisztában van azzal, hogy az autószervizek hogyan kezelik a garanciális csalásokat, és ez mekkora bonyolultságot jelent a folyamatokban, akkor nagyjából megérti a problémát.
Nos, az eszközök továbbra is naplókat írnak, igaz? Mi a probléma?
A probléma az, hogy ha a beszállítók többé-kevésbé megértik, hogy a naplót folyamatosan írni kell valahova (vagy megértették az elmúlt évtizedekben), akkor a kultúra nem ment tovább. A naplóra gyakran szükség van a költséges javításokkal járó esetek elemzéséhez – akár kezelői hibáról, akár valódi berendezés meghibásodásról van szó.
Egy rönk felvételéhez gyakran fizikailag kell megközelíteni a berendezést, fel kell nyitni valamilyen burkolatot, szabaddá tenni a szervizcsatlakozót, kábelt kell csatlakoztatni hozzá és adatfájlokat kell felvenni. Aztán kitartóan ragadd meg őket több órán keresztül, hogy képet kapj a helyzetről. Sajnos ez szinte mindenhol előfordul (jó, vagy egyoldalú az álláspontom, hiszen pont azokkal az iparágakkal dolgozunk, ahol a monitoring még csak kialakulóban van).
Fő ügyfeleink a berendezésgyártók. Jellemzően elkezdenek gondolkodni valamiféle monitorozáson, akár egy nagyobb incidens után, akár csak az év utazási számláit nézik meg. De leggyakrabban súlyos kudarcról beszélünk, amely pénz- vagy hírnévvesztéssel jár. Ritkán fordulnak elő olyan haladó vezetők, akik arra gondolnak, hogy „bármi történjen”. Az a helyzet, hogy általában a menedzser megkapja a szervizszerződések régi „parkját”, és nem látja értelmét új hardverre szerelni szenzorokat, mert arra csak pár év múlva lesz szükség.
Általában egy ponton a sült kakas még mindig harap, és eljön az ideje a módosításoknak.
Maga az adatátvitel nem túl ijesztő. A berendezésben általában már vannak érzékelők (vagy elég gyorsan telepítik), plusz a naplók már meg vannak írva, és a szervizesemények fel vannak jegyezve. Mindössze annyit kell tennie, hogy elkezdi küldeni. Az általános gyakorlat az, hogy valamilyen modemet, például beágyazott SIM-kártyával közvetlenül a készülékbe helyeznek a röntgenkészülékből az automatikus vetőgépbe, és a mobilhálózaton keresztül telemetriát küldenek. Azok a helyek, ahol nincs sejtlefedettség, általában meglehetősen távol vannak, és az elmúlt években ritkasággá váltak.
És akkor ugyanaz a kérdés kezdődik, mint korábban. Igen, most vannak naplók. De el kell őket helyezni valahova, és valahogy el kell olvasni. Általában szükség van valamilyen rendszerre az események megjelenítésére és elemzésére.
És akkor megjelenünk a színpadon. Pontosabban, gyakran jelentkezünk korábban, mert a beszállítói vezetők megnézik, mit csinálnak kollégáik, és azonnal hozzánk fordulnak tanácsért a telemetria küldéséhez szükséges hardver kiválasztásához.
Piaci rés
Nyugaton ennek a helyzetnek a megoldása három lehetőségből adódik: a Siemens ökoszisztéma (nagyon drága, nagyon nagy egységekhez kell, általában, mint a turbinák), saját maga által írt mandulák, vagy valamelyik helyi integrátor segít. Ennek eredményeként, amikor mindez az orosz piacra került, kialakult egy olyan környezet, ahol ott volt a Siemens az ökoszisztéma darabjaival, az Amazon, a Nokia és számos helyi ökoszisztéma, például az 1C fejlesztések.
Egyesítő láncszemként léptünk be a piacra, amely lehetővé teszi, hogy bármilyen (na jó, szinte bármilyen többé-kevésbé modern) protokoll segítségével bármilyen eszközről bármilyen adatot összegyűjtsünk, azokat együtt feldolgozzuk és az embernek tetszőleges formában megmutassuk. menő SDK-k mindenki számára fejlesztői környezetekhez és vizuális felhasználói felület tervezőhöz.
Ennek eredményeként minden adatot összegyűjthetünk a gyártó eszközéről, tárolhatjuk a szerveren, és ott összeállíthatunk egy riasztásokat tartalmazó felügyeleti panelt.
Így néz ki (itt az ügyfél vizualizációt is készített a vállalkozásról, ez több óra a felületen):
És vannak grafikonok a berendezésről:
A riasztások így néznek ki: gépszinten, ha a végrehajtó szervre nehezedő erőt túllépték, vagy ütközés történt, egy paraméterkészletet konfigurálnak, és a rendszer értesíti az osztályt vagy a javítószolgálatot, ha ezek túllépik.
Nos, a legnehezebb dolog a csomópontok meghibásodásának előrejelzése a megelőzés szempontjából. Ha megérti az egyes csomópontok erőforrásait, akkor nagymértékben csökkentheti a költségeket azokon a szerződéseken, amelyeknél fizetni kell az állásidőért.
Összegzés
Ez a történet egészen egyszerűen hangzana: nos, rájöttünk, hogy adatokat, monitorozást és elemzést kell küldenünk, ezért kiválasztottunk egy szállítót és megvalósítottuk. Hát ennyi, mindenki boldog. Ha a saját gyárunkban saját kezűleg írt rendszerekről beszélünk, akkor furcsa módon a rendszerek hamar megbízhatatlanná válnak. A naplók banális elvesztéséről, pontatlan adatokról, gyűjtési, tárolási és átvételi hibákról beszélünk. Egy-két évvel a telepítés után a régi naplók törlődnek, ami szintén nem mindig végződik jól. Bár van gyakorlat - évente 10 GB-ot gyűjtenek egy gépről. Ezt öt évre megoldják egy másik merevlemez vásárlásával 10 ezer rubelért... Egy ponton kiderül, hogy nem maga az adóberendezés az elsődleges, hanem a rendszer, amely lehetővé teszi a kapott adatok elemzését. Fontos az interfész kényelme. Általában ez a probléma minden ipari rendszerrel: a helyzet gyors megértése nem mindig könnyű. Fontos, hogy mennyi adat látható a rendszerben, a csomópontból érkező paraméterek száma, a rendszer képes-e nagy mennyiségű és adatmennyiséggel működni. Műszerfalak beállítása, magának az eszköznek a beépített modellje, jelenetszerkesztő (gyártási elrendezések rajzolásához).
Nézzünk néhány példát arra, hogy ez mit ad a gyakorlatban.
- Itt található az elsősorban kiskereskedelmi láncokban használt ipari hűtőberendezések globális gyártója. A cég bevételének 10%-a termékei szervizeléséhez nyújtott szolgáltatásokból származik. Csökkenteni kell a szolgáltatások költségeit, és általában lehetőséget kell adni a kínálat normális növelésére, mert ha többet adunk el, akkor a meglévő szolgáltatási rendszer nem fog megbirkózni. Közvetlenül egyetlen szervizközpont platformjához csatlakoztunk, néhány modult módosítottunk az adott ügyfél igényei szerint, és 35%-os utazási költségcsökkentést kaptunk, mivel a szolgáltatási információkhoz való hozzáférés lehetővé teszi az okok azonosítását. meghibásodás esetén, anélkül, hogy szervizmérnöknek kellene felkeresnie. Adatok elemzése hosszú időn keresztül - előre jelezni a műszaki állapotot, és szükség esetén gyorsan elvégezni az állapot alapú karbantartást. Bónuszként megnőtt a kérésekre adott válaszadási sebesség: kevesebb a terepbejárás, és a mérnökök gyorsabban tudják elintézni a dolgokat.
- Gépészmérnöki vállalat, az Orosz Föderáció és a FÁK számos városában használt elektromos járművek gyártója. Mint mindenki, ők is csökkenteni szeretnék a költségeket, és egyben előre jelezni a város trolibusz- és villamosparkjának műszaki állapotát, hogy időben értesítsék a műszaki személyzetet. Összekapcsoltuk és elkészítettük a műszaki adatok összegyűjtésére és továbbítására szolgáló algoritmusokat a gördülőállományból egyetlen helyzetközpontba (az algoritmusok közvetlenül a hajtásvezérlő rendszerbe vannak beépítve, és CAN-busz-adatokkal működnek). A műszaki állapotadatokhoz való távoli hozzáférés, beleértve a változó paraméterek (sebesség, feszültség, visszanyert energia átvitele stb.) valós idejű hozzáférését „oszcilloszkóp” módban, hozzáférést biztosított a távoli firmware-frissítésekhez. Az eredmény az utazási költségek 50%-os csökkenése: a szervizinformációkhoz való közvetlen hozzáférés lehetővé teszi a hiba okainak azonosítását anélkül, hogy szervizmérnök látogatása lenne, az adatok hosszú időintervallumon keresztüli elemzése pedig lehetővé teszi a meghibásodások előrejelzését. műszaki állapot és szükség esetén gyorsan „állapot alapú” karbantartás elvégzése, beleértve a veszélyhelyzetek objektív elemzését is. Meghosszabbított életciklusú szerződések végrehajtása a Megrendelő igényeinek megfelelően és határidőre. Az üzemeltető műszaki előírásainak való megfelelés, valamint új lehetőségek biztosítása számára a fogyasztói szolgáltatás jellemzőinek (klíma minősége, gyorsítás/fékezés stb.) figyelemmel kísérése terén.
- A harmadik példa egy önkormányzat. Meg kell takarítanunk az áramot és javítanunk kell az állampolgárok biztonságát. Egyetlen platformot kapcsoltunk össze a csatlakoztatott közvilágítás figyelésére, kezelésére és adatgyűjtésre, a teljes közvilágítási infrastruktúra távoli menedzselésére és egyetlen központról történő kiszolgálására, megoldást nyújtva az alábbi feladatokra. Jellemzők: a lámpák távoli, egyéni vagy csoportos tompítása vagy be-/kikapcsolása, automatikusan értesíti a városi szolgáltatásokat a világítási pontok meghibásodásairól a hatékonyabb karbantartási tervezés érdekében, valós idejű energiafogyasztási adatok biztosítása, hatékony elemző eszközök biztosítása az utcai világítás figyeléséhez és javításához Big Data alapú rendszer, amely adatokat szolgáltat a forgalomról, légkondicionálásról, más Smart City alrendszerekkel való integrációról. Eredmények - az utcai világítás energiafogyasztásának akár 80%-os csökkenése, a lakók biztonságának növelése intelligens világításvezérlő algoritmusok használatával (az utcán sétáló személy - felkapcsolja neki a lámpát, egy személy az átkelőhelyen - világosabbra kapcsol világítás, hogy messziről is látható legyen), a város kiegészítő szolgáltatásainak biztosítása (villamos járművek töltése, reklámtartalom biztosítása, videó megfigyelés stb.).
Tulajdonképpen amit mondani akartam: ma már egy kész platformmal (pl. a miénk) nagyon gyorsan és egyszerűen be lehet állítani a monitorozást. Ez nem igényel felszerelést (vagy minimálisat, ha még mindig nincs szenzor és adatátvitel), nem igényel megvalósítási költségeket és külön szakembereket. Csak tanulmányoznia kell a kérdést, el kell töltenie néhány napot a működésének megértésével, és néhány hetet a jóváhagyásokra, a megállapodásra és a protokollokkal kapcsolatos adatcserére. És ezt követően minden eszközről pontos adatok lesznek. Mindez pedig a Technoserv integrátor támogatásával országszerte megtehető, vagyis egy startupra nem jellemző jó szintű megbízhatóságot garantálunk.
A következő bejegyzésben egy megvalósítás példáján mutatom meg, hogyan is néz ki ez a beszállítói oldalról.
Forrás: will.com