MiroxMirox
  • Piattaforma

    • Filosofia
    • Panoramica della piattaforma
    • Risorse della piattaforma
  • Mirox-Cloud

    • Panoramica del cloud
    • Microservizi connessi
  • Mirox-Agent

    • Panoramica dell'agente
    • Opzioni di distribuzione
    • Data Scraper
    • Gemello digitale
  • Dettagli tecnici

    • Raccolta delle metriche
  • Informazioni

    • Impianti supportati
  • Tipi di impianto

    • Impianti solari
    • Parchi eolici
    • Accumulo a batteria
  • Monitoraggio e visualizzazione

    • Monitoraggio in tempo reale
    • Gemello digitale
    • Stati dei componenti
    • Rilevamento delle perdite
    • Rilevamento dell'efficienza
    • Dashboard KPI
  • Gestione dei dati

    • Eventi
    • Ticket
    • Previsioni
    • Report
  • Integrazione e condivisione

    • Cooperazioni
    • Token API
    • VPN
    • Proxy
  • IA

    • Assistente IA e wizard
    • Accesso agentico (MCP)
  • Fatturazione

    • Mercato e tariffe
    • Contabilità e fatturazione
  • Collaborazione

    • Inviti
  • Sicurezza

    • Autenticazione
    • Sistema di permessi
    • Restrizioni di cooperazione
    • Audit log degli accessi
  • Nodi

    • mrxnode
  • Applicazione

    • Controllo della porta
    • Relè generico
  • Cluster edge

    • Orchestrazione
  • Per iniziare

    • Per iniziare
  • Personale

    • Usare la VPN
    • Usare il proxy
    • Autenticazione a due fattori
    • Sessioni
    • Token API
  • Per impianto

    • Contatti
    • Dispositivi di rete
    • Datalogger
    • Componenti
    • VPN diretta (per agente)
  • Organizzazione

    • Permessi dei membri
    • Cooperazioni
    • Archiviazione file
  • Esportazione di dati

    • API di esportazione metriche
    • MiroxQL — linguaggio di query
    • Generazione esterna di report
    • Grafana
    • Panoramica dell'API
  • Assistenza

    • Richiedi una guida all'integrazione
  • mrxnode

    • Panoramica
    • Guide
    • Distribuzione su container
    • Riferimento comandi
    • Risoluzione dei problemi
  • Reportistica

    • Generatore di report esterno
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Piattaforma

    • Filosofia
    • Panoramica della piattaforma
    • Risorse della piattaforma
  • Mirox-Cloud

    • Panoramica del cloud
    • Microservizi connessi
  • Mirox-Agent

    • Panoramica dell'agente
    • Opzioni di distribuzione
    • Data Scraper
    • Gemello digitale
  • Dettagli tecnici

    • Raccolta delle metriche
  • Informazioni

    • Impianti supportati
  • Tipi di impianto

    • Impianti solari
    • Parchi eolici
    • Accumulo a batteria
  • Monitoraggio e visualizzazione

    • Monitoraggio in tempo reale
    • Gemello digitale
    • Stati dei componenti
    • Rilevamento delle perdite
    • Rilevamento dell'efficienza
    • Dashboard KPI
  • Gestione dei dati

    • Eventi
    • Ticket
    • Previsioni
    • Report
  • Integrazione e condivisione

    • Cooperazioni
    • Token API
    • VPN
    • Proxy
  • IA

    • Assistente IA e wizard
    • Accesso agentico (MCP)
  • Fatturazione

    • Mercato e tariffe
    • Contabilità e fatturazione
  • Collaborazione

    • Inviti
  • Sicurezza

    • Autenticazione
    • Sistema di permessi
    • Restrizioni di cooperazione
    • Audit log degli accessi
  • Nodi

    • mrxnode
  • Applicazione

    • Controllo della porta
    • Relè generico
  • Cluster edge

    • Orchestrazione
  • Per iniziare

    • Per iniziare
  • Personale

    • Usare la VPN
    • Usare il proxy
    • Autenticazione a due fattori
    • Sessioni
    • Token API
  • Per impianto

    • Contatti
    • Dispositivi di rete
    • Datalogger
    • Componenti
    • VPN diretta (per agente)
  • Organizzazione

    • Permessi dei membri
    • Cooperazioni
    • Archiviazione file
  • Esportazione di dati

    • API di esportazione metriche
    • MiroxQL — linguaggio di query
    • Generazione esterna di report
    • Grafana
    • Panoramica dell'API
  • Assistenza

    • Richiedi una guida all'integrazione
  • mrxnode

    • Panoramica
    • Guide
    • Distribuzione su container
    • Riferimento comandi
    • Risoluzione dei problemi
  • Reportistica

    • Generatore di report esterno
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Piattaforma

    • Filosofia della piattaforma
    • Panoramica della piattaforma
    • Risorse della piattaforma
  • Mirox-Cloud

    • Panoramica del cloud
    • Microservizi connessi
  • Mirox-Agent

    • Mirox-Agent
    • Opzioni di distribuzione dell'agente
    • Data Scraper
    • Digital Twin
  • Dettagli tecnici

    • Raccolta di metriche

Data Scraper

Il Data Scraper è il motore di raccolta dati centrale all'interno del Mirox-Agent, che recupera attivamente informazioni in tempo reale da tutte le apparecchiature monitorate nel tuo impianto. Si collega ai tuoi logger, inverter, contatori e sistemi di accumulo tramite una libreria di adattatori specifici per fornitore, normalizza tutto in un unico vocabolario coerente di metriche e inoltra il risultato al resto della piattaforma — mentre esegue un insieme crescente di analitiche edge (performance ratio, tracciamento del curtailment, baseline di cielo sereno, previsioni e monitoraggio di rete) direttamente nell'impianto.

Scopo e ruolo

Il Data Scraper ha uno scopo unico e mirato: raccogliere attivamente misurazioni grezze dalle apparecchiature e inoltrarle per l'elaborazione. Funge da ponte tra le diverse apparecchiature dei produttori e la piattaforma unificata Mirox, traducendo formati di dati proprietari in metriche standardizzate.

Responsabilità principali:

  • Connettersi a data logger e dispositivi di monitoraggio tramite adattatori specifici per fornitore
  • Recuperare misurazioni grezze secondo pianificazioni configurabili
  • Trasformare i dati specifici del produttore in un formato di metrica standardizzato
  • Rilevare e tracciare automaticamente i componenti dell'installazione
  • Monitorare l'attività e lo stato operativo dei componenti
  • Eseguire analitiche edge (potenza attesa, performance ratio, curtailment, cielo sereno e previsioni)
  • Ispezionare la rete locale dell'impianto e verificare l'accesso ai dispositivi
  • Inoltrare le metriche al Time-Series Database e al servizio Digital Twin
  • Riportare lo stato di salute e operativo dei componenti all'IoT Cloud

Questa separazione delle responsabilità mantiene il Data Scraper leggero, focalizzato e distribuibile in modo indipendente.

Panoramica dell'architettura

Il Data Scraper opera come un servizio asincrono guidato dagli eventi in cui più attività di raccolta dati vengono eseguite simultaneamente:

Principi architetturali chiave:

  • Stateless: nessuno stato persistente tra i riavvii
  • Basato su adattatori: un adattatore dedicato e specifico per fornitore parla il protocollo di ciascun dispositivo
  • Auto-riparante: ripristino automatico degli errori con backoff esponenziale
  • Concorrente: ogni sorgente dati viene raccolta in modo indipendente
  • Distribuito all'edge: opera presso o vicino all'impianto, vicino alle apparecchiature che legge

Requisiti di accesso alla rete

Il Data Scraper richiede accesso diretto alla rete TCP/IP alle sorgenti dati per la comunicazione. Questo significa tipicamente:

  • Connettività Ethernet/WiFi diretta all'indirizzo IP del dispositivo
  • Porte di rete aperte per il protocollo del dispositivo (ad es. TCP 80/443 per le API HTTP e WebSocket)
  • Routing di rete adeguato tra l'host del Data Scraper e i dispositivi

Se l'accesso diretto alla rete non è possibile (ad es. reti OT isolate, sistemi air-gapped, dispositivi solo seriali), potrebbe essere necessario implementare un collettore dati intermedio come:

  • Data logger di terze parti con connettività di rete
  • Gateway di protocollo (Serial-to-Ethernet, bridge fieldbus, ecc.)
  • Soluzione hardware personalizzata per interfacce specializzate

Consulta il nostro team di ingegneria per valutare le opzioni di connettività per la tua specifica installazione.

Il sistema di adattatori

Device-specific protocols

Adapter

Standardized data format

Concetto

Un adattatore è un modulo di connessione specifico per fornitore che sa come comunicare con una particolare famiglia di dispositivi. Ogni adattatore è costruito a mano e sottoposto a reverse engineering rispetto all'interfaccia web, API o database del dispositivo stesso — non esiste un unico motore "che parla qualsiasi protocollo". Il sistema di adattatori è il meccanismo di estensibilità centrale: supportare un nuovo dispositivo significa aggiungere un nuovo adattatore, cosa che facciamo su richiesta (vedi sotto).

Ogni adattatore è un modulo autonomo responsabile di:

  1. Gestione della connessione - Stabilire e mantenere la comunicazione
  2. Recupero dei dati - Acquisire le misurazioni utilizzando il protocollo appropriato
  3. Trasformazione dei dati - Conversione in formato di metrica standardizzato

Tutti gli adattatori ereditano da una classe base che fornisce monitoraggio dello stato di salute, logica di retry automatica, backoff esponenziale in caso di errori, validazione delle metriche e reporting dello stato alla piattaforma IoT.

Gestione dello stato di salute

Ogni adattatore implementa una macchina a stati automatica:

  • INITIALIZING: avvio e stabilimento delle connessioni iniziali
  • HEALTHY: funzionamento normale con raccolte dati riuscite
  • UNHEALTHY: presenza di errori ma con tentativo di continuare
  • RECONNECTING: esecuzione di azioni di ripristino dopo errori ripetuti
  • FROZEN: il dispositivo restituisce dati obsoleti — gli stessi valori si ripetono, oppure non è arrivata alcuna nuova lettura entro la finestra prevista
  • PAUSED: in pausa temporaneamente per comando dell'utente; riprende automaticamente alla scadenza della pausa

Il sistema transita automaticamente tra gli stati, riporta lo stato alla piattaforma e tenta il ripristino senza intervento manuale. Lo stato FROZEN è ciò che permette alla piattaforma di distinguere un logger realmente fuori servizio da uno che sta semplicemente ripetendo un valore bloccato.

Dispositivi supportati

Il Data Scraper include circa quindici adattatori specifici per fornitore, ciascuno costruito per una particolare famiglia di dispositivi. L'elenco seguente riflette ciò che è supportato oggi e cresce ogni volta che viene integrato un nuovo dispositivo.

Famiglia di dispositiviCos'èCome viene letto
Data logger BluelogLogger in stile Meteocontrol (sensori + stringhe)Login HTTP più un feed WebSocket in tempo reale
SMA Sunny CentralController di inverter centraleAPI HTTP del fornitore (con rilevamento dello spegnimento)
SMA Power ManagerController d'impianto SMAAPI HTTP del fornitore
Logger SungrowData logger per inverter SungrowConnessione WebSocket in tempo reale
Huawei SmartLoggerSmartLogger 1000 / 3000 / 4000Interfaccia web HTTP (onboarding zero-config)
Contatori JanitzaContatori di power qualityHTTP, senza credenziali (onboarding zero-config)
PLC Phoenix ContactController PLCnext / SPSAPI REST HTTPS del fornitore (onboarding zero-config)
Controller DexconController d'impiantoAPI REST HTTPS del fornitore
ZebotecInverter e sensoriAPI HTTP del fornitore
FREQCON BESSSistema di accumulo a batteriaHTTP del fornitore più un'interfaccia di query su serie temporali
PRTGServer di monitoraggio di reteAPI HTTP PRTG
Historian BeckerDatabase historian (Microsoft SQL Server)Connessione Microsoft SQL Server
Object storage / fileStorage S3 o compatibile S3 e file localiScansione di file con parsing CSV/Excel e rilevamento dei gap
Modello meteoMeteo Open-Meteo + modello di potenza PV su dispositivoHTTP (modellazione cielo sereno e irraggiamento)

Trasporti reali in uso

In questi adattatori, i metodi di comunicazione effettivi sono API HTTP/HTTPS del fornitore (i più comuni), connessioni WebSocket in tempo reale (Bluelog e Sungrow), Microsoft SQL Server (l'historian Becker), accesso S3 / file e un'interfaccia di query su serie temporali utilizzata solo dall'adattatore per la batteria FREQCON. Non esiste un'acquisizione generica Modbus, MQTT, FTP/SFTP o WebDAV — ogni integrazione è realizzata appositamente per il proprio dispositivo.

Creazione di nuovi adattatori

È possibile sviluppare nuovi adattatori per supportare ulteriori dispositivi o protocolli. Il design modulare e le funzionalità della classe base riducono significativamente i tempi di sviluppo.

Compatibilità con apparecchiature legacy: possiamo creare adattatori per dispositivi più datati che non sono mai stati progettati specificamente per l'esportazione dei dati. Finché il dispositivo fornisce i suoi dati in qualsiasi modo accessibile — che sia tramite un'API REST, un'interfaccia web, un database, un file system o qualsiasi altro meccanismo — possiamo estrarre e integrare tali dati nella piattaforma.

Raccolta dati senza restrizioni: i nostri adattatori non si limitano ai formati di esportazione dati predefiniti che i data logger tipicamente forniscono. Possiamo raccogliere qualsiasi dato che il dispositivo rende disponibile, andando oltre l'insieme standard di metriche che il logger di un produttore potrebbe esporre. Se un dispositivo dispone di informazioni diagnostiche aggiuntive, parametri avanzati o punti dati nascosti accessibili tramite la sua interfaccia, possiamo recuperarli e standardizzarli.

Adattatori personalizzati su richiesta

Possiamo creare nuovi adattatori per praticamente qualsiasi sorgente dati in qualsiasi momento su richiesta del cliente. Il sistema di adattatori è progettato per una rapida estensibilità — il supporto per un nuovo protocollo può tipicamente essere implementato nel giro di giorni a seconda della complessità. Se disponi di apparecchiature di un produttore non ancora supportato, contattaci per discutere lo sviluppo di un adattatore personalizzato.

Nessuna documentazione del fornitore richiesta

Lo sviluppo di adattatori non richiede rigorosamente la documentazione delle API del fornitore. Attraverso l'analisi del traffico di rete, il reverse engineering del protocollo (dove legalmente consentito) e i test empirici, possiamo spesso creare adattatori funzionanti anche per dispositivi con interfacce non documentate. Questa capacità è particolarmente preziosa per apparecchiature legacy o sistemi con protocolli proprietari.

Onboarding tramite la piattaforma

Per un sottoinsieme di dispositivi, puoi mettere online un logger dalla piattaforma senza scrivere a mano alcuna configurazione. Una procedura guidata di onboarding chiede all'agente di eseguire una connessione di prova (test a vuoto) al dispositivo e ti restituisce in tempo reale i risultati della verifica, così vedi immediatamente se la connessione funziona prima di confermarla. Ci sono due varianti:

  • Onboarding zero-config — l'adattatore possiede già l'intero set di letture del dispositivo, quindi la procedura guidata mostra solo un'anteprima live in sola lettura e salvi. Disponibile oggi per contatori Janitza, Huawei SmartLogger e controller Phoenix Contact. Janitza non necessita di alcuna credenziale.
  • Mappatura interattiva per logger generici — alcuni logger espongono valori grezzi arbitrari che la piattaforma non è in grado di interpretare da sola. Per questi la procedura guidata chiede all'agente di enumerare ogni valore grezzo esposto dal dispositivo (gruppo, nome, unità, campione live), l'operatore associa ciascuno a una metrica nota e un test a vuoto guidato dalla mappatura mostra in anteprima le metriche esatte che verrebbero prodotte prima del salvataggio. QReader è il primo logger generico supportato in questo modo.

Non è plug-and-play universale

Solo le famiglie di dispositivi sopra elencate sono oggi gestibili tramite procedura guidata (le tre famiglie zero-config più i logger generici come QReader). Tutti gli altri adattatori richiedono ancora una configurazione per dispositivo fornita con l'agente, quindi considera l'automazione dell'onboarding come specifica per dispositivo piuttosto che universale.

Standardizzazione delle metriche

Tutti i dati raccolti vengono trasformati in un formato di metrica standardizzato definito dalla tassonomia delle metriche della piattaforma. Questo garantisce coerenza tra tutte le sorgenti dati e consente un'elaborazione unificata a valle.

Struttura della metrica

Ogni metrica segue una struttura standardizzata compatibile con i moderni database di serie temporali:

Componenti:

  • Nome: identificatore di metrica standardizzato dalla tassonomia predefinita
  • Valore: misurazione numerica in unità SI di base
  • Etichette: coppie chiave-valore per l'identificazione e il raggruppamento dei componenti
  • Timestamp: conservazione opzionale del timestamp originale del dispositivo

Etichette standard:

  • Tipo di adattatore sorgente e numero di istanza
  • Nomi leggibili dall'uomo
  • Identificatori dei componenti (ID inverter, numero di stringa, ecc.)
  • Posizione fisica o informazioni di raggruppamento

Convenzioni delle unità

Tutte le metriche utilizzano unità SI di base indipendentemente da ciò che riporta il dispositivo del produttore:

  • Potenza: Watt (W)
  • Energia: Wattora (Wh)
  • Tensione: Volt (V)
  • Corrente: Ampere (A)
  • Temperatura: Celsius (°C)
  • Irraggiamento: Watt per metro quadrato (W/m²)

Gli adattatori convertono automaticamente dalle unità specifiche del produttore (kW, MWh, ecc.) a questi standard durante la fase di trasformazione.

Categorie di metriche

La piattaforma definisce 376 tipi di metriche standardizzate organizzate in 11 famiglie:

FamigliaNumeroCosa copre
Powerplant156Rete, uscita CA, inverter, combiner box, stringhe, irraggiamento
Battery86Batteria box, accumulo, misurazioni di modulo e cella
Weather46Input e misurazioni meteo
Weather Model16Produzione PV modellata dai dati meteo
Network SNMP16Letture SNMP dai dispositivi di rete
Agent19Auto-telemetria e stato di salute dell'agente
Network Monitor11Misurazioni di monitoraggio della rete locale
AI Usage11Utilizzo delle funzionalità AI all'edge
Operator7Telemetria della flotta di operatori
Network4Connettività di base
Scraper4Auto-metriche del Data Scraper

Le espansioni delle etichette (per stringa, per fase, per inverter e così via) moltiplicano queste in molte più serie temporali individuali in un impianto reale. Per la tassonomia completa delle metriche e le definizioni, consulta Raccolta delle metriche.

Flusso di raccolta dati

Strategie di polling

Gli adattatori supportano due modalità di polling:

Basato su intervallo (predefinito): si esegue ogni N secondi dopo il completamento della raccolta precedente. Semplice e reattivo a durate di raccolta variabili.

Basato su orario fisso: si esegue a intervalli fissi a partire dalla mezzanotte con uno scostamento opzionale (ad es. alle 00:01, 05:01, 10:01 per intervalli di 5 minuti con uno scostamento di 1 minuto). Utile per l'allineamento con sistemi esterni.

Pipeline di elaborazione

Dopo la raccolta, le metriche attraversano diverse fasi di elaborazione:

Preparazione delle metriche: vengono aggiunte le etichette sorgente, applicati i timestamp e validata la struttura.

Filtraggio: i filtri configurati possono modificare valori, validare intervalli o saltare metriche in base a regole.

Calcoli: i calcolatori automatici derivano metriche aggiuntive:

  • La potenza di radiazione solare integrata in energia di irraggiamento
  • La tensione × corrente di stringa calcolata in potenza
  • I valori di potenza integrati in energia nel tempo

Rilevamento dei componenti: man mano che le metriche fluiscono, il Data Scraper rileva e identifica automaticamente i componenti dell'installazione. Questa è una funzionalità cruciale — poiché il Data Scraper è il livello che raccoglie attivamente i dati, sa intrinsecamente quali componenti esistono e stanno fornendo dati. Il sistema rileva automaticamente:

  • Inverter (dalle metriche di potenza degli inverter)
  • Combiner box di stringa / GAK (dalle metriche GAK)
  • Singole stringhe (dalle metriche di tensione/corrente di stringa)
  • Sensori di irraggiamento (dalle metriche di radiazione)
  • Punti di connessione alla rete (dalle metriche di energia di rete)

I componenti rilevati vengono sincronizzati con la piattaforma IoT per la gestione dell'inventario, creando un registro delle apparecchiature in tempo reale e auto-manutenuto senza configurazione manuale.

Tracciamento dell'attività dei componenti

Poiché il Data Scraper effettua continuamente il polling delle sorgenti dati, può rilevare quali componenti stanno fornendo attivamente dati e quali hanno smesso di rispondere. Quando un componente smette di inviare metriche, il Data Scraper lo contrassegna come inattivo nell'IoT Cloud. Quando riprende, viene automaticamente contrassegnato di nuovo come attivo. Questo fornisce consapevolezza in tempo reale dello stato operativo delle apparecchiature — non solo se il Data Scraper riesce a raggiungere il data logger, ma se i singoli componenti all'interno dell'installazione funzionano e riportano dati.

Rilevamento della produzione: il sistema monitora lo stato operativo dell'impianto:

  • Rileva quando inizia la produzione in base a irraggiamento e potenza
  • Identifica spegnimenti imprevisti durante le ore di produzione
  • Riporta le transizioni di stato per gli avvisi

Raggruppamento delle metriche: le metriche vengono raggruppate in batch per serie temporale per ottimizzare le prestazioni di inserimento nel database.

Ottimizzazione del traffico di rete

Dopo il raggruppamento e il batching delle metriche, il Data Scraper applica una compressione aggiuntiva prima di trasmettere i dati al Mirox-Cloud. Questo riduce significativamente il volume del traffico di rete, particolarmente vantaggioso quando la larghezza di banda internet è limitata o a consumo. Per maggiori dettagli sulle considerazioni relative alla larghezza di banda, consulta Distribuzione on-site.

Esportazione dei dati

Le metriche elaborate vengono inoltrate a due destinazioni:

Time-Series Database: le metriche vengono inviate in batch con rate limiting e logica di retry per l'archiviazione a lungo termine e l'interrogazione storica.

Webhook Digital Twin: un'attività in background separata inoltra continuamente i valori delle metriche più recenti al servizio Digital Twin (un microservizio completamente separato) per l'analisi in tempo reale. Il Data Scraper non sa nulla di cosa fa il Digital Twin con i dati — si limita a fornire le metriche. Per informazioni sull'elaborazione del Digital Twin, consulta Digital Twin.

Funzionamento stateless

Il Data Scraper è progettato per essere completamente stateless:

  • Nessuno storage persistente — tutto lo stato esiste solo in memoria
  • Può essere arrestato e riavviato senza perdita di dati
  • Più istanze possono essere eseguite in modo indipendente per parchi diversi
  • Ogni ciclo di polling è indipendente dai cicli precedenti
  • Resistente ai crash, senza rischio di corrompere lo stato persistente

L'unico stato persistente esiste esternamente:

  • File di configurazione (versionati)
  • Time-Series Database (sistema esterno)
  • Registro dei componenti dell'IoT Cloud (sistema esterno)

Questo design garantisce semplicità operativa, affidabilità e una facile scalabilità orizzontale.

Separazione delle responsabilità

Il Data Scraper ha una responsabilità ristretta e focalizzata che consente una chiara separazione dagli altri componenti della piattaforma:

Data Scraper:

  • Raccoglie misurazioni grezze dalle apparecchiature
  • Trasforma i dati in formato standard
  • Rileva e traccia i componenti
  • Monitora lo stato di attività dei componenti
  • Inoltra le metriche ad altri servizi

Digital Twin: convalida rispetto a modelli fisici e rileva anomalie e perdite

Time-Series Database: archivia i dati storici, fornisce un'interfaccia di interrogazione

IoT Cloud: mantiene il registro dei componenti, traccia lo stato dei dispositivi, gestisce l'inventario delle apparecchiature

Questa separazione consente lo sviluppo, il test, la distribuzione e la scalabilità indipendenti di ciascun componente, garantendo al contempo che ogni servizio si concentri sulla propria competenza principale.

Funzionalità avanzate

Monitoraggio automatico dello stato di salute

Ogni adattatore implementa una macchina a stati che traccia lo stato di salute operativo con reporting automatico alla piattaforma ed esposizione tramite l'API delle metriche per il monitoraggio operativo.

Rilevamento automatico dei componenti

La posizione del Data Scraper come livello di raccolta dati gli conferisce un vantaggio unico: sa intrinsecamente quali componenti esistono in un'installazione perché interagisce direttamente con le metriche che producono. Man mano che le metriche fluiscono attraverso il sistema, i componenti vengono rilevati automaticamente dalle etichette delle metriche e registrati con la piattaforma IoT.

Processo di rilevamento:

  1. Le metriche arrivano con etichette identificative (ID inverter, numero di stringa, posizione del sensore, ecc.)
  2. Il Data Scraper estrae le informazioni sui componenti da queste etichette
  3. I nuovi componenti vengono registrati automaticamente con l'IoT Cloud
  4. I metadati dei componenti (tipo, identificatore, posizione) vengono sincronizzati
  5. La piattaforma mantiene un inventario aggiornato delle apparecchiature senza inserimento manuale

Questo meccanismo di auto-rilevamento garantisce che la piattaforma sappia sempre quali apparecchiature esistono nell'installazione, eliminando la necessità di configurazione manuale e riducendo i tempi di distribuzione.

Rilevamento dello stato di produzione

Il servizio monitora lo stato operativo dell'impianto e rileva gli avvii di produzione, gli spegnimenti imprevisti durante le ore di produzione e le transizioni di stato per avvisi e analisi, riportando solo quando lo stato cambia effettivamente. Sorveglia anche la sovrapproduzione — output superiore al modello di cielo sereno per un periodo prolungato — che può segnalare un logger che restituisce valori bloccati e, in tal caso, ripiegare sul modello di cielo sereno affinché il flusso di dati rimanga sensato. Questo fornisce consapevolezza operativa in tempo reale oltre le sole misurazioni grezze.

Metriche calcolate

Diversi calcolatori derivano automaticamente metriche dalle misurazioni grezze — la radiazione solare integrata in energia di irraggiamento, la potenza di stringa calcolata da tensione e corrente, e i valori di potenza integrati in energia nel tempo. Questi calcoli avvengono in modo trasparente, arricchendo il flusso di dati senza richiedere una configurazione esplicita.

Analitica edge

Oltre alla raccolta grezza, il Data Scraper esegue un insieme di analitiche direttamente nell'impianto, calcolate dal feed di metriche in tempo reale ed esportate come serie temporali rappresentabili in grafici insieme ai dati grezzi.

Potenza attesa e performance ratio

L'agente calcola la potenza attesa per ciascun impianto a partire dalle sue sorgenti di irraggiamento (piranometro on-site, radiazione satellitare o modello meteo) e la confronta con l'output effettivo per derivare il performance ratio (PR) — una misura normalizzata di quanto bene l'impianto converte la luce solare disponibile in elettricità. Il PR viene calcolato per giorno e tiene conto del clipping, del gelo e dei filtri di qualità dei dati, in modo che i giorni anomali non distorcano il risultato.

Tracciamento del curtailment in tempo reale

Quando un impianto produce meno di quanto potrebbe, l'agente attribuisce la produzione mancata alla sua causa: curtailment da parte del marketer (un limite deliberato guidato dal mercato) rispetto al curtailment da parte del gestore di rete. Questa distinzione è importante per la contabilizzazione delle perdite e il reporting contrattuale. Il curtailment viene tracciato al minuto ed emesso sia come potenza istantanea sia come energia cumulativa. Consulta Rilevamento delle perdite per capire come il curtailment si inserisce nell'attribuzione complessiva delle perdite.

Baseline di cielo sereno e previsioni

  • Baseline di cielo sereno: una curva PV teorica in condizioni ideali mantenuta come registro a lungo termine, che ti offre un riferimento stabile per confrontare l'output reale.
  • Previsione day-ahead: una previsione di produzione PV a breve orizzonte derivata dai dati meteo, così puoi anticipare l'output del giorno successivo. Queste sono basate sulla fisica meteorologica, non su congetture statistiche.

Backfill storico

Quando un impianto viene connesso per la prima volta o dopo un'interruzione, l'agente può eseguire il backfill dei dati storici — riproducendo le letture grezze e ri-derivando le analitiche sopra descritte per una finestra richiesta, per poi consegnare il risultato alle pipeline in tempo reale, in modo che i grafici siano completi fin dal primo giorno invece di partire vuoti.

Monitoraggio della rete

Il Data Scraper include un ispettore della rete locale integrato che opera insieme alla raccolta dati e mappa la rete on-site dell'impianto. Rileva i dispositivi negli intervalli di rete configurati eseguendo una scansione degli host raggiungibili, leggendo la tabella degli indirizzi, identificando i fornitori dagli indirizzi hardware e sondando i dispositivi per la loro identità. I dispositivi rilevati vengono classificati rispetto a un'ampia libreria di profili di apparecchiature di rete note, e un passaggio di identificazione dei dispositivi tramite AI aiuta a riconoscere le famiglie di dispositivi che le regole semplici non rilevano.

Una volta noti i dispositivi, l'ispettore ne effettua il polling per raggiungibilità e stato di salute (tempo di risposta, stato delle interfacce e delle risorse) e riporta i risultati alla piattaforma. Puoi avviare o arrestare una scansione di rilevamento, ricontrollare un singolo dispositivo e rivedere la rete rilevata — consulta Ispettore della rete locale.

Auditing del proxy

Per gli impianti raggiungibili tramite il Mirox Browser Proxy, l'agente verifica l'accesso umano alle interfacce dei dispositivi locali. Raggruppa l'attività di ciascuna persona in sessioni, oscura i dati di query sensibili prima che qualsiasi cosa venga archiviata e può produrre un riepilogo generato dall'AI di ciò che una sessione ha fatto. Questo alimenta la traccia di audit degli accessi della piattaforma — consulta Registro di audit degli accessi.

Caratteristiche di prestazione

Prestazioni tipiche:

  • Frequenze di polling: 1-300 secondi per adattatore (configurabile)
  • Adattatori concorrenti: 20+ in esecuzione simultaneamente
  • Throughput: 10.000+ metriche al minuto in modo sostenuto
  • Latenza: sotto i 100 ms dalla raccolta all'inserimento nel database
  • Utilizzo delle risorse: 5-15% di CPU, 100-500 MB di memoria su hardware edge

L'architettura asincrona garantisce un'elevata concorrenza senza blocchi, consentendo una raccolta efficiente da molte sorgenti simultaneamente.

Funzionalità correlate

  • Digital Twin — il motore di analisi basato sulla fisica che consuma le metriche raccolte dal Data Scraper
  • Panoramica del Mirox-Agent — come il Data Scraper si inserisce nell'agente edge più ampio
  • Opzioni di distribuzione — i compromessi tra distribuzione on-site e cloud per l'agente
  • Raccolta delle metriche — la tassonomia completa delle metriche standardizzate
  • Ispettore della rete locale — la superficie di monitoraggio della rete on-site
  • Rilevamento delle perdite — come vengono attribuiti il curtailment e le altre perdite
Prev
Opzioni di distribuzione dell'agente
Next
Digital Twin
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH