Storici e AI: aggiungere un livello time-series senza sostituirli

Il 5 ottobre 2026 IIoT World ha pubblicato una guida di 22 pagine di InfluxData, indicata come "Sponsored by InfluxData", sul tema dei dati nella produzione automotive. Va letta per ciò che è: marketing di un fornitore, non giornalismo indipendente. Inoltre mi baso solo sul riassunto pubblicato da IIoT World, non ho letto la guida completa.

Il problema descritto

La tesi di partenza è che i volumi di dati nelle moderne linee di assemblaggio dei veicoli superino ciò per cui i vecchi historian sono stati progettati. Il riassunto elenca alcune criticità ricorrenti:

• la licenza per tag trasforma ogni nuovo sensore in una decisione di costo;
• le architetture proprietarie intrappolano i dati di qualità in silos a livello di stabilimento;
• i flussi di esportazione batch frenano l'analisi in tempo reale necessaria alla manutenzione predittiva;
• sostituire tutto è rischioso: un fermo linea può generare in poche ore mancato takt, penali JIT e fermi presso il cliente OEM.

L'approccio proposto: affiancare, non sostituire

La guida suggerisce di mantenere l'historian esistente e aggiungere InfluxDB come livello time-series parallelo, in modo che la produzione continui mentre entrano in servizio nuove funzioni. Sono descritti due modelli di adozione:

• Parallel feed: Telegraf, collettore open source con plugin per OPC-UA, MQTT e Modbus, invia i dati dei nuovi sensori a InfluxDB in parallelo all'historian. Nuova strumentazione, robot e programmi di lancio evitano così la licenza per tag.
• Historian consolidation: i dati di più historian scollegati confluiscono in un unico livello interrogabile, utile per benchmark tra stabilimenti e indagini di garanzia.

Flussi dati e integrazioni citati

Per l'automotive vengono indicati esempi per reparto: stampaggio (tonnellaggio, temperatura stampi, vibrazioni), lamiera e saldatura (dati giunti KUKA/FANUC, corrente di saldatura a punti), verniciatura (livelli vasca e-coat, temperature forni, HVAC) e assemblaggio finale (avvitatori Atlas Copco, AGV, test a fine linea al banco a rulli).

Tra le integrazioni: PTC incorpora InfluxDB come livello di persistenza in ThingWorx, Kepware invia dati OPC a InfluxDB 3, Rockwell porta dati dei PLC Allen-Bradley tramite FactoryTalk Optix e View SE, mentre Litmus Edge gestisce mappatura dei tag e contesto degli asset tra i siti.

Il lato AI e i casi citati

Sul fronte AI, un InfluxDB MCP Server permetterebbe agli ingegneri di interrogare le metriche di produzione in linguaggio naturale, senza scrivere SQL né gestire lo schema. Tra i casi, riportati dal fornitore e non verificati: Toyo Tires, passata da 100 macchine in uno stabilimento in Serbia fino a 1.000 macchine su più siti, con rilevamento anomalie in tempo reale e conservazione dei dati per 20 anni; Gotion, produttore di batterie EV, per analisi e machine learning nella produzione di celle; American Axle & Manufacturing, con quasi 85 stabilimenti in 18 paesi, che usa InfluxDB, Telegraf e Grafana.

Perché conta

Al di là del prodotto, il valore sta nel pattern: raccolta all'edge via OPC-UA o MQTT, approccio brownfield, nessun fermo linea. È un modo pragmatico per portare dati di PLC e historian in un livello pronto per l'AI, rispettando linee validate e certificate IATF 16949. Il tema si collega al principio "prima i dati, poi l'AI", qui declinato sull'architettura degli historian.

Le affermazioni su costi e prestazioni provengono dal fornitore: vanno verificate con un test pilota.

Indicazione pratica

Prima di valutare qualsiasi piattaforma, conviene verificare quanto la licenza per tag limiti oggi la strumentazione, quali silos blocchino analisi trasversali e se i protocolli aperti già disponibili coprano i nuovi asset. Un flusso parallelo su una singola linea o su un nuovo programma di lancio, senza toccare l'historian validato, è un test a basso rischio per misurare costi, latenza e qualità dei dati con numeri propri.