Edge o cloud? In ambito industriale è la domanda sbagliata

Nei progetti di digitalizzazione industriale ricorre regolarmente la stessa domanda: edge o cloud?

Come se si dovesse scegliere tra due visioni del mondo che si escludono a vicenda. Da una parte l’elaborazione in loco, dall’altra il cloud. L’una è veloce e indipendente, l’altro scalabile e gestibile centralmente.

In realtà, un sistema industriale ben funzionante utilizza quasi sempre entrambi. Non per seguire le mode tecnologiche, ma in base a dove un dato o una decisione possono essere gestiti nel modo più sicuro, rapido ed economico.

Che cosa significa davvero edge?

L’edge non è necessariamente un server speciale accanto alla linea di produzione. Ne può far parte qualsiasi capacità di calcolo e decisionale che operi vicino al punto in cui i dati vengono generati.

Può essere:

• un sensore intelligente;
• un PLC;
• un gateway IoT industriale;
• un computer locale;
• un server di stabilimento;
• un servizio di elaborazione dati eseguito in un container.

Il compito dell’edge non è semplicemente «inviare meno dati al cloud». Può gestire localmente le funzioni per cui contano la bassa latenza, l’indipendenza dalla rete, la protezione dei dati o la sicurezza operativa.

Ciò che non va affidato alla connessione remota

Se una decisione deve essere presa in millisecondi o secondi, il percorso di andata e ritorno in rete può essere rischioso. Lo stesso vale quando il processo deve funzionare anche senza connessione a Internet.

Di norma restano in locale:

• il controllo diretto di macchine e processi;
• le funzioni di sicurezza funzionale (safety);
• l’intervento di protezione immediato;
• la pre-elaborazione dei dati ad alta frequenza di campionamento;
• il buffering dei dati;
• le funzioni operative locali di base;
• l’adattamento dei protocolli di comunicazione.

Se, ad esempio, un sensore di vibrazioni produce diverse migliaia di campioni al secondo, non conviene necessariamente inviare in continuo ogni valore grezzo a un sistema centrale. L’elaborazione locale può calcolare grandezze caratteristiche, rilevare il superamento di soglie e trasmettere solo la sintesi rilevante o la porzione di campioni attorno a un evento.

Dove l’elaborazione centrale o in cloud è più forte

L’ambiente centrale è vantaggioso quando occorre collegare dati provenienti da più siti, da lunghi periodi o da più sistemi aziendali.

Qui conviene gestire, ad esempio:

• il confronto tra siti;
• l’analisi storica;
• il monitoraggio dei dispositivi a livello di flotta;
• la reportistica aziendale;
• la gestione centralizzata delle autorizzazioni;
• l’addestramento dei modelli;
• i processi di manutenzione e di business;
• la gestione delle versioni e delle configurazioni.

Il vantaggio del cloud non è soltanto che «il server si trova altrove». Può offrire capacità flessibile, accessibilità centralizzata, una gestione operativa uniforme e l’elaborazione congiunta di dati provenienti da più fonti.

Cinque criteri decisionali reali

La ripartizione dei compiti tra edge e cloud va definita in base ad almeno cinque criteri.

1. Latenza

Entro quanto tempo occorre reagire? Un intervento di protezione della macchina e un report energetico mensile non appartengono ovviamente alla stessa categoria.

2. Affidabilità della connessione

Che cosa succede se la connessione WAN o mobile si interrompe? Il processo locale deve continuare a funzionare in sicurezza e i dati, se necessario, vanno memorizzati in un buffer e sincronizzati in seguito.

3. Volume dei dati

Trasmettiamo serie di dati grezzi o grandezze già elaborate? Larghezza di banda, costi di archiviazione e obiettivo dell’analisi determinano insieme la risposta giusta.

4. Sicurezza e gestione dei dati

Quali dati possono lasciare il sito? In quale direzione sono consentite le connessioni? Dove avvengono autenticazione, cifratura e registrazione degli eventi?

5. Ciclo di vita e gestione operativa

Chi aggiorna il componente locale? Come si gestisce la configurazione di cento siti? Come si torna indietro da una versione difettosa? Un dispositivo edge non può diventare una scatola nera dimenticata.

Il funzionamento offline non è un’eccezione, ma uno stato di progetto

In una soluzione industriale l’interruzione della rete va progettata non come un incidente straordinario, ma come uno stato del sistema gestito in anticipo.

Occorre stabilire:

• quanti dati possono essere memorizzati localmente;
• in quale ordine avviene il recupero dei dati;
• come si gestiscono i duplicati;
• che cosa succede in caso di comandi contrastanti;
• quali funzioni restano disponibili;
• quando e a chi il sistema invia segnalazioni.

L’approccio di OrigSmart a gateway e piattaforma gestisce questa continuità. Collegamento di campo, logica locale, inoltro dei messaggi, elaborazione centrale dei dati e processi aziendali non sono progetti separati, ma parti di un unico sistema progettato end-to-end.

In un sistema bidirezionale il confine conta ancora di più

La semplice telemetria invia dati solo verso l’alto. Una vera piattaforma operativa, invece, può anche agire sul funzionamento fisico: modifica un setpoint, regola un inverter, pianifica i consumi, conferma un allarme o avvia un processo locale.

In questi casi occorre separare chiaramente:

• la raccomandazione dal comando eseguibile;
• l’ottimizzazione centrale dal limite di sicurezza locale;
• l’autorizzazione dell’utente dall’abilitazione lato dispositivo;
• il funzionamento normale dalla modalità di riserva sicura (fallback).

Il sistema centrale può indicare che ridurre un carico sarebbe economicamente vantaggioso. Il controllo locale, però, deve impedire qualsiasi intervento che violi un limite tecnologico o di sicurezza.

Fonti

• Commissione europea – La politica europea per l’Internet delle cose
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – Sistema operativo aziendale basato sul web