Tre sogni per una fabbrica diversa

Esistono tre cose che chiunque abbia mai messo in funzione una macchina industriale si è chiesto almeno una volta. Tre cose che non si dicono ad alta voce perché sembrano utopie. Questo articolo le mette in fila.

Una scena, tanto per cominciare

Turno di notte, reparto X. Una linea si ferma. Il pannello HMI mostra un codice: E-1423. Il manuale sta in un armadio a tre edifici di distanza. Il tecnico che conosce quella macchina è in ferie. L'operatore ha due strade: chiamare il servizio di assistenza — che risponde forse al mattino — o tirare a indovinare. In tutto il mondo industrializzato, scene come questa si ripetono centinaia di volte a notte.

Il problema non è che manca un manuale. Manuali ce ne sono troppi. Il problema è che la macchina sa benissimo cosa le serve — il sensore della pressione le sta dicendo da trenta secondi che qualcosa è storto — ma non riesce a parlare una lingua che l'operatore capisca, e quando riesce a parlarla racconta il problema invece della soluzione. "Pressione fuori range" non è una frase utile alle tre di notte. "Verifica la valvola V12 del circuito aria, probabilmente si è incollata" lo è.

Da qui parte il lavoro che stiamo facendo. Non un nuovo PLC. Non un HMI più bello. Un modo diverso di pensare a cosa dovrebbe essere, nel 2026, il software che fa muovere una macchina. E tre idee fisse — chiamatele pure sogni — che stiamo provando a tenere insieme.

Sogno numero uno: automatizzare senza programmare

L'automazione industriale, così com'è fatta oggi, richiede una figura molto particolare: qualcuno che sappia programmare in un linguaggio — la famiglia IEC 61131-3, con i suoi dialetti ladder, function block, structured text — che non si usa praticamente da nessun'altra parte nel mondo del software. Chi sa quei linguaggi è raro, è caro, ed è quasi sempre in ritardo di tre settimane.

Il paradosso è che chi conosce davvero la macchina spesso non è il programmatore. È il capo reparto, il manutentore anziano, l'integratore che ha installato venti impianti simili. Queste persone sanno cosa deve fare la macchina. Non hanno nessuna voglia di imparare un linguaggio di programmazione nato negli anni '90 per spiegarlo.

L'idea è ribaltare la catena. Gli sviluppatori software scrivono componenti riutilizzabili — controllo di moto, gestione dei sensori, sequenze operative — una volta sola, in linguaggi moderni e general-purpose. L'integratore di macchina non li programma: li compone, specificando a voce o per iscritto cosa la macchina deve fare. Un modello linguistico di grandi dimensioni — un LLM — fa da traduttore: prende la specifica funzionale dell'integratore e la trasforma in una configurazione eseguibile, assemblando i componenti già scritti e testati.

Non è la fantasia di "l'AI che scrive il codice al posto tuo". È qualcosa di più modesto e più realistico: l'AI che legge la tua specifica e sceglie, tra componenti certificati, come combinarli. Il codice critico — quello che muove un asse con un ciclo di 5 millisecondi — continua a scriverlo un essere umano, in un linguaggio che garantisca determinismo e affidabilità. Ma quel codice viene scritto una volta per tutte e riutilizzato cento volte.

Sogno numero due: la macchina che sa di sé

Oggi le macchine parlano poco, e male. Un allarme è un codice numerico. Una diagnostica è una serie di LED. Un log è un file binario che solo il produttore sa aprire. La conoscenza di come funziona quella macchina, con quelle tolleranze, dopo quei duemila cicli, sta nella testa di una persona, o in un PDF da qualche parte.

Il secondo sogno è che sia la macchina a conoscersi. Non in senso mistico — in senso molto concreto: la documentazione tecnica, i parametri di processo, i casi di guasto tipici, le procedure di intervento non stanno più in un armadio o in un server documentale separato, ma dentro la macchina stessa, leggibili dal suo stesso software. E quando qualcosa non va, la macchina non dice "errore 1423". Dice "la valvola V12 probabilmente si è incollata, dovresti verificarla; nel frattempo posso proseguire in modalità degradata al 60% della velocità".

La differenza è tra un oggetto passivo che segnala e un oggetto attivo che propone. Il primo lascia il problema all'operatore. Il secondo lo affronta insieme a lui.

Questo richiede due cose poco scontate. Primo, che la conoscenza della macchina — storicamente custodita in manuali, schemi elettrici, disegni CAD e teste di tecnici — venga formalizzata e integrata nel sistema. Secondo, che il sistema abbia un interlocutore in grado di reggere una conversazione: di nuovo, un LLM, usato qui non per generare codice ma per tradurre sintomi in azioni comprensibili, nella lingua di chi sta davanti al pannello.

Ancora una volta, non è magia. È documentazione scritta meglio, indicizzata meglio, e un'interfaccia conversazionale sopra. Ma cambia tutto per chi fa il turno di notte.

Sogno numero tre: il software che gira ovunque

Il terzo sogno è il più tecnico e, paradossalmente, il più politico. Oggi l'automazione industriale è un mondo di ecosistemi chiusi. Ogni grande produttore di PLC ha il suo linguaggio, il suo ambiente di sviluppo, il suo hardware, i suoi driver, la sua rete di rivenditori. Cambiare fornitore significa riscrivere tutto.

L'ambizione qui è costruire un sistema software che giri su hardware generico — un mini-PC industriale, un controllore embedded, un server in cantina — scegliendo l'hardware in base al budget e alle prestazioni necessarie, non in base a quale marca di PLC ha vinto la trattativa. Un sistema operativo Linux in versione real-time, schede di comunicazione basate su standard aperti (EtherCAT su tutti), componenti software in linguaggi moderni per le parti deterministiche e in linguaggi più agili per quelle che non lo sono.

La regola, e qui è dove l'utopia si fa concreta: l'hardware deve incidere sulle prestazioni, mai sull'affidabilità. La stessa logica, su una macchina meno potente, deve funzionare in modo identico — solo più lentamente. Se il tempo di ciclo passa da 5 a 10 millisecondi, l'asse si muove con la stessa precisione ma a metà velocità. Mai "quasi uguale". Mai "funziona tranne in quel caso". Stesso sistema, stesse decisioni, stesse garanzie.

Questa è la parte in cui ingegneri esperti si mettono a ridere. Sanno benissimo che il real-time è difficile, che Linux non è nato come sistema real-time, che gli LLM non girano su un Raspberry Pi, che mischiare linguaggi diversi nello stesso stack ha più insidie di quante ne promettano i tutorial. Hanno ragione. Ma la direzione è quella, e i mattoncini per costruirla — le estensioni real-time del kernel Linux, stack EtherCAT open source maturi, LLM che iniziano a girare su hardware modesto — esistono, oggi, per la prima volta tutti insieme.

Perché "utopia"

Utopia è una parola onesta. Nessuna di queste tre cose è, oggi, un prodotto finito. La prima richiede LLM abbastanza affidabili da essere usati in un contesto produttivo, e siamo ai primi passi. La seconda richiede un lavoro enorme di formalizzazione della conoscenza industriale, che oggi è quasi tutta informale. La terza richiede di costruire alternative aperte contro ecosistemi chiusi che hanno vent'anni di vantaggio.

Ma i tre sogni insieme, se messi in fila, disegnano una direzione precisa: un'automazione in cui l'hardware è commodity, il software è riutilizzabile, la conoscenza è embedded nella macchina, e la figura del programmatore PLC — oggi collo di bottiglia di un'intera industria — non scompare, ma si sposta dove serve davvero, cioè a scrivere i componenti di base una volta per tutte.

Negli articoli che seguiranno racconteremo i pezzi che stiamo costruendo di questo puzzle. Uno per volta, senza promettere che il puzzle sia completo. Non lo è. Ma il disegno si inizia a vedere.