Quando un progetto di AI industriale fallisce, l’autopsia tipica si concentra sul modello, sul dataset, sulla pipeline ML. Quasi mai sul punto in cui il dato è nato: il sensore, il front-end analogico, il circuito di acquisizione, il firmware di campionamento, il gateway. Eppure è lì che si decide la qualità del dato, e con essa il limite massimo di ciò che qualsiasi algoritmo potrà estrarre. Un modello addestrato su sequenze con jitter di campionamento di decine di millisecondi, con sensori che derivano in temperatura senza compensazione, con timestamp generati a valle invece che alla sorgente, non potrà mai funzionare bene. Indipendentemente da quanto sofisticato sia. Per chi progetta elettronica industriale, gateway IIoT, schede di acquisizione e firmware embedded, l’AI industriale non è un argomento di marketing: è un nuovo insieme di vincoli tecnici che entrano in fase di progettazione hardware e firmware. Questo articolo affronta la questione dal lato giusto.
Il sensore: dove si pone il limite fisico
Rumore, banda e dinamica
Un modello di anomaly detection non può rilevare una variazione se questa è sotto il pavimento di rumore del sensore. La banda passante, la densità spettrale di rumore in µV/√Hz o µg/√Hz e la dinamica utile del sensore determinano il limite fisico oltre il quale nessun algoritmo può estrarre informazione. È una considerazione che precede la scelta dell’ADC e qualunque elaborazione a valle.
Per il condition monitoring vibrazionale su cuscinetti volventi, le firme di guasto incipiente si trovano tipicamente nella banda 1-20 kHz, con ampiezze RMS che nelle prime fasi possono restare sotto i 10 mg. Per rilevare questi segnali serve una densità di rumore dell’accelerometro almeno un ordine di grandezza inferiore. I MEMS industriali moderni raggiungono 25-30 µg/√Hz (su banda piena, decine di kHz), competitivi con i piezoelettrici industriali nella fascia sotto i 10 kHz. Sopra questa soglia, e in ambienti ad alta temperatura, il piezo conserva un vantaggio strutturale. La scelta non è religiosa: dipende dalla banda di interesse e dal regime termico.
Lo stesso ragionamento vale per la corrente assorbita da un motore (analisi MCSA: banda significativa fino a 5 kHz), per la pressione in un circuito idraulico, per la temperatura di un componente. Ogni grandezza ha una firma significativa che si manifesta in una banda specifica con un livello utile noto. Sottostimare uno dei due parametri condiziona tutta la catena a valle.
Il front-end analogico e l’aliasing
Tra il sensore e l’ADC c’è il front-end analogico, ed è il punto della catena dove si commettono gli errori più costosi. Il filtro anti-aliasing non è opzionale: senza, le componenti spettrali sopra la frequenza di Nyquist vengono ripiegate nella banda utile, generando contenuto spurio indistinguibile dal segnale reale. Su un sistema che campiona a 50 kSPS con cutoff a 20 kHz, serve un filtro analogico che attenui di almeno 60-80 dB sopra i 25 kHz.
L’ordine e la topologia del filtro contano. Un Butterworth offre attenuazione monotona in ampiezza e roll-off netto, ma la sua risposta in fase non è lineare, con ritardo di gruppo che cresce vicino al cutoff. Un Bessel ha risposta in fase quasi lineare nella banda passante, importante per la fedeltà temporale della forma d’onda (utile per analisi di inviluppo o cross-correlation), ma roll-off meno ripido che richiede ordine più alto a parità di reiezione. Un Chebyshev raggiunge rapidamente la stessa reiezione con meno componenti, al costo di ripple in ampiezza nella banda passante. La scelta dipende dal tipo di analisi che il dato dovrà sostenere a valle. Per chi lavora con convertitori analogico-digitali, questi sono argomenti consolidati. Quello che cambia con l’AI è il valore d’uso: il filtro non protegge più solo la misura, protegge il dataset di training. Un modello addestrato su dati con aliasing imparerà l’aliasing.
Risoluzione effettiva: ENOB conta più dei bit nominali
La dinamica utile dell’ADC è il secondo punto critico. Un ADC a 16 bit con SNR effettivo di 70 dB ha ENOB pari a (70 − 1,76) / 6,02 ≈ 11,3 bit. I bit nominali contano poco: la risoluzione effettiva è limitata da rumore termico, jitter di clock, distorsione e PSRR del riferimento di tensione. Su un segnale che oscilla nell’1% del fondo scala, situazione tipica in regime stazionario, dove le anomalie sono piccole variazioni rispetto al baseline, un ENOB basso produce un output prevalentemente di rumore. La risoluzione sulle anomalie diventa marginale.
Sui sistemi destinati a coprire una grande dinamica con piccole variazioni significative, il dithering controllato (iniezione di rumore decorrelato prima dell’ADC) può migliorare la risoluzione effettiva di 1-2 bit grazie alla decorrelazione dell’errore di quantizzazione. È una tecnica nota nei sistemi di misura, ancora poco sfruttata sui gateway industriali.
Sincronizzazione: il problema più sottovalutato
Campionamento sincrono multi-canale
Quando l’analisi correla più segnali, vibrazione triassiale, corrente di fase, temperatura, posizione, la sincronizzazione tra canali è critica almeno quanto la qualità del singolo segnale. Un ritardo costante tra canali può essere compensato; un jitter variabile no.
A livello hardware, le opzioni sono tre. La prima: un singolo ADC con multiplexer e sample-and-hold sequenziale. È la soluzione più economica, ma introduce uno skew tra canali pari al tempo di conversione, accettabile solo su segnali a banda bassa. La seconda: ADC dedicati per canale con clock comune e trigger di start coerente, oppure ADC multicanale con sample-and-hold simultaneo (architettura standard sulle schede di acquisizione vibrazionale multi-asse). La terza: ADC distribuiti su nodi diversi, sincronizzati via PTP: soluzione necessaria su sistemi geograficamente estesi, con un jitter residuo che va caratterizzato e che limita le analisi che richiedono coerenza temporale stretta.
Cross-correlazione, beamforming, analisi modale richiedono coerenza temporale stretta tra canali: progettare la sincronizzazione dopo aver scelto l’ADC significa quasi sempre precludere queste classi di analisi.
Timestamping: dove si genera l’informazione temporale
Un dato senza timestamp coerente è inutilizzabile per qualunque analisi che vada oltre il singolo segnale. La domanda chiave non è “il dato ha un timestamp?”, ma “dove e quando è stato generato?”.
Le opzioni, in ordine crescente di qualità: timestamp generato dal client a valle (peggiore: include latenza di rete e jitter di processamento), timestamp generato dal server alla ricezione, timestamp generato dal gateway alla lettura del PLC, timestamp generato dal PLC al momento della scrittura del registro, timestamp generato dall’ADC stesso al momento della conversione (migliore: il più vicino possibile alla sorgente). Lo scarto tra il primo e l’ultimo caso può arrivare a centinaia di millisecondi su sistemi distribuiti.
La specifica OPC UA Part 4 distingue formalmente tra sourceTimestamp e serverTimestamp proprio per questo. Il sourceTimestamp deve essere generato il più vicino possibile alla sorgente del dato, in UTC, con risoluzione coerente con la dinamica del processo. Il serverTimestamp è una metadata aggiuntiva, non un sostituto. Quando un dispositivo espone un dato senza distinguere i due, l’integratore a valle sta lavorando con informazioni incomplete.
PTP e il problema del clock drift
Su LAN industriale, NTP con server locale raggiunge tipicamente accuratezze sotto il millisecondo. Sufficienti per logging applicativo, marginali per correlare eventi su scale temporali sotto i 100 µs. Il protocollo PTP (IEEE 1588) porta la sincronizzazione sotto il microsecondo se l’infrastruttura supporta boundary clock o transparent clock negli switch. Time-Sensitive Networking (TSN, IEEE 802.1) integra PTP nativamente a livello di rete di campo.
Per dispositivi battery-powered o periodicamente disconnessi, il problema è opposto: mantenere l’accuratezza temporale in assenza di un master. Un oscillatore al quarzo standard ha tipicamente una deriva di 20-50 ppm, equivalente a qualche secondo al giorno e variabile con la temperatura. Un TCXO scende a 1-2 ppm, un OCXO a frazioni di ppb, al costo di consumo e dimensioni. Su un data logger che acquisisce per ore prima di riconnettersi, la scelta dell’oscillatore di riferimento ha conseguenze dirette sull’allineamento temporale dei dati al momento della riconciliazione.
L’edge: trasformare il dato, non solo trasportarlo
Decimazione e feature extraction locale
Spingere tutti i dati grezzi verso il cloud è una scelta architetturale costosa e raramente sensata. Un accelerometro a 26 kSPS su 3 assi a 16 bit produce circa 9 MB/minuto per nodo: su 50 pompe, oltre 600 GB al giorno. Cifre che rendono insostenibile il trasferimento in continuo e costoso anche lo storage cloud.
Il pattern consolidato non è “campionare meno”, ma “elaborare di più all’edge”. La decimazione con filtro digitale a finestra mobile riduce la frequenza di campionamento conservando la banda significativa: campionando a 26 kSPS e filtrando-decimando di un fattore 13 si ottengono 2 kSPS con banda passante fino a 1 kHz, sufficiente per molte applicazioni di trend monitoring. La FFT calcolata localmente su finestre temporali consente di trasmettere uno spettro al posto della forma d’onda, riducendo i dati di due ordini di grandezza. Feature statistiche (RMS, kurtosis, fattore di cresta, skewness, energia in banda) compresse a pochi byte per finestra portano la riduzione a tre ordini di grandezza.
La pipeline ML lavora poi su questi aggregati, già etichettati con il contesto operativo (stato macchina, ordine in corso, regime). La banda si riduce drasticamente, lo storage si controlla, e il dato arriva al modello con un livello di pre-processing tracciabile e versionabile. Il segnale grezzo si conserva solo su trigger: allarme superato, anomalia rilevata, finestra di acquisizione programmata per diagnosi approfondita.
Storage time-series sul gateway: cosa scegliere e perché
Sull’edge serve uno storage che regga acquisizioni continue ad alta frequenza, query temporali e politiche di retention. Le opzioni si dividono in due famiglie. I database relazionali tradizionali (PostgreSQL, SQLite) sono adatti per dati di contesto a bassa cardinalità (ordini, configurazioni, eventi discreti) ma soffrono con serie temporali ad alta frequenza per overhead di indici e gestione delle scritture. I database time-series (InfluxDB, TimescaleDB, VictoriaMetrics) sono ottimizzati per scritture sequenziali ad alto rate, compressione efficiente di dati numerici e query su finestre temporali.
Per chi progetta sistemi embedded per l’industria con memoria limitata, esistono alternative leggere: storage circolari in memoria, file binari con indice, formati colonnari embedded come Apache Parquet. La scelta dipende da quanto storico si vuole tenere localmente, da quante feature si calcolano e dalla strategia di sincronizzazione con il backend.
Store-and-forward e gestione della disconnessione
Una rete industriale non è sempre disponibile. Switch in manutenzione, modem cellulari in roaming, link wireless con interferenze, finestre di blackout pianificate: la disconnessione non è eccezione, è normalità. Un gateway che perde dati durante la disconnessione introduce buchi nel dataset che il modello a valle non può recuperare.
Il pattern store-and-forward è la risposta: il gateway accumula localmente i dati durante l’indisponibilità del backend, poi li trasmette quando la connessione torna. Le decisioni di progetto sono concrete: dimensionamento dello storage locale rispetto al worst-case di disconnessione (giorni, non ore), strategia di gestione dei dati più vecchi quando lo storage si riempie (drop oldest, drop newest, compressione progressiva), preservazione dei timestamp sorgente al momento della trasmissione differita, gestione delle duplicazioni in caso di trasmissione interrotta a metà.
Per chi sviluppa firmware di gateway, la disciplina del backlog è uno dei punti che separano un prodotto industriale serio da un prototipo travestito. La verifica di queste capacità in fase di collaudo, con scenari di disconnessione forzata di durata variabile, è una delle prove più sottovalutate.
Identità e contesto: dare significato al numero
Un valore numerico senza identità è inutile. La temperatura di un cuscinetto deve essere collegata a: identità univoca della macchina (codice persistente nel tempo, non solo “macchina 3” che può cambiare significato dopo una riconfigurazione), identità del componente specifico, stato operativo nel momento della misura, qualità del dato (valido, sensore in fault, fuori range), contesto produttivo (ordine, ricetta, fase, operatore).
Questa contestualizzazione si costruisce a livello di firmware del gateway o del PLC, non di analytics. Il PLC che pubblica T_BEARING_03 = 67.4 espone un numero. Il PLC che pubblica un oggetto strutturato con identità, stato, qualità, timestamp e contesto espone un’informazione utilizzabile.
OPC UA offre lo strumento concreto per questa contestualizzazione: le Companion Specifications, modelli informativi standard per famiglie di macchine utensili, robot, sistemi di visione, pesatura, confezionamento. Usarli significa parlare un linguaggio condiviso invece di inventare uno schema ad hoc per ogni progetto, ed entrare in un ecosistema dove un integratore può collegare la macchina senza driver custom.
Sul fronte del trasporto e della distribuzione dei messaggi, la scelta dei protocolli industriali (OPC UA PubSub, MQTT con Sparkplug, DDS-XRCE) è una decisione architetturale separata e con compromessi non banali, che abbiamo approfondito in un articolo dedicato.
Cybersecurity: ogni dato esposto è una superficie di attacco
Un dispositivo OT che fino a ieri era isolato in una rete di campo, una volta esposto su MQTT o OPC UA diventa raggiungibile da chiunque abbia accesso al broker o al server. Le conseguenze di un compromesso vanno dalla manipolazione del processo all’esfiltrazione di proprietà intellettuale. La serie ISO/IEC 62443 definisce il framework di riferimento e per progetti di una certa dimensione la conformità è ormai requisito contrattuale.
A livello di progettazione hardware e firmware, gli elementi essenziali sono pochi e non negoziabili: autenticazione mutua con mTLS e certificati X.509 (con rotazione e revoca, non chiavi hardcoded), autorizzazione granulare per ruolo, segregazione di rete, logging strutturato degli accessi. E soprattutto un meccanismo di firmware update sicuro previsto fin dal day one. Un dispositivo industriale ha un ciclo di vita di 10-20 anni; senza secure boot e OTA con anti-rollback, diventa legacy molto prima della fine della vita utile.
Cosa fa davvero la differenza
Il modello ML è l’ultimo anello della catena, e raramente il punto debole. Il punto debole quasi sempre sta più a monte: in un sensore con pavimento di rumore inadeguato al fenomeno, in un filtro anti-aliasing dimensionato male, in un ADC con ENOB troppo basso per la dinamica utile, in canali multi-segnale senza sincronizzazione hardware, in timestamp generati a valle invece che alla sorgente, in oscillatori senza compensazione su dispositivi disconnessi, in pipeline di decimazione non documentate, in store-and-forward che perde dati al riempimento del buffer.
Per chi progetta elettronica industriale, è una buona notizia. La competenza che fa la differenza in un progetto di AI industriale è l’ingegneria del segnale, del firmware embedded e dei sistemi di acquisizione. Sono competenze consolidate che oggi trovano un nuovo ambito di valore: il dato come prodotto, non come effetto collaterale della misura. Il modello arriverà comunque. La catena, prima del modello, va costruita bene.
