Data Scraper

El Data Scraper es el motor central de recopilación de datos dentro del Mirox-Agent, que recupera de forma activa información en tiempo real de todos los equipos monitorizados de tu planta. Se conecta a tus loggers, inversores, contadores y sistemas de baterías a través de una biblioteca de adaptadores específicos de cada fabricante, normaliza todo en un vocabulario de métricas único y coherente, y reenvía el resultado al resto de la plataforma, mientras ejecuta un conjunto creciente de analíticas en el edge (performance ratio, seguimiento de curtailment, líneas base de cielo despejado, previsión y monitorización de red) directamente en la planta.

Propósito y rol

El Data Scraper tiene un único propósito bien definido: recopilar de forma activa mediciones en bruto de los equipos y reenviarlas para su procesamiento. Actúa como puente entre los diversos equipos de los fabricantes y la plataforma unificada de Mirox, traduciendo formatos de datos propietarios a métricas estandarizadas.

Responsabilidades principales:

• Conectarse a data loggers y dispositivos de monitorización mediante adaptadores específicos de cada fabricante
• Recuperar mediciones en bruto según programaciones configurables
• Transformar los datos específicos del fabricante a un formato de métricas estandarizado
• Descubrir y rastrear automáticamente los componentes de la instalación
• Monitorizar la actividad y el estado operativo de los componentes
• Ejecutar analíticas en el edge (potencia esperada, performance ratio, curtailment, cielo despejado y previsiones)
• Inspeccionar la red local de la planta y auditar el acceso a los dispositivos
• Reenviar métricas a la base de datos de series temporales y al servicio Digital Twin
• Reportar la salud y el estado operativo de los componentes a la IoT Cloud

Esta separación de responsabilidades mantiene al Data Scraper ligero, enfocado y desplegable de forma independiente.

Visión general de la arquitectura

El Data Scraper opera como un servicio asíncrono y orientado a eventos en el que se ejecutan simultáneamente múltiples tareas de recopilación de datos:

Principios arquitectónicos clave:

• Sin estado: sin estado persistente entre reinicios
• Basado en adaptadores: un adaptador dedicado y específico del fabricante habla el protocolo de cada dispositivo
• Autorreparación: recuperación automática de errores con retroceso exponencial
• Concurrente: cada fuente de datos se recopila de forma independiente
• Desplegado en el edge: se ejecuta en la planta o cerca de ella, próximo a los equipos que lee

El sistema de adaptadores

Concepto

Un adaptador es un módulo conector específico del fabricante que sabe cómo comunicarse con una familia concreta de dispositivos. Cada adaptador se construye a mano y mediante ingeniería inversa contra la propia interfaz web, API o base de datos de ese dispositivo: no existe un único motor que «hable cualquier protocolo». El sistema de adaptadores es el mecanismo central de extensibilidad: dar soporte a un nuevo dispositivo significa añadir un nuevo adaptador, algo que hacemos bajo demanda (véase más abajo).

Cada adaptador es un módulo autónomo responsable de:

1. Gestión de la conexión: establecer y mantener la comunicación
2. Recuperación de datos: obtener mediciones usando el protocolo adecuado
3. Transformación de datos: convertir a un formato de métricas estandarizado

Todos los adaptadores heredan de una clase base que proporciona monitorización de salud, lógica de reintentos automáticos, retroceso exponencial ante fallos, validación de métricas y reporte de estado a la plataforma IoT.

Gestión de la salud

Cada adaptador implementa una máquina de estados automática:

• INITIALIZING: arrancando y estableciendo las conexiones iniciales
• HEALTHY: funcionando con normalidad y con recopilaciones de datos exitosas
• UNHEALTHY: experimentando errores pero intentando continuar
• RECONNECTING: ejecutando acciones de recuperación tras fallos repetidos
• FROZEN: el dispositivo devuelve datos obsoletos; los mismos valores se repiten, o no ha llegado ninguna lectura nueva dentro de la ventana esperada
• PAUSED: pausado temporalmente por orden del usuario; se reanuda automáticamente cuando expira la pausa

El sistema transiciona automáticamente entre estados, reporta el estado a la plataforma e intenta la recuperación sin intervención manual. El estado FROZEN es lo que permite a la plataforma distinguir un logger genuinamente caído de uno que simplemente repite un valor atascado.

Dispositivos compatibles

El Data Scraper incluye alrededor de quince adaptadores específicos de fabricante, cada uno construido para una familia concreta de dispositivos. La lista siguiente refleja lo que se admite hoy y crece cada vez que se integra un nuevo dispositivo.

Creación de nuevos adaptadores

Se pueden desarrollar nuevos adaptadores para dar soporte a dispositivos o protocolos adicionales. El diseño modular y la funcionalidad de la clase base reducen significativamente el tiempo de desarrollo.

Compatibilidad con equipos heredados: podemos crear adaptadores para dispositivos antiguos que nunca se diseñaron específicamente para la exportación de datos. Mientras el dispositivo proporcione sus datos de alguna forma accesible —ya sea mediante una API REST, una interfaz web, una base de datos, un sistema de archivos o cualquier otro mecanismo— podemos extraer e integrar esos datos en la plataforma.

Recopilación de datos sin restricciones: nuestros adaptadores no se limitan a los formatos predefinidos de exportación de datos que los data loggers suelen ofrecer. Podemos recopilar cualquier dato que el dispositivo ponga a disposición, yendo más allá del conjunto estándar de métricas que el logger de un fabricante podría exponer. Si un dispositivo tiene información de diagnóstico adicional, parámetros avanzados o puntos de datos ocultos accesibles a través de su interfaz, podemos recuperarlos y estandarizarlos.

Onboarding a través de la plataforma

Para un subconjunto de dispositivos, puedes poner un logger en línea desde la plataforma sin escribir a mano ninguna configuración. Un asistente de onboarding pide al agente que realice una conexión de prueba (dry-run) al dispositivo y te transmite en directo los resultados del sondeo, de modo que veas de inmediato si la conexión funciona antes de confirmarla. Hay dos variantes:

• Onboarding sin configuración — el adaptador ya posee el conjunto completo de lecturas del dispositivo, así que el asistente solo muestra una vista previa en vivo de solo lectura y guardas. Disponible hoy para contadores Janitza, Huawei SmartLogger y controladores Phoenix Contact. Janitza no necesita ninguna credencial.
• Asignación interactiva para loggers genéricos — algunos loggers exponen valores en bruto arbitrarios que la plataforma no puede interpretar por sí sola. Para estos, el asistente pide al agente que enumere cada valor en bruto que expone el dispositivo (grupo, nombre, unidad, muestra en vivo), el operador asigna cada uno a una métrica conocida y una prueba en seco (dry run) basada en la asignación previsualiza las métricas exactas que se producirían antes de guardar. QReader es el primer logger genérico soportado de esta forma.

Estandarización de métricas

Todos los datos recopilados se transforman a un formato de métricas estandarizado definido por la taxonomía de métricas de la plataforma. Esto garantiza la coherencia entre todas las fuentes de datos y permite un procesamiento unificado aguas abajo.

Estructura de las métricas

Cada métrica sigue una estructura estandarizada compatible con las bases de datos de series temporales modernas:

Componentes:

• Nombre: identificador de métrica estandarizado de una taxonomía predefinida
• Valor: medición numérica en unidades base del SI
• Etiquetas: pares clave-valor para la identificación y agrupación de componentes
• Marca de tiempo: conservación opcional de la marca de tiempo original del dispositivo

Etiquetas estándar:

• Tipo de adaptador de origen y número de instancia
• Nombres legibles por humanos
• Identificadores de componente (ID de inversor, número de string, etc.)
• Ubicación física o información de agrupación

Convenciones de unidades

Todas las métricas usan unidades base del SI, independientemente de lo que reporte el dispositivo del fabricante:

• Potencia: vatios (W)
• Energía: vatios-hora (Wh)
• Tensión: voltios (V)
• Corriente: amperios (A)
• Temperatura: Celsius (°C)
• Irradiancia: vatios por metro cuadrado (W/m²)

Los adaptadores convierten automáticamente desde las unidades específicas del fabricante (kW, MWh, etc.) a estos estándares durante la fase de transformación.

Categorías de métricas

La plataforma define 376 tipos de métricas estandarizadas organizadas en 11 familias:

Las expansiones de etiquetas (por string, por fase, por inversor, etc.) las multiplican en muchas más series temporales individuales en una planta real. Para la taxonomía y las definiciones completas de las métricas, consulta Recopilación de métricas.

Flujo de recopilación de datos

Estrategias de sondeo

Los adaptadores admiten dos modos de sondeo:

Basado en intervalos (predeterminado): se ejecuta cada N segundos después de que finalice la recopilación anterior. Sencillo y adaptable a duraciones de recopilación variables.

Basado en tiempos fijos: se ejecuta en intervalos fijos desde medianoche con un desfase opcional (p. ej., a las 00:01, 05:01, 10:01 para intervalos de 5 minutos con un desfase de 1 minuto). Útil para alinearse con sistemas externos.

Pipeline de procesamiento

Tras la recopilación, las métricas pasan por varias etapas de procesamiento:

Preparación de métricas: se añaden las etiquetas de origen, se aplican las marcas de tiempo y se valida la estructura.

Filtrado: los filtros configurados pueden modificar valores, validar rangos u omitir métricas según reglas.

Cálculos: los calculadores automáticos derivan métricas adicionales:

• La potencia de radiación solar se integra en energía de irradiación
• La tensión × corriente de string se calcula como potencia
• Los valores de potencia se integran en energía a lo largo del tiempo

Descubrimiento de componentes: a medida que fluyen las métricas, el Data Scraper descubre e identifica automáticamente los componentes de la instalación. Esta es una función crucial: dado que el Data Scraper es la capa que recopila activamente los datos, sabe de forma inherente qué componentes existen y están proporcionando datos. El sistema descubre automáticamente:

• Inversores (a partir de las métricas de potencia de inversor)
• Cajas de conexiones de strings / GAK (a partir de las métricas de GAK)
• Strings individuales (a partir de las métricas de tensión/corriente de string)
• Sensores de irradiación (a partir de las métricas de radiación)
• Puntos de conexión a la red (a partir de las métricas de energía de red)

Los componentes descubiertos se sincronizan con la plataforma IoT para la gestión del inventario, creando un registro de equipos en tiempo real y autogestionado sin configuración manual.

Detección de producción: el sistema monitoriza el estado operativo de la planta:

• Detecta cuándo comienza la producción según la irradiancia y la potencia
• Identifica apagados inesperados durante las horas de producción
• Reporta las transiciones de estado para las alertas

Agrupación de métricas: las métricas se agrupan por serie temporal para optimizar el rendimiento de la inserción en la base de datos.

Exportación de datos

Las métricas procesadas se reenvían a dos destinos:

Base de datos de series temporales: las métricas se envían en lotes con limitación de tasa y lógica de reintentos para el almacenamiento a largo plazo y la consulta histórica.

Webhook de Digital Twin: una tarea de fondo independiente reenvía continuamente los valores de métricas más recientes al servicio Digital Twin (un microservicio completamente separado) para su análisis en tiempo real. El Data Scraper no tiene conocimiento de lo que el Digital Twin hace con los datos: simplemente proporciona las métricas. Para información sobre el procesamiento del Digital Twin, consulta Digital Twin.

Operación sin estado

El Data Scraper está diseñado para ser completamente sin estado:

• Sin almacenamiento persistente: todo el estado existe únicamente en memoria
• Se puede detener y reiniciar sin pérdida de datos
• Pueden ejecutarse múltiples instancias de forma independiente para distintos parques
• Cada ciclo de sondeo es independiente de los ciclos anteriores
• Resistente a fallos, sin riesgo de corromper un estado persistente

El único estado persistente existe externamente:

• Archivos de configuración (con control de versiones)
• Base de datos de series temporales (sistema externo)
• Registro de componentes de la IoT Cloud (sistema externo)

Este diseño garantiza simplicidad operativa, fiabilidad y un escalado horizontal sencillo.

Separación de responsabilidades

El Data Scraper tiene una responsabilidad estrecha y bien definida que permite una separación clara respecto a otros componentes de la plataforma:

Data Scraper:

• Recopila mediciones en bruto de los equipos
• Transforma los datos a un formato estándar
• Descubre y rastrea componentes
• Monitoriza el estado de actividad de los componentes
• Reenvía métricas a otros servicios

Digital Twin: valida contra modelos físicos y detecta anomalías y pérdidas

Base de datos de series temporales: almacena datos históricos, proporciona una interfaz de consulta

IoT Cloud: mantiene el registro de componentes, rastrea el estado de los dispositivos, gestiona el inventario de equipos

Esta separación permite el desarrollo, las pruebas, el despliegue y el escalado independientes de cada componente, garantizando a la vez que cada servicio se centre en su competencia principal.

Funciones avanzadas

Monitorización automática de la salud

Cada adaptador implementa una máquina de estados que rastrea la salud operativa con reporte automático a la plataforma y exposición a través de la API de métricas para la monitorización operativa.

Descubrimiento automático de componentes

La posición del Data Scraper como capa de recopilación de datos le da una ventaja única: sabe de forma inherente qué componentes existen en una instalación porque interactúa directamente con las métricas que producen. A medida que las métricas fluyen por el sistema, los componentes se descubren automáticamente a partir de las etiquetas de las métricas y se registran en la plataforma IoT.

Proceso de descubrimiento:

1. Las métricas llegan con etiquetas identificativas (ID de inversor, número de string, ubicación del sensor, etc.)
2. El Data Scraper extrae la información del componente de estas etiquetas
3. Los nuevos componentes se registran automáticamente en la IoT Cloud
4. Se sincronizan los metadatos del componente (tipo, identificador, ubicación)
5. La plataforma mantiene un inventario de equipos actualizado sin entrada manual

Este mecanismo de autodescubrimiento garantiza que la plataforma siempre sepa qué equipos existen en la instalación, eliminando la necesidad de configuración manual y reduciendo el tiempo de despliegue.

Detección del estado de producción

El servicio monitoriza el estado operativo de la planta y detecta inicios de producción, apagados inesperados durante las horas de producción y transiciones de estado para alertas y análisis, reportando solo cuando el estado cambia realmente. También vigila la sobreproducción —salida por encima del modelo de cielo despejado durante un periodo sostenido— que puede señalar un logger que devuelve valores congelados y, en ese caso, recurre al modelo de cielo despejado para que el flujo de datos siga siendo sensato. Esto proporciona conciencia operativa en tiempo real más allá de las simples mediciones en bruto.

Métricas calculadas

Varios calculadores derivan automáticamente métricas a partir de las mediciones en bruto: la radiación solar integrada en energía de irradiación, la potencia de string calculada a partir de la tensión y la corriente, y los valores de potencia integrados en energía a lo largo del tiempo. Estos cálculos se realizan de forma transparente, enriqueciendo el flujo de datos sin requerir configuración explícita.

Analítica en el edge

Más allá de la recopilación en bruto, el Data Scraper ejecuta un conjunto de analíticas directamente en la planta, calculadas a partir del feed de métricas en directo y exportadas como series temporales graficables junto con los datos en bruto.

Potencia esperada y performance ratio

El agente calcula la potencia esperada de cada planta a partir de sus fuentes de irradiancia (piranómetro in situ, radiación por satélite o modelo meteorológico) y la compara con la salida real para derivar el performance ratio (PR), una medida normalizada de lo bien que la planta convierte la luz solar disponible en electricidad. El PR se calcula por día y tiene en cuenta el clipping, la escarcha y los filtros de calidad de datos, de modo que los días anómalos no distorsionen el resultado.

Seguimiento de curtailment en directo

Cuando una planta produce menos de lo que podría, el agente atribuye la producción perdida a su causa: curtailment por parte del comercializador (un límite deliberado impulsado por el mercado) frente a curtailment por parte del operador de red. Esta distinción es importante para la contabilidad de pérdidas y la elaboración de informes contractuales. El curtailment se rastrea por minuto y se emite tanto como potencia instantánea como energía acumulada. Consulta Detección de pérdidas para ver cómo encaja el curtailment en la atribución global de pérdidas.

Línea base de cielo despejado y previsión

• Línea base de cielo despejado: una curva PV teórica de condiciones ideales mantenida como registro a largo plazo, que te da una referencia estable con la que comparar la salida real.
• Previsión a un día (day-ahead): una previsión de producción PV a corto plazo derivada de los datos meteorológicos, para que puedas anticipar la producción del día siguiente. Se basan en la física meteorológica, no en conjeturas estadísticas.

Relleno histórico (backfill)

Cuando una planta se conecta por primera vez o tras un hueco, el agente puede rellenar (backfill) datos históricos, reproduciendo las lecturas en bruto y volviendo a derivar las analíticas anteriores para una ventana solicitada, y luego entregando el resultado a los pipelines en directo para que los gráficos estén completos desde el primer día en lugar de empezar vacíos.

Monitorización de red

El Data Scraper incluye un inspector de red local integrado que se ejecuta junto a la recopilación de datos y mapea la red in situ de la planta. Descubre dispositivos en los rangos de red configurados barriendo en busca de hosts alcanzables, leyendo la tabla de direcciones, identificando fabricantes a partir de las direcciones de hardware y sondeando los dispositivos para conocer su identidad. Los dispositivos descubiertos se clasifican contra una amplia biblioteca de perfiles de equipos de red conocidos, y un paso de identificación de dispositivos por IA ayuda a reconocer familias de dispositivos que las reglas simples pasan por alto.

Una vez conocidos los dispositivos, el inspector los sondea para comprobar su alcanzabilidad y salud (tiempo de respuesta, estado de interfaces y recursos) y reporta los resultados a la plataforma. Puedes activar o detener un escaneo de descubrimiento, volver a comprobar un dispositivo individual y revisar la red descubierta; consulta Inspector de red local.

Auditoría del proxy

Para las plantas accesibles a través del Mirox Browser Proxy, el agente audita el acceso humano a las interfaces de los dispositivos locales. Agrupa la actividad de cada persona en sesiones, redacta los datos de consulta sensibles antes de almacenar nada y puede producir un resumen generado por IA de lo que hizo una sesión. Esto alimenta el registro de auditoría de acceso de la plataforma; consulta Registro de auditoría de acceso.

Características de rendimiento

Rendimiento típico:

• Frecuencias de sondeo: 1-300 segundos por adaptador (configurable)
• Adaptadores concurrentes: más de 20 ejecutándose simultáneamente
• Caudal: más de 10.000 métricas por minuto de forma sostenida
• Latencia: menos de 100 ms desde la recopilación hasta la inserción en la base de datos
• Uso de recursos: 5-15 % de CPU, 100-500 MB de memoria en hardware de edge

La arquitectura asíncrona garantiza una alta concurrencia sin bloqueos, lo que permite una recopilación eficiente desde muchas fuentes simultáneamente.

Funciones relacionadas

• Digital Twin — el motor de análisis basado en física que consume las métricas que recopila el Data Scraper
• Visión general del Mirox-Agent — cómo encaja el Data Scraper dentro del agente de edge más amplio
• Opciones de despliegue — los compromisos entre el despliegue en el emplazamiento y en la nube para el agente
• Recopilación de métricas — la taxonomía completa de métricas estandarizadas
• Inspector de red local — la superficie de monitorización de red in situ
• Detección de pérdidas — cómo se atribuyen el curtailment y otras pérdidas