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:
- Gestione della connessione - Stabilire e mantenere la comunicazione
- Recupero dei dati - Acquisire le misurazioni utilizzando il protocollo appropriato
- 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 dispositivi | Cos'è | Come viene letto |
|---|---|---|
| Data logger Bluelog | Logger in stile Meteocontrol (sensori + stringhe) | Login HTTP più un feed WebSocket in tempo reale |
| SMA Sunny Central | Controller di inverter centrale | API HTTP del fornitore (con rilevamento dello spegnimento) |
| SMA Power Manager | Controller d'impianto SMA | API HTTP del fornitore |
| Logger Sungrow | Data logger per inverter Sungrow | Connessione WebSocket in tempo reale |
| Huawei SmartLogger | SmartLogger 1000 / 3000 / 4000 | Interfaccia web HTTP (onboarding zero-config) |
| Contatori Janitza | Contatori di power quality | HTTP, senza credenziali (onboarding zero-config) |
| PLC Phoenix Contact | Controller PLCnext / SPS | API REST HTTPS del fornitore (onboarding zero-config) |
| Controller Dexcon | Controller d'impianto | API REST HTTPS del fornitore |
| Zebotec | Inverter e sensori | API HTTP del fornitore |
| FREQCON BESS | Sistema di accumulo a batteria | HTTP del fornitore più un'interfaccia di query su serie temporali |
| PRTG | Server di monitoraggio di rete | API HTTP PRTG |
| Historian Becker | Database historian (Microsoft SQL Server) | Connessione Microsoft SQL Server |
| Object storage / file | Storage S3 o compatibile S3 e file locali | Scansione di file con parsing CSV/Excel e rilevamento dei gap |
| Modello meteo | Meteo Open-Meteo + modello di potenza PV su dispositivo | HTTP (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:
| Famiglia | Numero | Cosa copre |
|---|---|---|
| Powerplant | 156 | Rete, uscita CA, inverter, combiner box, stringhe, irraggiamento |
| Battery | 86 | Batteria box, accumulo, misurazioni di modulo e cella |
| Weather | 46 | Input e misurazioni meteo |
| Weather Model | 16 | Produzione PV modellata dai dati meteo |
| Network SNMP | 16 | Letture SNMP dai dispositivi di rete |
| Agent | 19 | Auto-telemetria e stato di salute dell'agente |
| Network Monitor | 11 | Misurazioni di monitoraggio della rete locale |
| AI Usage | 11 | Utilizzo delle funzionalità AI all'edge |
| Operator | 7 | Telemetria della flotta di operatori |
| Network | 4 | Connettività di base |
| Scraper | 4 | Auto-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:
- Le metriche arrivano con etichette identificative (ID inverter, numero di stringa, posizione del sensore, ecc.)
- Il Data Scraper estrae le informazioni sui componenti da queste etichette
- I nuovi componenti vengono registrati automaticamente con l'IoT Cloud
- I metadati dei componenti (tipo, identificatore, posizione) vengono sincronizzati
- 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