In breve: cosa tenere a mente da questo confronto​

Prima di entrare nei dettagli, ecco le conclusioni principali per i decisori che hanno poco tempo a disposizione:

• Copertura: i quattro operatori (Orange, SFR, Bouygues, Free) coprono ormai il 99% della popolazione con il 4G grazie al New Deal Mobile del 2018. La differenza si nota nelle zone rurali e in termini di estensione del territorio, dove Orange mantiene un leggero vantaggio.
• Prezzi: Bouygues e SFR sono generalmente i più competitivi sui volumi; Orange applica un sovrapprezzo per la copertura.
• Resilienza: nessuna SIM mono-operatore copre il 100% di un parco multi-sito. La SIM multi-operatore (multi-IMSI / eUICC) passa automaticamente alla rete migliore ed elimina le zone senza copertura di un singolo operatore.
• Urgenza 2026-2028: il 2G verrà disattivato (Orange chiuderà la propria rete tra il 22 settembre e il 20 ottobre 2026) e il 3G seguirà intorno al 2028. Qualsiasi nuova implementazione deve essere almeno LTE-M / NB-IoT / 4G, pena una rapida obsolescenza.
• Sicurezza: per i settori critici (NIS2), l’APN privato + VPN non è più un’opzione, ma un requisito imprescindibile.

Che cos'è una SIM M2M e in cosa differisce da una SIM per il grande pubblico?​

Una SIM M2M (Machine-to-Machine), oggi più comunemente denominata SIM IoT, è una scheda SIM progettata specificamente per le apparecchiature industriali e connesse. Si distingue da una SIM per smartphone sotto quasi tutti gli aspetti:

Formato SIM industriale: i gateway e i router IoT integrano solitamente uno slot SIM nel formato 2FF (mini-SIM, 25×15 mm) o 3FF (micro-SIM), oppure una eSIM saldata (MFF2) per ambienti soggetti a forti vibrazioni. È fondamentale verificarlo prima di effettuare qualsiasi ordine: un formato errato blocca l’intera implementazione.

Da ricordare: una SIM M2M non è solo un «abbonamento economico». È un componente industriale progettato per durare quanto la macchina che la ospita.

Copertura di rete mobile in Francia nel 2026: cosa dicono i dati dell'ARCEP​

La copertura è il criterio principale per una SIM M2M. Ecco lo stato effettivo della rete, basato sui dati ARCEP del quarto trimestre del 2025 (pubblicati nel marzo 2026), piuttosto che sulle argomentazioni commerciali degli operatori.

4G: la copertura supera il 99% della popolazione​

Grazie agli obblighi vincolanti previsti dal New Deal Mobile del 2018, i quattro operatori coprono oggi oltre il 99% della popolazione francese con la rete 4G. La sfida non si gioca quindi più sulla popolazione, ma su:

• La copertura territoriale (zone rurali, montagna, assi secondari), dove Orange mantiene un vantaggio.
• La copertura indoor / qualità del segnale, ora classificata dall’ARCEP su tre livelli: ottima, buona, limitata.
• Le zone bianche residue, trattate dal dispositivo di copertura mirata (diverse migliaia di ripetitori condivisi).

Condivisione delle risorse: l'accordo «Crozon» tra SFR e Bouygues​

Un aspetto importante per la resilienza di un parco: SFR e Bouygues Telecom condividono una parte della loro rete nelle zone meno densamente popolate (accordo di condivisione noto come «Crozon»). In pratica, in queste zone, scegliere SFR o Bouygues può equivalere a connettersi alla stessa antenna fisica — il che riduce l’utilità di un failover tra questi due operatori e rafforza l’interesse di un passaggio che includa Orange (rete indipendente). Free, dal canto suo, beneficia del roaming sulla rete Orange nelle zone che non copre ancora.

Bande di frequenza chiave per l'IoT​

Per un sensore installato nel sottosuolo o in zona rurale, sono le bande basse (700/800 MHz) a fare la differenza — non il 5G urbano pubblicizzato.

⚠️ Fine del 2G e del 3G: la scadenza che rende obsoleti i parchi​

È l'aspetto più sottovalutato di un'implementazione IoT nel 2026 e merita una sezione a sé stante.

• 2G: Orange disattiverà la propria rete 2G tra il 22 settembre e il 20 ottobre 2026. Gli altri operatori seguono un calendario simile. L’ARCEP prevede addirittura di abolire l’obbligo di mappare la rete 2G, segno che la tecnologia sta giungendo al termine del suo ciclo di vita.
• 3G: spegnimento previsto verso il 2028.

Conseguenza diretta: qualsiasi modem o modulo IoT solo 2G (ancora molto diffuso sui vecchi contatori e allarmi) smetterà di funzionare a partire dall'autunno del 2026. Un modulo 2G/3G senza supporto 4G smetterà di funzionare intorno al 2028.

Cosa fare?

• Per qualsiasi nuova implementazione: richiedere moduli 4G (LTE Cat-1 / Cat-1 bis) o IoT a basso consumo LTE-M / NB-IoT, che continueranno a essere supportati ben oltre il 2030.
• Per un parco esistente in 2G/3G: pianificare la sostituzione dell’hardware prima della scadenza. Una SIM compatibile con LTE-M/NB-IoT non è sufficiente se il modem non lo è.
• Privilegiare le SIM per le quali l’operatore garantisce esplicitamente il supporto LTE-M e NB-IoT nel lungo periodo.

Consiglio di Eziwan: i gateway e la SIM Eziwan sono 4G/LTE-M con funzione di fallback, progettati per superare tali interruzioni senza necessità di intervento in loco.

Gli operatori M2M in Francia: panorama 2026​

Orange Business (Flux M2M / Orange IoT)​

Orange è l'operatore storico con la copertura più estesa, in particolare nelle zone rurali e nei territori d'oltremare.

Offerte M2M:

• Flux M2M Lite: solo dati, piani da 1 MB a 2 GB al mese
• Flux M2M Pro: dati + SMS + voce, APN privato disponibile
• Orange IoT Suite: gestione della flotta SIM + connettività + API

Punti di forza:

• Copertura 4G più estesa, con un vantaggio nelle zone rurali e in termini di superficie
• Rete LTE-M implementata a livello nazionale per l’IoT a basso consumo
• Copertura DOM/COM (Réunion, Martinica, Guadalupa, Antille, ecc.)
• SLA aziendale con disponibilità fino al 99,9%
• Membro della GSMA per i profili eSIM industriali
• Rete indipendente (non condivisa): ideale come «secondo operatore» in caso di migrazione

Punti deboli:

• Tariffe premium: spesso dal 20% al 40% in più rispetto a SFR e Bouygues
• Contratto M2M spesso della durata di 24-36 mesi
• Quantità minima d'ordine talvolta elevata (≈100 SIM)

Tariffe indicative (solo dati, escluse le opzioni):

SFR Business (SFR IoT)​

SFR propone offerte M2M competitive, con un buon rapporto qualità/prezzo per le implementazioni su larga scala e un sistema di pooling molto apprezzato.

Offerte M2M:

• SFR IoT Connect: connettività dati M2M
• SFR IoT Platform: gestione della flotta + API + avvisi
• Offerte condivise (pooling): un volume complessivo condiviso tra tutte le SIM del contratto

Punti di forza:

• Tariffe competitive (spesso dal −15 al −25% rispetto a Orange su volumi medi)
• Pooling: ideale quando il consumo varia da una SIM all’altra
• Copertura 4G paragonabile a quella di Orange, 5G urbano performante
• API di gestione della flotta ben documentata

Punti deboli:

• Copertura leggermente inferiore a quella di Orange nelle zone molto rurali
• Rete condivisa con Bouygues («Crozon») nelle zone a bassa densità: il failover SFR↔Bouygues è poco efficace in queste zone
• Assistenza M2M talvolta meno reattiva rispetto al segmento Enterprise

Tariffe indicative:

Bouygues Telecom Entreprises (IoT)​

Bouygues ha notevolmente migliorato la propria copertura e offre spesso le tariffe più basse del mercato per i grandi volumi.

Offerte M2M:

• Bouygues Telecom IoT: SIM dati, SMS, voce
• FleetMap: strumento di gestione della flotta SIM
• Partnership con integratori per le principali piattaforme IoT

Punti di forza:

• Prezzi molto competitivi, spesso i più bassi per grandi volumi
• Copertura 4G completa, condivisione della rete «Crozon» con SFR nelle zone a bassa densità
• Offerte con sconti progressivi a partire da circa 50 SIM
• Buon livello di servizio per PMI/ETI

Punti deboli:

• Presenza più limitata nei DOM/COM
• Rete condivisa con SFR nelle zone a bassa densità (stessa riserva riguardo al failover)

Tariffe indicative:

Objenious / LoRaWAN (Bouygues)​

Per le applicazioni a basso consumo e a bassa velocità di trasmissione (telelettura di contatori di acqua/gas, geolocalizzazione di beni, sensori ambientali), il LoRaWAN rappresenta un'alternativa alla rete cellulare:

• Rete LoRaWAN nazionale che copre la maggior parte della popolazione
• Consumo energetico estremamente basso: diversi anni con una sola batteria
• Limite: non adatto alla trasmissione video, a velocità elevate o ad aggiornamenti OTA frequenti

Nota: l'ecosistema LoRaWAN è in continua evoluzione (acquisizioni, riposizionamenti degli operatori). Verificate la sostenibilità della rete e dell'offerta commerciale prima di assumervi un impegno a lungo termine.

MVNO e operatori specializzati nell'IoT​

1NCE — la SIM «a vita» con costo una tantum​

1NCE propone un modello rivoluzionario: un pagamento unico di circa 10 $/12 € per 500 MB di dati + 250 SMS validi per 10 anni, sulla rete di Deutsche Telekom e dei suoi partner (tra cui Orange in Francia), con copertura in oltre 170 paesi. La SIM supporta 2G, 3G, 4G/LTE-M, NB-IoT ed è dichiarata «5G-ready».

Per:

• Implementazioni a bassissimo consumo (sensori, telelettura, tracciamento delle risorse)
• Costi operativi (OPEX) pressoché nulli dopo l'acquisto; costi prevedibili su 10 anni
• Tunnel OpenVPN incluso, portale e API di gestione
• Disponibili versioni Industrial (rinforzata) e eSIM/eUICC (con un leggero sovrapprezzo)

Contro:

• Limite massimo di 500 MB per tutta la durata del contratto: insufficiente per i video o gli aggiornamenti OTA frequenti (ricaricabile a ~12 € per 500 MB)
• Velocità limitata (fino a 1 Mbit/s)
• Nessuna APN privata dedicata come presso gli operatori aziendali
• Assistenza prevalentemente scritta, salvo per l’offerta premium

1NCE è eccellente per oggetti semplici e essenziali. Per la supervisione industriale, l'accesso remoto VPN regolare o la videosorveglianza, è necessaria un'offerta di un operatore o multi-operatore.

Tele2 IoT / Telenor Connexion​

Operatori europei specializzati nell'IoT, con offerte multinazionali interessanti per le implementazioni internazionali e una gestione della flotta ben consolidata.

Arkessa / ZARIOT / Transatel / Onomondo​

Soluzioni eUICC / multi-IMSI che consentono di passare da un operatore all'altro in base alla copertura, con un core di rete unificato — particolarmente adatte alle implementazioni in più paesi e per evitare il vincolo all'operatore (vendor lock-in).

La SIM multi-operatore: la soluzione per i settori critici​

La SIM multi-operatore (multi-IMSI / eUICC) è una scheda in grado di connettersi automaticamente all'operatore che offre il segnale migliore in ogni luogo e di passare automaticamente a un'altra rete in caso di interruzione del servizio.

Come funziona​

Vantaggi della SIM multi-operatore​

Casi d'uso ideali: stazioni di pompaggio, parchi eolici e solari, siti agricoli, telelettura multisito, veicoli in movimento, implementazioni in più paesi e qualsiasi sito in cui verificare la copertura di ciascun operatore prima dell'installazione risulterebbe troppo costoso.

Promemoria «Crozon»: per garantire una vera ridondanza, il passaggio deve includere Orange (rete indipendente) e non solo SFR e Bouygues, che condividono la loro rete nelle zone a bassa densità.

La SIM Eziwan​

La SIM Eziwan è una SIM M2M multi-operatore integrata nelle nostre offerte:

• Passaggio automatico tra Orange / SFR / Bouygues in base alla migliore copertura
• APN privato protetto (traffico crittografato tra gateway e cloud Eziwan, data center in Francia)
• Dashboard di monitoraggio: RSRP, RSRQ, consumo dati in tempo reale
• Fatturazione unificata: un unico contratto per l’intera flotta
• Senza impegno di volume minimo: ordinate da 1 a 1000 SIM
• Compatibile con LTE-M e 4G: progettato per superare la fine del 2G/3G senza interruzioni

Fotocamera digitale professionale: perché è fondamentale nel settore industriale​

L'APN privato (Access Point Name) crea una rete virtuale dedicata tra le vostre SIM e la vostra infrastruttura cloud, senza passare attraverso la rete Internet pubblica.

Vantaggi dell'APN privato:

• Il traffico non viene mai esposto su Internet pubblico (superficie di attacco ridotta)
• Possibilità di indirizzamento IP fisso (stesso IP per ogni SIM, semplifica l'accesso remoto)
• Isolamento di rete completo rispetto agli altri clienti dell'operatore
• Elemento fondamentale per la conformità NIS2 delle entità essenziali e importanti

APN pubblico vs APN privato:

Disponibilità: Orange, SFR e Bouygues offrono tutti un APN privato; la SIM Eziwan lo include di serie.

Consumo tipico di dati per caso d'uso​

Calcolare la quota forfettaria in modo accurato evita di pagare più del dovuto (o di rimanere senza scorte). Ordini di grandezza osservati:

Ottimizzazione tramite edge computing: un gateway che filtra i dati a livello locale (banda morta, aggregazione, compressione) prima della trasmissione riduce il consumo 4G dal 70 al 95%. Un sito M340 con 30 variabili può passare da ~150 MB/mese a 15-25 MB/mese — il che, su 500 siti, equivale al passaggio da un piano tariffario da «200 MB» a uno da «50 MB» e a un risparmio sostanziale a livello dell’intero parco.

Roaming internazionale: aspetti da tenere in considerazione​

Per le apparecchiature installate al di fuori della Francia:

Unione europea: attenzione, le offerte M2M non beneficiano automaticamente del “Roam Like Home”, riservato ai piani tariffari per il pubblico generale. Il roaming M2M è soggetto a condizioni contrattuali specifiche: verificate sempre le clausole M2M del vostro operatore (traffico, durata consentita del roaming permanente, restrizioni relative al «roaming permanente»).

Al di fuori dell'UE: il costo al MB può essere molto elevato (nell'ordine di +0,5 a 2 €/MB). Per un'implementazione internazionale, è preferibile optare per una SIM locale o una SIM globale multi-IMSI (Eziwan, Tele2 IoT, Onomondo) che negozia l'accesso alle reti paese per paese.

Roaming permanente: alcuni paesi (e alcuni operatori ospitanti) limitano o vietano il roaming permanente degli oggetti fissi. Un'implementazione duratura all'estero deve basarsi su un'offerta multi-IMSI o su una SIM locale, non sul roaming «tollerato».

Tabella comparativa sintetica​

★ = valutazione indicativa di Eziwan, da valutare in base alla vostra zona geografica e ai vostri volumi.

Come scegliere: albero decisionale rapido​

• Sensori semplici, consumo energetico molto basso, budget fisso per 10 anni → 1NCE o offerta LTE-M dell’operatore.
• Parco nazionale con più siti, zone rurali, elevata criticità → SIM multi-operatore (Eziwan) con APN privato.
• Grandi volumi urbani, ottimizzazione dei costi → Bouygues o SFR (pooling).
• Territori d'oltremare, esigenza di copertura massima → Orange.
• Implementazione internazionale / multipaese → SIM multi-IMSI globale (Eziwan, Tele2 IoT, Onomondo).
• Video / accesso remoto frequente → piano dati generoso di un operatore o multi-operatore, soprattutto non una SIM «a vita» con limite di traffico.

In ogni caso: moduli 4G/LTE-M come minimo (mai solo 2G/3G) e APN privato non appena i dati sono sensibili.

Domande frequenti — SIM M2M per l'IoT industriale​

Posso utilizzare una SIM per il mercato consumer in un gateway IoT? Tecnicamente sì, ma non è consigliabile. Le SIM per il mercato consumer supportano un intervallo di temperatura limitato (0-40 °C), hanno una durata di vita più breve e non offrono né APN privato, né monitoraggio della flotta, né SLA industriale. In un parco dispositivi installato sul campo, il costo aggiuntivo di una SIM M2M è ampiamente compensato dall’affidabilità e dalla gestione centralizzata.

I miei dispositivi 2G o 3G continueranno a funzionare? No, a lungo termine. Orange disattiverà la propria rete 2G tra il 22 settembre e il 20 ottobre 2026, gli altri operatori seguiranno l’esempio e la rete 3G verrà disattivata intorno al 2028. Qualsiasi modulo esclusivamente 2G sarà fuori servizio a partire dall’autunno 2026; un modulo 2G/3G senza supporto 4G lo sarà intorno al 2028. Per qualsiasi nuovo progetto, richiedete apparecchiature 4G / LTE-M / NB-IoT.

Qual è il consumo minimo di una SIM M2M in modalità standby? In assenza di traffico di servizio, una SIM M2M consuma solo i segnali di mantenimento della connessione (keep-alive, heartbeat): a seconda dell'operatore e della configurazione, 1-10 MB al mese. Con un APN privato e un tunnel VPN (OpenVPN/IPSec) mantenuto costantemente attivo, si va piuttosto sui 5-15 MB al mese di keep-alive, esclusi i dati applicativi.

È possibile cambiare operatore senza dover riconfigurare tutto? Con una SIM eUICC (eSIM), sì: il profilo dell’operatore viene riconfigurato da remoto, senza bisogno di interventi in loco. Con una SIM fisica tradizionale monoperatore, è necessario sostituire fisicamente la scheda. La SIM multi-operatore Eziwan risolve il problema: un’unica SIM gestisce automaticamente le tre reti francesi.

Qual è la differenza tra LTE-M e NB-IoT? LTE-M offre una velocità di trasmissione più elevata, una bassa latenza e supporta la mobilità (oggetti in movimento, possibilità di trasmissione vocale) — adatto al tracciamento delle risorse e alla telemetria reattiva. NB-IoT è destinato a oggetti statici a bassissimo consumo (contatori nei sotterranei), con un’ottima copertura ma una velocità di trasmissione e una latenza inferiori. Entrambe le tecnologie sopravviveranno alla fine delle reti 2G/3G.

Le SIM M2M sono conformi alla normativa francese? Sì. Le offerte M2M degli operatori francesi sono regolamentate dall'ARCEP. Le SIM IoT dati non richiedono l'identificazione dell'utente finale (non è necessario un documento d'identità), tranne che per le offerte che includono chiamate vocali o SMS in uscita verso numeri di telefonia mobile.

Come gestire 500 SIM distribuite su 500 siti? Tramite un portale di gestione della flotta: consumo dati in tempo reale per ogni SIM, individuazione delle SIM inattive o con consumo eccessivo, attivazione/disattivazione da remoto, visualizzazione del segnale (RSRP/RSRQ), avvisi in base alle soglie. Il portale Eziwan integra questa gestione nella stessa dashboard in cui avviene il monitoraggio delle vostre apparecchiature, evitando di dover passare da un’interfaccia all’altra.

Una SIM multi-operatore costa molto di più? In generale, dal 10% al 20% in più rispetto a una SIM monoperatore equivalente. In un sito critico, questo sovrapprezzo è marginale rispetto al costo di un'interruzione del servizio o di un intervento tecnico dovuto a una zona senza copertura non prevista.

Per una consulenza personalizzata in base al vostro parco e alle vostre aree geografiche, contattate il nostro team — effettuiamo un'analisi gratuita della copertura presso le vostre sedi, operatore per operatore.

Per approfondire​

• Blog: failover LTE dual SIM — garantire la connettività critica
• Blog: monitoraggio RSRP/RSRQ 4G industriale — interpretare le metriche LTE
• Blog: router 4G LTE industriale — migrare dall'ADSL prima della fine del rame
• Blog: rete privata 5G — casi d’uso e ROI per lo stabilimento
• Blog: confronto tra operatori industriali dual SIM

Risorse aggiuntive​

• Connettività industriale — soluzioni di connettività 4G LTE e M2M per l'industria
• Connettività Eziwan — offerte SIM M2M e connettività gestita per l'IoT industriale
• Connessione Internet per siti industriali isolati — connettere un sito privo di infrastrutture fisse tramite 4G/LTE
• Soluzioni industriali Eziwan — gamma completa di soluzioni di monitoraggio e connettività industriale
• Gateway IoT industriale — gateway IoT multi-operatore con gestione SIM integrata

Perché scegliere Grafana per il monitoraggio industriale?​

Grafana si è affermato nel settore per diversi motivi:

• Connettori universali: InfluxDB, TimescaleDB, PostgreSQL, Prometheus, MQTT, REST API — una fonte di dati per ogni stack
• Pannelli avanzati: serie temporali, indicatori, statistiche, tabelle, mappe di calore, diagrammi di flusso (con plugin)
• Avvisi integrati: notifiche via SMS, e-mail, Slack, PagerDuty, webhook
• Gestione degli accessi: team, cartelle, autorizzazioni per dashboard
• Plugin di settore: P&ID (diagrammi di flusso), schemi di tubazioni, schemi sinottici

Rispetto a un sistema SCADA tradizionale:

Architettura: da Modbus a Grafana​

Lo stack completo per monitorare i controllori Modbus in Grafana:

Alternativa per grandi volumi:

Soluzione Eziwan (tutto in uno):

Eziwan integra lo stack completo (raccolta dati Modbus/OPC-UA, serie temporali nel cloud, dashboard Grafana preconfigurate, avvisi via SMS/e-mail) senza che sia necessario installare e gestire i singoli componenti.

Installare Grafana + InfluxDB con Docker​

# docker-compose.yml
version: '3.8'

services:
  influxdb:
    image: influxdb:2.7
    ports:
      - "8086:8086"
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: mot_de_passe_securise
      DOCKER_INFLUXDB_INIT_ORG: eziwan
      DOCKER_INFLUXDB_INIT_BUCKET: industrie
      DOCKER_INFLUXDB_INIT_RETENTION: 1825d  # 5 ans
    volumes:
      - influxdb_data:/var/lib/influxdb2

  grafana:
    image: grafana/grafana:10.4.0
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: grafana_securise
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - influxdb

  telegraf:
    image: telegraf:1.29
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
    depends_on:
      - influxdb

volumes:
  influxdb_data:
  grafana_data:

Configurazione di Telegraf per MQTT​

# telegraf.conf
[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = ["usine/#"]
  qos = 1
  data_format = "json"
  
  # Analisi sintattica del topic MQTT: fabbrica/sito/stazione/variabile
  [[inputs.mqtt_consumer.topic_parsing]]
    topic = "usine/+/+/+"
    tags = "_/_/station/_"
    fields = "_/_/_/value"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  token = "votre_token_influxdb"
  organization = "eziwan"
  bucket = "industrie"

Creare il proprio primo dashboard industriale​

Pannello 1: Grafico di tendenza (serie temporale)​

Per visualizzare l'andamento della pressione di una stazione nel tempo:

Query InfluxDB (Flux):

from(bucket: "industrie")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "mqtt_consumer")
  |> filter(fn: (r) => r["station"] == "station1")
  |> filter(fn: (r) => r["_field"] == "pression")
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")

Pannello delle impostazioni:

• Tipo: Time series
• Unità asse Y: bar (Pressione)
• Spessore linea: 2
• Opacità riempimento: 10
• Soglie: verde < 8 bar, arancione 8-10 bar, rosso > 10 bar

Pannello 2: Indicatore (Valore istantaneo)​

Per visualizzare il valore corrente di una variabile:

Query InfluxDB:

from(bucket: "industrie")
  |> range(start: -1m)
  |> filter(fn: (r) => r["station"] == "station1" and r["_field"] == "pression")
  |> last()

Impostazioni del pannello:

• Tipo: Gauge
• Min: 0, Max: 16
• Unità: bar
• Soglie: 0=verde, 10=arancione, 12=rosso

Panel 3: Statistiche (KPI)​

Per visualizzare il TRS o un contatore di produzione:

Query InfluxDB:

from(bucket: "industrie")
  |> range(start: -24h)
  |> filter(fn: (r) => r["_field"] == "pieces_produites")
  |> sum()

Parametri pannello:

• Tipo: Stat
• Unità: pcs (personalizzata)
• Modalità colore: Background (rosso se < obiettivo)

Panel 4: Tabella multisito​

Per visualizzare lo stato di tutti i tuoi siti in tempo reale:

from(bucket: "industrie")
  |> range(start: -5m)
  |> filter(fn: (r) => r["_field"] == "pression" or r["_field"] == "debit" or r["_field"] == "etat")
  |> last()
  |> pivot(rowKey: ["_time", "station"], columnKey: ["_field"], valueColumn: "_value")

Risultato: tabella con le colonne Stazione / Pressione / Portata / Stato, una riga per ogni sito.

Configurare gli avvisi di Grafana​

Avviso di superamento della soglia​

In Grafana 10+ (Unified Alerting):

1. Aprire il pannello → Edit → Alert
2. Creare una regola:

   Condition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
   

3. Configurare la notifica:
   • Punto di contatto: Email → maintenance@usine.fr
   • Punto di contatto: Webhook → SMS tramite Twilio/OVH SMS
4. Silenziamento automatico: 15 minuti dopo la conferma

Raggruppamento degli avvisi per siti multipli​

Per evitare le "alert storms" quando più siti smettono di funzionare contemporaneamente:

# alertmanager.yml
route:
  group_by: ['alertname', 'site']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'maintenance-team'

receivers:
  - name: 'maintenance-team'
    email_configs:
      - to: 'maintenance@usine.fr'
        send_resolved: true
    webhook_configs:
      - url: 'https://api.sms-provider.fr/send'

Annotazioni sugli eventi​

Aggiungere annotazioni automatiche ai grafici in caso di allarmi:

// Creare un'annotazione InfluxDB in caso di errore
from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["_field"] == "defaut" and r["_value"] == 1)
  |> map(fn: (r) => ({r with _value: "Défaut détecté sur ${r.station}"}))

Modelli e variabili Grafana per siti multipli​

Le variabili dei modelli consentono di creare un dashboard generico riutilizzabile per tutti i tuoi siti.

Creare una variabile "site"​

Dashboard Settings → Variables → New Variable:

• Nome: site
• Tipo: Query
• Origine dati: InfluxDB
• Query:

  import "influxdata/influxdb/schema"
  schema.tagValues(bucket: "industrie", tag: "station")
  

Utilizzo della variabile nei pannelli​

from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["station"] == "${site}")
  |> filter(fn: (r) => r["_field"] == "pression")

L'operatore può ora selezionare il sito da un menu a tendina nella parte superiore della dashboard.

Dashboard Grafana preconfigurate per il settore industriale​

Pannello di controllo della stazione di pompaggio​

┌─────────────────────────────────────────────────────────────────┐
│  Stazione: [menu a tendina]  │  Periodo: [6 ore|24 ore|7 giorni|30 giorni] │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│  Pressione    │   Portata │  Livello │  Stato pompa │
│  [gauge]     │   [gauge]    │  [gauge]     │  [stat 🟢/🔴]      │
├──────────────┴──────────────┴──────────────┴────────────────────┤
│  Andamenti nelle ultime 24 ore: Pressione / Portata / Livello │
│  [time series graph]                                             │
├─────────────────────────────────────────────────────────────────┤
│  Allarmi attivi    │  Ultimi interventi │
│  [table]            │  [table annotations]                       │
└─────────────────────────────────────────────────────────────────┘

Dashboard di produzione multisito​

┌────────────────────────────────────────────────────────────────────┐
│  Vue globale — 15 sites                                            │
├──────────┬──────────┬──────────┬──────────┬──────────┬────────────┤
│ Site 1   │ Site 2   │ Site 3   │ Site 4   │ Site 5   │ ...        │
│ TRS: 87% │ TRS: 91% │ TRS: 73% │ TRS: 94% │ TRS: 82% │            │
│ 🟢 OK    │ 🟢 OK    │ 🔴 Alrm  │ 🟢 OK    │ 🟡 Warn  │            │
├──────────┴──────────┴──────────┴──────────┴──────────┴────────────┤
│  Produzione cumulativa nelle ultime 24 ore: obiettivo vs. dati effettivi [grafico a barre] │
└────────────────────────────────────────────────────────────────────┘

Integrazione Eziwan → Grafana​

Eziwan offre due modalità di integrazione con Grafana:

Modalità 1: Grafana ospitato su Eziwan (consigliato)​

La piattaforma Eziwan integra Grafana in modo nativo. I vostri dati Modbus/OPC-UA sono già presenti nel nostro database di serie temporali ospitato in Francia. Potete accedere direttamente alle dashboard dal vostro browser, con:

• Dashboard preconfigurate per i casi d’uso più comuni (acqua, energia, produzione)
• Avvisi via SMS/e-mail gestiti
• Archiviazione dei dati per 5 anni senza necessità di configurazione
• Gestione multisito, multiutente e dei diritti di accesso

Modalità 2: Esportazione verso il proprio Grafana esistente​

Se disponete già di un Grafana interno:

• API REST Eziwan: interrogate i vostri dati tramite GET /api/v1/variables/{id}/history
• Webhook MQTT: Eziwan pubblica i vostri dati sul vostro broker MQTT esistente
• Plugin Grafana Eziwan (disponibile su richiesta): plugin di origine dati per la connessione diretta

Domande frequenti — Grafana per il monitoraggio industriale​

Grafana può sostituire un sistema SCADA in produzione? Per la visualizzazione e gli avvisi, sì, in molti casi. Per il controllo in tempo reale (scrittura sul PLC, sequenze di comando), si consiglia comunque di utilizzare un sistema SCADA o un sistema HMI dedicato. Grafana eccelle nella registrazione storica dei dati, nell'analisi delle tendenze e nel monitoraggio multisito.

Quale database utilizzare per archiviare i dati industriali in Grafana? InfluxDB è la scelta standard per le serie temporali industriali (alta frequenza, compressione nativa, potenti query Flux). TimescaleDB (estensione di PostgreSQL) è l'ideale se si dispone già di PostgreSQL. Prometheus è adatto alle metriche di infrastruttura, ma meno indicato per i dati di processo.

Come proteggere l'accesso a Grafana da Internet? Posizionare Grafana dietro un reverse proxy (Nginx/Traefik) con TLS, abilitare l'autenticazione OIDC/LDAP, disabilitare l'accesso anonimo, configurare avvisi in caso di tentativi di connessione non riusciti. Non esporre mai InfluxDB direttamente su Internet.

Grafana è in grado di gestire 1.000 siti e 100.000 variabili? Sì, con l'architettura giusta. InfluxDB 2.x supporta miliardi di punti dati. Grafana Enterprise gestisce il clustering. Per volumi molto elevati, prendere in considerazione l’utilizzo di Apache Kafka a monte per lo streaming e l’adozione di politiche di conservazione differenziate (dati con intervallo di 1 secondo conservati per 30 giorni, dati con intervallo di 1 minuto conservati per 5 anni).

È possibile visualizzare uno schema P&ID in Grafana? Sì, con il plugin Flowcharting (basato su draw.io). È sufficiente disegnare lo schema P&ID, associare le variabili di Grafana a ciascuna apparecchiatura e i valori verranno visualizzati in tempo reale sullo schema sinottico con un cambio di colore a seconda dello stato.

Per approfondire​

• Blog: manutenzione predittiva IIoT — dai dati dei sensori all'allerta sul campo
• Blog: supervisione industriale da remoto — guida completa 2026
• Blog: Modbus TCP vs RTU — quale protocollo scegliere?
• Blog: parco fotovoltaico — supervisione e monitoraggio IoT
• Documentazione: configurazione Modbus RTU sul gateway Eziwan

Vuoi creare dashboard Grafana senza dover gestire l'infrastruttura? Prova Eziwan gratuitamente per 30 giorni — i tuoi dati Modbus su Grafana in meno di un'ora.

Risorse aggiuntive​

• Modbus RTU verso il cloud — collega le tue apparecchiature RS-485 Modbus RTU al cloud
• Data logger industriale cloud — archiviazione storica dei tuoi dati Modbus nel cloud
• SCADA cloud — piattaforma SCADA cloud con dashboard integrate
• Protocolli industriali — comprendere Modbus, MQTT, OPC UA e altri protocolli
• Monitoraggio e teleassistenza industriale — monitoraggio multisito delle vostre apparecchiature Modbus

Che cos'è l'OPC-UA e perché è importante?​

OPC-UA (IEC 62541) è un protocollo di comunicazione indipendente dalla piattaforma, progettato per lo scambio sicuro di dati industriali. A differenza del suo predecessore OPC-DA (solo Windows, DCOM), OPC-UA funziona su qualsiasi sistema operativo (Linux, Windows, RTOS embedded) e su qualsiasi rete (Ethernet, 4G, Wi-Fi).

Perché l'OPC-UA domina l'Industria 4.0​

• Interoperabilità: un server Siemens S7-1500 OPC-UA è leggibile senza driver proprietario da qualsiasi client conforme
• Modello informativo: i dati hanno un significato (unità, descrizione, cronologia), non solo un valore
• Sicurezza nativa: crittografia, autenticazione, certificati — integrati nel protocollo
• Profili di conformità: un sottoinsieme snello per le piccole apparecchiature embedded
• Pubsub e MQTT: estensione OPC-UA Pub/Sub per architetture cloud (IEC 62541-14)

Architettura OPC-UA: i concetti fondamentali​

Client-Server​

Il modello di base OPC-UA è client-server:

• Server OPC-UA: messo a disposizione dall'apparecchiatura (PLC, HMI, server dati)
• Client OPC-UA: utilizza i dati (SCADA, gateway, applicazione cloud)

Lo stesso dispositivo può fungere contemporaneamente da server e da client (ad es. un gateway che aggrega diversi PLC e rende disponibili i dati consolidati).

Spazio di indirizzamento e NodeId​

L'Address Space è l'albero di informazioni esposto da un server OPC-UA. Ogni nodo ha un NodeId univoco:

Formato NodeId:

• ns=2;i=1234 — namespace 2, identificatore intero 1234
• ns=2;s=Station_1.Pression — namespace 2, identificatore stringa
• ns=0;i=2258 — namespace 0 (standard), ServerStatus

Spazi dei nomi:

• ns=0: spazio dei nomi standard OPC-UA (tipi, metodi)
• ns=1: spesso lo spazio dei nomi del produttore
• ns=2+: spazi dei nomi applicativi (i vostri dati)

Modalità di comunicazione​

Gli abbonamenti sono l'approccio corretto per il monitoraggio in tempo reale: invece di effettuare un polling ogni secondo, il client si abbona a un nodo e riceve una notifica solo quando il valore supera una soglia configurabile (DeadbandValue).

Sicurezza OPC-UA: la guida completa​

La sicurezza è uno dei punti di forza di OPC-UA — ma anche una delle fonti di complessità. Ecco i concetti fondamentali.

Modalità di sicurezza​

Certificati X.509​

OPC-UA utilizza certificati X.509 per l'autenticazione reciproca client-server:

Creazione di un certificato autofirmato a scopo di test:

# Avec OpenSSL
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout client_key.pem -out client_cert.pem \
  -subj "/CN=EziwanGateway/O=Eziwan/C=FR" \
  -extensions v3_req \
  -config <(cat /etc/ssl/openssl.cnf; echo "[v3_req]"; echo "subjectAltName=URI:urn:eziwan:gateway:client")

In produzione: utilizzare una PKI interna o un'autorità di certificazione riconosciuta. La prima volta, i certificati devono essere scambiati manualmente tra client e server.

Autenticazione utente​

Oltre ai certificati di sistema, OPC-UA gestisce l'autenticazione utente:

• Anonimo: nessuna autenticazione (se consentito dal server)
• Nome utente/Password: login applicativo
• Certificato: certificato utente X.509
• IssuedToken: token JWT o Kerberos

Implementazione di OPC-UA in Python​

La libreria python-opcua (o il suo fork asyncua) è il punto di riferimento in Python.

Installazione​

pip install asyncua

Client OPC-UA in Python — lettura dei dati​

import asyncio
from asyncua import Client

async def main():
    url = "opc.tcp://192.168.1.10:4840/freeopcua/server/"
    
    async with Client(url=url) as client:
        # Leggere un nodo in base al NodeId
        node = client.get_node("ns=2;s=Station_1.Pression")
        value = await node.read_value()
        print(f"Pression: {value} bar")
        
        # Lettura di più nodi in batch
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
            client.get_node("ns=2;s=Station_1.Defaut"),
        ]
        values = await client.read_values(nodes)
        for node, val in zip(nodes, values):
            print(f"  {node}: {val}")

asyncio.run(main())

Client OPC-UA per Python — abbonamento (Subscription)​

import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler

class DataChangeHandler(SubHandler):
    def datachange_notification(self, node, val, data):
        print(f"[CHANGE] {node} = {val}")
    
    def event_notification(self, event):
        print(f"[EVENT] {event}")

async def main():
    url = "opc.tcp://192.168.1.10:4840"
    
    async with Client(url=url) as client:
        handler = DataChangeHandler()
        subscription = await client.create_subscription(500, handler)  # 500ms
        
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
        ]
        
        monitored_items = await subscription.subscribe_data_change(nodes)
        print("Subscriptions actives, attente changements...")
        
        await asyncio.sleep(30)  # ascolta 30 secondi
        await subscription.unsubscribe(monitored_items)

asyncio.run(main())

Connessione sicura con certificato​

from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.crypto.cert_man import CertificateManager

async def connect_secure():
    client = Client("opc.tcp://192.168.1.10:4840")
    
    await client.set_security(
        SecurityPolicyBasic256Sha256,
        certificate="./client_cert.der",
        private_key="./client_key.pem",
        server_certificate="./server_cert.der"
    )
    
    await client.connect()
    # ... le vostre operazioni
    await client.disconnect()

Implementazione di OPC-UA in Node.js​

La libreria node-opcua è il punto di riferimento per JavaScript/TypeScript.

npm install node-opcua

Lettura dei dati​

const opcua = require("node-opcua");

const client = opcua.OPCUAClient.create({
    endpointMustExist: false,
    connectionStrategy: { maxRetry: 5, initialDelay: 2000 }
});

const endpointUrl = "opc.tcp://192.168.1.10:4840";

async function main() {
    await client.connect(endpointUrl);
    const session = await client.createSession();
    
    const nodeToRead = {
        nodeId: "ns=2;s=Station_1.Pression",
        attributeId: opcua.AttributeIds.Value
    };
    
    const dataValue = await session.read(nodeToRead);
    console.log(`Pression: ${dataValue.value.value} bar`);
    console.log(`Timestamp: ${dataValue.serverTimestamp}`);
    
    await session.close();
    await client.disconnect();
}

main().catch(console.error);

OPC-UA sui principali controllori industriali​

Siemens S7-1500 / S7-1200​

L'S7-1500 supporta il server OPC-UA nativo a partire dal firmware 2.0:

• Porta: 4840 (TCP)
• Configurazione in TIA Portal: Device Configuration → OPC UA → Server
• Attivare i nodi desiderati nella configurazione di accesso
• Autenticazione: certificati o nome utente/password

L'S7-1200 supporta OPC-UA a partire dalla versione 4.1 del firmware.

Schneider Electric M580 / M340​

M580: OPC-UA tramite modulo BMENOC0311 (firmware ≥ V2.0) M340: nessun supporto nativo per OPC-UA → Si consiglia Modbus TCP oppure un gateway da OPC-UA a Modbus (ad es. Kepware KEPServerEX)

Allen-Bradley / Rockwell (EtherNet/IP)​

I controllori Rockwell non supportano nativamente OPC-UA. Opzioni:

• KEPServerEX (Kepware): bridge EtherNet/IP → OPC-UA
• FactoryTalk Linx Gateway: server OPC-UA per l'ecosistema Rockwell
• Eziwan Gateway: connessione diretta EtherNet/IP/Modbus, esposizione API REST

Beckhoff TwinCAT 3​

TwinCAT 3 integra un server OPC-UA nativo tramite TF6100 (modulo OPC-UA). Configurazione tramite TwinCAT System Manager.

Wago / Phoenix Contact / Pilz​

La maggior parte dei PLC moderni di questi produttori supporta OPC-UA. Verificare il firmware e attivare il server nelle impostazioni di rete.

OPC-UA PubSub: l'estensione per il cloud​

OPC-UA PubSub (IEC 62541-14) è l'estensione che rende OPC-UA compatibile con le architetture IoT basate sul cloud:

• Publisher: l'apparecchiatura pubblica i propri dati su un Message Oriented Middleware
• Subscriber: il cloud o il sistema SCADA si abbona al flusso

Protocolli supportati:

• AMQP (porta 5672)
• MQTT (porta 1883 o 8883) — il più utilizzato nell'IoT
• UDP Multicast (rete locale)

Formati di codifica:

• JSON (leggibile, facile da debuggare)
• UADP (binario, compatto, integrato)

Esempio di messaggio OPC-UA PubSub in formato JSON:

{
  "MessageId": "abc123",
  "PublisherId": "urn:station1:plc",
  "DataSetWriterId": 1,
  "MetaDataVersion": {"MajorVersion": 1, "MinorVersion": 0},
  "Timestamp": "2026-08-14T10:30:00.000Z",
  "Payload": {
    "Station_1.Pression": {"Value": 4.2, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"},
    "Station_1.Debit": {"Value": 125.3, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"}
  }
}

Migrazione da OPC-DA a OPC-UA​

Se disponete di installazioni basate su OPC-DA (OPC Classic, Windows DCOM), la migrazione a OPC-UA offre:

• Eliminazione della dipendenza da Windows/DCOM
• Compatibilità con Linux / Raspberry Pi / PLC basati su Linux
• Crittografia (assente in OPC-DA)
• Accesso diretto a Internet (impossibile con DCOM senza una VPN complessa)

Strumento di migrazione: OPC UA Wrapper (ad es. Kepware) crea un server OPC-UA che espone i dati di un server OPC-DA esistente, consentendo una migrazione graduale.

OPC-UA con il gateway Eziwan​

L'Eziwan Gateway integra un client OPC-UA in grado di connettersi ai server OPC-UA delle vostre apparecchiature:

• Connessione Siemens S7-1500 OPC-UA (porta 4840)
• Connessione a qualsiasi server OPC-UA conforme alla norma IEC 62541
• Supporto delle modalità di sicurezza None, Sign, SignAndEncrypt
• Configurazione dei NodeId nell'interfaccia cloud (scansione automatica dello spazio degli indirizzi)
• Trasmissione dei dati alla piattaforma cloud Eziwan tramite MQTT/TLS

Vantaggio principale: non è necessario sviluppare autonomamente un client OPC-UA. Il gateway si occupa di tutto e mette a disposizione un'API REST per il vostro sistema SCADA o ERP.

Domande frequenti — OPC-UA​

OPC-UA è più complesso di Modbus? Sì, ma è giustificato per gli impianti con apparecchiature di diversi produttori e per i progetti dell’Industria 4.0. Per un impianto con 2-3 controllori dello stesso produttore, Modbus TCP può essere sufficiente. OPC-UA è la scelta obbligata in presenza di apparecchiature eterogenee, requisiti di sicurezza o esigenze di interoperabilità ERP/MES.

Devo aprire la porta 4840 sul mio firewall? Nell'architettura "zero-inbound-port" (come Eziwan), il gateway avvia la connessione al server OPC-UA internamente. Nessuna porta è aperta dall'esterno. Il tunnel VPN crittografato trasporta i dati verso il cloud.

OPC-UA può sostituire MQTT in un'architettura IoT? OPC-UA PubSub con trasporto MQTT combina il meglio dei due: il modello informativo semantico di OPC-UA con la leggerezza e la scalabilità di MQTT. È questa la direzione intrapresa dai modelli di riferimento dell’Industria 4.0 (Industrie 4.0 Architecture Reference Model, IDS-R).

Quali prestazioni ci si può aspettare da un server OPC-UA integrato? Una CPU 1515 del Siemens S7-1500 è in grado di elaborare circa 10.000 nodi OPC-UA in lettura al secondo. Per i PLC meno potenti (M221, piccoli WAGO), limitare il polling OPC-UA a 100-500 nodi/s. Le sottoscrizioni (Subscription) sono molto più efficienti del polling per volumi elevati.

Esistono server OPC-UA gratuiti da provare? Sì: ProsysOPC UA Simulation Server (gratuito, Windows), Node-RED con node-red-contrib-opcua (gratuito, multipiattaforma), python-opcua in modalità server (esempio nella documentazione su GitHub). Questi strumenti consentono di testare un client senza disporre di un PLC fisico.

Per approfondire​

• Blog: OPC-UA e MQTT — come combinare i due su un gateway industriale
• Blog: accesso remoto sicuro a PLC e SCADA — VPN, zero-trust e NIS2
• Blog: collegare un PLC Siemens S7 al cloud — guida tecnica
• Blog: IEC 62443 — guida pratica alla sicurezza informatica industriale
• Blog: Modbus TCP vs RTU — confronto completo per l’IoT industriale

Hai bisogno di aiuto per collegare i tuoi server OPC-UA al cloud? Richiedi una demo gratuita — il nostro team ti affiancherà dal POC all'implementazione.

Risorse aggiuntive​

• Da OPC UA a MQTT — pubblicazione di dati OPC UA su un broker MQTT cloud
• Protocolli industriali — confronto tra OPC UA, Modbus, MQTT e altri protocolli
• Gateway IoT industriale — come scegliere un gateway compatibile con OPC UA
• Da Modbus TCP al cloud — monitoraggio dei controllori Modbus TCP dal cloud
• SCADA cloud — architettura SCADA moderna con connettività OPC UA e cloud

Perché collegare il tuo M340/M221 al cloud?​

I controllori Schneider Electric della gamma Modicon sono presenti in migliaia di impianti industriali francesi: trattamento delle acque, stazioni di pompaggio, processi agroalimentari, linee di confezionamento. Robusti e affidabili, hanno spesso una durata di vita di 15-20 anni.

Ma le loro capacità di comunicazione native sono limitate:

• Nessuna connettività cloud nativa
• Accesso remoto spesso limitato a una costosa VPN MPLS
• Nessuna registrazione a lungo termine senza un server SCADA on-premise
• Avvisi inesistenti o solo locali (spie luminose, sirene)

La soluzione: un gateway IoT industriale che legge i dati Modbus del vostro M340/M221 e li trasmette al cloud, senza modificare il programma del PLC.

Compatibilità Modbus dei controllori Schneider Electric​

Modicon M221​

Il M221 (TM221CE16R, TM221CE24T, ecc.) integra una porta Modbus RTU nativa sulla presa RJ45 (RS-485 tramite adattatore TM3TI4 o cavo specifico) e una porta Modbus TCP sulla porta Ethernet.

Registri accessibili:

• da %MW0 a %MW255 — parole di memoria
• %QW — uscite analogiche
• %IW — ingressi analogici
• %M — bit di memoria (bobine 0-255)

Configurazione dello slave Modbus sull'M221:

In EcoStruxure Machine Expert - Basic:

1. Configuration → Modbus Serial o Modbus TCP
2. Indirizzo slave: 1 (impostazione predefinita)
3. Attivare "Slave function" → OK

Modicon M340​

Il M340 (BMX P34 2020, BMX P34 2030, ecc.) è dotato di una porta seriale Modbus RTU (RS-485, connettore SUB-D a 9 pin) e di un modulo ETH (BMX NOE 0100 o BMX NOC 0401) per Modbus TCP.

Registri accessibili tramite Modbus:

Indirizzo Modbus → indirizzo Unity Pro:

• Registro 400001 = %MW0
• Registro 400100 = %MW99
• Registro 400501 = %MW500

Modicon M580 (ePAC)​

L'M580 dispone di Modbus TCP nativo sulla porta Ethernet CPU e supporta le stesse tabelle di registri dell'M340, oltre a:

• Accesso ai moduli I/O tramite BMENOC0311 (modulo Ethernet)
• Supporto EtherNet/IP
• Funzionalità Data Exchange con EcoStruxure Plant

Architettura di connessione​

Opzione 1: Tramite Modbus TCP (Ethernet) — consigliata​

Prerequisiti:

• Modulo ETH installato sul rack (BMX NOE 0100 per M340)
• Indirizzo IP del PLC configurato (ad es. 192.168.1.10)
• Firewall interno che consenta l'accesso alla porta 502 dall'IP del gateway

Vantaggi:

• Nessun cablaggio RS-485 aggiuntivo
• Maggiore velocità di trasmissione (fino a 30 richieste al secondo)
• Coesistenza con Traffic Unity Pro (letture non invasive)

Opzione 2: Tramite Modbus RTU (RS-485)​

Per il modello M221: utilizzare il cavo TCSMCNAM3M002P (da RJ45 a RS-485) o l'adattatore VW3A8306 a seconda della gamma.

Per il modello M340: connettore SUB-D a 9 pin sul lato PLC, terminali 3 (+) e 8 (-) per RS-485.

Impostazioni seriali M221/M340 (impostazioni predefinite):

• Velocità: 19200 bps
• Parità: nessuna (8N1)
• Indirizzo slave: 1

Configurazione del gateway Eziwan per Schneider​

Una volta collegato il gateway, la configurazione si effettua dall'interfaccia cloud di Eziwan con pochi clic.

Aggiungere un dispositivo Modbus​

1. Accedere a Flotte → Site → + Équipement
2. Selezionare Modbus TCP o Modbus RTU
3. Inserire:
   • IP: 192.168.1.10 (o l'indirizzo del proprio M340)
   • Porta: 502
   • ID slave: 1

Configurare le variabili da leggere​

Conversione tecnica: applicare un fattore moltiplicatore se il PLC restituisce un valore lordo (ad es. ×0.01 per passare da 1500 a 15,00 bar).

Intervallo di polling consigliato​

Cosa offre il cloud​

Dashboard in tempo reale​

Non appena il gateway si connette per la prima volta, i dati vengono trasmessi in tempo reale alla dashboard di Eziwan:

• Grafici di tendenza su 1 ora, 24 ore, 7 giorni, 30 giorni
• Indicatori e grafici configurabili
• Tabelle multisito per confrontare i vostri impianti
• Esportazione CSV/Excel per la reportistica

Sistema di allerta​

Configura avvisi precisi per ogni variabile:

Avviso: Livello del serbatoio
  Condition : %MW10 < 10 (niveau bas)
  Canal : SMS + Email
  Destinatari: equipe@maintenance.fr, astreinte@maintenance.fr
  Acquittement : requis

Avviso: Guasto alla pompa
  Condizione: %M5 = 1 (bit di errore attivo)
  Canale: SMS immediato
  Priorità: Critica

Storicizzazione a lungo termine​

Tutti i dati vengono archiviati per 5 anni di serie, senza costi aggiuntivi. È possibile:

• Consultare i dati storici di produzione degli anni N-1 e N-2
• Individuare deterioramenti progressivi (ad esempio, una pompa che assorbe più corrente)
• Generare rapporti di conformità (acqua, energia, settore farmaceutico)

Caso pratico: stazione di pompaggio M340​

Contesto: un ente locale gestisce 12 stazioni di pompaggio dotate di M340 BMX P34 2020. Manutenzione attuale: 3 giri di ispezione sul campo a settimana, 2 tecnici.

Configurazione implementata:

• 12 × Eziwan Gateway (Modbus TCP, SIM SFR Business)
• Variabili lette per stazione: livello del pozzo, portata, pressione di mandata, corrente del motore, ore di funzionamento, guasti (12 variabili)
• Intervallo di polling: 5 s per portata/pressione/guasti, 1 min per livello/contatori

Risultati dopo 6 mesi:

• Ispezioni sul campo: 3/settimana → 1/settimana (-67%)
• Incidenti rilevati prima di un fermo: 4 (surriscaldamento della pompa, valvola bloccata, galleggiante grippato)
• Risparmi calcolati: 41.000 € all’anno (costi di spostamento + interventi di manutenzione correttiva evitati)
• ROI (ritorno sull’investimento) per hardware + abbonamento: 5 mesi

Migrazione da SoMachine / Unity Pro​

Se si utilizza SoMachine (M221) o Unity Pro (M340/M580), non è necessaria alcuna modifica al programma PLC. Il gateway Eziwan si connette in modalità sola lettura per impostazione predefinita.

Se desiderate anche scrivere comandi (setpoint, comandi) dal cloud:

• Utilizzate i codici funzione FC05 (Write Single Coil) e FC06 (Write Single Register)
• Configurare i diritti di accesso nel gateway Eziwan (autenticazione a più fattori)
• Creare intervalli di registri specificamente dedicati ai comandi a distanza (es. %MW200-MW220)

Compatibilità con EcoStruxure​

Il gateway Eziwan è compatibile con EcoStruxure in diversi modi:

In parallelo a EcoStruxure Plant​

Il gateway legge gli stessi registri del vostro SCADA EcoStruxure, senza interferenze. Ideale per aggiungere:

• Monitoraggio centralizzato multisito
• Accesso mobile per i tecnici sul campo
• Avvisi via SMS/e-mail (spesso assenti nella versione base di EcoStruxure)

Sostituzione graduale​

Se la vostra licenza EcoStruxure Plant sta per scadere, potete effettuare una migrazione graduale:

1. Implementare il gateway Eziwan in parallelo
2. Verificare i dati per 4-8 settimane
3. Trasferire il monitoraggio principale su Eziwan
4. Ridurre la licenza EcoStruxure all’ambito effettivamente necessario

Confronto tra connessioni cloud: M221 vs M340 vs M580​

Domande frequenti — Connessione dei modelli M340/M221 al cloud​

È necessario modificare il programma SoMachine/Unity Pro? No. Il gateway Eziwan si connette in modalità Modbus master al PLC slave. Non viene aggiunta alcuna riga di codice al PLC. Se il PLC è già configurato come slave Modbus (come avviene per impostazione predefinita), la connessione è immediata.

Il mio M340 è già dotato di un sistema SCADA Unity Pro: è compatibile? Sì. Più master Modbus TCP possono interrogare lo stesso slave contemporaneamente. Il gateway Eziwan e il vostro SCADA coesistono senza conflitti, a condizione di configurare una frequenza di polling ragionevole (≥ 1 s).

Posso monitorare i moduli di ingresso analogici (BMX AMI 0410)? Sì. I moduli analogici sono indirizzati nelle tabelle %IW (ingressi) e %QW (uscite). Consultare la documentazione di Unity Pro per la mappatura dei registri dei moduli specifici.

Il gateway funziona se la rete 4G è interrotta? Sì. Il gateway Eziwan integra un buffer su scheda SD: i dati continuano a essere acquisiti localmente e vengono trasmessi in blocco non appena viene ripristinata la connettività (store-and-forward). Gli avvisi locali (SMS diretti) rimangono operativi anche senza il cloud.

È compatibile con la gamma Zelio Logic? Zelio Logic Smart Relay supporta Modbus RTU in modo limitato. A seconda del modello (SR2/SR3), l'accesso ai registri interni potrebbe essere limitato. Contattateci per verificare la compatibilità del vostro modello specifico.

Avviare il proprio POC​

Avete un M340, un M221 o un M580 in sede e desiderate verificare la connessione al cloud?

Eziwan offre un POC gratuito di 30 giorni che include:

• 1 gateway preconfigurato spedito entro 48 ore
• Onboarding guidato dal nostro team tecnico
• Dashboard configurate in base alle vostre esigenze
• Senza impegno, senza carta di credito

Avvia il POC gratuito → | Calcola il tuo ROI →

Per approfondire​

• Blog: collegare un PLC Siemens S7 al cloud — guida tecnica
• Blog: accesso remoto sicuro a PLC e SCADA — VPN e NIS2
• Blog: Modbus TCP vs RTU — quale protocollo scegliere?
• Documentazione: compatibilità Siemens S7-1200/S7-1500
• Blog: manutenzione predittiva IIoT — dai dati dei sensori all’allerta

Utilizzate altre linee di prodotti Schneider Electric (Altivar, Easergy, PowerLogic)? Contattateci per verificare la compatibilità con la vostra apparecchiatura specifica.

Risorse aggiuntive​

• Accesso remoto ai PLC Schneider — accesso remoto sicuro ai PLC Schneider M340, M221 e M580
• Collegamento di un PLC al cloud — collegamento di qualsiasi PLC industriale al cloud
• Modbus TCP verso il cloud — supervisione tramite Modbus TCP dal cloud
• Accesso remoto industriale — architettura VPN e zero-trust per siti industriali
• Monitoraggio e assistenza remota industriale — monitoraggio centralizzato dei vostri controllori Schneider

Questa guida mette a confronto le 4 principali tecnologie wireless utilizzate nell'IoT industriale in Francia, fornendo raccomandazioni concrete per ciascun caso d'uso.

Panoramica: 4 tecnologie per 4 esigenze diverse​

Prima di entrare nei dettagli, ecco l'essenziale in una frase per ciascuna tecnologia:

• LoRaWAN: per sensori a basso consumo alimentati a batteria, in ambienti aperti, su lunghe distanze (da 1 a 15 km)
• Zigbee: per reti di sensori ad alta densità in ambienti interni, con struttura mesh, su brevi distanze (da 10 a 100 m)
• 4G LTE: per siti isolati, apparecchiature critiche, connessioni WAN a lunga distanza, banda larga
• Wi-Fi: per siti con infrastruttura di rete esistente, apparecchiature mobili in aree coperte, banda larga locale

Confronto tecnico dettagliato​

LoRaWAN in dettaglio​

Quando utilizzarlo​

LoRaWAN è ideale per le situazioni in cui sono necessarie distanze molto lunghe e un consumo energetico molto basso, ma in cui la velocità di trasmissione è ridotta (pochi byte per messaggio ogni minuto o ogni ora).

Casi d'uso industriali ideali per LoRa:

• Lettura dei contatori di acqua, gas ed elettricità in contesti urbani o periurbani
• Monitoraggio delle condizioni ambientali su vaste aree (temperatura, umidità, CO₂ in diversi edifici)
• Tracciamento di beni con sensori GPS/di movimento a lunga durata (pallet, serbatoi mobili)
• Monitoraggio di sensori in zone di difficile accesso (fognature, infrastrutture sotterranee, aree rurali)
• Rilevamento di apertura/chiusura (botole, porte di silos) su ampi perimetri

Vantaggi di LoRaWAN:

• Autonomia della batteria eccezionale (da 5 a 10 anni con una batteria AA)
• Infrastruttura molto semplice: un concentratore LoRa copre un raggio da 5 a 15 km in ambito rurale
• Reti pubbliche disponibili in Francia (Bouygues Telecom LoRa, Objenious, Sewan, CityMesh)
• Costo per nodo molto contenuto (da 10 a 50 € per un semplice sensore)

Limiti di LoRaWAN:

• Velocità di trasmissione molto bassa: impossibile inviare immagini, flussi video o più di pochi byte per messaggio
• Elevata latenza: il downlink (cloud → sensore) può richiedere dai 5 ai 10 secondi — non adatto al controllo in tempo reale
• Limitazioni normative: la banda a 868 MHz è limitata all’1% di duty cycle (circa 36 secondi di trasmissione all’ora) — ciò limita la frequenza degli invii
• In ambienti interni densamente costruiti (calcestruzzo spesso, scantinati), la portata scende a poche decine di metri

Architettura tipica LoRa industriale:

Zigbee in dettaglio​

Quando utilizzarlo​

Zigbee è ideale per le reti fitte di sensori in ambienti interni a corto raggio, in particolare negli edifici (smart building) e negli stabilimenti industriali, dove le distanze sono brevi ma il numero di nodi è elevato.

Casi d'uso industriali ideali per Zigbee:

• Gestione tecnica degli edifici (GTB): illuminazione, tapparelle, HVAC
• Monitoraggio delle condizioni ambientali in ambienti ad alta densità (magazzini, camere bianche)
• Rete di sensori di presenza, apertura porte, contatori di energia per zona
• Automazione industriale leggera in sostituzione dei sistemi cablati per gli edifici terziari

Vantaggi di Zigbee:

• Architettura a rete (mesh): i nodi Zigbee inoltrano i dati dei nodi distanti, eliminando le zone d'ombra
• Basso consumo della batteria (da 1 a 5 anni)
• Ampio ecosistema di sensori standardizzati e interoperabili (standard Matter dal 2022)
• Velocità di trasmissione sufficiente per le misurazioni in tempo reale (allarmi, stati)
• Densità di nodi molto elevata (migliaia sulla stessa rete)

Limiti di Zigbee:

• Portata limitata: da 10 a 100 m per salto (la rete mesh compensa questo limite, ma richiede un numero sufficiente di nodi intermedi)
• Coordinamento necessario: ogni rete Zigbee richiede un coordinatore (hub o gateway Zigbee)
• 2,4 GHz = interferenze con Wi-Fi, Bluetooth e forni a microonde in ambienti industriali densamente popolati
• Non adatto a collegamenti a lunga distanza tra edifici distanti

Il 4G LTE in dettaglio​

Quando utilizzarlo​

Il 4G LTE è la tecnologia ideale per le connessioni WAN a lunga distanza, i siti isolati privi di infrastruttura di rete e le applicazioni che richiedono una larghezza di banda sufficiente per il monitoraggio e l'accesso remoto.

Casi d'uso industriali ideali per il 4G:

• Siti isolati (stazioni di pompaggio, baite, antenne, sensori meteorologici) senza connessione via cavo
• Connessione di emergenza per siti industriali critici (failover da fibra ottica a 4G)
• Gateway IoT che trasmettono i dati dal campo al cloud (monitoraggio Modbus, OPC-UA)
• Accesso remoto VPN per la telemanutenzione delle apparecchiature industriali
• Veicoli e attrezzature mobili (camion refrigerati, macchinari da cantiere)
• Implementazioni rapide dove l’installazione di un cavo di rete è impossibile o troppo costosa

Vantaggi del 4G LTE industriale:

• Copertura nazionale: il 99,2% dei comuni francesi (comprese le zone rurali e industriali isolate)
• Velocità sufficiente: da 5 a 50 Mbps sono più che sufficienti per il monitoraggio e la manutenzione remota
• Nessuna infrastruttura locale: nessun cablaggio, nessun switch, nessun punto di accesso da mantenere
• Doppia SIM: commutazione automatica tra operatori per massimizzare la disponibilità
• Plug-and-play: un gateway 4G industriale è operativo in meno di un’ora

Limiti del 4G LTE:

• Costo per nodo più elevato: un gateway industriale 4G costa da 300 a 600 €, l’abbonamento SIM da 10 a 20 € al mese
• Consumo energetico: richiede un'alimentazione di rete (non adatto ai sensori alimentati a batteria)
• Latenza: da 30 a 100 ms (accettabile per il monitoraggio, non per il controllo in tempo reale critico)
• Zone senza copertura: alcune aree rurali molto isolate prive di copertura (risolvibile con antenna esterna o via satellite)
• Dipendenza dall’operatore: la disponibilità dipende dalla rete mobile (accettabile con dual-SIM)

Il Wi-Fi in dettaglio​

Quando utilizzarlo​

Il Wi-Fi è adatto a siti con un'infrastruttura di rete esistente, ad apparecchiature che richiedono un'elevata velocità di trasmissione e ad aree completamente coperte da punti di accesso.

Casi d'uso industriali ideali per il Wi-Fi:

• Collegamento di sensori o apparecchiature industriali in uno stabilimento già coperto dal Wi-Fi
• Veicoli o attrezzature mobili in loco (carrelli elevatori, AGV) in un'area coperta
• Telecamere IP di monitoraggio (richiedono l’alta velocità del Wi-Fi)
• Sistema SCADA locale in modalità di monitoraggio in tempo reale (latenza < 10 ms)

Vantaggi del Wi-Fi industriale:

• Velocità molto elevata (compatibile con lo streaming video e gli aggiornamenti rapidi del firmware)
• Infrastruttura spesso già presente negli stabilimenti moderni
• Latenza molto bassa (da 1 a 10 ms) — utilizzabile per applicazioni in tempo reale di media complessità
• Numerose apparecchiature industriali con Wi-Fi integrato (HMI, robot collaborativi)

Limiti del Wi-Fi industriale:

• Portata limitata: da 30 a 150 m per AP; richiede una rete mesh per coprire aree estese
• Interferenze: banda a 2,4 GHz saturata in ambienti industriali densamente popolati (motori, frequenze radio, macchine CNC)
• Consumo elevato: non adatto ai sensori alimentati a batteria
• Infrastruttura costosa: AP industriali (Cisco, Aruba, Extreme Networks) = da 500 a 3.000 € per AP
• Gestione della rete complessa: il roaming per i dispositivi mobili richiede competenze specifiche in materia di Wi-Fi

Guida alla scelta: come scegliere?​

Albero decisionale​

Tabella delle raccomandazioni per settore​

Architettura ibrida: il meglio dei due mondi​

In pratica, le implementazioni IoT industriali mature utilizzano una combinazione di diverse tecnologie, scelte in base alla natura di ciascuna apparecchiatura.

Esempio di architettura ibrida: sito industriale di 10 ettari

Il gateway Eziwan funge da concentratore multiprotocollo: comunica in Modbus sulla rete OT locale, è compatibile con i concentratori LoRa e Zigbee per i sensori wireless e trasmette tutti i dati al cloud tramite 4G LTE. Un unico abbonamento, un'unica dashboard.

Confronto dei costi su 5 anni (installazione di 100 sensori)​

Nota: il 4G LTE è nettamente più costoso per nodo, ma offre una connettività WAN a lunga distanza che LoRa e Zigbee non sono in grado di garantire. Il confronto è valido solo per i sensori di raccolta dati, non per i gateway industriali che devono garantire la connessione a Internet.

Conclusione​

Non esiste una tecnologia IoT "migliore" in assoluto. La scelta dipende da tre criteri fondamentali:

1. La distanza: breve (Zigbee), medio-lunga (LoRaWAN), molto lunga o WAN (4G LTE)
2. Il consumo: a batteria a lunga durata (LoRaWAN > Zigbee > Wi-Fi), alimentato dalla rete elettrica (tutte)
3. La velocità di trasmissione: dati dei sensori (sono sufficienti LoRaWAN e Zigbee), monitoraggio e accesso remoto (sono necessari 4G LTE e Wi-Fi)

La soluzione Eziwan è ottimizzata per il 4G LTE come tecnologia di connessione WAN industriale, poiché è la più adatta ai gateway che devono collegare le reti OT locali (Modbus, OPC-UA) al cloud di supervisione. Può essere integrata con concentratori LoRaWAN o Zigbee per i sensori a basso consumo.

Hai bisogno di aiuto per scegliere l'architettura giusta per il tuo progetto? Contatta il nostro team di ingegneri per una valutazione gratuita della tua situazione.

Domande frequenti​

È possibile combinare LoRaWAN e 4G LTE nello stesso sito? Sì — anzi, è addirittura consigliabile. I sensori LoRaWAN alimentati a batteria (contatori dell’acqua, sonde ambientali, sensori di livello) trasmettono i dati tramite un concentratore LoRa. Il gateway Eziwan 4G LTE aggrega i dati dei sensori LoRa locali e delle apparecchiature Modbus, inviandoli al cloud. Il 4G viene utilizzato solo per la connessione WAN, non per ogni singolo sensore.

LoRaWAN è affidabile per il monitoraggio industriale critico? LoRaWAN è adatto al monitoraggio non critico (letture dei contatori, ambiente, presenza). Per i sistemi di monitoraggio critici (allarmi delle pompe, valori di processo), il 4G LTE è preferibile grazie alla sua bassa latenza e alla sua affidabilità. Spesso i due protocolli coesistono: LoRaWAN per i sensori ausiliari, 4G per i controllori logici programmabili (PLC) e le interfacce uomo-macchina (HMI) critiche.

Qual è la differenza tra LoRa e LoRaWAN? LoRa è la tecnologia radio (modulazione CSS di Semtech). LoRaWAN è il protocollo di rete basato su LoRa: definisce l'architettura di rete (nodi → concentratori → Network Server → Application Server), la gestione degli indirizzi, la sicurezza (AES-128) e le classi di dispositivi (A, B, C). LoRa senza LoRaWAN può funzionare in modalità punto-punto proprietaria, che è meno interoperabile.

È possibile utilizzare Zigbee in un ambiente industriale soggetto a disturbi elettromagnetici? Zigbee (2,4 GHz) è sensibile alle interferenze radio industriali (motori, variatori, saldatura). In ambienti fortemente disturbati, è preferibile utilizzare i canali Zigbee a 915 MHz (disponibili nella versione sub-GHz) oppure ricorrere alla connessione cablata (RS-485 Modbus) per le apparecchiature più critiche. La rete mesh Zigbee migliora la resilienza, ma non elimina i limiti fisici.

Il Wi-Fi industriale è adatto a una macchina in movimento (AGV, trasportatore)? Il Wi-Fi con roaming 802.11r (Fast Transition) viene utilizzato per gli AGV (carrelli a guida automatica) e i trasportatori. Una rete di access point che copre l’intero percorso consente un handover rapido (<50 ms) tra gli AP. Si tratta di un’implementazione più complessa e costosa rispetto a una rete fissa, ma è la soluzione standard per le macchine in movimento in ambienti interni.

Per approfondire​

• Blog: OPC-UA, MQTT, Modbus — come scegliere il proprio gateway industriale
• Blog: Modbus, MQTT, OPC-UA — confronto completo dei protocolli industriali
• Blog: SIM M2M IoT — confronto tra operatori in Francia 2026
• Blog: come scegliere il proprio gateway IoT industriale — 9 criteri
• Blog: monitoraggio industriale da remoto — guida completa 2026

Eziwan è specializzata nella connettività IoT industriale 4G LTE. Il nostro gateway multiprotocollo (Modbus, OPC-UA, MQTT, LoRaWAN, Zigbee) si adatta alla vostra architettura esistente. Scopri il gateway Eziwan →

Risorse aggiuntive​

• Connettività industriale — soluzioni di connettività multiprotocollo per l'IoT industriale
• Protocolli industriali — guida ai protocolli di comunicazione industriali (Modbus, OPC-UA, MQTT…)
• Gateway IoT industriale — gateway multiprotocollo radio e cablati per l’IIoT
• Connessione Internet per siti industriali isolati — scegliere il protocollo radio più adatto per i siti privi di copertura via cavo
• Soluzioni industriali Eziwan — gamma completa di soluzioni di connettività e monitoraggio industriale

Questa guida illustra i principali casi d'uso dell'IoT agricolo in Francia, le apparecchiature compatibili, i costi e il ROI, e spiega come implementare una soluzione di monitoraggio agricolo affidabile nelle zone rurali — anche in assenza di connessione in fibra ottica.

L'agricoltura: un terreno fertile per l'IoT industriale​

L'agricoltura moderna utilizza già numerose apparecchiature elettroniche ed elettromeccaniche: sistemi di irrigazione automatizzati, ventilatori per gli allevamenti, serbatoi di raffreddamento del latte, silos di stoccaggio, serre climatizzate, pompe per pozzi. La stragrande maggioranza di queste apparecchiature dispone di interfacce di comunicazione (Modbus RTU, 4-20 mA, uscite a impulsi) che consentono una connessione IoT senza necessità di sostituzione.

I vantaggi dell'IoT per l'agricoltura:

• Monitoraggio 24 ore su 24 senza la presenza costante dell'agricoltore
• Avvisi immediati in caso di anomalie (guasti alle attrezzature, superamento delle soglie)
• Cronologia dei dati per l’ottimizzazione delle pratiche e la tracciabilità
• Riduzione delle perdite (latte non conforme, crescita insufficiente, mortalità animale)
• Conformità normativa facilitata (benessere animale, direttive sulle acque)

Caso d'uso 1: Monitoraggio degli allevamenti​

Allevamenti suini, pollai, bovini da latte​

Gli allevamenti in regime intensivo (allevamenti suini, avicoli, allevamenti da latte) sono particolarmente adatti al monitoraggio tramite IoT. I parametri critici da monitorare sono:

Condizioni climatiche dell'edificio:

• Temperatura (°C) e umidità relativa (%): variazioni significative incidono direttamente sulla crescita e sulla salute degli animali
• Concentrazione di CO₂ (ppm): indicatore della qualità dell'aria e dell'efficienza della ventilazione
• Concentrazione di NH₃ (ammoniaca, ppm): gas pericoloso prodotto dagli escrementi, soggetto a normative per il benessere degli animali

Impianti di ventilazione:

• Stato di funzionamento/arresto di ciascun ventilatore (ingresso digitale)
• Velocità di rotazione o posizione delle serrande (uscita 0-10 V o 4-20 mA)
• Consumo elettrico per circuito (trasformatore di corrente)

Mangimi e acqua:

• Livello dei silos dei mangimi (sensore di livello a ultrasuoni)
• Consumo d'acqua (flussometro a impulsi)
• Stato degli alimentatori automatici (TOR)

Sensori compatibili e interfacce:

Soglie di allerta tipiche per gli allevamenti:

Caso d'uso 2: Monitoraggio dei serbatoi del latte​

Il raffreddamento del latte è un obbligo normativo (decreto del 15 settembre 2004, come modificato): il latte vaccino deve essere raffreddato a 8 °C entro 2 ore dalla mungitura e mantenuto a una temperatura massima di 4 °C fino al ritiro.

Il mancato rispetto di tali temperature comporta:

• Degradazione microbiologica irreversibile del latte
• Rifiuto della raccolta da parte del caseificio (perdita economica diretta)
• Penali contrattuali (malus di qualità)

Monitoraggio IoT del serbatoio del latte:

La maggior parte dei serbatoi per il latte di ultima generazione (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) è dotata di una porta RS-232 o RS-485 Modbus per il monitoraggio. I parametri accessibili includono:

• Temperatura del latte (°C) con risoluzione di 0,1 °C
• Stato del compressore di raffreddamento
• Volume del latte (se il serbatoio è dotato di indicatore di livello)
• Cronologia delle temperature (curva completa dall'ultima mungitura)

Il Gateway Eziwan si collega al serbatoio tramite RS-232 o RS-485 e invia i dati al cloud con un polling configurabile di 5 minuti. Se la temperatura supera gli 8 °C per più di 15 minuti, viene inviato un avviso via SMS.

Caso di studio: un allevatore di vacche da latte della Bretagna, che gestisce 3 serbatoi per il latte (allevamento di 120 vacche), ha evitato 2 rifiuti di raccolta in 6 mesi grazie agli avvisi SMS notturni (guasto al compressore rilevato alle 2 del mattino, intervento alle 4 prima del ritiro previsto alle 6). Risparmio: 2 × 800 L × 0,40 €/L = 640 € di perdita evitata, oltre alle penali per la qualità.

Caso d'uso 3: Monitoraggio di serre orticole e per la coltivazione di ortaggi​

Le serre orticole rappresentano un investimento significativo (da 50 a 300 €/m²), la cui redditività dipende dal mantenimento di condizioni climatiche ottimali. Il monitoraggio tramite IoT consente di individuare i guasti (malfunzionamento del riscaldamento, ventilazione bloccata, rottura del telo di plastica) prima che causino danni irreversibili alle colture.

Parametri da monitorare in serra:

Impianti della serra monitorabili:

• Caldaie e pompe di calore (riscaldamento): Bosch, Vaillant, Viessmann — tramite Modbus o relè digitale
• Ventilatori e sistemi di apertura: comando 0-10 V o relè
• Pompe di irrigazione: variatore di frequenza Modbus
• Impianto di trattamento dell’acqua (UVA, osmotizzatore): ingressi digitali (ON/OFF) di stato di funzionamento/arresto

ROI della supervisione di una serra ortofrutticola: Per una serra di 5.000 m² coltivata a pomodori (produzione annuale ~500 t, prezzo di rivendita ~0,80 €/kg = 400.000 € di fatturato annuo), un guasto al sistema di riscaldamento non rilevato durante la notte nel mese di marzo può distruggere l’intera coltivazione — con una perdita compresa tra 100.000 e 200.000 €. Il costo di un gateway Eziwan con avviso via SMS: 500 € + 100 € all’anno di abbonamento. ROI immediato.

Caso d'uso 4: Gestione dell'irrigazione​

L'irrigazione rappresenta il 45% del consumo idrico industriale in Francia. La normativa sta diventando più severa (decreti di restrizione nei periodi di magra, canoni idrici), rendendo indispensabile una gestione accurata dell'irrigazione.

Monitoraggio IoT dell'irrigazione:

• Misuratori di portata per appezzamento: misurazione del volume d'acqua applicato per appezzamento o per coltura (Modbus o a impulsi)
• Misuratori di umidità del suolo (tensiometri, sensori TDR): misurazione dell’umidità volumetrica e della suzione del suolo — database per l’attivazione del fabbisogno irriguo
• Stazioni meteorologiche integrate: ETP (evapotraspirazione potenziale) calcolata in tempo reale, integrazione con Météo France per l’ETP previsionale
• Contatori dell’acqua di pozzo: monitoraggio dei volumi prelevati per la dichiarazione DDT (obblighi normativi > 1.000 m³/anno)
• Pompe di pozzo e gruppi di irrigazione: monitoraggio dello stato e del consumo elettrico

Conformità normativa: Gli impianti che prelevano più di 1.000 m³/anno di acque sotterranee o superficiali sono tenuti a dichiarare i propri prelievi (articolo L214-1 del Codice dell'ambiente). Eziwan genera automaticamente i rapporti mensili sui prelievi da trasmettere alla DDT/DREAL.

Caso d'uso 5: Sili di stoccaggio​

Lo stoccaggio dei cereali rappresenta una sfida economica di grande rilevanza. Condizioni di stoccaggio inadeguate (temperatura, umidità) possono causare la formazione di micotossine (aflatossine, DON) o muffe che compromettono la qualità o rendono la merce invendibile.

Parametri da monitorare:

• Temperatura: catene di termometri per silos (Rolfes, GSI) con 4-8 sonde per silo a diverse altezze
• Umidità: sensori di umidità del grano a lettura continua o all’ingresso del silo (silo di ricezione)
• Livello: sensori di livello a ultrasuoni o a pressione per determinare il volume stoccato
• Ventilazione: stato dei ventilatori di estrazione e di raffreddamento, portata (m³/h)
• Consumo elettrico: controllo automatico dei ventilatori in base alla temperatura

Interfaccia: la maggior parte dei moderni sistemi di controllo dei silos (Superchief, GSI Fan Controller, Brock NECO) dispone di un'uscita Modbus RS-485 o di una porta RS-232.

Connettività 4G per le aziende agricole​

La grande maggioranza delle aziende agricole francesi non dispone di una connessione in fibra ottica. Il 4G LTE copre il 99,2% dei comuni francesi (fonte: Arcep 2025), ma la copertura all'interno degli edifici può essere scarsa.

Soluzioni per le zone con scarsa copertura:

1. Antenna 4G esterna direzionale: guadagno da 9 a 15 dBi, portata fino a 30 km in linea d’aria, compatibile con tutti gli operatori. Installazione sul cornicione dell’edificio o su un palo.

2. SIM multi-operatore Eziwan: verifica la copertura dei 3 operatori francesi (Orange, SFR, Bouygues) e si connette al segnale migliore disponibile. Aumenta in modo significativo la copertura nelle zone rurali.

3. LoRa + Gateway 4G: per i sensori a bassissimo consumo e molto distanti (fino a 15 km), un'architettura LoRaWAN con un concentratore LoRa connesso in 4G tramite l'Eziwan Gateway può coprire l'intera area di un impianto.

4. Connessione satellitare (ultima risorsa): per i siti privi di copertura 4G, è possibile integrare un'opzione satellitare (Starlink a bassa latenza o Eutelsat ViaSat) con l'Eziwan Gateway. Latenza di 20-40 ms con Starlink.

Normative agricole e IoT​

Benessere degli animali​

La direttiva europea 2008/120/CE (suini), 2007/43/CE (polli da carne) e 1999/74/CE (galline ovaiole) impongono livelli minimi di temperatura, spazio, ventilazione e illuminazione. Il monitoraggio tramite IoT consente di:

• Documentare in modo continuo il rispetto delle soglie normative
• Fornire prove durante i controlli della DDPP (Direzione Dipartimentale per la Protezione delle Popolazioni)
• Segnalare immediatamente il superamento di una soglia normativa

Direttiva sui nitrati​

Le aziende agricole situate in zone vulnerabili ai nitrati sono soggette al Programma d'Azione Regionale (PAR). Il monitoraggio dello spandimento e della gestione degli effluenti (contatore di portata sulla barra di spandimento, livello della fossa) facilita il rispetto delle date di divieto e il calcolo delle dosi.

Tracciabilità della filiera​

Numerose filiere (Label Rouge, DOP, IGP, agricoltura biologica) richiedono la tracciabilità delle condizioni di allevamento o di coltivazione. I dati IoT di Eziwan vengono archiviati e possono essere esportati per alimentare gli strumenti di tracciabilità (Bluerex, Kite Consulting, OAD-Systèmes).

Costi e ROI per un'azienda agricola​

Investimento tipo​

ROI per un allevamento da latte​

• Costo di un rifiuto di raccolta: da 600 a 2.000 € (a seconda del volume + sanzioni)
• Rischio annuale in assenza di supervisione: da 1 a 2 incidenti relativi ai serbatoi all’anno in 5 anni di esercizio
• Costo annualizzato di un incidente: da 600 a 800 € all’anno
• Costo della supervisione: da 250 a 400 € all’anno
• ROI netto: da 200 a 550 € all’anno = ammortizzato in meno di 1 anno

Aiuti disponibili​

Il piano France 2030 e gli aiuti PCAE (Piano di competitività e adattamento delle aziende agricole) finanziano parzialmente le attrezzature per la modernizzazione digitale del settore agricolo. Le percentuali di aiuto variano a seconda delle regioni e dei programmi (dal 30 al 50% degli investimenti ammissibili). Rivolgetevi alla vostra Camera dell’Agricoltura o al vostro consulente FranceAgriMer per conoscere i programmi applicabili al vostro progetto.

Conclusione​

L'IoT industriale è ormai alla portata delle aziende agricole francesi, grazie alla copertura capillare del 4G, ai sensori Modbus standardizzati e alle piattaforme cloud economiche come Eziwan. Gli ostacoli tecnici e finanziari che ne frenavano l'adozione si sono notevolmente ridotti.

Con un investimento iniziale compreso tra 1.000 e 2.000 € per edificio e un abbonamento inferiore a 400 € all’anno, un agricoltore beneficia di un monitoraggio 24 ore su 24 delle sue attrezzature critiche, di avvisi SMS immediati e di una cronologia documentata ai fini degli obblighi normativi.

Prossimo passo: contattate il team di Eziwan per uno studio di fattibilità gratuito su misura per la vostra azienda agricola e il vostro tipo di produzione.

Domande frequenti​

Il 4G è disponibile nelle zone rurali agricole francesi? La copertura 4G nella Francia metropolitana supera il 99% della popolazione, ma copre solo circa l’80% del territorio in termini di superficie — alcune aziende agricole situate in zone non coperte rimangono escluse. Per queste zone: la rete NB-IoT (NarrowBand-IoT) offre una migliore penetrazione all’interno degli edifici e una portata maggiore, mentre le soluzioni satellitari (Starlink) stanno diventando accessibili per i siti completamente isolati. Prima di qualsiasi implementazione è indispensabile verificare preventivamente la copertura nel sito esatto.

È possibile collegare un silo di stoccaggio o una cantina cooperativa già esistenti senza sostituire le apparecchiature? Nella stragrande maggioranza dei casi, sì. I silos moderni sono dotati di sensori di temperatura e umidità con uscite 4-20 mA o RS485 Modbus: un gateway IoT si collega direttamente. Per le apparecchiature più datate prive di interfaccia digitale, sono disponibili sensori sostitutivi compatibili con Modbus RTU a un prezzo compreso tra 50 e 100 € per punto di misura.

Quali obblighi normativi può aiutare a documentare il monitoraggio IoT? Nel settore zootecnico: gli obblighi di tracciabilità sanitaria (profilassi, identificazione degli animali, condizioni di trasporto — regolamento UE 2016/429), il benessere degli animali (temperature, ventilazione, densità) e i controlli DPE/PAC possono avvalersi dei dati storici dell’IoT come prove. Il registro automatico di tutte le misurazioni con data e ora certificate rappresenta un vantaggio significativo durante i controlli.

Per approfondire​

• Blog: monitoraggio 4G delle risorse idriche e della rete fognaria — gestione delle risorse idriche per gli enti locali
• Blog: ROI dell'IoT industriale — calcolo e ottimizzazione
• Blog: monitoraggio del segnale 4G — RSRP, RSRQ e copertura rurale
• Blog: SIM M2M IoT — confronto tra operatori in Francia nel 2026

Eziwan affianca gli agricoltori, le cooperative e gli organismi di stoccaggio nella supervisione IoT dei loro impianti. La nostra soluzione si adatta alle attrezzature esistenti senza necessità di sostituzione, con una connettività 4G ottimizzata per le zone rurali. Scopri le nostre soluzioni →

Risorse aggiuntive​

• Monitoraggio remoto dell'irrigazione — controllo e monitoraggio dei sistemi di irrigazione tramite IoT
• Connessione Internet per siti industriali isolati — connettività 4G per aziende agricole in zone rurali
• Monitoraggio delle attrezzature industriali — monitoraggio delle attrezzature agricole e di stoccaggio
• Connettività industriale — soluzioni di connettività robuste per le zone rurali
• Soluzioni industriali Eziwan — gamma di soluzioni IoT adatte ai settori primari

La presente guida pratica è destinata ai responsabili tecnici, ai direttori dei servizi idrici e fognari e ai direttori dei sistemi informativi degli enti locali — consorzi idrici, aziende municipalizzate, comunità di comuni — che gestiscono le reti di acqua potabile.

Situazione attuale: il parco impianti di telegestione idrica in Francia​

Un parco che invecchia​

La telegestione delle reti idriche in Francia si basa oggi in gran parte su apparecchiature installate tra il 2000 e il 2015. Le tecnologie prevalenti sono:

• Modem SOFREL S4W/S500: ampiamente utilizzati dai gestori delegati (Veolia, Suez, Saur) sulle reti idriche, questi modem GSM/GPRS utilizzano la rete 2G/EDGE, oggi in fase di disattivazione
• RTU Servelec (ex Sontay) e Lacroix Sofrel: gamma di RTU dedicata al settore idrico, utilizzata nelle stazioni di sollevamento e di trattamento
• Sistemi proprietari dei gestori in concessione: ogni gestore in concessione (DSP) ha implementato la propria infrastruttura (Veolia Hub Eau, Suez IntelliO) con protocolli proprietari che limitano la gestione in regime di servizio pubblico

La chiusura della rete 2G: un fattore scatenante della modernizzazione​

Orange ha annunciato ufficialmente la chiusura della rete 2G nel 2026 (dopo diversi rinvii). SFR ha già chiuso la propria rete 2G in diverse zone. Bouygues Telecom sta seguendo lo stesso percorso.

I modem SOFREL S4W e le altre RTU 2G/GPRS utilizzate nelle torri idriche, nelle stazioni di pompaggio e nelle stazioni di sollevamento non funzioneranno più dopo tali chiusure.

Si tratta di un'importante opportunità di modernizzazione verso soluzioni 4G LTE con una piattaforma cloud di monitoraggio centralizzato.

Architettura di supervisione moderna per una rete idrica potabile​

I siti tipici da monitorare​

Configurazione consigliata​

Migrazione dai sistemi esistenti​

Sostituzione di un modem SOFREL S4W​

Il SOFREL S4W è il modem più diffuso nelle reti idriche francesi. La migrazione verso l'Eziwan Gateway è stata progettata per essere non invasiva.

Fasi della migrazione:

1. Audit preliminare (1 ora da remoto): identificazione dei registri Modbus configurati sull’S4W, mappatura degli I/O utilizzati (ingressi digitali, ingressi analogici, uscite a relè), elenco degli attuali destinatari SMS
2. Consegna del Gateway preconfigurato: l’Eziwan Gateway viene consegnato con il vostro modello di configurazione (registri Modbus identici a quelli dell’S4W, stesse soglie di allarme, stessi destinatari SMS)
3. Sostituzione fisica (30-45 minuti per sito): il Gateway viene collegato allo stesso cablaggio RS-485. La SIM 4G viene inserita e attivata. La connessione al cloud viene stabilita automaticamente
4. Verifica: un tecnico Eziwan interviene da remoto per verificare la trasmissione dei dati e gli avvisi
5. Messa in servizio: il sito è visibile nella dashboard cloud con tutti i suoi dati storici (a partire dalla migrazione — i dati storici S4W non vengono trasferiti)

Compatibilità: L'Eziwan Gateway legge tutti i registri Modbus configurati sul vostro PLC (Schneider M340, Siemens S7-1200, Lacroix E30...). La migrazione non richiede alcuna modifica al PLC di campo.

Costo di migrazione: Il Gateway Eziwan è più economico di un SOFREL S4W nuovo e offre funzionalità più avanzate (VPN, multiprotocollo, OTA). Per una flotta di 50 stazioni, il ritorno sull'investimento rispetto all'acquisto di S4W nuovi è immediato.

Migrazione da un sistema in delega (fine del DSP)​

In caso di ritorno alla gestione diretta o di cambio di concessionario, l'ente locale spesso perde l'accesso al sistema di supervisione proprietario dell'operatore uscente. La transizione può comportare settimane o mesi senza supervisione centralizzata.

L'approccio di Eziwan alle transizioni DSP:

1. Implementazione anticipata: installare i gateway Eziwan 3-6 mesi prima della scadenza del contratto DSP, in parallelo al sistema esistente
2. Verifica parallela: confrontare i dati Eziwan con quelli dell’operatore uscente per verificarne la coerenza
3. Transizione senza intoppi: alla scadenza del contratto DSP, il sistema di supervisione Eziwan è già operativo e convalidato
4. Continuità storica: 3-6 mesi di dati storici già disponibili sulla piattaforma Eziwan

Conformità normativa​

Autocontrollo e obblighi dell'ARS​

Il decreto del 21 luglio 2015, che modifica il decreto del 2 maggio 2007, impone obblighi di autocontrollo per gli impianti di trattamento delle acque reflue (STEP) e per gli impianti di produzione di acqua potabile (UPEP):

Parametri da monitorare e archiviare (UPEP):

• Portata dell'acqua prodotta (m³/h e m³/giorno)
• Torbidità dell'acqua trattata (NTU) — soglia di allerta: > 1 NTU
• Contenuto di cloro residuo (mg/L) — soglia di allarme: < 0,1 mg/L
• pH (da 6,5 a 9,0)
• Conduttività (μS/cm)
• Temperatura (°C)

Requisiti di archiviazione:

• Conservazione per almeno 5 anni
• Data e ora UTC certificate
• Formato di esportazione compatibile con SANDRE per la trasmissione ai servizi statali
• Possibilità di accesso ai DDETSPP (ex DDASS) su richiesta

Come Eziwan soddisfa questi requisiti:

• Archiviazione per almeno 10 anni (oltre i 5 anni previsti dalla normativa)
• Data e ora UTC su ogni misurazione, con firma digitale
• Esportazione in formato CSV e JSON secondo lo standard SANDRE
• API di accesso per i servizi di controllo
• Report automatici giornalieri e settimanali configurabili

Direttiva NIS2: applicabilità all'acqua potabile​

Il recepimento della direttiva NIS2 in Francia (legge del 16 aprile 2024) classifica gli operatori del settore idrico in categorie in base alle loro dimensioni:

Soggetti chiave:

• Gestori di servizi idrici che riforniscono più di 50.000 persone OPPURE
• Fatturato superiore a 50 milioni di euro OPPURE
• Designati come OIV (Operatori di Importanza Vitale)

Soggetti rilevanti:

• Gestori di servizi idrici che riforniscono più di 10.000 persone OPPURE
• Fatturato superiore a 10 milioni di euro

Obblighi previsti dalla direttiva NIS2 relativi alla telegestione delle risorse idriche:

Caso pratico: consorzio idrico con 80 stazioni​

Contesto: Un consorzio intercomunale gestisce 80 stazioni di pompaggio (da 12 a 350 m³/h) e 6 serbatoi idrici in un’area rurale che comprende 45 comuni. Attrezzature esistenti: modem SOFREL S4W 2G, supervisione locale limitata, 3 tecnici.

Problemi:

• Il 40% delle stazioni è privo di allarme automatico (i guasti vengono segnalati tramite chiamate dei residenti)
• La rete 2G è in fase di disattivazione sul territorio
• Obbligo NIS2 (consorzio che serve più di 15.000 abitanti)
• Contratto di prestazione che impone un tasso di continuità del servizio > 99,5%

Implementazione Eziwan:

• 80 gateway Eziwan (1 per stazione) consegnati preconfigurati in 3 settimane
• Migrazione dagli S4W in 6 settimane (13 stazioni a settimana, 2 tecnici)
• Configurazione: da 8 a 24 registri Modbus per stazione, avvisi via SMS/e-mail
• Dashboard centralizzata: panoramica in tempo reale delle 80 stazioni, mappatura GIS

Risultati a 6 mesi:

• Interventi non programmati ridotti del 68% (da 240 a 77 interventi/anno)
• Rilevamento di una perdita significativa su una conduttura di mandata (portata notturna anomala rilevata automaticamente alle 2 del mattino, intervento alle 6)
• Conformità NIS2 documentata (audit esterno superato)
• Risparmio stimato: 95.000 € all’anno (spostamenti evitati + danni evitati)

Protocolli e apparecchiature compatibili​

Contatori dell'acqua​

Sonde di misurazione dell'acqua​

Controllori automatici per impianti idrici​

Calcolo del ROI per un ente locale​

Costi evitati grazie al monitoraggio IoT​

Interventi dei tecnici:

• Costo medio di un intervento non programmato: da 180 a 350 € (1 ora e 30 minuti andata e ritorno + diagnosi)
• Riduzione tipica con Eziwan: dal 60 al 75% degli interventi non programmati evitati
• Esempio: 80 stazioni, 3 tecnici: 240 interventi/anno → 77 interventi/anno = 163 interventi evitati × 250 € = 40.750 €/anno

Danni evitati (perdite, guasti, straripamenti):

• Perdita non rilevata sulla linea di mandata: da 5.000 a 50.000 m³ persi prima dell’individuazione manuale
• Costo per m³ di acqua prodotta: da 0,80 a 1,20 €
• Esempio: 1 perdita da 15.000 m³ evitata = da 12.000 a 18.000 € all’anno

Servizi di reperibilità:

• Riduzione degli interventi notturni di emergenza: da -40% a 60%
• Risparmio su indennità di reperibilità e ore di straordinario: da 10.000 a 25.000 € all'anno a seconda del parco veicoli

Conformità normativa:

• Evitare una diffida da parte dell'ARS a seguito del superamento di una soglia non rilevata
• Costo stimato di una non conformità documentata: da 15.000 a 50.000 € (interventi urgenti + audit esterno)

Esempio di calcolo del ROI per 80 stazioni​

ROI anno 1: 80.750 − 72.000 = +8.750 € già dal primo anno ROI a partire dal secondo anno: 80.750 − (14.400 + 9.600) = +56.750 € all'anno

Finanziamenti e aiuti disponibili​

FESR e stanziamenti regionali​

I progetti di ammodernamento della telegestione delle reti idriche potabili possono beneficiare di finanziamenti del FESR (Fondo europeo di sviluppo regionale) nell'ambito dei programmi operativi regionali 2021-2027, nell'asse "Transizione digitale dei servizi pubblici".

Agenzie per le risorse idriche​

Le 6 agenzie francesi per le risorse idriche (Artois-Picardie, Reno-Mosa, Senna-Normandia, Loira-Bretagna, Adour-Garonna, Rodano-Mediterraneo-Corsica) offrono incentivi per l'ammodernamento della gestione delle reti idriche. I criteri di ammissibilità comprendono la riduzione delle perdite (rendimento della rete), la conformità normativa e la transizione digitale.

Contattate la vostra agenzia idrica locale per conoscere i programmi in corso e le percentuali di finanziamento applicabili al vostro progetto.

Fondo di sostegno agli investimenti locali (DSIL) e DETR​

La DSIL e la DETR (Dotazione per le Attrezzature dei Territori Rurali) possono finanziare progetti digitali a favore degli enti locali rurali. I progetti di modernizzazione delle reti idriche tramite l'IoT rientrano negli obiettivi "servizi di prossimità" e "transizione digitale" di tali dotazioni.

Domande frequenti​

Il monitoraggio IoT è ammissibile al Piano “France Relance” o agli aiuti regionali? Sì, sono applicabili diverse misure. La DSIL (Dotazione di sostegno agli investimenti locali) finanzia i progetti digitali degli enti locali. La DETR (Dotazione per le infrastrutture dei territori rurali) copre i comuni rurali. Le agenzie per le risorse idriche (Senna-Normandia, Loira-Bretagna, ecc.) dispongono di programmi specifici per la riduzione delle perdite e l’automonitoraggio. In genere è richiesta una documentazione tecnica con un ROI quantificato (risparmi sulle perdite, costi evitati).

La migrazione da un sistema SOFREL esistente è invasiva? No. Il gateway Eziwan si collega in parallelo alle apparecchiature SOFREL esistenti tramite Modbus RTU/TCP o 4-20 mA. Non è necessario disattivare il sistema esistente durante la transizione. La migrazione può avvenire in più fasi: prima la lettura dei dati, poi il passaggio graduale delle stazioni pilota e infine la sostituzione completa secondo il vostro programma di rinnovo delle apparecchiature.

In che modo la soluzione soddisfa i requisiti della relazione di autocontrollo ARS? La piattaforma Eziwan consente di esportare i dati di autocontrollo nei formati richiesti (CSV, Excel) con i timestamp certificati. Gli indicatori di prestazione (tasso di perdite, portata nominale vs effettiva, anomalie di pressione) vengono calcolati automaticamente sulla base delle letture e possono essere estratti per i periodi richiesti dall’ARS.

Conclusioni e prossimi passi​

La modernizzazione del sistema di telegestione dell'acqua potabile non è più un'opzione per gli enti locali francesi. La chiusura della rete 2G, gli obblighi previsti dalla direttiva NIS2, i requisiti di automonitoraggio dell'ARS e la pressione sui costi di esercizio convergono nel rendere questo investimento imprescindibile.

La buona notizia: il ROI è rapido (in genere < 18 mesi), la migrazione dai sistemi esistenti (SOFREL, ecc.) è ben documentata e non invasiva, e le soluzioni moderne (gateway 4G + cloud) sono nettamente più economiche rispetto alle apparecchiature proprietarie di prima generazione.

I prossimi passi:

1. Audit del vostro parco attuale: inventario delle apparecchiature, identificazione dei modem 2G, mappatura dei controllori di campo
2. Simulazione del ROI: il nostro team può prepararvi un calcolo personalizzato basato sul vostro parco
3. Progetto pilota: avviare il progetto su 5-10 stazioni pilota per verificare la soluzione prima dell’implementazione su larga scala

Contatta il team Eziwan per un audit gratuito della tua infrastruttura di telegestione idrica.

Per approfondire​

• Blog: monitoraggio delle reti idriche e fognarie con 4G — feedback dal campo
• Blog: telelettura dei contatori da GPRS a 4G — guida pratica alla migrazione
• Blog: Modbus TCP vs RTU — guida completa per le reti idriche
• Blog: checklist NIS2 — 30 punti di controllo per gli enti locali
• Blog: SIM M2M IoT — confronto tra operatori per le reti rurali

Eziwan collabora con enti locali, consorzi idrici e aziende municipalizzate per l'ammodernamento dei loro sistemi di telegestione. Forniamo supporto nelle transizioni DSP e nelle migrazioni dai sistemi SOFREL, Lacroix e altri RTU per il settore idrico. Scopri la nostra soluzione per il settore idrico →

Risorse aggiuntive​

• Soluzione per l'acqua e la rete fognaria — monitoraggio IoT delle reti idriche potabili per gli enti locali
• Monitoraggio delle torri idriche — telegestione delle torri idriche e dei serbatoi degli enti locali
• Lettura remota wireless M-Bus — lettura automatica dei contatori dell’acqua via radio
• Monitoraggio serbatoi idrici — monitoraggio in tempo reale di livelli e pressioni
• Soluzione per stazioni di pompaggio — monitoraggio e controllo remoto delle stazioni di pompaggio

Questa guida mette a confronto in modo obiettivo le due architetture sulla base di 7 criteri chiave — costo totale, sicurezza, latenza, scalabilità, conformità, manutenibilità e resilienza — per aiutarvi a prendere la decisione giusta in base al vostro contesto industriale.

Cosa mettiamo a confronto​

SCADA on-premise (classico): Server fisici installati presso la vostra sede o nella vostra sala server. Software SCADA installato localmente (Wonderware InTouch/System Platform, Ignition, PCVue, WinCC). Cronologia dei dati su un server SQL locale. Accesso dalla rete locale (LAN) o tramite VPN per l’accesso remoto.

SCADA cloud / IIoT SaaS: Piattaforma ospitata nel cloud (AWS, Azure, GCP o cloud sovrano francese). Gateway industriali in loco che raccolgono i dati dal campo e li inviano al cloud. Dashboard accessibile da qualsiasi browser. Cronologia dei dati nel cloud. Esempi: Eziwan, Axonize, Samsara, Siemens MindSphere, AWS IoT SiteWise.

Criterio 1: Costo totale di proprietà (TCO su 3 anni)​

SCADA on-premise — TCO indicativo per 10 siti industriali​

SCADA cloud SaaS — TCO indicativo per 10 siti industriali​

Conclusione sul TCO: Il cloud SaaS è da 2 a 4 volte più conveniente su un arco di 3 anni per le implementazioni multisito. Il vantaggio aumenta con il numero di siti. Per un singolo sito con un sistema SCADA già ammortizzato, la soluzione on-premise può continuare a essere una valida opzione.

Criterio 2: Sicurezza​

Questo è spesso l'argomento principale dei sostenitori della soluzione on-premise. Analizziamo cosa c'è di vero in tutto ciò.

Cosa vale per l'on-premise:​

• Dati fisicamente nei vostri locali — nessun transito verso l'esterno
• Nessuna dipendenza da terzi per l'accesso ai dati
• Possibilità di isolamento dalla rete Internet (air gap)

Cosa si crede spesso a torto riguardo all'on-premise:​

• "On-premise = più sicuro" — falso nella maggior parte dei casi. Le PMI in genere non dispongono di un team dedicato alla sicurezza informatica. I loro server on-premise funzionano spesso su Windows Server 2012/2016 senza patch, senza monitoraggio degli accessi e senza sistemi di rilevamento delle intrusioni. Un fornitore di servizi cloud certificato ISO 27001 con un team di sicurezza dedicato è generalmente più sicuro di un server in una sala macchine non sorvegliata.
• "I miei dati non escono dallo stabilimento" — vero solo se avete effettivamente isolato il server SCADA. Se accedete al sistema SCADA da Internet (RDP, VPN), i dati transitano comunque.

Cosa offre il cloud:​

• Hosting certificato ISO 27001 con un team di sicurezza attivo 24 ore su 24, 7 giorni su 7
• Crittografia in transito e inattiva (TLS 1.3, AES-256)
• Aggiornamenti di sicurezza automatici — nessuna vulnerabilità CVE non corretta negli ultimi 3 anni
• Autenticazione MFA nativa su tutti gli accessi
• Log di audit completi e centralizzati

Quali sono i rischi effettivi del cloud:​

• Disponibilità di Internet — se la connessione a Internet viene interrotta, si perde l’accesso al sistema SCADA remoto (ma non il controllo locale, che rimane sui controllori)
• Conformità dei dati sovrani — se si trattano dati sensibili (OIV, dati personali), la scelta del provider di hosting cloud è fondamentale (Francia vs Stati Uniti)

Conclusione sulla sicurezza: A parità di livello di maturità, il cloud certificato ISO 27001 ospitato in Francia è generalmente più sicuro di una soluzione on-premise non gestita. Per gli OIV (Operatori di Importanza Vitale) o i settori altamente sensibili, si raccomanda il cloud sovrano francese (SecNumCloud certificato ANSSI).

Criterio 3: Latenza e tempo reale​

La verità sulla latenza nel cloud​

La latenza di andata e ritorno tra un gateway sul campo e un server cloud ospitato a Parigi è compresa tra 50 e 200 ms, a seconda della qualità della connessione 4G o in fibra ottica.

È accettabile per la vostra applicazione?

Regola d'oro: il controllo in tempo reale rimane SEMPRE sul PLC locale. Il cloud gestisce il monitoraggio, gli avvisi, la cronologia e la manutenzione remota. Questa separazione delle responsabilità è la chiave per un'architettura IIoT corretta.

Conclusione sulla latenza: La latenza nel cloud è perfettamente accettabile nel 95% dei casi di monitoraggio industriale. Solo il ciclo di controllo in tempo reale deve rimanere locale.

Criterio 4: Scalabilità​

On-premise: scalabilità difficile e costosa​

Passare da 10 a 50 siti monitorati in locale richiede:

• Server aggiuntivi (o potenziamento della memoria/dello spazio di archiviazione)
• Licenze aggiuntive (spesso proporzionali al numero di tag o connessioni)
• Intervento di un integratore per la configurazione
• Migrazione dei dati storici
• Test e convalida prima della messa in produzione

Tempi di consegna tipici: da 4 a 12 settimane. Costo marginale elevato.

Cloud: scalabilità quasi istantanea​

Aggiungere un nuovo sito nel cloud SaaS:

1. Ordinare un gateway (consegna in 5-7 giorni)
2. Installarlo e collegarlo alla rete OT del sito (30-60 minuti)
3. Configurare i punti dati dalla dashboard web
4. Il sito è visibile nella dashboard centralizzata — immediatamente

Tempi di consegna tipici: da 1 a 2 settimane (i tempi di consegna dipendono principalmente dalla disponibilità dei componenti). Costo marginale contenuto.

Verdetto sulla scalabilità: Il cloud vince a mani basse. Questo aspetto è particolarmente determinante per le implementazioni multisito o per gli integratori che gestiscono parchi che vanno da diverse decine a diverse centinaia di siti clienti.

Criterio 5: Conformità e normativa​

NIS2 (direttiva europea sulla sicurezza informatica)​

Per gli enti essenziali e importanti soggetti alla direttiva NIS2 (acqua, energia, settori industriali critici), i requisiti di sicurezza informatica sono gli stessi indipendentemente dall'architettura. La differenza sta nella capacità di dimostrare la conformità:

• On-premise: siete responsabili dell'intera catena (sistema operativo, applicazione, rete, accessi). L'audit NIS2 verificherà i vostri log, le vostre procedure di aggiornamento e la segmentazione della rete.
• Cloud certificato: il fornitore di servizi cloud certificato ISO 27001 copre una parte dei requisiti (infrastruttura, hosting). Rimanete responsabili della configurazione delle applicazioni e degli accessi degli utenti.

GDPR e dati personali​

Se il vostro sistema SCADA tratta dati personali (orari di presenza degli operatori, accessi biometrici), l’ubicazione dei dati è importante:

• Cloud UE (AWS Parigi, OVHCloud): conforme al GDPR se il contratto prevede le clausole DPA appropriate
• Cloud USA (senza SCC): non conforme per i dati personali dei cittadini europei
• On-premise in Francia: conforme per natura se gli accessi sono controllati

Settori regolamentati (farmaceutico, agroalimentare)​

Il 21 CFR Parte 11 della FDA (tracciabilità elettronica nel settore farmaceutico) e l’Allegato 11 delle GMP dell’UE sono compatibili con il cloud, a condizione che si scelga un fornitore in grado di fornire le certificazioni di convalida (IQ/OQ/PQ) richieste dai revisori.

Verdetto di conformità: Il cloud ospitato in Francia da un fornitore certificato ISO 27001 è conforme alla direttiva NIS2, al GDPR e alle principali normative di settore. Verificate le certificazioni del fornitore.

Criterio 6: Manutenibilità​

On-premise: il costo IT nascosto​

Le aziende spesso sottovalutano il carico di lavoro legato alla manutenzione di un sistema SCADA on-premise:

• Aggiornamenti del sistema operativo (patch mensili di Windows Server)
• Aggiornamenti antivirus (giornalieri)
• Gestione dei backup e test di ripristino
• Aggiornamenti del database SQL (PostgreSQL, MS SQL)
• Rinnovo dei certificati SSL
• Gestione delle licenze (rinnovo, audit Microsoft)
• Assistenza agli utenti interni

In pratica, un sistema SCADA on-premise richiede da 0,3 a 0,5 ETP IT nel corso del tempo (condivisione con altri sistemi).

Cloud: manutenzione in outsourcing​

Su una piattaforma cloud SaaS, il fornitore gestisce:

• L'intera infrastruttura (server, rete, archiviazione)
• Gli aggiornamenti di sicurezza (senza interruzioni del servizio)
• I backup (RTO/RPO garantiti contrattualmente)
• La scalabilità dell’infrastruttura in base al carico di lavoro

Il vostro team si occupa esclusivamente della manutenzione dei gateway sul campo (firmware OTA automatizzabile) e della configurazione delle applicazioni.

Conclusione sulla gestibilità: Il cloud riduce il carico operativo del 70-80%. Un fattore decisivo per le PMI che non dispongono di un team IT dedicato.

Criterio 7: Resilienza e disponibilità​

On-premise: una resilienza a doppio taglio​

Punti di forza:

• Funziona anche in assenza di connessione a Internet (monitoraggio locale continuo)
• Nessuna dipendenza da terze parti per l'accesso locale

Punti deboli:

• Guasto del server = interruzione totale del monitoraggio
• Richiede ridondanza hardware per garantire l'alta disponibilità (costo raddoppiato)
• Disaster recovery complesso (ricostruzione del server)
• SLA effettivo spesso mediocre (99% = 3,65 giorni di inattività all’anno)

Cloud: alta disponibilità fin dalla progettazione​

Le piattaforme cloud industriali affidabili garantiscono una disponibilità del 99,9% (SLA contrattuale = < 8,76 ore di inattività all'anno) o addirittura del 99,95%.

Architettura multi-AZ (multi-datacenter): il guasto di un datacenter non compromette il servizio. Il DR (Disaster Recovery) è automatico.

Rischio principale legato al cloud: se la connessione Internet/4G della sede viene interrotta, il gateway perde il collegamento con il cloud. I dati vengono memorizzati temporaneamente in locale (store-and-forward) e ritrasmessi al ripristino della connessione. Il monitoraggio remoto non è disponibile durante l'interruzione.

Risposta: per i siti critici, implementare una connessione di riserva (SIM 4G dual-operator con failover su fibra ottica, oppure VSAT satellitare come ultima risorsa).

Conclusione sulla resilienza: Il cloud offre una maggiore disponibilità della piattaforma. La soluzione on-premise è più resiliente per il monitoraggio locale senza dipendenza dalla rete. Una soluzione ibrida (controllo locale + monitoraggio cloud) offre il meglio di entrambe.

Architettura ibrida: il meglio dei due mondi​

La maggior parte delle nuove implementazioni industriali adotta un'architettura ibrida:

Vantaggi della soluzione ibrida:

• Il monitoraggio e gli allarmi critici rimangono locali (latenza zero)
• Il monitoraggio, la cronologia e l'accesso remoto sono nel cloud
• In caso di interruzione della connessione Internet, il processo continua (PLC) e i dati vengono memorizzati nel buffer (gateway)
• L'intelligenza edge (regole di automazione locali) riduce la dipendenza dal cloud

È proprio questa l'architettura che Eziwan implementa: un gateway industriale in ogni sede (edge) e una piattaforma cloud per il monitoraggio centralizzato.

Tabella riassuntiva​

Quando scegliere cosa?​

Scegliete il cloud SaaS se:​

• Gestite più siti (3+) e desiderate un monitoraggio centralizzato
• Non disponete di un team IT dedicato alla manutenzione dei server
• State implementando una nuova soluzione (greenfield) senza sistemi SCADA legacy
• Il vostro budget è limitato e cercate di ridurre al minimo le spese in conto capitale (capex)
• Avete bisogno di un accesso remoto di qualità per i vostri tecnici o subappaltatori

Scegliete la soluzione on-premise se:​

• Disponete di un sistema SCADA recente e già ammortizzato (Wonderware, Ignition)
• Siete un OIV e avete vincoli assoluti di isolamento di rete
• Disponete di un team IT interno in grado di gestire l’infrastruttura
• Il vostro sito è unico e non richiede una supervisione multisito
• I vostri vincoli di latenza sono estremi (tempo reale critico < 10 ms)

Scegliete la soluzione ibrida se:​

• Disponete di un sistema SCADA esistente che desiderate integrare con l'accesso remoto
• Volete ottenere il miglior ROI senza dover riprogettare la vostra architettura SCADA locale
• Il vostro processo richiede un controllo locale, ma desiderate la supervisione nel cloud
• Si tratta dello scenario più comune per i nuovi progetti IIoT

Conclusione​

Non esiste una risposta valida per tutti. La scelta dipende dal numero di siti, dal livello di maturità IT, dai vincoli normativi e dalle vostre ambizioni in termini di scalabilità.

Una cosa è certa: per le implementazioni multisito, il rapporto TCO pende nettamente a favore del cloud SaaS. E l'argomento della sicurezza regge solo se la vostra infrastruttura on-premise è gestita correttamente — cosa che raramente avviene nelle PMI prive di un team dedicato alla sicurezza informatica.

L'architettura ibrida edge + cloud, rappresentata da soluzioni come Eziwan, consente oggi di combinare il controllo locale (latenza zero, funzionamento offline) con la potenza del cloud (monitoraggio centralizzato, accesso remoto, cronologia illimitata) — senza dover scegliere.

Domande frequenti​

Un sistema SCADA cloud può funzionare in caso di interruzione della connessione a Internet? Con un'architettura ibrida (gateway edge + cloud), il processo industriale continua a funzionare (il PLC opera in modo autonomo) e i dati vengono memorizzati temporaneamente a livello locale dal gateway (store-and-forward). Il monitoraggio in tempo reale viene interrotto durante l’interruzione, ma i dati non vanno persi: vengono trasmessi non appena si ristabilisce la connessione. Per gli allarmi critici, configurare avvisi locali (relè, SMS dal gateway edge) che funzionano senza Internet.

Quali sistemi SCADA on-premise sono compatibili con un gateway IoT cloud? Wonderware AVEVA, Ignition (Inductive Automation), CODESYS, FactoryTalk (Rockwell), WinCC (Siemens), Citect: tutti si integrano con i gateway IoT cloud tramite OPC-UA, Modbus TCP o API REST. L'architettura ibrida consiste nel lasciare che il sistema SCADA on-premise gestisca il controllo locale e nell'aggiungere un gateway IoT cloud per il monitoraggio remoto e l'accesso remoto dei tecnici.

Il cloud SaaS è adatto alla protezione dei segreti industriali (formule, processi proprietari)? I dati critici relativi ai processi (ricette, parametri proprietari) possono essere esclusi dal trasferimento al cloud: si trasmettono solo i dati necessari per il monitoraggio (temperature, pressioni, stato dei macchinari). Per i dati più sensibili, l’hosting cloud in Francia (OVHCloud, Scaleway), soggetto alla legislazione francese, offre un livello di protezione aggiuntivo rispetto agli host statunitensi soggetti al CLOUD Act.

Quanto tempo richiede la migrazione da un sistema SCADA on-premise al cloud? Per un sito con un sistema SCADA esistente, l’implementazione di un livello cloud (accesso remoto, supervisione multisito) richiede da 1 a 4 settimane senza interferire con il sistema SCADA on-premise. Il sistema SCADA esistente rimane in funzione; il gateway IoT cloud viene aggiunto in parallelo. Una migrazione completa verso un sistema SCADA cloud (senza sistema SCADA on-premise) richiede da 2 a 6 mesi a seconda della complessità dell’installazione.

Per approfondire​

• Blog: monitoraggio industriale da remoto — guida completa 2026
• Blog: edge computing vs cloud industriale — quando utilizzare l'uno o l'altro?
• Blog: accesso remoto sicuro a PLC e SCADA — VPN e NIS2
• Blog: ROI dell’IoT industriale — calcolo e ottimizzazione
• Documentazione: architettura della piattaforma Eziwan

Siete indecisi tra la soluzione cloud e quella on-premise per il vostro progetto di monitoraggio? Contattate il nostro team per una consulenza personalizzata in base al vostro contesto industriale.

Risorse aggiuntive​

• SCADA cloud — piattaforma SCADA cloud per il monitoraggio industriale centralizzato
• Monitoraggio e teleassistenza industriale — soluzioni di monitoraggio remoto per l'industria
• Edge computing industriale — elaborazione locale dei dati per ridurre la dipendenza dal cloud
• Guida: architettura SCADA 4G — progettazione di un'architettura SCADA con connettività 4G

Questa guida illustra le principali minacce OT individuate nel periodo 2025-2026, i settori più esposti in Francia e le misure concrete per ridurre la vostra esposizione.

Perché i sistemi OT sono diventati l'obiettivo numero uno​

Per decenni, i sistemi industriali sono stati protetti dall'air gap: il loro totale isolamento fisico dalle reti IT e da Internet. Questa protezione naturale è venuta meno con la digitalizzazione industriale.

I fattori che hanno cambiato le carte in tavola:

• Convergenza IT/OT: i controllori logici programmabili (PLC), i sistemi SCADA e i sensori sono ormai collegati ai sistemi ERP, MES e al cloud per il monitoraggio remoto
• Durata di vita delle apparecchiature: un controllore logico programmabile (PLC) ha una durata di vita compresa tra i 15 e i 25 anni. I PLC installati tra il 2005 e il 2010 funzionano spesso con sistemi operativi obsoleti (Windows XP, CE) per i quali non viene più fornito supporto
• Protocolli privi di sicurezza nativa: Modbus, DNP3, Profibus e BACnet sono stati progettati per garantire l’affidabilità, non la sicurezza. Non supportano né l’autenticazione né la crittografia
• Risorse limitate: un PLC o un RTU non dispone della potenza di calcolo necessaria per eseguire un antivirus o moderni algoritmi crittografici
• Ciclo di aggiornamento lento: l’applicazione di una patch a un PLC può richiedere un fermo di produzione programmato — molte aziende rimandano gli aggiornamenti per anni

Conseguenza: i sistemi OT presentano una serie di vulnerabilità non corrette, protocolli non sicuri e una crescente esposizione di rete. Per un aggressore, si tratta di un bersaglio ideale.

Le 6 principali minacce OT nel 2026​

1. Ransomware industriale (ICS Ransomware)​

Il ransomware rimane la minaccia numero uno. Tuttavia, nel periodo 2025-2026, i gruppi di cybercriminali hanno sviluppato varianti specifiche per i sistemi industriali, in grado di:

• Crittografare i file di configurazione SCADA (progetti Wonderware, Ignition, Siemens TIA Portal)
• Modificare i parametri dei controllori per provocare un guasto fisico oltre alla crittografia
• Sfruttare le interfacce OPC-UA e Modbus TCP per diffondersi lateralmente nella rete OT

Gruppi attivi in Europa: LockBit 3.0, BlackCat/ALPHV, Play e Cl0p hanno tutti preso di mira le industrie francesi nel periodo 2024-2025. Il settore manifatturiero rappresenta il 28% delle vittime di ransomware in Europa.

Impatto medio di un ransomware industriale:

• Tempo di inattività della produzione: da 12 a 21 giorni
• Costo totale (riscatto + ripristino + mancato guadagno): da 2,5 a 8 milioni di euro per una PMI
• Tasso di pagamento del riscatto: il 42% delle aziende industriali paga (rispetto al 30% di tutti i settori)

Vettori di attacco più frequenti:

1. VPN senza MFA compromessa tramite credential stuffing
2. Accesso remoto da parte di fornitori di servizi di manutenzione (TeamViewer, AnyDesk) con credenziali condivise
3. Phishing mirato agli ingegneri che hanno accesso ai sistemi OT
4. Sfruttamento di vulnerabilità nelle interfacce uomo-macchina (HMI) esposte su Internet

2. Attacchi ai controllori logici programmabili (PLC/RTU)​

I controllori programmabili sono ormai presi di mira direttamente. Gli attacchi più sofisticati modificano la logica di programma (firmware o ladder logic) per:

• Provocare arresti di emergenza indesiderati
• Spingere le apparecchiature oltre i loro limiti di funzionamento normali
• Nascondere i valori reali agli operatori (manipolazione dei dati di supervisione)

Vulnerabilità ricorrenti individuate dall'ANSSI (2024-2025):

Misura preventiva fondamentale: isolare i controllori in VLAN dedicate, vietare le connessioni dirette dalla rete IT, utilizzare DMZ industriali conformi all'architettura Purdue.

3. Attacchi ai protocolli industriali privi di misure di sicurezza​

Modbus, DNP3, BACnet e Profinet sono stati progettati negli anni '70-'90 per garantire affidabilità e velocità. Nessuno di essi integra un sistema di autenticazione nativo. Qualsiasi dispositivo collegato alla stessa rete può:

• Leggere tutti i registri di un controllore Modbus senza alcuna restrizione
• Scrivere valori nelle bobine e nei registri senza autenticazione
• Inviare comandi DNP3 ad apparecchiature di distribuzione elettrica o idrica

Tipo di attacco: un aggressore che accede alla rete OT (tramite una VPN compromessa, una postazione di manutenzione infetta o un cavo collegato fisicamente) può inviare direttamente comandi Modbus al controllore di una pompa o di un compressore.

Misure di mitigazione:

• Implementare gateway industriali dotati di firewall applicativo che blocchino i comandi Modbus di scrittura non autorizzati (whitelist degli indirizzi IP di origine + codici funzione)
• Implementare l’autenticazione reciproca TLS sulle comunicazioni OPC-UA
• Monitorare le comunicazioni Modbus per rilevare codici funzione anomali (FC05/FC06/FC15/FC16 al di fuori delle finestre di manutenzione)

4. Attacchi alle interfacce HMI e SCADA​

Le interfacce uomo-macchina (IUM) e i server SCADA rappresentano spesso i punti deboli perché:

• Funzionano su Windows Server (2012, 2016 o addirittura 2008) raramente aggiornato
• Sono accessibili dalle reti IT per il monitoraggio della produzione
• Dispongono di server web per l'accesso remoto (spesso senza MFA)

Scenario di attacco comune:

1. L'autore dell'attacco compromette una postazione IT tramite phishing
2. Scansione della rete → rileva un server SCADA Wonderware sulla porta 80
3. Sfruttamento di una vulnerabilità web o delle credenziali predefinite
4. Accesso al sistema di supervisione della produzione → modifica delle soglie di allarme per mascherare un'anomalia
5. Distribuzione del ransomware dal sistema SCADA al resto della rete OT

Fact check 2025: La piattaforma Shodan elenca oltre 15.000 interfacce uomo-macchina (HMI) industriali accessibili direttamente da Internet in Francia, di cui circa 3.400 senza autenticazione configurata.

5. Attacchi alla catena di approvvigionamento (Supply Chain OT)​

La minaccia alla catena di approvvigionamento OT è in forte aumento. Consiste nel compromettere un dispositivo, un software o un fornitore prima che raggiunga la vittima finale.

Vettori identificati:

• Firmware dannoso presente in router industriali o gateway IoT importati (principalmente dall'Asia) che contengono backdoor
• Aggiornamenti software compromessi di software SCADA o librerie di protocolli industriali
• Fornitori di servizi di manutenzione che accedono alla rete OT con i propri strumenti (chiavette USB, computer portatili) da altre sedi dei clienti infette
• Integrazione di componenti di terze parti nei controllori logici (schede di comunicazione, moduli industriali) con firmware non verificato

Requisiti NIS2 direttamente correlati: l'articolo 21 della direttiva NIS2 impone esplicitamente la gestione della sicurezza della catena di approvvigionamento per i soggetti essenziali e importanti.

6. Minacce interne (Insider)​

Le minacce interne sono spesso sottovalutate nel settore. Esse riguardano:

• Dipendenti insoddisfatti con accesso ai sistemi di controllo
• Subappaltatori con accessi remoti permanenti non disattivati al termine dell'incarico
• Sabotaggio intenzionale di sistemi critici (casi documentati nel settore idrico ed energetico)

Statistiche 2024 (rapporto DBIR di Verizon): il 18% degli incidenti OT coinvolge un attore interno o un fornitore di fiducia compromesso.

Misura chiave: Accesso Zero Trust — ogni accesso deve essere autenticato (MFA), limitato nel tempo e sottoposto a controllo. Un subappaltatore non deve mai avere un accesso permanente illimitato.

I settori più esposti in Francia​

1. Acqua e servizi igienico-sanitari​

Il settore idrico è il bersaglio numero uno degli attacchi OT secondo l’ANSSI ed Europol. I motivi:

• Infrastruttura critica con impatto diretto sulla salute pubblica
• Sistemi obsoleti (molti RTU Sofrel risalenti agli anni 2000-2010)
• Personale spesso poco formato in materia di sicurezza informatica
• Bilanci IT/OT limitati negli enti locali

Caso di riferimento: Nel febbraio 2021, un hacker ha modificato il livello di soda caustica in un impianto di trattamento delle acque in Florida tramite un accesso TeamViewer non protetto. Un operatore attento ha individuato l’anomalia in tempo. Lo stesso tipo di attacco è possibile su qualsiasi sistema SCADA idrico privo di rigorosi controlli di accesso.

In Francia, la normativa NIS2 classifica i gestori dei servizi idrici che riforniscono più di 10.000 abitanti come entità essenziali, con obblighi più rigorosi in materia di sicurezza informatica a partire dal 17 ottobre 2024.

2. Energia e reti elettriche​

Gli attacchi alle infrastrutture energetiche (produzione, trasporto, distribuzione) sono triplicati in Europa dal 2022. Sono a rischio i gestori delle reti di distribuzione (GRD), i produttori di energia rinnovabile e gli stabilimenti industriali dotati di sottostazioni elettriche.

Protocolli interessati: IEC 60870-5-101/104, IEC 61850 GOOSE, DNP3 — tutti privi di autenticazione nativa nelle loro versioni di base.

3. Industria farmaceutica e agroalimentare​

Questi settori sono caratterizzati da una forte regolamentazione (FDA 21 CFR Parte 11, EU GMP Allegato 11) e dall'utilizzo di sistemi OT critici. La contaminazione di un processo di produzione causata dall'interferenza con i controllori automatici può avere gravi conseguenze per la salute.

Gli attacchi volti a interrompere la produzione (sabotaggio concorrenziale) si stanno moltiplicando in questi settori ad alto valore aggiunto.

4. Enti locali e città intelligenti​

Le città intelligenti installano su larga scala sensori, attuatori e gateway IoT, spesso con budget destinati alla sicurezza insufficienti. L'illuminazione pubblica, la gestione dei parcheggi e i sistemi di trasporto urbano sono ormai tutti connessi — e potenzialmente vulnerabili.

Le 10 misure prioritarie per garantire la sicurezza del vostro OT nel 2026​

Livello 1: Nozioni di base (da svolgere immediatamente)​

1. Inventario di tutte le risorse OT Non è possibile proteggere ciò che non si conosce. Mappate tutti i controllori, i sistemi SCADA, le interfacce HMI, i gateway e le apparecchiature di rete, indicando il sistema operativo, il firmware, i protocolli e le connessioni. Utilizzate strumenti di rilevamento passivo (Nozomi Networks, Claroty, Dragos) che non interferiscano con la rete OT.

2. Segmentazione della rete IT/OT Isolate la vostra rete OT dalla rete IT utilizzando un firewall industriale o una DMZ dedicata. L'architettura Purdue (livelli da 0 a 5) rimane il punto di riferimento. Come requisito minimo: vietare qualsiasi comunicazione diretta tra PC da ufficio e controllori di campo.

3. Eliminazione degli accessi remoti non sicuri Verificate tutti gli accessi remoti esistenti (VPN, TeamViewer, AnyDesk, RDP). Disattivate quelli che non sono strettamente necessari. Per gli accessi legittimi, implementate l'autenticazione a più fattori (MFA) e limitate le fasce orarie di accesso.

4. Modifica delle credenziali predefinite Tutte le apparecchiature (PLC, switch, HMI, router) fornite con credenziali predefinite (admin/admin, root/root) devono essere modificate al momento della prima messa in servizio. Documentate le credenziali in un archivio di password sicuro (Bitwarden, HashiCorp Vault).

5. Backup delle configurazioni dei PLC Esportate e salvate i progetti TIA Portal, Unity Pro e Studio 5000 in modalità offline, in una posizione isolata dalla rete OT. In caso di attacco ransomware, il ripristino da un backup integro deve poter avvenire nel giro di poche ore, non di settimane.

Livello 2: Rafforzamento (da pianificare su un periodo di 6-12 mesi)​

6. Autenticazione forte per gli accessi remoti Implementare una VPN industriale con MFA (TOTP o FIDO2) per tutti gli accessi remoti — tecnici interni, subappaltatori, integratori. Ogni sessione deve essere registrata (session recording) a fini di audit.

7. Monitoraggio dei comportamenti di rete OT (NDR) Implementate una sonda di monitoraggio passivo sulla vostra rete OT per rilevare anomalie di comunicazione: nuove apparecchiature, codici funzione Modbus insoliti, comunicazioni verso indirizzi IP sconosciuti, modifiche al firmware. Le soluzioni Nozomi Networks, Claroty e Dragos sono leader di mercato.

8. Gestione delle vulnerabilità OT Iscrivetevi alle newsletter sulla sicurezza dei vostri produttori (Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation Security Advisories). Valutate i CVE critici (CVSS ≥ 7,0) e pianificate l'applicazione delle patch durante le prossime finestre di manutenzione.

9. Piano di risposta agli incidenti OT Documentare il processo specifico di risposta agli incidenti OT: chi contattare (ANSSI se si tratta di un’entità NIS2), come isolare un segmento compromesso senza interrompere la produzione, procedure di ripristino dai backup. Testare il piano una volta all’anno tramite simulazione.

10. Formazione dei team (OT Security Awareness) Gli ingegneri dell'automazione non hanno generalmente ricevuto una formazione in materia di sicurezza informatica. Sessioni di 2-4 ore dedicate alle minacce specifiche dell'OT, al phishing, alla gestione delle chiavette USB e agli accessi remoti sicuri riducono significativamente il rischio interno.

In che modo Eziwan soddisfa i requisiti di sicurezza OT​

Il gateway e la piattaforma Eziwan sono stati progettati fin dall'inizio considerando la sicurezza OT come un requisito non funzionale critico.

Architettura Zero Trust:

• Tutte le comunicazioni gateway → cloud sono crittografate con TLS 1.3 con autenticazione reciproca tramite certificato X.509
• Ogni gateway dispone di un identificativo univoco e non modificabile, preconfigurato in fabbrica (Device Identity)
• Nessuna porta in entrata aperta sul gateway: le connessioni vengono avviate esclusivamente dall’OT verso il cloud (modello push)

Controllo granulare degli accessi remoti:

• VPN OpenVPN/IPSec con autenticazione a più fattori (MFA) obbligatoria per tutti gli accessi remoti
• Sessioni a tempo limitato (scadenza automatica configurabile: 1 ora, 4 ore, 24 ore)
• Registro di audit completo: chi si è connesso, da quale indirizzo IP, per quanto tempo, quali azioni sono state eseguite
• Accesso dei subappaltatori: restrizione in base all’indirizzo IP di origine, al dispositivo di destinazione e alla fascia oraria

Monitoraggio OT integrato:

• Rilevamento di anomalie nei valori Modbus (variazione fuori intervallo, valore bloccato, comunicazione interrotta)
• Avvisi in tempo reale via SMS/e-mail in caso di anomalie rilevate
• Cronologia completa dei valori per l'analisi post-incidente

Hosting sovrano:

• Infrastruttura ospitata in Francia (AWS Parigi eu-west-3), ISO 27001
• Dati non trasferiti al di fuori dell'UE
• Conformità al GDPR, alla direttiva NIS2 e ai requisiti dell'ANSSI

Lista di controllo per la sicurezza OT 2026​

Utilizzate questa checklist per valutare il vostro livello di maturità in materia di sicurezza informatica OT:

Governance

• Mappa aggiornata delle risorse OT (inventario completo)
• Politica di sicurezza OT formalizzata e approvata dalla direzione
• Responsabile della sicurezza informatica OT designato (o MSSP specializzato)
• Classificazione dei sistemi in base alla criticità (livelli di sicurezza IEC 62443)

Architettura di rete

• Segmentazione IT/OT con firewall/DMZ industriale
• VLAN dedicate per zona Purdue (livelli 0, 1, 2, 3)
• Nessuna apparecchiatura OT accessibile direttamente da Internet
• Nessuna connessione diretta tra postazioni IT d'ufficio e controllori di campo

Accessi e identità

• Rimozione delle credenziali predefinite su tutte le apparecchiature
• MFA implementato su tutti gli accessi remoti (VPN, RDP, SCADA web)
• Accessi dei subappaltatori limitati (durata, ambito, fascia oraria)
• Registro di audit degli accessi remoti archiviato per ≥ 1 anno

Manutenzione e aggiornamenti

• Processo di gestione delle vulnerabilità OT documentato
• Backup delle configurazioni dei controllori testati e archiviati fuori dalla rete
• Procedura di aggiornamento del firmware pianificata durante le finestre di manutenzione

Rilevamento e risposta

• Monitoraggio dei comportamenti di rete OT (NDR o SIEM OT)
• Piano di risposta agli incidenti OT documentato e testato
• Procedura di notifica all'ANSSI (obbligatoria per i soggetti NIS2)
• Contatti di emergenza per la sicurezza informatica identificati (CERT interno o esterno)

Domande frequenti — Sicurezza informatica OT e minacce nel settore industriale nel 2026​

Un ransomware che colpisce la rete IT può raggiungere i controllori OT?

Sì, se le reti OT e IT sono interconnesse senza una segmentazione rigorosa. È esattamente il vettore di diffusione di NotPetya (2017) e di numerosi incidenti industriali verificatisi da allora. Il ransomware crittografa i server IT, si diffonde tramite Active Directory e le condivisioni di rete e, se la rete OT si trova sulla stessa LAN o è accessibile tramite lo stesso dominio Windows, vengono colpite le postazioni di supervisione SCADA e, talvolta, i controllori logici programmabili (PLC).

I controllori Siemens o Schneider possono essere infettati direttamente da un malware?

I controllori logici industriali non si “infettano” nel senso classico del termine (non hanno un file system standard, né consentono l’esecuzione di codice arbitrario tramite i vettori usuali). Tuttavia, possono essere riprogrammati da remoto se si ottiene l’accesso (cfr. Stuxnet). Il rischio reale consiste più spesso nell’arresto o nella manipolazione dei controllori da parte di un operatore compromesso o tramite un accesso remoto non adeguatamente protetto, piuttosto che in un’infezione diretta del firmware.

Qual è l'obbligo di notifica all'ANSSI in caso di incidente OT ai sensi della direttiva NIS2?

Per i soggetti soggetti alla normativa NIS2 (soggetti essenziali e soggetti rilevanti), l'obbligo prevede: notifica preliminare entro 24 ore se l'incidente è suscettibile di avere un impatto significativo, relazione intermedia entro 72 ore, relazione finale entro un mese. La notifica all’ANSSI può essere effettuata tramite l’apposito modulo disponibile sul suo sito web. Il mancato rispetto di tali obblighi espone a sanzioni che possono arrivare fino a 10 milioni di euro o al 2% del fatturato globale.

Le soluzioni di segmentazione della rete OT sono molto costose per una PMI?

No. Una segmentazione di base (VLAN OT/IT su uno switch gestibile da 200-400 €, con regole restrittive tra le VLAN) è alla portata di qualsiasi PMI. Per un livello superiore, i firewall industriali compatti (Stormshield SNi40, Fortinet FortiGate Rugged) partono da 500-800 €. La segmentazione rappresenta la soluzione con il miglior rapporto costo/efficacia nella sicurezza informatica OT: contiene gli incidenti prima che si diffondano.

È necessario disattivare i protocolli non sicuri come Modbus TCP sulla rete OT?

Sulla rete OT interna, il protocollo Modbus TCP può rimanere attivo: la sua mancanza di autenticazione è accettabile in una rete fisicamente isolata e segmentata. L'errore critico consiste nell'esporre la porta Modbus (502) su Internet o sulla rete IT senza alcun controllo. La priorità è garantire che nessuna porta OT sia accessibile dall’esterno, non necessariamente sostituire Modbus con un protocollo più sicuro nel breve termine.

Conclusione​

La sicurezza informatica dei sistemi OT non è più un'opzione per le aziende industriali francesi. La direttiva NIS2, i requisiti della norma IEC 62443 e la realtà degli incidenti (ransomware, attacchi alle reti idriche, sabotaggi alle infrastrutture energetiche) rendono indispensabile la protezione dei sistemi OT.

La buona notizia: contrariamente a quanto pensano molti operatori del settore, non è necessario rifare tutto da capo per ottenere progressi significativi. Le 5 misure fondamentali presentate in questa guida — inventario, segmentazione, eliminazione degli accessi non sicuri, credenziali predefinite, backup — riducono dell’80% il rischio di incidenti gravi, con costi e complessità ragionevoli.

Il vostro prossimo passo: effettuate un audit OT della vostra infrastruttura (Eziwan offre un audit gratuito delle vostre connessioni remote) e individuate le 3 azioni prioritarie da attuare nei prossimi 30 giorni.

Articolo redatto dal team di Eziwan. Eziwan è un fornitore di gateway IIoT e di piattaforme di supervisione industriale per le PMI, gli enti locali e gli integratori di automazione francesi. Scopri il nostro approccio alla sicurezza OT →

Risorse aggiuntive​

• Sicurezza informatica industriale — panoramica delle soluzioni di protezione per le reti OT
• Sicurezza informatica degli accessi remoti OT — proteggere le connessioni remote agli ICS
• NIS2 per l'industria — obblighi normativi e sanzioni per le aziende industriali
• VPN industriale — protezione degli accessi remoti con crittografia avanzata

Tuttavia, la norma è considerata complessa e voluminosa. Questa guida pratica ne riassume i punti essenziali per le imprese francesi: cosa richiede concretamente la norma, come conformarsi ad essa e le priorità per il 2026.

Che cos'è la norma IEC 62443?​

La norma IEC 62443 (precedentemente ISA-99) è una famiglia di norme sviluppata dall'ISA (International Society of Automation) e pubblicata dall'IEC. Riguarda la sicurezza informatica dei sistemi di automazione e controllo industriale (IACS).

La struttura della norma​

La norma è suddivisa in 4 serie:

Per un'azienda francese che intenda conformarsi alla direttiva NIS2, le parti più rilevanti sono:

• IEC 62443-2-1: politiche e procedure di sicurezza
• IEC 62443-3-3: requisiti di sicurezza dei sistemi
• IEC 62443-4-2: requisiti dei componenti (per valutare le vostre apparecchiature)

I livelli di sicurezza (SL): capire i livelli di sicurezza​

Il concetto centrale della norma IEC 62443 è il Security Level, ovvero il livello di protezione richiesto in base alla criticità del sistema.

I 4 livelli​

Per la stragrande maggioranza delle aziende industriali francesi: il livello SL 2 è l'obiettivo appropriato. Il livello SL 3 è riservato agli operatori di importanza vitale (OIV) con sistemi altamente critici. Il livello SL 4 è destinato quasi esclusivamente alle infrastrutture militari e nucleari.

Come determinare lo SL necessario per il proprio sistema?​

La procedura si articola in 3 fasi:

1. Identificazione delle zone e dei condotti (IEC 62443-3-2)

Iniziate suddividendo i vostri sistemi OT in zone di sicurezza (Security Zones):

• Zona di produzione (controllori, sensori, interfacce uomo-macchina locali)
• Zona di supervisione (SCADA, server di archiviazione dati)
• Zona DMZ OT (interfaccia IT/OT)
• Zona di accesso remoto

Quindi identificare i canali (Conduits) — le vie di comunicazione tra le zone (VPN di accesso remoto, collegamenti SCADA, gateway IT/OT).

2. Valutare la criticità di ciascuna zona (CASC)

Per ogni area, valutate le conseguenze di una compromissione in base ai criteri CASC:

• Confidenzialità: i dati devono rimanere segreti?
• Integrazione: una modifica dei dati o dei comandi potrebbe causare danni?
• Disponibilità: un'interruzione del sistema causerebbe danni significativi?
• Sicurezza: un malfunzionamento potrebbe mettere a rischio delle vite umane?

3. Definire l'SL target per zona

Il livello di criticità valutato determina il livello di sicurezza (SL) target: un’area dotata di controllori di sicurezza (SIL) in un impianto SEVESO punterà all’SL 3, mentre un’area di supervisione di una stazione di pompaggio di acqua potabile punta generalmente all’SL 2.

I 7 requisiti fondamentali (Foundational Requirements) della norma IEC 62443-3-3​

La norma IEC 62443-3-3 definisce 7 requisiti fondamentali (FR) per i sistemi. Ciascun FR è suddiviso in requisiti dettagliati in base al livello SL.

FR 1 — Controllo dell'identificazione e dell'autenticazione​

Cosa significa in pratica:

• Ogni utente e ogni dispositivo deve essere identificato in modo univoco (non sono ammessi account condivisi)
• Le password predefinite dei dispositivi OT devono essere modificate
• Per SL 2: autenticazione a due fattori (MFA) per gli accessi remoti

App Eziwan: ogni tecnico dispone di una chiave VPN OpenVPN/IPSec individuale. L'autenticazione MFA è disponibile sulla piattaforma cloud.

FR 2 — Controllo dell'utilizzo​

Cosa significa:

• Ogni utente ha accesso solo alle risorse necessarie allo svolgimento delle proprie mansioni (principio del privilegio minimo)
• Le operazioni sulle apparecchiature critiche richiedono un'autorizzazione esplicita

Applicazione: il sistema RBAC di Eziwan consente di definire i diritti di accesso per sede, per apparecchiatura e per fascia oraria per ciascun tecnico.

FR 3 — Integrità dei dati​

Cosa significa:

• I dati trasmessi tra le apparecchiature non devono poter essere modificati durante il trasferimento
• L'integrità delle configurazioni dei controllori deve essere verificabile

Applicazione: tutte le comunicazioni Eziwan sono crittografate tramite OpenVPN (autenticazione + crittografia). Le configurazioni sono firmate digitalmente.

FR 4 — Riservatezza dei dati​

Cosa significa:

• I dati sensibili (ricette, parametri di produzione, dati personali) devono essere crittografati sia durante il trasferimento che quando sono archiviati

Applicazione: crittografia AES-256-GCM di tutte le comunicazioni; dati archiviati crittografati sull'infrastruttura cloud francese.

FR 5 — Flusso di dati limitato​

Cosa significa:

• Le comunicazioni tra le zone di sicurezza devono essere controllate e limitate al minimo necessario
• Nessuna comunicazione diretta tra l'area IT dell'ufficio e i controllori OT senza DMZ

Applicazione Eziwan: architettura zero-inbound-port — la rete OT non è mai esposta direttamente. Il traffico passa attraverso il cloud Eziwan, che funge da punto di controllo centralizzato.

FR 6 — Risposta agli eventi​

Cosa significa:

• Gli incidenti di sicurezza devono essere individuati, registrati e gestiti
• Per la direttiva NIS2: notifica obbligatoria entro 24 ore per i soggetti essenziali

Applicazione: registrazione completa di tutti gli eventi di sicurezza, avvisi configurabili in caso di anomalie di connessione, esportazione dei log per SIEM.

FR 7 — Disponibilità delle risorse​

Cosa significa:

• Il sistema deve rimanere disponibile anche in caso di tentativi di attacco (protezione contro gli attacchi DoS)
• Devono essere predisposti meccanismi di backup e ripristino

Applicazione: failover Dual SIM, infrastruttura cloud multi-AZ, backup automatici delle configurazioni dei gateway.

Il processo di conformità alla norma IEC 62443 in 6 fasi​

Ecco un approccio pragmatico per le aziende industriali francesi che devono conformarsi alla direttiva NIS2 facendo riferimento alla norma IEC 62443.

Fase 1: Inventario delle risorse OT (3-5 giorni)​

Elencate tutti i vostri sistemi OT:

• Controllori logici programmabili (PLC, DCS, RTU)
• Interfacce uomo-macchina (HMI) e postazioni operatore
• Server SCADA e historian
• Apparecchiature di rete OT (switch, router, firewall)
• Gateway e apparecchiature di connettività

Per ogni dispositivo: versione del firmware/software, connettività di rete, data dell'ultimo aggiornamento di sicurezza, accessi remoti esistenti.

Fase 2: Mappatura delle aree e delle condutture (2-3 giorni)​

Disegnate lo schema della rete OT attuale con le zone di sicurezza e i flussi di comunicazione. Identificate:

• Le interfacce IT/OT esistenti
• Gli accessi remoti (VPN, RDP, TeamViewer)
• Le apparecchiature con porte esposte su Internet (cercate i vostri indirizzi IP su Shodan)

Fase 3: Analisi semplificata dei rischi (1 settimana)​

Per ogni area, valutate:

• Criticità (impatto di una compromissione: produzione, sicurezza, ambiente)
• Minaccia (chi potrebbe voler attaccare il vostro settore?)
• Vulnerabilità (stato attuale della sicurezza dell'area)

Stabilite l'ordine di priorità delle aree da trattare per prime: elevata criticità + elevata vulnerabilità = priorità 1.

Fase 4: Definizione del livello SL target per zona​

In base all'analisi dei rischi:

• Aree di produzione standard → SL 2
• Aree con controllori di sicurezza SIL → SL 3
• Aree operative OT (postazioni di ingegneria) → da SL 1 a SL 2

Fase 5: Piano di risanamento (da attuare nell'arco di 6-18 mesi)​

Per ogni area il cui livello attuale è inferiore al livello di riferimento (SL), definire le misure correttive:

Azioni prioritarie SL 2:

1. Rimuovere tutte le password predefinite dalle apparecchiature OT
2. Sostituire gli accessi remoti non sicuri (RDP esposto, TeamViewer) con una VPN zero-trust
3. Implementare l'autenticazione MFA per tutti gli accessi remoti
4. Creare account nominativi (nessun account generico condiviso)
5. Attivare la registrazione degli accessi su tutte le apparecchiature che lo consentono
6. Segmentare la rete OT dalla rete IT degli uffici (DMZ o VLAN con ACL)

Azioni importanti SL 2: 7. Aggiornare il firmware delle apparecchiature OT (gateway, switch industriali) 8. Documentare le procedure di risposta agli incidenti 9. Formare i team di manutenzione sui rischi legati alla sicurezza informatica OT

Fase 6: Valutazione e miglioramento continuo​

La conformità alla norma IEC 62443 non è un progetto una tantum, ma un processo continuo. Pianificate:

• Revisione annuale dell'inventario e della mappatura
• Test di penetrazione annuale (o semestrale) degli accessi remoti
• Aggiornamento del piano di correzione dopo ogni incidente o evoluzione dell'infrastruttura

IEC 62443 e NIS2: cosa devono fare gli enti francesi​

La direttiva NIS2 (recepita in Francia con la legge dell'8 ottobre 2024) non cita esplicitamente la norma IEC 62443, ma le misure da essa previste corrispondono direttamente a quanto previsto da tale norma.

I soggetti interessati​

Settori essenziali: energia (elettricità, gas, petrolio), trasporti (aerei, ferroviari, marittimi, stradali), settore bancario, infrastrutture finanziarie, acqua (distribuzione, acque reflue), sanità, infrastrutture digitali.

Settori chiave: servizi postali, gestione dei rifiuti, prodotti chimici, settore alimentare, produzione industriale (dispositivi medici, apparecchiature elettroniche, meccanica), fornitori di servizi digitali.

Le misure di sicurezza informatica richieste (art. 21 NIS2)​

1. Politica di sicurezza dei sistemi informativi (IEC 62443-2-1)
2. Gestione degli incidenti: rilevamento, risposta, notifica entro 24 ore (IEC 62443-2-1, FR 6)
3. Continuità operativa: backup, piani di ripristino (IEC 62443-3-3 FR 7)
4. Sicurezza della catena di approvvigionamento: sicurezza dei subappaltatori con accesso OT (IEC 62443-2-4)
5. Sicurezza degli acquisti: valutazione della sicurezza prima dell’implementazione delle apparecchiature OT (IEC 62443-4-2)
6. Formazione e sensibilizzazione: tutto il personale con accesso ai sistemi OT
7. Crittografia e crittografia: comunicazioni crittografate, dati sensibili protetti
8. Controllo degli accessi: autenticazione forte, RBAC, registrazione degli eventi (IEC 62443-3-3 FR 1, FR 2)
9. Sicurezza delle risorse umane: verifica dei precedenti, procedure di uscita dall’azienda
10. Valutazione dei rischi: processo formale documentato (IEC 62443-3-2)

I 5 errori da evitare in un progetto IEC 62443​

Errore 1: Iniziare dalla documentazione prima di fare il punto della situazione​

Molte aziende commissionano politiche di sicurezza redatte prima ancora di aver effettuato un inventario effettivo. Il risultato: documenti teorici scollegati dalla realtà sul campo. Iniziate sempre dall’inventario e dalla mappatura.

Errore 2: Considerare la norma IEC 62443 come un progetto informatico​

La sicurezza OT presenta alcuni vincoli specifici: le apparecchiature non possono essere messe fuori servizio per gli aggiornamenti, i protocolli sono obsoleti (Modbus del 1979) e il personale è composto da tecnici di automazione, non da informatici. Coinvolgete i team di produzione sin dall’inizio.

Errore 3: Puntare al livello SL 3 o SL 4 senza una motivazione valida​

Gli SL 3 e SL 4 prevedono requisiti molto rigorosi (autenticazione forte sui controllori, crittografia di tutti i protocolli industriali, compreso Modbus) che spesso richiedono la sostituzione delle apparecchiature OT. Per la maggior parte delle aziende industriali, l'SL 2 rappresenta un obiettivo realistico e sufficiente.

Errore 4: Trascurare la sicurezza degli accessi di terze parti​

Gli incidenti OT più comuni riguardano gli accessi remoti da parte di subappaltatori addetti alla manutenzione. È necessario dare priorità alla sicurezza degli accessi di terze parti (account nominativi, autenticazione a più fattori, tracciabilità) prima di affrontare gli aspetti più tecnici.

Errore 5: Pensare che la conformità alla direttiva NIS2 equivalga alla conformità alla norma IEC 62443​

La normativa NIS2 impone misure di sicurezza ma non certifica la conformità alla norma IEC 62443. La certificazione IEC 62443 (da parte di un organismo accreditato) è distinta dalla conformità alla direttiva NIS2. Per la maggior parte delle aziende del settore manifatturiero, una conformità documentata alla norma IEC 62443 senza certificazione formale è sufficiente per soddisfare i requisiti della direttiva NIS2.

Domande frequenti​

È obbligatorio ottenere la certificazione IEC 62443 per essere conformi alla direttiva NIS2? No. La direttiva NIS2 impone misure tecniche e organizzative di sicurezza, ma non richiede una certificazione formale secondo la norma IEC 62443 (rilasciata da organismi accreditati come TÜV, Bureau Veritas, ecc.). D'altra parte, documentare che le vostre pratiche sono in linea con la norma IEC 62443 è un ottimo modo per dimostrare la vostra conformità alla direttiva NIS2 all'ANSSI.

Da quale parte della norma IEC 62443 deve partire una PMI industriale? Per una PMI, si consiglia di iniziare dalla norma IEC 62443-2-1 (politiche e procedure) e dalla norma IEC 62443-3-3 (requisiti di sistema per i livelli di sicurezza 1 e 2). Si tratta delle parti più direttamente applicabili e più richieste dai committenti. Le parti 4.x (componenti) interessano piuttosto i produttori di apparecchiature.

Che cos'è una zona di sicurezza (Security Zone) nella norma IEC 62443? Una zona di sicurezza è un gruppo di sistemi con lo stesso livello di sicurezza richiesto, separati dalle altre zone tramite condotti (canali di comunicazione controllati). Esempio: Zona 1 = controllori di produzione (SL2), Zona 2 = SCADA (SL2), Zona 3 = IT (SL1). Le comunicazioni tra le zone devono necessariamente passare attraverso un firewall o una DMZ controllata.

Come valutare il livello di sicurezza (SL) da fissare come obiettivo per il mio impianto? Il livello di sicurezza (SL) da raggiungere dipende dalle conseguenze di un incidente: SL1 per un rischio limitato (arresto temporaneo di un processo non critico), SL2 per un rischio significativo (impatto sulla produzione o sulla sicurezza delle persone), SL3 per i sistemi critici (energia, acqua, sanità). La maggior parte delle PMI industriali punta all’SL2 per i propri sistemi SCADA e all’SL1 per i sistemi di supporto.

La norma IEC 62443 riguarda la sicurezza degli accessi remoti tramite VPN? Sì. La norma IEC 62443-3-3 tratta esplicitamente l'autenticazione (SR 1.1, SR 1.2), la crittografia delle comunicazioni (SR 4.1), la gestione delle sessioni (SR 1.3) e la tracciabilità (SR 2.8). Una VPN OpenVPN/IPSec con autenticazione tramite certificato e registrazione soddisfa i requisiti dei Livelli di sicurezza 1 e 2 su questi punti.

Risorse aggiuntive​

• Guida: NIS2 per l'industria — obblighi, sanzioni, piano d'azione
• Blog: lista di controllo per la conformità NIS2 — 30 punti di verifica
• Blog: sicurezza informatica OT — minacce e incidenti nel 2026
• Blog: zero porte in entrata — architettura OT sicura
• Documentazione: sicurezza dell’accesso remoto Eziwan

Risorse aggiuntive​

• Sicurezza informatica industriale — soluzioni di protezione per reti OT e ICS
• NIS2 per l'industria — obblighi normativi e piano di conformità
• Sicurezza informatica per l'accesso remoto OT — proteggere gli accessi remoti ai controllori logici programmabili
• Accesso remoto industriale — architetture zero-trust conformi alla norma IEC 62443
• Guida alla sicurezza della rete OT — segmentazione, VPN e conformità NIS2

Questa guida propone un metodo strutturato per calcolare il ritorno sull'investimento di un progetto di monitoraggio IoT industriale, con esempi numerici tratti da implementazioni reali.

Perché il ROI dell'IoT viene spesso sottovalutato​

La maggior parte dei calcoli del ROI dell'IoT si concentra sui risparmi diretti e evidenti. Tuttavia, l'IoT industriale genera benefici in quattro categorie spesso sottovalutate:

1. Risparmi diretti: costi evitati (spostamenti, interventi di emergenza, guasti imprevisti)
2. Aumento della produttività: tempo liberato grazie all’automazione del monitoraggio
3. Riduzione dei rischi: costi degli incidenti evitati (penali contrattuali, sanzioni normative, danni alla reputazione)
4. Valore dei dati: ottimizzazioni rese possibili dai nuovi dati disponibili

I progetti che considerano solo la categoria 1 attribuiscono sistematicamente un ROI troppo basso all'IoT.

La formula del ROI dell'IoT industriale​

Il ROI viene calcolato su un determinato periodo (di solito 1, 2 o 3 anni):

ROI (%) = [(Utili totali - Costi totali) / Costi totali] × 100

Costi totali = Investimento iniziale + Costi ricorrenti

• Investimento iniziale: hardware (gateway, sensori), installazione, configurazione, formazione
• Costi ricorrenti: abbonamenti alla piattaforma, SIM M2M, manutenzione dell'hardware

Benefici totali = somma dei risparmi e dei guadagni nelle 4 categorie

Categoria 1: Risparmi diretti​

Riduzione degli spostamenti dei tecnici​

Spesso è la voce più importante e più facile da quantificare.

Costo effettivo di un intervento tecnico (Francia, 2026):

In che modo la supervisione IoT riduce gli spostamenti:

• Diagnosi a distanza: il tecnico individua la causa del problema prima di recarsi sul posto → porta con sé il ricambio giusto, evitando così due interventi
• Prevenzione dei falsi allarmi: senza supervisione, ogni allarme dell’operatore comporta un intervento. Con l’IoT, la dashboard distingue i guasti reali dai falsi allarmi
• Interventi programmati: gli avvisi predittivi consentono di raggruppare gli interventi in un sito in un’unica visita pianificata

Risparmi tipici riscontrati:

• Enti di gestione idrica: da 1,5 a 3 spostamenti evitati per stazione di pompaggio all'anno
• Industrie con più sedi: da 2 a 4 interventi di emergenza convertiti in manutenzione programmata per sede all'anno
• Parchi fotovoltaici: riduzione del 60-70% delle visite di manutenzione reattiva

Riduzione dei fermi non programmati​

Un guasto imprevisto costa in media da 3 a 5 volte di più rispetto a un intervento preventivo equivalente.

Costo di un fermo non programmato (esempio: PMI industriale):

• Perdite di produzione: da 500 a 5.000 € all’ora (a seconda del settore)
• Manodopera d’urgenza (+50% sulla tariffa di reperibilità): 500-1.500 €
• Ricambi urgenti (costo × 2 rispetto alle scorte normali): da +200 a 500 €
• Totale fermo di 4 ore per una PMI: da 2.500 a 22.000 €

Grazie al monitoraggio IoT e agli avvisi preventivi, gli indicatori di anomalie vengono rilevati prima del guasto: le vibrazioni aumentano progressivamente, la temperatura supera la soglia prestabilita, la corrente del motore registra un aumento anomalo. L'intervento viene pianificato durante un fermo programmato.

ROI della prevenzione: evitare da 1 a 2 fermi non programmati per sito all'anno è spesso sufficiente per ammortizzare l'investimento totale nell'IoT.

Categoria 2: Aumento della produttività​

Tempo dell'operatore risparmiato grazie all'automazione del monitoraggio​

Senza un sistema di monitoraggio IoT, gli operatori e i tecnici dedicano tempo a:

• Effettuare giri di controllo regolari
• Inserire manualmente i dati di lettura in fogli di calcolo
• Redigere rapporti sulle prestazioni
• Rispondere alle telefonate relative alla segnalazione di guasti

Stima del tempo risparmiato (per 20 apparecchiature monitorate):

14 ore/settimana × costo orario complessivo (60 €) = 840 €/settimana di risparmio in termini di produttività, ovvero 43.000 €/anno.

Riduzione dei tempi di diagnosi​

Grazie alla cronologia dei dati disponibile nel cloud, la diagnosi di un guasto richiede 10-15 minuti invece di 1-2 ore in loco. Il tecnico visualizza il grafico di andamento, individua l'anomalia e pianifica un intervento mirato.

Categoria 3: Riduzione dei rischi​

Conformità normativa evitata​

Per i settori soggetti alla direttiva NIS2 (acqua, energia, trasporti, sanità), le sanzioni per la mancata conformità possono arrivare fino al 2% del fatturato annuo globale per un’entità essenziale.

Il monitoraggio IoT, con registrazione degli accessi, tracciabilità degli interventi e report di audit automatici, riduce significativamente il rischio di non conformità.

Sanzioni per servizio evitato​

Per le aziende soggette a SLA (fornitori di servizi di manutenzione, gestori di reti), ogni ora di indisponibilità può comportare l'applicazione di penali contrattuali.

Esempio: un gestore di una rete idrica soggetto a una penale di 2.000 € per ogni ora di non conformità relativa alla pressione. 1 guasto rilevato con 4 ore di anticipo grazie all'IoT = 8.000 € di penali evitate.

Categoria 4: Valore dei dati​

Ottimizzazione del consumo energetico​

I dati sul consumo elettrico raccolti in tempo reale consentono di individuare i picchi di consumo superflui, le apparecchiature non ottimizzate e le opportunità di riduzione del carico.

Risparmi tipici: riduzione del 5-15% della bolletta elettrica per le apparecchiature monitorate.

Esempio concreto: una stazione di pompaggio con pompe che funzionano a piena potenza 24 ore su 24. L'analisi IoT rivela che la domanda notturna è inferiore del 40%. Riduzione della velocità delle pompe tramite un variatore di velocità (già presente) → risparmio del 22% sul consumo elettrico.

Decisioni basate sui dati vs intuizione​

Prima dell'IoT, le decisioni relative alla manutenzione si basavano sull'esperienza e sui dati cartacei. Dopo l'IoT, si basano su dati reali:

• Frequenza di manutenzione adeguata all'utilizzo effettivo (anziché a un calendario fisso)
• Definizione delle priorità di investimento basata sui dati relativi alle prestazioni effettive
• Dimostrazione quantificata dell'impatto dei miglioramenti realizzati

Esempi di calcolo del ROI per settore​

Servizio idrico — rete di 40 stazioni di pompaggio​

Investimento iniziale:

• 40 gateway IoT: 40 × 400 € = 16 000 €
• Installazione (0,5 giorni/tecnico/sito): 40 × 200 € = 8 000 €
• Totale: 24 000 €

Costi ricorrenti annuali:

• Abbonamenti alle piattaforme + SIM: 40 × 480 €/anno = 19.200 €/anno

Risparmi annuali:

• Spostamenti evitati (2/stazione/anno × 200 €): 40 × 400 € = 16 000 €
• Interventi di emergenza evitati (1/stazione/anno × 300 €): 40 × 300 € = 12 000 €
• Fermi macchina non programmati evitati (0,5/anno × 3 000 €): 20 × 3 000 € = 60 000 €
• Aumento della produttività degli operatori (5 ore/settimana liberate × 60 €): 15 600 €
• Risparmio totale: 103 600 €/anno

ROI anno 1: (103.600 - 24.000 - 19.200) / 43.200 = 140% Periodo di recupero dell'investimento: da 4 a 5 mesi

PMI industriale — 3 siti produttivi​

Investimento iniziale:

• 15 gateway (5 per sede): 15 × 400 € = 6.000 €
• Installazione e configurazione: 3.000 €
• Totale: 9.000 €

Costi ricorrenti annuali:

• Abbonamenti + SIM: 15 × 480 € = 7.200 €/anno

Risparmi annuali:

• Spostamenti tra sedi evitati: 24 spostamenti × 250 € = 6.000 €
• Fermi evitati (1,5/sede/anno × 8.000 €): 36.000 €
• Riduzione della manutenzione preventiva (20% degli interventi): 12.000 €
• Risparmio totale: 54.000 €/anno

ROI anno 1: (54.000 - 9.000 - 7.200) / 16.200 = 234% Periodo di recupero dell'investimento: 3 mesi

I fattori che massimizzano il ROI​

1. Iniziare dai siti e dalle attrezzature più critici​

Il ROI è massimo per le apparecchiature con un costo elevato in caso di guasto e per i siti più lontani (costi di spostamento elevati). Date la priorità a:

• Pompe critiche per l’approvvigionamento di acqua potabile
• Apparecchiature in produzione continua (costo di fermo/ora elevato)
• Siti situati a più di un'ora di viaggio dal tecnico di turno

2. Integrare il monitoraggio nei processi di manutenzione​

Un sistema IoT non integrato nei flussi di lavoro di manutenzione genera scarso valore. Il ROI raggiunge il massimo quando:

• Gli avvisi IoT generano automaticamente ordini di lavoro nel sistema di gestione della manutenzione (GMAO)
• I report IoT sostituiscono quelli manuali
• I tecnici utilizzano l'accesso remoto prima di ogni intervento in loco (per una diagnosi preliminare)

3. Misurare e ottimizzare continuamente​

Stabilite alcuni KPI di monitoraggio sin dall'inizio:

• Numero di interventi sul campo evitati (rispetto ai dati storici precedenti all'introduzione dell'IoT)
• MTTR (Mean Time To Repair): tempo medio di risoluzione degli incidenti
• OEE (Overall Equipment Effectiveness) per le linee di produzione
• Numero di fermi non pianificati

Effettuate un confronto trimestrale per individuare le opportunità di miglioramento.

Gli errori che riducono il ROI​

Sottovalutare i costi di implementazione iniziale​

Un'installazione approssimativa comporta costosi interventi di correzione. Prevedete dal 30 al 50% del costo dell'attrezzatura per l'installazione, la configurazione e la formazione.

Trascurare la gestione del cambiamento​

Per ottenere il massimo ritorno sull'investimento (ROI), è necessario che i team adottino effettivamente le nuove pratiche. Un tecnico che non utilizza l'accesso remoto prima di recarsi sul posto non risparmia nulla.

Scegliere una piattaforma non scalabile​

Il costo della migrazione da una piattaforma IoT a un'altra è spesso superiore al costo iniziale. Verificate la scalabilità, la disponibilità di API aperte e la affidabilità del fornitore prima di impegnarvi.

Conclusione​

Il ROI dell'IoT industriale raramente rappresenta il problema che si immagina: nella stragrande maggioranza delle implementazioni industriali, viene raggiunto in meno di 12 mesi, spesso in un periodo compreso tra i 3 e i 6 mesi.

La vera domanda non è «è redditizio?», ma «da dove cominciare?» La risposta: iniziate con 5-10 siti o impianti ad alta criticità, misurate il ROI effettivo nell’arco di 3 mesi, quindi procedete a una implementazione su larga scala basandovi su dati concreti.

Domande frequenti​

Come calcolare il ROI di un progetto IoT industriale in assenza di dati storici sui guasti? Utilizzate le stime di settore come punto di partenza: un guasto non pianificato costa in media dal 5 al 15% del valore annuale della produzione nel settore manifatturiero. Per gli enti di gestione delle risorse idriche, considerate da 2.500 a 5.000 € per ogni intervento di emergenza non pianificato. Affinate le stime con i vostri dati effettivi dopo 3 mesi di implementazione pilota.

Il ROI dell’IoT industriale è lo stesso per una PMI e per un grande gruppo? No. I grandi gruppi beneficiano di economie di scala sui gateway e sugli abbonamenti e dispongono di un numero maggiore di apparecchiature critiche: il ROI assoluto è più elevato. D'altra parte, il ROI relativo (% di risparmio rispetto al budget di manutenzione) è spesso migliore per le PMI, poiché non dispongono di risorse IT dedicate e risparmiano proporzionalmente di più automatizzando il monitoraggio.

È meglio calcolare il ROI prima o dopo aver avviato un progetto pilota? Entrambe le cose. Prima: un ROI stimato giustifica il budget del progetto pilota agli occhi della direzione. Dopo: il ROI misurato (con dati reali) giustifica l’implementazione completa e conferisce credibilità alle ipotesi iniziali. L’esperienza dimostra che il ROI reale è spesso superiore a quello stimato, poiché durante il progetto pilota emergono benefici inaspettati (maggiore visibilità, decisioni più rapide, ecc.).

Quali costi vanno tenuti in considerazione in un progetto IoT industriale? I costi tipicamente sottovalutati: installazione del cablaggio RS-485 (prevedere 200–500 € per sito), formazione del personale di manutenzione (minimo 2 giorni), configurazione SCADA (integrazione dei nuovi dati negli strumenti esistenti) e gestione del cambiamento (far adottare i nuovi strumenti dai tecnici sul campo).

Risorse per approfondire l'argomento​

• Blog: manutenzione predittiva IIoT — dai dati dei sensori all'allerta
• Blog: monitoraggio delle reti idriche e fognarie — 300 stazioni 4G
• Blog: monitoraggio industriale da remoto — guida completa 2026
• Blog: SCADA cloud vs on-premise — guida decisionale
• Blog: Zero-Touch Provisioning — implementare 50 router in 2 ore

Risorse aggiuntive​

• Calcolatore ROI Eziwan — stimare il ritorno sull'investimento del proprio progetto IoT industriale
• Guida al ROI dell'IoT industriale — metodologia e casi concreti di calcolo del ROI dell'IIoT
• Manutenzione predittiva IIoT — ridurre i costi di manutenzione grazie all’IoT predittivo
• Soluzioni industriali Eziwan — gamma completa di soluzioni per massimizzare il ROI industriale
• Monitoraggio delle apparecchiature industriali — supervisione delle risorse industriali per ottimizzare le prestazioni

Questa guida tratta l'argomento nella sua interezza: definizioni, architetture tecniche, scelta dei protocolli, sicurezza informatica e implementazione pratica per implementazioni da 1 a 1.000 siti.

Che cos'è la supervisione industriale a distanza?​

La supervisione industriale a distanza (o telesorveglianza industriale) indica l'insieme delle tecnologie che consentono di:

• Visualizzare lo stato delle apparecchiature industriali (macchine, controllori logici programmabili, sensori) da una postazione remota
• Ricevere avvisi in tempo reale in caso di anomalie, superamento delle soglie o guasti
• Intervenire da remoto sulle apparecchiature (modifica dei parametri, riavvio, riconfigurazione)
• Analizzare i dati storici per ottimizzare le prestazioni e pianificare preventivamente gli interventi di manutenzione

Si applica a tutti i settori: industria manifatturiera, acqua e servizi igienico-sanitari, energia, agricoltura, edilizia tecnica.

Supervisione vs SCADA vs IIoT: quali sono le differenze?​

Questi termini vengono spesso confusi. Ecco le differenze:

Nel 2026 i confini si assottigliano: le moderne piattaforme IIoT (tra cui Eziwan) offrono funzionalità SCADA basate su cloud, integrando al contempo i protocolli industriali tradizionali (Modbus, OPC-UA).

Le architetture di supervisione remota​

Architettura 1: supervisione centralizzata via cloud (consigliata)​

Vantaggi:

• Implementazione rapida, senza necessità di un'infrastruttura server in loco
• Accesso da qualsiasi browser, tablet o smartphone
• Scalabilità da 1 a migliaia di siti senza necessità di una riprogettazione dell'architettura
• Aggiornamenti centralizzati senza intervento sul posto

Casi d'uso tipici: enti gestori delle risorse idriche, reti di distribuzione dell'energia, parchi fotovoltaici, parchi di macchinari industriali dislocati in diverse aree geografiche.

Architettura 2: SCADA on-premise con accesso remoto tramite VPN​

Vantaggi:

• I dati rimangono nell'infrastruttura IT dell'azienda
• Compatibile con i sistemi SCADA esistenti (Wonderware, WinCC, Vijeo Citect)
• Controllo totale sull'hosting e sulla sicurezza

Casi d'uso tipici: grandi aziende industriali con sistemi SCADA già in uso, settori industriali soggetti a vincoli in materia di sovranità dei dati.

Architettura 3: edge computing + cloud ibrido​

Per i siti che generano grandi quantità di dati (linee di produzione, presse, macchine CNC), l'edge computing consente di elaborare localmente i dati critici e di inviare al cloud solo i dati sintetici.

I protocolli industriali per il monitoraggio remoto​

Modbus RTU/TCP — lo standard universale​

Modbus è il protocollo più diffuso nel settore industriale. Esiste in due varianti:

• Modbus RTU: su collegamento seriale RS-485. Fino a 32 dispositivi su 1.200 m di cavo. Velocità di trasmissione da 9.600 a 115.200 bps.
• Modbus TCP: incapsulamento Modbus su Ethernet/IP. Porta 502. Velocità limitata esclusivamente dalla rete.

Cosa è possibile monitorare tramite Modbus: tutti i moderni controllori logici programmabili (PLC) industriali (Siemens S7, Schneider Modicon, ABB, Allen Bradley), la stragrande maggioranza dei contatori di energia, dei variatori di velocità e dei sensori industriali.

Limitazione: solo architettura master/slave. Nessuna notifica di eventi: il master deve interrogare (poll) gli slave a intervalli regolari.

MQTT — il protocollo dell'IIoT​

MQTT (Message Queuing Telemetry Transport) è un protocollo publish/subscribe leggero progettato per connessioni a bassa larghezza di banda.

Punti di forza per il monitoraggio remoto:

• Connessione persistente: il client MQTT (gateway) si connette una volta al broker e mantiene la sessione
• QoS configurabile: consegna garantita dei messaggi critici (QoS 1 o 2)
• Topic gerarchici: usine/ligne1/pompe3/courant — struttura logica dei dati
• Last Will & Testament: notifica automatica in caso di disconnessione di un dispositivo

Integrazione cloud: MQTT è supportato in modo nativo da AWS IoT Core, Azure IoT Hub, Google Cloud IoT e HiveMQ.

OPC-UA — per ambienti SCADA particolarmente esigenti​

L'OPC-UA (Unified Architecture) è lo standard interoperabile dell'Industria 4.0.

Punti di forza:

• Modello informativo a oggetti (non solo registri numerici)
• Sicurezza integrata: autenticazione, crittografia, firma dei messaggi
• Compatibile con i principali sistemi SCADA (WinCC, FactoryTalk, Ignition)
• Standard per applicazioni MES ed ERP

Quando scegliere OPC-UA: integrazioni con sistemi SCADA esistenti, MES, ERP SAP. Ambienti in cui la semantica dei dati (non solo i valori grezzi) è importante.

La sicurezza informatica nella supervisione a distanza​

Il monitoraggio industriale da remoto rappresenta un importante vettore di attacco se non adeguatamente protetto. Nel periodo 2024-2025, si sono verificati diversi incidenti legati ad accessi remoti non protetti alle apparecchiature OT.

Le 5 regole d'oro della sicurezza informatica OT​

1. Nessuna porta in entrata aperta sulla rete industriale

L'architettura zero-inbound-port è il principio fondamentale: sono le apparecchiature industriali stesse ad avviare la connessione verso il cloud di supervisione. Nessuna porta RDP, VNC o Modbus è esposta direttamente su Internet.

2. VPN e crittografia obbligatorie

Tutte le comunicazioni tra i siti industriali e la piattaforma di supervisione devono essere crittografate. OpenVPN con crittografia AES-256-GCM è la raccomandazione 2026 per le nuove implementazioni.

3. Autenticazione forte per gli accessi remoti

Ogni tecnico che accede da remoto deve autenticarsi tramite una chiave crittografica personale (non una password condivisa). L'autenticazione a più fattori (MFA) è obbligatoria per i soggetti soggetti alla direttiva NIS2.

4. Principio del privilegio minimo

Un tecnico addetto alla manutenzione di un determinato PLC ha accesso solo a quel PLC, non all'intera rete OT. La segmentazione dettagliata degli accessi limita la diffusione in caso di compromissione.

5. Registro di audit completo

Tutte le connessioni remote, le modifiche alle impostazioni e gli interventi vengono registrati con data e ora, identità e indirizzo IP di origine. Questi registri sono richiesti dalla direttiva NIS2 per gli enti essenziali e importanti.

NIS2 e monitoraggio remoto​

La direttiva NIS2 (recepita nel diritto francese dall'ottobre 2024) impone alle entità essenziali e alle entità importanti misure specifiche in materia di accessi remoti:

• Controllo degli accessi basato sull'identità (nessun account condiviso)
• Crittografia delle comunicazioni
• Registrazione e monitoraggio degli accessi
• Gestione degli incidenti con notifica entro 24 ore (entità essenziali)

I settori interessati: acqua e servizi igienico-sanitari, energia, trasporti, sanità, gestione dei rifiuti, produzione industriale critica.

Implementazione pratica: da 1 a 1.000 siti​

Per un sito singolo (POC o progetto pilota)​

Materiale necessario:

• 1 gateway IoT con connessione 4G e interfacce RS-485
• Abbonamento SIM M2M (oppure utilizzare la propria SIM dell'operatore)
• Accesso alla piattaforma cloud di monitoraggio

Tempo di implementazione: da 2 a 4 ore per un tecnico (installazione dell'hardware + configurazione cloud + verifica dei dati Modbus).

Costo indicativo: 300-600 € di materiale + 30-80 € al mese di abbonamento alla piattaforma + SIM M2M.

Da 10 a 50 siti​

Su questa scala, lo Zero-Touch Provisioning (ZTP) diventa fondamentale per ridurre i costi di implementazione.

Processo ZTP Eziwan:

1. Si prepara una configurazione standard nel cloud (protocolli, avvisi, VPN)
2. Ogni gateway viene consegnato preconfigurato in fabbrica (o configurato da remoto)
3. In loco: collegamento all’alimentazione + SIM + RS-485 — il gateway si configura automaticamente
4. Meno di 30 minuti di intervento tecnico per ogni sede

Risparmio rispetto alla configurazione manuale: su 50 siti, lo ZTP consente in genere di risparmiare da 2 a 3 giorni-uomo di configurazione di rete.

Per oltre 100 siti (gestione della flotta)​

Per le grandi flotte, le funzionalità di gestione centralizzata assumono un’importanza fondamentale:

• Dashboard della flotta: panoramica della connettività e dello stato di ogni sito
• Avvisi aggregati: filtraggio dei falsi allarmi, escalation automatica
• Aggiornamenti firmware OTA: distribuzione degli aggiornamenti su tutta la flotta senza necessità di spostamenti
• Gestione delle SIM: consumo dati per sito, sostituzione della SIM con un clic
• Report automatizzati: disponibilità di rete, incidenti, interventi — per reportistica CSR o contrattuale

Esempi concreti di utilizzo​

Servizio idrico — rete di 80 stazioni di pompaggio​

Situazione precedente: visite settimanali di supervisione, 2-3 turni di reperibilità a settimana per interventi urgenti.

Soluzione implementata: 80 gateway 4G LTE con Modbus RTU, avvisi in tempo reale sui livelli e sui guasti delle pompe, accesso remoto dei tecnici tramite VPN OpenVPN/IPSec.

Risultati:

• Riduzione del 70% dei giri di ispezione (da settimanali a mensili per i controlli di routine)
• Individuazione dei guasti in meno di 30 secondi (rispetto alle 4-48 ore precedenti)
• ROI raggiunto in 4 mesi

Settore agroalimentare — 3 siti produttivi​

Situazione precedente: ogni sito disponeva di un proprio sistema SCADA locale, senza alcuna visibilità consolidata a livello di gruppo.

Soluzione implementata: 3 gateway IoT che consolidano i dati Modbus di ciascun sito in un'unica dashboard cloud. Accesso remoto per il team di manutenzione del gruppo.

Risultati:

• Un unico dashboard per i 3 siti (rispetto a 3 interfacce SCADA indipendenti)
• Tempi di risposta agli incidenti ridotti del 65%
• Accesso sicuro e tracciabile per i subappaltatori addetti alla manutenzione

Parco fotovoltaico — 15 impianti di produzione​

Situazione precedente: datalogger proprietari incompatibili tra i diversi produttori di inverter.

Soluzione implementata: gateway IoT con parser Modbus universale compatibile con i protocolli SunSpec, SMA, ABB e Fronius. Dashboard di monitoraggio delle prestazioni (kWh, indice di rendimento, disponibilità).

Risultati:

• Unificazione del monitoraggio in un'unica dashboard
• Rilevamento dei cali di prestazioni +3% → intervento preventivo pianificato
• Report automatici per gli investitori e il gestore di rete

Lista di controllo per l'implementazione del monitoraggio remoto​

Prima di avviare il vostro progetto di supervisione a distanza, verificate i seguenti punti:

Connettività​

• Copertura 4G LTE verificata in ogni sito (test degli operatori)
• Opzione Dual SIM valutata per i siti critici
• Stima del consumo di dati per sito (frequenza di polling Modbus × dimensione dei registri)

Apparecchiature sul campo​

• Elenco dei protocolli: Modbus RTU (RS-485), Modbus TCP o proprietario?
• Elenco delle variabili da monitorare per ciascuna apparecchiatura (registri Modbus)
• Alimentazione disponibile nell'armadio (24 V CC o 230 V CA)

Sicurezza informatica​

• Architettura "zero-inbound-port" adottata
• VPN OpenVPN/IPSec o IPSec in fase di pianificazione
• Politica di accesso per i tecnici definita (diritti, fasce orarie)
• NIS2 applicabile alla vostra organizzazione? (entità essenziali / importanti)

Piattaforma cloud​

• Hosting dei dati in Francia o nell'UE (GDPR)
• API disponibile per l'integrazione con sistemi SCADA/MES esistenti
• SLA di disponibilità della piattaforma (minimo 99,5%)

Conclusione​

Nel 2026 il monitoraggio industriale da remoto non sarà più un'opzione: la fine del GPRS 2G, la direttiva NIS2 e la pressione economica sui costi di manutenzione lo rendono indispensabile per tutte le aziende industriali con siti remoti.

La buona notizia: le soluzioni 4G LTE con Zero-Touch Provisioning consentono oggi di connettere un sito industriale in meno di un’ora, a meno di 50 € al mese, tutto compreso.

La chiave del successo sta nel scegliere fin dall'inizio un'architettura cloud-native sicura, anziché aggiungere la sicurezza come strato aggiuntivo su un'architettura non progettata a tale scopo.

Domande frequenti — Monitoraggio industriale da remoto​

Qual è la differenza tra SCADA e la supervisione IoT nel cloud?

Un sistema SCADA tradizionale è un sistema centralizzato (spesso on-premise) con client pesanti (software dedicati per PC), archiviazione storica locale e un'architettura a stella. La supervisione IoT su cloud è un'architettura distribuita: ogni sito invia i propri dati al cloud tramite il gateway, senza un server centrale in loco. Il cloud offre accesso multisito, funzionalità mobile e API REST per l’integrazione, mentre il sistema SCADA tradizionale richiede una VPN site-to-site e una licenza per ogni client. Entrambi possono coesistere tramite connettori OPC-UA o Modbus integrati con il sistema SCADA esistente.

Quante variabili è possibile monitorare contemporaneamente su 100 siti?

Non esiste un limite fisso dal lato cloud: le moderne piattaforme IIoT sono progettate per gestire milioni di punti di misura. Il limite pratico deriva dal gateway e dalla rete: un gateway standard raccoglie fino a 500 variabili Modbus per sito con un polling di 5 s, ovvero 6.000 valori al minuto per sito. Su 100 siti, si tratta di 600.000 valori al minuto — un volume gestibile se il cloud è dimensionato di conseguenza (serie temporali, partizionamento per sito).

La supervisione remota può funzionare se il PLC è in modalità STOP (arresto del programma)?

Sì, per il monitoraggio dello stato del PLC (CPU in STOP, ora dell'ultimo allarme, stato degli ingressi/uscite). No per la raccolta Modbus delle variabili di processo: il server Modbus TCP del PLC smette di rispondere in modalità STOP su alcuni modelli (l'S7-1200 in modalità STOP arresta MB_SERVER). Verificare il comportamento specifico del PLC in modalità STOP prima di fare affidamento sulla raccolta Modbus per rilevare gli arresti della CPU.

Qual è la latenza minima tra un cambiamento di stato sul controllore e la sua visualizzazione nel pannello di controllo?

Con un polling Modbus di 1 s e un cloud adeguatamente dimensionato, la latenza totale è in genere compresa tra 2 e 5 s (1 s di attesa per il polling + 1-2 s di transito 4G + 1-2 s di elaborazione nel cloud). In caso di allarmi critici (superamento della soglia), Eziwan può inviare notifiche via SMS/e-mail in meno di 10 s dal rilevamento del superamento. Per una reazione in tempo reale (< 100 ms), è necessaria una logica locale sul PLC o sul gateway — non sul cloud.

È possibile monitorare dispositivi non Ethernet (contatori RS-485, sensori 4-20 mA)?

Sì, tramite la porta RS-485 del gateway per il protocollo Modbus RTU e tramite gli ingressi analogici per i segnali 4-20 mA o 0-10 V. I sensori privi di protocollo digitale (semplici contatti a secco, interruttori di livello) si collegano agli ingressi digitali del gateway o di un modulo di espansione. L'obiettivo è quello di monitorare l'intero sito da un unico gateway, indipendentemente dall'eterogeneità delle apparecchiature.

Risorse aggiuntive​

• Guida: accesso remoto sicuro a PLC e SCADA — architettura VPN
• Guida: router industriale 4G LTE — migrazione dall'ADSL
• Guida: collegamento di un PLC Siemens S7 al cloud
• NIS2: obblighi concreti per le aziende industriali
• Documentazione: supervisione multisito Eziwan
• Blog: ROI dell’IoT industriale — calcolo e ottimizzazione

Risorse aggiuntive​

• Supervisione e teleassistenza industriale — soluzioni di supervisione e teleassistenza per l'industria
• Monitoraggio delle apparecchiature industriali — monitorare le vostre apparecchiature industriali in tempo reale
• SCADA cloud — piattaforma SCADA cloud per il monitoraggio multisito
• Telediagnostica industriale — diagnostica remota dei vostri impianti industriali
• Guida: monitoraggio di siti isolati — monitorare siti senza connessione via cavo
• Data logger industriale cloud — registrazione e archiviazione dei dati di processo

Questo articolo chiarisce le loro differenze fondamentali, i loro punti di forza e i loro limiti, e offre una guida decisionale per scegliere il protocollo più adatto al proprio caso d'uso.

Prima di tutto, capire: protocolli di natura diversa​

Prima di procedere al confronto, è necessario comprendere che Modbus, MQTT e OPC-UA non operano allo stesso livello:

Modbus è un protocollo di lettura dei dati: consente di interrogare un dispositivo per leggerne i registri (misure, stati). Si tratta di un protocollo di campo, master/slave, progettato per l'acquisizione di dati da dispositivi industriali.

MQTT è un protocollo di messaggistica: consente di pubblicare e sottoscrivere flussi di dati tramite un broker centralizzato. Si tratta di un protocollo di trasporto dei messaggi, non di acquisizione diretta da un dispositivo.

OPC-UA è un'architettura di servizi: integra l'acquisizione dei dati, l'accesso al modello di dati, la sicurezza, gli allarmi e la cronologia in un unico standard industriale unificato. È la soluzione più completa — e la più complessa.

In pratica: La maggior parte delle moderne architetture IoT industriali utilizza tutte e tre. Modbus per leggere i dispositivi di campo. MQTT per trasmettere i dati al cloud. OPC-UA per l'interoperabilità tra sistemi complessi.

Modbus RTU e Modbus TCP​

Che cos'è Modbus?​

Modbus è stato creato nel 1979 da Modicon (oggi Schneider Electric). È il protocollo industriale più antico ancora in uso — e di gran lunga il più diffuso nel settore industriale francese.

Modbus RTU funziona su una connessione seriale RS-485 (o RS-232). È un protocollo asincrono, master/slave, con una topologia a bus lineare (multidrop). Su un unico bus RS-485 possono essere collegati fino a 247 slave.

Modbus TCP è il protocollo Modbus incapsulato in pacchetti TCP/IP. Funziona su Ethernet, porta 502. Mantiene il modello master/slave ma consente topologie di rete arbitrarie (a stella, ad albero). Non vi è alcun limite rigido al numero di slave a livello di rete.

Cosa permette di leggere Modbus​

Modbus espone 4 tipi di dati:

• Coils (0x): uscite digitali in lettura/scrittura (booleani)
• Discrete Inputs (1x): ingressi digitali di sola lettura (booleani)
• Input Registers (3x): registri a 16 bit di sola lettura (misure dei sensori)
• Holding Registers (4x): registri a 16 bit di lettura/scrittura (setpoint, parametri)

Per leggere un valore di temperatura da un sensore: il master invia una richiesta "leggi i registri da 3x01 a 3x02", lo slave risponde con i due registri contenenti il valore (in genere un numero in virgola mobile a 32 bit distribuito su due registri contigui).

Punti di forza di Modbus​

Universalità assoluta: Se disponete di un'apparecchiatura industriale dotata di una porta RS-485 o di una porta Ethernet e non sapete quale protocollo utilizzi, provate innanzitutto con Modbus. È molto probabile che supporti Modbus.

Semplice: Il protocollo è semplice: registri numerati, funzioni standard di lettura/scrittura. Qualsiasi sviluppatore può implementare un client Modbus in poche ore.

Resilienza: Nessuna dipendenza da un broker o da un server centrale. Il master interroga direttamente ogni slave. Un guasto del master non influisce sui rapporti tra gli slave.

Maturità: 45 anni di diffusione industriale. Le librerie Modbus sono disponibili in tutti i linguaggi di programmazione (Python, C, Java, JavaScript...).

Limiti di Modbus​

Architettura esclusivamente pull: Il master deve interrogare in modo proattivo ogni slave. I dispositivi non inviano dati spontaneamente. Su un bus con 50 slave interrogati ogni secondo, la frequenza effettiva per slave può scendere a 20 secondi.

Assenza di sicurezza nativa: Modbus RTU e Modbus TCP non dispongono di alcun meccanismo di autenticazione né di crittografia. Qualsiasi dispositivo presente sulla rete può leggere o scrivere nei registri di un’apparecchiatura Modbus esposta. La sicurezza deve essere garantita a livello di rete (VPN, segmentazione).

Nessun rilevamento automatico: Non esiste un meccanismo di rilevamento dei dispositivi Modbus su un bus. È necessario conoscere l'indirizzo slave e gli indirizzi dei registri di ciascun dispositivo.

Nessuna denominazione semantica: Il registro 40001 non indica cosa contiene — occorre consultare la documentazione del produttore per sapere che si tratta della "temperatura dell'acqua in ingresso". Nessuna autodescrizione.

Quando utilizzare Modbus​

• Lettura dei dati dalle apparecchiature sul campo (contatori di energia, sensori di pressione, variatori, controllori PLC)
• Reti di campo esistenti con cablaggio RS-485 già installato
• Progetti con apparecchiature eterogenee di diversi produttori (Modbus è il protocollo più universale)
• Budget limitati o team privi di competenze specialistiche

MQTT (Message Queuing Telemetry Transport)​

Che cos'è MQTT?​

MQTT è stato creato nel 1999 da IBM per la telemetria su collegamenti satellitari a bassa velocità. È stato standardizzato da OASIS nel 2014 (MQTT 3.1.1) e nel 2019 (MQTT 5.0).

MQTT è un protocollo publish/subscribe: i publisher inviano messaggi su determinati topic, mentre i subscriber ricevono i messaggi relativi ai topic a cui sono iscritti. Un broker MQTT centrale si occupa di instradare i messaggi tra publisher e subscriber.

Architettura MQTT​

Il broker è il cuore dell'architettura MQTT. I client (publisher e subscriber) si connettono al broker: non comunicano mai direttamente tra loro.

Punti di forza di MQTT​

Architettura push: Gli editori inviano i dati quando hanno qualcosa da comunicare. Nessun polling: l'abbonato riceve i dati immediatamente al momento della pubblicazione. Latenza tipica: 10-50 ms end-to-end.

Leggerezza: Il protocollo è stato progettato per dispositivi con risorse limitate (microcontrollori, modem 2G). Un messaggio MQTT può occupare solo 2 byte (header minimo). Molto efficiente in termini di larghezza di banda.

QoS configurabile: Tre livelli di qualità del servizio: QoS 0 (al massimo una volta), QoS 1 (almeno una volta), QoS 2 (esattamente una volta). Per le applicazioni critiche, il QoS 2 garantisce la consegna esattamente una volta.

Interoperabilità cloud: Tutti i principali provider cloud (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) mettono a disposizione un broker MQTT nativo. MQTT è il protocollo di fatto per le architetture IoT cloud.

TLS nativo: MQTT supporta nativamente TLS 1.3. La sicurezza è integrata nel protocollo, non è un'aggiunta.

Limiti di MQTT​

Non è possibile leggere direttamente i dispositivi: un dispositivo Modbus RTU non supporta nativamente il protocollo MQTT. È necessario un gateway o un passerella che legga i dati Modbus e li pubblichi in formato MQTT. Ecco perché Modbus e MQTT vengono spesso utilizzati insieme nelle architetture IoT industriali.

Dipendenza dal broker: Se il broker MQTT smette di funzionare, l'intera architettura di messaggistica crolla. La resilienza del broker è fondamentale. I broker gestiti (AWS IoT, HiveMQ Cloud) sono molto affidabili, ma creano una dipendenza da un servizio esterno.

Mancanza di un modello di dati standardizzato: MQTT non definisce né il formato dei messaggi né la struttura degli argomenti. Ogni implementazione è libera, il che compromette l'interoperabilità. Due sistemi MQTT di produttori diversi non comunicano necessariamente tra loro senza un adeguamento.

Nessuna richiesta/risposta nativa: MQTT è orientato agli eventi unidirezionali. Per implementare un modello richiesta/risposta (ad es.: richiedere un parametro a un dispositivo), è necessario utilizzare MQTT 5.0 con argomenti di risposta correlati — è possibile, ma più complesso.

Quando utilizzare MQTT​

• Trasferimento dei dati dal campo al cloud (Modbus → Gateway → MQTT → Cloud)
• Architetture basate sugli eventi in cui i dati cambiano in modo irregolare
• Implementazioni IoT embedded su microcontrollori o dispositivi con risorse limitate
• Integrazione con broker cloud nativi (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

Che cos'è l'OPC-UA?​

L'OPC-UA (IEC 62541) è stato sviluppato dalla OPC Foundation a partire dal 2006 come successore dell'OPC Classic (basato su COM/DCOM di Windows). Si tratta dello standard industriale più ambizioso: combina acquisizione dati, modello semantico, sicurezza, cronologia, allarmi e accesso ai metodi in un unico protocollo.

OPC-UA è oggi il protocollo preferito dai produttori di controllori per le architetture Industry 4.0: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation — tutti supportano OPC-UA in modo nativo già da 5 a 10 anni.

Punti di forza dell'OPC-UA​

Modello di dati semantico: A differenza di Modbus (registri numerati e anonimi), OPC-UA espone un albero di oggetti denominati e tipizzati. Il nodo "ns=2;i=1001" può essere denominato "Macchina1/MotorePrincipale/TemperaturaCuscinetto" con metadati (unità, intervallo, descrizione). L'autodescrizione è nativa.

Sicurezza integrata: autenticazione, autorizzazione, crittografia, integrità dei messaggi — tutto è integrato nel protocollo. OPC-UA supporta diversi profili di sicurezza (None, Sign, SignAndEncrypt) con algoritmi moderni (AES-256, RSA-2048+).

Pubblica/Sottoscrivi tramite OPC-UA PubSub (2017): OPC-UA può ora funzionare in modalità di pubblicazione asincrona (push), non solo in modalità richiesta/risposta (pull). È in grado di pubblicare su broker MQTT, rendendo OPC-UA e MQTT complementari anziché concorrenti.

Accesso ai metodi: OPC-UA consente di richiamare metodi sulle apparecchiature — non solo di leggere i valori. L'azionamento di una valvola, il comando di avvio di un motore — tutto è modellato come un oggetto OPC-UA.

Semantica e interoperabilità: Le "Companion Specifications" OPC-UA definiscono modelli standardizzati per settore: OPC-UA for Plastics, for Robotics, for PackML (imballaggio), for Mining... Un software SCADA compatibile con OPC-UA for PackML può connettersi a qualsiasi linea di confezionamento conforme, senza necessità di configurazioni specifiche.

Limiti dell'OPC-UA​

Complessità: OPC-UA è il protocollo più complesso da implementare e configurare. Le specifiche superano le 1000 pagine. La curva di apprendimento è notevole per i team che non hanno esperienza pregressa con OPC-UA.

Risorse richieste: Un server OPC-UA completo richiede più risorse rispetto a uno slave Modbus. I PLC di vecchia generazione o i microcontrollori con risorse limitate non sono in grado di supportare uno stack OPC-UA completo (esistono tuttavia profili "nano" più leggeri).

Non universalmente diffuso sul campo: Le apparecchiature più vecchie (precedenti al 2010-2015) non supportano OPC-UA. In un parco industriale eterogeneo, si incontreranno molte più apparecchiature Modbus che OPC-UA tra le apparecchiature di campo esistenti.

Overhead di rete: I messaggi OPC-UA sono più voluminosi rispetto a quelli Modbus (XML o binari, a seconda del protocollo di trasporto). Su connessioni 4G a bassa velocità, questo può rappresentare un fattore determinante.

Quando utilizzare OPC-UA​

• Controllori Siemens S7-1200/1500 di ultima generazione con TIA Portal (OPC-UA nativo)
• Architetture Industry 4.0 con interoperabilità SCADA/MES/ERP
• Progetti che richiedono un elevato livello di sicurezza e tracciabilità degli accessi
• Ambienti multiconstruttore con necessità di interoperabilità semantica

Guida alla scelta: quale combinazione scegliere per il tuo progetto?​

Architettura tipica di un sistema IoT industriale semplice​

Utilizzo: Monitoraggio dei processi, avvisi, cronologia. L'80% dei progetti IoT industriali francesi rientra in questo schema.

Architettura con bus di integrazione cloud​

Utilizzo: Progetti con più utenti dei dati (SCADA + ERP + BI). MQTT come bus di integrazione.

Architettura Industria 4.0 con OPC-UA​

Utilizzo: Impianti dotati di controllori logici programmabili di ultima generazione, progetti Industry 4.0, integrazione MES.

Matrice decisionale​

Come Eziwan gestisce i tre protocolli​

Il gateway Eziwan è indipendente dai protocolli utilizzati sul campo:

• Modbus RTU: porta RS-485 nativa, modalità master, fino a 247 slave per bus, polling configurabile da 1 s a 15 min
• Modbus TCP: client Modbus TCP, connessioni simultanee a più server Modbus
• MQTT: publisher MQTT (pubblicazione dei dati raccolti), possibilità di fungere da subscriber per i comandi
• OPC-UA: client OPC-UA (lettura dei nodi, sottoscrizione alle variazioni di valore) — disponibile su richiesta per le implementazioni OPC-UA

Per quanto riguarda il cloud, i dati vengono normalizzati internamente e resi disponibili tramite:

• API REST (JSON) per le applicazioni cloud
• Webhooks per gli eventi in tempo reale
• MQTT in uscita per le integrazioni tramite bus

È possibile combinare Modbus RTU sui dispositivi di campo e MQTT verso il proprio cloud AWS/Azure senza modificare nulla: il gateway si occupa della conversione.

Conclusione​

Nel 2026, alla domanda “Modbus, MQTT o OPC-UA?” la risposta è generalmente “tutti e tre insieme”:

• Modbus per leggere le vostre apparecchiature di campo (è il linguaggio che utilizzano)
• MQTT per trasferire i dati verso il cloud e distribuirli a diverse applicazioni
• OPC-UA se disponete di controllori di ultima generazione Siemens/Rockwell/Beckhoff e avete bisogno di interoperabilità SCADA/MES

Non si tratta di una competizione, ma di un'architettura a livelli. La scelta non è "quale protocollo", bensì "quale protocollo a quale livello per quale apparecchiatura".

Domande frequenti — Modbus, MQTT e OPC-UA​

È possibile utilizzare Modbus e MQTT contemporaneamente sullo stesso gateway?

Sì, ed è l'architettura più diffusa nell'IIoT. Il gateway raccoglie i dati dai controllori via Modbus TCP o RTU (livello di campo) e li pubblica tramite MQTT verso il cloud (livello di trasporto). Modbus si ferma al gateway: non viene mai esposto su Internet. MQTT subentra per il trasporto verso il cloud, con TLS 1.3 e autenticazione.

OPC-UA può sostituire Modbus sui controllori esistenti (S7-1200, M340)?

Sui Siemens S7-1200, il server OPC-UA è disponibile solo a partire dal firmware V4.4 e richiede una configurazione esplicita in TIA Portal. Sui modelli S7-1500, è integrato di serie a partire dal firmware V2.0. Sui controllori Schneider M340, OPC-UA non è integrato di serie: è necessario un modulo aggiuntivo. In pratica, per i sistemi esistenti, Modbus TCP rimane la soluzione universale; OPC-UA è indicato principalmente per i nuovi progetti con controllori di ultima generazione.

MQTT con QoS 0 vs QoS 1 vs QoS 2 — quale scegliere per il monitoraggio industriale?

Per il monitoraggio dei dati di processo (temperature, pressioni), il QoS 1 (At Least Once) rappresenta il giusto compromesso: la consegna è garantita anche dopo la riconnessione, con il rischio di qualche duplicato (accettabile per i dati di monitoraggio). Il QoS 2 (Exactly Once) è più oneroso a causa dello scambio di conferme e raramente necessario per le misurazioni. Il QoS 0 (At Most Once) è adatto per dati molto frequenti (> 1/s) in cui è accettabile una perdita occasionale.

È sufficiente un broker MQTT pubblico (HiveMQ, EMQX cloud) per il settore industriale?

Per progetti pilota o applicazioni non critiche, sì. Ma per una produzione soggetta a vincoli di riservatezza (dati di processo, identificativi delle apparecchiature), è preferibile un broker privato ospitato in Francia. I dati MQTT che transitano attraverso broker pubblici statunitensi sono potenzialmente soggetti al CLOUD Act — da valutare in base alla sensibilità dei dati e al settore di attività.

OPC-UA influisce sulle prestazioni del PLC rispetto a Modbus?

OPC-UA richiede notevoli risorse in più in termini di CPU e memoria rispetto a Modbus TCP. Su un S7-1500 con CPU 1511, con un server OPC-UA attivo e 50 connessioni client, il tempo di ciclo può aumentare dal 5 al 15%. Su un S7-1200, le risorse sono più limitate: verificare sistematicamente l’impatto con il programma di produzione completo prima di implementare OPC-UA in produzione.

Per approfondire​

• Blog: Modbus TCP vs RTU — quale protocollo scegliere?
• Blog: OPC-UA, MQTT, Modbus — come scegliere il proprio gateway industriale
• Blog: guida completa a OPC-UA per l’industria
• Blog: MQTT, RS485, Modbus — i protocolli IoT industriali spiegati
• Documentazione: configurazione Modbus sul gateway Eziwan

Risorse aggiuntive​

• Protocolli industriali — confronto completo tra Modbus, MQTT, OPC UA e DNP3
• Modbus RTU verso il cloud — collegare le vostre apparecchiature RS-485 Modbus RTU al cloud
• OPC UA verso MQTT — pubblicare dati OPC UA su un broker MQTT
• RS-485 Modbus 4G — trasmissione dei dati RS-485 Modbus tramite rete 4G
• Gateway IIoT — soluzioni di gateway IIoT per l’industria
• Guida: Modbus verso il cloud — guida completa per l’invio dei dati Modbus

Questa guida descrive i 9 criteri che consentono di distinguere un gateway realmente adatto agli ambienti industriali da un prodotto di consumo mal ricondizionato. È rivolta ai responsabili della manutenzione, agli esperti di automazione e ai responsabili IT del settore industriale che hanno in programma un progetto di connessione o di supervisione.

Criterio 1: Protocolli industriali supportati in modo nativo​

Questo è il criterio fondamentale. Se il vostro gateway non “parla” il protocollo delle vostre apparecchiature, tutti gli altri criteri diventano secondari.

I protocolli indispensabili in Francia nel 2026​

Modbus RTU (RS-485) — Lo standard di riferimento nel settore industriale francese. Contatori di energia, controllori HVAC, sensori di misura, convertitori di frequenza: se la vostra apparecchiatura dispone di una porta seriale RS-485, probabilmente comunica tramite Modbus RTU. Qualsiasi gateway industriale che si rispetti deve supportarlo in modo nativo.

Modbus TCP (Ethernet) — La versione di rete di Modbus. PLC recenti, gateway Modbus-Ethernet, apparecchiature con interfaccia RJ45. Da verificare: il gateway supporta il ruolo di master Modbus (polling attivo) o solo quello di server (passivo)?

MQTT — Il protocollo di messaggistica IoT per eccellenza. Utilizzato per pubblicare dati su broker cloud (AWS IoT, Azure IoT Hub, MQTT Mosquitto locale). Indispensabile per le architetture cloud-native.

OPC-UA — Standard industriale IEC 62541, adottato da Siemens, Rockwell e Beckhoff per i controllori di ultima generazione. Se il vostro sistema informativo comprende PLC Siemens S7-1500/1200 o una versione recente di TIA Portal, verificate la compatibilità con OPC-UA.

Protocolli specifici:

• DNP3: reti elettriche, acqua potabile, gas (Francia, Nord America)
• IEC 61850: stazioni di trasformazione ad alta tensione
• M-Bus: contatori di calore, acqua, gas (edifici, reti di teleriscaldamento)
• BACnet: HVAC e gestione tecnica degli edifici (GTB)

Lista di controllo dei protocolli:

• Modbus RTU (RS-485) in modalità master
• Modbus TCP in modalità master
• MQTT con TLS 1.2/1.3
• Protocolli specifici del proprio settore

Criterio 2: Connettività di rete e ridondanza​

4G LTE: lo standard attuale​

Nel 2026, un gateway industriale dovrà essere dotato almeno di un modulo 4G LTE Cat-M1/Cat-4. La rete 4G copre il 97% del territorio francese in termini di popolazione ed è sufficiente per il 95% delle applicazioni IoT industriali (monitoraggio in tempo reale, avvisi, accesso remoto).

Aspetti da tenere in considerazione:

• Il modulo 4G è integrato (SIM M2M interna) o esterno (chiavetta USB)?
• Il modulo esterno rappresenta un'ulteriore fonte di guasti e di cattiva gestione termica
• Alcuni gateway riportano la dicitura "compatibile con 4G" ma richiedono un modem esterno: prestare attenzione

Dual SIM: la vera ridondanza di rete​

Una sola SIM = un solo operatore = un unico punto di vulnerabilità. In alcune aree industriali (zone con copertura parziale, gallerie, aree con scarsa copertura), un operatore potrebbe perdere il segnale mentre l'altro lo mantiene.

La funzione Dual SIM, con due schede SIM di due operatori diversi e commutazione automatica, è la soluzione ideale per le applicazioni critiche. Eziwan integra nativamente la funzione Dual SIM.

Domande da porre:

• Il gateway supporta due SIM contemporaneamente?
• Il passaggio da una SIM all'altra avviene automaticamente (senza intervento umano)?
• Il tempo di passaggio è accettabile per la vostra applicazione (obiettivo: meno di 30 secondi)?

Connessione via cavo come soluzione di backup​

Per le sedi in cui sono disponibili la fibra ottica o la rete Ethernet, un gateway dotato di porta Ethernet WAN consente di utilizzare la fibra ottica come connessione principale e il 4G come backup. Entrambe le connessioni devono essere gestite contemporaneamente con un failover automatico e trasparente.

Criterio 3: Sicurezza e architettura Zero Trust​

La sicurezza informatica dei gateway IoT industriali è diventata un requisito imprescindibile, un’evoluzione accelerata dalla direttiva NIS2, che ora copre un ampio spettro di aziende industriali.

Cosa bisogna verificare​

Architettura "solo in uscita": Il gateway deve stabilire esclusivamente connessioni in uscita. Nessuna porta in entrata deve essere aperta sulla rete OT. Ciò elimina la superficie di attacco accessibile da Internet. Si tratta dell'architettura Zero Trust: "Non fidarsi mai, verificare sempre".

Protocollo VPN: OpenVPN è oggi il punto di riferimento: robusto, ampiamente testato, supera i firewall tramite TCP 443 e si autentica tramite certificato X.509 (crittografia AES-256-GCM). IPSec (IKEv2) rimane una valida opzione per gli ambienti regolamentati secondo lo standard FIPS 140-2.

Crittografia dei dati in transito: TLS 1.3 come requisito minimo per le comunicazioni cloud. Verificare che il gateway non comunichi in chiaro con un broker MQTT non crittografato.

Autenticazione: Chiavi crittografiche per dispositivo, revocabili singolarmente. Evitate i gateway con password amministratore condivisa tra tutti i dispositivi.

Aggiornamento sicuro del firmware (OTA): I gateway non aggiornati diventano vettori di attacco. Verificate che il gateway supporti gli aggiornamenti OTA firmati crittograficamente.

NIS2 e responsabilità​

A partire da ottobre 2024, la direttiva NIS2 impone alle entità essenziali e significative di gestire la sicurezza della propria catena di approvvigionamento digitale, compresi i gateway IoT. Un gateway che apre porte in entrata sulla rete OT o che comunica in chiaro costituisce una non conformità alla direttiva NIS2.

Criterio 4: Robustezza negli ambienti industriali​

Un gateway "industriale" deve essere in grado di resistere alle condizioni reali degli ambienti industriali. Ecco le certificazioni e le specifiche da verificare:

Temperatura di funzionamento​

Un gateway IT standard funziona a temperature comprese tra 0 °C e +40 °C. Un vero gateway industriale funziona in genere a temperature comprese tra -20 °C e +70 °C.

Grado di protezione IP​

IP20: Protezione minima, utilizzo esclusivo all’interno di un armadio chiuso in un locale pulito.
IP40: Protezione contro corpi solidi di dimensioni superiori a 1 mm. Armadio tecnico standard.
IP65: A prova di polvere e getti d’acqua. Per ambienti polverosi (settore agroalimentare, edilizia, esterni sotto copertura).
IP67: Immersione temporanea fino a 1 metro. Per ambienti molto umidi.
IP68: Immersione prolungata. Raramente necessaria ma utile per le apparecchiature interrate.

Vibrazioni e urti​

Per le applicazioni su veicoli industriali, gru a ponte, compressori o ambienti soggetti a vibrazioni: verificare la conformità alla norma EN 61131-2 o IEC 60068 per le prove meccaniche.

Montaggio su guida DIN​

Per l'installazione in un quadro elettrico, il montaggio su guida DIN da 35 mm è lo standard del settore. Evitate i gateway che richiedono viti da fissaggio a parete o un montaggio su rack da 19" non standard per le installazioni industriali.

Certificazioni normative​

CE (obbligatorio nell'UE): La marcatura CE è obbligatoria per tutte le apparecchiature elettroniche vendute in Europa.
ATEX (zone a rischio di esplosione): Per impianti chimici e petroliferi con atmosfere potenzialmente esplosive. Zona ATEX 1/2 o zona 21/22 a seconda dell’applicazione.
EN 61131-2: Norma specifica per le apparecchiature utilizzate con controllori logici programmabili (PLC).

Criterio 5: Zero Touch Provisioning (ZTP)​

Lo ZTP è un criterio spesso sottovalutato, soprattutto quando si implementano diverse decine o centinaia di gateway.

Senza ZTP: Ogni gateway deve essere configurato manualmente prima dell'implementazione. Un tecnico deve collegarsi all'interfaccia locale, inserire l'indirizzo IP del server cloud, le credenziali, i parametri di rete... Per 50 sedi, si tratta di 50 interventi di almeno 30 minuti ciascuno = 25 ore di lavoro tecnico, più gli spostamenti.

Con ZTP: Il gateway si connette automaticamente al cloud di gestione al primo avvio (tramite una SIM M2M preconfigurata). Scarica la configurazione dal server ed è operativo in meno di 5 minuti senza alcun intervento locale.

Domande da porre al fornitore:

• Lo ZTP è davvero "zero touch" o richiede comunque una configurazione iniziale?
• La SIM M2M è preconfigurata con i parametri del server cloud?
• In caso di problemi di provisioning, come viene effettuata la diagnosi da remoto?

Criterio 6: Edge computing e logica locale​

I gateway più avanzati dispongono di una potenza di calcolo tale da consentire l'esecuzione della logica a livello locale, senza dipendere dal cloud:

Aggregazione locale: Calcolare medie, valori minimi/massimi e somme su un determinato periodo (ad es.: energia consumata in kWh all'ora) prima di inviare i dati al cloud. Riduce la larghezza di banda necessaria.

Avvisi locali: Attivare un allarme locale (relè, cicalino, SMS diretto) senza passare dal cloud. Utile in caso di interruzione della rete: il gateway continua a monitorare e a inviare avvisi a livello locale.

Filtraggio dei dati: inviare solo i dati che hanno subito una variazione superiore a una soglia prestabilita. Riduce drasticamente i costi dei dati mobili nei siti con un numero elevato di pagine.

Script di logica: Sui gateway avanzati (Eziwan, alcuni modelli Teltonika), è possibile eseguire localmente script Python o JavaScript per gestioni logiche aziendali complesse.

Criterio 7: Gestione e supervisione da una console centralizzata​

Per i progetti con più sedi (a partire da 3-4 sedi), la console di gestione centralizzata rappresenta un importante fattore di differenziazione:

Pannello di controllo della flotta: Panoramica in tempo reale dello stato di tutti i gateway (connessi/disconnessi, livello del segnale, avvisi attivi).

Aggiornamenti firmware da remoto: distribuire un aggiornamento di sicurezza su 50 gateway con pochi clic, senza doversi recare sul posto.

Configurazione remota: modificare una soglia di allarme, aggiungere un nuovo sensore, modificare un parametro di rete — il tutto dalla console web.

Avvisi relativi alla flotta: Ricevere una notifica quando un gateway perde la connessione o quando un dispositivo supera una soglia.

Criterio 8: Hosting dei dati e sovranità digitale​

Questo criterio è diventato strategico per le imprese francesi con l'entrata in vigore della direttiva NIS2 e i requisiti in materia di sovranità digitale.

Domande chiave:

• Dove vengono ospitati i dati raccolti dal gateway?
• La società che lo gestisce è soggetta al CLOUD Act statunitense (filiale di un’azienda statunitense)?
• I dati possono essere sequestrati da autorità straniere senza preavviso?
• Il fornitore è certificato ISO 27001? SecNumCloud (ANSSI) per gli OIV?

Per gli enti essenziali ai sensi della direttiva NIS2 e gli operatori di importanza vitale, l'hosting dei dati in Francia presso un fornitore non soggetto a leggi extraterritoriali straniere è di fatto un requisito imprescindibile.

Criterio 9: Assistenza tecnica e supporto​

Anche il miglior gateway del mondo non serve a nulla senza un servizio di assistenza in grado di rispondere alle vostre domande tecniche in tempo reale:

SLA di assistenza: Qual è il tempo di risposta garantito? 4 ore, 8 ore, 24 ore? Per le applicazioni industriali critiche, si raccomanda uno SLA inferiore a 4 ore lavorative.

Competenze industriali: Il servizio di assistenza conosce i protocolli industriali Modbus, PROFIBUS e Siemens S7? Oppure si tratta di un servizio di assistenza IT generico?

Documentazione: API documentata (OpenAPI 3.0)? Esempi di codice? Librerie Python/Node?

Assistenza al progetto: Il fornitore offre assistenza durante la prima implementazione?

Lista di controllo riassuntiva: 9 criteri​

□ Protocoles
  □ Modbus RTU (RS-485) master
  □ Modbus TCP master
  □ MQTT TLS
  □ Protocolli specifici del proprio settore

□ Connectivité
  □ 4G LTE integrato
  □ Dual SIM con due operatori
  □ Port Ethernet WAN (optionnel)
  □ Délai failover < 30 secondes

□ Sécurité
  □ Architecture outbound-only (zero inbound port)
  □ VPN OpenVPN/IPSec o equivalente moderno
  □ TLS 1.3 per le comunicazioni cloud
  □ Autenticazione tramite chiave crittografica
  □ Aggiornamento OTA firmato

□ Robustesse
  □ Temperatura minima: da -20 °C a +70 °C
  □ IP40 come minimo (IP65 in caso di ambiente polveroso)
  □ Montage rail DIN 35mm
  □ Certificazioni CE (+ ATEX se necessario)

□ ZTP
  □ Implementazione senza intervento in loco
  □ SIM M2M preconfigurata

□ Edge computing
  □ Aggregazione locale
  □ Alertes locales sans cloud
  □ Logique locale configurable

□ Console centralizzata
  □ Dashboard della flotta in tempo reale
  □ Aggiornamenti firmware OTA
  □ Configurazione remota

□ Hosting dei dati
  □ Hosting in Francia o nell'UE
  □ Non soumis au CLOUD Act
  □ ISO 27001 minimum

□ Support
  □ SLA documentato
  □ Expertise protocoles industriels
  □ API documentata tramite OpenAPI

Domande frequenti​

Qual è la differenza tra un gateway IoT industriale e un router 4G industriale? Un router 4G industriale garantisce la connettività di rete IP (routing, NAT, VPN). Un gateway IoT industriale aggiunge funzionalità sul campo: porta RS-485 per Modbus RTU, edge computing, integrazione cloud nativa (MQTT, API REST). Alcuni prodotti, come l'Eziwan Gateway, combinano entrambe le funzioni in un unico dispositivo.

È possibile utilizzare un gateway IoT industriale senza un abbonamento al cloud Eziwan? L'hardware Eziwan Gateway può funzionare in modalità autonoma con il proprio broker MQTT o API. La piattaforma cloud Eziwan (dashboard, ZTP, gestione della flotta, avvisi) è opzionale. Detto questo, è inclusa nell'abbonamento ed elimina la necessità di gestire l'infrastruttura server.

Quanti registri Modbus è possibile acquisire contemporaneamente? L'Eziwan Gateway è in grado di gestire fino a 500 registri Modbus (RTU o TCP) per intervallo di polling. Per le implementazioni con esigenze superiori (contatori di energia multicanale, linee con numerosi sensori), il polling può essere distribuito su più intervalli di tempo configurabili.

Che cos'è l'edge computing su un gateway industriale e ne ho bisogno? L'edge computing consente di eseguire la logica direttamente sul gateway (aggregazione, filtraggio, rilevamento locale delle anomalie, avvisi senza cloud). È utile quando: la connettività è intermittente (i dati vengono elaborati e memorizzati temporaneamente in locale), il volume dei dati grezzi è troppo elevato per essere inviato al cloud, oppure è richiesta una reazione rapida (<1 s) senza passare dal cloud.

Come verificare che un gateway sia conforme alla normativa NIS2? La conformità NIS2 per i gateway riguarda: la crittografia delle comunicazioni (minimo TLS 1.3), l'autenticazione forte (certificati X.509, nessuna password predefinita), la tracciabilità degli accessi (registro di audit), gli aggiornamenti di sicurezza (OTA firmati) e l’hosting dei dati nell’UE (GDPR). Richiedete al vostro fornitore l’attestato di conformità o le certificazioni ISO 27001.

Per approfondire​

• Blog: router 4G industriale vs router consumer — 10 differenze
• Blog: Zero-Touch Provisioning — implementare 50 router in 2 ore
• Blog: NIS2 e sicurezza informatica industriale — obblighi e piano d’azione
• Guida: monitoraggio industriale remoto — architettura e sicurezza
• Documentazione: integrazione Modbus RTU sul gateway Eziwan

Risorse​

• Eziwan Gateway — specifiche tecniche
• Confronto tra router industriale e modem Internet
• Guida: Modbus RTU vs Modbus TCP
• VPN industriale vs Zero Trust
• Calcolatore del ROI dell’IoT industriale
• Alternativa a Ewon — confronto tra soluzioni IIoT

Risorse aggiuntive​

• Gateway IoT industriale — criteri di scelta e confronto tra gateway IoT industriali
• Gateway Eziwan — specifiche e funzionalità del gateway Eziwan
• Gateway IIoT — soluzioni di gateway IIoT per l’industria
• Gateway IoT — gamma completa di gateway IoT Eziwan
• Router industriali — router industriali 4G LTE per le vostre sedi remote
• Connettività industriale — soluzioni di connettività per l'Industria 4.0

Questo articolo chiarisce le definizioni, mette a confronto i diversi approcci sulla base di criteri concreti e vi aiuta a scegliere la strategia più adatta al vostro contesto nel 2026 — che si tratti di un piccolo stabilimento con 20 macchinari o di un grande sito industriale con oltre 500 beni.

Le 4 strategie di manutenzione: definizioni precise​

1. Manutenzione correttiva​

Definizione: Si interviene dopo il guasto. L'attrezzatura si rompe, la si ripara.

Varianti:

• Intervento correttivo differito: il guasto viene rilevato, ma la riparazione viene programmata (apparecchiatura non critica)
• Intervento correttivo d'urgenza: guasto critico, è necessario un intervento immediato

Costo tipico: da 4 a 5 volte superiore rispetto alla manutenzione preventiva equivalente (ricambi urgenti, ore di lavoro straordinario, perdite di produzione).

Quando è accettabile: Apparecchiature non critiche facilmente sostituibili, il cui costo di monitoraggio è superiore al costo di un guasto.

2. Manutenzione preventiva sistematica​

Definizione: Si sostituisce o si revisiona secondo un calendario prestabilito (intervalli di tempo o di produzione), indipendentemente dallo stato effettivo.

Esempio: Sostituzione dell'olio di un riduttore ogni 2000 ore, anche se è ancora in buone condizioni.

Problema principale: il 30-40% dei componenti sostituiti durante gli interventi di manutenzione preventiva è ancora utilizzabile. Si sprecano sia risorse che componenti.

Costo tipico: da 2 a 3 volte superiore rispetto alla manutenzione condizionale ben calibrata.

Quando è opportuno: Impianti con modalità di degrado ben note e prevedibili nel tempo, in un contesto normativo che impone revisioni periodiche.

3. Manutenzione basata sulle condizioni (Condition-Based Maintenance — CBM)​

Definizione: Si interviene quando lo stato effettivo dell'apparecchiatura lo richiede, sulla base di misurazioni fisiche continue (vibrazioni, temperatura, corrente, rumore, ecc.).

Principio: Ogni dispositivo “parla” attraverso i propri dati. Noi lo ascoltiamo.

Esempio: Il cuscinetto viene sostituito quando la vibrazione supera una soglia critica stabilita al momento della messa in servizio, non a una data prestabilita.

ROI documentato: Riduzione dal 25 al 55% dei fermi macchina non programmati, risparmio dal 10 al 30% sui costi totali di manutenzione.

Cosa serve: sensori installati sulle apparecchiature, acquisizione dei dati in tempo reale, soglie di allerta configurate.

4. Manutenzione predittiva (Predictive Maintenance — PdM)​

Definizione: Si prevede la data di un futuro guasto utilizzando un modello matematico (statistico o di apprendimento automatico) alimentato da dati storici e in tempo reale.

Differenza rispetto al condizionale: La CBM dice: «L'attrezzatura è in cattive condizioni, intervenite al più presto». La PdM dice: «L'attrezzatura si guasterà tra 3 e 5 giorni con una probabilità dell'87%».

Cosa serve: dati storici relativi ad almeno 12-18 mesi per ogni apparecchiatura, competenze nella modellizzazione, team in grado di mettere a frutto le previsioni.

Realtà sul campo 2026: La vera manutenzione predittiva (ML + modelli fisici) è oggi accessibile alle grandi aziende e alle medie imprese dotate di team dedicati ai dati. Per le PMI, la manutenzione condizionale offre l'80% dei vantaggi con solo il 20% della complessità.

Confronto basato su 7 criteri​

Quali sensori utilizzare per la manutenzione predittiva?​

La manutenzione condizionale si basa su misurazioni fisiche. Ecco i sensori più utilizzati, classificati in base al ROI:

1. Vibrazione (accelerometro)​

Cosa si rileva: squilibrio rotazionale, disallineamento degli alberi, deterioramento dei cuscinetti, cavitazione delle pompe, usura degli ingranaggi.

Applicazioni: Motori elettrici, pompe centrifughe, compressori, ventilatori, trasportatori.

Segnali precursori: Aumento del livello complessivo di vibrazione (RMS), comparsa di frequenze armoniche caratteristiche, aumento della curtosi (impulsività).

Costo del sensore: da 50 € (modello industriale base) a 500 € (a banda larga + ICP).

Tempo di preavviso: Rilevamento da 2 a 12 settimane prima del guasto del cuscinetto.

2. Temperatura a infrarossi / termica​

Cosa si rileva: surriscaldamento anomalo di motori, trasformatori, collegamenti elettrici, cuscinetti, freni.

Applicazioni: Quadri elettrici, motori, cuscinetti, circuiti di raffreddamento.

Segnali premonitori: Aumento della temperatura di funzionamento oltre il valore di riferimento stabilito.

Costo del sensore: da 20 € (sonda a contatto PT100) a 2000 € (termocamera fissa).

3. Corrente elettrica (pinza amperometrica)​

Cosa si rileva: squilibrio di carico, deterioramento dell'isolante, armoniche anomale, difficoltà di avviamento.

Applicazioni: Motori asincroni, servomotori, sistemi di azionamento.

Vantaggio: Nessuna installazione meccanica — la misurazione è non invasiva. Ideale per apparecchiature di difficile accesso.

4. Acustica / ultrasuoni​

Cosa si rileva: perdite di gas compresso, arco elettrico, deterioramento dei cuscinetti a basso carico, problemi di lubrificazione.

Applicazioni: Rete dell'aria compressa, quadri elettrici ad alta tensione, cuscinetti a rotazione lenta.

ROI tipico: Un controllo a ultrasuoni dell'aria compressa individua in genere dal 15 al 30% delle perdite, con un risparmio immediato sui consumi elettrici del compressore.

5. Analisi dell'olio (in linea)​

Cosa si rileva: contaminazione da particelle, deterioramento della viscosità, presenza di acqua, metalli da usura.

Applicazioni: Riduttori, cambi, turbine, compressori.

Sensori in linea: Consentono un monitoraggio continuo senza campionamento, con allarme automatico in caso di presenza di particelle o di materiale dielettrico.

Attuazione pratica: da dove iniziare?​

Fase 1: Identificare le apparecchiature critiche (analisi FMEA semplificata)​

Elencate le vostre attrezzature e valutate per ciascuna di esse:

• Criticità (impatto di un guasto: interruzione della produzione, sicurezza, ambiente)
• Frequenza dei guasti (storico del sistema di gestione della manutenzione, se disponibile)
• Rilevabilità (il guasto è preannunciato o si verifica all'improvviso?)

Concentrate i sensori CBM sulle apparecchiature con elevata criticità + guasti progressivi.

Fase 2: Definire gli indicatori chiave per ogni apparecchiatura​

Per ogni apparecchiatura critica, definire quali parametri misurare. Esempio per una pompa centrifuga:

• Vibrazioni (accelerometro sul cuscinetto lato motore e lato pompa)
• Temperatura dei cuscinetti (PT100 o infrarossi)
• Corrente del motore (pinza amperometrica)
• Pressione differenziale (se la pressione è critica)

Fase 3: Installazione e collegamento dei sensori​

I sensori si collegano al gateway Eziwan tramite RS-485/Modbus RTU, nel caso dei sensori industriali standard, oppure tramite le uscite 4-20 mA, nel caso dei trasmettitori di processo. Il gateway invia tutte le misurazioni alla piattaforma cloud in tempo reale.

Fase 4: Stabilire i valori di riferimento​

Al momento della messa in servizio, registrare i valori di riferimento di ciascun parametro su un’apparecchiatura nuova o in buone condizioni. Questi valori di riferimento servono a:

• Definire le soglie di allarme (allarme a +20%, emergenza a +50% del valore di riferimento)
• Rilevare una deriva progressiva rispetto alla linea di base

Fase 5: Calibrare le soglie di allarme​

Troppa sensibilità = falsi allarmi che demotivano il personale. Sensibilità insufficiente = guasti non rilevati. La calibrazione delle soglie richiede da 2 a 4 settimane di osservazione in condizioni normali per essere perfezionata.

Eziwan consente di modificare le soglie dalla piattaforma cloud senza bisogno di interventi sul campo.

Fase 6: Integrazione con il sistema di gestione della manutenzione (GMAO)​

L'allarme CBM ha valore solo se attiva un'azione pianificata nel sistema di gestione della manutenzione (GMAO). L'API REST Eziwan consente di creare automaticamente un ordine di intervento nel vostro sistema di gestione della manutenzione (SAP PM, Infor EAM, Hive Maintenix) non appena viene attivato un allarme.

Esperienze sul campo​

Cementificio — riduttore principale del frantoio​

Contesto: Riduttore da 800 kW, costo di sostituzione 180.000 €, tempi di consegna 6 settimane.

Prima di CBM: 2 guasti gravi in 4 anni. Ogni guasto = 6 settimane di fermo parziale = 420.000 € di perdita di produzione.

Dopo il CBM (vibrazioni + temperatura + analisi dell'olio): Rilevamento di un deterioramento progressivo 8 settimane prima del guasto. Intervento pianificato durante un fermo programmato. Costo dell’intervento preventivo: 28.000 € contro i 180.000 € di una sostituzione d’emergenza.

ROI: 9 mesi.

Stabilimento agroalimentare — linea di confezionamento​

Contesto: 12 motoriduttori su linea critica. Manutenzione preventiva a 3000 ore (sostituzione sistematica dell'olio + ispezione).

Dopo l'implementazione del CBM (corrente + vibrazioni): Sui 12 motoriduttori monitorati, il CBM ha permesso di:

• Evitare 3 fermi macchina non programmati
• Ridurre del 40% gli interventi preventivi non necessari (l'olio risultava ancora pulito all'analisi)
• Rilevare 2 problemi di allineamento impercettibili a occhio nudo

ROI: 11 mesi.

Conclusione: quale strategia adottare?​

Per una PMI industriale (meno di 50 macchinari): Iniziate con la manutenzione condizionale sui vostri 5-10 macchinari più critici. L'investimento è contenuto, il ROI rapido e la complessità gestibile anche senza un team dedicato all'analisi dei dati.

Per un’azienda di medie dimensioni o una grande impresa: La manutenzione condizionale rimane la base. Per le apparecchiature più critiche, per le quali sono disponibili dati storici sufficienti, integrate questa strategia con modelli predittivi (inizialmente su 2 o 3 apparecchiature prioritarie).

Cosa si osserva nel 2026: La maggior parte delle aziende industriali francesi che hanno effettivamente migliorato le proprie prestazioni di manutenzione lo ha fatto ricorrendo alla manutenzione condizionale basata sull'IoT — non con complessi progetti di machine learning. Il ROI è misurabile in meno di un anno.

Domande frequenti​

Qual è la differenza tra manutenzione predittiva e manutenzione condizionale (CBM)? La manutenzione condizionale attiva un intervento quando viene superata una soglia (ad es.: temperatura > 85 °C → allarme immediato). La manutenzione predittiva analizza le tendenze nel tempo per anticipare il deterioramento prima che venga raggiunta la soglia critica (ad es.: la temperatura aumenta di 2 °C a settimana da 3 settimane → pianificare un intervento tra 2 settimane). La manutenzione condizionale è più semplice da implementare, mentre quella predittiva offre un lead time di intervento più lungo.

Qual è il tipo di sensore più utile per avviare una manutenzione condizionale? Per motori e pompe: il sensore di corrente (trasformatore di corrente sul cavo di alimentazione) è il più versatile — rileva sovraccarichi, difficoltà di avviamento e degrado meccanico senza richiedere alcuna modifica all’apparecchiatura. Per le trasmissioni meccaniche (riduttori, cuscinetti): il sensore di vibrazioni accelerometrico. Questi due tipi di sensori coprono l’80% dei casi di guasti prevenibili in ambito industriale.

Per approfondire​

• Blog: Manutenzione predittiva IIoT — dai dati dei sensori agli avvisi in tempo reale
• Blog: ROI dell'IoT industriale — calcolo e ottimizzazione
• Blog: Modbus TCP vs RTU — quale protocollo scegliere per la raccolta dei dati dai sensori?
• Blog: Grafana per il monitoraggio industriale Modbus
• Documentazione: caso d'uso per un produttore di macchinari OEM

Risorse aggiuntive​

• Manutenzione predittiva IIoT — soluzioni di manutenzione predittiva basate sull'IoT industriale
• Telediagnostica industriale — diagnostica remota per prevenire i guasti
• Monitoraggio delle apparecchiature industriali — monitoraggio continuo dei vostri macchinari industriali
• Supervisione e teleassistenza industriale — supervisione centralizzata per gestire la manutenzione a distanza
• Guida: ridurre gli spostamenti sul campo — ottimizzare gli interventi grazie alla manutenzione condizionale

Questo articolo analizza perché l'hosting in Francia è diventato un criterio di selezione imprescindibile per molte aziende del settore manifatturiero e cosa ciò comporti concretamente nella scelta della soluzione IIoT.

Che cos'è un "dato industriale" e perché la sua ubicazione è importante?​

I dati industriali generati dai vostri gateway IoT, controllori logici programmabili, sensori e sistemi SCADA coprono un ampio spettro:

• Dati di processo: temperature, pressioni, portate, livelli — le misurazioni fisiche della vostra produzione
• Dati operativi: stati di allarme, eventi relativi alle macchine, registri di manutenzione
• Dati sulla topologia di rete: indirizzi IP, schemi di installazione, versione del firmware delle apparecchiature
• Dati di accesso: chi si è connesso a quale apparecchiatura, quando e da dove

Questi dati, considerati nel loro insieme, costituiscono una mappa dettagliata della vostra infrastruttura industriale: la sua capacità produttiva, i suoi punti deboli, le sue modalità di guasto. Se finissero nelle mani sbagliate — concorrenti, attori statali ostili, criminali informatici — le conseguenze potrebbero essere gravi.

La domanda quindi non è «I miei dati sono sensibili?», ma «Chi può accedervi e sotto quale giurisdizione?».

Il problema del CLOUD Act statunitense​

Dal 2018, il Clarifying Lawful Overseas Use of Data Act (CLOUD Act) impone alle aziende statunitensi di fornire alle autorità federali statunitensi i dati che ospitano, anche se tali dati sono fisicamente archiviati in Europa.

In pratica, ciò significa che se utilizzate AWS, Microsoft Azure o Google Cloud, i vostri dati industriali possono essere intercettati dall’FBI o dalla NSA, anche se i vostri server si trovano a Parigi o a Francoforte, senza che ne siate necessariamente informati e senza che possiate avvalervi di un ricorso giuridico efficace a livello europeo.

Per quanto riguarda i dati industriali, questo rischio è particolarmente preoccupante:

• Spionaggio industriale: i vostri parametri di produzione, i ritmi di produzione e le formulazioni potrebbero essere utilizzati dai concorrenti statunitensi
• Infrastrutture critiche: per gli OIV (Operatori di Importanza Vitale), la divulgazione dei dati di monitoraggio può costituire un rischio per la sicurezza nazionale
• Intelligence economica: la capacità produttiva effettiva di uno stabilimento, i suoi fornitori, i suoi flussi logistici — tutto ciò può interessare attori statali

Sia la Commissione europea che l'ANSSI hanno raccomandato di evitare di affidare i dati sensibili a fornitori soggetti al CLOUD Act. La direttiva NIS2 rafforza tale raccomandazione trasformandola di fatto in un obbligo per gli enti essenziali.

Cosa dice NIS2 sulla localizzazione dei dati​

La direttiva NIS2 non prevede esplicitamente l'obbligo di ospitare tutti i dati in Francia o nell'UE. Tuttavia, molti dei suoi requisiti lo implicano indirettamente:

1. Gestione della catena di approvvigionamento digitale​

L'articolo 21 della direttiva NIS2 richiede una gestione dei rischi legati alla catena di approvvigionamento, che includa i fornitori di servizi cloud. Ciò comporta una valutazione formale di ciascun fornitore di servizi cloud: dove ha sede? In quale giurisdizione i suoi dati possono essere sequestrati? Quali sono le sue certificazioni di sicurezza?

Per le entità essenziali (EE) — tra cui figurano numerose aziende dei settori dell'energia, dell'acqua, dei trasporti, della sanità e delle infrastrutture digitali — tale valutazione deve essere documentata e giustificabile in caso di verifica da parte dell'ANSSI.

2. Segnalazione degli incidenti e disponibilità dei dati probatori​

La direttiva NIS2 impone tempi di notifica molto brevi: 24 ore per la segnalazione iniziale, 72 ore per il rapporto sull'incidente. Per rispettare tali scadenze, è necessario disporre di un accesso immediato ai registri di audit, ai log di connessione e ai dati di monitoraggio. Se tali dati sono ospitati presso un fornitore di servizi statunitense soggetto a procedure legali, si rischia di non potervi accedere in tempo utile.

3. Continuità operativa e resilienza​

La direttiva NIS2 richiede un piano di continuità operativa che includa la resilienza dei sistemi informativi. Un fornitore di servizi cloud la cui operatività possa essere compromessa da una decisione giudiziaria statunitense (ingiunzione, congelamento dei beni) rappresenta un rischio inaccettabile per la continuità operativa delle entità essenziali.

4. Sanzioni​

Per i soggetti essenziali, le sanzioni previste dalla direttiva NIS2 possono arrivare fino a 10 milioni di euro o al 2% del fatturato globale. È prevista anche la responsabilità personale dei dirigenti. In questo contesto, la scelta di un servizio di hosting “economico ma rischioso” non è più razionale dal punto di vista economico.

Il GDPR e i dati industriali​

Il GDPR si applica ai dati personali — che possono includere dati aziendali qualora consentano di identificare una persona fisica. Esempi tipici:

• Dati di accesso remoto: chi si è collegato a quale PLC (ID nominativo)
• Registri di produzione: dati sulla produttività per operatore/macchina (se associati a una persona)
• Dati di manutenzione: chi ha effettuato quale intervento (tecnico identificato per nome)
• Allarmi con attribuzione: quale persona ha conferito il "resettato" a quale allarme

Per questi dati, il GDPR vieta qualsiasi trasferimento al di fuori dello Spazio economico europeo in assenza di un meccanismo di protezione adeguato (clausole contrattuali standard, norme aziendali vincolanti, ecc.). A seguito dell’invalidazione del Privacy Shield nel 2020 (sentenza Schrems II), i trasferimenti verso gli Stati Uniti sono particolarmente vulnerabili dal punto di vista giuridico.

"Hosting in Francia" elimina ogni ambiguità: i dati rimangono nel SEE, sotto la giurisdizione del GDPR, senza che sia necessario giustificare alcun meccanismo di trasferimento.

Le certificazioni che contano per l'industria francese​

Non tutti i provider di hosting francesi sono uguali. Per un’infrastruttura IoT industriale critica, cercate queste certificazioni:

ISO 27001​

Certificazione di riferimento per la sicurezza delle informazioni. Indispensabile. Richiede un SMSI (Sistema di Gestione della Sicurezza delle Informazioni) documentato e sottoposto a verifica annuale.

HDS (Hosting dei dati sanitari)​

Obbligatorio per i dati sanitari (settore farmaceutico, ospedali, dispositivi medici). Standard ANSSI/MiPih.

SecNumCloud​

Il marchio dell'ANSSI per i servizi cloud affidabili. Il più alto livello di sicurezza disponibile per il cloud francese. Raccomandato per gli OIV e gli enti essenziali NIS2. Attuali fornitori: OVHcloud, Outscale (Dassault Systèmes), Oodrive.

CSP (Cloud Service Provider) certificato ANSSI​

Elenco dei fornitori certificati per i sistemi informativi sensibili.

Attenzione: alcuni fornitori dichiarano di offrire un "hosting in Francia", pur essendo filiali di società statunitensi soggette al CLOUD Act. Richiedete una dichiarazione che attesti che il fornitore non è soggetto a una legge extraterritoriale che consenta l'accesso ai vostri dati senza preavviso.

Casi concreti: quali aziende del settore sono interessate?​

Operatori di importanza vitale (OIV)​

I 12 settori OIV in Francia (energia, acqua, trasporti, alimentazione, finanza, sanità, ecc.) sono soggetti a specifici obblighi in materia di sicurezza informatica a partire dalla Legge di Programmazione Militare (LPM) del 2013. Per questi settori, l’hosting dei dati di monitoraggio in data center francesi certificati non è un’opzione, ma un requisito contrattuale dell’ANSSI.

Entità essenziali e rilevanti ai sensi del NIS2​

Con NIS2, l'ambito di applicazione si amplia notevolmente:

• Tutte le imprese con più di 250 dipendenti nei settori interessati
• Subappaltatori critici nel settore della difesa
• Gestori di reti idriche ed energetiche locali (anche di medie dimensioni)
• Laboratori farmaceutici e produttori di dispositivi medici

PMI industriali che esportano verso clienti particolarmente esigenti​

Una PMI subappaltatrice di Airbus, Dassault Aviation o di un’azienda farmaceutica può essere contrattualmente tenuta a conservare i propri dati in condizioni conformi ai requisiti del committente. I grandi gruppi industriali inseriscono sempre più spesso queste clausole nei propri bandi di gara per i fornitori.

Come valutare la vostra attuale soluzione IoT​

Ecco 5 domande da porre al vostro attuale o futuro fornitore di servizi IIoT:

1. Dove sono fisicamente ospitati i miei dati? Chiedete l'indirizzo preciso del data center, non limitatevi a "in Europa". Un'hosting "in Europa" può significare Irlanda (Amazon), Olanda (Microsoft) o Finlandia (Google) — tutti soggetti al CLOUD Act.

2. La società madre è soggetta al CLOUD Act? Se il vostro fornitore è una filiale di un'azienda statunitense, è soggetto al CLOUD Act indipendentemente dall'ubicazione dei suoi server.

3. Quali sono le vostre certificazioni in materia di sicurezza? Almeno ISO 27001. SecNumCloud se siete un OIV o un’entità essenziale ai sensi della direttiva NIS2.

4. Avete firmato un DPA (Data Processing Agreement) ai sensi del GDPR? Obbligatorio ogni volta che vengono trattati dati personali (cosa che spesso avviene nel caso dei log di accesso).

5. Potete fornirmi un rapporto di penetrazione recente? I fornitori seri pubblicano i riassunti dei propri test di penetrazione o li condividono tramite un accordo di riservatezza (NDA).

La posizione di Eziwan​

La piattaforma Eziwan è ospitata esclusivamente in Francia, presso fornitori certificati ISO 27001. Siamo un’azienda francese (SAS di diritto francese) e non siamo soggetti ad alcuna legge extraterritoriale che consenta l’accesso ai vostri dati senza il vostro consenso e senza una decisione giudiziaria francese.

I nostri impegni concreti:

• Dati ospitati in Francia: data center certificato ISO 27001 sul territorio francese
• Società di diritto francese: nessun obbligo di divulgazione ai sensi della legislazione straniera
• Accordo sul trattamento dei dati (DPA) conforme al GDPR: contratto di trattamento dei dati conforme al GDPR, firmabile su richiesta
• Registro di audit NIS2: tutti gli accessi ai dati e alle apparecchiature sono tracciati e disponibili per l’audit dell’ANSSI
• Crittografia end-to-end: dati crittografati sia in transito (TLS 1.3) che inattivi (AES-256)

Per le entità essenziali ai sensi della direttiva NIS2 e gli OIV, siamo in grado di fornire una documentazione completa che includa la politica di sicurezza, le certificazioni e gli SLA contrattuali conformi ai requisiti normativi.

Conclusione: la sovranità digitale industriale non è più facoltativa​

Nel 2026, la domanda «Dove sono ospitati i miei dati industriali?» è diventata importante quanto «Le mie apparecchiature sono ridondanti?» o «Ho un backup delle configurazioni dei miei controllori logici programmabili?».

I rischi sono reali e documentati:

• Normativi: sanzioni NIS2 che possono arrivare fino a 10 milioni di euro per i soggetti essenziali
• Giuridici: trasferimenti illeciti ai sensi del GDPR che possono comportare sanzioni da parte della CNIL
• Operativi: indisponibilità dei dati in caso di controversia con un fornitore straniero
• Concorrenziali: potenziale divulgazione di dati di produzione a soggetti stranieri