Una de las ventajas de trabajar en una start-up es la posibilidad de tener una mayor cantidad de espacios, comparado con una empresa tradicional, para experimentar con diferentes tipos de tecnologías, frameworks y/o librerías, todo con el objetivo de resolver de la forma más costo eficiente los retos a resolver en la prestación de los servicios que ofrecemos.

En Uptime Analytics hemos pasado varias veces por las fases de ideación, prototipado y producto. En el último ciclo ejecutado nos concentramos en la idea de ofrecer una solución como servicio de analítica descriptiva y predictiva para hornos industriales de principio a fin.  Dicha solución incluye la recolección de datos en sitio, el almacenamiento de los datos “en bruto”, pasando por su transformación y cargue en un modelo de datos propio del dominio de hornos industriales, hasta la presentación y explotación de los datos a través de objetos descriptivos y predictivos accesibles a través de una interfaz gráfica web.

En la fase de prototipado el objetivo es poder probar lo más rápido posible la idea, validarla con clientes actuales y con prospectos, por lo tanto, la herramienta principal utilizada fue la plataforma de Qlik. Esta herramienta es utilizada principalmente por dos razones: desarrollo rápido que nos permite cubrir múltiples componentes de la solución, específicamente la transformación de datos, creación y uso de un modelo de datos y por su presentación visualización de los objetos descriptivos y predictivos; como segunda razón, contamos con expertise in-house con un nivel alto dentro de la empresa. Ahora bien, para la parte de recolección de datos desde la fuente, en etapa de prototipo lo clave es poder contar con los datos, así que lo clave es poder extraer los datos manualmente en algún formato no propietario, normalmente en formato CSV o XLSX.

En la fase de producto el objetivo es convertir el prototipo en un servicio escalable, reproducible entre clientes y operacional. Analizando los diferentes componentes de la solución se hizo aparente que no todos podían llegar a cumplir totalmente dichos objetivos, revisemos cada uno de los componentes:

  • Recolección de los datos en sitio: la meta es automatizar lo que previamente es una tarea manual y dispendiosa, lo logramos a través de la combinación de nuestro Signal Hub que se instala en las plantas del cliente, y servicios de recolección y almacenamiento local (en caso de pérdida de conectividad). El tema aquí es que debido a la variedad de diferencias entre clientes es difícil contar con un producto de caja que cubra todas las necesidades. Nos hemos encontrado con esquemas de extracción común usando Modbus-RTU/TCP, hasta escenarios más complejos donde el dato reside en sistemas con estructuras de datos propietarios, pasando por escenarios en los cuales ha sido necesario crear circuitos especializados para leer pulsos eléctricos. En el corto plazo queremos ir consolidando los diferentes esquemas de extracción que nos hemos encontrado y crear una librería reutilizable de código para ser usado en los próximos clientes.
    Tanto en la fase de prototipado como en la fase de producto hemos mantenido una combinación de AWS DynamoDB y AWS S3, para almacenar los datos “en bruto” que se obtienen de las plantas del cliente.
  • Tareas programadas: como se mencionó anteriormente, en la fase de prototipado se desarrollan usando la plataforma de Qlik, pero en la fase de producto se desarrollan usando Apache Airflow como nuestra plataforma de ETL. ¿Porque el cambio? Contar con un mayor pool de personas disponible para desarrollar ETL’s en el mercado (el requerimiento básico para desarrollar es que conozcan Python), y el no requerir costos de licenciamiento para su uso.
    Al igual que el componente anterior, las ETL’s varían entre cliente/fuente de datos aunque en menor medida que la recolección de datos, en este caso si ha sido posible diseñar y desarrollar librerías estándar que permitan escalar más rápidamente la adquisición de nuevos clientes; aunque todavía hay temas por seguir evolucionado, las bases definidas y desarrolladas son lo suficientemente sólidas para seguir creciendo.
    En el mediano plazo tenemos contemplado experimentar con esquemas de streaming para escenarios de detección de anomalías casi en tiempo real.
  • Modelo de datos estándar de hornos industriales: para este componente los prototipos funcionales también fueron desarrollados usando la plataforma de Qlik, pero ahora estamos usando bases de datos optimizadas para datos de series de tiempo, y que adicionalmente también brindan la libertad de combinarla con datos en estructura relacional tradicional para almacenar datos categóricos que brindan contexto a los datos que se visualizan. ¿Por qué el cambio? En esencia, las mismas del punto anterior, con la salvedad de que no es necesario conocer Python, sino tener conocimientos SQL.
    En el corto plazo tenemos en el radar hacer pruebas de concepto y experimentar con mayor profundidad bases de datos especializadas en analítica a gran escala, entre otros Apache Druid, ¿por qué? Prepararnos, en un futuro no muy lejano, para volúmenes de datos mayores que la actual arquitectura no soporte.
    A este nivel contamos con un componente escalable, reproducible, operacional y transversal para todos los hornos industriales actuales más los que incluyamos a futuro.
  • Tableros con objetos descriptivos y predictivos: este es el cambio más grande de cara a nuestros clientes, decidimos movernos a una plataforma de visualización, usando diferentes componentes open source, que nos ofreciera flexibilidad para agregar nuevas capacidades sin depender de un tercero, hiciera uso de tecnologías abiertas y modernas (Flask, React) y permitiera a nuestros clientes la capacidad para hacer análisis con los datos depurados y procesados de manera independiente a Uptime Analytics de forma costo-eficiente (sin estar atado a la cantidad de usuarios).
    Este componente está diseñado y desarrollado para ser completamente transversal, cumpliendo con las condiciones para ser considerado un producto.

Otro elemento importante que tenemos presente en nuestra evolución arquitectónica es el desarrollar la capacidad (tecnología, proceso, conocimiento) para poder utilizar los componentes arquitectónicos descritos hasta el momento como base para futuras líneas de solución orientadas a otros tipos de equipos industriales como generadores eléctricos, transformadores, motores de combustión, entre otros.

Como se ha visto hasta el momento hacemos uso extensivo de varios proyectos open source, por lo tanto, también es importante mencionar nuestra intención de ser “good citizen” en el mundo open source, a través de aportes al código fuente, documentación, participación en meetups, entre otros. Lo anterior es importante porque creemos que al participar activamente en este tipo de comunidades se construye un vínculo donde ambas partes nos beneficiamos, lo cual al final nos permite ofrecer una oferta de valor más robusta a nuestros clientes.

Como empresa, Uptime Analytics está constantemente revisando y evaluando nuevas tendencias y tecnologías para determinar su utilidad en la resolución de las problemáticas a la cuales se enfrenta nuestros clientes. Creemos que es un imperativo que toda empresa debe tener directa o indirectamente a través de proveedores de servicios como nosotros. Por último, hasta el momento he dejado a un lado el entrenamiento y ejecución de modelos predictivos desde el punto de vista tecnológico, este tema será objeto de un próximo post

Autor: Omar Ashton – CTO en Uptime Analytics

Dirección Colombia

Bogotá: 

Easywork Calle 103 #13A – 06

Medellín: 

Ruta N Calle 67 #52-50 Torre A

Teléfono

(57) 318 252 7551

© Uptime analytics 2020 | Política de tratamiento de datos

Un desarrollo de evendidigital.com