Come far parlare SCADA e MES con .NET e OPC UA: il dato giusto al momento giusto

La linea produce.

I dati esistono.

Ma SCADA e MES non si parlano, e in mezzo c'è un foglio di carta.

L'integrazione SCADA-MES con OPC UA e .NET serve esattamente a togliere quel foglio: un middleware scritto in C# si collega come client al server OPC UA dello SCADA, riceve i valori di processo appena cambiano, li traduce nel formato che il MES si aspetta e li scrive.

Nessuna trascrizione, nessun ritardo di ventiquattr'ore.

Sono le otto di mattina.

Il responsabile di produzione apre il MES e legge che il lotto 4872 è "In corso".

Punto.

Non sa se la macchina sta girando davvero, se la temperatura è dentro specifica, se nelle ultime due ore sono usciti scarti.

Quelle informazioni esistono tutte, aggiornate al secondo, dentro uno SCADA che sta a trenta metri dalla sua scrivania.

Nessuno le ha mai collegate.

Così parte il rito.

L'operatore telefona al capolinea.

Il capolinea guarda il monitor e trascrive a mano sul foglio di reparto.

Il foglio diventa un Excel.

L'Excel entra nel MES il giorno dopo.

Quando il numero arriva a chi deve decidere, ha già ventiquattr'ore.

Le decisioni si prendono lo stesso, ogni giorno, su ogni linea.

Non è la slide di un convegno sull'Industria 4.0.

È la giornata normale di centinaia di stabilimenti italiani nel 2026, dalla piccola azienda con una linea sola al gruppo con sei stabilimenti e un MES diverso per ognuno.

Ho visto questa scena decine di volte, e la parte che mi colpisce non è mai la tecnologia.

È che dentro l'azienda lo sanno già tutti.

Lo sa il capolinea, lo sa il responsabile di produzione, lo sa il direttore di stabilimento.

Quello che manca è la persona capace di stare in mezzo, perché chi scrive C# non ha mai visto un PLC da vicino e chi conosce il PLC non ha mai scritto un servizio che deve reggere trecentosessantacinque giorni l'anno senza che nessuno lo guardi.

Qui trovi come si costruisce quel collegamento: la mappa dei livelli, l'architettura che regge in produzione, come si scrive il client OPC UA in C#, e i tre o quattro dettagli che decidono se il sistema sopravvive al primo aggiornamento notturno del MES.

Se lavori già con C# e .NET, la distanza da colmare è più corta di quanto sembri.

Il primo passo però è capire perché due sistemi che stanno nello stesso capannone siano nati per non parlarsi.

Cos'è il MES e come si posiziona rispetto allo SCADA nella piramide produttiva ISA-95

In sala controllo ci sono due schermi affiancati.

Uno mostra il forno che respira, l'altro mostra l'ordine di produzione numero 4872.

Sono a venti centimetri di distanza e non si sono mai rivolti la parola.

Il MES è il livello 3 della piramide ISA-95: sta sopra lo SCADA, che è il livello 2, e sotto l'ERP, che è il livello 4.

Lo SCADA guarda la macchina, il MES governa l'ordine di produzione, l'ERP tiene i conti.

ISA-95 è lo standard internazionale che stabilisce chi sta a quale piano e quali informazioni passano da un piano all'altro.

Il modo più veloce per capirla è seguire un numero solo mentre sale.

Prendi la temperatura della zona 3 del forno 1.

Nasce al livello 0 e 1, dove ci sono il sensore, il cavo, la scheda di ingresso e il PLC che chiude il suo ciclo di controllo in millisecondi: lì il numero è ancora solo una tensione tradotta in gradi.

Sale di un piano e arriva al livello 2, lo SCADA.

Qui il numero diventa qualcosa che un essere umano può guardare: finisce su un sinottico, alimenta un grafico, fa scattare un allarme se esce di soglia.

L'orologio dello SCADA batte a secondi.

Un piano ancora e c'è il livello 3, il MES.

Al MES della singola misura non importa niente.

Al MES importa sapere che quella temperatura apparteneva al lotto 4872, prodotto con la ricetta B, sulla linea 1, nel turno di notte.

Il suo orologio batte a turni.

All'ultimo piano, il livello 4, c'è l'ERP: SAP, Oracle, Microsoft Dynamics.

Lì la temperatura del forno non esiste più.

Esistono i pezzi conformi, il costo del lotto, la giacenza aggiornata.

L'orologio batte a mesi.

Lo stesso viaggio, visto tutto insieme, sta in quattro righe:

Ogni piano ha il suo orologio, ed è questa la vera difficoltà del mestiere: l'integrazione non è far viaggiare dei byte, è mettere d'accordo orologi che battono a velocità diverse senza che nessuno dei due rallenti.

Il MES fa il traduttore in tutte e due le direzioni.

Verso il basso prende dall'ERP l'ordine pianificato, cosa produrre, quanti pezzi, entro quando, e lo trasforma in istruzioni operative per la linea: numero di lotto, ricetta di processo, quantità obiettivo.

Verso l'alto restituisce il consuntivo: pezzi realmente prodotti, materie prime realmente consumate, non conformità realmente rilevate.

Nel mezzo tiene la tracciabilità dei lotti, la gestione delle ricette, i dati di qualità, il calcolo dell'OEE (Overall Equipment Effectiveness, il principale indicatore di efficienza produttiva), la gestione delle fermate e dei consumi.

Sono le funzioni che lo standard MESA International riconosce a questo livello.

Sul mercato italiano incontri Aveva MES (l'ex Wonderware), Siemens Opcenter, Aveva PI System, e i MES scritti in casa o da software house locali.

Nel farmaceutico si aggiunge la conformità GMP (Good Manufacturing Practice), che alza l'asticella su tracciabilità e audit trail al punto da rendere impensabile qualsiasi passaggio manuale.

Il pianerottolo tra il secondo e il terzo piano è esattamente il posto dove vive il middleware .NET di cui parla tutto questo articolo.

E dove non vive nessuno, quel pianerottolo lo occupa qualcun altro: un operatore con una penna in mano.

Il problema dell'integrazione SCADA-MES: dati duplicati, errori manuali e decisioni tardive

Fine turno, 22 e 10.

L'operatore guarda il monitor, scrive 1.240 sul foglio di reparto, mette la firma e va a casa.

Quel numero, da questo momento, comincia a peggiorare.

Senza integrazione lo stesso dato viene raccolto due volte, arriva al MES con ore o giorni di ritardo, e i due sistemi finiscono per raccontare due verità diverse sullo stesso turno.

Non è un fastidio organizzativo: è una perdita che nelle aziende strutturate finisce nei report al consiglio di amministrazione.

Segui quel 1.240 e vedi il danno accumularsi passo dopo passo.

Prima cosa: mentre lui scrive, il numero è già vecchio.

Il MES lo riceverà domani mattina, forse dopodomani.

Se in quel turno c'era un problema di qualità in corso, quando qualcuno se ne accorge la produzione è andata avanti per un altro turno intero.

Il ritardo non è un ritardo di informazione, è un ritardo di reazione.

Seconda cosa: la penna.

Il monitor diceva 1.204 e sul foglio è finito 1.240, perché alle dieci di sera due cifre si invertono e nessuno se ne accorge.

In un impianto farmaceutico un numero scambiato non è un errore di battitura, è un lotto che si blocca e un'indagine da chiudere per iscritto.

Terza cosa, la più insidiosa, perché non si vede: la discrepanza sistematica.

Lo SCADA conta i pezzi che passano sul sensore di fine linea.

L'operatore dichiara nel MES i pezzi confezionati.

La differenza dovrebbe essere lo scarto, ma spesso le due fonti contano in punti diversi della linea o chiamano "pezzo" due cose diverse.

Alla riunione del lunedì i due numeri non tornano e comincia la discussione su chi ha ragione.

Senza integrazione quella discussione non si chiude, perché non esiste un modo automatico di riconciliare i due conteggi.

Quarta cosa: qualcuno ha lavorato due volte.

Il dato è stato prodotto una volta dallo SCADA e digitato una seconda volta da un essere umano pagato per fare altro.

Doppio lavoro, doppio rischio, doppio costo, e uno dei due passaggi non aggiunge niente.

Ed è esattamente il doppio passaggio che un servizio .NET messo in mezzo ai due sistemi elimina una volta per tutte.

Le stime della Manufacturing Enterprise Solutions Association, l'associazione di settore che definisce gli standard MES, collocano tra il 5% e il 15% l'efficienza produttiva che le aziende manifatturiere perdono a causa di sistemi informativi non integrati. Su una linea che produce 2 milioni di euro di valore l'anno, significa tra 100.000 e 300.000 euro di valore non realizzato.

Poi c'è la parte che nessuno mette in un report, perché non si riesce a misurare: l'informazione che sparisce per strada.

Quando un operatore trascrive a mano, sceglie.

Sceglie cosa vale la pena riportare e cosa no.

Il picco di temperatura durato otto secondi non lo scrive.

La microfermata di novanta secondi non la dichiara, perché sotto i due minuti "non è una fermata vera".

Quelle cose restano nello SCADA e non arrivano mai al MES.

Il risultato è che la storia della produzione è incompleta per costruzione, e nessuno saprà mai dire quanto.

Il pezzo mancante non è la volontà di collegare i due sistemi.

È il collegamento stesso, e la cosa curiosa è che lo strumento per costruirlo è uno standard aperto che i costruttori di mezzo mondo hanno già messo dentro i loro prodotti, spesso a insaputa di chi li ha comprati.

Quella forbice tra il 5% e il 15% non compare in nessun bilancio con il suo nome vero.

Si chiama efficienza persa, e la paga l'azienda un turno alla volta mentre tutti guardano da un'altra parte.

Se vuoi essere tu quello che chiude il buco, e non quello che lo mette a verbale, si parte dal linguaggio con cui quel middleware si scrive: il Corso C#.

Esci sapendo costruire il servizio che sta in mezzo a due sistemi che non si parlano, non sapendo raccontare come funziona.

Intanto, in quello stabilimento, il foglio di carta continua a viaggiare.

OPC UA come standard di integrazione industriale: perché è la scelta giusta nel 2026

C'è un momento preciso, nella prima riunione di progetto, in cui qualcuno dice la frase: "facciamo che lo SCADA scrive un CSV su una cartella condivisa e il MES lo legge, in due giorni siamo a casa".

La frase è ragionevole.

In quella stanza però ci sono altre tre persone, e ognuna delle tre ammazzerà quella proposta per un motivo diverso.

OPC UA (OPC Unified Architecture) è lo standard IEC 62541 per la comunicazione tra sistemi industriali, ed è la scelta corretta nella grande maggioranza delle integrazioni SCADA-MES perché porta con sé tre cose che un CSV, un'API REST fatta in casa o un database condiviso non hanno: il significato del dato, la sicurezza dentro il protocollo, e gli aggiornamenti a evento invece dell'interrogazione continua.

La prima obiezione arriva dall'ingegnere di processo, e sembra una pignoleria: "87.3 di cosa?".

Il CSV trasporta numeri nudi.

Uno SCADA che espone i dati via OPC UA non espone un numero: espone un albero di nodi con tipo, unità di misura, intervallo ammissibile, descrizione e relazioni gerarchiche.

Il client non riceve "87.3", riceve la temperatura della zona 3 del forno 1, in gradi Celsius, con un intervallo ammesso tra 80 e 95.

Quel contesto è la differenza tra un dato e un'informazione, e su un CSV non ci sta.

La seconda obiezione arriva dal responsabile della sicurezza OT, e non è negoziabile: quella cartella condivisa deve essere raggiungibile sia dalla rete di fabbrica sia dalla rete aziendale.

Tradotto: hai appena disegnato un ponte tra i due mondi e ci hai messo sopra un lucchetto di plastica.

OPC UA prevede autenticazione con certificati X.509 e cifratura TLS dentro il protocollo stesso, non come strato aggiunto dopo.

È la sola cosa che rende accettabile l'attraversamento del confine tra rete OT e rete IT.

La terza obiezione arriva dall'amministratore dello SCADA e riguarda il carico.

Se il tuo software chiede ogni secondo il valore di duemila tag, il server SCADA fa duemila risposte al secondo per un impianto che magari cambia stato tre volte al minuto.

OPC UA rovescia il verso: il client crea una sottoscrizione, dichiara quali nodi vuole seguire e con quale variazione minima (il deadband, la banda morta sotto la quale non vale la pena disturbare nessuno), e poi tace.

È il server che chiama quando c'è qualcosa da dire.

Le tre obiezioni, messe in fila, sono anche la tabella con cui rispondere la prossima volta che qualcuno propone la cartella condivisa:

Aggiungi che OPC UA non è la trovata di un fornitore: è uno standard aperto mantenuto dalla OPC Foundation e adottato da Siemens, ABB, Rockwell, Schneider e Beckhoff.

Se lo SCADA espone un server OPC UA, il tuo client in C# si collega senza chiedere il permesso a nessun ufficio commerciale.

Esiste anche la modalità OPC UA PubSub, introdotta nelle versioni più recenti dello standard, che porta la comunicazione uno-a-molti su broker MQTT o AMQP: è la strada per le architetture in cui più sistemi, anche in cloud, devono consumare gli stessi dati di impianto.

Lo standard però ti dice solo come parlare.

Non ti dice dove mettere il software che parla, e la risposta che sembra più economica, collegare il MES direttamente allo SCADA, è la stessa che fa saltare i progetti dodici mesi dopo, quando nessuno si ricorda più chi ha deciso cosa.

Architettura dell'integrazione SCADA-MES con .NET: i componenti del sistema

Venerdì sera il reparto IT aggiorna il MES.

È un aggiornamento normale, testato, autorizzato.

Lunedì mattina lo SCADA non riceve più i parametri di lotto e la linea parte in manuale.

Nessuno ha sbagliato niente: è la prova che i due sistemi erano legati con lo spago.

L'architettura corretta mette un middleware .NET in mezzo: lo SCADA espone i dati di processo attraverso il suo server OPC UA, un'applicazione C# si collega come client, riceve, traduce e scrive nel MES attraverso le sue API.

SCADA e MES non si toccano mai direttamente, e questo è il punto dell'intero disegno.

La ragione è che i due sistemi vivono a velocità diverse anche nella manutenzione.

Toccare uno SCADA in produzione significa finestra programmata, test estensivi e firma del responsabile di impianto: succede una volta l'anno, se succede.

Il MES segue i cicli di rilascio normali dell'IT, quindi cambia molte volte l'anno.

Legarli insieme vuol dire consegnare la continuità della fabbrica al calendario di rilascio di una squadra che non sa nemmeno di averla in mano.

Il modo più onesto di descrivere l'architettura non è elencare i componenti, ma raccontare come nascono.

Parti da un servizio Windows vuoto in .NET, e ogni pezzo che aggiungi lo aggiungi perché qualcosa è andato storto.

Il primo pezzo è il client OPC UA verso il server dello SCADA.

Lo SCADA, che sia Ignition, WinCC, iFIX, Aveva o un sistema fatto su misura, pubblica i suoi tag nello spazio degli indirizzi: temperature, contatori, stati macchina, codici di allarme, navigabili come un albero di cartelle.

Questa parte funziona quasi subito, ed è la ragione per cui i progetti di integrazione sembrano facili nella prima settimana.

Il secondo pezzo nasce al primo collaudo, quando scopri che il MES non ha la minima idea di cosa sia "PL01.Z3.TEMP.PV".

Serve una tabella di corrispondenza che traduca i nomi dei tag dello SCADA nei campi che il MES si aspetta, e serve che quella tabella sia configurabile senza ricompilare: gli impianti cambiano, i tag si aggiungono, e non puoi fare un rilascio per ogni sensore nuovo.

Il terzo pezzo nasce quando ti accorgi che lo SCADA misura in gradi Celsius e il MES vuole i Kelvin, oppure che uno conta pezzi come numero intero e l'altro pretende un decimale con l'unità di misura esplicita.

È lavoro noioso, di conversione e normalizzazione, ed è anche il lavoro che nessuno vede finché non manca.

Il quarto pezzo nasce la prima notte di manutenzione del MES.

Il MES è irraggiungibile per tre ore, il middleware continua a ricevere dati dallo SCADA e non sa dove metterli.

Se non hai previsto un magazzino temporaneo su disco, in quelle tre ore la fabbrica ha prodotto e la storia della produzione ha un buco che non si recupera più.

Il quinto pezzo arriva quando in un report compare una temperatura di meno novemilanovecentonovantanove gradi.

Il middleware deve validare e filtrare prima di inoltrare: scarta i valori con qualità OPC UA "Bad", quelli fuori dal campo fisicamente possibile, e i duplicati inutili quando la banda morta lato server non è configurata bene.

Dall'altra parte il MES riceve quello che gli mandi attraverso le sue API REST oppure, nei sistemi più recenti, esponendo a sua volta un server OPC UA.

Sembra il capolinea, e infatti manca ancora un pezzo.

L'ultimo componente lo capisci solo quando il cliente contesta un lotto di marzo.

Il MES conserva quello che gli serve per governare la produzione e butta via tutto il resto, comprese le misure ad alta risoluzione che nessuno guardava.

Per questo accanto al MES vive un historian, cioè un database time-series come InfluxDB, TimescaleDB o Aveva PI System, che storicizza tutto quello che lo SCADA misura alla massima risoluzione.

È l'unico posto in cui, otto mesi dopo, la risposta esiste ancora.

Il servizio .NET che ne esce fa cinque cose, e nessuna delle cinque è facoltativa:

• Legge: si collega come client al server OPC UA dello SCADA e sottoscrive i tag che servono.
• Traduce i nomi: una tabella di corrispondenza porta "PL01.Z3.TEMP.PV" nel campo che il MES si aspetta, e si cambia senza ricompilare.
• Converte le unità: gradi Celsius contro Kelvin, numeri interi contro decimali con l'unità di misura esplicita.
• Accumula quando il MES non c'è: un magazzino temporaneo su disco copre le finestre di manutenzione notturna.
• Filtra prima di inoltrare: fuori i valori con qualità "Bad", quelli fisicamente impossibili e i duplicati inutili.

Il disegno regge.

Il punto è che l'intera architettura poggia su un oggetto solo, la sessione OPC UA verso lo SCADA, e quella sessione prima o poi cade.

Quello che succede nei trenta secondi successivi separa un middleware da laboratorio da uno che vive in fabbrica.

Implementare un client OPC UA in C# per leggere dati dallo SCADA

Primo giorno vero di lavoro.

Visual Studio aperto, progetto nuovo, e la sensazione di dover imparare un mondo intero prima di scrivere una riga utile.

La verità è che le righe utili sono poche e stanno tutte nella prima ora.

Il client OPC UA in C# si costruisce con OPCFoundation.NetStandard.Opc.Ua, il pacchetto NuGet ufficiale della OPC Foundation: configuri l'applicazione e il suo certificato, apri una sessione verso il server dello SCADA, navighi l'albero dei nodi per trovare quelli che ti servono, crei una sottoscrizione e dichiari cosa vuoi seguire.

Da quel momento in poi è il server che chiama te.

Non è una libreria di terze parti costruita sopra lo standard: è la libreria che gli stessi fornitori di SCADA usano dentro i loro kit di sviluppo, supporta .NET Standard 2.0 ed è quindi compatibile con .NET 6, .NET 7, .NET 8 e le versioni successive.

Si installa come qualsiasi altro pacchetto NuGet, con un comando solo: la parte difficile di questo mestiere non è mai stata l'installazione.

Il concetto su cui si regge tutto è la sottoscrizione, e conviene arrivarci con un'immagine prima che con una definizione.

Interrogare a ciclo continuo è come telefonare a un collega ogni sessanta secondi per chiedergli se è arrivata la merce: funziona, ma dopo mezza giornata quello stacca il telefono.

La sottoscrizione è lasciargli il tuo numero dicendo "chiamami tu quando arriva, e solo se il camion è più grande di un furgone".

L'oggetto Subscription di OPC UA fa esattamente questo, e il MonitoredItem è la singola cosa che hai chiesto di sorvegliare.

In pratica configuri due oggetti e pochi numeri, e sono quei numeri a decidere se il sistema funziona.

Sulla sottoscrizione dichiari ogni quanto al massimo vuoi essere disturbato, per esempio un intervallo di pubblicazione di 1000 millisecondi, e i due contatori che dicono al server per quanto tenere viva la sottoscrizione e ogni quanto mandarti un segnale di presenza anche nei momenti in cui non succede niente.

Su ogni singolo tag da sorvegliare dichiari due cose: cosa guardare e con quanta sensibilità.

Cosa guardare è l'identificativo del nodo, che ha una forma tipo "ns=2;s=PL01.Z3.TEMP.PV" e non è altro che l'indirizzo di quel tag nell'albero dello SCADA, spazio dei nomi più percorso.

La sensibilità sono tre numeri: un campionamento lato server ogni 500 millisecondi, una coda di dieci valori perché niente vada perso tra una pubblicazione e l'altra, e una banda morta assoluta di 0,5 gradi.

È l'ultimo il numero che conta davvero: con 0,5 il server ti chiama quando la temperatura si muove sul serio, con zero ti chiama a ogni tremolio del sensore e ti riempie la rete di rumore che poi qualcuno dovrà filtrare a valle.

Da lì in avanti il tuo codice non chiede più niente a nessuno: registra un metodo da chiamare quando arriva una notifica e aspetta.

E quella notifica porta tre informazioni, non una: il valore, i tempi di campionamento e di ricezione, e la qualità del dato.

È il terzo campo quello che ti eviterà una riunione spiacevole.

La qualità in OPC UA ha tre stati e vanno trattati in tre modi diversi.

"Good" vuol dire che il sensore sta lavorando e il numero è credibile.

"Bad" vuol dire che il numero non è affidabile, perché il sensore è guasto o la comunicazione tra PLC e SCADA si è interrotta.

"Uncertain" è la zona grigia: sensore in calibrazione, valore al limite del campo di ingresso.

La regola operativa è secca: un valore che non sia "Good" non entra mai nel MES come dato di processo, ma viene registrato come evento di anomalia, perché il fatto che il sensore fosse cieco è a sua volta un'informazione preziosa.

L'altro punto delicato è la caduta della sessione.

La rete industriale non è internet: switch gestiti, VLAN dedicate, e ogni pacchetto che ci passa è stato messo lì da qualcuno.

Ma le disconnessioni capitano lo stesso, per manutenzione di rete, riavvii programmati dello SCADA, aggiornamenti firmware.

La libreria della OPC Foundation include il SessionReconnectHandler, che si aggancia all'evento di KeepAlive e prova a ricucire la sessione da solo.

Il meccanismo è semplice da descrivere e facile da sbagliare.

Il KeepAlive è il battito che il client e il server si scambiano per dirsi che sono ancora vivi: quando lo stato che arriva è "Bad", fai partire un tentativo di riconnessione con una finestra di dieci secondi.

Uno solo.

L'errore che vedo più spesso è avviarne uno nuovo a ogni battito mentre il primo sta ancora lavorando: nel giro di un minuto il servizio ha venti riconnessioni in parallelo verso uno SCADA che stava già facendo fatica, e da problema di rete la cosa diventa un problema tuo.

Mentre la riconnessione è in corso, il middleware non muore e non rifiuta: continua ad accettare i comandi che arrivano dal MES e li mette in coda, e quando la sessione torna li processa in ordine.

È una decina di righe di codice, ed è la differenza tra un servizio che si riprende da solo alle tre di notte e uno che alle sette del mattino trovi spento con qualcuno che ti guarda male.

Fin qui hai costruito un orecchio.

Funziona, ascolta, non disturba nessuno.

Il giorno in cui il MES chiede di parlare, e non solo di ascoltare, cambia il tipo di responsabilità che ti sei preso: perché una lettura sbagliata produce un numero sbagliato, mentre una scrittura sbagliata muove qualcosa di fisico dentro un capannone pieno di persone.

Inviare comandi dallo SCADA al MES e viceversa: write di variabili OPC UA

Il MES manda il cambio ricetta.

La macchina è in marcia.

Fin qui è un problema di software, da qui in avanti è un problema di stabilimento.

La scrittura di una variabile OPC UA è il momento in cui il tuo codice smette di guardare e comincia a toccare: il MES invia il comando al middleware, il middleware in C# scrive il nodo o chiama un Method sullo SCADA, rilegge un nodo di stato per avere conferma che il comando sia stato accettato, e solo allora risponde al MES.

Mai prima.

Rispetto alla lettura cambiano due cose.

La prima è che non tutti i nodi sono scrivibili, ed è giusto così: i valori dei sensori fisici sono in sola lettura, mentre setpoint, comandi e ricette sono i pochi punti in cui il server accetta di farsi modificare.

La seconda è che l'errore non resta dentro il computer.

Scrivere un valore sbagliato in un database ti costa una query di correzione.

Scrivere un setpoint sbagliato su un forno industriale ti costa il lotto, e in qualche caso ben più del lotto.

Per questo la validazione va fatta prima della scrittura, non dopo la telefonata, e le domande da farsi sono sempre le stesse quattro:

• Il valore rientra nell'intervallo ammesso?
• Il tipo di dato corrisponde a quello del nodo?
• Esiste già un comando pendente sullo stesso nodo?
• E soprattutto, lo stato della macchina permette questa modifica adesso?

La ricetta non si cambia a linea in marcia, e questa non è una regola del software, è una regola del reparto che il software deve conoscere.

Poi c'è il dettaglio che separa chi ha già lavorato in impianto da chi no, ed è l'esito della scrittura.

Una scrittura OPC UA che fallisce non ti solleva un'eccezione: restituisce un codice di stato per ogni valore scritto, e se non lo leggi il tuo servizio prosegue tranquillo convinto di avere cambiato la ricetta sul nodo "ns=2;s=PL01.RECIPE.SET" mentre lo SCADA l'ha rifiutata in silenzio.

Controllare quello stato, scrivere nel log il codice di errore insieme al nodo interessato e far risalire il fallimento a chi ha inviato il comando è lavoro di pochi minuti.

Non farlo significa presentarsi alla riunione del giorno dopo con l'unica frase che non puoi permetterti: "a me risultava fatto".

Quando il comando è composto da più valori, scrivere una variabile alla volta è un rischio silenzioso: se la terza scrittura fallisce, la macchina resta con due parametri nuovi e uno vecchio, in uno stato che nessuno ha mai progettato.

OPC UA risolve il problema con i Method, funzioni che il server espone e il client richiama con parametri di ingresso e di uscita.

Un Method come "AvviaLotto(numeroOrdine, codiceProdotto, quantitaTarget)" viene eseguito dallo SCADA come operazione unica: o si applica tutto, o non si applica niente.

Quando lo SCADA lo mette a disposizione, usare il Method invece di tre scritture separate è una delle scelte che ti risparmiano l'indagine del lunedì.

Nel verso opposto, quando è lo SCADA a dover avvisare il MES di qualcosa che è appena successo, fine lotto, allarme critico, cambio di stato macchina, le strade sono due.

Puoi sorvegliare i tag di stato con un MonitoredItem e reagire alle variazioni, che è la strada più semplice e funziona ovunque.

Oppure puoi usare gli OPC UA Events, eventi tipizzati che lo SCADA genera e il client riceve già strutturati, con severità e sorgente: più elegante, più ricco, e disponibile solo se chi ha configurato lo SCADA ha fatto il suo lavoro fino in fondo.

Il pattern raccomandato per i comandi critici (avvio/stop produzione, cambio ricetta) è: il MES invia il comando al middleware, il middleware scrive il nodo OPC UA o chiama il Method nello SCADA, attende la conferma di esecuzione leggendo un nodo di stato, e solo allora notifica il MES dell'esito. Questo ciclo di conferma è essenziale per evitare che il MES consideri eseguito un comando che lo SCADA non ha ricevuto.

Resta un presupposto che nessuno mette per iscritto: che il numero che rileggi per avere conferma sia vero.

E i numeri che arrivano da un impianto, ogni tanto, mentono con la faccia serissima.

Il dettaglio dell'esito della scrittura non sta in nessun tutorial.

Lo impari in due modi: sbagliando su un impianto vero, con qualcuno che ti guarda male alle sette del mattino, oppure con qualcuno che te lo dice prima.

Nel Corso C# lavoriamo sul secondo modo, e sul tuo codice, non su un esempio da manuale.

Ti dico dove si romperà mesi prima che lo faccia la macchina.

Un valore sbagliato in un database lo correggi con una query.

Su un forno in marcia, no.

Gestire la qualità del dato: timestamp, valori fuori range e connessione interrotta

Notte tra sabato e domenica.

Il grafico della temperatura del forno è una riga dritta, perfetta, immobile da trenta secondi.

Un forno vero non fa mai una riga così: quella riga significa che qualcosa si è staccato e nessuno lo ha detto.

Un dato di processo va giudicato su tre cose prima di essere inoltrato al MES: da quale orologio arriva il suo tempo, quale qualità gli ha attaccato il server OPC UA, e se il valore è fisicamente possibile su quella macchina.

Se salti anche uno solo dei tre controlli, il MES riceve numeri credibili e falsi, che è la categoria di errore peggiore che esista.

Questo è il capitolo che i tutorial non coprono mai, perché in laboratorio non succede niente di tutto questo.

Tornando a quella riga dritta: il server OPC UA continuava a esporre il tag, ma con qualità "Bad".

Il valore era congelato all'ultima comunicazione buona.

Un middleware che ignora la qualità e inoltra comunque manda al MES un dato che sembra fresco e ha mezzo minuto di età, e su un processo che cambia in fretta mezzo minuto è un'altra fabbrica.

La regola è quella già vista: solo "Good" passa come dato di processo, il resto diventa un evento di "perdita comunicazione sensore" con inizio e fine.

Poi guardi l'ora di quel dato e ti accorgi che sono in ballo tre orologi diversi.

Il SourceTimestamp dice quando il valore è stato campionato lato PLC e SCADA.

Il ServerTimestamp dice quando il server OPC UA lo ha ricevuto.

E poi c'è l'orologio del sistema operativo su cui gira il tuo servizio.

In un impianto reale questi tre orologi vanno in deriva l'uno rispetto all'altro, anche di secondi, e se il MES registra con il tempo del middleware mentre lo SCADA registra con il suo, gli stessi eventi risultano in ordine diverso nei due sistemi.

Usa sempre il SourceTimestamp come tempo del dato, tieni tutti i server dell'impianto sincronizzati via NTP, e quando il SourceTimestamp è assurdo, nel futuro o molto più vecchio dell'atteso, segnala il dato come sospetto invece di crederci.

Il terzo guaio arriva puntuale la notte in cui il MES viene aggiornato.

Il middleware raccoglie e accumula, e la domanda diventa: quanto grande deve essere il magazzino temporaneo?

Si dimensiona su due numeri, la durata massima prevista di irraggiungibilità del MES, di solito una finestra notturna di due o quattro ore, e la frequenza di campionamento dei tag più veloci.

Troppo grande spreca memoria, troppo piccolo perde dati esattamente quando servono.

Per volumi importanti, dell'ordine dei milioni di punti, SQLite è la scelta pragmatica: sta dentro il processo, non chiede un server in più a nessuno, e regge bene le scritture sequenziali veloci che sono il pane di un middleware industriale.

L'ultimo guaio è il più teatrale.

I sensori industriali si guastano, e quando un termistore si rompe non restituisce un valore un po' strano: restituisce quel meno 9999 gradi, oppure 99999.

Quel numero passa il PLC, passa lo SCADA, esce dal server OPC UA con aria innocente e, se il middleware non lo ferma, entra nell'historian e nel calcolo degli indicatori di produzione dove resterà per sempre.

Serve una tabella di intervalli fisici per ogni tag, uno scarto esplicito e una riga di log che dica cosa è stato buttato e perché: il valore si getta, la notizia che il sensore è morto no.

I tre controlli, con il sintomo che li fa scattare, sono questi:

Sistemati i tre controlli, il tuo dato è pulito, datato e credibile.

Ed è pronto per il viaggio che quasi nessuno gli racconta in anticipo: il MES non è il capolinea.

Integrazione con ERP SAP attraverso il MES: il flusso completo dalla macchina al gestionale

Riunione di fine mese.

Il controllo di gestione dice che in SAP risultano 11.400 pezzi, il MES ne dichiara 11.640, e per un'ora e mezza si discute di chi ha ragione invece che di cosa fare.

Ho visto quella riunione ripetersi ogni mese per due anni di fila.

Il dato di produzione fa un giro completo in tre tempi: SAP genera l'ordine, il MES lo pianifica e apre il lotto, il middleware .NET scrive i parametri nello SCADA; la macchina produce e il middleware riporta i consuntivi al MES; a fine lotto il MES chiude l'ordine in SAP con una conferma di produzione.

Capire questo giro conta anche per chi tocca solo il primo tratto, perché la forma dei dati che raccogli dipende da come finiranno in SAP.

Nella fase discendente SAP genera l'ordine di produzione con tutto il suo corredo: codice prodotto, versione della distinta materiali, quantità, data richiesta, centro di costo.

Il MES lo prende, sceglie la linea disponibile, apre il lotto con un numero univoco di tracciabilità.

A quel punto tocca al middleware: scrive nello SCADA il numero di lotto, la ricetta di processo, la quantità obiettivo e il tempo ciclo atteso.

La fabbrica ora sa cosa sta per fare, e lo sa perché glielo ha detto il tuo servizio in C#.

Nella fase di produzione lo SCADA fa il suo mestiere: conta i pezzi, registra le fermate, misura i parametri di qualità.

Il middleware legge in tempo reale e scrive nel MES, che aggiorna l'avanzamento del lotto e calcola l'OEE mentre la linea sta ancora girando.

È la prima volta che il responsabile di produzione vede un numero vero prima della fine del turno, ed è anche il momento in cui il progetto smette di essere una voce di budget e diventa una cosa che la gente usa.

Nella fase ascendente il MES consuntiva l'ordine in SAP: pezzi prodotti, materie prime consumate, tempi di lavorazione.

In SAP questo diventa una Conferma di Produzione (MIGO o CORK nelle transazioni di produzione) che muove le giacenze, i costi di produzione e la disponibilità dell'articolo.

Da lì in avanti il numero che è nato su un sensore ha effetti contabili.

Le difficoltà di questo giro sono tre e si presentano sempre nello stesso ordine.

La prima è la più banale e la più letale: le unità di misura.

SAP tratta i materiali con le unità dell'anagrafica, pezzi, chili, litri, metri.

Lo SCADA misura in unità fisiche che spesso non coincidono, impulsi di contatore, millivolt del sensore, unità grezze.

Il MES è il punto in cui la conversione avviene, ma i fattori di conversione deve conoscerli anche il middleware, altrimenti la discussione di fine mese ricomincia da capo.

La seconda difficoltà è la versione della distinta materiali.

SAP può avere più versioni della stessa distinta, e quella valida dipende dalla data.

Quando il MES passa al middleware la distinta da applicare, va verificato che sia la versione corrente in SAP, perché produrre con la distinta dell'anno scorso è un errore che nessun sistema segnala fino al collaudo del prodotto.

La terza difficoltà non si risolve con il codice, ed è giusto dirlo.

Lo SCADA registra il pezzo scartato al controllo in linea.

SAP distingue tra rottame e pezzo da rilavorare, e quella distinzione ha conseguenze economiche diverse.

Nessun middleware può decidere al posto del responsabile qualità: il sistema segnala, propone, traccia, ma la classificazione finale resta a una persona.

Chi promette il contrario sta vendendo qualcosa.

Sono le tre cose che ti porti dietro in ogni progetto di questo tipo, nell'ordine in cui si presentano:

• Le unità di misura: SAP usa quelle dell'anagrafica, lo SCADA misura in impulsi di contatore e millivolt, e i fattori di conversione li deve conoscere anche il middleware.
• La versione della distinta materiali: SAP ne può avere più di una e quella valida dipende dalla data, quindi va verificato che sia la corrente prima di mandare in produzione.
• La classificazione dello scarto: rottame o pezzo da rilavorare ha conseguenze economiche diverse, e la decisione finale resta al responsabile qualità.

Il MES resta il punto di disaccoppiamento tra i due mondi: lo SCADA non sa niente di SAP, SAP non sa niente dello SCADA, e questa ignoranza reciproca è un patrimonio.

Il giorno in cui l'azienda cambia lo SCADA, l'integrazione con SAP non si tocca.

Il giorno in cui cambia il gestionale, la fabbrica non se ne accorge.

Resta una domanda che finora abbiamo scavalcato, e che in molti impianti italiani è la prima a essere posta, non l'ultima: come fa il tuo servizio a stare con un piede nella rete di fabbrica e un piede nella rete aziendale senza aprire una porta a chi non deve entrare.

Sicurezza nell'integrazione SCADA-MES: attraversare il confine IT/OT senza aprire varchi

Presenti il progetto, tutto fila, poi parla il responsabile della sicurezza OT e dice una frase sola: "questo software da dove ci parla?".

Se non hai la risposta pronta, il progetto si ferma lì, e ha ragione lui.

Il middleware .NET vive nella DMZ tra le due reti: verso la rete OT parla solo con il server OPC UA dello SCADA, su una porta sola (tipicamente la 4840), verso la rete IT parla solo con le API del MES.

Tra rete OT e rete IT non esiste nessuna rotta diretta, e il tuo servizio è l'unico attraversamento previsto.

OPC UA aiuta perché la sicurezza è dentro il protocollo, non appiccicata sopra.

Ogni connessione si configura su tre livelli: nessuna sicurezza, che serve solo a far funzionare la demo e in produzione non esiste; firma del messaggio con certificato X.509, che garantisce chi sta parlando; firma e cifratura, che nasconde anche cosa viene detto.

Il minimo accettabile è la firma, la scelta giusta è firma e cifratura.

La gestione dei certificati è la parte più noiosa del mestiere ed è anche quella che ti fa perdere il primo pomeriggio in impianto.

Il server ha un certificato, il client ne ha un altro, e i due devono fidarsi reciprocamente: finché l'amministratore dello SCADA non approva il certificato del tuo client nel suo elenco dei certificati fidati (Trusted Store), la connessione viene rifiutata e il messaggio di errore non ti dirà mai chiaramente perché.

Nelle aziende strutturate il giro passa dalla PKI interna, che aggiunge tempi e moduli da compilare.

Mettilo nel piano di progetto la prima volta, non la seconda.

Sull'autenticazione applicativa la regola è vecchia e nessuno la rispetta: il middleware si collega con un account dedicato che ha i permessi minimi, lettura sui tag di processo e scrittura solo sui nodi di comando che gli servono davvero.

Usare un account amministratore perché "tanto è un servizio interno" significa che il giorno in cui quel processo viene compromesso l'attaccante eredita l'intero impianto invece di quattro nodi.

Poi c'è l'audit trail, che è la parte che distingue un progetto industriale da un progetto gestionale.

Ogni scrittura verso lo SCADA va registrata in un log immutabile con tempo, valore scritto, valore precedente, esito e identità applicativa.

Negli impianti soggetti a normativa, farmaceutico, alimentare, chimico, questo non è un miglioramento: è richiesto dalla FDA 21 CFR Part 11 e dalle Good Manufacturing Practice europee, e in un audit vale quanto il codice.

Nulla di tutto questo è nei corsi di C#.

È il motivo per cui l'azienda che cerca questa figura non sta cercando "uno sviluppatore .NET", e alla fine si tratta di capire cosa stia cercando davvero, e quanto sia disposta a pagarla.

Niente di quello che hai letto qui sopra sta in un corso di C# qualunque.

Sta nella testa di chi quel confine lo ha attraversato con un progetto vero in mano, e si trasferisce in un modo solo: guardando il codice di chi impara.

Il Corso C# è il percorso in cui questo succede, con me, non con un video.

Se dal confronto viene fuori che questa strada non fa per te, te lo dico prima di iniziare.

Seguo personalmente le persone, quindi i posti sono pochi e non prendo tutti.

Chi cerca in Italia uno sviluppatore .NET che sappia integrare SCADA e MES?

Un tecnico di un'azienda meccanica del bresciano me lo ha detto con queste parole: "abbiamo cercato per otto mesi. Trovavamo o gente che sa fare i siti, o gente che sa fare i PLC. Uno che sapesse tutti e due, mai".

Chi sa costruire un'integrazione SCADA-MES in .NET occupa una casella scoperta del mercato italiano: le aziende trovano sviluppatori C# e trovano tecnici di automazione, quasi mai la stessa persona con le due competenze insieme.

È una figura di confine, e i confini sono il posto in cui i profili valgono di più.

Il contesto aiuta a capire perché la domanda non cala.

Il manifatturiero italiano è il secondo d'Europa dopo la Germania, con il 14% della produzione industriale venduta dell'Unione contro il 26% tedesco (dati Eurostat 2024): meccanica, farmaceutico, alimentare, ceramica, carta, tessile.

Sono impianti che generano dati ininterrottamente e che, nella maggior parte dei casi, hanno ancora SCADA e MES che non si parlano, o che si parlano attraverso una persona con un foglio in mano.

Il collo di bottiglia non è la volontà.

È che uno sviluppatore cresciuto solo nel mondo IT, C#, API, database relazionali, non ha mai avuto in mano un protocollo di campo e non sa cosa significhi che un valore ha una qualità.

E un tecnico dell'automazione che conosce PLC, SCADA e reti industriali non ha gli strumenti per costruire un servizio che regga per anni senza manutenzione.

Non è colpa di nessuno dei due: è che il sistema formativo italiano li ha cresciuti in due edifici diversi, e nessuno ha mai aperto una porta tra i due.

Le posizioni aperte più difficili da coprire nelle aziende di system integration specializzate in Industria 4.0 sono esattamente questo: sviluppatori .NET con conoscenza dei protocolli industriali (OPC UA, Modbus, Profinet) e comprensione dell'architettura IT/OT. Sono ruoli pagati sopra la media dello sviluppo applicativo tradizionale, con pacchetti di benefit e possibilità di lavoro ibrido.

Le fasce retributive per il .NET industriale, livello per livello, le trovi nell'articolo sulla modernizzazione dei sistemi SCADA legacy.

La prima chiamata, per chi entra in questo mondo, arriva quasi sempre da una società di integrazione di sistemi: Accenture Industry X, Reply, Engineering, e decine di realtà più piccole e molto specializzate che costruiscono piattaforme di integrazione per conto dei clienti manifatturieri.

Si lavora su progetti diversi, si vedono molti impianti in poco tempo, e si impara in fretta perché non c'è alternativa.

Dopo un paio d'anni ti cerca chi il MES lo costruisce.

Aveva, Siemens e le software house verticali hanno bisogno di sviluppatori capaci di scrivere i connettori OPC UA verso i sistemi SCADA più diversi, che è un lavoro di prodotto e non di commessa: meno impianti, più profondità, cicli più lunghi.

La terza porta è quella che non trovi negli annunci.

Le grandi manifatturiere con un reparto IT interno, Barilla, Luxottica, Brembo per fare nomi che tutti conoscono, cercano queste persone e spesso le cercano male, per passaparola, perché non sanno come si chiama il profilo che gli serve.

Chi entra da lì diventa il riferimento tecnico dell'impianto, e quella posizione non la perde più.

Il percorso per costruire il profilo, partendo da C# e .NET, ha tre passi in sequenza:

1. Studiare le basi del mondo industriale: cosa fa un PLC, come funziona OPC UA, cosa dice il modello ISA-95.
2. Fare pratica vera contro un server OPC UA di prova, per esempio con simulatori come Prosys OPC UA Simulation Server, fino a gestire sottoscrizioni, qualità del dato e riconnessione.
3. Lavorare su un impianto reale, anche piccolo, dove le conseguenze degli errori esistono davvero.

Il terzo passo è quello che non si compra su una piattaforma di video, ed è anche l'unico che il mercato considera esperienza.

È il salto che in autonomia richiede anni e molti tentativi a vuoto, perché nessuno ti dice quali dei tuoi errori sono normali e quali sono strutturali.

Un percorso guidato accorcia questa curva, e non perché contenga informazioni segrete: perché qualcuno guarda il tuo codice e ti dice dove si romperà.

In Sviluppatore Migliore seguo personalmente le persone, quindi i posti sono limitati e non prendo tutti.

Se dal confronto viene fuori che questa strada non fa per te, te lo dico io prima di iniziare: è più onesto e ci fa risparmiare tempo a entrambi.

La linea produce.

I dati esistono.

Qualcuno deve farli parlare, e in questo momento in Italia le aziende che cercano quel qualcuno sono molte di più delle persone in grado di rispondere.

Tra dodici mesi quel qualcuno esisterà.

Sarà entrato in un system integrator, avrà messo le mani sul primo impianto e avrà smesso di chiedersi se ce la fa.

L'unica variabile è se sei tu o è un altro, e non la decide il mercato: la decidi adesso.

Il Corso C# è il punto in cui questa cosa smette di essere un'idea che ti gira in testa e diventa una data sul calendario.

Chi resta a leggere articoli, tra dodici mesi, sta leggendo altri articoli.