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) e un continuo watchdog di salute dei componenti 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
• Sorvegliare continuamente la salute dei componenti e lo stato delle connessioni, aprendo eventi di parco per interruzioni, conflitti di misurazione e problemi di connessione
• 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:

• Nessun database proprio: nessuno stato di analisi sopravvive ai riavvii; i dati non consegnati vengono bufferizzati su disco locale finché non possono essere inviati
• 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

Il sistema di adattatori

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 venti 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.

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.

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 diciassette famiglie di dispositivi: contatori Janitza, Huawei SmartLogger, controller Phoenix Contact, inverter Fronius, data logger Solar-Log, SMA Sunny Central, SMA Power Manager, logger Sungrow, Zebotec, Becker PV-Control (Prometheus), sistemi di accumulo a batteria FREQCON, Wattkraft Parkcontrol, convertitori per batterie NR Electric, batterie a container Linyang/Xieneng relè di protezione SEG HighPROTEC, batterie INTILION scalecube e il controllore di allarme WAGO PFC200. Diverse di queste — ad esempio Janitza, Fronius e Wattkraft — non necessitano di alcuna credenziale; SMA Power Manager e logger Sungrow si onboardano con le credenziali del dispositivo e segnalano inoltre automaticamente il proprio inventario dispositivi (elenco componenti, numeri di serie, firmware) invece di richiederlo in digitazione. Il controllore di allarme WAGO è l'unica eccezione al percorso rapido: nulla sul filo dice quale programma stia eseguendo una WAGO, quindi non viene mai rilevato automaticamente — si aggiunge tramite Aggiungi logger, scegliendo a mano l'adattatore e il suo profilo di integratore.
• 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 e Bluelog vengono integrati in questo modo.

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 451 tipi di metriche standardizzate organizzate in 11 famiglie:

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.

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.

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 non mantiene alcun database proprio e non conserva alcuno stato di analisi tra i riavvii:

• 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
• Le misurazioni e i report di stato che non possono essere consegnati — ad esempio durante un'interruzione di internet — vengono bufferizzati su disco locale e consegnati automaticamente al ripristino della connettività, così nulla va perso (la resilienza "Conservazione locale / Ripresa automatica" descritta nella Panoramica del Mirox-Agent)

L'unico stato persistente è il buffer locale di consegna dei dati non ancora trasmessi, oltre a ciò che risiede 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
• Sorveglia in tempo reale la salute dei componenti e lo stato delle connessioni, aprendo e chiudendo eventi di parco
• 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 continuamente la potenza attesa per ciascun impianto e vi confronta la produzione effettiva sotto forma di performance ratio (PR) — una misura normalizzata di quanto bene l'impianto converte la luce solare disponibile in elettricità. Invece di fidarsi di un singolo input, più sorgenti di irraggiamento indipendenti vengono monitorate in parallelo, e ciascuna sorgente ottiene la propria serie di PR — così un sensore on-site che deriva non potrà mai distorcere silenziosamente la tua baseline:

• Piranometro on-site — i sensori di irraggiamento propri dell'impianto, disponibili quasi in tempo reale
• Satellite — irraggiamento derivato da satellite per la posizione esatta del sito
• Modello meteo — irraggiamento modellato a partire dai dati meteorologici

Conversione al piano dei moduli (POA). Tutte le sorgenti vengono convertite in irraggiamento sul piano dei moduli (plane-of-array, POA) — l'irraggiamento che colpisce effettivamente i moduli — utilizzando la gerarchia dei componenti dell'impianto (il park tree): ogni stringa porta con sé il proprio orientamento, un grado di azimut e un'inclinazione, configurati dall'operatore o rilevati dal motore di analisi. L'irraggiamento orizzontale viene scomposto nelle sue componenti diretta e diffusa e trasposto su ciascun piano di moduli distinto con la fisica della posizione solare standard di settore, così i campi di moduli orientati in direzioni diverse ottengono ciascuno la propria aspettativa corretta. Le aspettative delle stringhe vengono sommate in curve per combiner box e inverter e limitate alla potenza nominale CA di ciascun inverter.

Filtraggio delle anomalie. Prima che un istante possa contare per il PR affidabile ("pulito"), una batteria di filtri maschera ogni situazione in cui un rapporto basso non significherebbe un guasto:

Un PR per sorgente. Il performance ratio viene poi calcolato separatamente per ciascuna sorgente di irraggiamento — pubblicato sia grezzo (ogni valore calcolabile) sia pulito (solo i valori filtrati e affidabili) — a livello di parco e per componente (inverter, combiner box, stringa). La media mobile del PR pulito inoltre auto-calibra il modello di potenza attesa: l'aspettativa si adatta automaticamente all'efficienza reale di ciascun impianto, e questa stessa aspettativa è ciò con cui il watchdog di salute dei componenti confronta la produzione in tempo reale.

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.

Watchdog di salute dei componenti

Oltre a raccogliere dati, l'agente giudica continuamente se ogni componente in produzione — inverter, combiner box (GAK), stringhe e sensori di irraggiamento — sia davvero in salute, e trasforma le sue conclusioni in eventi di parco che vedi sulla piattaforma. Due domande vengono poste giorno e notte: il componente è ancora connesso e sta producendo quanto dovrebbe?

Monitoraggio delle connessioni

La connettività viene tracciata come una rigorosa catena causale — collegamento del parco, dispositivi di rete, data logger, componenti — e il watchdog differenzia i modi in cui una connessione può interrompersi, ciascuno con il proprio evento:

Un solo allarme per causa radice. Ogni livello apre eventi solo mentre tutti i livelli sopra di esso sono in salute: un'interruzione a livello di parco apre esattamente un evento a livello di parco e trattiene silenziosamente tutto ciò che sta sotto, uno switch guasto apre un evento di dispositivo, e solo quando il percorso di rete e il logger sono dimostrabilmente a posto un componente silenzioso diventa un guasto di componente. Tutte le transizioni sono stabilizzate (debounce) contro riavvii e brevi intermittenze, e ogni evento si chiude automaticamente al ripristino, indicando la durata dell'interruzione.

Verifiche di potenza e produzione

In parallelo, il watchdog confronta la potenza misurata di ciascun componente con il modello di potenza attesa in brevi finestre di valutazione. Uno zero o un deficit conta come evidenza solo quando un gate ambientale dimostra che le condizioni giustificano la produzione — irraggiamento sufficiente e sostenuto, niente neve, gelo o nebbia, nessun curtailment effettivamente vincolante e un percorso di rete in salute — così una buia mattina d'inverno non potrà mai far scattare un allarme.

Prima che un allarme si apra, il risultato viene messo a confronto incrociato con testimoni indipendenti: i figli del componente un livello più in basso nella gerarchia, il proprio contatore di energia cumulativa e un audit energetico notturno tra genitore e figli. L'esito decide quale tipo di evento ricevi:

• Interruzione di produzione — il componente ha davvero smesso di produrre in condizioni in cui dovrebbe produrre
• Conflitto di misurazione — il componente sta producendo, ma la sua lettura è errata (un guasto nei dati da investigare, mai conteggiato come produzione persa)
• Nessuna comunicazione — il componente ha smesso completamente di riportare dati; la produzione è sconosciuta e deliberatamente non conteggiata come perdita
• Produzione ridotta — il componente sta producendo, ma molto al di sotto della sua aspettativa modellata (giudicato sia in tempo reale sia in un audit notturno sull'intera giornata)

Le stringhe e i sensori di irraggiamento ricevono indagini per fasi invece di verdetti istantanei: una stringa silenziosa apre dapprima un'indagine a bassa priorità e viene confermata come interruzione o difetto solo con prove di livello fisico — ad esempio output zero sotto un cielo coperto mentre le sue stringhe sorelle producono — mentre zeri ricorrenti che seguono il percorso del sole vengono riconosciuti e registrati come ombreggiamento, non come difetto. Un sensore il cui canale di irraggiamento si spegne mentre gli altri suoi canali restano attivi viene segnalato come sporcamento (pulire la cupola) anziché come difetto hardware.

Segni vitali degli inverter

Le verifiche sopra chiedono se un inverter stia ancora producendo. Un secondo gruppo di verifiche chiede se un inverter che produce si stia avviando in silenzio verso un difetto — leggendo i segnali che l'agente già raccoglie da ogni inverter ma che non ha mai usato per giudicarlo: temperatura, resistenza di isolamento, correnti e tensioni per fase e il lato DC (tensione e potenza).

Un percorso di manutenzione proprio. Questi rilievi non arrivano mai come un'interruzione: l'inverter sta producendo e nulla è ancora perduto. Si aprono come rilevazioni di manutenzione, tenute deliberatamente separate dagli eventi di interruzione di cui sopra — le normali segnalazioni di stato di salute di un inverter che produce non possono mai chiudere un rilievo di manutenzione, e un rilievo di manutenzione aperto non può mai impedire l'apertura di un vero allarme di interruzione. E non spostano mai un numero di produzione: un inverter con un rilievo di manutenzione continua a contare come produttivo ovunque la piattaforma conti i componenti che producono, perché sta producendo.

Ogni rilievo è un evento a sé. Non esiste più una voce generica "Manutenzione richiesta inverter": ogni rilievo viene segnalato con il proprio nome parlante (Temperatura elevata, Isolamento in calo, Squilibrio di fase, Rendimento in calo), e ogni inverter porta al massimo un evento aperto per rilievo. Più rilievi possono quindi stare fianco a fianco sulla stessa unità, ciascuno con il proprio ragionamento, la propria storia e il proprio rientro, invece di confluire in un'unica voce che dice soltanto "qui c'è qualcosa da guardare".

L'osservazione si vede, il verdetto aspetta. Un sospetto appena nato non sparisce più nella contabilità interna dell'agente. Non appena una verifica ha di che interessarsi, apre un evento di osservazione a bassa priorità — "Osservazione: temperatura elevata", "Osservazione: squilibrio di fase" e così via, con la stessa icona del rilievo confermato, in una tinta più chiara. L'elenco attività dell'impianto mostra così esattamente che cosa il sistema sta osservando, e da quando. Ciò che un evento simile deliberatamente non fa è cambiare lo stato di salute di un componente: le osservazioni non compaiono mai nelle viste di salute — pagine di analisi e di produzione, chip dei componenti, colonna dei componenti delle stazioni e i relativi conteggi — perché lì la piattaforma pronuncia un verdetto solo quando è sicura. Un'osservazione è una traccia, non un verdetto.

Una sola catena, dal primo sospetto al rilievo. Quando arriva la prova di conferma, l'osservazione viene chiusa e al suo posto si apre il rilievo confermato a priorità normale, collegato all'osservazione da cui è nato. I due si leggono come un'unica storia — osservato da quel giorno, confermato in quell'altro — e la chiusura dell'osservazione non annuncia alcun rientro, perché nulla è rientrato: il rilievo è semplicemente salito di stadio. Solo dalla conferma in poi compare nelle viste di salute. Se la conferma non arriva mai, l'osservazione si richiude da sé quando la condizione sparisce, e non è mai stato affermato nulla.

Gli eventi di manutenzione nominano il componente inverter reale e portano lo stesso ragionamento in linguaggio semplice di ogni altro evento, con i numeri concreti alle spalle — l'eccesso misurato, il confronto con le unità vicine, il numero di giorni osservati. Per ora sono deliberatamente silenziosi: compaiono nell'elenco eventi dell'impianto ma restano sotto ogni soglia di notifica, mentre le nuove verifiche vengono calibrate su dati reali della flotta. Eventi dell'inverter descrive che cosa apre, conferma e chiude ciascuna di esse.

Prove di causa sugli eventi esistenti

Due dei segnali appena letti non generano eventi propri — rafforzano quelli che già esistono:

Lato AC o lato DC? Quando il watchdog apre un'interruzione di produzione di un inverter, legge anche la tensione DC esattamente nelle finestre diurne in cui l'unità non ha erogato nulla. Un bus DC spento significa che la causa sta sul lato DC (stringhe, apparecchiature DC); uno in tensione significa che il generatore è intatto e il guasto sta nell'unità stessa o sul suo lato AC. Il verdetto — lato AC, lato DC o indeterminato — entra nel ragionamento dell'evento di interruzione e decide quale intervento di servizio abbia senso. Il testimone dipende dal costruttore: alcuni dispositivi — tra cui Huawei — non segnalano mai un bus spento, quindi lì può solo scagionare il lato DC, mai accusarlo.

Una riduzione dovuta alla rete non è un difetto. Quando un singolo inverter mantiene la sua tensione AC a 1,10 volte la tensione nominale o oltre durante una finestra di sottoprestazione, sta limitando l'uscita di proposito, seguendo la regola volt-watt delle prescrizioni di connessione — sta obbedendo alla rete, non guastandosi. Tali finestre vengono tenute neutre invece di essere conteggiate come deficit, così che un allacciamento di rete rigido non possa mai accumularsi in un falso difetto.

Quanto rapidamente vengono rilevati gli eventi?

Questi rilevatori non osservano in modo continuo. Girano una volta per notte — più una volta poco dopo l'avvio dell'agente — e ricostruiscono le loro prove dallo storico registrato a ogni passaggio. Una condizione presente da settimane viene quindi trovata alla prima valutazione una volta che la sua verifica è armata, e non settimane dopo. Ciò che richiede tempo è la prova stessa: ogni verifica pretende uno storico minimo e una serie di persistenza prima di dire alcunché. La prima colonna qui sotto indica il punto in cui si apre l'osservazione — bassa priorità, visibile nell'elenco attività dell'impianto, deliberatamente assente dalle viste di salute. La seconda indica che cosa serve perché quell'osservazione venga sostituita dal rilievo ufficiale, l'unico che quelle viste mostrano.

Un impianto appena collegato vede quindi le prime osservazioni sulla temperatura dopo circa tre settimane e le prime osservazioni di efficienza dopo circa due mesi, mentre il testimone DC e l'esonero di rete funzionano dal primo giorno.

Vale la pena conoscere due limiti:

• Un gruppo di confronto richiede almeno sei inverter comparabili. Tutte queste regole sono relative alle unità vicine — ogni apparecchio è giudicato rispetto ai propri simili, mai rispetto a una soglia assoluta, perché i limiti assoluti scalano con la dimensione del generatore e con il costruttore. La conseguenza è deliberata: se un intero gruppo di confronto degrada allo stesso modo nello stesso momento, questa deriva comune non è rilevabile con questo metodo.
• La copertura è per inverter ed è dettata dai dati. Una verifica si arma solo dove il logger del costruttore fornisce davvero la metrica — nessun interruttore di configurazione la attiva. La copertura differisce quindi da impianto a impianto e da costruttore a costruttore.

Eventi che si spiegano da soli

Ogni evento porta con sé un ragionamento in linguaggio semplice: cosa è stato misurato, in quali condizioni, quali evidenze indipendenti lo hanno corroborato o contraddetto e cosa lo risolverebbe. Gli eventi si chiudono automaticamente al ripristino comprovato, vengono riclassificati sul posto quando le evidenze cambiano il quadro (mai un'oscillazione di chiusura e riapertura) e rispettano le tue decisioni — un evento che chiudi resta chiuso finché il guasto non si guadagna pienamente un nuovo evento. Un unico evento riepilogativo "componenti fuori servizio" a livello di parco porta il vero allarme per l'operatore: si apre quando almeno un inverter o combiner box è fuori servizio da un periodo prolungato, elenca i componenti interessati e invia notifiche solo alla prima apertura e al ripristino definitivo.

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
• Eventi — come gli eventi di parco del watchdog ti raggiungono