SIEMENS S7

Guida alla connessione di PLC legacy in fabbrica

Guida connessione PLC legacy: metodi, protocolli e criteri per raccogliere dati affidabili, integrare le macchine e ridurre l'infrastruttura locale IT.
📅 07 agosto 2026 ⏱ 7 min lettura · Modulo: Connessione PLC Siemens S7

Un PLC installato da quindici o vent'anni non è necessariamente un ostacolo alla digitalizzazione. Spesso controlla una macchina ancora produttiva, con logiche stabili e un valore industriale rilevante. La guida connessione PLC legacy serve proprio a distinguere ciò che può essere integrato rapidamente da ciò che...

Guida alla connessione di PLC legacy: da dove partire

La prima fase è un censimento tecnico della macchina. Non basta indicare il costruttore del PLC: servono modello CPU, versione firmware, schede di comunicazione installate, porta disponibile, configurazione di rete e software di programmazione utilizzato. Un Siemens S5, un S7-200 con porta PPI, un S7-300 senza Ethernet nativo o un controllore Modbus seriale richiedono approcci diversi, anche quando governano processi simili.

Va verificato anche se la macchina possiede un HMI, un PC di supervisione o un gateway già collegato. In molti impianti, il dato utile è disponibile su una rete Ethernet industriale esistente o può essere letto attraverso un'interfaccia già presente. In altri casi, la sola comunicazione è seriale oppure il PLC è accessibile esclusivamente dalla rete di programmazione del manutentore. Questa differenza determina costi, tempi e livello di rischio dell'intervento.

La domanda corretta non è soltanto "il PLC è connettibile?", ma "quali dati sono esposti, con quale frequenza e senza interferire con il ciclo macchina?". Un collegamento fisico possibile non garantisce infatti che l'integrazione sia utile ai fini produttivi o adeguata ai requisiti di interconnessione.

Identificare il percorso di comunicazione più adatto

Quando il PLC legacy dispone di Ethernet e di un protocollo accessibile, la raccolta dati può avvenire direttamente. I casi più frequenti riguardano comunicazioni Siemens S7, Modbus TCP/IP, OPC UA, EtherNet/IP o MQTT, a seconda dell'architettura della macchina e degli eventuali dispositivi intermedi.

Se il controllore non espone Ethernet, è possibile valutare un gateway industriale o un modulo di comunicazione compatibile. Un gateway può convertire una rete seriale o un protocollo proprietario in Ethernet, rendendo il dato disponibile a un agente di raccolta. Non è però una soluzione automatica: va controllata la compatibilità effettiva con il modello PLC, il numero di variabili leggibili, i tempi di polling e la gestione degli errori di comunicazione.

In alcuni scenari il punto migliore da cui acquisire i dati non è il PLC principale. Una macchina può avere un contatore esterno, un controllo numerico, un inverter, una bilancia, una stampante o un HMI con informazioni più semplici da leggere e già coerenti con il dato richiesto. Questa alternativa è valida se conserva tracciabilità e attendibilità del processo. Non lo è se produce indicatori incompleti, ad esempio pezzi contati senza distinguere quelli buoni dagli scarti.

Definire i dati prima di configurare il protocollo

Un progetto di connessione efficace parte dalla mappa dati, non dalla scelta del connettore. Leggere centinaia di tag "per sicurezza" aumenta il lavoro di configurazione e rende più difficile validare il risultato. È preferibile definire un set iniziale collegato agli obiettivi operativi: produzione, efficienza, qualità, fermi e avanzamento ordine.

Per il monitoraggio base, possono essere sufficienti il contapezzi totale, il contapezzi buoni, gli scarti, lo stato automatico/manuale, il ciclo attivo e il codice allarme. Per calcolare correttamente l'OEE servono però regole aggiuntive: disponibilità, velocità teorica o standard di produzione, classificazione dei fermi e criterio per la qualità. Se uno di questi elementi non è presente nel PLC, il MES può acquisire parte del dato dalla macchina e completare il contesto con causali operatore, anagrafiche articolo o ordini ricevuti dall'ERP.

La mappa deve riportare indirizzo della variabile, tipo dato, unità di misura, direzione di lettura o scrittura, frequenza di acquisizione e significato industriale. Un registro Modbus letto come intero senza considerare ordine delle word, segno o fattore di scala può generare valori errati. Analogamente, un bit di "macchina in marcia" non coincide sempre con lo stato di produzione: potrebbe rimanere attivo durante il riscaldamento, il cambio formato o un'attesa materiale.

Lettura, scrittura e requisiti di interconnessione

La lettura dati è il punto di partenza più prudente. Permette di monitorare la produzione senza modificare la logica della macchina e con un impatto contenuto sulla validazione dell'impianto. La scrittura di variabili, invece, va prevista solo quando esiste un caso d'uso concreto: invio di un ordine, di una ricetta autorizzata, di un codice articolo o di un comando di sincronizzazione.

Scrivere su un PLC legacy richiede maggiore cautela. Occorre definire autorizzazioni, controlli di coerenza, gestione del timeout e comportamento in caso di perdita del collegamento. Un comando ERP non deve mai diventare un'azione non controllata sulla macchina. In molti casi la soluzione corretta è uno scambio a stati: il sistema invia il dato, il PLC lo valida, restituisce una conferma e registra l'esito.

Per la conformità Transizione 4.0, l'interconnessione non coincide con la semplice visualizzazione su dashboard. La macchina deve poter scambiare informazioni con sistemi interni secondo le funzioni previste, mantenendo evidenze tecniche coerenti con il progetto. Per questo è utile documentare architettura, flussi informativi, variabili scambiate, identificativi macchina, utenti coinvolti e test eseguiti.

Architettura: raccogliere dati senza appesantire lo stabilimento

Il modello tradizionale prevede un server locale, database, backup, aggiornamenti e accessi remoti da gestire in fabbrica. Può essere una scelta adeguata per impianti con policy specifiche o vincoli di rete molto restrittivi, ma porta con sé costi operativi e responsabilità IT continuative.

Un'architettura cloud-native con agente leggero on-premise riduce questa complessità. L'agente dialoga con i PLC e i dispositivi autorizzati sulla rete OT, invia i dati alla piattaforma e consente l'accesso via browser a dashboard, report e configurazioni. In questo modo il server applicativo non deve essere installato e mantenuto nello stabilimento.

La segmentazione resta essenziale. La rete OT non va esposta direttamente a Internet e l'agente dovrebbe comunicare verso l'esterno attraverso connessioni cifrate e autorizzate, senza aprire accessi in ingresso alla rete di fabbrica. Vanno inoltre definiti ruoli, credenziali, registri di accesso e procedure per aggiornamenti e assistenza. La sicurezza non è un elemento separato dalla raccolta dati: è parte dell'architettura che rende il progetto sostenibile.

Testare la connessione sul campo

Prima dell'avvio definitivo, la connessione va collaudata con la produzione reale. Il primo controllo riguarda la stabilità: letture continue, assenza di disconnessioni ricorrenti e carico di rete compatibile con gli altri sistemi. Il secondo riguarda la qualità: i contatori mostrati dal sistema devono corrispondere ai valori macchina in turni, lotti e condizioni operative differenti.

È utile eseguire prove mirate su avvio, fermo, cambio produzione, scarto, allarme e perdita temporanea di connettività. La piattaforma deve gestire correttamente dati mancanti, ripristino della comunicazione e prevenzione dei duplicati. Un dato raccolto in tempo reale ma non riconciliabile a fine turno crea più discussioni che controllo.

La validazione dovrebbe coinvolgere manutenzione, produzione e IT/OT. L'automation engineer conferma indirizzi e comportamento PLC; il responsabile di produzione verifica che gli stati rappresentino ciò che accade sul reparto; l'IT valida segmentazione, accessi e policy. Questa collaborazione riduce le correzioni tardive, soprattutto quando la macchina opera su più turni o produce articoli con logiche differenti.

Quando il retrofit è necessario e quando no

Non ogni PLC legacy merita un retrofit completo. Se la macchina offre dati essenziali, comunica in modo stabile e non richiede interventi sulla logica, un'integrazione mirata può generare rapidamente visibilità su produzione e fermi. Soluzioni come PLCinCloud sono progettate proprio per collegare protocolli e macchinari eterogenei a un ambiente MES senza introdurre server locali dedicati.

Il retrofit diventa più indicato quando non esiste alcuna interfaccia leggibile, i dati disponibili sono insufficienti per l'obiettivo richiesto oppure il PLC presenta limiti di affidabilità e manutenzione che mettono a rischio la continuità produttiva. Anche in questo caso non è detto che serva sostituire l'intero controllo: talvolta bastano un modulo di comunicazione, sensori aggiuntivi o un aggiornamento HMI.

La scelta deve partire dal valore del dato e dal ciclo di vita della macchina. Collegare un impianto legacy non significa forzarlo a comportarsi come un impianto nuovo. Significa estrarre le informazioni che servono al reparto, integrarle con i sistemi aziendali e creare una base concreta per decidere dove intervenire dopo, con priorità misurabili e non per intuizione.

Vuoi vedere PLCinCloud all'opera?

Demo gratuita di 30 minuti sul tuo caso d'uso. Nessun impegno.

Richiedi una demo →