A mediados de octubre, como parte del foro juvenil U-NOVUS en Tomsk, realizamos un taller sobre ciencia de datos.
Tomsk, en principio, disfruta merecidamente de la fama de una ciudad de científicos y estudiantes, después de todo, 15 institutos de investigación, 9 universidades y varias incubadoras de empresas, esto es grave. Por lo tanto, decidimos invitar a estudiantes y expertos de varias compañías a participar.
Dimos un caso de la vida (lectura - de producción), era una tarea de análisis avanzado en una empresa petroquímica.
Sobre cómo fue, debajo del corte.
El taller duró 3 días, es decir, cuánto tiempo tuvieron los equipos para resolver nuestros problemas y demostrar que la solución creada por ellos es algo que realmente ayudará a la industria, o simplemente llevará una serie de mecanismos útiles que se pueden aplicar en la producción de química digital en el futuro.
Desafío
Era necesario crear un escenario de trabajo, en cuyo marco se llevaría a cabo el desarrollo e implementación de un sistema de monitoreo proactivo de los equipos tecnológicos que utilizamos en la producción.
Al mismo tiempo, era importante tener en cuenta que es lógico dividir dicho equipo en varios tipos (de acuerdo con la criticidad), por lo tanto, los enfoques para su administración y monitoreo no deberían ser los mismos, y un solo script no funcionaría aquí. También era necesario tener en cuenta que la empresa utiliza los sistemas de visualización más simples para los datos ya recopilados, que también se pueden utilizar. Además, le dimos una serie de factores a la carga: la influencia de la condición del equipo en el margen del producto; frecuencia de reparaciones programadas; Escenarios para instalar soportes adicionales en los casos en que un sistema de monitoreo básico ya está en su lugar, y así sucesivamente.
E inmediatamente prescribimos una serie de marcos y limitaciones que deben tenerse en cuenta, de lo contrario resultará que tomaste una decisión, pero no podrás aplicarla, porque olvidaste algunos de estos factores. Esto ayuda, porque tal solución debería funcionar en la producción en vivo, y pueden suceder muchas cosas diferentes en el proceso.
Entre estos factores estaban:
- Mala calidad de los datos recopilados.
- La presencia en el equipo para crear un sistema de monitoreo de especialistas con diversos conocimientos: programadores, tecnólogos de producción, personas familiarizadas con el equipo, así como expertos en el campo del modelado matemático.
- La falta de voluntad del personal para usar el nuevo sistema (bueno, de qué otra manera).
- Una falta total de datos para resolver problemas (no se considera algún parámetro, no hay un sensor que tome información, etc.).
- Si hay algún dato, puede haber dificultades con él; por ejemplo, no todos están digitalizados (pero debe trabajar con ellos), están almacenados en diferentes formatos, algunos no se pueden alcanzar con un par de clics y debe recorrer un par de círculos. aprobaciones
Componentes obligatorios del sistema: un módulo que encuentra anomalías en el equipo (algo se está calentando, se supone que no, algo cuelga, pero debería aguantar, y un comportamiento similar), y un módulo de pronóstico que puede predecir una situación similar en función de los datos ya recopilados .
En la salida, quería obtener una descripción detallada de la solución, lo que permitirá, teniendo en cuenta todas estas condiciones, introducir un sistema de monitoreo proactivo de los equipos. Podría incluir algoritmos de aprendizaje automático, cualquier solución y marco listos para usar.
Y es absolutamente ideal (y es por eso que había personas de la empresa como parte de los equipos): tener en cuenta los procesos comerciales que se verán afectados por la introducción de dicho sistema; incluso puede que tenga que introducir nuevos procesos comerciales para asegurarse de que la solución funcione.
Resumen
Debemos rendir homenaje a los equipos: demostraron ser excelentes. Los equipos estaban bastante mezclados, en el marco de uno, tanto estudiantes como programadores con analistas de datos y jefes de dirección, y los directores de compañías locales podían trabajar de inmediato. Y tal composición influyó enormemente en las soluciones resultantes, verificamos e inmediatamente notamos que alguien tenía un gran énfasis en la parte arquitectónica, alguien puso la interacción con los usuarios a la vanguardia, alguien decidió que lo principal era planificación y cumplimiento de KPI. En general, observa la solución e inmediatamente imagina quién la inventó exactamente.
Los criterios de evaluación para nosotros fueron bastante simples. Lo principal es la aplicabilidad práctica de la solución en nuestras empresas. Casi todos lograron, de las 6 soluciones presentadas, solo 2 no nos convenían en absoluto (aunque, con una muestra de 6, esta es una tercera). Pero la cuestión era que los chicos fallaron la solución en sí misma sin entrar en detalles, o la solución no era adecuada para la industria petroquímica. Por desgracia, esto también sucede, y parece que la solución en sí no es mala, resuelve problemas, tal vez incluso se escala, pero específicamente, no la usamos en absoluto, la pila no es la misma. En general
Las 4 soluciones restantes se mostraron perfectamente, decidimos que los chicos entienden exactamente lo que hicieron y lo que harán, por lo que ahora participarán en nuestros proyectos.
Nikolay Ksenzik, Jefe del Centro de Tecnologías Digitales en Tomsk, SIBUR IT.