solution.data_collection()
La raccolta dati sembra un problema di collegamenti fisici, ma in realtà si gioca sulla qualità semantica: dati che arrivano non basta, devono essere interpretabili.
Ogni linea ha nomi tag arbitrari, unità diverse e frequenze incoerenti. I sistemi a valle non sanno cosa stanno leggendo.
Senza un dizionario tag condiviso, l'analytics e l'MES costruiscono mappe parallele che si rompono al primo cambio di PLC.
Quando la rete o il gateway cade, i dati si perdono. Nessuno segnala il buco e gli storici non sono affidabili per decisioni a posteriori.
Servono logiche di store-and-forward e marcatori espliciti sui buchi: meglio un dato mancante dichiarato che un numero inventato.
Ogni stabilimento ha la sua implementazione: broker diversi, protocolli diversi, security diverse. Manutenzione e rollout diventano impossibili.
Un pattern di raccolta unico con varianti controllate è l'unico modo per rendere scalabile la data platform industriale.
Inventario degli asset, protocolli disponibili, tag list e frequenze di campionamento necessarie.
Design del layer di raccolta: edge gateway, protocolli, buffering locale e connessione al data store.
Setup dei driver per ogni macchina: OPC-UA, Modbus, S7, MQTT. Test di lettura e validazione.
Configurazione database time-series, retention policy e API di accesso ai dati.
La differenza non sta solo nel collegamento alla macchina, ma nella qualità del dato che arriva ai sistemi a valle.
Disegno di edge, gateway, broker, historian o API secondo requisiti di continuità e sicurezza.
Retry, buffering, store-and-forward e controlli di coerenza per evitare buchi o duplicazioni.
Dizionario tag, architettura resiliente, semantica condivisa: i dati arrivano corretti e interpretabili.
