Overvåking av produksjonsutstyr: hvordan går det i Russland?

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Hei, Habr! Vårt team overvåker maskiner og ulike installasjoner over hele landet. I hovedsak gir vi produsenten muligheten til å slippe å sende en ingeniør rundt igjen når "åh, alt er ødelagt", men i virkeligheten trenger de bare å trykke på én knapp. Eller når det gikk i stykker ikke på utstyret, men i nærheten.

Det grunnleggende problemet er følgende. Her produserer du en oljekrakkingsenhet, eller en maskinverktøy for maskinteknikk, eller en annen enhet for et anlegg. Som regel er selve salget ekstremt sjelden mulig: det er vanligvis en leverings- og servicekontrakt. Det vil si at du garanterer at maskinvaren vil fungere i 10 år uten avbrudd, og for avbrudd er du ansvarlig enten økonomisk, eller gir strenge SLAer, eller noe lignende.

Dette betyr faktisk at du regelmessig må sende en ingeniør til nettstedet. Som vår praksis viser, er fra 30 til 80 % av turene unødvendige. Det første tilfellet - det ville være mulig å finne ut hva som skjedde eksternt. Eller be operatøren om å trykke på et par knapper og alt vil fungere. Det andre tilfellet er "grå" ordninger. Dette er når en ingeniør går ut, planlegger utskifting eller komplekst arbeid, og deretter deler kompensasjonen i to med noen fra fabrikken. Eller han nyter rett og slett ferien med elskerinnen sin (en ekte sak) og liker derfor å gå ut oftere. Planten har ikke noe imot det.

Installasjon av overvåking krever modifikasjon av maskinvaren med en dataoverføringsenhet, selve overføringen, en slags datainnsjø for lagring, parsing av protokoller og et prosesseringsmiljø med muligheten til å se og sammenligne alt. Vel, det er nyanser i alt dette.

Hvorfor kan vi ikke klare oss uten fjernovervåking?

Det er kjipt dyrt. Forretningsreise for en ingeniør - minst 50 tusen rubler (fly, hotell, overnatting, dagpenger). Dessuten er det ikke alltid mulig å bryte opp, og samme person kan være nødvendig i forskjellige byer.

  • I Russland er leverandøren og forbrukeren nesten alltid ganske langt fra hverandre. Når du selger et produkt til Sibir, vet du ikke noe om det bortsett fra det leverandøren forteller deg. Verken hvordan det fungerer, eller under hvilke forhold det brukes, eller faktisk hvem som trykket på hvilken knapp med skjeve hender - du har objektivt sett ikke denne informasjonen, du kan bare vite det fra forbrukerens ord. Dette gjør vedlikeholdet svært vanskelig.
  • Ubegrunnede anker og krav. Det vil si at kunden din, som bruker produktet ditt, kan ringe, skrive, klage når som helst og si at produktet ditt ikke fungerer, det er dårlig, det er ødelagt, kom raskt og fiks det. Hvis du er heldig og det ikke bare er "forbruksmateriellet ble ikke fylt", så sendte du ikke en spesialist forgjeves. Det hender ofte at nyttig arbeid tok mindre enn en time, og alt annet - forberede en forretningsreise, flyreiser, overnatting - alt dette krevde mye av ingeniørens tid.
  • Det er helt klart ubegrunnede påstander, og for å bevise dette må du sende en ingeniør, utarbeide en rapport og gå til retten. Som et resultat blir prosessen forsinket, og dette gir ikke noe godt for verken kunden eller deg.
  • Tvister oppstår på grunn av det faktum at for eksempel kunden betjente produktet feil, kunden har av en eller annen grunn et nag til deg og sier ikke at produktet ditt ikke fungerte som det skal, ikke i modusene angitt i de tekniske spesifikasjonene og i passet. Samtidig kan du ikke gjøre noe mot det, eller du kan, men med vanskeligheter, hvis for eksempel produktet ditt logger og registrerer disse modusene. Havari på grunn av kundens feil - dette skjer hele tiden. Jeg hadde et tilfelle der en dyr tysk portalmaskin gikk i stykker på grunn av en kollisjon med en stolpe. Operatøren satte den ikke på null, og som et resultat stoppet maskinen der. Dessuten sa kunden ganske tydelig: "Vi har ingenting med det å gjøre." Men informasjonen ble loggført, og det var mulig å slå opp disse loggene og forstå hvilket kontrollprogram som ble brukt og som et resultat av at nettopp denne kollisjonen skjedde. Dette sparte leverandøren for svært store kostnader til garantireparasjoner.
  • De nevnte "grå" ordningene er en konspirasjon med tjenesteleverandøren. Den samme serviceteknikeren går til kunden hele tiden. De forteller ham: «Hør, Kolya, la oss gjøre det som du vil: du skriver at alt er ødelagt her, vi får erstatning, eller du tar med en slags glidelås for reparasjon. Vi vil gjennomføre alt dette i det stille, vi vil dele pengene.» Alt som gjenstår er enten å tro, eller på en eller annen måte finne på noen kompliserte måter å sjekke alle disse konklusjonene og bekreftelsene på, som ikke tilfører noen tid eller nerver, og ingenting godt skjer i dette. Hvis du er kjent med hvordan biltjenester håndterer garantisvindel og hvor mye kompleksitet dette påfører prosesser, så forstår du omtrent problemet.

Vel, enheter skriver fortsatt logger, ikke sant? Hva er problemet?

Problemet er at hvis leverandørene mer eller mindre forstår at loggen hele tiden må skrives et sted (eller har forstått de siste tiårene), så har ikke kulturen gått lenger. Loggen er ofte nødvendig for å analysere saker med kostbare reparasjoner – enten det var en operatørfeil eller et reelt utstyrshavari.

For å plukke opp en logg må du ofte nærme deg utstyret fysisk, åpne et slags kabinett, avdekke servicekontakten, koble en kabel til den og hente datafiler. Ta dem deretter vedvarende i flere timer for å få et bilde av situasjonen. Akk, dette skjer nesten overalt (vel, enten har jeg et ensidig ståsted, siden vi jobber nettopp med de bransjene hvor overvåking nettopp etableres).

Våre hovedkunder er utstyrsprodusenter. Vanligvis begynner de å tenke på å gjøre en slags overvåking, enten etter en større hendelse eller bare ser på reiseregningene for året. Men oftere enn ikke snakker vi om en stor fiasko med tap av penger eller omdømme. Progressive ledere som tenker på "hva som enn skjer" er sjeldne. Faktum er at lederen vanligvis får den gamle "parken" med servicekontrakter, og han ser ingen vits i å installere sensorer på ny maskinvare, fordi det bare vil være nødvendig om et par år.

Generelt, på et tidspunkt biter den stekte hanen fortsatt, og tiden kommer for modifikasjoner.

Dataoverføring i seg selv er ikke veldig skummelt. Utstyret har vanligvis allerede sensorer (eller de installeres ganske raskt), pluss at logger allerede er skrevet og servicehendelser er notert. Alt du trenger å gjøre er å begynne å sende den. Den generelle praksisen er å sette inn et slags modem, for eksempel med embed-SIM, direkte inn i enheten fra røntgenmaskinen til den automatiske såmaskinen, og sende telemetri via mobilnettet. Steder hvor det ikke er celledekning er vanligvis ganske langt unna og har blitt sjeldne de siste årene.

Og så begynner det samme spørsmålet som før. Ja, det er logger nå. Men de må settes et sted og leses på en eller annen måte. Generelt er det nødvendig med et slags system for å visualisere og analysere hendelser.

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Og så dukker vi opp på scenen. Mer presist dukker vi ofte opp tidligere, fordi leverandørenes ledere ser på hva kollegene deres gjør og umiddelbart kommer til oss for å få råd om valg av maskinvare for sending av telemetri.

Markedsnisje

I Vesten kommer måten å løse denne situasjonen på tre alternativer: Siemens økosystem (veldig dyrt, nødvendig for veldig store enheter, vanligvis som turbiner), selvskrevne mandler, eller en av de lokale integratorene hjelper. Som et resultat, da alt dette kom til det russiske markedet, ble det dannet et miljø hvor det var Siemens med sine deler av økosystemet, Amazon, Nokia og flere lokale økosystemer som 1C-utviklinger.

Vi kom inn på markedet som en samlende lenke som lar oss samle inn data fra alle enheter ved å bruke alle (ok, nesten alle mer eller mindre moderne) protokoller, behandle dem sammen og vise dem til en person i hvilken som helst nødvendig form: for dette har vi kule SDK-er for alle utviklingsmiljøer og visuell brukergrensesnittdesigner.

Som et resultat kan vi samle inn alle dataene fra produsentens enhet, lagre dem i lagring på serveren og sette sammen et overvåkingspanel med varsler der.

Slik ser det ut (her laget kunden også en visualisering av bedriften, dette er flere timer i grensesnittet):

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Og det er grafer fra utstyret:

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Overvåking av produksjonsutstyr: hvordan går det i Russland?

Varsler ser slik ut: på maskinnivå, hvis kraften på det utøvende organet er overskredet eller en kollisjon har skjedd, konfigureres et sett med parametere, og systemet vil informere avdelingen eller reparasjonstjenestene når de overskrides.

Vel, det vanskeligste er å forutsi svikt i noder basert på deres tilstand for forebygging. Hvis du forstår ressursen til hver av nodene, kan du redusere kostnadene betraktelig på de kontraktene der det er en betaling for nedetid.

Oppsummering

Denne historien ville høres ganske enkel ut: Vel, vi innså at vi trengte å sende data, overvåking og analyse, så vi valgte en leverandør og implementerte den. Vel, det er det, alle er glade. Hvis vi snakker om selvskrevne systemer på vår egen fabrikk, så blir systemene merkelig nok raskt upålitelige. Vi snakker om banalt tap av logger, unøyaktige data, feil ved innsamling, lagring og mottak. Et år eller to etter installasjonen begynner gamle logger å bli slettet, noe som heller ikke alltid ender godt. Selv om det er en praksis - 10 GB samles inn fra en maskin per år. Dette løses i fem år ved å kjøpe en annen harddisk for 10 tusen rubler... På et tidspunkt viser det seg at det ikke er selve sendeutstyret som er primært, men systemet som gjør at de mottatte dataene kan analyseres. Bekvemmeligheten til grensesnittet er viktig. Dette er generelt problemet med alle industrielle systemer: raskt å forstå situasjonen er ikke alltid lett. Det er viktig hvor mye data som er synlig i systemet, antall parametere fra noden, systemets evne til å operere med et stort volum og mengde data. Sette opp dashbord, en innebygd modell av selve enheten, en sceneredigerer (for å tegne produksjonsoppsett).

La oss gi et par eksempler på hva dette gir i praksis.

  1. Her er en global produsent av industrielt kjøleutstyr som hovedsakelig brukes i butikkjeder. 10 % av selskapets inntekter kommer fra å tilby tjenester for service på produktene. Det er nødvendig å redusere kostnadene for tjenester og generelt gi muligheten til å øke leveransene normalt, fordi hvis vi selger mer, vil det eksisterende servicesystemet ikke klare seg. Vi koblet oss direkte til plattformen til et enkelt servicesenter, modifiserte et par moduler for denne kundens behov, og fikk 35 % reduksjon i reiseutgifter på grunn av at tilgang til serviceinformasjon gjør det mulig å identifisere årsakene feil uten behov for en servicetekniker til å besøke. Analyse av data over lengre tid - forutsi teknisk tilstand og om nødvendig raskt utfør tilstandsbasert vedlikehold. Som en bonus har responshastigheten på forespørsler økt: det er færre ekskursjoner, og ingeniører er i stand til å få ting gjort raskere.
  2. Mekanisk ingeniørfirma, produsent av elektriske kjøretøy som brukes i mange byer i Russland og CIS. Som alle andre ønsker de å redusere kostnadene og samtidig forutsi den tekniske tilstanden til byens trolleybuss- og trikkeflåte for å varsle teknisk personale i tide. Vi koblet og lagde algoritmer for innsamling og overføring av tekniske data fra rullende materiell til et enkelt situasjonssenter (algoritmene er bygget direkte inn i drivkontrollsystemet og fungerer med CAN-bussdata). Fjerntilgang til tekniske tilstandsdata, inkludert sanntidstilgang til endrede parametere (hastighet, spenning, overføring av gjenvunnet energi, etc.) i "oscilloskop"-modus, ga tilgang til eksterne fastvareoppdateringer. Resultatet er en reduksjon i reisekostnadene med 50 %: direkte tilgang til serviceinformasjon gjør det mulig å identifisere årsakene til feilen uten at en servicetekniker trenger å besøke, og analysen av data over lange tidsintervaller lar deg forutsi teknisk tilstand og om nødvendig raskt utføre «tilstandsbasert» vedlikehold, inkludert objektiv analyse av nødsituasjoner. Implementering av forlengede livssykluskontrakter i full overensstemmelse med kundens krav og til rett tid. Overholdelse av kravene til operatørens tekniske spesifikasjoner, samt gi ham nye muligheter når det gjelder å overvåke egenskapene til forbrukerservice (kvalitet på klimaanlegg, akselerasjon/bremsing, etc.).
  3. Det tredje eksemplet er en kommune. Vi må spare strøm og forbedre sikkerheten til innbyggerne. Vi koblet til én enkelt plattform for overvåking, administrasjon og innsamling av data om tilkoblet gatebelysning, fjernadministrering av hele den offentlige belysningsinfrastrukturen og service fra ett enkelt kontrollpanel, og gir løsninger på følgende oppgaver. Funksjoner: dimming eller slå av lys på/av eksternt, individuelt eller i grupper, automatisk varsling av bytjenester om feil i lyspunkter for mer effektiv vedlikeholdsplanlegging, gir sanntids energiforbruksdata, gir kraftige analytiske verktøy for overvåking og forbedring av gatebelysningen system basert på Big Data, som gir data om trafikk, luftkondisjonering, integrasjon med andre Smart City-delsystemer. Resultater - redusere energiforbruket for gatebelysning med opptil 80 %, øke sikkerheten for beboerne gjennom bruk av intelligente lysstyringsalgoritmer (en person som går nedover gaten - slå på lyset for ham, en person ved krysset - slå på lysere belysning slik at han kan sees langveisfra), sørger for tilleggstjenester for byen (lading av elektriske kjøretøy, reklameinnhold, videoovervåking, etc.).

Egentlig, det jeg ville si: i dag, med en ferdig plattform (for eksempel vår), kan du sette opp overvåking veldig raskt og enkelt. Dette krever ikke endringer i utstyr (eller minimale, hvis det fortsatt ikke er sensorer og dataoverføring), det krever ikke implementeringskostnader og separate spesialister. Du trenger bare å studere problemstillingen, bruke et par dager på å forstå hvordan det fungerer, og noen uker på godkjenninger, en avtale og utveksling av data om protokoller. Og etter det vil du ha nøyaktige data fra alle enheter. Og alt dette kan gjøres over hele landet med støtte fra Technoserv-integratoren, det vil si at vi garanterer et godt nivå av pålitelighet, noe som ikke er typisk for en oppstart.

I neste innlegg vil jeg vise hvordan dette ser ut fra leverandørens side, ved å bruke eksempelet på én implementering.

Kilde: www.habr.com

Legg til en kommentar