Ola, Habr! O noso equipo supervisa máquinas e instalacións diversas en todo o país. Esencialmente, ofrecémoslle ao fabricante a oportunidade de non ter que enviar un enxeñeiro unha vez máis cando "oh, está todo roto", pero en realidade só precisan premer un botón. Ou cando se avaria non no equipo, senón preto.
O problema básico é o seguinte. Aquí está a producir unha unidade de rachadura de aceite, ou unha máquina-ferramenta para enxeñaría mecánica ou algún outro dispositivo para unha planta. Como regra xeral, a venda en si é moi raramente posible: adoita ser un contrato de subministración e servizo. É dicir, garantes que a peza de hardware funcionará durante 10 anos sen interrupcións, e das interrupcións eres responsable ben financeiramente, ben proporcionas uns SLA estritos ou algo semellante.
De feito, isto significa que cómpre enviar regularmente un enxeñeiro ao sitio. Como mostra a nosa práctica, do 30 ao 80% das viaxes son innecesarias. O primeiro caso - sería posible descubrir o que pasou remotamente. Ou pídelle ao operador que prema un par de botóns e todo funcionará. O segundo caso son os esquemas "gris". É entón cando un enxeñeiro sae, programa a substitución ou traballos complexos e despois divide a compensación á metade con alguén da fábrica. Ou simplemente goza das súas vacacións coa súa amante (un caso real) e, polo tanto, gústalle saír máis a miúdo. A planta non lle importa.
A instalación da monitorización require a modificación do hardware cun dispositivo de transmisión de datos, a propia transmisión, algún tipo de lago de datos para almacenalo, protocolos de análise e un ambiente de procesamento con capacidade para ver e comparar todo. Ben, hai matices en todo isto.
Por que non podemos prescindir da vixilancia remota?
É cursi caro. Viaxe de negocios para un enxeñeiro - polo menos 50 mil rublos (avión, hotel, aloxamento, dieta). Ademais, non sempre é posible romper e pode ser necesaria a mesma persoa en diferentes cidades.
- En Rusia, o provedor e o consumidor case sempre están bastante afastados un do outro. Cando vendes un produto a Siberia, non sabes nada diso excepto o que che di o provedor. Nin como funciona, nin en que condicións se usa, nin, de feito, quen presionou que botón coas mans tortas: obxectivamente non tes esta información, só podes coñecela polas palabras do consumidor. Isto dificulta moito o mantemento.
- Reclamacións e recursos infundados. É dicir, o teu cliente, que está a usar o teu produto, pode chamar, escribir, reclamar en calquera momento e dicir que o teu produto non funciona, está mal, está avariado, acude urxentemente e arranxalo. Se tes sorte e non é só "os consumibles non se encheron", entón non enviaches un especialista en balde. Moitas veces ocorre que o traballo útil levou menos dunha hora e todo o demais - preparar unha viaxe de negocios, voos, aloxamento - todo isto requiriu moito tempo do enxeñeiro.
- Hai reclamacións claramente infundadas e, para probalo, cómpre enviar un enxeñeiro, elaborar un informe e acudir aos tribunais. Como resultado, o proceso atrasase, e isto non trae nada bo nin para o cliente nin para ti.
- As disputas xorden debido ao feito de que, por exemplo, o cliente utilizou o produto de forma incorrecta, o cliente por algún motivo ten rencor contra ti e non di que o teu produto non funcionou correctamente, non nos modos indicados nas especificacións técnicas e no pasaporte. Ao mesmo tempo, non podes facer nada contra el, ou podes, pero con dificultade, se, por exemplo, o teu produto rexistra e rexistra eses modos dalgún xeito. Avarías por culpa do cliente: isto ocorre todo o tempo. Tiven un caso no que unha costosa máquina de portal alemán rompeu debido a unha colisión cun poste. O operario non a puxo a cero e, como resultado, a máquina parou alí. Ademais, o cliente dixo claramente: "Non temos nada que ver con iso". Pero a información foi rexistrada, e foi posible buscar estes rexistros e comprender que programa de control se utilizou e como consecuencia do cal se produciu esta mesma colisión. Isto aforroulle ao provedor custos moi elevados para as reparacións en garantía.
- Os esquemas "gris" mencionados son unha conspiración co provedor de servizos. O mesmo técnico de servizo vai ao cliente todo o tempo. Dinlle: "Escoita, Kolya, imos facelo como queiras: escribes aquí que está todo roto, teremos unha compensación ou traes algún tipo de cremalleira para a reparación. Implementaremos todo isto en silencio, repartiremos o diñeiro". Só queda ou crer, ou inventar dalgún xeito unhas complicadas formas de comprobar todas estas conclusións e confirmacións, o que non engade tempo nin nervios, e nisto non pasa nada bo. Se estás familiarizado coa forma en que os servizos de automóbiles tratan a fraude na garantía e a cantidade de complexidade que isto impón aos procesos, entenderás aproximadamente o problema.
Ben, os dispositivos aínda escriben rexistros, non? Cal é o problema?
O problema é que se os provedores entenden máis ou menos que o rexistro debe escribirse constantemente nalgún lugar (ou o entenderon durante as últimas décadas), entón a cultura non foi máis lonxe. O rexistro adoita ser necesario para analizar casos con reparacións caras, xa sexa un erro do operador ou unha avaría real do equipo.
Para recoller un rexistro, moitas veces cómpre achegarse fisicamente ao equipo, abrir algún tipo de carcasa, expoñer o conector de servizo, conectarlle un cable e recoller ficheiros de datos. A continuación, cólleos de forma persistente durante varias horas para facer unha imaxe da situación. Por desgraza, isto ocorre en case todas partes (ben, ou teño un punto de vista unilateral, xa que traballamos precisamente con aquelas industrias nas que só se está a establecer a vixilancia).
Os nosos principais clientes son os fabricantes de equipos. Normalmente, comezan a pensar en facer algún tipo de seguimento, xa sexa despois dun incidente importante ou só mirando as súas contas de viaxe do ano. Pero a maioría das veces, estamos a falar dun gran fracaso con perda de diñeiro ou reputación. Os líderes progresistas que pensan en "pase o que pase" son raros. O caso é que normalmente o xestor consegue o vello "parque" de contratos de servizos, e non ve sentido instalar sensores en hardware novo, porque só será necesario nun par de anos.
En xeral, nalgún momento o galo asado aínda morde, e chega o momento das modificacións.
A transferencia de datos en si non dá moito medo. O equipo normalmente xa ten sensores (ou instálanse con bastante rapidez), ademais de que xa se escriben rexistros e se anotan os eventos do servizo. Todo o que tes que facer é comezar a envialo. A práctica xeral é inserir algún tipo de módem, por exemplo, cunha SIM integrada, directamente no dispositivo desde a máquina de raios X ata a sementadora automática e enviar telemetría a través da rede móbil. Os lugares onde non hai cobertura celular adoitan estar bastante afastados e volvéronse raros nos últimos anos.
E entón comeza a mesma pregunta que antes. Si, agora hai rexistros. Pero hai que poñelos nalgún lugar e ler dalgún xeito. En xeral, é necesario algún tipo de sistema de visualización e análise de incidencias.
E despois aparecemos no escenario. Máis precisamente, adoitamos aparecer antes, porque os xestores dos provedores miran o que están a facer os seus compañeiros e acuden inmediatamente a nós para que nos asesoremos sobre a selección de hardware para o envío de telemetría.
Nicho de mercado
En Occidente, a forma de solucionar esta situación redúcese en tres opcións: o ecosistema de Siemens (moi caro, necesario para unidades moi grandes, xeralmente como turbinas), mandos autoescritos ou axuda dalgún dos integradores locais. Como resultado, cando todo isto chegou ao mercado ruso, formouse un ambiente onde estaba Siemens coas súas pezas do ecosistema, Amazon, Nokia e varios ecosistemas locais como desenvolvementos 1C.
Entramos no mercado como un vínculo unificador que nos permite recoller calquera dato de calquera dispositivo utilizando calquera protocolo (vale, case máis ou menos moderno), procesalos xuntos e mostrámolos a unha persoa en calquera forma requirida: para iso temos SDK fantásticos para todos os contornos de desenvolvemento e o deseñador de interfaces de usuario visual.
Como resultado, podemos recoller todos os datos do dispositivo do fabricante, almacenalos no servidor e montar alí un panel de monitorización con alertas.
Este é o que parece (aquí o cliente tamén fixo unha visualización da empresa, esta son varias horas na interface):
E hai gráficos do equipo:
As alertas teñen o seguinte aspecto: a nivel de máquina, se se superou a forza sobre o órgano executivo ou se produciu unha colisión, configúrase un conxunto de parámetros e o sistema informará ao departamento ou aos servizos de reparación cando se superen.
Ben, o máis difícil é prever o fallo dos nodos en función da súa condición de prevención. Se entendes o recurso de cada un dos nodos, podes reducir moito os custos naqueles contratos nos que hai un pago por tempo de inactividade.
Resumo
Esta historia soaría bastante sinxela: ben, decatámonos de que necesitabamos enviar datos, seguimento e análise, así que eliximos un provedor e implementámolo. Pois xa está, todos contentos. Se estamos a falar de sistemas auto-escritos na nosa propia fábrica, entón, curiosamente, os sistemas rapidamente non son fiables. Falamos da banal perda de rexistros, datos inexactos, fallos na recollida, almacenamento e recepción. Un ou dous anos despois da instalación, os rexistros antigos comezan a ser eliminados, o que tampouco sempre remata ben. Aínda que hai unha práctica: recóllense 10 GB dunha máquina ao ano. Isto resólvese durante cinco anos comprando outro disco duro por 10 mil rublos... Nalgún momento resulta que o principal non é o propio equipo transmisor, senón o sistema que permite analizar os datos recibidos. A comodidade da interface é importante. Este é xeralmente o problema de todos os sistemas industriais: comprender rapidamente a situación non sempre é doado. É importante cantos datos son visibles no sistema, o número de parámetros do nodo, a capacidade do sistema para operar cun gran volume e cantidade de datos. Configurar paneis de mando, un modelo integrado do propio dispositivo, un editor de escenas (para debuxar esquemas de produción).
Poñamos un par de exemplos do que isto dá na práctica.
- Aquí está un fabricante global de equipos de refrixeración industrial utilizados principalmente en cadeas de venda polo miúdo. O 10% dos ingresos da empresa proceden da prestación de servizos para o mantemento dos seus produtos. É necesario reducir o custo dos servizos e, en xeral, dar a oportunidade de aumentar os suministros con normalidade, porque se vendemos máis, o sistema de servizos existente non vai facer fronte. Conectámonos directamente á plataforma dun único centro de servizos, modificamos un par de módulos para as necesidades deste cliente en concreto e recibimos unha redución do 35% nos gastos de desprazamento debido a que o acceso á información do servizo permite identificar as causas. de falla sen necesidade de que un enxeñeiro de servizo a visite. Análise de datos durante longos períodos de tempo: prever o estado técnico e, se é necesario, realizar rapidamente o mantemento baseado en condicións. Como extra, aumentou a velocidade de resposta ás solicitudes: hai menos viaxes de campo e os enxeñeiros poden facer as cousas máis rápido.
- Empresa de enxeñería mecánica, fabricante de vehículos eléctricos utilizados en moitas cidades da Federación Rusa e da CEI. Como todos, queren reducir custos e ao mesmo tempo prever o estado técnico das flotas de trolebuses e tranvías da cidade para avisar oportunamente ao persoal técnico. Conectamos e creamos algoritmos para recoller e transmitir datos técnicos do material rodante a un único centro de situación (os algoritmos están integrados directamente no sistema de control da unidade e funcionan con datos do bus CAN). O acceso remoto aos datos de condicións técnicas, incluído o acceso en tempo real a parámetros cambiantes (velocidade, tensión, transferencia de enerxía recuperada, etc.) en modo "osciloscopio", permitiu acceder ás actualizacións de firmware remotas. O resultado é unha redución dos custos de viaxe nun 50%: o acceso directo á información do servizo permite identificar as causas do fallo sen necesidade de que un enxeñeiro de servizo a visite, e a análise dos datos a longos intervalos de tempo permite prever o condición técnica e, se é necesario, realizar rapidamente o mantemento "baseado en condicións", incluíndo análise obxectiva das situacións de emerxencia. Implementación de contratos de ciclo de vida estendido de acordo cos requisitos do Cliente e en prazo. Cumprimento dos requisitos das especificacións técnicas do operador, así como dotarlle de novas oportunidades en canto ao seguimento das características do servizo ao consumidor (calidade do aire acondicionado, aceleración/freada, etc.).
- O terceiro exemplo é un concello. Necesitamos aforrar electricidade e mellorar a seguridade dos cidadáns. Conectamos unha única plataforma de seguimento, xestión e recollida de datos sobre o alumeado público conectado, xestionando de forma remota toda a infraestrutura de alumeado público e dándolle servizo desde un único panel de control, dando solucións ás seguintes tarefas. Características: atenuar ou acender/apagar as luces de forma remota, individualmente ou en grupos, notificar automaticamente aos servizos da cidade de fallos nos puntos de iluminación para unha planificación máis eficiente do mantemento, proporcionar datos de consumo enerxético en tempo real, proporcionar potentes ferramentas analíticas para controlar e mellorar a iluminación pública. sistema baseado en Big Data, proporcionando datos de tráfico, aire acondicionado, integración con outros subsistemas de Smart City. Resultados: redución do consumo de enerxía para o alumeado público ata un 80%, aumentando a seguridade dos residentes mediante o uso de algoritmos de control de iluminación intelixente (unha persoa que camiña pola rúa - acende a luz para el, unha persoa no cruce - acende máis brillante) iluminación para que se vexa de lonxe), prestando para a cidade servizos adicionais (carga de vehículos eléctricos, achega de contidos publicitarios, videovixilancia, etc.).
En realidade, o que quería dicir: hoxe, cunha plataforma preparada (por exemplo, a nosa), pódese configurar a vixilancia de forma moi rápida e sinxela. Isto non require cambios nos equipos (ou mínimos, se aínda non hai sensores e transmisión de datos), non require custos de implantación e especialistas separados. Só cómpre estudar o tema, dedicar un par de días a entender o seu funcionamento e unhas semanas en aprobacións, acordo e intercambio de datos sobre protocolos. E despois diso terás datos precisos de todos os dispositivos. E todo isto pódese facer en todo o país co apoio do integrador Technoserv, é dicir, garantimos un bo nivel de fiabilidade, que non é o propio dunha startup.
Na seguinte publicación mostrarei como é o aspecto do provedor, usando o exemplo dunha implementación.
Fonte: www.habr.com