Hallo, Habr! Ons team monitort machines en diverse installaties door het hele land. In wezen bieden we de fabrikant de mogelijkheid om niet nog een keer een monteur te hoeven sturen als ‘oh, alles is kapot’, maar in werkelijkheid hoeven ze maar op één knop te drukken. Of wanneer het niet op de apparatuur kapot ging, maar in de buurt.
Het fundamentele probleem is het volgende. Hier produceert u een oliekraakeenheid, of een werktuigmachine voor de machinebouw, of een ander apparaat voor een fabriek. In de regel is de verkoop zelf uiterst zelden mogelijk: het gaat meestal om een leverings- en servicecontract. Dat wil zeggen dat u garandeert dat het stuk hardware 10 jaar zonder onderbrekingen zal werken, en voor onderbrekingen bent u financieel verantwoordelijk, of stelt u strikte SLA's op, of iets dergelijks.
In feite betekent dit dat u regelmatig een ingenieur naar de locatie moet sturen. Zoals uit de praktijk blijkt, is 30 tot 80% van de ritten onnodig. Het eerste geval: het zou mogelijk zijn om op afstand uit te zoeken wat er is gebeurd. Of vraag de operator om op een paar knoppen te drukken en alles werkt. Het tweede geval betreft “grijze” regelingen. Dit is wanneer een ingenieur op pad gaat, vervanging of complex werk plant en vervolgens de vergoeding in tweeën deelt met iemand uit de fabriek. Of hij geniet gewoon van zijn vakantie met zijn minnares (een echt geval) en gaat daarom graag vaker uit. De plant vindt het niet erg.
Het installeren van monitoring vereist aanpassing van de hardware met een apparaat voor gegevensoverdracht, de overdracht zelf, een soort datameer om deze op te slaan, parseerprotocollen en een verwerkingsomgeving met de mogelijkheid om alles te bekijken en te vergelijken. Welnu, er zijn nuances in dit alles.
Waarom kunnen we niet zonder monitoring op afstand?
Het is oubollig duur. Zakenreis voor één ingenieur - minimaal 50 duizend roebel (vliegtuig, hotel, accommodatie, dagvergoeding). Bovendien is het niet altijd mogelijk om uit elkaar te gaan, en kan dezelfde persoon in verschillende steden nodig zijn.
- In Rusland staan leverancier en consument vrijwel altijd vrij ver van elkaar. Wanneer u een product aan Siberië verkoopt, weet u er niets van, behalve wat de leverancier u vertelt. Noch hoe het werkt, noch onder welke omstandigheden het wordt gebruikt, noch, in feite, wie met kromme handen op welke knop heeft gedrukt - je beschikt objectief niet over deze informatie, je kunt het alleen weten uit de woorden van de consument. Dit maakt het onderhoud erg lastig.
- Ongegronde beroepen en claims. Dat wil zeggen dat uw klant, die uw product gebruikt, op elk moment kan bellen, schrijven, klagen en zeggen dat uw product niet werkt, slecht is, kapot is, dringend langskomt en het repareert. Als je geluk hebt en het is niet alleen "de verbruiksartikelen waren niet gevuld", dan heb je niet tevergeefs een specialist gestuurd. Het komt vaak voor dat nuttig werk minder dan een uur duurde, en al het andere - het voorbereiden van een zakenreis, vluchten, accommodatie - dit alles vergde veel tijd van de ingenieur.
- Er zijn duidelijk ongegronde claims, en om dit te bewijzen, moet je een ingenieur sturen, een rapport opstellen en naar de rechter stappen. Hierdoor loopt het proces vertraging op, en dit levert zowel voor de klant als voor u niets goeds op.
- Geschillen ontstaan doordat de klant het product bijvoorbeeld verkeerd heeft bediend, de klant om wat voor reden dan ook wrok tegen u heeft en niet zegt dat uw product niet correct werkte, niet in de modi vermeld in de technische specificaties en in het paspoort. Tegelijkertijd kunt u er niets tegen doen, of dat kunt u wel, maar met moeite, als uw product bijvoorbeeld op de een of andere manier deze modi registreert en registreert. Storingen als gevolg van de schuld van de klant - dit gebeurt de hele tijd. Ik had een geval waarbij een dure Duitse portaalmachine kapot ging door een botsing met een paal. De operator zette deze niet op nul, waardoor de machine daar stopte. Bovendien zei de klant heel duidelijk: “Wij hebben er niets mee te maken.” Maar de informatie werd vastgelegd en het was mogelijk om deze logboeken op te zoeken en te begrijpen welk besturingsprogramma werd gebruikt en als gevolg waarvan juist deze botsing plaatsvond. Dit bespaarde de leverancier zeer grote kosten voor garantiereparaties.
- De genoemde “grijze” regelingen zijn een complot met de dienstverlener. Steeds dezelfde servicemonteur gaat naar de klant. Ze zeggen tegen hem: 'Luister, Kolya, laten we het doen zoals jij wilt: je schrijft dat alles hier kapot is, we krijgen een compensatie, of je brengt een soort ritssluiting mee voor reparatie. We zullen dit allemaal rustig uitvoeren, we zullen het geld verdelen.” Het enige dat overblijft is geloven, of op de een of andere manier een aantal ingewikkelde manieren bedenken om al deze conclusies en bevestigingen te controleren, wat geen tijd of zenuwen toevoegt, en er gebeurt niets goeds in. Als u bekend bent met de manier waarop autodiensten omgaan met garantiefraude en hoeveel complexiteit dit met zich meebrengt voor processen, dan begrijpt u het probleem grofweg.
Apparaten schrijven nog steeds logboeken, toch? Wat is het probleem?
Het probleem is dat als leveranciers min of meer begrijpen dat het logboek voortdurend ergens moet worden geschreven (of dat de afgelopen decennia hebben begrepen), de cultuur niet verder is gegaan. Het logboek is vaak nodig om gevallen met dure reparaties te analyseren, of het nu om een bedieningsfout gaat of om een echte apparatuurstoring.
Om een logboek op te halen, moet u de apparatuur vaak fysiek benaderen, een soort behuizing openen, de serviceconnector blootleggen, er een kabel op aansluiten en gegevensbestanden ophalen. Pak ze vervolgens enkele uren volhardend vast om een beeld te krijgen van de situatie. Helaas gebeurt dit bijna overal (nou ja, ik heb ook een eenzijdig standpunt, aangezien we precies samenwerken met die industrieën waar monitoring net wordt ingesteld).
Onze belangrijkste klanten zijn fabrikanten van apparatuur. Normaal gesproken beginnen ze na te denken over een of andere vorm van monitoring, hetzij na een groot incident, hetzij gewoon door naar hun reisrekeningen voor het jaar te kijken. Maar vaker wel dan niet hebben we het over een grote mislukking met verlies van geld of reputatie. Progressieve leiders die nadenken over ‘wat er ook gebeurt’ zijn zeldzaam. Feit is dat de manager meestal het oude 'park' van servicecontracten krijgt, en dat hij geen zin ziet in het installeren van sensoren op nieuwe hardware, omdat deze pas over een paar jaar nodig zal zijn.
Over het algemeen bijt de geroosterde haan op een gegeven moment nog steeds en is het tijd voor aanpassingen.
Gegevensoverdracht zelf is niet erg eng. De apparatuur beschikt meestal al over sensoren (of deze worden vrij snel geïnstalleerd), plus er worden al logboeken geschreven en servicegebeurtenissen genoteerd. Het enige dat u hoeft te doen, is het verzenden ervan. De algemene praktijk is om een soort modem, bijvoorbeeld met een ingebouwde simkaart, rechtstreeks in het apparaat te plaatsen, van de röntgenmachine naar de automatische seeder, en telemetrie via het mobiele netwerk te verzenden. Plaatsen waar geen mobiel bereik is, liggen meestal vrij ver weg en zijn de laatste jaren zeldzaam geworden.
En dan begint dezelfde vraag als voorheen. Ja, er zijn nu logboeken. Maar ze moeten ergens worden neergezet en op de een of andere manier worden gelezen. Over het algemeen is er behoefte aan een soort systeem voor het visualiseren en analyseren van incidenten.
En dan verschijnen wij op het podium. Om precies te zijn: wij komen vaak eerder langs, omdat de managers van de leveranciers kijken waar hun collega’s mee bezig zijn en meteen bij ons terechtkomen voor advies over de keuze van hardware voor het versturen van telemetrie.
Nichemarkt
In het Westen komt de manier om deze situatie op te lossen neer op drie opties: het Siemens-ecosysteem (erg duur, nodig voor zeer grote eenheden, meestal zoals turbines), zelfgeschreven mandules, of een van de lokale integrators helpt. Als gevolg hiervan ontstond er, toen dit allemaal op de Russische markt kwam, een omgeving met Siemens met zijn onderdelen van het ecosysteem, Amazon, Nokia en verschillende lokale ecosystemen zoals 1C-ontwikkelingen.
We zijn op de markt gekomen als een verbindende schakel waarmee we alle gegevens van elk apparaat kunnen verzamelen met behulp van elk (oké, bijna elk min of meer modern) protocol, deze samen kunnen verwerken en in elke gewenste vorm aan een persoon kunnen laten zien: hiervoor hebben we coole SDK's voor iedereen, ontwikkelomgevingen en ontwerpers van visuele gebruikersinterfaces.
Hierdoor kunnen we alle gegevens van het apparaat van de fabrikant verzamelen, opslaan op de server en daar een monitoringpaneel met waarschuwingen samenstellen.
Zo ziet het eruit (hier heeft de klant ook een visualisatie van de onderneming gemaakt, dit is enkele uren in de interface):
En er zijn grafieken van de apparatuur:
Waarschuwingen zien er als volgt uit: op machineniveau wordt, als de kracht op het uitvoerend orgaan wordt overschreden of een botsing heeft plaatsgevonden, een reeks parameters geconfigureerd en zal het systeem de afdeling of reparatiediensten informeren wanneer deze worden overschreden.
Welnu, het moeilijkste is het voorspellen van het falen van knooppunten op basis van hun toestand voor preventie. Als u de middelen van elk van de knooppunten begrijpt, kunt u de kosten aanzienlijk verlagen voor die contracten waarbij voor downtime wordt betaald.
Beknopt
Dit verhaal zou vrij simpel klinken: we realiseerden ons dat we gegevens, monitoring en analyse moesten verzenden, dus kozen we een leverancier en implementeerden deze. Nou, dat is alles, iedereen is blij. Als we het hebben over zelfgeschreven systemen in onze eigen fabriek, dan worden de systemen vreemd genoeg al snel onbetrouwbaar. We hebben het over het banale verlies van logbestanden, onnauwkeurige gegevens, fouten bij het verzamelen, opslaan en ontvangen. Een jaar of twee na de installatie beginnen oude logs te worden verwijderd, wat ook niet altijd goed afloopt. Hoewel er een praktijk is: er wordt 10 GB per jaar verzameld van één machine. Dit wordt voor vijf jaar opgelost door nog een harde schijf aan te schaffen voor 10 roebel. Op een gegeven moment blijkt dat niet de zendapparatuur zelf primair is, maar het systeem waarmee de ontvangen gegevens kunnen worden geanalyseerd. Het gemak van de interface is belangrijk. Dit is over het algemeen het probleem bij alle industriële systemen: het snel begrijpen van de situatie is niet altijd gemakkelijk. Het is belangrijk hoeveel gegevens zichtbaar zijn in het systeem, het aantal parameters van het knooppunt, het vermogen van het systeem om met een groot volume en een grote hoeveelheid gegevens te werken. Dashboards opzetten, een ingebouwd model van het apparaat zelf, een scène-editor (voor het tekenen van productie-indelingen).
Laten we een paar voorbeelden geven van wat dit in de praktijk oplevert.
- Hier is een wereldwijde fabrikant van industriële koelapparatuur die voornamelijk in winkelketens wordt gebruikt. 10% van de inkomsten van het bedrijf komt uit het verlenen van diensten voor het onderhouden van zijn producten. Het is noodzakelijk om de kosten van diensten te verlagen en in het algemeen de mogelijkheid te bieden om het aanbod normaal te vergroten, want als we meer verkopen, zal het bestaande dienstensysteem het niet aankunnen. We zijn rechtstreeks aangesloten op het platform van één enkel servicecentrum, hebben een aantal modules aangepast aan de behoeften van deze specifieke klant en hebben een reductie van 35% in de reiskosten gekregen dankzij het feit dat toegang tot service-informatie het mogelijk maakt om de oorzaken te identificeren van storingen zonder dat er een servicemonteur langs hoeft te komen. Analyse van gegevens over langere tijd: voorspel de technische staat en voer indien nodig snel conditiegebaseerd onderhoud uit. Als bonus is de reactiesnelheid op verzoeken toegenomen: er zijn minder excursies en ingenieurs kunnen dingen sneller gedaan krijgen.
- Werktuigbouwkundig bedrijf, fabrikant van elektrische voertuigen die in veel steden van de Russische Federatie en het GOS worden gebruikt. Net als iedereen willen ze de kosten verlagen en tegelijkertijd de technische staat van de trolleybus- en tramvloten van de stad voorspellen om het technisch personeel tijdig op de hoogte te stellen. We hebben algoritmen verbonden en gecreëerd voor het verzamelen en verzenden van technische gegevens van rollend materieel naar één situatiecentrum (de algoritmen zijn rechtstreeks in het aandrijfbesturingssysteem ingebouwd en werken met CAN-busgegevens). Toegang op afstand tot technische toestandsgegevens, inclusief realtime toegang tot veranderende parameters (snelheid, spanning, overdracht van teruggewonnen energie, enz.) in “oscilloscoop”-modus, gaf toegang tot firmware-updates op afstand. Het resultaat is een reductie van de reiskosten met 50%: directe toegang tot service-informatie maakt het mogelijk om de oorzaken van storingen te identificeren zonder dat er een servicemonteur langs hoeft te komen, en door de analyse van gegevens over lange tijdsintervallen kunt u de problemen voorspellen technische staat en, indien nodig, snel ‘conditiegebaseerd’ onderhoud uitvoeren, inclusief objectieve analyse van noodsituaties. Implementatie van verlengde levenscycluscontracten volledig in overeenstemming met de eisen van de klant en op tijd. Naleving van de vereisten van de technische specificaties van de exploitant, en hem nieuwe mogelijkheden bieden op het gebied van monitoring van de kenmerken van de consumentenservice (kwaliteit van de airconditioning, acceleratie/remmen, enz.).
- Het derde voorbeeld is een gemeente. We moeten elektriciteit besparen en de veiligheid van burgers verbeteren. We hebben één enkel platform verbonden voor het monitoren, beheren en verzamelen van gegevens over aangesloten straatverlichting, het op afstand beheren van de gehele openbare verlichtingsinfrastructuur en het onderhouden ervan vanaf één enkel bedieningspaneel, en bieden oplossingen voor de volgende taken. Kenmerken: lampen op afstand dimmen of aan/uit zetten, individueel of in groepen, stadsdiensten automatisch op de hoogte stellen van storingen in verlichtingspunten voor een efficiëntere onderhoudsplanning, realtime energieverbruiksgegevens verstrekken, krachtige analytische hulpmiddelen bieden voor het monitoren en verbeteren van de straatverlichting systeem gebaseerd op Big Data, dat gegevens levert over verkeer, airconditioning en integratie met andere Smart City-subsystemen. Resultaten - vermindering van het energieverbruik voor straatverlichting met wel 80%, verhoging van de veiligheid voor bewoners door het gebruik van intelligente lichtregelalgoritmen (een persoon die over straat loopt - doet het licht voor hem aan, een persoon op het kruispunt - zet helderder aan verlichting zodat hij van veraf gezien kan worden), het voorzien van aanvullende diensten voor de stad (opladen van elektrische voertuigen, aanbieden van reclame-inhoud, videobewaking, enz.).
Wat ik eigenlijk wilde zeggen: vandaag de dag kun je met een kant-en-klaar platform (bijvoorbeeld dat van ons) heel snel en eenvoudig monitoring opzetten. Hiervoor zijn geen veranderingen in apparatuur nodig (of minimale, als er nog geen sensoren en datatransmissie zijn), er zijn geen implementatiekosten en aparte specialisten nodig. Je hoeft het probleem alleen maar te bestuderen, een paar dagen te besteden aan het begrijpen hoe het werkt, en een paar weken aan goedkeuringen, een overeenkomst en uitwisseling van gegevens over protocollen. En daarna beschikt u over nauwkeurige gegevens van alle apparaten. En dit alles kan door het hele land worden gedaan met de steun van de Technoserv-integrator, dat wil zeggen dat we een goed niveau van betrouwbaarheid garanderen, wat niet typisch is voor een startup.
In de volgende post zal ik laten zien hoe dit er vanaf de kant van de leverancier uitziet, aan de hand van het voorbeeld van één implementatie.
Bron: www.habr.com