Saluton, Habr! Nia teamo kontrolas maŝinojn kaj diversajn instalaĵojn tra la lando. Esence, ni donas la ŝancon al la fabrikanto ne devi sendi inĝenieron denove kiam "ho, ĉio estas rompita", sed fakte ili nur bezonas premi unu butonon. Aŭ kiam ĝi paneis ne sur la ekipaĵo, sed proksime.
La baza problemo estas la sekva. Ĉi tie vi produktas naftokrakan unuon, aŭ maŝinilon por mekanika inĝenierado, aŭ iun alian aparaton por planto. Kiel regulo, la vendo mem estas ege malofte ebla: ĝi estas kutime provizo kaj servokontrakto. Tio estas, vi garantias, ke la aparataro funkcios dum 10 jaroj sen interrompoj, kaj pri interrompoj vi respondecas aŭ finance, aŭ provizas striktajn SLA-ojn, aŭ ion similan.
Fakte, ĉi tio signifas, ke vi devas regule sendi inĝenieron al la retejo. Kiel nia praktiko montras, de 30 ĝis 80% de vojaĝoj estas nenecesaj. La unua kazo - eblus ekscii, kio okazis malproksime. Aŭ petu al la telefonisto premi kelkajn butonojn kaj ĉio funkcios. La dua kazo estas "grizaj" skemoj. Jen kiam inĝeniero eliras, planas anstataŭaĵon aŭ kompleksan laboron, kaj tiam dividas la kompenson en duono kun iu el la fabriko. Aŭ li simple ĝuas siajn feriojn kun sia mastrino (vera kazo) kaj tial ŝatas eliri pli ofte. La planto ne ĝenas.
Instalado de monitorado postulas modifon de la aparataro per datumtranssendo-aparato, la transsendo mem, ia datumlago por konservi ĝin, analizi protokolojn kaj pretigan medion kun la kapablo rigardi kaj kompari ĉion. Nu, estas nuancoj al ĉio ĉi.
Kial ni ne povas fari sen fora monitorado?
Ĝi estas kurioze multekosta. Komerca vojaĝo por unu inĝeniero - almenaŭ 50 mil rubloj (aviadilo, hotelo, loĝejo, ĉiutaga poŝmono). Krome, ne ĉiam eblas disiĝi, kaj la sama persono povas esti bezonata en malsamaj urboj.
- En Rusio, la provizanto kaj la konsumanto preskaŭ ĉiam estas sufiĉe malproksime unu de la alia. Kiam vi vendas produkton al Siberio, vi scias nenion pri ĝi krom tio, kion la provizanto diras al vi. Nek kiel ĝi funkcias, nek en kiaj kondiĉoj ĝi estas uzata, nek, fakte, kiu premis kiun butonon per kurbaj manoj - vi objektive ne havas ĉi tiun informon, vi povas scii ĝin nur el la vortoj de la konsumanto. Ĉi tio faras bontenadon tre malfacila.
- Senbazaj pledoj kaj asertoj. Tio estas, via kliento, kiu uzas vian produkton, povas voki, skribi, plendi iam ajn kaj diri, ke via produkto ne funkcias, ĝi estas malbona, ĝi estas rompita, venu urĝe kaj ripari ĝin. Se vi estas bonŝanca kaj ĝi ne estas nur "la konsumeblaj ne estis plenigitaj", tiam vi ne vane sendis specialiston. Ofte okazas, ke utila laboro daŭris malpli ol unu horon, kaj ĉio alia - prepari komercan vojaĝon, flugojn, loĝadon - ĉio ĉi postulis multan tempon de la inĝeniero.
- Estas klare senbazaj asertoj, kaj por pruvi tion, vi devas sendi inĝenieron, ellabori raporton kaj iri al tribunalo. Kiel rezulto, la procezo estas prokrastita, kaj ĉi tio ne alportas ion bonan nek por la kliento nek por vi.
- Disputoj ŝprucas pro la fakto, ke ekzemple la kliento funkciis la produkton malĝuste, la kliento ial havas rankoron kontraŭ vi kaj ne diras, ke via produkto ne funkciis ĝuste, ne en la manieroj deklaritaj en la teknikaj specifoj kaj en la pasporto. Samtempe, vi ne povas fari ion kontraŭ ĝi, aŭ vi povas, sed malfacile, se, ekzemple, via produkto iel registras kaj registras tiujn modojn. Panasoj pro la kulpo de la kliento - ĉi tio okazas ĉiam. Mi havis kazon, kie multekosta germana portalmaŝino rompiĝis pro kolizio kun stango. La funkciigisto ne metis ĝin al nulo, kaj kiel rezulto la maŝino haltis tie. Krome, la kliento diris sufiĉe klare: "Ni havas nenion komunan kun ĝi." Sed la informoj estis registritaj, kaj eblis serĉi ĉi tiujn protokolojn kaj kompreni, kiu kontrolprogramo estis uzata kaj kiel rezulto ĉi tiu sama kolizio okazis. Ĉi tio ŝparis al la provizanto tre grandajn kostojn por garantiaj riparoj.
- La menciitaj "grizaj" skemoj estas komploto kun la servoprovizanto. La sama servoteknikisto iras al la kliento la tutan tempon. Ili diras al li: „Aŭskultu, Kolja, ni faru tion kiel vi volas: vi skribas, ke ĉio estas rompita ĉi tie, ni ricevos kompenson, aŭ vi alportu ian zipon por riparo. Ni efektivigos ĉion ĉi trankvile, ni dividos la monon.” Restas aŭ kredi, aŭ iel elpensi iujn komplikajn manierojn kontroli ĉiujn ĉi tiujn konkludojn kaj konfirmojn, kio ne aldonas tempon nek nervojn, kaj nenio bona okazas en tio. Se vi konas kiel aŭtoservoj traktas garantian fraŭdon kaj kiom da komplekseco ĉi tio trudas al procezoj, tiam vi proksimume komprenas la problemon.
Nu, aparatoj ankoraŭ skribas protokolojn, ĉu ne? Kio estas la problemo?
La problemo estas, ke se provizantoj pli-malpli komprenas, ke la protokolo devas esti konstante skribita ie (aŭ komprenis dum la lastaj jardekoj), tiam la kulturo ne iris plu. La protokolo estas ofte necesa por analizi kazojn kun multekostaj riparoj - ĉu ĝi estis operacianta eraro aŭ vera ekipaĵo paneo.
Por preni protokolon, vi ofte devas fizike alproksimiĝi al la ekipaĵo, malfermi ian envolvaĵon, elmontri la servokonektilon, konekti kablon al ĝi kaj preni datumdosierojn. Tiam persiste prenu ilin dum pluraj horoj por akiri bildon de la situacio. Ve, ĉi tio okazas preskaŭ ĉie (nu, ĉu mi havas unuflankan vidpunkton, ĉar ni laboras ĝuste kun tiuj industrioj, kie monitorado nur estas establita).
Niaj ĉefaj klientoj estas ekipaĵproduktantoj. Tipe, ili komencas pensi pri fari ian monitoradon, ĉu post grava okazaĵo aŭ simple rigardante siajn vojaĝfakturojn por la jaro. Sed pli ofte, ni parolas pri grava fiasko kun perdo de mono aŭ reputacio. Progresemaj gvidantoj kiuj pensas pri "kio ajn okazas" estas maloftaj. La fakto estas, ke kutime la administranto ricevas la malnovan "parkon" de servaj kontraktoj, kaj li vidas nenian signifon instali sensilojn sur nova aparataro, ĉar ĝi estos bezonata nur post kelkaj jaroj.
Ĝenerale, iam la rostita koko ankoraŭ mordas, kaj venas la tempo por modifoj.
Transdono de datumoj mem ne estas tre timiga. La ekipaĵo kutime jam havas sensilojn (aŭ ili estas instalitaj sufiĉe rapide), krome protokoloj jam estas skribitaj kaj servaj eventoj estas notitaj. Ĉio, kion vi devas fari, estas komenci sendi ĝin. La ĝenerala praktiko estas enmeti iun specon de modemo, ekzemple, kun embed-SIM, rekte en la aparaton de la Rentgenfota maŝino ĝis la aŭtomata sedilo, kaj sendi telemetrion per la ĉela reto. Lokoj kie ne ekzistas ĉela kovrado estas kutime sufiĉe foraj kaj fariĝis maloftaj en la lastaj jaroj.
Kaj tiam komenciĝas la sama demando kiel antaŭe. Jes, estas protokoloj nun. Sed oni devas meti ilin ien kaj iel legi. Ĝenerale necesas ia sistemo por bildigi kaj analizi okazaĵojn.
Kaj tiam ni aperas sur la scenejo. Pli precize, ni ofte aperas pli frue, ĉar la administrantoj de la provizantoj rigardas kion faras iliaj kolegoj kaj tuj venas al ni por konsiloj pri elekto de aparataro por sendi telemetrion.
Merkata niĉo
En la Okcidento, la maniero solvi ĉi tiun situacion estas tri opcioj: la Siemens-ekosistemo (tre multekosta, necesa por tre grandaj unuoj, kutime kiel turbinoj), memskribitaj manduloj, aŭ unu el la lokaj integrigantoj helpas. Kiel rezulto, kiam ĉio ĉi venis al la rusa merkato, estis formita medio kie estis Siemens kun ĝiaj pecoj de la ekosistemo, Amazon, Nokia kaj pluraj lokaj ekosistemoj kiel 1C evoluoj.
Ni eniris la merkaton kiel unuecigan ligilon, kiu ebligas al ni kolekti ajnajn datumojn de ajnaj aparatoj uzante ajnajn (bone, preskaŭ pli aŭ malpli modernajn) protokolojn, prilabori ilin kune kaj montri ilin al persono en ajna postulata formo: por tio ni havas bonegaj SDK-oj por ĉiuj evolumedioj kaj vida uzantinterfaco dezajnisto.
Kiel rezulto, ni povas kolekti ĉiujn datumojn de la aparato de la fabrikanto, konservi ĝin en stokado sur la servilo kaj kunmeti monitoran panelon kun atentigoj tie.
Jen kiel ĝi aspektas (ĉi tie la kliento ankaŭ faris bildigon de la entrepreno, jen kelkaj horoj en la interfaco):
Kaj estas grafikaĵoj de la ekipaĵo:
Atentigoj aspektas jene: sur la maŝino-nivelo, se la forto sur la plenuma korpo estas superita aŭ kolizio okazis, aro da parametroj estas agordita, kaj la sistemo informos la fakon aŭ riparajn servojn kiam ili estas superitaj.
Nu, la plej malfacila afero estas antaŭdiri la fiaskon de nodoj surbaze de ilia kondiĉo por preventado. Se vi komprenas la rimedon de ĉiu el la nodoj, tiam vi povas multe redukti kostojn sur tiuj kontraktoj kie estas pago por malfunkcio.
Resumo
Ĉi tiu rakonto sonus sufiĉe simpla: nu, ni rimarkis, ke ni bezonas sendi datumojn, monitoradon kaj analizon, do ni elektis vendiston kaj efektivigis ĝin. Nu, jen, ĉiuj estas feliĉaj. Se ni parolas pri memskribitaj sistemoj ĉe nia propra fabriko, tiam, strange, la sistemoj rapide fariĝas nefidindaj. Ni parolas pri la banala perdo de ŝtipoj, malĝustaj datumoj, misfunkciadoj en kolekto, stokado kaj ricevo. Jaron aŭ du post instalado, malnovaj protokoloj komencas esti forigitaj, kio ankaŭ ne ĉiam bone finiĝas. Kvankam ekzistas praktiko - 10 GB estas kolektitaj de unu maŝino jare. Ĉi tio estas solvita dum kvin jaroj aĉetante alian malmolan diskon por 10 mil rubloj... En iu momento rezultas, ke ne la elsenda ekipaĵo mem estas primara, sed la sistemo, kiu permesas analizi la ricevitajn datumojn. La komforto de la interfaco estas grava. Ĉi tio ĝenerale estas la problemo ĉe ĉiuj industriaj sistemoj: rapide kompreni la situacion ne ĉiam estas facila. Gravas kiom da datumoj estas videblaj en la sistemo, la nombro da parametroj de la nodo, la kapablo de la sistemo funkcii kun granda volumo kaj kvanto da datumoj. Agordi panelojn, enkonstruitan modelon de la aparato mem, scenejredaktilon (por desegni produktadajn aranĝojn).
Ni donu kelkajn ekzemplojn pri tio, kion tio donas en la praktiko.
- Jen tutmonda fabrikanto de industriaj fridigaj ekipaĵoj uzataj ĉefe en podetalaj ĉenoj. 10% de la enspezo de la firmao venas de liverado de servoj por servado de ĝiaj produktoj. Necesas redukti la koston de servoj kaj ĝenerale doni la ŝancon plialtigi provizojn normale, ĉar se ni vendos pli, la ekzistanta servosistemo ne elportos. Ni konektis rekte al la platformo de ununura servocentro, modifis kelkajn modulojn por la bezonoj de ĉi tiu aparta kliento, kaj ricevis 35% redukton de vojaĝkostoj pro la fakto, ke aliro al servaj informoj ebligas identigi la kaŭzojn. de fiasko sen neceso de servo-inĝeniero por viziti. Analizo de datumoj dum longaj tempoj - antaŭdiri la teknikan kondiĉon kaj, se necese, rapide plenumi kondiĉ-bazitan bontenadon. Kiel gratifiko, la rapideco de respondo al petoj pliiĝis: estas malpli da ekskursoj, kaj inĝenieroj povas fari aferojn pli rapide.
- Kompanio pri mekanika inĝenierado, fabrikanto de elektraj veturiloj uzataj en multaj urboj de la Rusa Federacio kaj la CIS. Kiel ĉiuj aliaj, ili volas redukti kostojn kaj samtempe antaŭdiri la teknikan staton de la urbaj trolebusaj kaj tramflotoj por ĝustatempe sciigi teknikan personaron. Ni konektis kaj kreis algoritmojn por kolekti kaj transdoni teknikajn datumojn de rulvaro al ununura situacio-centro (la algoritmoj estas enkonstruitaj rekte en la stirado-kontrolsistemon kaj funkcias kun CAN-busaj datumoj). Fora aliro al teknikaj kondiĉaj datumoj, inkluzive de realtempa aliro al ŝanĝiĝantaj parametroj (rapideco, tensio, translokigo de reakirita energio, ktp.) en "osciloskopa" reĝimo, donis aliron al foraj firmware-ĝisdatigoj. La rezulto estas redukto de vojaĝkostoj je 50%: rekta aliro al servaj informoj ebligas identigi la kaŭzojn de malsukceso sen neceso de servo inĝeniero viziti, kaj la analizo de datumoj dum longaj intervaloj permesas antaŭdiri la teknika kondiĉo kaj, se necese, rapide plenumi "kondiĉan" prizorgadon, inkluzive de objektiva analizo de kriz-situacioj. Efektivigo de plilongigitaj vivciklaj kontraktoj plene konforme al la postuloj de la Kliento kaj ĝustatempe. Konformo al la postuloj de la teknikaj specifoj de la funkciigisto, same kiel provizi al li novajn ŝancojn pri monitorado de la karakterizaĵoj de konsumanto-servo (kvalito de klimatizilo, akcelo / bremsado, ktp.).
- La tria ekzemplo estas municipo. Ni devas ŝpari elektron kaj plibonigi la sekurecon de civitanoj. Ni konektis ununuran platformon por monitorado, administrado kaj kolektado de datumoj pri konektita strata lumigado, malproksime administrante la tutan infrastrukturon de publika lumigado kaj priservante ĝin de ununura kontrolpanelo, provizante solvojn al la sekvaj taskoj. Karakterizaĵoj: malŝalti aŭ malŝalti/malŝalti lumojn malproksime, individue aŭ en grupoj, aŭtomate sciigi urbajn servojn pri misfunkciadoj en lumpunktoj por pli efika prizorgadoplanado, disponigante realtempajn energikonsumajn datumojn, disponigante potencajn analizajn ilojn por monitorado kaj plibonigo de la stratlumado. sistemo bazita sur Big Data, provizante datumojn pri trafiko, klimato, integriĝo kun aliaj Smart City-subsistemoj. Rezultoj - reduktante la energikonsumon por stratlumado ĝis 80%, pliigante sekurecon por loĝantoj per la uzo de inteligentaj lumkontrolaj algoritmoj (persono marŝante laŭ la strato - ŝaltu la lumon por li, persono ĉe la transirejo - ŝaltu pli hele. lumigado por ke li estu videbla de malproksime), disponigante por la urbo kromajn servojn (ŝargado de elektraj veturiloj, disponigado de reklam-enhavo, videogvatado ktp.).
Efektive, kion mi volis diri: hodiaŭ, per preta platformo (ekzemple la nia), vi povas agordi monitoradon tre rapide kaj facile. Ĉi tio ne postulas ŝanĝojn en ekipaĵo (aŭ minimumaj, se ankoraŭ ne ekzistas sensiloj kaj transdono de datumoj), ĝi ne postulas efektivigajn kostojn kaj apartajn specialistojn. Vi nur bezonas studi la aferon, pasigi kelkajn tagojn por kompreni kiel ĝi funkcias, kaj kelkajn semajnojn pri aproboj, interkonsento kaj interŝanĝo de datumoj pri protokoloj. Kaj post tio vi havos precizajn datumojn de ĉiuj aparatoj. Kaj ĉio ĉi povas esti farita en la tuta lando kun la subteno de la integristo Technoserv, tio estas, ni garantias bonan nivelon de fidindeco, kiu ne estas tipa por starto.
En la sekva afiŝo mi montros, kiel ĉi tio aspektas de la flanko de la provizanto, uzante la ekzemplon de unu efektivigo.
fonto: www.habr.com