De los datos del pozo a la decisión operacional: cómo integrar Streamlit, KNIME, Orange, NiFi, Kappa, TimescaleDB, Grafana y APIs REST en Oil & Gas

La industria Oil & Gas produce datos de manera permanente. Cada pozo, bomba, variador de frecuencia, sensor de fondo, estación de producción, sistema SCADA y plataforma de supervisión genera señales que describen parcialmente el comportamiento de los activos. Sin embargo, disponer de grandes volúmenes de información no garantiza que una organización pueda utilizarlos para mejorar su operación.

Una presión registrada cada cinco segundos, una temperatura de motor, una frecuencia de operación o una tasa de producción solamente adquieren valor cuando pueden relacionarse con un activo, un momento, una condición operacional y una decisión concreta. El verdadero desafío no consiste en capturar más datos, sino en construir una arquitectura capaz de recibirlos, validarlos, contextualizarlos, almacenarlos, analizarlos y presentarlos de forma comprensible.

Esta necesidad explica por qué una solución industrial moderna no puede depender exclusivamente de un dashboard, una base de datos o una herramienta de Inteligencia Artificial. Se requiere un ecosistema compuesto por diferentes tecnologías, cada una especializada en una etapa del ciclo de vida del dato.

En este contexto, herramientas como Apache NiFi, Kappa, TimescaleDB, Grafana, las APIs REST, Streamlit, KNIME y Orange pueden interrelacionarse para crear soluciones completas. Algunas administran el flujo de información, otras conservan el histórico, algunas facilitan el análisis y otras presentan los resultados a operadores, ingenieros y gerentes.

AABO Services ha venido aplicando este enfoque en desarrollos como AABO OPERATIONS y BESIA, donde la información operacional se integra dentro de arquitecturas diseñadas para crecer desde entornos de simulación hasta escenarios con fuentes industriales reales.

El problema no es la falta de datos, sino su fragmentación

En muchas operaciones petroleras, la información se encuentra distribuida entre sistemas especializados que fueron implementados en momentos diferentes y con objetivos particulares. Los datos de producción pueden residir en una base corporativa, mientras las variables eléctricas están disponibles en un sistema de control, las alarmas en otra plataforma y los documentos técnicos en repositorios separados.

Esta fragmentación provoca que los especialistas deban realizar comparaciones manuales, descargar archivos, construir hojas de cálculo y consultar varias aplicaciones antes de entender lo que sucede en un pozo.

También genera inconsistencias. Un sistema puede identificar un activo con el nombre oficial del pozo, mientras otro utiliza una abreviatura. Una variable puede almacenarse en psi y otra en kilopascales. Algunas fechas pueden registrarse en hora local y otras en tiempo universal. Si estas diferencias no se corrigen, el análisis puede producir conclusiones equivocadas.

Una arquitectura integrada debe resolver estas variaciones antes de presentar la información. Esto significa que el flujo no puede limitarse a copiar registros entre sistemas. Debe identificar cada activo, normalizar unidades, verificar fechas, controlar duplicados, validar rangos y conservar evidencia del origen de cada dato.

La arquitectura debe seguir el ciclo de vida del dato

Una arquitectura moderna para Oil & Gas puede comprenderse como una secuencia de capas. Primero aparecen las fuentes operacionales. Después se encuentra la base que recibe y organiza las lecturas recientes. A continuación se incorporan los mecanismos que extraen, validan y transportan la información. Posteriormente se encuentra el repositorio histórico de series temporales. Finalmente aparecen las APIs, las aplicaciones analíticas, los dashboards y los modelos de Inteligencia Artificial.

Cada componente debe cumplir una responsabilidad concreta. Cuando una misma herramienta intenta capturar, transformar, almacenar, analizar y visualizar todo, la solución se vuelve difícil de mantener. La separación de funciones permite modificar una capa sin reconstruir toda la plataforma.

La siguiente arquitectura representa un modelo reutilizable para proyectos de producción, supervisión de pozos, bombas electrosumergibles y monitoreo operacional:

flowchart LR
    A[SCADA, LOWIS, sensores, archivos y APIs externas] --> B[PostgreSQL operacional]

    B --> C[Kappa<br/>Lectura, normalización y preparación]
    C --> D[Apache NiFi<br/>Orquestación, validación y trazabilidad]
    D --> E[TimescaleDB<br/>Históricos y series temporales]

    E --> F[API REST<br/>Acceso controlado a los datos]
    E --> G[Grafana<br/>Monitoreo y tendencias]

    F --> H[Aplicación web corporativa]
    F --> I[Streamlit<br/>Laboratorios analíticos]

    E --> J[KNIME<br/>Procesamiento y modelos]
    E --> K[Orange<br/>Experimentación de Machine Learning]

    J --> F
    K --> J

    H --> L[Operadores, ingenieros y gerencia]
    G --> L
    I --> M[Especialistas y analistas]

Esta estructura permite comenzar con datos sintéticos y reemplazarlos posteriormente por fuentes reales sin modificar por completo la experiencia del usuario. La aplicación puede continuar utilizando las mismas APIs, aunque la información ya no provenga de un simulador, sino de LOWIS, SCADA o un sistema corporativo.

Apache NiFi como columna vertebral del flujo de datos

Apache NiFi es una plataforma diseñada para automatizar el movimiento de información entre sistemas. Su función principal es recibir datos, evaluarlos, transformarlos, dirigirlos hacia diferentes destinos y registrar qué ocurrió durante el proceso.

En un proyecto Oil & Gas, NiFi puede consultar periódicamente una base operacional, identificar nuevos registros, verificar que tengan una fecha válida, comprobar que el activo exista en el catálogo y enviar las lecturas hacia un repositorio histórico.

También puede administrar condiciones de error. Si un registro llega sin nombre de pozo, con una unidad no reconocida o con una fecha futura incorrecta, NiFi puede separarlo del flujo principal y trasladarlo a una ruta de revisión.

Esta capacidad es importante porque los datos industriales rara vez llegan en condiciones perfectas. Los sistemas pueden perder comunicación, repetir valores, cambiar formatos o enviar información incompleta. El pipeline debe ser capaz de reconocer estas situaciones y evitar que los errores se propaguen hacia los dashboards.

NiFi también aporta trazabilidad. La organización puede conocer cuándo ingresó un dato, qué transformaciones recibió, qué ruta siguió y en qué momento fue almacenado. Esta visibilidad es fundamental para auditorías, análisis de incidentes y validación de resultados.

En AABO OPERATIONS, NiFi forma parte de la arquitectura que transporta la información procesada por Kappa hacia TimescaleDB. Esto permite separar la operación inmediata del almacenamiento analítico e histórico.

Kappa como componente de integración desarrollado por AABO

Dentro de los desarrollos de AABO Services, Kappa funciona como un puente entre la base operacional y el pipeline administrado por NiFi.

Kappa no debe entenderse únicamente como un mecanismo de transferencia. Su función consiste en preparar la información para que pueda recorrer la arquitectura de forma consistente. Puede identificar los registros pendientes, aplicar reglas de secuencia, normalizar estructuras y organizar los datos antes de entregarlos al flujo de integración.

Esta separación permite que NiFi se concentre en la orquestación, mientras Kappa gestiona la lógica específica del proyecto. Por ejemplo, si una base operacional cambia el nombre de una columna o incorpora una nueva variable, la adaptación puede realizarse en Kappa sin alterar innecesariamente todas las etapas del pipeline.

En AABO OPERATIONS, Kappa ha sido integrado con PostgreSQL operacional y NiFi. La información generada por la fuente simulada se registra inicialmente en la base operacional. Kappa identifica y prepara los registros. NiFi los transporta hacia TimescaleDB, donde quedan disponibles para consultas históricas, dashboards y Grafana.

Este patrón es reutilizable. En un nuevo proyecto, Kappa podría adaptarse para recibir datos desde LOWIS, un historiador industrial, un sistema de producción o cualquier base que gestione mediciones de activos.

TimescaleDB como memoria operacional

Los datos industriales tienen una característica esencial: su valor depende del tiempo. No es suficiente conocer la presión actual de un pozo. Es necesario saber cómo ha cambiado durante los últimos minutos, horas, días o meses.

TimescaleDB es una extensión de PostgreSQL especializada en series temporales. Permite almacenar grandes cantidades de registros asociados con una fecha y una hora, conservando al mismo tiempo la capacidad relacional de PostgreSQL.

Esto significa que las mediciones pueden vincularse con catálogos de campos, plataformas, pozos, bombas, sensores, variables y unidades. La base no conserva solamente números; conserva datos contextualizados.

En un sistema BES, por ejemplo, TimescaleDB puede almacenar la frecuencia del variador, la corriente de cada fase, el voltaje, la presión de entrada, la presión de descarga, la temperatura del motor, la vibración y la producción del pozo.

Posteriormente, estas variables pueden analizarse de manera conjunta. Un aumento progresivo de temperatura, acompañado por un incremento de corriente y una disminución de producción, puede representar una condición que merece atención. La detección no depende de un valor aislado, sino del comportamiento combinado durante un periodo.

TimescaleDB permite ejecutar consultas por ventanas temporales, calcular promedios, identificar máximos, generar agregaciones y comparar periodos. También facilita la aplicación de políticas de retención, especialmente importantes en soluciones demostrativas o ambientes donde el almacenamiento debe mantenerse bajo control.

En AABO OPERATIONS, TimescaleDB es la fuente histórica utilizada por los dashboards y Grafana. En BESIA, constituye una capa estratégica para conservar el comportamiento de los sistemas de bombeo electrosumergible y preparar futuros análisis predictivos.

Las APIs REST como contrato entre datos y aplicaciones

Una aplicación empresarial no debería conectarse directamente a una base de datos cada vez que necesita presentar información. Esta práctica expone credenciales, aumenta el acoplamiento y dificulta modificar la estructura interna.

Las APIs REST resuelven este problema creando una capa de servicios. La aplicación realiza una solicitud y recibe una respuesta estructurada, generalmente en formato JSON.

Una API puede responder preguntas como cuál es el estado actual de un pozo, cuáles fueron las últimas mediciones, qué alarmas están activas, cómo evolucionó una variable y cuáles son los activos con mayor criticidad.

La API también puede controlar permisos. Un operador podría acceder solamente a los pozos de su área, mientras un gerente podría consultar indicadores consolidados de varios campos.

Otro beneficio es la reutilización. Una misma API puede alimentar una aplicación web, un dashboard, un módulo de Inteligencia Artificial, una aplicación móvil o una integración con otra empresa.

En los desarrollos de AABO Services, las APIs forman parte de la estrategia para desacoplar las bases de datos de las interfaces. Esto permite que la capa visual evolucione sin comprometer el modelo interno y facilita la incorporación de nuevos consumidores.

Grafana como ventana hacia el comportamiento temporal

Grafana es una plataforma especializada en observación de datos. Puede conectarse con TimescaleDB y convertir las consultas en gráficos, indicadores, tablas y alertas.

Su principal fortaleza en Oil & Gas es la capacidad de representar series temporales. Un operador puede observar varias variables de un pozo dentro de la misma ventana y reconocer relaciones que no son evidentes al revisar valores separados.

Grafana puede mostrar cómo una modificación de frecuencia afectó la presión de entrada, la corriente del motor y la producción. También puede identificar interrupciones de comunicación, tendencias anormales y diferencias entre activos.

Sin embargo, Grafana no debe considerarse necesariamente como la aplicación corporativa completa. Su función es proporcionar profundidad operacional. La gestión de usuarios, los procesos de negocio, las fichas técnicas, los documentos y la navegación general pueden mantenerse en una aplicación propia.

En AABO OPERATIONS, Grafana consume información exclusivamente desde TimescaleDB. Esta regla arquitectónica evita que las consultas históricas afecten directamente la base operacional y conserva una separación clara entre captura y observación.

En BESIA, Grafana puede convertirse en una herramienta complementaria para los especialistas que necesiten analizar curvas detalladas, mientras el portal principal presenta una visión ejecutiva y simplificada.

Streamlit como laboratorio rápido de aplicaciones analíticas

Streamlit es un framework de Python que permite crear aplicaciones interactivas orientadas a datos. Su principal ventaja es la velocidad con la que puede transformarse un análisis o modelo en una interfaz utilizable.

Un especialista puede desarrollar un cálculo en Python, conectarlo con una base de datos y agregar controles para seleccionar un pozo, un rango de fechas o una variable. El resultado puede convertirse rápidamente en una aplicación interna.

En BESIA, Streamlit podría utilizarse para construir un laboratorio de diagnóstico. El usuario seleccionaría un sistema BES y observaría el comportamiento conjunto de presión, temperatura, frecuencia, corriente, vibración y producción.

También podría ajustar parámetros, probar escenarios y comparar el comportamiento real con una línea base. Este laboratorio sería útil para validar indicadores antes de incorporarlos al portal productivo.

Streamlit no sustituye necesariamente una interfaz desarrollada con HTML, CSS y JavaScript. Su función dentro de AABO Services sería acelerar la experimentación, construir demostraciones y validar ideas con clientes y especialistas.

Una vez aprobado un modelo, la lógica podría trasladarse a una API y la visualización definitiva integrarse en la aplicación corporativa.

KNIME como plataforma de procesamiento analítico

KNIME permite construir flujos de análisis mediante componentes visuales conectados. Cada nodo representa una operación, como leer una base de datos, filtrar registros, combinar tablas, calcular campos, entrenar un modelo o generar una salida.

Esta forma de trabajo puede ser útil en proyectos donde se necesita demostrar claramente cómo se transforma la información.

En Oil & Gas, KNIME podría recibir datos históricos de producción, combinarlos con información de completación, variables eléctricas y características del pozo. Posteriormente podría limpiar valores, calcular indicadores y preparar un conjunto de datos para análisis predictivo.

También puede utilizarse para automatizar procesos periódicos. Un flujo podría ejecutarse diariamente, analizar el comportamiento de los pozos y generar una tabla con los activos que requieren revisión.

La diferencia frente a NiFi es importante. NiFi está especialmente orientado al movimiento continuo, la integración y la trazabilidad de los datos. KNIME se concentra en la preparación analítica, el modelamiento y la construcción de procesos de análisis.

Dentro de AABO Services, KNIME sería una herramienta complementaria. No reemplazaría la arquitectura actual, sino que podría incorporarse en proyectos que requieran procesamiento estadístico, segmentación, clasificación o generación de modelos reproducibles.

Orange como espacio de experimentación con Machine Learning

Orange es una herramienta visual para análisis de datos y machine learning. Permite probar algoritmos sin escribir grandes cantidades de código y facilita la comparación de diferentes modelos.

Su utilidad se encuentra principalmente en las etapas iniciales de investigación. Un equipo podría cargar un conjunto de datos, seleccionar variables, probar algoritmos y observar si existe capacidad para clasificar o predecir determinados comportamientos.

En BESIA, Orange podría utilizarse para explorar si las variables eléctricas, térmicas y productivas permiten anticipar una condición anormal.

En AABO OPERATIONS podría ayudar a identificar patrones de producción, pérdida de comunicación o desviaciones entre pozos.

No obstante, Orange no debería convertirse en el núcleo de una solución productiva. Una vez validado un modelo, la lógica debería implementarse en un entorno controlado, normalmente mediante Python, APIs y procesos versionados.

Su papel sería similar al de un laboratorio. Permite aprender rápidamente qué modelos tienen potencial antes de invertir tiempo en una implementación industrial.

Cómo se relacionan todas las herramientas

El valor de estas tecnologías aparece cuando se conectan correctamente.

Las fuentes industriales producen datos. PostgreSQL operacional recibe las lecturas recientes. Kappa identifica, normaliza y prepara la información. NiFi administra el flujo y registra la trazabilidad. TimescaleDB conserva el histórico. Las APIs REST exponen los datos de forma segura. Grafana permite observar tendencias. Streamlit facilita los laboratorios. KNIME automatiza los análisis y Orange ayuda a experimentar con modelos.

Ninguna herramienta realiza todo el proceso por sí sola. La arquitectura funciona porque cada componente tiene límites claros.

Esto también mejora la escalabilidad. Si el volumen de datos aumenta, se puede optimizar la capa temporal. Si se incorpora una nueva fuente, se adapta el pipeline. Si se desarrolla una aplicación móvil, puede consumir las mismas APIs. Si aparece un nuevo modelo predictivo, puede integrarse sin modificar la captura de datos.

AABO OPERATIONS como caso de integración

AABO OPERATIONS constituye una muestra funcional de esta arquitectura.

El proyecto utiliza una fuente SCADA simulada que genera lecturas operacionales. Estas mediciones ingresan a PostgreSQL operacional, donde quedan disponibles para los procesos que requieren información reciente.

Desde esta base se alimentan los componentes PAI y Kappa. Kappa prepara la información para el flujo NiFi. NiFi transporta los datos hacia TimescaleDB. Los dashboards y Grafana consultan el repositorio histórico.

Esta separación permite que el sistema operacional continúe recibiendo información mientras los usuarios realizan consultas históricas sobre otra capa.

También facilita sustituir la fuente simulada por una fuente real. Mientras se mantenga el contrato de datos, el resto de la plataforma puede continuar operando.

BESIA como aplicación para bombeo electrosumergible

BESIA traslada este enfoque al monitoreo de bombas electrosumergibles.

La plataforma incorpora un catálogo de campos, plataformas, pozos y sistemas BES. Su simulador genera variables relacionadas con fondo, superficie, producción, electricidad, alarmas y comunicaciones.

Entre los datos considerados se encuentran la presión de entrada, presión de descarga, temperatura de motor, temperatura de intake, corriente por fase, voltaje, potencia, frecuencia, vibración, producción de petróleo, agua y gas.

LOWIS_SIM representa una fuente operacional simulada. El objetivo es que la plataforma pueda evolucionar hacia una conexión real con LOWIS u otros sistemas industriales.

BESIA ya aplica un modelo encapsulado con base operacional, simulación, publicación web y almacenamiento histórico. Su evolución incluye la integración de pipelines, APIs, TimescaleDB y herramientas analíticas.

Streamlit podría incorporarse para laboratorios. KNIME podría utilizarse en procesos de análisis. Orange podría emplearse para evaluar modelos exploratorios. Grafana podría proporcionar análisis temporal avanzado.

De la visualización descriptiva a la inteligencia operacional

La primera etapa de una solución suele ser descriptiva. El sistema muestra qué está ocurriendo.

La segunda etapa es diagnóstica. La plataforma ayuda a entender por qué ocurrió una desviación.

La tercera etapa es predictiva. Los modelos estiman qué podría suceder si la condición continúa.

La cuarta etapa es prescriptiva. La solución recomienda acciones, como revisar un activo, ajustar una frecuencia o priorizar una intervención.

Las herramientas descritas permiten construir esta evolución de forma progresiva. No es necesario comenzar inmediatamente con Inteligencia Artificial. Primero debe garantizarse que los datos sean confiables, trazables y comparables.

Una predicción basada en información incorrecta solamente automatiza el error. Por esta razón, AABO Services prioriza primero la arquitectura de datos, la normalización y la trazabilidad.

Conclusión

La transformación de los datos Oil & Gas en decisiones no depende de adquirir una plataforma aislada. Requiere diseñar una arquitectura donde cada componente cumpla una función específica.

Kappa prepara la información operacional. NiFi controla su recorrido. TimescaleDB conserva la historia. Las APIs REST habilitan el acceso. Grafana permite observar el comportamiento. Streamlit acelera los laboratorios. KNIME estructura los procesos analíticos y Orange facilita la experimentación con machine learning.

AABO Services ha venido aplicando este enfoque en proyectos como AABO OPERATIONS y BESIA, demostrando que es posible comenzar con fuentes simuladas, validar la arquitectura y evolucionar hacia conexiones industriales reales sin perder trazabilidad ni control.

Las organizaciones que necesiten integrar información de pozos, producción, sistemas SCADA, LOWIS, bombas electrosumergibles o activos industriales pueden contactar a AABO Services para realizar un análisis de su situación actual.

AABO Services puede diseñar una arquitectura adaptada al negocio, identificar las fuentes disponibles, definir los indicadores prioritarios y construir una hoja de ruta desde la integración inicial hasta la analítica avanzada y la Inteligencia Artificial.