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) y un watchdog de salud de componentes continuo 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
• Vigilar de forma continua la salud y el estado de conexión de los componentes, y generar eventos de parque por averías, conflictos de medición y problemas de conexión
• 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 base de datos propia: ningún estado de análisis sobrevive a los reinicios; los datos no entregados se almacenan en búfer en el disco local hasta que puedan enviarse
• 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 veinte 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 diecisiete familias de dispositivos: contadores Janitza, Huawei SmartLogger, controladores Phoenix Contact, inversores Fronius, data loggers Solar-Log, SMA Sunny Central, SMA Power Manager, logger Sungrow, Zebotec, Becker PV-Control (Prometheus), almacenamiento de baterías FREQCON, Wattkraft Parkcontrol, convertidores de baterías NR Electric, baterías de contenedor Linyang/Xieneng relés de protección SEG HighPROTEC, baterías INTILION scalecube y el controlador de alarma WAGO PFC200. Varias de ellas — por ejemplo Janitza, Fronius y Wattkraft — no necesitan ninguna credencial; SMA Power Manager y el logger Sungrow se incorporan con credenciales del dispositivo e informan además automáticamente de su propio inventario de dispositivos (lista de componentes, números de serie, firmware) en lugar de pedirlo por escrito. El controlador de alarma WAGO es la única excepción a la vía rápida: nada en el cable indica qué programa ejecuta una WAGO, así que nunca se detecta automáticamente — se añade con Añadir logger, eligiendo a mano el adaptador y su perfil de integrador.
• 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 y Bluelog se incorporan 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 451 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 no mantiene ninguna base de datos propia y no conserva estado de análisis entre reinicios:

• 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
• Las mediciones y los reportes de estado que no pueden entregarse — por ejemplo, durante un corte de internet — se almacenan en búfer en el disco local y se entregan automáticamente en cuanto vuelve la conectividad, de modo que no se pierde nada (la resiliencia de «Retención local / Reanudación automática» descrita en la Visión general del Mirox-Agent)

El único estado persistente es el búfer local de entrega de los datos aún no transmitidos, más lo que reside 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
• Vigila en directo la salud y el estado de conexión de los componentes, abriendo y cerrando eventos de parque
• 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 de forma continua la potencia esperada de cada planta y compara la producción real con ella en forma de performance ratio (PR), una medida normalizada de lo bien que la planta convierte la luz solar disponible en electricidad. En lugar de confiar en una única entrada, se monitorizan en paralelo varias fuentes de irradiancia independientes, y cada fuente obtiene su propia serie de PR — de modo que un sensor in situ con deriva nunca pueda distorsionar silenciosamente tu línea base:

• Piranómetro in situ — los sensores de irradiancia propios de la planta, disponibles casi en tiempo real
• Satélite — irradiancia derivada de satélite para la ubicación exacta del emplazamiento
• Modelo meteorológico — irradiancia modelada a partir de datos meteorológicos

Conversión al plano de los módulos (POA). Todas las fuentes se convierten a irradiancia en el plano del array (POA) — la irradiancia que realmente incide sobre los módulos — utilizando la jerarquía de componentes de la planta (el árbol del parque): cada string lleva su propia orientación, un grado de azimut y una inclinación, ya sea configurados por el operador o detectados por el motor de análisis. La irradiancia horizontal se descompone en sus partes directa y difusa y se transpone a cada plano de módulos distinto con física de posición solar estándar del sector, de modo que los campos de módulos orientados en direcciones diferentes obtienen cada uno su propia expectativa correcta. Las expectativas de los strings se suman en curvas de caja de conexiones y de inversor y se limitan a la potencia nominal AC de cada inversor.

Filtrado de anomalías. Antes de que un instante pueda contar para el PR fiable («limpio»), una batería de filtros enmascara todas las situaciones en las que un ratio bajo no significaría un fallo:

Un PR por fuente. El performance ratio se calcula entonces por separado para cada fuente de irradiancia — publicado tanto en bruto (todos los valores calculables) como en limpio (solo los valores filtrados y fiables) — a nivel de parque y por componente (inversor, caja de conexiones, string). La media móvil del PR limpio además autocalibra el modelo de potencia esperada: la expectativa se adapta automáticamente a la eficiencia real de cada planta, y esta misma expectativa es la que el watchdog de salud de componentes contrasta con la producción en directo.

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.

Watchdog de salud de componentes

Más allá de recopilar datos, el agente juzga de forma continua si cada componente productor — inversores, cajas de conexiones (GAK), strings y sensores de irradiancia — está realmente sano, y convierte sus conclusiones en eventos de parque que ves en la plataforma. Se plantean dos preguntas las veinticuatro horas del día: ¿sigue el componente conectado? y ¿está produciendo lo que debería?

Monitorización de conexiones

La conectividad se rastrea como una cadena causal estricta — enlace del parque, dispositivos de red, data loggers, componentes — y el watchdog diferencia las formas en que una conexión puede fallar, cada una con su propio evento:

Una alarma por causa raíz. Cada capa solo genera eventos mientras todas las capas por encima de ella están sanas: una caída de todo el parque genera exactamente un evento a nivel de parque y retiene silenciosamente todo lo de abajo, un switch muerto genera un evento de dispositivo, y solo cuando la ruta de red y el logger están demostrablemente bien un componente silencioso se convierte en un fallo de componente. Todas las transiciones se amortiguan frente a reinicios y cortes breves, y cada evento se cierra automáticamente con la recuperación, indicando la duración de la interrupción.

Comprobaciones de potencia y producción

En paralelo, el watchdog compara la potencia medida de cada componente con el modelo de potencia esperada en ventanas de evaluación cortas. Un cero o un déficit solo cuenta como evidencia cuando una verificación de entorno demuestra que las condiciones justifican que haya producción — irradiancia sostenida suficiente, sin nieve, escarcha ni niebla, sin curtailment activamente vinculante y con una ruta de red sana — de modo que una mañana oscura de invierno nunca pueda alertar a nadie.

Antes de que se abra una alarma, el hallazgo se contrasta con testigos independientes: los hijos del componente un nivel más abajo en la jerarquía, su propio contador de energía acumulada y una auditoría nocturna de energía entre padre e hijos. El resultado decide qué tipo de evento recibes:

• Avería de producción — el componente ha dejado realmente de producir en condiciones en las que debería producir
• Conflicto de medición — el componente sí está produciendo, pero su propia lectura es errónea (un fallo de datos que investigar, nunca contabilizado como producción perdida)
• Sin comunicación — el componente ha dejado de reportar por completo; la producción es desconocida y deliberadamente no se contabiliza como pérdida
• Producción reducida — el componente está produciendo, pero muy por debajo de su expectativa modelada (evaluado tanto en directo como en una auditoría nocturna del día completo)

Los strings y los sensores de irradiancia reciben investigaciones por etapas en lugar de veredictos instantáneos: un string silencioso abre primero una investigación de prioridad baja y solo se confirma como avería o defecto con pruebas de rigor físico — por ejemplo, salida cero bajo un cielo cubierto mientras sus hermanos producen —, mientras que los ceros recurrentes que siguen la trayectoria del sol se reconocen y se registran como sombreado, no como un defecto. Un sensor cuyo canal de irradiancia se apaga mientras sus otros canales siguen vivos se reporta como suciedad (limpia la cúpula) en lugar de como un defecto de hardware.

Constantes vitales de los inversores

Las comprobaciones anteriores preguntan si un inversor sigue produciendo. Un segundo conjunto de comprobaciones pregunta si un inversor que produce se dirige en silencio hacia un defecto — leyendo las señales que el agente ya recoge de cada inversor pero que nunca había utilizado para juzgarlo: temperatura, resistencia de aislamiento, corrientes y tensiones por fase y el lado DC (tensión y potencia).

Una vía de mantenimiento propia. Estos hallazgos nunca llegan como una avería: el inversor está produciendo y todavía no se pierde nada. Se abren como tareas de mantenimiento, deliberadamente separadas de los eventos de avería anteriores — los informes rutinarios de salud de un inversor que produce nunca pueden cerrar un hallazgo de mantenimiento, y un hallazgo de mantenimiento abierto nunca puede bloquear una alarma de avería real. Tampoco mueven jamás una cifra de producción: un inversor con un hallazgo de mantenimiento sigue contando como productivo allí donde la plataforma cuenta componentes productivos, porque lo está.

Cada hallazgo es un evento propio. Ya no existe una entrada genérica de «Mantenimiento requerido del inversor»: cada hallazgo se comunica con su propio nombre descriptivo (Temperatura elevada, Aislamiento debilitado, Desequilibrio de fases, Eficiencia decreciente), y cada inversor lleva como máximo un evento abierto por hallazgo. Por eso varios hallazgos pueden convivir en la misma unidad, cada uno con su propio razonamiento, su propio historial y su propia recuperación, en lugar de fundirse en una única entrada que solo dice «aquí hay algo que atender».

La vigilancia se ve; el veredicto espera. Una sospecha nueva ya no desaparece en la contabilidad interna del agente. En cuanto una comprobación tiene motivos para fijarse, abre un evento de observación de prioridad baja — «Observación: temperatura elevada», «Observación: desequilibrio de fases», y así sucesivamente, con el mismo icono que el hallazgo confirmado en un tono más claro. Así, la lista de actividad de la planta muestra exactamente qué está vigilando el sistema y desde cuándo. Lo que un evento así deliberadamente no hace es cambiar la salud de un componente: las observaciones nunca aparecen en las vistas de salud — páginas de análisis y de producción, chips de componentes, columna de componentes de las estaciones y sus recuentos — porque allí la plataforma solo emite un veredicto cuando está segura. Una observación es una pista, no un veredicto.

Una sola cadena, de la primera sospecha al hallazgo. Cuando llega la evidencia confirmatoria, la observación se cierra y en su lugar se abre el hallazgo confirmado con prioridad normal, enlazado a la observación de la que nació. Ambos se leen como un único historial — vigilado desde este día, confirmado en aquel — y el cierre de la observación no anuncia ninguna recuperación, porque nada se ha recuperado: el hallazgo simplemente ha subido de etapa. Solo a partir de la confirmación aparece en las vistas de salud. Si la corroboración nunca llega, la observación se cierra sin más cuando la condición desaparece, y nunca se afirmó nada.

Los eventos de mantenimiento nombran el componente inversor real y llevan el mismo razonamiento en lenguaje claro que cualquier otro evento, con las cifras concretas detrás — el exceso medido, la comparación con las unidades vecinas, el número de días observados. Por ahora son deliberadamente silenciosos: aparecen en la lista de eventos de la planta, pero quedan por debajo de todos los umbrales de notificación mientras las nuevas comprobaciones se calibran con datos reales de la flota. Eventos del inversor explica qué abre, confirma y cierra cada uno.

Evidencia de causa en eventos existentes

Dos de las señales recién leídas no generan eventos propios — refuerzan los que ya existen:

¿Lado AC o lado DC? Cuando el watchdog abre una avería de producción de un inversor, lee además la tensión DC exactamente en aquellas ventanas diurnas en las que la unidad no entregó nada. Un bus DC apagado significa que la causa está en el lado DC (strings, aparamenta DC); uno con tensión significa que el generador está intacto y el fallo está en la propia unidad o en su lado AC. El veredicto — lado AC, lado DC o indeterminado — pasa al razonamiento del evento de avería y decide qué intervención de servicio merece la pena siquiera. El testigo depende del fabricante: algunos equipos — Huawei entre ellos — nunca reportan un bus apagado, así que allí solo puede exonerar al lado DC, nunca acusarlo.

Una reducción por el lado de la red no es un defecto. Cuando un inversor mantiene su tensión AC en 1,10 veces su tensión nominal o por encima durante una ventana de bajo rendimiento, está limitando su salida a propósito, siguiendo la regla volt-watt del código de red — obedece a la red, no falla. Esas ventanas se mantienen neutras en lugar de contarse como déficit, de modo que una conexión de red rígida nunca puede acumularse hasta convertirse en un defecto falso.

¿Con qué rapidez se detectan los eventos?

Estos detectores no vigilan de forma continua. Se ejecutan una vez por noche — más una vez poco después de arrancar el agente — y reconstruyen su evidencia a partir del histórico almacenado en cada pasada. Por eso, una condición que lleva semanas presente se encuentra en la primera evaluación una vez que su comprobación está armada, y no semanas después. Lo que lleva tiempo es la evidencia en sí: cada comprobación exige un histórico mínimo y una racha de persistencia antes de decir nada. La primera columna de abajo indica el punto en que se abre la observación — prioridad baja, visible en la lista de actividad de la planta, deliberadamente ausente de las vistas de salud. La segunda indica qué hace falta para que esa observación sea sustituida por el hallazgo oficial, que es lo único que esas vistas muestran.

Por tanto, una planta recién incorporada ve sus primeras observaciones de temperatura al cabo de unas tres semanas y sus primeras observaciones de eficiencia al cabo de unos dos meses, mientras que el testigo DC y la exoneración de red funcionan desde el primer día.

Merece la pena conocer dos límites:

• Un grupo de comparación necesita al menos seis inversores comparables. Todas estas reglas son relativas a las unidades vecinas — cada equipo se juzga frente a sus hermanos, nunca frente a un umbral absoluto, porque los límites absolutos escalan con el tamaño del generador y con el fabricante. La consecuencia es deliberada: si todo un grupo de comparación se degrada del mismo modo al mismo tiempo, esa deriva común no es detectable con este método.
• La cobertura es por inversor y viene dada por los datos. Una comprobación solo se arma allí donde el logger del fabricante entrega realmente la métrica — ningún interruptor de configuración la activa. Por eso la cobertura difiere de planta a planta y de fabricante a fabricante.

Eventos que se explican por sí mismos

Cada evento lleva un razonamiento en lenguaje claro: qué se midió, en qué condiciones, qué evidencia independiente lo corroboró o lo contradijo, y qué lo resolvería. Los eventos se cierran automáticamente cuando la recuperación queda demostrada, se reclasifican en el propio evento cuando la evidencia cambia de opinión (nunca un vaivén de cerrar y reabrir) y respetan tus decisiones — un evento que cierras permanece cerrado hasta que el fallo se gana plenamente uno nuevo. Un único evento resumen «componentes caídos» a nivel de parque lleva la alarma real para el operador: se abre cuando al menos un inversor o una caja de conexiones lleva caído un periodo sostenido, enumera los componentes afectados y notifica solo en la primera apertura y en la recuperación final.

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
• Eventos — cómo te llegan los eventos de parque del watchdog