Il percorso di controllo ad anello chiuso di Eldric collega il policy worker (xLSTM) ai tuoi endpoint industriali. Cinque opzioni di trasporto coprono diverse forme di deployment, e un fallback di sicurezza guidato da watchdog mantiene sano l'anello quando il policy worker manca il suo deadline. Le fasce di licenza variano per trasporto — vedi la tabella sotto.
L'anello di controllo lavora alla frequenza che imposti (tipicamente 10–100 Hz). A ogni tick:
Se uno qualsiasi dei passi supera il timeout del watchdog, l'anello applica il fallback di sicurezza configurato e conta la mancanza. Mancanze ripetute innescano una transizione di stato; mancanze prolungate possono passare il binding a un failover worker se ne hai configurato uno.
| Trasporto | Stato | Fascia di licenza | Uso tipico |
|---|---|---|---|
| WebSocket | GA | Standard+ | Latenza sotto il tick, anelli a 50–100 Hz |
| Modbus TCP | GA | Standard+ | Apparecchiature industriali legacy, drive, sensori |
| OPC-UA | Anteprima | Pro+ | Parchi PLC, ambienti industriali multi-vendor |
| MQTT (Sparkplug B), publish | GA | Pro+ | Spinta delle azioni di policy verso la flotta di attuatori |
| MQTT (Sparkplug B), subscribe | Anteprima | Pro+ | Recupero delle osservazioni dalla flotta di sensori |
| File tail (test) | GA | Standard+ | Banco di test deterministico, anelli di sviluppo |
WebSocket, Modbus, MQTT-publish e i trasporti file-tail deterministici sono GA nella 5.0. OPC-UA è in anteprima fino alla 5.0 RC1 — il sorgente C++ è già nella release, la libreria open62541 viene integrata nel RPM del cluster al prossimo build. MQTT-subscribe (recuperare osservazioni da una flotta di sensori Sparkplug-B attraverso il policy worker) resta in anteprima per la linea 5.0; il subscriber in background per-binding + ring buffer arriva con prossime patch 5.0.x. Vedi problemi noti per lo stato corrente delle anteprime.
Quando l'anello di controllo gira più veloce di quanto consenta comodamente la latenza di round-trip HTTP, il trasporto WebSocket mantiene aperta una connessione persistente verso il policy worker. L'IoT worker invia in stream le osservazioni; il policy worker risponde in stream con le azioni. Nessun setup di connessione per tick; la latenza scende al solo round-trip di rete più il tempo di inferenza.
Quando usarlo: anelli di controllo a 50–100 Hz, carichi sensibili al jitter, ogni scenario in cui il sovraccarico di setup per richiesta eroderebbe il tuo budget di tempo.
Modalità di guasto: se il WebSocket cade, l'IoT worker porta subito il binding in stato degradato. Il fallback di sicurezza si attiva mentre in background gira un tentativo di riconnessione.
Modbus su TCP è il protocollo di servizio per drive, sensori e PLC industriali più datati. Il trasporto Modbus legge i registri di osservazione, li invia al policy worker e scrive l'azione validata sugli indirizzi Modbus configurati. GA nella 5.0.
Quando usarlo: integrazione con drive motore, VFD, contatori di energia, impianti di trattamento acque, ogni scenario in cui Modbus è già il protocollo operativo. Si abbina naturalmente al WebSocket lato policy e a Modbus lato attuatore, quando i requisiti di latenza sono stringenti sulla chiamata al modello ma l'attuatore va a bene con i tempi di polling Modbus.
Modalità di guasto: la perdita di connessione viene intercettata dal watchdog; il fallback di sicurezza si attiva e il binding passa allo stato di failover se configurato.
Il trasporto OPC-UA collega l'anello di controllo a un PLC tramite il protocollo OPC-UA. Iscriviti a un insieme di valori di tag OPC-UA; l'IoT worker li assembla nell'osservazione; il policy worker restituisce l'azione; l'IoT worker riscrive i valori di azione nei tag OPC-UA di scrittura configurati. Fascia Pro+. Anteprima fino alla 5.0 RC1 — il sorgente C++ è nella release; la libreria open62541 viene integrata nel RPM del cluster al prossimo build, portando il trasporto in GA.
Quando usarlo: infrastruttura PLC esistente, parchi industriali multi-vendor, ogni scenario in cui OPC-UA è il punto di integrazione di fatto. La piattaforma parla OPC-UA direttamente senza adattatori specifici per vendor.
Modalità di guasto: la sessione OPC-UA è monitorata dallo stesso watchdog. La perdita di connessione al PLC innesca il fallback di sicurezza e la riconnessione.
Il trasporto MQTT, configurato per il namespacing Sparkplug B, distribuisce osservazioni e azioni verso una flotta di sensori / attuatori attraverso un broker MQTT. Due metà con stato diverso in GA: publish (azioni verso i topic degli attuatori) è GA — l'IoT worker spinge gli output di policy validati nella tua flotta Sparkplug-B tramite un percorso di publish per attuatore. Subscribe (osservazioni dai topic dei sensori) resta in anteprima — recuperare le osservazioni attraverso il policy worker richiede un subscriber in background per-binding + ring buffer che arriva nella linea di patch 5.0. Fascia Pro+ su entrambe le metà.
Quando usarlo: flotte di sensori distribuite in cui gli attuatori non sono colocati con il policy worker, ambienti IoT che già usano MQTT-Sparkplug-B per la telemetria, deployment in cui il policy worker guida molti anelli di controllo indipendenti tramite un unico broker.
Modalità di guasto: la consegna MQTT lato attuatore è at-most-once per configurazione (i comandi di controllo non devono essere ripetuti); il watchdog rileva backpressure sui publish o disconnessione del broker e attiva il fallback di sicurezza.
Il watchdog è la linea di difesa tra un policy worker in difficoltà e i tuoi attuatori. Il watchdog impone un budget di latenza per tick — se un tick lo supera, l'IoT worker scarta l'azione in ritardo e applica un fallback configurato. Tre modalità di fallback:
Scrivi zero (o lo zero configurato dell'attuatore) su ogni uscita. Default sicuro per attuatori in cui "nessun comando" è uno stato quiescente — giunti robotici, coppia motore, velocità pompa.
Riscrivi l'ultima azione validata. Continua quello che l'attuatore stava facendo. Utile dove l'azione più recente era nota come sicura e uno stop improvviso sarebbe peggio del continuare — es. far rallentare un robot in movimento invece di una frenata d'emergenza.
Mantieni l'ultima azione che ha superato tutti i controlli di sicurezza (clamp, limiti, NaN). Più forte del freeze perché salta l'azione più recente se si stava avvicinando a un limite di sicurezza.
La macchina a stati: un singolo tick mancato mette il binding in stato degradato; mancanze prolungate oltre una soglia configurabile innescano il failover verso un policy worker di backup (se ne hai configurato uno) o fermano del tutto il binding (se non l'hai fatto). La scelta della configurazione è tua per binding.
Per gli anelli di controllo che non possono fermarsi, l'admin configura una strategia di failover sul binding:
Per il contesto robotico / industriale più ampio, leggi robotica e smart manufacturing. Per la copertura completa di protocolli dell'IoT worker, vedi il catalogo funzionalità § 10. Per domande specifiche sul deployment: office@eldric.ai.