Hej, Habr! Vores team overvåger maskiner og diverse installationer i hele landet. Grundlæggende giver vi muligheden for, at producenten ikke skal sende en ingeniør rundt igen, når "åh, det hele er i stykker", men i virkeligheden behøver de kun at trykke på én knap. Eller når det gik i stykker ikke på udstyret, men i nærheden.
Det grundlæggende problem er følgende. Her producerer du en oliekrakningsenhed eller en værktøjsmaskine til maskinteknik eller en anden enhed til et anlæg. Som regel er selve salget yderst sjældent muligt: Det er normalt en leverings- og servicekontrakt. Det vil sige, at du garanterer, at stykket hardware vil fungere i 10 år uden afbrydelser, og for afbrydelser er du ansvarlig enten økonomisk, eller leverer strenge SLA'er eller noget lignende.
Faktisk betyder det, at du regelmæssigt skal sende en ingeniør til webstedet. Som vores praksis viser, er fra 30 til 80 % af rejserne unødvendige. Det første tilfælde - det ville være muligt at finde ud af, hvad der skete på afstand. Eller bed operatøren om at trykke på et par knapper, og alt vil virke. Det andet tilfælde er "grå" ordninger. Det er, når en ingeniør går ud, planlægger udskiftning eller komplekst arbejde og derefter deler kompensationen i to med en fra fabrikken. Eller han nyder simpelthen sin ferie med sin elskerinde (et rigtig tilfælde) og går derfor gerne ud oftere. Planten gider ikke.
Installation af overvågning kræver modifikation af hardwaren med en datatransmissionsenhed, selve transmissionen, en form for datasø til lagring af det, parsing af protokoller og et behandlingsmiljø med mulighed for at se og sammenligne alt. Nå, der er nuancer til alt dette.
Hvorfor kan vi ikke undvære fjernovervågning?
Det er banalt dyrt. Forretningsrejse for en ingeniør - mindst 50 tusind rubler (fly, hotel, indkvartering, dagpenge). Derudover er det ikke altid muligt at slå op, og den samme person kan være nødvendig i forskellige byer.
- I Rusland er leverandøren og forbrugeren næsten altid ret langt fra hinanden. Når du sælger et produkt til Sibirien, ved du ikke noget om det, undtagen hvad leverandøren fortæller dig. Hverken hvordan det virker, eller under hvilke forhold det bruges, eller i virkeligheden, hvem der trykkede på hvilken knap med skæve hænder - du har objektivt set ikke denne information, du kan kun kende dem fra forbrugerens ord. Dette gør vedligeholdelsen meget vanskelig.
- Ugrundede klager og krav. Det vil sige, at din kunde, som bruger dit produkt, til enhver tid kan ringe, skrive, klage og sige, at dit produkt ikke virker, det er dårligt, det er gået i stykker, kom akut og fiks det. Hvis du er heldig, og det ikke bare er "forbrugsstofferne var ikke fyldt", så sendte du ikke en specialist forgæves. Det sker ofte, at nyttigt arbejde tog mindre end en time, og alt andet - forberedelse af en forretningsrejse, fly, indkvartering - alt dette krævede meget af ingeniørens tid.
- Der er klart ubegrundede påstande, og for at bevise dette skal du sende en ingeniør, udarbejde en rapport og gå til retten. Som følge heraf er processen forsinket, og det bringer ikke noget godt for hverken kunden eller dig.
- Tvister opstår på grund af det faktum, at kunden for eksempel betjente produktet forkert, kunden af en eller anden grund har et nag til dig og siger ikke, at dit produkt ikke fungerede korrekt, ikke i de tilstande, der er angivet i de tekniske specifikationer og i passet. Samtidig kan du ikke gøre noget imod det, eller du kan, men med besvær, hvis for eksempel dit produkt på en eller anden måde logger og registrerer disse tilstande. Nedbrud på grund af kundens skyld - dette sker hele tiden. Jeg havde et tilfælde, hvor en dyr tysk portalmaskine gik i stykker på grund af en kollision med en stang. Operatøren satte den ikke til nul, og som et resultat stoppede maskinen der. Desuden sagde kunden ganske tydeligt: "Vi har intet med det at gøre." Men oplysningerne blev logget, og det var muligt at slå disse logs op og forstå, hvilket styreprogram, der blev brugt, og som følge heraf netop denne kollision opstod. Dette sparede leverandøren for meget store omkostninger til garantireparationer.
- De nævnte "grå" ordninger er en sammensværgelse med tjenesteudbyderen. Den samme servicetekniker går hele tiden til kunden. De siger til ham: "Hør, Kolya, lad os gøre det, som du vil: du skriver, at alt er gået i stykker her, vi får erstatning, eller du medbringer en slags lynlås til reparation. Vi vil gennemføre alt dette stille og roligt, vi vil dele pengene.” Det eneste, der er tilbage, er enten at tro, eller på en eller anden måde opfinde nogle komplicerede måder at kontrollere alle disse konklusioner og bekræftelser på, som ikke tilføjer nogen tid eller nerver, og der sker ikke noget godt i dette. Hvis du er bekendt med, hvordan bilservice håndterer garantisvig, og hvor meget kompleksitet dette pålægger processer, så forstår du nogenlunde problemet.
Nå, enheder skriver stadig logs, ikke? Hvad er problemet?
Problemet er, at hvis leverandører mere eller mindre forstår, at loggen konstant skal skrives et eller andet sted (eller har forstået det gennem de seneste årtier), så er kulturen ikke nået længere. Loggen er ofte nødvendig for at analysere sager med dyre reparationer - uanset om det var en operatørfejl eller et reelt udstyrsnedbrud.
For at hente en log skal du ofte fysisk henvende dig til udstyret, åbne en form for kabinet, blotlægge servicestikket, tilslutte et kabel til det og hente datafiler. Tag derefter vedholdende fat i dem i flere timer for at få et billede af situationen. Ak, det sker næsten alle steder (jamen, enten har jeg en ensidig holdning, da vi netop arbejder med de brancher, hvor overvågning netop er ved at blive etableret).
Vores primære kunder er udstyrsproducenter. Typisk begynder de at tænke på at lave en form for overvågning, enten efter en større hændelse eller bare kigger på deres rejseregninger for året. Men oftere end ikke taler vi om en stor fiasko med tab af penge eller omdømme. Progressive ledere, der tænker på "hvad der end sker", er sjældne. Faktum er, at lederen normalt får den gamle "park" af servicekontrakter, og han ser ingen mening i at installere sensorer på ny hardware, for det bliver først nødvendigt om et par år.
Generelt bider den stegte hane stadig på et tidspunkt, og tiden kommer til modifikationer.
Dataoverførsel i sig selv er ikke særlig skræmmende. Udstyret har normalt allerede sensorer (eller de installeres ret hurtigt), plus logfiler er allerede skrevet, og servicehændelser er noteret. Alt du skal gøre er at begynde at sende det. Den generelle praksis er at indsætte en form for modem, for eksempel med et embed-SIM, direkte i enheden fra røntgenmaskinen til den automatiske såmaskine og sende telemetri via mobilnetværket. Steder, hvor der ikke er celledækning, er normalt ret langt væk og er blevet sjældne i de senere år.
Og så begynder det samme spørgsmål som før. Ja, der er logs nu. Men de skal sættes et sted og læses på en eller anden måde. Generelt er der brug for en form for system til visualisering og analyse af hændelser.
Og så dukker vi op på scenen. Mere præcist dukker vi ofte op tidligere, fordi leverandørernes ledere ser på, hvad deres kollegaer laver, og straks kommer til os for at få råd om valg af hardware til afsendelse af telemetri.
Markedsniche
I Vesten kommer måden at løse denne situation på tre muligheder: Siemens økosystem (meget dyrt, nødvendigt til meget store enheder, normalt som turbiner), selvskrevne mandler eller en af de lokale integratorer hjælper. Som et resultat, da alt dette kom til det russiske marked, blev der dannet et miljø, hvor der var Siemens med sine dele af økosystemet, Amazon, Nokia og flere lokale økosystemer som 1C-udviklinger.
Vi kom ind på markedet som et samlende link, der giver os mulighed for at indsamle data fra enhver enhed ved hjælp af enhver (okay, næsten alle mere eller mindre moderne) protokoller, behandle dem sammen og vise dem til en person i enhver påkrævet form: til dette har vi fede SDK'er til alle udviklingsmiljøer og visuel brugergrænsefladedesigner.
Som et resultat kan vi indsamle alle data fra producentens enhed, gemme dem på lager på serveren og samle et overvågningspanel med advarsler der.
Sådan ser det ud (her lavede kunden også en visualisering af virksomheden, dette er flere timer i grænsefladen):
Og der er grafer fra udstyret:
Advarsler ser sådan ud: på maskinniveau, hvis kraften på det udøvende organ er blevet overskredet, eller der er sket en kollision, konfigureres et sæt parametre, og systemet vil informere afdelingen eller reparationstjenesterne, når de overskrides.
Nå, det sværeste er at forudsige svigt af noder baseret på deres tilstand for forebyggelse. Hvis du forstår ressourcen for hver af noderne, så kan du i høj grad reducere omkostningerne på de kontrakter, hvor der er betaling for nedetid.
Resumé
Denne historie ville lyde ret simpel: Nå, vi indså, at vi skulle sende data, overvågning og analyse, så vi valgte en leverandør og implementerede den. Nå, det er det, alle er glade. Hvis vi taler om selvskrevne systemer på vores egen fabrik, så bliver systemerne pudsigt nok hurtigt upålidelige. Vi taler om det banale tab af logfiler, unøjagtige data, fejl i indsamling, opbevaring og modtagelse. Et år eller to efter installationen begynder gamle logfiler at blive slettet, hvilket heller ikke altid ender godt. Selvom der er en praksis - indsamles 10 GB fra en maskine om året. Dette løses i fem år ved at købe endnu en harddisk for 10 tusind rubler... På et tidspunkt viser det sig, at det ikke er selve sendeudstyret, der er det primære, men systemet, der gør det muligt at analysere de modtagne data. Grænsefladens bekvemmelighed er vigtig. Dette er generelt problemet med alle industrielle systemer: hurtigt at forstå situationen er ikke altid let. Det er vigtigt, hvor meget data der er synligt i systemet, antallet af parametre fra noden, systemets evne til at operere med en stor mængde og mængde data. Opsætning af dashboards, en indbygget model af selve enheden, en sceneeditor (til tegning af produktionslayout).
Lad os give et par eksempler på, hvad det giver i praksis.
- Her er en global producent af industrielt køleudstyr, der primært bruges i detailkæder. 10% af virksomhedens indtægt kommer fra at levere tjenester til servicering af sine produkter. Det er nødvendigt at reducere omkostningerne til tjenester og generelt give mulighed for at øge udbuddet normalt, for hvis vi sælger mere, vil det eksisterende servicesystem ikke klare sig. Vi koblede direkte til platformen for et enkelt servicecenter, modificerede et par moduler til netop denne kundes behov og fik en reduktion på 35 % i rejseudgifter på grund af det faktum, at adgang til serviceoplysninger gør det muligt at identificere årsagerne fejl uden behov for en servicetekniker til at besøge. Analyse af data over længere tid – forudsige den tekniske tilstand og om nødvendigt hurtigt udfør tilstandsbaseret vedligeholdelse. Som en bonus er reaktionshastigheden på anmodninger steget: Der er færre ekskursioner, og ingeniører er i stand til at få tingene gjort hurtigere.
- Mekanisk ingeniørvirksomhed, producent af elektriske køretøjer, der bruges i mange byer i Den Russiske Føderation og CIS. Som alle andre ønsker de at reducere omkostningerne og samtidig forudsige den tekniske tilstand af byens trolleybus- og sporvognsflåder for at varsle det tekniske personale rettidigt. Vi koblede og skabte algoritmer til indsamling og transmission af tekniske data fra rullende materiel til et enkelt situationscenter (algoritmerne er indbygget direkte i drevets styresystem og arbejder med CAN-bus-data). Fjernadgang til tekniske tilstandsdata, herunder realtidsadgang til skiftende parametre (hastighed, spænding, overførsel af genvundet energi osv.) i "oscilloskop"-tilstand, gav adgang til fjernfirmwareopdateringer. Resultatet er en reduktion i rejseomkostningerne med 50 %: direkte adgang til serviceinformation gør det muligt at identificere årsagerne til fejl, uden at en servicetekniker skal besøge, og analysen af data over lange tidsintervaller giver dig mulighed for at forudsige teknisk stand og om nødvendigt hurtigt udføre ”tilstandsbaseret” vedligeholdelse, herunder objektiv analyse af nødsituationer. Implementering af forlængede livscykluskontrakter i fuld overensstemmelse med Kundens krav og til tiden. Overholdelse af kravene i operatørens tekniske specifikationer samt give ham nye muligheder med hensyn til at overvåge egenskaberne ved forbrugerservice (kvalitet af aircondition, acceleration/bremsning osv.).
- Det tredje eksempel er en kommune. Vi skal spare på strømmen og forbedre borgernes sikkerhed. Vi tilsluttede en enkelt platform til overvågning, styring og indsamling af data om tilsluttet gadebelysning, fjernstyring af hele den offentlige belysningsinfrastruktur og servicering af den fra et enkelt kontrolpanel, hvilket giver løsninger til følgende opgaver. Funktioner: dæmpning eller tænd/sluk for lyset eksternt, individuelt eller i grupper, meddeler automatisk bytjenester om fejl i belysningspunkter for mere effektiv vedligeholdelsesplanlægning, leverer data om energiforbrug i realtid, giver kraftfulde analytiske værktøjer til overvågning og forbedring af gadebelysningen system baseret på Big Data, der leverer data om trafik, luftforhold, integration med andre Smart City-delsystemer. Resultater - reduktion af energiforbruget til gadebelysning med op til 80%, øget sikkerhed for beboere ved brug af intelligente lysstyringsalgoritmer (en person, der går ned ad gaden - tænd lyset for ham, en person ved krydset - tænd lysere belysning, så han kan ses på afstand), sørger for byens ekstra tjenester (opladning af elektriske køretøjer, levering af reklameindhold, videoovervågning osv.).
Faktisk, hvad jeg ville sige: I dag, med en færdiglavet platform (for eksempel vores), kan du konfigurere overvågning meget hurtigt og nemt. Dette kræver ikke ændringer i udstyr (eller minimale, hvis der stadig ikke er sensorer og datatransmission), det kræver ikke implementeringsomkostninger og separate specialister. Du skal blot studere problemet, bruge et par dage på at forstå, hvordan det fungerer, og et par uger på godkendelser, en aftale og udveksling af data om protokoller. Og derefter vil du have nøjagtige data fra alle enheder. Og alt dette kan gøres i hele landet med støtte fra Technoserv-integratoren, det vil sige, at vi garanterer et godt niveau af pålidelighed, hvilket ikke er typisk for en startup.
I det næste indlæg vil jeg vise, hvordan dette ser ud fra leverandørens side, ved at bruge eksemplet på én implementering.
Kilde: www.habr.com