URALCHEM fabrica fertilizantes. No. 1 en Rusia: para la producción de nitrato de amonio, por ejemplo, se encuentra entre los 3 principales productores nacionales de amoníaco, urea y fertilizantes nitrogenados. Se producen ácidos sulfúricos, fertilizantes de dos tres componentes, fosfatos y mucho más. Todo esto crea entornos agresivos en los que fallan los sensores.
Construimos Data Lake y al mismo tiempo buscamos aquellos sensores que se congelan, fallan, comienzan a dar datos falsos y generalmente se comportan de manera diferente a como deberían comportarse las fuentes de información. Y el "truco" es que es imposible construir modelos matemáticos y gemelos digitales sobre la base de datos "malos": simplemente no resolverán el problema correctamente y darán un efecto comercial.
Pero las fábricas modernas necesitan Data Lake para los científicos de datos. En el 95% de los casos, los datos "sin procesar" no se recopilan de ninguna manera, sino que solo se tienen en cuenta los agregados en el sistema de control del proceso, que se almacenan durante dos meses y se almacenan los puntos de "cambio en la dinámica" del indicador, que se calculan mediante un algoritmo especialmente establecido, que para los científicos de datos reduce la calidad de los datos, porque ., quizás, puede perder las "ráfagas" del indicador ... En realidad, algo así sucedió en URALCHEM. Era necesario crear un almacén de datos de producción, recoger las fuentes en las tiendas y en los sistemas MES / ERP. En primer lugar, esto es necesario para comenzar a recopilar el historial para la ciencia de datos. En segundo lugar, para que los científicos de datos tengan una plataforma para sus cálculos y un sandbox para probar hipótesis, y no cargar el mismo donde está girando el sistema de control de procesos.Los científicos de datos intentaron analizar los datos disponibles, pero esto no fue suficiente. Los datos se almacenaron diezmados, con pérdidas, a menudo inconsistentes con el sensor. No era posible tomar un conjunto de datos rápidamente y tampoco había ningún lugar para trabajar con él.
Ahora volvamos a qué hacer si el sensor "funciona".
Cuando construyes un lago
No es suficiente construir algo así:
también debe demostrarle a la empresa que todo funciona y mostrar un ejemplo de un proyecto terminado. Está claro que hacer un proyecto en una combinación de este tipo se trata de cómo construir el comunismo en un solo país, pero las condiciones son exactamente esas. Tomamos un microscopio y demostramos que pueden clavar un clavo.
A nivel mundial, URALCHEM tiene la tarea de digitalizar la producción. Como parte de toda esta acción, en primer lugar, realizar un sandbox para probar hipótesis, aumentar la eficiencia del proceso de producción, así como desarrollar modelos predictivos de fallas de equipos, sistemas de apoyo a la decisión y así reducir el número de paradas y mejorar la calidad de los procesos de producción. Aquí es cuando sabe de antemano que algo está a punto de fallar y puede repararlo una semana antes de que la máquina comience a destrozar todo lo que hay a su alrededor. Beneficio: reducir los costos de producción y mejorar la calidad del producto.
Así surgieron los criterios para la plataforma y los requisitos básicos para el piloto: almacenamiento de gran cantidad de información, acceso online a datos de sistemas de inteligencia empresarial, cálculos cercanos al tiempo real para emitir recomendaciones o notificaciones lo antes posible.
Trabajamos las opciones de integración y nos dimos cuenta de que para el rendimiento y la operación en modo NRT, necesita trabajar solo a través de su conector, que agregará datos a Kafka (un agente de mensajes escalable horizontalmente, que solo le permite "suscribirse al evento" de cambiar la lectura del sensor, y en función de de este evento sobre la marcha para realizar cálculos y generar notificaciones). Por cierto, Artur Khismatullin, jefe del departamento de desarrollo de sistemas de producción, la rama OTSO de URALCHEM JSC, nos ayudó mucho.
¿Qué se necesita, por ejemplo, para hacer un modelo predictivo de falla de equipo?
Esto requiere telemetría de cada nodo en tiempo real o en porciones cercanas a él. Es decir, no una vez por hora un estado general, sino lecturas directamente específicas de todos los sensores por cada segundo.
Nadie recopila ni almacena estos datos. Además, necesitamos datos históricos de al menos seis meses, y en el sistema de control de procesos, como dije, se almacenan como máximo los últimos tres meses. Es decir, debe comenzar con el hecho de que los datos se recopilarán en algún lugar, se escribirán en algún lugar y se almacenarán en algún lugar. Datos de unos 10 GB por nodo al año.
Además, necesitará trabajar con estos datos de alguna manera. Esto requiere una instalación que le permita normalmente hacer selecciones de la base de datos. Y es deseable que en uniones complejas no todo se levante por un día. Especialmente más tarde, cuando la producción comienza a agregar más problemas de predicción del matrimonio. Bueno, para las reparaciones predictivas, también hay un informe vespertino de que la máquina puede averiarse cuando se averió hace media hora, un caso regular.
Como resultado, el lago es necesario para los científicos de datos.
A diferencia de otras soluciones similares, todavía teníamos la tarea del tiempo real en Hadoop. Porque las próximas grandes tareas son los datos sobre la composición del material, el análisis de la calidad de las sustancias, el consumo de material de producción.
En realidad, cuando construimos la plataforma, lo siguiente que la empresa quería de nosotros era que recopilamos datos sobre la falla de los sensores y construyamos un sistema que nos permita enviar trabajadores para cambiarlos o repararlos. Y al mismo tiempo marca el testimonio de ellos como erróneo en la historia.
Sensores
En producción, un entorno agresivo, los sensores funcionan de manera difícil y a menudo fallan. Idealmente, también se necesita un sistema de monitoreo predictivo para los sensores, pero primero, al menos evaluaciones de cuáles mienten y cuáles no.
Resultó que incluso un modelo simple para determinar qué hay con el sensor es fundamental para una tarea más: construir un equilibrio matemático. Planificación adecuada del proceso: cuánto y qué debe introducirse, cómo calentarlo, cómo procesarlo: si la planificación es incorrecta, no está claro cuánta materia prima se necesita. No se producirán suficientes productos, la empresa no obtendrá ganancias. Si hay más de lo necesario, nuevamente una pérdida, porque necesita almacenar. El balance de material correcto solo se puede obtener a partir de la información correcta de los sensores.
Entonces, en nuestro proyecto piloto, se eligió el monitoreo de la calidad de los datos de producción.
Nos sentamos con los tecnólogos para obtener los datos "sin procesar", miramos las fallas confirmadas del equipo. Las dos primeras razones son muy simples.
Aquí, el sensor de repente comienza a mostrar datos que, en principio, no deberían ser: lo
más probable es que este pico local sea el momento en que el sensor se volvió malo térmica o químicamente.
También se va más allá de los límites de medición permitidos (cuando hay una cantidad física como la temperatura del agua de 0 a 100). A cero, el agua no se mueve por el sistema y a 200 es vapor, y lo hubiéramos notado por la ausencia de un techo sobre el taller.
El segundo caso también es casi trivial: los
datos del sensor no cambian durante varios minutos seguidos; esto no sucede en una producción en vivo. Probablemente algo con el dispositivo.
El 80% de los problemas se resuelven mediante el seguimiento de estos patrones sin Big Data, correlaciones e historial de datos. Pero para una precisión superior al 99%, debe agregar otra comparación con otros sensores en los nodos vecinos, en particular, antes y después de la sección de la que proviene la telemetría dudosa: La
producción es un sistema equilibrado: si un indicador cambia, el otro también debe cambiar. En el marco del proyecto, se formaron reglas sobre la relación de indicadores, y estas relaciones fueron "normalizadas" por los tecnólogos. Según estas pautas, un sistema basado en Hadoop puede identificar sensores potencialmente inoperantes.
Los operadores de la planta estaban complacidos de que los sensores se detectaran correctamente, ya que esto significaba que podían enviar rápidamente a un reparador o simplemente limpiar el sensor deseado.
En realidad, el piloto terminó enumerando sensores potencialmente inoperantes en la tienda que muestran información incorrecta.
Puede preguntar cómo se implementó la respuesta a las condiciones de emergencia y preemergencia antes y cómo se convirtió después del proyecto. Responderé que la reacción a un accidente no se ralentiza, porque en tal situación, varios sensores muestran el problema a la vez.
O el tecnólogo o el jefe de departamento es responsable de la eficiencia de la instalación (y acciones en caso de accidentes). Entienden perfectamente qué y cómo está sucediendo con su equipo, y saben cómo ignorar algunos de los sensores. Los sistemas de control de procesos que acompañan a la instalación son los responsables de la calidad de los datos. Normalmente, cuando el sensor está dañado, no se pone en modo no operativo. Para el tecnólogo, sigue siendo un trabajador, el tecnólogo debe reaccionar. El tecnólogo revisa el evento y descubre que no pasó nada. Se ve así: "Analizamos solo la dinámica, no miramos los absolutos, sabemos que son incorrectos, necesitamos ajustar el sensor". "Destacamos" a los especialistas del sistema automatizado de control de procesos que el sensor está mal y dónde está mal. Ahora, en lugar de una ronda formal planificada, primero repara dispositivos específicos de manera específica y luego realiza rondas, sin confiar en la tecnología.
Para que quede más claro cuánto tiempo lleva una caminata planificada, simplemente diré que hay de tres a cinco mil sensores en cada uno de los sitios. Hemos proporcionado una herramienta de análisis integral que proporciona datos procesados, sobre cuya base un especialista debe tomar una decisión sobre la verificación. Basándonos en su experiencia, “resaltamos” exactamente lo que se necesita. Ya no necesita verificar manualmente cada sensor, y se reduce la probabilidad de que se pierda algo.
Cual es el resultado
Recibí la confirmación comercial de que la pila se puede usar para resolver problemas de producción. Almacenamos y procesamos datos del sitio. La empresa ahora debe elegir los siguientes procesos para que los científicos de datos operen. Mientras designan a una persona responsable del control de calidad de los datos, redactan reglamentos para él e implementan esto en su proceso de producción.
Así es como implementamos este caso: Los
tableros se ven así : Se muestran
en esos lugares:
Lo que tenemos:
- se creó un espacio de información a nivel tecnológico para trabajar con lecturas de sensores de equipos;
- verificó la capacidad de almacenar y procesar datos basados en tecnología Big Data;
- probó la capacidad de los sistemas de inteligencia empresarial (por ejemplo, Power BI) para trabajar con un lago de datos construido en la plataforma Arenadata Hadoop;
- se introdujo un almacenamiento analítico unificado para recopilar información de producción de los sensores de los equipos con la posibilidad de almacenar información a largo plazo (el volumen planificado de datos acumulados para el año es de aproximadamente dos terabytes);
- se han desarrollado mecanismos y métodos para obtener datos en un modo casi en tiempo real;
- desarrolló un algoritmo para determinar las desviaciones y el funcionamiento incorrecto de los sensores en el modo de tiempo casi real (cálculo: una vez por minuto);
- Se realizaron pruebas del funcionamiento del sistema y la capacidad de generar informes en la herramienta BI.
La conclusión es que hemos resuelto completamente un problema de producción: hemos automatizado un proceso de rutina. Entregamos una herramienta de pronóstico y liberamos tiempo para que los tecnólogos resuelvan problemas más inteligentes.
Y si todavía tiene preguntas que no son para comentarios, aquí está el correo: chemistry@croc.ru