Hola, Habr! El nostre equip controla màquines i instal·lacions diverses arreu del país. Essencialment, oferim l'oportunitat al fabricant de no haver d'enviar un enginyer una vegada més quan "oh, està tot trencat", però en realitat només han de prémer un botó. O quan es va avariar no a l'equip, sinó a prop.
El problema bàsic és el següent. Aquí esteu produint una unitat de trencament d'oli, una màquina-eina per a enginyeria mecànica o algun altre dispositiu per a una planta. Com a regla general, la venda en si és molt poques vegades possible: sol ser un contracte de subministrament i servei. És a dir, garanteixes que la peça de maquinari funcionarà durant 10 anys sense interrupcions, i de les interrupcions ets responsable, ja sigui econòmicament, o proporciona uns SLA estrictes, o alguna cosa semblant.
De fet, això significa que cal enviar regularment un enginyer al lloc. Com demostra la nostra pràctica, del 30 al 80% dels viatges són innecessaris. El primer cas: seria possible esbrinar què va passar de forma remota. O demaneu a l'operador que premeu un parell de botons i tot funcionarà. El segon cas són els esquemes "grises". És quan un enginyer surt, programa la substitució o treballs complexos i després divideix la compensació per la meitat amb algú de la fàbrica. O simplement gaudeix de les seves vacances amb la seva mestressa (un cas real) i per tant li agrada sortir més sovint. A la planta no li importa.
La instal·lació de la monitorització requereix la modificació del maquinari amb un dispositiu de transmissió de dades, la transmissió en si, algun tipus de llac de dades per emmagatzemar-lo, protocols d'anàlisi i un entorn de processament amb la possibilitat de veure i comparar-ho tot. Bé, tot això té matisos.
Per què no podem prescindir de la supervisió remota?
És cursi car. Viatge de negocis per a un enginyer: almenys 50 mil rubles (avió, hotel, allotjament, dieta). A més, no sempre és possible separar-se i pot ser que es necessiti la mateixa persona a diferents ciutats.
- A Rússia, el proveïdor i el consumidor gairebé sempre estan força allunyats l'un de l'altre. Quan vens un producte a Sibèria, no en saps res excepte el que t'indica el proveïdor. Ni com funciona, ni en quines condicions s'utilitza, ni, de fet, qui va prémer quin botó amb les mans tortes: objectivament, no teniu aquesta informació, només la podeu saber a partir de les paraules del consumidor. Això fa que el manteniment sigui molt difícil.
- Reclamacions i recursos infundats. És a dir, el teu client, que està utilitzant el teu producte, pot trucar, escriure, queixar-se en qualsevol moment i dir-li que el teu producte no funciona, està malament, està avariat, vine urgent i arregla'l. Si tens sort i no només "no s'han omplert els consumibles", no has enviat un especialista en va. Sovint passa que un treball útil trigava menys d'una hora, i tota la resta, preparar un viatge de negocis, vols, allotjament, tot això requeria molt de temps de l'enginyer.
- Hi ha afirmacions clarament infundades i, per demostrar-ho, cal enviar un enginyer, elaborar un informe i acudir als tribunals. Com a resultat, el procés es retarda i això no aporta res de bo ni per al client ni per a tu.
- Les disputes sorgeixen a causa del fet que, per exemple, el client va operar el producte de manera incorrecta, el client per alguna raó té rancor contra vostè i no diu que el seu producte va funcionar incorrectament, no en els modes indicats a les especificacions tècniques i a la passaport. Al mateix temps, no podeu fer res en contra, o sí, però amb dificultat, si, per exemple, el vostre producte registra i registra aquests modes d'alguna manera. Avaries per culpa del client: això passa tot el temps. Vaig tenir un cas en què una màquina de portal alemanya cara es va trencar a causa d'una col·lisió amb un pal. L'operari no el va posar a zero i, com a resultat, la màquina es va aturar allà. A més, el client va dir clarament: "No hi tenim res a veure". Però la informació es va registrar i va ser possible buscar aquests registres i entendre quin programa de control s'utilitzava i com a conseqüència del qual es va produir aquesta mateixa col·lisió. Això va estalviar al proveïdor costos molt importants per a les reparacions en garantia.
- Els esquemes "grises" esmentats són una conspiració amb el proveïdor de serveis. El mateix tècnic de servei va al client tot el temps. Li diuen: “Escolta, Kolya, fem-ho com vulguis: escrius que aquí està tot trencat, tindrem una indemnització, o portes algun tipus de cremallera per a la reparació. Implementarem tot això en silenci, repartirem els diners". Només queda o creure, o d'alguna manera inventar unes maneres complicades de comprovar totes aquestes conclusions i confirmacions, que no afegeix ni temps ni nervis, i en això no passa res de bo. Si esteu familiaritzat amb com tracten els serveis d'automòbils amb el frau de garantia i quanta complexitat això imposa als processos, enteneu aproximadament el problema.
Bé, els dispositius encara escriuen registres, oi? Quin és el problema?
El problema és que si els proveïdors comprenen més o menys que el registre s'ha d'escriure constantment en algun lloc (o ho han entès durant les últimes dècades), aleshores la cultura no ha anat més lluny. Sovint es necessita el registre per analitzar casos amb reparacions costoses, ja sigui un error de l'operador o una avaria real de l'equip.
Per recollir un registre, sovint cal apropar-se físicament a l'equip, obrir algun tipus de carcassa, exposar el connector de servei, connectar-hi un cable i recollir fitxers de dades. A continuació, agafeu-los de manera persistent durant diverses hores per fer-vos una idea de la situació. Per desgràcia, això passa gairebé a tot arreu (bé, jo tinc un punt de vista unilateral, ja que treballem precisament amb aquelles indústries on s'acaba d'establir el monitoratge).
Els nostres principals clients són els fabricants d'equips. Normalment, comencen a pensar en fer algun tipus de control, ja sigui després d'un incident important o simplement mirant les seves factures de viatge de l'any. Però més sovint, estem parlant d'un fracàs important amb pèrdua de diners o reputació. Els líders progressistes que pensen en "el que passi" són rars. El cas és que normalment el gerent aconsegueix l'antic "parc" de contractes de servei, i no veu cap sentit instal·lar sensors en maquinari nou, perquè només es necessitarà d'aquí a un parell d'anys.
En general, en algun moment el gall rostit encara mossega, i arriba el moment de les modificacions.
La transferència de dades en si no fa molta por. L'equip normalment ja disposa de sensors (o s'instal·len amb força rapidesa), a més, ja s'escriuen els registres i s'anoten els esdeveniments del servei. Tot el que has de fer és començar a enviar-lo. La pràctica general és inserir algun tipus de mòdem, per exemple, amb una SIM incrustada, directament al dispositiu des de la màquina de raigs X fins a la sembradora automàtica, i enviar telemetria a través de la xarxa mòbil. Els llocs on no hi ha cobertura cel·lular solen estar bastant lluny i s'han tornat rars en els últims anys.
I llavors comença la mateixa pregunta que abans. Sí, ara hi ha registres. Però cal posar-los en algun lloc i llegir-los d'alguna manera. En general, es necessita algun tipus de sistema de visualització i anàlisi d'incidències.
I després sortim a l'escenari. Més precisament, sovint ens presentem abans, perquè els responsables dels proveïdors miren què estan fent els seus companys i de seguida acudeixen a nosaltres per demanar-nos assessorament sobre la selecció de maquinari per enviar telemetria.
Nínxol de mercat
A Occident, la manera de resoldre aquesta situació es redueix a tres opcions: l'ecosistema Siemens (molt car, necessari per a unitats molt grans, normalment com turbines), màndules escrites per si mateix, o un dels integradors locals ajuda. Com a resultat, quan tot això va arribar al mercat rus, es va formar un entorn on hi havia Siemens amb les seves peces de l'ecosistema, Amazon, Nokia i diversos ecosistemes locals com els desenvolupaments 1C.
Vam entrar al mercat com un enllaç unificador que ens permet recollir qualsevol dada des de qualsevol dispositiu utilitzant qualsevol protocol (d'acord, gairebé qualsevol més o menys modern), processar-los conjuntament i mostrar-los a una persona en qualsevol forma requerida: per això hem SDK fantàstics per a tothom, entorns de desenvolupament i dissenyador d'interfícies d'usuari visual.
Com a resultat, podem recollir totes les dades del dispositiu del fabricant, emmagatzemar-les en un emmagatzematge al servidor i muntar-hi un panell de monitorització amb alertes.
Això és el que sembla (aquí el client també va fer una visualització de l'empresa, això són diverses hores a la interfície):
I hi ha gràfics de l'equip:
Les alertes tenen aquest aspecte: a nivell de màquina, si s'ha superat la força sobre l'òrgan executiu o s'ha produït una col·lisió, es configura un conjunt de paràmetres, i el sistema informarà el departament o els serveis de reparació quan es superin.
Bé, el més difícil és predir la fallada dels nodes en funció de la seva condició de prevenció. Si enteneu el recurs de cadascun dels nodes, podeu reduir considerablement els costos en aquells contractes en què hi ha un pagament per temps d'inactivitat.
Resum
Aquesta història sonaria força senzilla: bé, ens vam adonar que necessitàvem enviar dades, seguiment i anàlisi, així que vam triar un proveïdor i el vam implementar. Bé, això és tot, tothom està content. Si parlem de sistemes escrits per nosaltres mateixos a la nostra pròpia fàbrica, aleshores, curiosament, els sistemes es tornen ràpidament poc fiables. Estem parlant de la pèrdua banal de registres, dades inexactes, errors en la recollida, emmagatzematge i recepció. Un any o dos després de la instal·lació, es comencen a suprimir els registres antics, cosa que tampoc sempre acaba bé. Tot i que hi ha una pràctica: es recullen 10 GB d'una màquina per any. Això es soluciona durant cinc anys comprant un altre disc dur per 10 mil rubles... En algun moment resulta que no és el propi equip de transmissió el que és principal, sinó el sistema que permet analitzar les dades rebudes. La comoditat de la interfície és important. Aquest és generalment el problema de tots els sistemes industrials: comprendre ràpidament la situació no sempre és fàcil. És important quantes dades són visibles al sistema, el nombre de paràmetres del node, la capacitat del sistema per funcionar amb un gran volum i quantitat de dades. Configuració de taulers, un model integrat del propi dispositiu, un editor d'escenes (per dibuixar maquetes de producció).
Donem un parell d'exemples del que això dóna a la pràctica.
- Aquí hi ha un fabricant global d'equips de refrigeració industrial utilitzats principalment en cadenes minoristes. El 10% dels ingressos de l'empresa provenen de la prestació de serveis per al manteniment dels seus productes. Cal reduir el cost dels serveis i, en general, donar l'oportunitat d'augmentar els subministraments amb normalitat, perquè si venem més, el sistema de serveis existent no ho farà. Ens vam connectar directament a la plataforma d'un únic centre de servei, vam modificar un parell de mòduls per a les necessitats d'aquest client en concret, i vam rebre una reducció del 35% en les despeses de viatge pel fet que l'accés a la informació del servei permet identificar-ne les causes. de fallada sense necessitat de visitar un enginyer de servei. Anàlisi de dades durant llargs períodes de temps: prediu l'estat tècnic i, si cal, realitzeu ràpidament el manteniment basat en l'estat. Com a avantatge, la velocitat de resposta a les sol·licituds ha augmentat: hi ha menys sortides de camp i els enginyers són capaços de fer les coses més ràpidament.
- Empresa d'enginyeria mecànica, fabricant de vehicles elèctrics utilitzats a moltes ciutats de la Federació Russa i la CEI. Com tothom, volen reduir costos i alhora preveure l'estat tècnic de les flotes de troleibusos i tramvies de la ciutat per tal d'avisar oportunament el personal tècnic. Hem connectat i creat algorismes per recollir i transmetre dades tècniques del material mòbil a un únic centre de situació (els algorismes s'incorporen directament al sistema de control de la unitat i funcionen amb dades del bus CAN). L'accés remot a les dades de l'estat tècnic, inclòs l'accés en temps real a paràmetres canviants (velocitat, voltatge, transferència d'energia recuperada, etc.) en mode "oscil·loscopi", va donar accés a actualitzacions remotes del firmware. El resultat és una reducció dels costos de viatge en un 50%: l'accés directe a la informació del servei permet identificar les causes de la fallada sense la necessitat de visitar un enginyer de servei, i l'anàlisi de dades en intervals de temps llargs permet predir el estat tècnic i, si cal, realitzar ràpidament el manteniment "basat en condicions", inclosa l'anàlisi objectiva de les situacions d'emergència. Implementació de contractes de cicle de vida ampliat d'acord amb els requisits del Client i puntual. Compliment dels requisits de les especificacions tècniques de l'operador, així com oferir-li noves oportunitats pel que fa al seguiment de les característiques del servei al consumidor (qualitat de l'aire condicionat, acceleració/frenada, etc.).
- El tercer exemple és un municipi. Hem d'estalviar electricitat i millorar la seguretat dels ciutadans. Vam connectar una única plataforma de seguiment, gestió i recollida de dades de l'enllumenat públic connectat, gestionant de forma remota tota la infraestructura d'enllumenat públic i servint-la des d'un únic panell de control, donant solucions a les següents tasques. Característiques: atenuació o encendre/apagar els llums de forma remota, individualment o en grup, notificació automàtica als serveis municipals de fallades en els punts d'enllumenat per a una planificació més eficient del manteniment, proporcionar dades de consum energètic en temps real, proporcionar potents eines analítiques per controlar i millorar l'enllumenat públic sistema basat en Big Data, proporcionant dades de trànsit, aire condicionat, integració amb altres subsistemes de Smart City. Resultats: reduir el consum d'energia per a l'enllumenat públic fins a un 80%, augmentar la seguretat per als residents mitjançant l'ús d'algoritmes intel·ligents de control de la il·luminació (una persona que camina pel carrer - enceneu la llum per a ell, una persona al pas - enceneu més brillants). il·luminació perquè es pugui veure des de lluny), proporcionant a la ciutat serveis addicionals (carrega de vehicles elèctrics, aportació de continguts publicitaris, videovigilància, etc.).
De fet, el que volia dir: avui, amb una plataforma ja feta (per exemple, la nostra), podeu configurar el monitoratge de manera molt ràpida i senzilla. Això no requereix canvis en els equips (o mínims, si encara no hi ha sensors i transmissió de dades), no requereix costos d'implementació i especialistes separats. Només cal estudiar el tema, dedicar un parell de dies a entendre com funciona, i unes setmanes a aprovacions, un acord i intercanvi de dades sobre protocols. I després d'això tindreu dades precises de tots els dispositius. I tot això es pot fer a tot el país amb el suport de l'integrador Technoserv, és a dir, garantim un bon nivell de fiabilitat, que no és típic d'una startup.
A la propera publicació mostraré com es veu això des del proveïdor, utilitzant l'exemple d'una implementació.
Font: www.habr.com