Un macchinario può produrre migliaia di segnali al minuto, ma non è la quantità a determinare la conformità. Alla domanda «quali dati richiede Transizione 4.0?» la risposta utile per una fabbrica è questa: servono dati ed evidenze che dimostrino, nel tempo, che il bene è realmente interconnesso, scambia informazioni...
Quali dati richiede Transizione 4.0: il principio corretto
La normativa non definisce un elenco unico di tag obbligatori valido per ogni macchina, settore e investimento. Un centro di lavoro CNC, una linea di confezionamento e un impianto di refrigerazione hanno segnali, cicli e architetture molto diversi. Il punto non è quindi raccogliere indiscriminatamente tutto ciò che il PLC espone.
I dati devono essere coerenti con le caratteristiche tecnologiche richieste per il bene e con la perizia o l'attestazione tecnica predisposta per l'investimento. Devono consentire di dimostrare l'identificazione univoca della macchina, l'interconnessione ai sistemi aziendali, lo scambio bidirezionale di informazioni e, quando pertinente, il monitoraggio delle condizioni di lavoro o dei parametri di processo.
In pratica, il dato fiscale non vive separato dal dato di produzione. Se la macchina riceve un ordine dall'ERP e restituisce quantità prodotte, stati, scarti e avanzamenti, la stessa integrazione crea valore per pianificazione, tracciabilità e analisi dell'OEE. Se invece si attiva una raccolta dati solo per produrre una schermata dimostrativa, il progetto resta fragile e difficile da mantenere.
I dati essenziali da rendere disponibili
Il perimetro esatto dipende dalla tipologia di bene, dalla configurazione installata e dalle funzioni dichiarate. Esistono però famiglie di dati che ricorrono nella maggior parte dei progetti di interconnessione industriale.
Identità e configurazione del bene
La prima evidenza riguarda l'identità della macchina. Devono essere associabili al bene almeno modello, costruttore, matricola o identificativo univoco, data di entrata in funzione e collocazione produttiva. È utile rilevare anche versione software, ricetta attiva o configurazione principale, quando questi elementi incidono sul processo o sulla tracciabilità.
Questo collegamento evita un errore frequente: disporre di dati tecnicamente corretti, ma non attribuibili con certezza al bene oggetto dell'investimento. In un impianto con macchine analoghe, una nomenclatura coerente tra PLC, MES, anagrafica cespiti ed ERP non è un dettaglio amministrativo. È una condizione di verificabilità.
Stato macchina, eventi e cronologia
Servono dati che descrivano cosa sta facendo il bene e quando. Marcia, fermo, allarme, attesa materiale, cambio formato, setup, manutenzione e modalità manuale o automatica sono esempi tipici. Per essere utili, questi stati devono essere registrati con timestamp e, se possibile, con causa o codice evento.
La storicizzazione è centrale. Una dashboard che mostra lo stato attuale attesta la visibilità istantanea, ma non documenta la continuità dell'interconnessione. Un log consultabile consente invece di ricostruire eventi, indisponibilità, allarmi e attività produttive per un intervallo definito.
Dati di produzione e di processo
Il sistema deve poter acquisire le informazioni necessarie a monitorare e gestire il processo. In base al caso, possono includere contapezzi, quantità buone, scarti, velocità, tempi ciclo, lotti, commesse, codici prodotto, parametri di lavorazione, consumi o valori di qualità.
Non ogni segnale deve diventare un KPI. È preferibile selezionare dati affidabili, con una semantica chiara e una responsabilità definita. Per esempio, il contapezzi letto dal PLC è utile soltanto se si sa quando viene azzerato, se include gli scarti e come viene correlato a ordine e lotto. La qualità del modello dati conta più del numero di variabili raccolte.
Scambio con ERP, MES o altri sistemi aziendali
L'interconnessione richiede uno scambio di informazioni con sistemi interni o esterni alla fabbrica. L'evidenza più forte non è una connessione di rete teoricamente disponibile, ma un flusso reale e documentabile: l'ERP invia ordine, codice articolo, quantità o ricetta; il sistema di fabbrica restituisce avanzamento, consuntivo, stato, tempi, scarti o dichiarazioni di completamento.
La bidirezionalità va letta con pragmatismo. Non significa necessariamente che il gestionale debba comandare ogni asse o intervenire direttamente sulla logica di sicurezza della macchina. Significa che il bene riceve dati funzionali all'attività produttiva e restituisce dati utilizzabili dai sistemi aziendali. Il livello di automazione dello scambio dipende dal processo, dall'architettura OT e dalle responsabilità operative.
Comandi, parametri e tracciabilità degli accessi
Quando il progetto prevede il controllo remoto, l'impostazione di parametri, il caricamento ricette o l'avvio di funzioni dal sistema superiore, è opportuno tracciare chi ha eseguito l'azione, quando e con quale esito. Non tutti i beni richiedono le stesse funzioni di comando, ma dove esistono devono essere governate con ruoli, autorizzazioni e registrazioni adeguate.
Qui la sicurezza è parte della conformità operativa. Un comando ammesso dalla logica applicativa non deve mai aggirare i circuiti di sicurezza, le procedure di lockout o le autorizzazioni previste in stabilimento. L'integrazione IT/OT deve rispettare il perimetro della macchina, non forzarlo.
Le evidenze che rendono il dato difendibile
Il dato da solo non basta: deve essere accompagnato da evidenze tecniche e organizzative. Per ogni bene interconnesso conviene predisporre un fascicolo aggiornato che renda chiaro il percorso dell'informazione, dal campo al sistema aziendale.
Un set documentale efficace comprende almeno:
- anagrafica del bene con identificativo, matricola e collocazione;
- schema dell'architettura di rete e dei sistemi coinvolti;
- mappatura dei segnali scambiati, con origine, destinazione e significato;
- esempi datati di ordini ricevuti, dati restituiti e log eventi;
- schermate o report che attestino monitoraggio e storicizzazione;
- procedure di gestione utenze, backup, modifiche e indisponibilità del servizio.
La perizia o l'attestazione tecnica resta il documento di riferimento per l'interpretazione dei requisiti applicabili al caso concreto. La piattaforma dati deve fornire prove coerenti con quanto dichiarato, non sostituire la valutazione tecnica. Se cambiano PLC, indirizzamento IP, integrazioni ERP, ricette o logiche di raccolta, anche la documentazione va riesaminata.
Dalla raccolta tag alla catena del dato
Il problema più comune non è la mancanza di dati, ma la loro frammentazione. Una parte è nel PLC Siemens, un'altra in un database locale, gli ordini vivono nell'ERP e gli allarmi sono consultabili solo dal pannello operatore. In queste condizioni diventa complesso dimostrare uno scambio continuativo e, soprattutto, usare le informazioni per migliorare la produzione.
Una piattaforma MES cloud-native può acquisire segnali tramite protocolli come OPC UA, Modbus TCP/IP, EtherNet/IP, MQTT o connessioni specifiche ai PLC, normalizzarli e associarli a macchine, commesse e KPI. Il vantaggio non è soltanto tecnico: un unico modello dati riduce le riconciliazioni manuali tra fonti diverse e rende più semplice produrre log, dashboard e report coerenti.
L'architettura va scelta in base a vincoli reali. In alcuni stabilimenti è opportuno usare un agente leggero on-premise per dialogare con la rete OT, evitando di esporre direttamente i PLC. In altri casi pesano maggiormente requisiti di latenza, segmentazione di rete, policy del reparto IT o disponibilità della connettività. L'obiettivo resta identico: dati affidabili, accessibili, protetti e contestualizzati senza introdurre server da amministrare in reparto.
PLCinCloud applica questo approccio collegando macchine e sistemi gestionali in un ambiente operativo unico, con raccolta dei dati di processo, storicizzazione e documentazione orientata alla compliance. Il risultato atteso non è una nuova interfaccia da consultare occasionalmente, ma un sistema utilizzato da produzione, manutenzione e amministrazione con finalità diverse sullo stesso dato.
Come verificare se i dati raccolti sono sufficienti
Prima di considerare chiuso un progetto, è utile eseguire una prova concreta: selezionare una commessa reale e ricostruirne il percorso. Si deve poter vedere quale ordine o istruzione è stata resa disponibile alla macchina, quando la produzione è iniziata, quali stati e parametri sono stati registrati, quali quantità sono state prodotte e quali informazioni sono tornate al sistema aziendale.
Se uno di questi passaggi dipende da un file compilato manualmente, da una schermata non storicizzata o dalla memoria di un operatore, la catena è incompleta. Non significa che l'investimento non possa essere corretto, ma indica un punto da progettare meglio.
La domanda più utile non è quante variabili siano state lette dal PLC. È se, a distanza di mesi, l'azienda riesce a dimostrare con dati coerenti come la macchina ha lavorato, con quali informazioni ha dialogato e quale valore operativo ha generato. Progettare questa risposta fin dall'avvio trasforma la conformità in un vantaggio quotidiano di fabbrica.