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

Per un produttore di macchinari industriali (OEM), l'integrazione della manutenzione remota non è solo un argomento di vendita. Si tratta di una trasformazione del modello economico. Questo articolo fornisce le basi tecniche, economiche e contrattuali necessarie per portare a termine con successo questa trasformazione.

1. La manutenzione remota come fattore di differenziazione​

L'evoluzione delle aspettative dei clienti​

Dieci anni fa, offrire la manutenzione remota rappresentava un vantaggio competitivo. Oggi, in molti settori, è un requisito indispensabile per accedere a determinati mercati.

Settore agroalimentare e delle bevande: le moderne linee di produzione funzionano 20 ore su 24, 6 giorni su 7. Un fermo non programmato costa tra i 5.000 e i 50.000 € all’ora a seconda della capacità. I committenti esigono che l’attività riprenda entro 2-4 ore, un obiettivo impossibile da raggiungere senza una diagnosi a distanza.

Farmacia e cosmetica: le apparecchiature sono soggette a procedure di qualificazione (IQ/OQ/PQ). Ogni modifica o intervento deve essere documentato. La manutenzione remota con tracciabilità completa delle sessioni soddisfa pienamente tale requisito.

Settore automobilistico e meccanico: i grandi clienti includono la connettività delle apparecchiature tra i criteri di selezione per le gare d'appalto. In alcuni capitolati d'oneri, le apparecchiature non connesse vengono escluse a priori.

Energie rinnovabili: turbine eoliche, centrali solari, pompe di calore industriali — la manutenzione preventiva basata sui dati di funzionamento è un fattore chiave per la competitività.

Cosa stanno già facendo i vostri concorrenti​

I costruttori che hanno integrato la manutenzione remota nella propria offerta segnalano effetti commerciali significativi:

• Tasso di rinnovo dei contratti di manutenzione: nettamente superiore — i clienti che beneficiano del monitoraggio in tempo reale rinnovano quasi sistematicamente
• Prezzo di vendita della macchina: giustifica un sovrapprezzo dal 3 all’8% sul prezzo della macchina, ammortizzato in meno di un anno grazie ai risparmi sulla manutenzione
• Fidelizzazione dei clienti: la connettività crea un contatto regolare tra costruttore e cliente, che favorisce il riacquisto o l’ampliamento del parco macchine

2. Architettura tecnica: macchina → gateway → cloud​

Il gateway come componente della macchina​

L'approccio più efficace consiste nell'integrare il gateway Eziwan come componente standard della macchina, alla stregua del convertitore di frequenza o del pannello HMI. Esso è riportato nella distinta base, nello schema elettrico e nel manuale d'uso.

Questa integrazione fin dalla fase di progettazione evita i problemi legati all'integrazione a posteriori (adeguamento del cablaggio, giustificazione dei costi all'acquirente) e consente di proporre la manutenzione remota in modo trasparente come una funzionalità della macchina.

Schema completo dell'architettura​

┌──────────────────────────────────────────────────────────────────┐
│  Machine industrielle (OEM)                                      │
│                                                                  │
│  [Capteurs et actionneurs]                                       │
│  ├── Températures, pressions, débits                             │
│  ├── Moteurs, variateurs, servomoteurs                           │
│  └── Codeurs, capteurs de position                               │
│                     ↓ Analogique / TOR                          │
│  [Automate / Motion controller]                                  │
│  ├── Programme de production (protégé Know-How)                  │
│  ├── Variables de process (accessibles supervision)              │
│  ├── Compteurs et historique local                               │
│  └── Codes défaut et diagnostics                                 │
│                     ↓ Modbus TCP ou RS-485                      │
│  [Gateway Eziwan] ← Intégrée en standard dans l'armoire         │
│  ├── Collecte Modbus (poll 1-60s configurable)                   │
│  ├── Bufferisation locale (perte 4G jusqu'à 48h)                 │
│  ├── 4G LTE Dual SIM (SIM multi-opérateurs incluse)             │
│  └── Tunnel OpenVPN sortant → zéro port entrant               │
└──────────────────────────────────────────────────────────────────┘
              │ Tunnel OpenVPN chiffré
              ▼
     [Cloud Eziwan]
          ↙              ↘
  [Espace OEM]       [Espace client]
  - Toutes variables  - Variables autorisées
  - Firmware update   - Supervision process
  - Diagnostics       - Alertes et historique
  - Accès toutes machines  - Ses machines seulement

Separazione delle interfacce di accesso​

La separazione tra l'area OEM e l'area cliente è uno degli aspetti più importanti dell'architettura. Essa risponde a due esigenze contrastanti:

• L'OEM necessita di un accesso completo alla macchina per la diagnostica e la manutenzione
• Il cliente necessita di visibilità sulla propria produzione senza avere accesso al know-how del costruttore

Variabili protette (solo OEM): Parametri di calibrazione, ricette di produzione, parametri PID di regolazione, soglie di protezione interne.

Variabili condivise (visibili al cliente): Temperature di processo, pressioni, portate, stati delle macchine, contatori di produzione, codici di errore generici.

3. Sicurezza: proteggere il cliente e tutelare il proprio know-how​

La fiducia come argomento di vendita​

I vostri clienti pongono sempre la stessa domanda: «Se avete accesso remoto al mio macchinario, come posso essere sicuro che non possiate vedere i miei dati di produzione riservati?»

E a volte pongono la domanda opposta: «Se un hacker compromette il vostro accesso come produttore, può accedere al mio computer?»

La risposta tecnica a queste due domande è il compartimentamento crittografico.

Segregazione crittografica​

Indipendenza degli spazi di accesso: Lo spazio OEM e lo spazio cliente utilizzano credenziali completamente distinte, senza alcun collegamento tra loro. La compromissione di una credenziale del cliente non consente l'accesso allo spazio OEM e viceversa.

Selezione dettagliata delle variabili visibili: La configurazione del gateway definisce esplicitamente quali variabili sono visibili a ciascun livello di accesso:

variables:
  - nom: "Temperature_Etuve"
    modbus_addr: 100
    access_oem: read_write    # OEM peut lire et modifier
    access_client: read       # Client peut lire

  - nom: "PID_Kp_Etuve"
    modbus_addr: 200
    access_oem: read_write
    access_client: hidden     # Client ne voit pas ce paramètre

  - nom: "Compteur_Cycles"
    modbus_addr: 300
    access_oem: read
    access_client: read       # Les deux peuvent lire les compteurs

Tracciabilità degli accessi OEM presso il cliente: Il cliente può vedere nella propria dashboard quando i tecnici OEM si sono collegati alla sua macchina, per quanto tempo e su quali variabili. Questa trasparenza rafforza la fiducia.

Protezione del vostro programma PLC​

Indipendentemente dal gateway, si raccomanda di attivare le protezioni native del controllore:

Siemens S7-1500:

• Protezione "Know-How": crittografia del programma, impedisce la lettura anche tramite TIA Portal
• Protezione "Copy": collegamento del programma al numero di serie della CPU (impossibile copiare su un'altra CPU)
• Protezione dell’accesso di livello 4 (protezione completa): qualsiasi modifica richiede la password

Schneider M340:

• Protezione dell'accesso tramite password in EcoStruxure
• Salvataggio crittografato del programma

4. Dati operativi: una miniera d’oro per l’ufficio tecnico​

I dati che solo il produttore può analizzare​

Quando la vostra macchina è in produzione presso 100 clienti, avete accesso a qualcosa di unico: dati di funzionamento reali, in condizioni diverse, su un lungo periodo. Si tratta di una risorsa per cui i team di ricerca e sviluppo delle grandi aziende investono milioni.

Durata di vita effettiva dei componenti: Dopo quante ore di funzionamento, statisticamente, si guasta il cuscinetto a sfere dell’asse Y della vostra macchina? I dati relativi al vostro parco macchine di 100 unità rispondono con precisione a questa domanda. Quello che pensavate fosse un MTBF di 8.000 ore potrebbe in realtà essere di 6.500 ore nella produzione effettiva, oppure di 12.000 ore se gli operatori seguono correttamente le procedure di lubrificazione.

Correlazione tra parametri e guasti: Quale combinazione di temperatura ambiente + carico del motore + durata del ciclo precede un guasto del regolatore termico? Queste correlazioni consentono di migliorare gli algoritmi di manutenzione preventiva sulle prossime generazioni.

Utilizzo effettivo vs utilizzo previsto: La vostra macchina viene utilizzata secondo le specifiche? Alcuni clienti spingono la macchina oltre i suoi limiti nominali. Altri la utilizzano ben al di sotto di essi. Queste informazioni guidano le decisioni di progettazione (sovradimensionare un componente che viene sistematicamente sollecitato al 95%).

Segmentazione del parco macchine: Alcuni clienti presentano tassi di guasto tre volte superiori alla media. Perché? L'analisi dei dati operativi può rivelare correlazioni con l'ambiente (temperatura, umidità, vibrazioni) o con le pratiche degli operatori.

5. Modello economico SaaS ricorrente​

Dalla transazione singola all'abbonamento​

La manutenzione remota crea i presupposti per un abbonamento annuale di manutenzione connessa. Questo modello trasforma il rapporto commerciale:

Modello tradizionale:

• Vendita di macchinari: ricavo una tantum
• Contratto di manutenzione: rinegoziazione annuale, spesso sotto pressione sui prezzi
• Pezzi di ricambio: ricavo occasionale

Modello connesso:

• Vendita della macchina: ricavo una tantum (invariato, o addirittura premium)
• Abbonamento alla connettività: ricavo ricorrente, rinnovo automatico
• Contratto di manutenzione esteso: SLA rispettabili grazie alla diagnostica remota, prezzo premium
• Dati sul parco macchine: valore per la R&S (non monetizzabile direttamente ma con un forte ROI indiretto)

Struttura tariffaria tipo​

──────────────────────────────────────────────────────────────────
OFFRE STANDARD — Supervision opérationnelle
  • Tableau de bord client en temps réel
  • Alertes SMS/email sur défauts machine
  • Historique 1 an
  • 2 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE MAINTENANCE CONNECTÉE
  • Tout le Standard +
  • Accès technicien OEM à distance (illimité)
  • SLA : diagnostic à distance sous 4h ouvrées
  • Mise à jour firmware automate à distance
  • Historique 3 ans
  • 5 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE PERFORMANCE GARANTIE
  • Tout le Maintenance Connectée +
  • Rapport mensuel de performance machine
  • Analyse prédictive (détection dérive)
  • Engagement disponibilité machine
  • Accès API données pour intégration client
──────────────────────────────────────────────────────────────────

Calcolo del ROI per l'OEM​

Per un OEM con 150 macchine installate, ipotizzando 1,8 interventi correttivi per macchina all’anno:

Ipotesi indicative. Il ROI effettivo dipende dall’ubicazione del parco, dalla natura dei guasti e dall’organizzazione interna.

6. Integrazione nel ciclo di vita del prodotto​

Raccomandazioni per l'integrazione hardware​

Alimentazione dedicata: Prelevare 24 V CC da un'alimentazione permanente (a monte dell'interruttore principale della macchina). Il gateway deve rimanere accessibile anche quando la macchina principale è spenta: è proprio in questi momenti che la diagnostica remota risulta più utile.

Rete del PLC: Collegare il gateway a una porta Ethernet dedicata (se possibile, separata dalla porta HMI). Sui controllori a porta singola (S7-1200 CPU 1211C, M221...), utilizzare uno switch industriale gestibile per separare i flussi HMI / gateway / ingegneria.

Antenna 4G: Per gli armadi in acciaio, prevedere sistematicamente un passaggio cavi per l'antenna remota. All'interno, con l'armadio chiuso, il segnale è spesso insufficiente. Nella stragrande maggioranza dei casi è sufficiente un cavo LMR-200 da 3 m con antenna direzionale all'esterno dell'armadio.

Documentazione per le schede tecniche delle macchine​

Eziwan fornisce ai partner OEM la documentazione da integrare nei manuali d'uso delle macchine:

• Schema di cablaggio certificato (formati DXF e PDF)
• Procedura di attivazione e disattivazione della telemanutenzione (per l'operatore del cliente)
• Informativa sulla privacy dei dati di telemetria (conforme al GDPR)
• Procedura di sostituzione del gateway (garanzia, fine del ciclo di vita)

Domande frequenti — Manutenzione remota per produttori OEM​

Il cliente può disattivare il gateway di telemanutenzione sul proprio computer?

Tecnicamente sì: il cliente può scollegare fisicamente il gateway. Dal punto di vista contrattuale, la risposta dipende dal contratto di manutenzione: gli OEM che offrono SLA con tempi di intervento inferiori a 4 ore possono subordinare tale SLA all’attivazione permanente della telemanutenzione. In pratica, i clienti disattivano raramente il gateway poiché lo utilizzano anche per monitorare la propria produzione.

Come proteggere il programma del controllore (know-how OEM) consentendo al contempo il monitoraggio da parte del cliente?

Due livelli di protezione complementari: (1) a livello di PLC, attivare la protezione Know-How (S7-1500) o la protezione tramite password (M340) per impedire la lettura del programma anche tramite TIA Portal. (2) A livello di Eziwan, configurare le variabili come access_client: hidden per i parametri riservati. Il cliente vede solo le variabili di processo, non i parametri di regolazione.

Quante macchine è possibile gestire con un unico account OEM Eziwan?

Non esiste un limite fisso: gli account OEM sono progettati per le flotte industriali (da decine a migliaia di macchine). La dashboard OEM consente di filtrare per cliente, modello di macchina, stato (allerta, normale, offline) e di confrontare le prestazioni tra macchine dello stesso modello.

Come fatturare l'abbonamento al servizio di telemanutenzione ai clienti in caso di rivendita di Eziwan?

Eziwan offre un programma di partnership OEM con tariffe all'ingrosso. L'OEM integra la connettività nel proprio abbonamento di manutenzione, applicando il margine che desidera. Il cliente finale non è a conoscenza del rapporto con Eziwan: sottoscrive un «abbonamento di manutenzione connessa» presso l’OEM.

Cosa succede alla scadenza del contratto di manutenzione: l'accesso OEM viene interrotto?

Sì, se il contratto prevede tale clausola. Dalla dashboard OEM, gli accessi all'account di un cliente possono essere disattivati immediatamente (scadenza del contratto, controversia) o trasferiti a un altro fornitore. I dati storici del cliente rimangono nel suo account e gli appartengono: non vanno persi.

Il monitoraggio a distanza non è più un lusso per questi impianti: è una necessità operativa e, in alcuni settori regolamentati (acqua potabile, depurazione), un requisito di conformità.

1. Problematiche specifiche delle stazioni di pompaggio​

Il contesto operativo reale​

Un gestore di stazioni di pompaggio con più sedi gestisce in genere da 20 a 200 siti, con un team composto da pochi tecnici di manutenzione che copre centinaia di chilometri quadrati. Le stazioni sono spesso:

• Geograficamente isolate: zone rurali, rive dei fiumi, terreni non urbanizzati, talvolta di difficile accesso in caso di maltempo
• Non sorvegliate: nessun personale permanente in loco, visite programmate da 1 a 4 volte al mese
• Fondamentali per il servizio: una stazione di sollevamento fuori servizio può causare un trabocco della rete o un'interruzione dell'approvvigionamento di acqua potabile nelle ore successive
• Soggette a vincoli normativi: i gestori dei servizi idrici e fognari sono soggetti al Codice dell’Ambiente e ai decreti prefettizi e devono redigere rapporti di servizio

In assenza di supervisione remota, la modalità operativa è reattiva: una chiamata da parte dell'utente, un allarme locale (sirena, spia rossa) o un giro di controllo periodico segnalano il problema. Il tempo di risposta si misura in ore, a volte in giorni per i siti più lontani.

I costi dell'approccio reattivo​

Interventi inutili: Tra il 30 e il 50% degli interventi a seguito di un allarme sono “interventi inutili”: l’operatore arriva sul posto e constata che il problema si è risolto da solo (riavvio automatico della pompa, interruzione transitoria di corrente) oppure che il problema non richiede un intervento immediato. Un intervento costa tra i 400 e i 700 € (veicolo, tempo, indennità).

Interventi mal preparati: Senza una diagnosi a distanza, il tecnico non sa cosa troverà e non può portare con sé i ricambi adeguati. Un viaggio di andata e ritorno in più per andare a prendere un ricambio può raddoppiare il costo dell'intervento.

Rilevamento tardivo dei guasti: Una pompa soggetta a cavitazione (aspirazione di aria), che funziona a secco o il cui rotore inizia a deteriorarsi può continuare a funzionare per diversi giorni in condizioni compromesse prima di subire un guasto definitivo. Nel frattempo, la durata della pompa si riduce e aumenta il rischio di un arresto improvviso.

Difficoltà nel rispetto degli obblighi normativi: La redazione dei rapporti annuali sulla qualità del servizio (RPQS per l'acqua potabile, rapporto annuale del gestore per la rete fognaria) richiede un notevole lavoro di consolidamento manuale se i dati non vengono archiviati automaticamente.

2. Architettura tipica: dal sensore al cruscotto​

Panoramica dell'architettura​

┌──────────────────────────────────────────────────────────────────┐
│  Station de pompage SP-42                                        │
│                                                                  │
│  [Capteurs de mesure]                                           │
│  ├── Niveau bâche : sonde à ultrasons ou pression relative 4-20mA │
│  ├── Débit : débitmètre électromagnétique (impulsions ou 4-20mA) │
│  ├── Courant moteur P1 : transformateur de courant (TA)          │
│  ├── Courant moteur P2 : transformateur de courant               │
│  └── Présence alimentation : contact sec sur TGBT               │
│                     ↓                                           │
│  [Coffret de régulation / Automate]                             │
│  ├── Siemens LOGO! 8 / S7-1200                                  │
│  ├── Schneider M221 / M241                                      │
│  ├── Wago PFC200                                                 │
│  └── Coffret "vrai de vrai" relais + télémesure ancienne        │
│                     ↓ Modbus TCP ou RTU                         │
│  [Gateway Eziwan]  ← Rail DIN, 24V DC                           │
│  └── 4G LTE Dual SIM ──────────────────────────────────────────┤
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
                     │ Tunnel OpenVPN
                     ▼
           [Cloud Eziwan]
           ├── Base time-series (données horodatées)
           ├── Moteur d'alertes
           └── Tableau de bord web + app mobile
                     │
                     ▼
           [Salle de conduite — téléopération]
           [Application mobile — astreinte]
           [Email/SMS — responsable exploitation]

Scelta del protocollo in base al controllore​

Gestione delle stazioni senza controllore​

Per le numerose piccole stazioni di sollevamento che non dispongono di un controllore logico programmabile — ma solo di un quadro di avviamento con contattori e relè — il gateway Eziwan può essere collegato direttamente ai segnali di campo tramite un modulo di espansione per ingressi/uscite digitali:

[Contact sec "Pompe 1 en marche"] ──→ [Entrée TOR 1 gateway]
[Contact sec "Défaut thermique"]  ──→ [Entrée TOR 2 gateway]
[Sonde niveau 4-20mA]             ──→ [Entrée analogique gateway]

Questo approccio consente di equipaggiare le stazioni esistenti senza modificare il cablaggio né installare un controllore.

3. Variabili di monitoraggio essenziali​

Schema di supervisione standard per una stazione di pompaggio​

Per una stazione dotata di 2 gruppi motopompa (la configurazione più comune), ecco le variabili minime da monitorare:

Variabili di stato (valori booleani):

%MW300 bits :
  bit 0 : Pompe 1 en marche
  bit 1 : Pompe 2 en marche
  bit 2 : Défaut thermique pompe 1 (disjoncteur déclenché)
  bit 3 : Défaut thermique pompe 2
  bit 4 : Défaut disjoncteur général
  bit 5 : Alimentation électrique présente
  bit 6 : Niveau haut bâche atteint (pré-alarme)
  bit 7 : Niveau très haut bâche (alarme)
  bit 8 : Niveau bas bâche (risque fonctionnement à sec)
  bit 9 : Mode manuel activé (maintenancier sur place)
  bit 10 : Défaut sonde niveau (valeur hors plage ou absence signal)

Variabili analogiche (registri a 16 o 32 bit):

%MW100 : Niveau bâche (% × 10 → ex. 752 = 75.2%)
%MW101 : Débit instantané (L/min)
%MW102-103 : Volume journalier pompé (m³ × 1000, int32 sur 2 registres)
%MW104 : Courant moteur pompe 1 (A × 10 → ex. 142 = 14.2 A)
%MW105 : Courant moteur pompe 2 (A × 10)
%MW106 : Nombre de démarrages pompe 1 (compteur)
%MW107 : Nombre de démarrages pompe 2 (compteur)
%MW108-109 : Durée de marche cumulée P1 (minutes, int32)
%MW110-111 : Durée de marche cumulée P2 (minutes, int32)
%MW112 : Tension secteur (V × 10)
%MW113 : Code défaut détaillé (bitfield constructeur)

Perché monitorare la corrente del motore​

Il monitoraggio della corrente del motore è l'indicatore più significativo per la manutenzione preventiva delle pompe:

Rilevamento della cavitazione: una pompa che aspira aria presenta una corrente motrice inferiore al normale (il fluido è meno denso). Indicatore precoce di un problema di livello o di aspirazione.

Rilevamento del funzionamento a secco: la corrente scende bruscamente al di sotto della corrente nominale a vuoto. Rischio di danneggiamento della tenuta meccanica in pochi minuti.

Deterioramento del rotore: un rotore usurato o incrostato consuma più corrente a parità di portata. Una variazione progressiva della corrente a portata costante indica la necessità di un intervento di manutenzione.

Problema di alimentazione elettrica: uno squilibrio di corrente tra le fasi (su una pompa trifase) può indicare un cavo difettoso o un problema nella rete elettrica del sito.

4. Configurazione degli avvisi a più livelli​

Gerarchia degli avvisi​

Un sistema di allarme efficace per una stazione di pompaggio deve essere calibrato in modo da evitare la "stanchezza da allarme" (troppi allarmi → gli operatori finiscono per ignorarli), garantendo al contempo che gli incidenti critici vengano segnalati immediatamente.

Livello 1 — Informazioni (e-mail al team di guida):

Démarrage pompe 2 alors que pompe 1 est déjà en marche
  → Information uniquement (situation normale en pointe)

Niveau bâche > 75% alors que les deux pompes sont en marche
  → Vérification débit entrant inhabituellement élevé

Livello 2 — Preallarme (e-mail + notifica sull'app mobile):

Niveau bâche > 85%
  → Situation anormale, surveiller l'évolution

Courant moteur > 110% de la valeur de référence pendant > 2 minutes
  → Surcharge légère, vérifier à la prochaine ronde

Aucune mise en marche des pompes depuis > 24h alors que niveau > 30%
  → Pompes peut-être en défaut silencieux

Livello 3 — Allarme (SMS + e-mail + webhook di reperibilità):

Niveau bâche > 95%
  → Risque de débordement, intervention urgente

Défaut thermique pompe 1 ET pompe 2 simultanément
  → Station hors service, intervention immédiate

Courant moteur < 40% de la valeur nominale pendant > 30 secondes
  → Fonctionnement à sec probable, arrêt automatique conseillé

Perte d'alimentation électrique
  → Toutes les pompes s'arrêtent, vérifier groupe électrogène si disponible

Perte de connectivité gateway > 15 minutes
  → Impossible de savoir l'état de la station

Configurazione delle fasce orarie e dell'escalation​

Gli avvisi possono essere configurati con fasce orarie e una logica di escalation:

Défaut thermique pompe :
  Heure ouvrée (8h-18h) → SMS technicien de service
  Nuit / week-end       → SMS astreinte + email responsable

Si pas d'acquittement en 30 minutes :
  → Appel téléphonique (webhook vers système de téléphonie)
  → SMS responsable de service

5. Cronologia, conformità e rendiconti normativi​

Il valore dei dati storici​

La cronologia dei dati di una stazione di pompaggio è una risorsa operativa preziosa che si accumula nel tempo:

Analisi delle tendenze a lungo termine: Confrontare le curve di corrente del motore della pompa 1 nel gennaio 2024 e nel gennaio 2025. Uno scostamento dell'8% indica che il rotore è in fase di usura: programmare la manutenzione preventiva prima del guasto, durante il fermo invernale.

Correlazione tra precipitazioni e portata in entrata: Per le stazioni di sollevamento delle acque reflue, la correlazione tra gli episodi piovosi e la portata in entrata consente di dimensionare le capacità di stoccaggio e di individuare le infiltrazioni di acque estranee nella rete.

Ottimizzazione dei parametri di regolazione: Analizzare i cicli di avvio/arresto: una pompa che si avvia più di 15 volte all'ora indica un problema di dimensionamento (pompa troppo potente, serbatoio troppo piccolo) o di regolazione.

Relazioni normative relative all'acqua e alla rete fognaria​

Per i gestori che operano in regime di delega di servizio pubblico (DSP) o di contratto di affitto, si applicano diversi obblighi di rendicontazione:

RPQS — Relazione sul prezzo e sulla qualità del servizio: Richiesto ogni anno dal Codice Generale degli Enti Locali (CGCT) per i servizi di acqua potabile e fognatura. Deve includere indicatori di prestazione: tasso di conformità dei prelievi, tasso di interruzioni, volume prodotto/distribuito, rendimento della rete.

Il pannello di controllo Eziwan genera automaticamente i dati grezzi relativi a questi indicatori (volumi pompati, tempi di inattività, numero di incidenti).

Relazioni di monitoraggio autorizzate: Alcuni impianti di prelievo o di scarico richiedono la presentazione di rapporti periodici alla DREAL (Direzione Regionale per l'Ambiente, la Pianificazione Territoriale e l'Edilizia Abitativa). I dati storici di Eziwan possono essere esportati in formato CSV per alimentare tali rapporti.

Conservazione dei dati: Per l'acqua potabile, i dati di monitoraggio devono essere conservati per almeno 5 anni. Eziwan consente di configurare la conservazione dei dati fino a diversi anni, a seconda dell'abbonamento.

6. Caso concreto: riduzione degli spostamenti sul campo​

Contesto​

Un consorzio intercomunale per la depurazione nella regione dei Paesi della Loira gestisce 65 stazioni di sollevamento distribuite su un territorio di 1.500 km². Prima dell’implementazione di Eziwan:

• 3 tecnici di manutenzione che coprivano l’intero territorio
• Circa 180 spostamenti all’anno (2,8 per sito)
• Budget stimato per spostamenti e reperibilità pari a 85.000 € all’anno

Dopo 12 mesi di utilizzo di Eziwan​

Interventi sul posto evitati grazie alla diagnosi a distanza:

• Il 45% degli allarmi è stato risolto a distanza senza necessità di recarsi sul posto (riarmo a distanza, diagnosi confermata senza urgenza)
• Il 20% degli interventi è stato preparato in anticipo grazie al preallarme (il tecnico parte con il ricambio giusto)

Risultati rilevati:

• Spostamenti: da 180 a 105 all'anno (-42 %)
• Tempo medio di intervento: da 3 ore a 1 ora e 45 minuti (migliore preparazione)
• Incidenti rilevati prima del guasto: 8 casi nell'arco dell'anno (pompe con deriva di corrente)
• Risparmio stimato: 38.000 € all'anno sui costi di manutenzione

I nostri clienti che gestiscono stazioni di pompaggio registrano, in media, una riduzione compresa tra il 35% e il 55% degli spostamenti nei primi 12 mesi successivi all'implementazione.

Domande frequenti — Monitoraggio remoto delle stazioni di pompaggio​

Il gateway funziona sui vecchi gruppi di sollevamento privi di controllore logico programmabile?

Sì. Tramite il modulo di espansione per ingressi/uscite digitali, il gateway è in grado di leggere direttamente i contatti a secco dei quadri di avviamento elettromeccanici: stato della pompa, guasto termico, presenza di alimentazione. Per i sensori di livello analogici 4-20 mA è disponibile un ingresso analogico diretto. Questo approccio evita di dover installare un PLC sulle stazioni esistenti.

Quante variabili è possibile monitorare su una stazione di piccole dimensioni (LOGO! 8 o M221)?

Il LOGO! 8 di Siemens supporta fino a 64 blocchi Modbus configurabili, mentre l’M221 di Schneider supporta fino a 100 parole %MW in Modbus TCP. Per una stazione standard a 2 pompe, lo schema di supervisione descritto in questo articolo (circa 20 variabili) rientra ampiamente nei limiti di questi controllori. Il gateway Eziwan non presenta limiti pratici sul numero di variabili raccolte.

I dati relativi al volume pompato sono sufficientemente precisi per i rapporti RPQS?

Dipende dalla precisione del misuratore di portata installato (in genere da ±0,5% a ±2% per un misuratore elettromagnetico). Il gateway raccoglie e registra con data e ora gli impulsi o il valore analogico del misuratore di portata con una risoluzione configurabile (ogni secondo, se necessario). La cronologia Eziwan può essere esportata in formato CSV con tutte le misurazioni grezze per i calcoli di volume integrati richiesti dal RPQS.

Come gestire le frequenti microinterruzioni di corrente in alcune zone rurali?

Il gateway Eziwan si riavvia in meno di 30 secondi dopo un'interruzione di corrente e ristabilisce automaticamente il tunnel VPN. I dati raccolti prima dell'interruzione vengono già trasmessi al cloud. Se l'interruzione dura più di 30 secondi, il gateway memorizza i dati nella cache al momento del riavvio e li ritrasmette. Per le sedi con interruzioni molto frequenti (più volte al giorno), è sufficiente un UPS da 24 V CC di piccola capacità (con autonomia di pochi minuti) per assorbire le microinterruzioni.

È possibile inviare comandi a distanza alle pompe (riarmo, avvio)?

Sì, tramite la scrittura nei registri Modbus (FC=06 o FC=16). Questa funzionalità deve essere attivata esplicitamente nella configurazione di Eziwan e protetta da diritti di accesso restrittivi (solo alcuni account possono scrivere). È garantita la completa tracciabilità: ogni operazione di scrittura nei registri viene registrata con l'identità dell'operatore e la data e l'ora.

Questa guida tratta gli aspetti fondamentali per un professionista: storia, struttura della trama byte per byte, codici funzione, confronto con i protocolli concorrenti, ottimizzazione delle prestazioni, sicurezza ed esempio di codice Python completo e funzionante.

1. Da Modbus RTU a Modbus TCP: 45 anni di evoluzione​

La nascita di Modbus nel 1979​

Modbus è stato creato nel 1979 da Modicon (oggi acquisita da Schneider Electric) per consentire la comunicazione tra i primi controllori logici programmabili Modicon 084. Si trattava di un protocollo seriale (RS-232 e successivamente RS-485), di tipo master/slave, progettato per un unico scopo: leggere e scrivere valori numerici su apparecchiature di campo.

La semplicità era il principio fondamentale di progettazione:

• Nessun indirizzamento di rete — solo un identificativo slave compreso tra 1 e 247 sul bus
• Nessuna autenticazione: qualsiasi master può interrogare qualsiasi slave
• Nessuna individuazione automatica: l'elenco degli slave viene configurato manualmente
• Nessun meccanismo di sicurezza: il protocollo presuppone un ambiente fisicamente sicuro

Modbus RTU (Remote Terminal Unit): versione binaria compatta per RS-485. I dati vengono trasmessi in formato binario, con un CRC a 16 bit per il rilevamento degli errori. Ancora molto diffuso sugli strumenti da campo (contatori di energia, sensori di pressione, convertitori di frequenza).

Modbus ASCII: versione leggibile in ASCII, per collegamenti RS-232. Meno efficiente (2 byte per ogni byte di dati), ormai obsoleta nelle nuove installazioni.

Modbus TCP: Ethernet senza una rivoluzione del protocollo​

Intorno al periodo 1996-1999, con la diffusione capillare di Ethernet negli stabilimenti, Modbus TCP ha incapsulato il protocollo in frame TCP/IP. La modifica è stata minime:

• Stesso modello di dati (coil, ingressi discreti, registri di ingresso, registri di temporizzazione)
• Stessi codici funzione
• Stesso indirizzamento dei registri
• Eliminazione del CRC (il TCP garantisce l’integrità)
• Aggiunta di un’intestazione MBAP di 7 byte per l’instradamento e la correlazione delle richieste
• Porta TCP standard: 502

Il vantaggio: tutte le apparecchiature esistenti compatibili con Modbus RTU potevano passare a Modbus TCP con modifiche minime. Lo svantaggio: le lacune di sicurezza originarie sono state mantenute.

2. Struttura di un frame Modbus TCP — analisi byte per byte​

Panoramica della trama​

┌─────────────────────────────────────────────────────────────────────┐
│                        Trame Modbus TCP                             │
├──────────────────────────────────────────┬──────────────────────────┤
│           MBAP Header (7 octets)         │        PDU               │
├──────────┬──────────┬──────────┬─────────┼────────────┬─────────────┤
│ Trans.ID │ Proto.ID │  Length  │ Unit ID │  Func.Code │    Data     │
│  2 bytes │  2 bytes │  2 bytes │  1 byte │   1 byte   │  n bytes    │
└──────────┴──────────┴──────────┴─────────┴────────────┴─────────────┘

Analisi dell'intestazione MBAP​

Identificatore della transazione (2 byte): Numero libero scelto dal cliente, restituito identico nella risposta. Consente di correlare le risposte alle richieste nel caso di connessioni persistenti con più richieste in corso. In pratica, la maggior parte dei client utilizza un semplice contatore (00 01, 00 02, 00 03...) o un identificatore fisso (00 00) se opera in modalità richiesta/risposta sequenziale.

Identificatore del protocollo (2 byte): Sempre 00 00 per Modbus. Questa costante è stata definita per consentire un’eventuale estensione ad altri protocolli tramite la stessa porta, ma non è mai stata utilizzata.

Lunghezza (2 byte): Numero di byte successivi, in formato big-endian. Include l'ID unità e la PDU, ma non i primi 4 byte dell'intestazione MBAP. Per una richiesta FC=03 di 10 registri: 6 byte (1 ID unità + 1 FC + 2 indirizzi + 2 conteggi) → 00 06.

Identificatore unità (1 byte): Identificatore dello slave Modbus. Nei PLC collegati direttamente (S7-1200 con MB_SERVER, M340 con server Modbus integrato), il valore è in genere 1 o 255. Sui gateway Modbus RTU→TCP, questo identificatore corrisponde all'indirizzo dello slave RTU sul bus RS-485.

Analisi di una richiesta FC=03 completa​

Lettura di 10 registri di controllo a partire dall'indirizzo 100 (es.: %MW100 su Schneider M340):

Requête client  (hex) :  00 01  00 00  00 06  FF  03  00 64  00 0A

Décodage byte par byte :
  00 01  → Transaction ID = 1
  00 00  → Protocol ID = 0 (Modbus standard)
  00 06  → Length = 6 (Unit ID + FC + 2 adresse + 2 count)
  FF     → Unit ID = 255 (0xFF = CPU locale M340)
  03     → Function Code = Read Holding Registers
  00 64  → Starting Address = 100 (0x0064 en big-endian)
  00 0A  → Quantity = 10 registres (0x000A)

Réponse automate  (hex) :  00 01  00 00  00 17  FF  03  14  [20 octets]

Décodage :
  00 01  → Transaction ID = 1 (même que la requête — corrélation)
  00 00  → Protocol ID = 0
  00 17  → Length = 23 (1 UID + 1 FC + 1 ByteCount + 20 données)
  FF     → Unit ID = 255
  03     → Function Code = 3 (confirme que c'est une réponse normale)
  14     → Byte Count = 20 (10 registres × 2 octets = 0x14 hex)
  [suivi de 20 octets de données — 10 valeurs uint16 big-endian]

Codici di eccezione (messaggi di errore)​

Quando il sistema automatizzato non è in grado di elaborare una richiesta, restituisce un codice di eccezione:

Réponse exception (hex) :  00 01  00 00  00 03  FF  83  02

  83 → FC + 0x80 = 3 + 128 = 131 → indique une réponse d'exception sur FC=3
  02 → Exception code : Illegal Data Address

3. I codici funzione in dettaglio​

FC=01 e FC=02 — Lettura dei bit​

FC=01 : Read Coils           → bits de sortie (écriture autorisée)
FC=02 : Read Discrete Inputs → bits d'entrée (lecture seule)

Requête : FC  AddrH  AddrL  QuantH  QuantL
          01  00 00  00 00  00 10   (lecture 16 coils depuis @0)

Réponse : FC  ByteCount  Coil_Data
          01  02         [2 bytes = 16 bits d'état]
          
Note : les coils sont packés en bits, LSB first.
       Byte1 bit0 = Coil@0, Byte1 bit1 = Coil@1, etc.

FC=03 — Lettura dei registri di mantenimento (il più utilizzato)​

Lettura e scrittura di registri a 16 bit. Limite: massimo 125 registri per richiesta.

FC=04 — Lettura dei registri di ingresso​

Identico a FC=03, ma per i registri "di ingresso" (sola lettura). Su Schneider M340, corrisponde agli %IW. Sulla maggior parte dei controllori logici, è poco utilizzato poiché i valori analogici vengono copiati negli %MW (Holding Registers).

FC=06 e FC=16 — Scrittura nei registri​

FC=06 : Write Single Register
  Requête : FC  AddrH  AddrL  ValueH  ValueL
            06  00 64  00 64  01 F4     (écriture 500 à l'adresse 100)

FC=16 : Write Multiple Registers (jusqu'à 123 registres par requête)
  Requête : FC  AddrH  AddrL  CountH  CountL  ByteCount  Values...
            10  00 64  00 05  01 2C   [données]

4. Modbus TCP vs OPC-UA vs MQTT: quale protocollo scegliere per la vostra architettura?​

Questi tre protocolli coesistono nelle moderne architetture IIoT. Servono livelli diversi e non sono in diretta concorrenza tra loro.

Come scegliere?​

Utilizzare Modbus TCP se:

• Il PLC supporta Modbus TCP (Siemens S7-1200, Schneider M340/M221/M241, Wago, Allen-Bradley...)
• È necessario acquisire misure semplici (registri a 16 bit)
• La semplicità di configurazione ha la precedenza sulla ricchezza del modello di dati

Utilizzare OPC-UA se:

• Il PLC supporta nativamente OPC-UA server (S7-1500, B&R, Beckhoff, CODESYS 3.x recente)
• È necessario monitorare variabili complesse (strutture, array, tipi personalizzati)
• L'interoperabilità con altri sistemi SCADA o MES è un requisito fondamentale

Utilizzate MQTT per il trasporto dati nel cloud se:

• Disponete di un gateway (come Eziwan) che raccoglie dati in Modbus/OPC-UA e li pubblica in MQTT
• Avete bisogno di un'architettura pub/sub scalabile per migliaia di punti

L'architettura di destinazione per l'IIoT nel cloud:

[Automate] ──Modbus TCP / OPC-UA──→ [Gateway] ──MQTT over TLS──→ [Cloud]

Il gateway converte e trasmette i dati. Funge da ponte tra il mondo OT (Modbus/OPC-UA) e il mondo cloud (MQTT/REST).

5. Sicurezza Modbus TCP: il problema e le soluzioni​

La totale assenza di autenticazione​

Modbus TCP non dispone di alcun meccanismo di sicurezza nativo:

• Nessuna autenticazione: chiunque sulla rete può leggere e scrivere
• Nessuna crittografia: i dati sono in chiaro (leggibili con Wireshark)
• Nessuna autorizzazione: non esiste il concetto di diritti di lettura/scrittura per utente

Conseguenza pratica: se il vostro controllore è accessibile da Internet (porta 502 aperta), è completamente vulnerabile. Se qualcuno si connette alla vostra rete OT (fisicamente o tramite una falla nella sicurezza), può leggere e modificare tutti i registri.

Le possibili risposte​

Segmentazione della rete (misura primaria): Limitare il traffico Modbus TCP a una rete OT isolata. Il gateway Eziwan si trova in questa rete OT; la comunicazione con il cloud avviene tramite un tunnel VPN, non tramite l'esposizione della porta 502.

Filtraggio IP sul PLC (misura secondaria): Alcuni PLC di nuova generazione (Schneider M340 con firmware ≥ 2.60, Siemens S7-1200 con firmware V4.x e funzioni FIREWALL) supportano il filtraggio IP: solo l’indirizzo IP del gateway Eziwan è autorizzato a connettersi alla porta 502.

Modbus Security (misura avanzata): Nel 2018 la Modbus Organization ha pubblicato un'estensione denominata "Modbus Security" (trasporto TLS per Modbus TCP) sulla porta 802. Questa estensione non è ancora ampiamente supportata dai controllori presenti sul mercato, ma è disponibile su alcune apparecchiature di recente produzione.

6. Ottimizzazione delle prestazioni di raccolta​

Raggruppamento delle richieste (batching)​

La regola d'oro: raggruppare le letture in blocchi contigui. Leggere 100 registri contigui in un'unica query è molto più efficiente che eseguire 100 query, ciascuna su un singolo registro:

Configuration inefficace (100 requêtes) :
  Lire %MW0  → 1 requête (2 octets de données)
  Lire %MW50 → 1 requête
  Lire %MW99 → 1 requête
  ... 97 requêtes supplémentaires ...
  Latence totale : 100 × (aller-retour réseau) ≈ 100 × 5ms = 500ms

Configuration optimisée (1 requête) :
  Lire %MW0 à %MW99 → 1 requête (200 octets de données)
  Latence totale : 1 × 5ms = 5ms

Il gateway Eziwan raggruppa automaticamente le variabili configurate in intervalli contigui. Per ottimizzare questo raggruppamento, organizzare le variabili di monitoraggio in aree di memoria adiacenti.

Impatto sul ciclo del controllore​

Ogni richiesta Modbus TCP ricevuta viene elaborata dal PLC al termine del ciclo di programma. Su un M340 con un ciclo di 10 ms, 10 richieste Modbus simultanee possono allungare il ciclo da 1 a 3 ms.

Raccomandazione: non superare 1 richiesta Modbus per ciclo del PLC nelle applicazioni con requisiti in tempo reale. Ridurre la frequenza di polling se il ciclo si allunga.

7. Esempio di codice Python completo con pymodbus​

"""
Collecte Modbus TCP industrielle avec gestion d'erreurs robuste
Compatible Schneider M340, Siemens S7-1200, Wago, Allen-Bradley...
Testé avec pymodbus >= 3.0

Installation :
    pip install pymodbus loguru
"""

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException, ConnectionException
from loguru import logger
import struct
import time
from dataclasses import dataclass
from typing import Optional


# ─── Configuration ────────────────────────────────────────────────────────────

HOST     = "192.168.1.20"  # IP automate Schneider M340
PORT     = 502             # Port Modbus TCP
UNIT_ID  = 255             # 255 pour CPU locale M340, 1 pour S7-1200
TIMEOUT  = 3               # Timeout en secondes
RETRIES  = 3               # Nombre de tentatives avant abandon


# ─── Structure de données ─────────────────────────────────────────────────────

@dataclass
class VariablesProcess:
    temperature_c: float = 0.0
    debit_lmin: int = 0
    pression_bar: float = 0.0
    pompe_1_marche: bool = False
    pompe_2_marche: bool = False
    code_defaut: int = 0
    compteur_production: int = 0
    timestamp: float = 0.0


# ─── Client Modbus avec reconnexion automatique ───────────────────────────────

class ModbusCollecteur:
    """Collecteur Modbus TCP avec gestion de reconnexion et retry."""

    def __init__(self, host: str, port: int = 502, unit_id: int = 1):
        self.host = host
        self.port = port
        self.unit_id = unit_id
        self.client: Optional[ModbusTcpClient] = None
        self._connexions_ok = 0
        self._connexions_echec = 0

    def connecter(self) -> bool:
        """Établit la connexion TCP vers l'automate."""
        try:
            self.client = ModbusTcpClient(
                self.host,
                port=self.port,
                timeout=TIMEOUT,
                retries=1,          # Retries gérés par notre code
                reconnect_delay=0,  # Pas de reconnexion automatique
            )
            if self.client.connect():
                self._connexions_ok += 1
                logger.info(f"Connecté à {self.host}:{self.port}")
                return True
            else:
                self._connexions_echec += 1
                logger.warning(f"Connexion refusée par {self.host}:{self.port}")
                return False
        except Exception as e:
            logger.error(f"Erreur connexion : {e}")
            return False

    def deconnecter(self):
        if self.client:
            self.client.close()
            self.client = None

    def lire_holding_registers(
        self, adresse: int, count: int
    ) -> Optional[list[int]]:
        """Lit des registres avec retry automatique."""
        for tentative in range(1, RETRIES + 1):
            try:
                if not self.client or not self.client.is_socket_open():
                    if not self.connecter():
                        time.sleep(1)
                        continue

                result = self.client.read_holding_registers(
                    address=adresse, count=count, slave=self.unit_id
                )

                if result.isError():
                    exception_code = getattr(result, 'exception_code', '?')
                    logger.warning(
                        f"Erreur Modbus addr={adresse} count={count} "
                        f"exception_code={exception_code}"
                    )
                    # Exception 04 (server busy) → attendre avant retry
                    if exception_code == 6:
                        time.sleep(0.5)
                    self.deconnecter()
                    continue

                return result.registers

            except ConnectionException:
                logger.warning(f"Connexion perdue (tentative {tentative}/{RETRIES})")
                self.deconnecter()
                time.sleep(0.5)
            except Exception as e:
                logger.error(f"Erreur inattendue : {e}")
                self.deconnecter()
                time.sleep(1)

        logger.error(f"Échec lecture après {RETRIES} tentatives — addr={adresse}")
        return None

    @staticmethod
    def registres_to_float32_abcd(reg_high: int, reg_low: int) -> float:
        """Décode 2 registres 16-bit en float32 IEEE754 big-endian (ABCD)."""
        raw = struct.pack(">HH", reg_high, reg_low)
        return struct.unpack(">f", raw)[0]

    @staticmethod
    def registres_to_int32(reg_high: int, reg_low: int) -> int:
        """Décode 2 registres en entier 32-bit signé big-endian."""
        raw = struct.pack(">HH", reg_high, reg_low)
        return struct.unpack(">i", raw)[0]


# ─── Lecture des variables process ───────────────────────────────────────────

def lire_variables(collecteur: ModbusCollecteur) -> Optional[VariablesProcess]:
    """
    Lecture optimisée : 1 seule requête Modbus pour toutes les variables.
    
    Plan mémoire (M340 EcoStruxure) :
      %MW100 : Temperature (int16, ×0.1 → °C)
      %MW101 : Débit (int16, L/min)
      %MW102-103 : Pression (float32 ABCD, bar)
      %MW104 : États machine (bits 0-7)
      %MW105 : Code défaut actif
      %MW106-107 : Compteur production (int32)
    """
    # 1 requête pour %MW100 à %MW107 (8 registres)
    registres = collecteur.lire_holding_registers(adresse=100, count=8)
    if registres is None:
        return None

    vars_process = VariablesProcess(
        temperature_c  = registres[0] * 0.1,                               # %MW100
        debit_lmin     = registres[1],                                      # %MW101
        pression_bar   = ModbusCollecteur.registres_to_float32_abcd(        # %MW102+103
                             registres[2], registres[3]),
        pompe_1_marche = bool(registres[4] & 0x0001),                      # %MW104 bit0
        pompe_2_marche = bool(registres[4] & 0x0002),                      # %MW104 bit1
        code_defaut    = registres[5],                                      # %MW105
        compteur_production = ModbusCollecteur.registres_to_int32(          # %MW106+107
                             registres[6], registres[7]),
        timestamp      = time.time(),
    )

    return vars_process


# ─── Boucle principale ────────────────────────────────────────────────────────

def main():
    collecteur = ModbusCollecteur(HOST, PORT, UNIT_ID)
    INTERVALLE = 5  # secondes entre chaque collecte

    logger.info(f"Démarrage collecte Modbus TCP — {HOST}:{PORT} — cycle {INTERVALLE}s")

    while True:
        try:
            vars_process = lire_variables(collecteur)

            if vars_process:
                logger.info(
                    f"T={vars_process.temperature_c:.1f}°C  "
                    f"Q={vars_process.debit_lmin}L/min  "
                    f"P={vars_process.pression_bar:.2f}bar  "
                    f"P1={'ON' if vars_process.pompe_1_marche else 'OFF'}  "
                    f"Défaut={vars_process.code_defaut}"
                )
                # Ici : publier via MQTT, API REST, ou base time-series
                # mqtt_client.publish("usine/ligne3/variables", vars_process)
            else:
                logger.warning("Collecte échouée — attente 10s avant retry")
                time.sleep(10)
                continue

            time.sleep(INTERVALLE)

        except KeyboardInterrupt:
            logger.info("Arrêt demandé.")
            collecteur.deconnecter()
            break


if __name__ == "__main__":
    main()

Domande frequenti — Protocollo Modbus TCP/IP​

Perché la porta Modbus TCP è la 502 e non una porta standard come la 80 o la 443?

La porta 502 è stata ufficialmente assegnata a Modbus dall'IANA (Internet Assigned Numbers Authority) in occasione della standardizzazione di Modbus TCP negli anni '90. All’epoca non vi era motivo di riutilizzare le porte applicative IT esistenti. Si tratta di una porta registrata (< 1024), pertanto il suo utilizzo come server richiede i privilegi di root su Linux — cosa che i firmware industriali gestiscono in modo nativo.

Qual è il limite massimo di registri leggibili in una singola richiesta FC=03?

Il limite è di 125 registri per richiesta FC=03 (Read Holding Registers), come definito nella specifica ufficiale Modbus. Ciò corrisponde a un massimo di 250 byte di dati utili per richiesta. Per FC=16 (Write Multiple Registers), il limite è di 123 registri per richiesta. Il gateway Eziwan gestisce automaticamente la suddivisione se un intervallo richiesto supera tali limiti.

Modbus TCP supporta più connessioni client simultanee?

Sì, ma è il PLC a definire il limite. Lo Schneider M340 accetta fino a 16 connessioni simultanee, il Siemens S7-1200 fino a 8 (tramite MB_SERVER). Oltre questo limite, il PLC restituisce un'eccezione 06 (Server Busy). In pratica, un gateway di raccolta dati + uno strumento di diagnostica + un sistema SCADA locale raggiungono facilmente le 3 connessioni simultanee — da tenere sotto controllo.

È possibile crittografare il protocollo Modbus TCP?

Lo standard Modbus TCP nativo (porta 502) non è crittografato. Dal 2018 esiste un’estensione “Modbus Security” sulla porta 802 con TLS, ma è raramente supportata dai controllori attuali. La soluzione pratica consiste nel confinare Modbus TCP in una rete OT isolata e far passare tutte le comunicazioni verso l’esterno tramite un tunnel VPN crittografato (come OpenVPN di Eziwan) — la crittografia è garantita dal livello di trasporto, non da Modbus stesso.

Pymodbus è l'unica libreria Python per Modbus TCP?

No. Le alternative principali sono minimalmodbus (più semplice per Modbus RTU), umodbus (leggero, con un basso consumo di memoria) e pyModbusTCP (puramente TCP, senza dipendenze). Per i progetti industriali in Python, pymodbus >= 3.0 rimane la scelta più completa grazie alla gestione delle eccezioni, alla riconnessione e al supporto di entrambe le modalità (RTU e TCP).

Come eseguire il debug di una comunicazione Modbus TCP senza poter accedere al PLC?

Utilizzare Modbus Slave (Windows) come simulatore di PLC locale, oppure diagslave (riga di comando, multipiattaforma). Questi strumenti simulano un server Modbus TCP che risponde a indirizzi configurabili. Ideale per testare una configurazione di raccolta dati senza il rischio di interferire con un PLC in produzione.

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 risposta in breve: le reti OT non sono reti IT. I controllori che vi operano gestiscono macchinari fisici: un comando errato o un’intrusione possono avere conseguenze a livello industriale, se non addirittura umane. Gli strumenti destinati al grande pubblico sono stati progettati per un contesto radicalmente diverso.

Questo articolo va oltre una semplice risposta sintetica. Spiega il modello di minaccia reale, illustra in dettaglio i requisiti della norma IEC 62443 e presenta i criteri tecnici per valutare una soluzione di accesso remoto industriale.

1. Il modello di Purdue e i livelli di affidabilità OT​

Per capire perché gli accessi remoti OT sono diversi, è necessario conoscere il modello Purdue (Purdue Enterprise Reference Architecture), punto di riferimento internazionale per la segmentazione delle reti industriali.

Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
           ─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
           ─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
           ─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
           ─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
           ─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)

L'accesso remoto industriale riguarda tipicamente i livelli 1 e 2 — i controllori logici programmabili (PLC) e gli strumenti di ingegneria. Questi livelli non devono mai essere accessibili direttamente dai livelli superiori senza controllo, e tanto meno da Internet.

La segmentazione tra i livelli costituisce la prima linea di difesa. L'accesso remoto, per definizione, attraversa tale segmentazione: da qui derivano i requisiti di sicurezza più rigorosi.

2. I rischi effettivi di un accesso non controllato alla rete OT​

Cosa viene trasmesso su una rete OT industriale​

Una rete OT tipica ospita:

• PLC (S7, M340, CompactLogix) che controllano i macchinari
• Variatori di frequenza che controllano i motori
• Interfacce uomo-macchina industriali che consentono la supervisione e la configurazione
• Sistemi SCADA che supervisionano l'intero processo
• Strumenti di misura (sensori di pressione, temperatura, portata)

Queste apparecchiature sono state progettate per garantire l'affidabilità in ambienti isolati, non per resistere agli attacchi di rete. Il protocollo Modbus non prevede alcuna autenticazione. S7Comm (Siemens) storicamente non disponeva di alcuna crittografia. Profinet, EtherNet/IP — la maggior parte dei protocolli industriali presuppone una rete affidabile.

Analisi di un attacco a un accesso remoto OT non adeguatamente protetto​

Ecco come si svolge in genere un attacco a un accesso remoto industriale non protetto:

Fase 1 — Ricognizione (automatica, passiva): Uno scanner automatico (Shodan, Censys o uno script personalizzato) identifica l'IP pubblico dello stabilimento e rileva una porta aperta (VPN classica su UDP 1194, porta Modbus 502, porta S7Comm 102). Questa fase non genera alcun log sospetto e dura pochi secondi.

Fase 2 — Sfruttamento dell'accesso: Se la VPN è protetta solo da una password debole (o se le credenziali sono state rubate tramite phishing), l'autore dell'attacco riesce ad accedere. Se si tratta di una porta Modbus direttamente esposta, può leggere e scrivere senza alcuna autenticazione.

Fase 3 — Ricognizione interna: Una volta ottenuto l'accesso, l'autore dell'attacco effettua una mappatura della rete OT: quali controllori sono accessibili, quali variabili sono leggibili, quali aree di processo vengono controllate.

Fase 4 — Azione dolosa: Le azioni possono essere immediate (interruzione della produzione, modifica dei parametri) o discrete (modifica graduale dei setpoint per compromettere la qualità del prodotto senza far scattare alcun allarme).

Incidenti documentati​

L'ANSSI e il CISA (Cybersecurity and Infrastructure Security Agency, Stati Uniti) segnalano regolarmente incidenti relativi ad accessi remoti industriali non adeguatamente protetti:

• TeamViewer su una postazione di supervisione idrica (Florida, 2021): un hacker ha modificato i livelli di trattamento chimico tramite TeamViewer installato sul sistema SCADA di un impianto di trattamento dell'acqua potabile. L'attacco è stato rilevato dall'operatore in tempo reale, ma avrebbe potuto passare inosservato.
• VPN senza MFA nel settore energetico: sono stati documentati diversi incidenti in cui credenziali VPN rubate hanno consentito l’accesso a reti elettriche regionali in Europa.
• Port forwarding Modbus: i ricercatori nel campo della sicurezza hanno dimostrato più volte la possibilità di modificare i parametri dei controllori logici programmabili (PLC) accessibili direttamente da Internet.

3. Porte aperte vs tunnel in uscita: la differenza fondamentale​

Architettura "porta di ingresso esposta"​

[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]

Questo modello espone un punto di accesso a Internet. Che si tratti di una porta VPN (UDP 1194 per OpenVPN, UDP 500/4500 per IPsec) o di una porta applicativa (502, 102, 443), tale porta viene monitorata costantemente.

Ciclo di vita di una porta esposta:

1. Apertura della porta → indicizzazione da parte di Shodan entro 24-48 ore
2. Primi tentativi di scansione → pochi giorni dopo l'esposizione
3. Tentativi di sfruttamento automatizzato → non appena viene identificata una firma nota
4. Sfruttamento mirato → se l'installazione viene identificata come critica o interessante

Architettura "solo tunnel in uscita"​

[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]

Cosa cambia sostanzialmente:

• La connessione viene avviata dall'interno — esattamente come un browser web
• Dal punto di vista del firewall dello stabilimento: traffico HTTPS in uscita verso un indirizzo IP noto
• Nessuna porta in entrata da aprire, nessuna regola del firewall da modificare
• Nessuna porta esposta = nessuna superficie di attacco di rete dal lato dello stabilimento

Se l'infrastruttura cloud di Eziwan venisse compromessa (scenario ipotetico), un malintenzionato non potrebbe propagare l'attacco alla rete dello stabilimento: la connessione è unidirezionale dal punto di vista dell'avvio.

Perché TeamViewer non è “così sicuro” come OpenVPN​

TeamViewer utilizza effettivamente un relay cloud (non c'è una connessione diretta tra l'autore dell'attacco e lo stabilimento), ma i problemi strutturali sono diversi:

4. Cosa dicono la norma IEC 62443 e l'ANSSI​

IEC 62443 — la norma di riferimento​

La norma IEC 62443 definisce i requisiti di sicurezza informatica per i sistemi industriali. Per l'accesso remoto, il Security Level 2 (SL2) — livello raccomandato per la maggior parte degli impianti industriali — richiede:

SR 1.1 — Identificazione e autenticazione umana: Ogni utente che accede al sistema deve essere identificato e autenticato individualmente. Gli account condivisi (un unico account "manutenzione" per l'intero team) sono espressamente esclusi.

SR 1.7 — Autenticazione rafforzata (Enhancement SL2): Per gli accessi remoti a livello SL2 è richiesta l'autenticazione a due fattori (MFA). La sola password non è sufficiente.

SR 2.6 — Accesso tramite reti non affidabili: Qualsiasi accesso da Internet alla rete OT deve essere crittografato, autenticato e registrato. Questo requisito costituisce la traduzione normativa della combinazione “tunnel in uscita + MFA + registri di audit”.

SR 6.2 — Monitoraggio continuo: Gli accessi remoti devono essere registrati in modo continuativo: chi si è collegato, quando, da quale indirizzo e per quanto tempo.

Raccomandazioni dell'ANSSI​

L'ANSSI pubblica guide specifiche per i sistemi industriali. I suoi cinque principi per l'accesso remoto industriale:

1. Segregazione: gli accessi remoti non devono attraversare direttamente la rete OT, ma devono passare attraverso una DMZ industriale
2. Autenticazione forte: MFA obbligatoria per qualsiasi accesso remoto alle apparecchiature di livello 1 o 2
3. Crittografia: tutte le comunicazioni remote devono essere crittografate con algoritmi recenti
4. Registrazione: log completi, esportabili, con data e ora, conservati per almeno 3 mesi
5. Privilegio minimo: ogni tecnico accede solo alle apparecchiature di propria competenza

5. OpenVPN, IPSec e L2TP in ambito industriale​

Non tutte le VPN sono uguali quando si tratta di gateway integrati su CPU ARM con limitazioni relative alla riconnessione e alla memoria.

Analisi comparativa dettagliata​