Software di acquisizione dati macchina: cosa comprare nel 2026 (e cosa saltare)
Il software di acquisizione dati macchina è lo strato che sta tra una linea di produzione e qualunque sistema voglia fare qualcosa di utile con quello che la linea sta facendo. Legge segnali da PLC, sensori, sistemi di visione, MES e, sempre più spesso, da camere puntate sulla macchina, poi trasforma quei segnali in un flusso che un database, una dashboard o un modello di IA possono consumare.
La categoria è passata da uno o due player dominanti a circa venti in cinque anni. Metà di loro risolve un problema che nel 2020 non esisteva. L’altra metà risolve un problema che i grandi vendor MES risolvevano e oggi non vogliono più risolvere. Questo pezzo è per il responsabile operations o IT che sta facendo una short list di strumenti e vuole una mappa chiara.
Cosa fa davvero un software di acquisizione dati macchina
Al suo nucleo, tre cose. Si collega alla sorgente dati (PLC, sensore, camera, MES, ERP, registro inserito a mano). Normalizza i dati in un formato coerente con timestamp e informazioni sulle unità. Passa i dati a qualunque sistema li consumi (un historian, una dashboard, un database in cloud, un modello di IA, il foglio Excel di un ingegnere di processo).
Le differenze tra i vendor sono quasi tutte nel primo passo e nel terzo. Il centro è commodity. I vendor competono su quanti protocolli parlano nativamente (Siemens S7, Allen-Bradley, Modbus, OPC UA, MQTT, EtherNet/IP, Profinet, più la lunga coda di protocolli specifici per brand) e su con quanti consumatori si integrano (SQL, database time-series, Snowflake, BigQuery, Azure Data Explorer, Power BI, Grafana, endpoint REST custom).
Per uno stabilimento piccolo o medio lo strato di connessione conta più di quello di consumo. Per uno stabilimento grande con uno stack analitico già in piedi vale il contrario.
Le cinque categorie di strumenti nel 2026
Cinque secchi coprono la maggior parte del mercato nel 2026.
1. Middleware classico in stile SCADA
Strumenti nati da workflow di historian e SCADA: AVEVA PI, Inductive Automation Ignition, Wonderware/AVEVA System Platform, GE Proficy. Forti sui dati PLC ad alto volume, deboli sulle integrazioni cloud moderne e sui dati da camera. Costosi (le licenze per tag o per connessione si sommano in fretta). Affidabili. Il default nell’oil & gas, nella grande chimica e nella grande manifattura discreta.
Scegli se: hai un parco PLC e historian consolidato da anni, l’IT di stabilimento lo gestisce con tranquillità e non stai cercando di aggiungere supervisione da camera o analytics in cloud in tempi stretti.
2. Stack moderni open source
Node-RED + InfluxDB + Grafana, spesso con Mosquitto per il brokering MQTT. United Manufacturing Hub per un bundle open source più opinato. HiveMQ per MQTT serio. Il costo di possesso è il tempo dei tuoi ingegneri, non una licenza. Il soffitto è alto e il pavimento è basso (serve qualcuno che sappia farlo girare).
Scegli se: hai un team interno a suo agio con il self-hosting, vuoi evitare il vendor lock-in e sei contento di pagare in ore di ingegnere invece che in dollari di licenza.
3. Piattaforme commerciali cloud-native
Tulip, Litmus Edge, HighByte, Cognite, Element, Cumulocity, AVEVA Data Hub. La promessa è la stessa per la maggior parte: TCO più basso del middleware SCADA legacy, tempo più breve alla prima dashboard, delivery nativa cloud, una storia IT decente per il procurement. Il pricing è per dispositivo o per flusso dati e si somma più in fretta di quanto i vendor ti diranno. UX e integrazioni IA variano molto tra vendor.
Scegli se: vuoi uno strumento moderno, non vuoi fare self-hosting, hai un budget per fee ricorrenti per dispositivo e hai un set chiaro di sorgenti dati da collegare entro dodici mesi.
4. Sistemi camera e IA-first
Una categoria più recente. Strumenti che trattano la camera come una sorgente dati di prima classe, non come un’aggiunta. La camera alimenta modelli di visione che contano pezzi, classificano difetti e rilevano anomalie di processo, e gli eventi risultanti vengono mostrati nella stessa pipeline dei dati PLC. Enao Vision sta qui. Altri entranti includono Augmentir, MakinaRocks e diversi plug-in MES specializzati per visione.
Scegli se: il tuo collo di bottiglia è la visibilità su quello che la linea sta davvero facendo (non solo quello che il PLC pensa stia facendo) e vuoi uno strumento che tratti dati da camera e dati PLC come pari.
5. Integrazioni fatte in casa
Molti stabilimenti girano su script Python che pingano un client OPC UA, scaricano CSV su una share di rete e ci mettono sopra qualche report Power BI. Non è una categoria di strumenti, è l’assenza di una, ma merita un nome perché su piccola scala funziona. Smette di funzionare quando lo script si rompe alle due di notte e nessuno sa come sistemarlo.
Scegli se: hai una o due linee, un ingegnere che mantiene gli script e zero budget. Passa a una delle categorie da 1 a 4 appena hai complessità in crescita o una seconda persona che deve mantenere il sistema.
Dove ogni categoria si rompe
Il middleware SCADA classico si rompe sui dati da camera e sulla delivery cloud. Aggiungere un sistema di visione a un server PI sembra una pezza. Tirare fuori i dati verso un data warehouse cloud aggiunge costi di licenza e di ingegneria che la maggior parte dei team sottostima.
Gli stack open source moderni si rompono sulle persone, non sulla tecnologia. Girano benissimo quando un ingegnere specifico è in azienda e smettono di girare quando quell’ingegnere se ne va. Il costo per far imparare lo stack al secondo ingegnere è quasi sempre più alto di un anno di licenze commerciali.
Le piattaforme commerciali cloud-native si rompono sulla trasparenza dei prezzi. Il listino è raramente il prezzo reale, e il prezzo reale cresce con l’uso in modi che non sono ovvi nel proof of concept. Si rompono anche sui casi limite: il protocollo PLC della lunga coda che il vendor non supporta ancora, la policy IT locale che vieta l’egress in cloud, la linea che gira su un controllore del 1998 senza porta Ethernet.
I sistemi camera e IA-first si rompono quando i dati PLC esistenti sono abbastanza buoni e la camera aggiunge rumore senza valore. Si rompono anche quando l’illuminazione e il montaggio alla linea sono sbagliati (lo stesso problema di qualunque sistema di visione).
L’integrazione fatta in casa si rompe alla prima settimana di vacanza della persona che l’ha scritta.
Come scegliere per uno stabilimento specifico
Tre domande in ordine. Quali sorgenti dati devi collegare oggi e quali dovrai collegare tra diciotto mesi? Dove devono atterrare i dati (un historian, un data warehouse cloud, uno strumento BI, un modello di IA)? Chi mantiene il sistema e qual è la sua tolleranza per la complessità self-hosted?
Uno stabilimento con venti macchine collegate via PLC, un historian PI già installato e un piccolo team IT dovrebbe probabilmente estendere quello che ha. Uno stabilimento con cinque linee, nessun historian, voglia di analytics in cloud e disponibilità a pagare per dispositivo dovrebbe guardare la categoria commerciale cloud-native. Uno stabilimento il cui gap di visibilità più grosso è cosa succede sulla linea oltre quello che il PLC riporta dovrebbe guardare i sistemi camera e IA-first. Uno stabilimento con un ingegnere e una linea va bene con il fatto in casa finché l’ingegnere non prende ferie.
L’errore è scegliere per riconoscibilità del brand invece che per risposta a queste tre domande. La risposta giusta è raramente la stessa dello stabilimento accanto.
Costi nel 2026
Ordine di grandezza approssimativo per uno stabilimento medio (10-30 macchine collegate).
SCADA classico: 100k-400k EUR iniziali più 15-25 percento di manutenzione annuale.
Open source moderno: 0 EUR di licenza più 1-2 ingegneri a tempo pieno (quindi 100k-200k EUR all’anno di costo caricato).
Commerciale cloud-native: 30k-150k EUR all’anno di abbonamento a seconda del tier per dispositivo o per flusso dati.
Camera e IA-first: 5k-20k EUR per linea all’anno di abbonamento, più un costo di setup una tantum nell’ordine di 1-5k per linea per l’hardware che fa girare la camera.
Fatto in casa: il costo del tempo di un ingegnere e il rischio di guasto catastrofico quando se ne va.
Questi intervalli sono ampi perché i numeri reali dipendono dalla negoziazione, dal volume e dagli sconti di fine trimestre. Trattali come orientamento, non come preventivi.
Primer da campo: cosa c’è davvero dentro un sistema di acquisizione dati
Un sistema di acquisizione dati funzionante nel 2026 è uno stack, non un singolo prodotto. Dare un nome ai pezzi aiuta quando ti siedi di fronte a un vendor e la demo glissa sulla metà di loro.
Allo strato sensori, gli ingressi sono tipicamente un mix di termocoppie e RTD per la temperatura, trasduttori di pressione, trasduttori di vibrazione, trasduttori di flusso e trasduttori di corrente e tensione usati per l’analisi di potenza. Ogni segnale sensore viene condizionato (il signal conditioning include amplificazione, isolamento e filtraggio) e convertito da analogico a digitale da convertitori analogico-digitali. Il flusso convertito porta poi un numero seriale della sorgente, un timestamp e le unità ingegneristiche, e viene passato a chi lo consuma.
L’hardware DAQ che fa quella conversione viene in tre forme. Data logger e registratori autonomi che salvano le letture in memoria interna per scaricarle dopo (il workflow di data logging più semplice, ancora comune su pompe remote, generatori e impianti HVAC). Hardware DAQ modulare su backbone Ethernet o USB che fa streaming verso un host (la forma dominante in laboratori di test e su banchi R&D). E front end di controllori a logica programmabile che combinano un piccolo stack DAQ con la logica di controllo sullo stesso dispositivo (la forma dominante sulle linee di produzione).
Sopra l’hardware sta il software DAQ. Fa tre lavori che si sovrappongono a quello che fa uno strumento di acquisizione dati macchina alla scala dello stabilimento. Configura i canali (frequenza di campionamento, range, filtraggio). Registra e salva i dati di processo (spesso su un host Linux che fa anche girare l’historian). E mostra le letture agli operatori tramite grafici in tempo reale, dashboard e allarmi. Lo strato utente è costruito in una gamma di linguaggi di programmazione: C e C# per gli stack legacy, Python e JavaScript per le dashboard web moderne, più una lunga coda di ambienti di scripting di vendor (LabVIEW, Codesys structured text, Beckhoff TwinCAT).
La ragione per cui questo primer conta per il buyer di stabilimento è che le stesse parole vogliono dire cose diverse a scale diverse. Un test engineer in un laboratorio R&D batterie che dice “DAQ” intende di solito uno chassis National Instruments PXI con uno stack di moduli analog input e LabVIEW sopra. Un responsabile operations in uno stabilimento di confezionamento che dice “acquisizione dati macchina” intende di solito un pezzo di middleware che tira dati da venti PLC e li passa a una dashboard e a un modello di IA. Entrambi hanno ragione, entrambi usano le stesse parole, e i vendor che vendono a entrambi i segmenti parlano in termini deliberatamente ambigui. Quando un commerciale ti parla di DAQ, chiedi se intende lo stack sensore-convertitore o lo strato PLC-dashboard. La risposta determina se lo strumento funziona per te.
I team di controllo qualità usano i dati DAQ in modo più aggressivo di qualunque altra funzione. I dati sono la prova in ogni CAPA, ogni audit fornitore, ogni reclamo cliente che richiede tracciabilità. Uno stabilimento che fa controllo qualità su registri scritti a mano sta in un decennio diverso da uno che lo fa sul sistema di acquisizione dati. Il passaggio dall’uno all’altro è quello che questo software sta davvero vendendo, anche quando viene venduto come produttività o come visibilità.
FAQ
MQTT è la stessa cosa di uno strumento di acquisizione dati macchina? No. MQTT è un protocollo di trasporto. Uno strumento di acquisizione dati macchina usa tipicamente MQTT (o OPC UA, o protocolli proprietari) come uno dei suoi strati di trasporto. Strumenti e protocolli sono cose diverse.
Mi servono sia un historian sia uno strumento di acquisizione dati macchina? In uno stabilimento piccolo, no. In uno stabilimento grande con dati PLC ad alto volume, sì. L’historian è ottimizzato per la memorizzazione e il recupero di serie temporali ad alta cadenza. Lo strumento di acquisizione è ottimizzato per portare i dati lì e ad altri consumatori.
Cos’è OPC UA e mi serve? OPC UA è lo standard aperto moderno per lo scambio dati macchina-a-macchina. La maggior parte degli strumenti di acquisizione lo parla. Ti serve se le tue macchine lo supportano (la maggior parte dei PLC moderni lo fa). Per macchine più vecchie si ripiega sui protocolli specifici del brand.
Come si incastra con il nostro MES o ERP? Lo strumento di acquisizione alimenta il MES con dati macchina in tempo reale. Il MES alimenta l’ERP con dati di produzione aggregati. Lo strumento di acquisizione è a monte di entrambi.
Parti dal gap di visibilità
Lo strumento giusto dipende dal gap. Se il gap sono dashboard da dati PLC, vai su commerciale cloud-native o open source. Se il gap è il reporting enterprise da un grande parco macchine, resta con lo stack classico e estendilo. Se il gap è sapere cosa la linea sta davvero facendo oltre quello che il PLC riporta, parti dalla categoria camera e IA-first e pensa al resto dopo.
Per uno sguardo più approfondito a cosa ti compra la supervisione da camera, vedi supervisione produzione da camera. Per come si incastra in un programma di visibilità più ampio, vedi sistema di supervisione produzione.
Apri un account gratuito o unisciti alla community per confrontare stack di acquisizione dati con colleghi di altri stabilimenti.
Unisciti alla community
Gestiamo una community Slack gratuita per builder di stabilimento, responsabili miglioramento continuo e gente delle operations che vuole confrontare stack di acquisizione dati in chiaro. Unisciti alla community.
