¡Hola Habr! Nuestro equipo monitorea máquinas e instalaciones diversas en todo el país. Básicamente, brindamos la oportunidad al fabricante de no tener que enviar a un ingeniero una vez más cuando “oh, está todo roto”, cuando en realidad solo necesita presionar un botón. O cuando se averió no en el equipo, sino cerca.
El problema básico es el siguiente. Aquí se produce una unidad de craqueo de petróleo, una máquina herramienta para la ingeniería mecánica o algún otro dispositivo para una planta. Por regla general, la venta en sí es muy rara vez posible: normalmente se trata de un contrato de suministro y servicios. Es decir, usted garantiza que la pieza de hardware funcionará durante 10 años sin interrupciones, y de las interrupciones usted es responsable financieramente, o proporciona SLA estrictos, o algo similar.
De hecho, esto significa que es necesario enviar un ingeniero al sitio con regularidad. Como muestra nuestra práctica, del 30 al 80% de los viajes son innecesarios. En el primer caso, sería posible descubrir qué sucedió de forma remota. O pídale al operador que presione un par de botones y todo funcionará. El segundo caso son los esquemas "grises". Esto es cuando un ingeniero sale, programa reemplazos o trabajos complejos y luego divide la compensación a la mitad con alguien de la fábrica. O simplemente disfruta de sus vacaciones con su amante (un caso real) y por eso le gusta salir más a menudo. A la planta no le importa.
La instalación de monitoreo requiere modificar el hardware con un dispositivo de transmisión de datos, la transmisión en sí, algún tipo de lago de datos para almacenarlos, protocolos de análisis y un entorno de procesamiento con la capacidad de ver y comparar todo. Bueno, todo esto tiene matices.
¿Por qué no podemos prescindir del monitoreo remoto?
Es cursi y caro. Viaje de negocios para un ingeniero: al menos 50 mil rublos (avión, hotel, alojamiento, dieta). Además, no siempre es posible separarse y es posible que se necesite a la misma persona en diferentes ciudades.
- En Rusia, el proveedor y el consumidor casi siempre están bastante alejados el uno del otro. Cuando vendes un producto a Siberia, no sabes nada más que lo que te dice el proveedor. Ni cómo funciona, ni en qué condiciones se utiliza, ni, de hecho, quién presionó qué botón con las manos torcidas; objetivamente no tienes esta información, solo puedes conocerla por las palabras del consumidor. Esto dificulta mucho el mantenimiento.
- Recursos y reclamaciones infundados. Es decir, tu cliente, que está usando tu producto, puede llamar, escribir, quejarse en cualquier momento y decir que tu producto no funciona, está malo, está roto, ven urgente y arréglalo. Si tiene suerte y no se trata simplemente de que "no se llenaron los consumibles", entonces no envió a un especialista en vano. A menudo sucede que el trabajo útil tomó menos de una hora, y todo lo demás (preparar un viaje de negocios, vuelos, alojamiento) requirió mucho tiempo del ingeniero.
- Hay afirmaciones claramente infundadas y, para demostrarlo, es necesario enviar a un ingeniero, redactar un informe y acudir a los tribunales. Como resultado, el proceso se retrasa y esto no aporta nada bueno ni para el cliente ni para usted.
- Las disputas surgen debido al hecho de que, por ejemplo, el cliente operó el producto incorrectamente, el cliente por alguna razón le guarda rencor y no dice que su producto no funcionó correctamente, no en los modos indicados en las especificaciones técnicas y en el pasaporte. Al mismo tiempo, no puede hacer nada contra esto, o puede hacerlo, pero con dificultad, si, por ejemplo, su producto de alguna manera registra y registra esos modos. Averías por culpa del cliente: esto sucede todo el tiempo. Tuve un caso en el que una costosa máquina de pórtico alemana se rompió debido a una colisión con un poste. El operador no lo puso a cero y, como resultado, la máquina se detuvo allí. Además, el cliente dijo claramente: "No tenemos nada que ver con eso". Pero la información se registró y fue posible buscar estos registros y comprender qué programa de control se utilizó y como resultado de cuál ocurrió esta colisión. Esto le ahorró al proveedor costes muy elevados por reparaciones en garantía.
- Los esquemas “grises” mencionados son una conspiración con el proveedor de servicios. El mismo técnico de servicio acude al cliente todo el tiempo. Le dicen: “Escucha, Kolya, hagámoslo como quieras: escribe que aquí todo está roto, recibiremos una compensación o traes algún tipo de cremallera para reparar. Todo esto lo implementaremos discretamente y dividiremos el dinero”. Todo lo que queda es creer o inventar de alguna manera algunas formas complicadas de verificar todas estas conclusiones y confirmaciones, lo que no agrega tiempo ni nervios, y no sucede nada bueno en esto. Si está familiarizado con la forma en que los servicios de automóviles abordan el fraude de garantía y la complejidad que esto impone a los procesos, entonces comprenderá a grandes rasgos el problema.
Bueno, los dispositivos todavía escriben registros, ¿verdad? ¿Cuál es el problema?
El problema es que si los proveedores entienden más o menos que el registro debe escribirse constantemente en algún lugar (o lo han entendido durante las últimas décadas), entonces la cultura no ha ido más lejos. El registro suele ser necesario para analizar casos de reparaciones costosas, ya sea un error del operador o una avería real del equipo.
Para recoger un registro, a menudo es necesario acercarse físicamente al equipo, abrir algún tipo de carcasa, exponer el conector de servicio, conectarle un cable y recoger los archivos de datos. Luego, tómelos persistentemente durante varias horas para tener una idea de la situación. Por desgracia, esto sucede en casi todas partes (bueno, o tengo un punto de vista unilateral, ya que trabajamos precisamente con aquellas industrias donde recién se está estableciendo el monitoreo).
Nuestros principales clientes son fabricantes de equipos. Normalmente, empiezan a pensar en realizar algún tipo de seguimiento, ya sea después de un incidente importante o simplemente mirando sus facturas de viajes del año. Pero la mayoría de las veces estamos hablando de un fracaso importante con pérdida de dinero o de reputación. Los líderes progresistas que piensan en “pase lo que pase” son raros. El hecho es que normalmente el gerente adquiere el antiguo "parque" de contratos de servicio y no ve ningún sentido en instalar sensores en hardware nuevo, porque sólo será necesario en un par de años.
Por lo general, en algún momento el gallo asado todavía muerde, y llega el momento de modificaciones.
La transferencia de datos en sí no da mucho miedo. Por lo general, el equipo ya tiene sensores (o se instalan con bastante rapidez), además ya se escriben registros y se anotan los eventos de servicio. Todo lo que necesitas hacer es comenzar a enviarlo. La práctica general es insertar algún tipo de módem, por ejemplo, con una SIM integrada, directamente en el dispositivo desde la máquina de rayos X a la sembradora automática y enviar la telemetría a través de la red celular. Los lugares donde no hay cobertura móvil suelen estar bastante lejos y se han vuelto raros en los últimos años.
Y entonces comienza la misma pregunta que antes. Sí, ahora hay registros. Pero es necesario ponerlos en algún lugar y leerlos de alguna manera. En general, se necesita algún tipo de sistema de visualización y análisis de incidencias.
Y luego aparecemos en el escenario. Más precisamente, a menudo llegamos antes, porque los gerentes de los proveedores observan lo que están haciendo sus colegas e inmediatamente acuden a nosotros para pedirnos consejo sobre la selección del hardware para enviar telemetría.
Nicho de mercado
En Occidente, la solución a esta situación se reduce a tres opciones: el ecosistema de Siemens (muy caro, necesario para unidades muy grandes, normalmente como turbinas), módulos escritos por uno mismo o la ayuda de uno de los integradores locales. Como resultado, cuando todo esto llegó al mercado ruso, se formó un entorno en el que estaban Siemens con sus partes del ecosistema, Amazon, Nokia y varios ecosistemas locales como los desarrollos de 1C.
Entramos al mercado como un vínculo unificador que nos permite recopilar cualquier dato de cualquier dispositivo utilizando cualquier protocolo (bueno, casi cualquier protocolo más o menos moderno), procesarlos juntos y mostrárselos a una persona en cualquier forma requerida: para esto tenemos SDK geniales para todos los entornos de desarrollo y diseñadores de interfaces visuales de usuario.
Como resultado, podemos recopilar todos los datos del dispositivo del fabricante, almacenarlos en el servidor y montar allí un panel de seguimiento con alertas.
Esto es lo que parece (aquí el cliente también hizo una visualización de la empresa, esto son varias horas en la interfaz):
Y hay gráficos del equipo:
Las alertas tienen este aspecto: a nivel de máquina, si se ha excedido la fuerza sobre el órgano ejecutivo o se ha producido una colisión, se configura un conjunto de parámetros y el sistema informará al departamento o a los servicios de reparación cuando se superen.
Bueno, lo más difícil es predecir el fallo de los nodos en función de su estado para la prevención. Si comprende el recurso de cada uno de los nodos, podrá reducir considerablemente los costos de aquellos contratos en los que existe un pago por el tiempo de inactividad.
Resumen
Esta historia parecería bastante simple: bueno, nos dimos cuenta de que necesitábamos enviar datos, seguimiento y análisis, así que elegimos un proveedor y lo implementamos. Bueno, eso es todo, todos contentos. Si hablamos de sistemas escritos por nosotros mismos en nuestra propia fábrica, entonces, por extraño que parezca, los sistemas rápidamente se vuelven poco fiables. Estamos hablando de pérdidas banales de registros, datos inexactos, fallas en la recopilación, almacenamiento y recepción. Uno o dos años después de la instalación, los registros antiguos comienzan a eliminarse, lo que tampoco siempre termina bien. Aunque existe una práctica: se recopilan 10 GB de una máquina por año. Esto se soluciona durante cinco años comprando otro disco duro por 10 mil rublos... En algún momento resulta que no es el equipo transmisor en sí el principal, sino el sistema que permite analizar los datos recibidos. La comodidad de la interfaz es importante. Este es generalmente el problema de todos los sistemas industriales: comprender rápidamente la situación no siempre es fácil. Es importante la cantidad de datos visibles en el sistema, la cantidad de parámetros del nodo, la capacidad del sistema para operar con un gran volumen y cantidad de datos. Configuración de paneles, un modelo integrado del propio dispositivo, un editor de escenas (para dibujar diseños de producción).
Pongamos un par de ejemplos de lo que esto aporta en la práctica.
- Aquí se encuentra un fabricante mundial de equipos de refrigeración industrial utilizados principalmente en cadenas minoristas. El 10% de los ingresos de la empresa proviene de la prestación de servicios para el mantenimiento de sus productos. Es necesario reducir el coste de los servicios y, en general, dar la posibilidad de aumentar la oferta con normalidad, porque si vendemos más, el sistema de servicios existente no dará abasto. Nos conectamos directamente a la plataforma de un único centro de servicios, modificamos un par de módulos para las necesidades de este cliente en particular y obtuvimos una reducción del 35% en los gastos de viaje debido a que el acceso a la información del servicio permite identificar las causas. de falla sin la necesidad de que un ingeniero de servicio lo visite. Análisis de datos durante largos períodos de tiempo: prediga la condición técnica y, si es necesario, realice rápidamente un mantenimiento basado en la condición. Como beneficio adicional, la velocidad de respuesta a las solicitudes ha aumentado: hay menos viajes de campo y los ingenieros pueden hacer las cosas más rápido.
- Empresa de ingeniería mecánica, fabricante de vehículos eléctricos utilizados en muchas ciudades de la Federación de Rusia y la CEI. Como todos, quieren reducir costes y al mismo tiempo predecir el estado técnico de las flotas de trolebuses y tranvías de la ciudad para avisar oportunamente al personal técnico. Conectamos y creamos algoritmos para recopilar y transmitir datos técnicos del material rodante a un único centro de situación (los algoritmos están integrados directamente en el sistema de control de conducción y funcionan con datos del bus CAN). El acceso remoto a los datos del estado técnico, incluido el acceso en tiempo real a parámetros cambiantes (velocidad, voltaje, transferencia de energía recuperada, etc.) en modo "osciloscopio", dio acceso a actualizaciones remotas del firmware. El resultado es una reducción de los costos de viaje en un 50%: el acceso directo a la información del servicio permite identificar las causas de las fallas sin la necesidad de que un ingeniero de servicio lo visite, y el análisis de los datos durante largos intervalos de tiempo le permite predecir el condición técnica y, si es necesario, realizar rápidamente el mantenimiento “basado en la condición”, incluido el análisis objetivo de situaciones de emergencia. Implementación de contratos de ciclo de vida extendido en total conformidad con los requisitos del Cliente y en tiempo. Cumplir con los requisitos de las especificaciones técnicas del operador, así como brindarle nuevas oportunidades en términos de seguimiento de las características del servicio al consumidor (calidad del aire acondicionado, aceleración/frenado, etc.).
- El tercer ejemplo es un municipio. Necesitamos ahorrar electricidad y mejorar la seguridad de los ciudadanos. Conectamos una única plataforma para monitorear, gestionar y recopilar datos del alumbrado público conectado, gestionando de forma remota toda la infraestructura de alumbrado público y dándole servicio desde un único panel de control, brindando soluciones a las siguientes tareas. Características: atenuar o encender/apagar las luces de forma remota, individual o en grupos, notificar automáticamente a los servicios de la ciudad sobre fallas en los puntos de iluminación para una planificación de mantenimiento más eficiente, proporcionar datos de consumo de energía en tiempo real, proporcionar poderosas herramientas analíticas para monitorear y mejorar el alumbrado público Sistema basado en Big Data, que proporciona datos sobre tráfico, climatización, integración con otros subsistemas de Smart City. Resultados: reducir el consumo de energía para el alumbrado público hasta en un 80%, aumentar la seguridad de los residentes mediante el uso de algoritmos inteligentes de control de iluminación (una persona que camina por la calle, enciende la luz, una persona en el cruce, enciende más brillante iluminación para que pueda ser visto desde lejos), dotando a la ciudad de servicios adicionales (recarga de vehículos eléctricos, provisión de contenidos publicitarios, videovigilancia, etc.).
En realidad, lo que quería decir: hoy, con una plataforma ya preparada (por ejemplo, la nuestra), es posible configurar el seguimiento de forma muy rápida y sencilla. Esto no requiere cambios en el equipo (o mínimos, si aún no hay sensores y transmisión de datos), no requiere costos de implementación ni especialistas separados. Sólo hace falta estudiar el tema, dedicar un par de días a entender cómo funciona y unas semanas a aprobaciones, acuerdos e intercambio de datos sobre protocolos. Y después de eso tendrás datos precisos de todos los dispositivos. Y todo esto se puede hacer en todo el país con el apoyo del integrador Technoserv, es decir, garantizamos un buen nivel de confiabilidad, lo cual no es típico de una startup.
En la próxima publicación mostraré cómo se ve esto desde el lado del proveedor, usando el ejemplo de una implementación.
Fuente: habr.com