Dobrý den, Habr! Náš tým monitoruje stroje a různé instalace po celé republice. V zásadě poskytujeme výrobci příležitost, aby nemusel znovu posílat inženýra, když „no, je to všechno rozbité“, ale ve skutečnosti stačí stisknout jedno tlačítko. Nebo když se porouchala ne na zařízení, ale poblíž.
Základní problém je následující. Zde vyrábíte jednotku na krakování oleje nebo obráběcí stroj pro strojírenství nebo jiné zařízení pro závod. Samotný prodej je zpravidla možný jen velmi zřídka: obvykle se jedná o zakázku na dodávky a služby. To znamená, že zaručujete, že daný kus hardwaru bude fungovat 10 let bez přerušení a za přerušení nesete odpovědnost buď finančně, nebo poskytnete přísné smlouvy SLA nebo něco podobného.
Ve skutečnosti to znamená, že musíte na web pravidelně posílat inženýra. Jak ukazuje naše praxe, 30 až 80 % výjezdů je zbytečných. První případ – na dálku by bylo možné zjistit, co se stalo. Nebo požádejte operátora, aby stiskl několik tlačítek a vše bude fungovat. Druhým případem jsou „šedá“ schémata. To je, když inženýr odjede, naplánuje výměnu nebo složitou práci a pak si s někým z továrny rozdělí náhradu na polovinu. Nebo si prostě užívá dovolenou s milenkou (skutečný případ) a proto rád chodí častěji ven. Rostlině to nevadí.
Instalace monitoringu vyžaduje úpravu hardwaru o zařízení pro přenos dat, samotný přenos, nějaké to datové jezero pro jejich uložení, parsovací protokoly a prostředí pro zpracování s možností vše prohlížet a porovnávat. No, v tom všem jsou nuance.
Proč se neobejdeme bez vzdáleného sledování?
Je to otřesně drahé. Služební cesta pro jednoho inženýra - nejméně 50 tisíc rublů (letadlo, hotel, ubytování, denní příspěvek). Navíc není vždy možné se rozejít a stejná osoba může být potřebná v různých městech.
- V Rusku jsou dodavatel a spotřebitel téměř vždy poměrně daleko od sebe. Když prodáváte produkt na Sibiř, nevíte o něm nic kromě toho, co vám řekne dodavatel. Ani to, jak to funguje, ani v jakých podmínkách se to používá a vlastně ani to, kdo stiskl jaké tlačítko s křivýma rukama - tyhle informace objektivně nemáte, můžete je poznat jen ze slov spotřebitele. To velmi ztěžuje údržbu.
- Nedůvodná odvolání a nároky. To znamená, že váš zákazník, který váš produkt používá, vám může kdykoli zavolat, napsat, stěžovat si a říct, že váš produkt nefunguje, je špatný, je rozbitý, urychleně přijet a opravit ho. Pokud máte štěstí a není to jen „spotřební materiál nebyl naplněn“, pak jste neposlali odborníka nadarmo. Často se stává, že užitečná práce trvala méně než hodinu a vše ostatní - příprava služební cesty, lety, ubytování - to vše vyžadovalo spoustu času inženýra.
- Existují zjevně nepodložené nároky, a abyste to dokázali, musíte poslat inženýra, vypracovat zprávu a obrátit se na soud. V důsledku toho se proces zpožďuje a to nepřináší nic dobrého ani pro zákazníka, ani pro vás.
- Spory vznikají z toho důvodu, že např. zákazník nesprávně obsluhoval produkt, zákazník má vůči Vám z nějakého důvodu zášť a netvrdí, že Váš produkt nefungoval správně, ne v režimech uvedených v technických specifikacích a v pase. Zároveň proti tomu nemůžete nic dělat, nebo můžete, ale s obtížemi, pokud například váš produkt ty režimy nějak loguje a zaznamenává. Poruchy vinou zákazníka – to se děje neustále. Měl jsem případ, kdy se kvůli srážce se sloupem rozbil drahý německý portálový stroj. Obsluha ji nenastavila na nulu a v důsledku toho se tam stroj zastavil. Zákazník navíc zcela jasně řekl: „My s tím nemáme nic společného.“ Ale informace byly protokolovány a bylo možné tyto protokoly vyhledat a pochopit, který řídicí program byl použit a v důsledku čehož došlo k této kolizi. To dodavateli ušetřilo velmi vysoké náklady na záruční opravy.
- Zmíněná „šedá“ schémata jsou konspirací s poskytovatelem služeb. K zákazníkovi chodí stále stejný servisní technik. Říkají mu: „Poslouchej, Koljo, udělejme to, jak chceš: napíšeš, že je tady všechno rozbité, dostaneme náhradu, nebo přineseš nějaký zip na opravu. To vše v tichosti zrealizujeme, peníze rozdělíme.“ Nezbývá než věřit, nebo nějak složitě vymýšlet, jak všechny tyto závěry a potvrzení ověřit, což nepřidá čas ani nervy a nic dobrého se v tom neděje. Pokud jste obeznámeni s tím, jak se autoservisy vypořádávají se záručními podvody a jak velkou složitost to ukládá procesům, pak tomuto problému zhruba rozumíte.
Zařízení stále zapisují protokoly, že? Co je za problém?
Problém je v tom, že pokud dodavatelé víceméně chápou, že log je potřeba neustále někam zapisovat (nebo tomu v posledních desetiletích rozuměli), pak kultura nešla dál. Protokol je často potřebný k analýze případů s nákladnými opravami – ať už šlo o chybu operátora nebo skutečnou poruchu zařízení.
Abyste mohli vyzvednout protokol, musíte se často fyzicky přiblížit k zařízení, otevřít nějaké pouzdro, odkrýt servisní konektor, připojit k němu kabel a vyzvednout datové soubory. Pak je vytrvale chytejte několik hodin, abyste si udělali obrázek o situaci. Bohužel, to se stává téměř všude (no, buď mám jednostranný pohled, protože pracujeme právě s těmi odvětvími, kde se monitoring teprve zavádí).
Našimi hlavními klienty jsou výrobci zařízení. Obvykle začnou přemýšlet o tom, že by provedli nějaký druh monitorování, buď po velkém incidentu, nebo se jen podívají na své cestovní účty za daný rok. Častěji ale mluvíme o velkém selhání se ztrátou peněz nebo reputace. Progresivní vůdci, kteří přemýšlejí o tom, „ať se stane cokoliv“, jsou vzácní. Faktem je, že obvykle manažer dostane starý „park“ servisních smluv a nevidí smysl v instalaci senzorů na nový hardware, protože to bude potřeba až za pár let.
Obecně platí, že v určitém okamžiku pečený kohout stále kouše a přichází čas na úpravy.
Samotný přenos dat není příliš děsivý. Zařízení obvykle již má senzory (nebo jsou instalovány poměrně rychle), plus jsou již zapsány protokoly a zaznamenány servisní události. Vše, co musíte udělat, je začít odesílat. Obecnou praxí je vložit nějaký druh modemu, například s embed-SIM, přímo do zařízení z rentgenového přístroje do automatického secího stroje a odeslat telemetrii přes mobilní síť. Místa, kde není pokrytí buňkou, jsou obvykle dost daleko a v posledních letech jsou vzácná.
A pak začíná stejná otázka jako předtím. Ano, nyní existují protokoly. Ale je potřeba je někam dát a nějak číst. Obecně je potřeba nějaký systém pro vizualizaci a analýzu incidentů.
A pak se objevíme na pódiu. Přesněji řečeno, často se objevíme dříve, protože manažeři dodavatelů se dívají na to, co dělají jejich kolegové, a hned se k nám chodí poradit s výběrem hardwaru pro odesílání telemetrie.
Mezeru na trhu
Na Západě se způsob, jak tuto situaci vyřešit, sestává ze tří možností: ekosystém Siemens (velmi drahý, potřebný pro velmi velké jednotky, obvykle jako turbíny), vlastnoručně napsané mandule nebo pomůže některý z místních integrátorů. Výsledkem bylo, že když to všechno přišlo na ruský trh, vytvořilo se prostředí, kde byl Siemens se svými kousky ekosystému, Amazon, Nokia a několik místních ekosystémů, jako je vývoj 1C.
Vstoupili jsme na trh jako sjednocující článek, který nám umožňuje shromažďovat jakákoli data z jakýchkoli zařízení pomocí jakýchkoli (dobře, téměř jakýchkoli více či méně moderních) protokolů, zpracovávat je společně a ukazovat je osobě v jakékoli požadované podobě: k tomu máme skvělé sady SDK pro každého vývojová prostředí a návrháře vizuálního uživatelského rozhraní.
Díky tomu můžeme shromáždit všechna data ze zařízení výrobce, uložit je do úložiště na serveru a tam sestavit monitorovací panel s upozorněními.
Takto to vypadá (zde si zákazník také udělal vizualizaci podniku, toto je několik hodin v rozhraní):
A tam jsou grafy z vybavení:
Upozornění vypadají takto: na úrovni stroje, pokud byla překročena síla působící na výkonný orgán nebo došlo ke kolizi, je nakonfigurována sada parametrů a systém o jejich překročení informuje oddělení nebo opravny.
No, nejtěžší je předpovědět selhání uzlů na základě jejich stavu pro prevenci. Pokud rozumíte zdrojům každého z uzlů, můžete výrazně snížit náklady na smlouvy, kde se platí za prostoje.
Shrnutí
Tento příběh by zněl docela jednoduše: dobře, uvědomili jsme si, že potřebujeme posílat data, monitorování a analýzy, a tak jsme vybrali dodavatele a implementovali to. No a je to, všichni jsou šťastní. Pokud mluvíme o systémech s vlastním zápisem v naší vlastní továrně, pak se kupodivu tyto systémy rychle stanou nespolehlivé. Hovoříme o banální ztrátě protokolů, nepřesných datech, selhání při sběru, skladování a příjmu. Rok nebo dva po instalaci se začnou mazat staré logy, což také ne vždy skončí dobře. I když existuje praxe - z jednoho stroje se vybere 10 GB za rok. To se na pět let řeší nákupem dalšího pevného disku za 10 tisíc rublů... V určité chvíli se ukazuje, že primární není samotné vysílací zařízení, ale systém, který umožňuje analyzovat přijatá data. Pohodlí rozhraní je důležité. To je obecně problém všech průmyslových systémů: rychlé pochopení situace není vždy snadné. Je důležité, kolik dat je v systému vidět, počet parametrů z uzlu, schopnost systému pracovat s velkým objemem a množstvím dat. Nastavení dashboardů, vestavěný model samotného zařízení, editor scén (pro kreslení produkčních layoutů).
Uveďme si pár příkladů toho, co to dává v praxi.
- Zde je světový výrobce průmyslových chladicích zařízení používaných především v obchodních řetězcích. 10 % příjmů společnosti pochází z poskytování služeb pro servis jejích produktů. Je potřeba zlevnit služby a obecně dát možnost normálně navýšit dodávky, protože když prodáme více, stávající systém služeb to nezvládne. Připojili jsme se přímo na platformu jednoho servisního centra, upravili jsme několik modulů pro potřeby tohoto konkrétního zákazníka a získali jsme 35% snížení cestovních nákladů díky tomu, že přístup k servisním informacím umožňuje identifikovat příčiny selhání bez nutnosti návštěvy servisního technika. Analýza dat za dlouhá časová období – předvídat technický stav a v případě potřeby rychle provádět údržbu na základě stavu. Jako bonus se zvýšila rychlost odezvy na požadavky: je méně výjezdů do terénu a inženýři jsou schopni dělat věci rychleji.
- Strojírenská společnost, výrobce elektrických vozidel používaných v mnoha městech Ruské federace a SNS. Stejně jako všichni ostatní chtějí snižovat náklady a zároveň předvídat technický stav vozového parku trolejbusů a tramvají ve městě, aby včas informovali technický personál. Propojili jsme a vytvořili algoritmy pro sběr a přenos technických dat z kolejových vozidel do jednoho situačního centra (algoritmy jsou zabudovány přímo do řídicího systému pohonu a pracují s daty sběrnice CAN). Vzdálený přístup k údajům o technickém stavu, včetně přístupu k měnícím se parametrům (rychlost, napětí, přenos rekuperované energie atd.) v reálném čase v režimu „osciloskopu“, umožnil přístup ke vzdáleným aktualizacím firmwaru. Výsledkem je snížení cestovních nákladů o 50 %: přímý přístup k servisním informacím umožňuje identifikovat příčiny selhání bez nutnosti návštěvy servisního technika a analýza dat v dlouhých časových intervalech umožňuje předvídat technický stav a v případě potřeby rychle provést „stavovou“ údržbu včetně objektivní analýzy havarijních situací. Implementace smluv s prodlouženým životním cyklem plně v souladu s požadavky zákazníka a včas. Splnění požadavků technických specifikací provozovatele a poskytnutí nových příležitostí, pokud jde o sledování charakteristik spotřebitelského servisu (kvalita klimatizace, zrychlení/brždění atd.).
- Třetím příkladem je obec. Musíme šetřit elektřinou a zlepšit bezpečnost občanů. Propojili jsme jednotnou platformu pro monitorování, správu a sběr dat o připojeném pouličním osvětlení, vzdálenou správu celé infrastruktury veřejného osvětlení a její obsluhu z jednoho ovládacího panelu, poskytující řešení následujících úkolů. Funkce: stmívání nebo zapínání/vypínání světel na dálku, jednotlivě nebo ve skupinách, automatické upozorňování městských služeb na poruchy v osvětlovacích bodech pro efektivnější plánování údržby, poskytování údajů o spotřebě energie v reálném čase, poskytování výkonných analytických nástrojů pro monitorování a zlepšování veřejného osvětlení systém založený na Big Data, poskytující data o provozu, klimatizaci, integraci s dalšími subsystémy Smart City. Výsledky – snížení spotřeby energie na pouliční osvětlení až o 80 %, zvýšení bezpečnosti obyvatel pomocí inteligentních algoritmů řízení osvětlení (člověk jdoucí po ulici – rozsviť mu světlo, člověk na přechodu – zapnout jasnější osvětlení tak, aby byl z dálky vidět), zajištění doplňkových služeb pro město (nabíjení elektromobilů, poskytování reklamního obsahu, video dohled atd.).
Vlastně to, co jsem chtěl říct: dnes už s hotovou platformou (třeba tou naší) nastavíte monitoring velmi rychle a jednoduše. To nevyžaduje změny ve vybavení (nebo minimální, pokud ještě nejsou senzory a přenos dat), nevyžaduje to náklady na implementaci a samostatné specialisty. Stačí si problém nastudovat, strávit pár dní pochopením toho, jak to funguje, a pár týdnů schvalováním, dohodou a výměnou dat o protokolech. A poté budete mít přesná data ze všech zařízení. A to vše lze s podporou integrátora Technoservu realizovat po celé republice, čili garantujeme dobrou úroveň spolehlivosti, která není pro startup typická.
V příštím příspěvku ukážu, jak to vypadá ze strany dodavatele, na příkladu jedné implementace.
Zdroj: www.habr.com