Come trasformare un sistema SCADA obsoleto in una piattaforma .NET moderna senza fermare la produzione

Ogni modernizzazione SCADA legacy che ho visto da vicino comincia dallo stesso punto: un file con estensione .vbp su un server, e nessuno in azienda che sappia ancora aprirlo.

Servirebbe Visual Basic 6, un ambiente di sviluppo che Microsoft ha abbandonato nel 2008.

Chi lo aveva scritto è andato in pensione.

O ha cambiato azienda.

O, in qualche caso, non c'è più.

Il sistema intanto gira.

Ogni mattina gli operatori accendono il PC dedicato, Windows XP o Windows 7, e lo schermo si riempie di valori, grafici e allarmi.

Tutto funziona, nel senso che nell'ultimo anno non è esploso niente.

Ma è il tipo di "funziona" su cui non puoi costruire niente: puoi solo sperare che duri ancora un trimestre.

Chi si ritrova questa situazione in mano, un responsabile IT, uno sviluppatore chiamato in consulenza, un capo reparto che ha ricevuto il problema come un pacco regalo mai richiesto, conosce bene quella sensazione.

La paura di toccare qualcosa che funziona e che nessuno capisce più.

Modificare significa forse rompere.

Non modificare significa aspettare il giorno in cui si rompe da solo, e quel giorno non lo scegli tu.

Il costo vero non è nella migrazione.

È nel restare dove sei: un sistema che nessuno sa manutenere, che non puoi estendere, che gira su hardware e sistemi operativi fuori supporto, e che tiene in ostaggio la produzione appendendola a una persona sola, ancora reperibile se ti va bene.

Questo articolo è per chi si trova esattamente lì: sviluppatori C# e responsabili tecnici che devono capire come si porta un sistema SCADA da VB6 a .NET senza fermare la produzione e senza scambiare il vecchio debito tecnico con uno nuovo di zecca.

Le strategie esistono, i pattern sono consolidati, il mercato italiano cerca chi sa applicarli.

La domanda a cui nessuno ti risponde è un'altra: quanto tempo hai davvero, prima che la scelta la faccia il sistema al posto tuo.

Perché i sistemi SCADA legacy sono una bomba a orologeria per la tua azienda

Il PC della sala controllo si rompe un martedì mattina.

L'ufficio acquisti fa la cosa più ragionevole del mondo: ordina una macchina nuova.

Ed è esattamente lì che il sistema "che funziona da vent'anni" smette di funzionare per sempre.

Un sistema SCADA legacy non è pericoloso perché è vecchio.

È pericoloso perché non riceve una patch di sicurezza da quasi vent’anni, dipende da componenti che non vengono più distribuiti e gira soltanto sul computer su cui è nato.

Il giorno in cui quel computer muore, si porta dietro l'impianto.

Partiamo dalla data, perché spiega tutto il resto.

Microsoft ha chiuso ufficialmente il supporto a Visual Basic 6 nel 2008.

Ogni vulnerabilità scoperta dopo quel giorno non ha mai ricevuto una correzione ufficiale, e non la riceverà mai.

In un impianto collegato alla rete aziendale, questo non è un dettaglio da riunione tecnica: è una porta lasciata aperta con il cartello "non toccare, funziona".

Poi c'è la parte che nessuno mette a verbale.

I progetti VB6 dell'epoca poggiavano quasi tutti su librerie COM e ActiveX di terze parti: i grafici di trend, la comunicazione seriale, l'accesso ai dati.

Quelle librerie non vengono aggiornate, molte non sono più distribuite, alcune appartengono ad aziende che non esistono più.

Sono punti ciechi dentro un sistema che governa la produzione, e nessuno in azienda ha l'elenco.

Il problema, però, ti si presenta quasi sempre sotto forma di compatibilità, non di sicurezza.

Windows 11 ha rimosso o limitato il supporto per alcune componenti a 32 bit e per il runtime VB6.

Installare uno SCADA scritto in VB6 su una macchina nuova diventa un'avventura: le dipendenze falliscono, i driver non si trovano, i controlli ActiveX dei grafici di trend rifiutano di registrarsi.

Il sistema che girava senza fiatare su quel PC del 2012 può semplicemente non partire su hardware comprato oggi.

Dall'altra parte del guado c'è .NET 10, la versione con supporto a lungo termine uscita a novembre 2025: quello che scrivi oggi riceve aggiornamenti di sicurezza per i prossimi tre anni, e il giorno in cui ti chiedono un servizio in cloud il livello di dominio e quello di comunicazione si spostano dentro un container, mentre l'interfaccia WPF resta dov'è, su Windows.

Se il tuo impianto è in Delphi o in C++/MFC, cambia il nome e non cambia la storia.

Sono tecnologie che hanno avuto il loro momento e oggi chiedono competenze sempre più rare.

Trovare uno sviluppatore Delphi disponibile e qualificato nel 2026 è difficile.

Trovarne uno che conosca anche lo specifico impianto SCADA che stai usando è quasi impossibile.

Non è una questione di talento: è demografia, e la demografia non si negozia.

Su .NET 10 il problema demografico non si pone: chi scrive C# lo trovi, oggi e fra dieci anni, e quel codice lo aprirà qualcun altro senza doverti richiamare mentre sei in pensione.

Non è una stima buttata lì: è la forbice che ho visto ricorrere nelle analisi di rischio con cui le aziende giustificano gli investimenti in continuità operativa, e si sposta soprattutto in base a quanto vale il lotto che stai perdendo.

Nel farmaceutico italiano, con gli obblighi di tracciabilità FDA e GMP, il conto sale ancora, perché ogni interruzione non documentata correttamente mette a rischio interi lotti di produzione.

Ecco perché la domanda "costa troppo migrare?" è la domanda sbagliata.

Quella giusta è: quanto costa non farlo, e per quanti anni ancora puoi permettertelo?

La finestra di vita utile di uno SCADA legacy si restringe ogni anno che passa.

Non è questione di sapere se diventerà un problema critico, ma di quando lo diventerà.

E chi arriva preparato ha delle opzioni; chi arriva in emergenza prende quello che passa il mercato.

C'è un'ultima voce, e non compare in nessun budget: la conoscenza aziendale.

Il codice VB6 scritto da una persona sola, senza documentazione, con nomi dei tag inventati sul momento e le regole di produzione sepolte dentro Form_Load e Timer_Tick, è debito tecnico allo stato puro: patrimonio dell'azienda scritto in una lingua che lì dentro non parla più nessuno.

Non è sparito.

È illeggibile, che ai fini pratici è la stessa cosa.

E qui arriva il passaggio che quasi tutti saltano, perché sembra il meno urgente di tutti: prima di decidere come migrare, devi sapere con precisione che cosa hai.

Nella maggioranza dei casi, nessuno lo sa.

Da dove parte davvero una modernizzazione SCADA legacy: l'audit prima di toccare una riga di codice

Immagina di dover ristrutturare una casa di cui non esistono le planimetrie, dove nessuno sa dove passano i tubi e l'unico muratore che l'ha costruita è irreperibile.

Nessuno inizierebbe a demolire.

Nel software, invece, si comincia quasi sempre dalla demolizione.

Una modernizzazione SCADA legacy parte da un audit del sistema esistente, non da Visual Studio: da una settimana a un mese di lavoro per mettere nero su bianco cinque cose, i tag, i PLC e i loro protocolli, le dipendenze COM, le logiche di produzione nascoste nel codice e la dimensione reale del lavoro.

Salti l'audit e stai scommettendo, non stai pianificando.

Il primo pezzo è l'inventario dei tag, e vale la pena spiegare di cosa parliamo, perché il termine confonde chi arriva dal software gestionale e non ha mai messo le mani in un sistema SCADA scritto in C#.

Un tag è un singolo punto di misura o di comando: la temperatura di un forno, la pressione di una linea, lo stato aperto o chiuso di una valvola.

Nei sistemi legacy questi punti vivono un po' dove capita: file di configurazione proprietari, un database Access dimenticato in una cartella condivisa, oppure scritti a mano dentro il codice VB6.

Vanno enumerati tutti, con nome, tipo di dato, frequenza di aggiornamento e dispositivo di provenienza.

Questa lista diventa la spina dorsale del sistema nuovo, e nessuno te la può dare già pronta.

Appena la lista è sul tavolo, ti si apre la domanda successiva: da dove arrivano davvero quei valori?

Qui mappi i PLC e i protocolli.

Siemens S7, Allen-Bradley ControlLogix, Modicon Quantum: ogni famiglia parla una lingua sua.

Il protocollo Siemens S7 non è Modbus TCP, che non è EtherNet/IP.

E il vecchio sistema come ci parla, con OPC Classic o con driver proprietari comprati vent'anni fa?

La risposta a questa domanda decide quanto ti costerà costruire il nuovo livello di comunicazione, prima ancora che tu abbia scritto una riga.

Poi tocca alle dipendenze COM e ActiveX, quelle che nel capitolo precedente erano punti ciechi.

Qui smettono di essere un rischio astratto e diventano un elenco: il componente per i grafici di trend, quello per la porta seriale, quello per l'accesso ai dati.

Per ognuno la decisione è secca, esiste un equivalente moderno oppure va riscritto.

Nessuna terza via.

La quarta area è quella che cambia il progetto, e non è tecnica: sono le logiche di produzione.

In un sistema VB6 la logica è sparsa ovunque, calcoli dentro i form, validazioni dentro i timer, regole di allarme dentro funzioni di utilità con nomi che non dicono niente.

Vanno estratte e documentate prima di essere riscritte.

È anche il momento in cui l'azienda scopre cosa fa realmente il suo impianto, che non sempre coincide con quello che tutti credevano facesse.

Ho visto riunioni cambiare direzione in dieci minuti per una regola di allarme trovata dentro un Timer_Tick.

Resta la stima del lavoro, che non è dare un voto al codice legacy: il voto lo conosci già.

È contare.

Quanti form, quante righe di codice ancora vive, quante integrazioni verso l'esterno.

Sono i numeri che determinano la durata del progetto e, soprattutto, quale delle strategie di migrazione puoi permetterti.

Alla fine di tutto questo ti ritrovi in mano un documento solo, ed è quello che porti in riunione:

• I tag, uno per uno, con nome, tipo di dato, frequenza di aggiornamento e dispositivo di provenienza;
• I PLC e i protocolli con cui il vecchio sistema ci parla, dal Siemens S7 a Modbus TCP a EtherNet/IP;
• Le dipendenze COM e ActiveX, ognuna con la decisione già presa accanto: equivalente moderno oppure riscrittura;
• Le logiche di produzione tirate fuori dai form, dai timer e dalle funzioni di utilità, scritte in una lingua che si può leggere;
• I numeri del lavoro: quante form, quante righe di codice ancora vive, quante integrazioni verso l'esterno.

Un mese di audit sembra tempo sottratto al progetto.

È l'unico modo che conosco per non pagarlo tre volte dopo, quando l'errore lo scopri con la linea ferma e il cliente al telefono.

Ogni ora spesa a capire il sistema vecchio è un'ora che non spenderai a rimediare su quello nuovo.

Con quei numeri in mano arrivi alla riunione in cui si decide come si migra.

Ed è lì che qualcuno, immancabilmente, propone la scorciatoia.

Hai appena visto cosa serve prima di scrivere una riga di codice.

Adesso la domanda vera: chi te lo insegna?

Non l'università, che il VB6 non lo ha mai visto.

Non un video, che ti mostra il caso pulito.

Il Corso C# parte da dove partono i progetti veri: da un sistema che qualcun altro ha scritto e che tocca a te capire.

Le strategie di migrazione: big bang, Strangler Fig e approccio incrementale

In riunione, qualcuno la propone sempre.

"Fermiamo tutto ad agosto, sostituiamo il sistema e a settembre ripartiamo con quello nuovo."

Sulla lavagna sembra la soluzione migliore.

È anche quella che, se scelta nel contesto sbagliato, ti costa più di ogni altra decisione del progetto.

Le strade sono tre: il big bang, che sostituisce tutto in un colpo solo; il pattern Strangler Fig, che fa crescere il nuovo attorno al vecchio fino a svuotarlo; e l'approccio incrementale puro, che affianca funzionalità nuove al sistema esistente.

Nella maggioranza delle migrazioni SCADA la risposta è la seconda, e vale la pena capire perché le altre due esistono lo stesso.

Il big bang è semplice da pianificare e feroce da eseguire: fermi il vecchio, avvii il nuovo, e nel mezzo non c'è rete.

Funziona solo se tutte e tre queste condizioni sono vere insieme.

Puoi programmare un fermo impianto lungo, da qualche giorno a qualche settimana.

Il sistema nuovo è stato testato in modo esaustivo su un ambiente che replica fedelmente quello produttivo.

E il rientro al vecchio sistema, se serve, è rapido e accettabile.

In pratica lo vedo applicabile dove i fermi sono già in calendario, le revisioni annuali degli stabilimenti farmaceutici, le manutenzioni stagionali di certi impianti alimentari, e dove il vecchio sistema è talmente degradato da non reggere nemmeno come rete di sicurezza.

Quando quelle condizioni non ci sono tutte, serve un'idea diversa, e questa arriva dalla botanica.

Il fico strangolatore cresce attorno a un albero ospite, lo avvolge, prende il suo posto, e l'albero originale scompare senza che nessuno lo abbatta.

Il pattern Strangler Fig fa la stessa cosa con il tuo SCADA: il sistema nuovo non sostituisce il vecchio, gli cresce intorno.

Parti dai moduli meno critici o più facili da isolare, attivi il nuovo modulo in parallelo, lo validi, e solo quando è stabile spegni il vecchio.

Poi ripeti, modulo dopo modulo, area dopo area, finché dal vecchio sistema non resta che un guscio da disinstallare.

Ogni passo è un rischio piccolo, e soprattutto è un rischio che puoi annullare.

Se un modulo si comporta male, il vecchio è ancora acceso lì accanto.

Torni indietro in minuti, non in settimane, e nessuno in direzione se ne accorge.

Resta il caso in cui il vecchio sistema non ha nessuna separazione tra moduli; quindi, non c'è niente da strangolare un pezzo alla volta, ma ha ancora vita operativa davanti.

Lì funziona l'approccio incrementale puro: le funzionalità nuove nascono direttamente nel sistema nuovo, il vecchio continua a gestire quelle che ha sempre gestito, e il baricentro si sposta un po' alla volta finché la sostituzione avviene senza un momento di rottura riconoscibile.

Messe una accanto all'altra, le tre strade si distinguono su tre domande sole:

Qualunque strada scegli, una cosa non è opzionale: il piano di rientro al sistema precedente, quello che nei documenti di progetto trovi come rollback, va scritto e provato prima che la migrazione cominci, non dopo il primo incidente.

Nel mondo industriale "speriamo che funzioni" non è una strategia, è una preghiera.

La soglia che uso sui progetti che seguo è mezz'ora: il rientro deve essere eseguibile in meno di 30 minuti, documentato passo per passo e provato in ambiente di staging.

Non è un numero tondo scelto a caso.

Con i costi orari di cui sopra, trenta minuti di linea ferma sono già un conto a cinque cifre da spiegare a qualcuno, e oltre quella soglia il rientro smette di essere una manovra tecnica e diventa un problema di direzione.

Deciso il come, resta il cosa.

E qui si gioca la partita che quasi nessuno mette in preventivo: se il sistema nuovo lo scrivi con la testa di prima, hai solo comprato un sistema vecchio con una sintassi più recente.

Da VB6 a C#: cosa cambia nell'architettura e come strutturare il nuovo progetto

Apri il progetto legacy e conti le form: ventisette.

Dentro ognuna c'è tutto, la lettura dei dati, i calcoli, la grafica, la gestione degli allarmi.

Se pensi di tradurlo riga per riga in C#, quello che ottieni è lo stesso disordine con una sintassi più moderna.

Passare da VB6 a C# non è un trasferimento di codice: è una riscrittura che ti obbliga a fare scelte di architettura, cioè esattamente quello che VB6 non ti chiedeva mai.

Le tre decisioni che contano riguardano come separi interfaccia e logica, come parli con il database e come parli con i PLC.

Il resto viene di conseguenza.

Come si struttura un progetto .NET per lo SCADA: i tre livelli

Comincio dalla separazione, perché è quella che ti cambia le giornate.

Nel progetto legacy la form è il sistema: legge, elabora, mostra, reagisce ai clic.

Il modello MVVM con WPF prende quel blocco unico e lo taglia in tre.

La View è solo XAML, descrive come appare la finestra e non sa nulla di come funziona l'impianto.

Il ViewModel è una classe C# che espone i valori attraverso INotifyPropertyChanged; quindi, la finestra si aggiorna da sola quando il valore cambia.

Il Model sono le entità del tuo dominio: un Tag, un Allarme, un Setpoint.

Sembra teoria fino al primo giovedì sera in cui devi verificare la logica degli allarmi.

Con la form monolitica, apri l'applicazione, aspetti che si connetta e provi a mano.

Con il ViewModel separato, scrivi un test e la logica la verifichi in due secondi, senza aprire nessuna finestra e senza toccare l'impianto.

In più la grafica la puoi cambiare senza rimettere mano alle regole, e due persone possono lavorare in parallelo sulla View e sul ViewModel senza pestarsi i piedi.

Questa è la differenza pratica tra un sistema che puoi manutenere e uno che puoi solo temere, ed è il motivo per cui vale la pena vedere MVVM applicato per intero invece che a metà.

Sul fronte dati, si lasciano DAO e ADO, i meccanismi di accesso ai database dell'era VB6, e si passa a Entity Framework Core o a Dapper.

La regola pratica che uso è semplice: per i dati di configurazione e di stato, Entity Framework Core con SQLite o SQL Server è la scelta pragmatica; per i dati che arrivano di continuo dai sensori, Dapper su TimescaleDB o un client per InfluxDB regge meglio il ritmo.

Sul fronte campo, si abbandonano DCOM e OPC Classic per OPC-UA.

La base è la libreria ufficiale della OPC Foundation per .NET Standard, disponibile su NuGet come OPCFoundation.NetStandard.Opc.Ua: legge i tag, si iscrive alle variazioni di valore, scrive i setpoint, con un'interfaccia tipizzata e testabile.

È il pezzo che trasforma il tuo progetto industriale in un normale progetto .NET 10, con tutto quello che ne consegue in termini di strumenti e di persone che lo sanno leggere.

A quel punto la struttura del progetto viene quasi da sé, su tre livelli.

Il livello di dominio contiene le entità come Tag, Allarme e Storico e le interfacce dei servizi, senza dipendere da niente di esterno: è C# e basta.

Il livello di infrastruttura contiene le implementazioni concrete, il client OPC-UA, i repository verso il database, il servizio di storicizzazione.

Il livello di presentazione contiene l'applicazione WPF con i suoi ViewModel e le sue View, dipende dal dominio e non dall'infrastruttura, che gli arriva risolta tramite iniezione delle dipendenze.

Il vantaggio si vede tra due anni, non oggi.

Cambi database time-series e tocchi solo l'infrastruttura.

Ti chiedono una dashboard web oltre all'HMI da sala controllo e aggiungi un progetto di presentazione senza rimettere mano al dominio.

C'è però un pezzo di questa architettura che, in un impianto reale, non parte al primo tentativo: la comunicazione con i PLC.

Perché quasi sempre i PLC non parlano ancora OPC-UA.

Come gestire il protocollo OPC Classic durante la migrazione

Hai il progetto .NET pronto, il client OPC-UA che funziona benissimo contro il server di prova, e vai in campo.

In campo trovi un server OPC di quindici anni fa, su una macchina che nessuno ha il coraggio di riavviare.

Il tuo codice moderno e quel server non hanno nessuna intenzione di parlarsi.

La soluzione non è toccare i PLC: è mettere in mezzo un traduttore.

Un wrapper OPC-UA si installa nella rete di campo, verso il basso dialoga in OPC Classic con i server esistenti, verso l'alto espone gli stessi dati come un normale server OPC-UA.

Il sistema .NET vede solo OPC-UA e del vecchio protocollo non sa nulla.

Quale delle sue sigle ti trovi davanti non è un dettaglio da glossario: decide quale traduttore puoi comprare e quanto lo paghi.

OPC Classic è la generazione precedente del protocollo: OPC DA per i dati in tempo reale, OPC HDA per i dati storici, OPC A&E per allarmi ed eventi.

Poggia su DCOM, la tecnologia Windows per far dialogare programmi su macchine diverse, e questo spiega la sua fama: funziona, ma è delicato da configurare, dipende dalla versione di Windows e non ha nessuna intenzione di uscire dal mondo Microsoft, tantomeno di andare verso il cloud.

Negli impianti italiani che ho visto, OPC Classic è la regola e non l'eccezione.

Con il traduttore in mezzo, i PLC non si toccano, la rete di campo resta com'è, e tutto il lavoro di configurazione fatto negli anni sui server OPC Classic non viene buttato via.

È la differenza tra un progetto che chiede all'azienda di rifare l'impianto e uno che chiede di aggiungere una macchina.

Di prodotti che fanno questo mestiere ce ne sono diversi, e la fotografia che segue è quella di metà 2026: la scelta non è una questione di gusto, e i listini cambiano più in fretta dei protocolli.

Technosoftware offre componenti sia client sia server con un buon supporto per OPC DA e HDA.

Unified Automation propone una suite completa.

Prosys OPC è un'alternativa solida, molto diffusa in ambito accademico e nelle installazioni di media dimensione.

Alcuni fornitori SCADA come Kepware, del gruppo PTC, includono già un gateway OPC nella loro offerta.

A guidarti sono tre numeri: quale versione di OPC Classic usi tra DA, HDA e A&E, quanti tag devono passare dal gateway, perché le versioni gratuite o base hanno spesso un tetto, e se ti serve un contratto di supporto con tempi di risposta garantiti.

Su un impianto in produzione, un fornitore con assistenza commerciale batte quasi sempre una soluzione senza garanzie di continuità: non per snobismo, ma perché alle tre di notte vuoi un numero da chiamare.

C'è uno scenario in cui il traduttore, da solo, non basta.

Il vecchio server OPC Classic sta su una macchina Windows XP o Windows 7 che non puoi aggiornare, perché ospita anche altro software critico altrettanto vecchio.

Lì il wrapper va installato su una macchina separata, anche virtuale, con DCOM configurato per raggiungere il server OPC Classic remoto.

Si fa, ma preparati a passare qualche giornata su permessi DCOM, firewall e account di servizio.

Chi ti dice che è una configurazione da mezz'ora non l'ha mai fatta.

Una nota che vale più di tutto il resto: passare a OPC-UA non è solo una scelta tecnica, è una scelta di posizionamento.

OPC-UA è il protocollo nativo dei PLC nuovi, dal Siemens S7-1500 a Beckhoff, fino a Phoenix Contact, è la porta d'ingresso del cloud industriale, da Azure IoT Hub ad AWS IoT, ed è la direzione indicata dalle normative Industria 4.0.

Quando lo introduci durante la migrazione non stai solo risolvendo il problema di oggi: stai mettendo l'impianto nella condizione di poter fare cose che oggi non sono nemmeno sul tavolo.

Sempre che tu riesca a dimostrare, prima di accenderlo, che il sistema nuovo legge gli stessi identici valori del vecchio.

Il wrapper lo configuri in una giornata.

Quello che non trovi in nessuna documentazione è la seconda giornata, quella dei permessi DCOM che non tornano, del firewall che blocca la porta giusta e dell'account di servizio che nessuno sa più a chi appartiene.

Lì o hai qualcuno che ci è già passato, o perdi una settimana.

Chi tiene il Corso C# quelle settimane le ha già perse su altri sistemi, e te le risparmia.

Testare uno SCADA legacy senza fermare la produzione

Nello sviluppo gestionale rilasci, guardi i log, correggi.

Su un impianto quel lusso non ce l'hai: non puoi mettere in produzione una versione sperimentale e stare a vedere cosa succede.

Un errore qui significa una linea ferma, un allarme che non suona, nel caso peggiore un operatore in pericolo.

Il modo di testare senza fermare niente esiste ed è fatto di tre passaggi in sequenza: prima simuli i PLC, poi ascolti l'impianto vero in sola lettura mentre il vecchio sistema continua a lavorare, infine confronti i dati storici prodotti dai due sistemi nello stesso periodo.

Solo dopo spegni qualcosa.

I tre passaggi del collaudo: simulatore, sistema in ombra, confronto storico

Il primo passaggio ti serve per non dipendere dal campo.

Invece di collegarti ai PLC dell'impianto, ti colleghi a un simulatore che si comporta come loro e produce valori sintetici.

Siemens mette a disposizione PLCSIM per i suoi S7.

Sul fronte OPC-UA esistono server di prova come il Prosys OPC UA Simulation Server o il server dimostrativo di Unified Automation, che espongono centinaia di nodi con valori che si muovono in modo realistico.

Con questi in mano sviluppi e provi tutto il livello di comunicazione dalla tua scrivania, senza chiedere a nessuno il permesso di entrare in reparto.

Il client OPC-UA che hai scritto in C# non distingue il simulatore dall'impianto: è lo stesso codice, cambia solo l'indirizzo del server nella configurazione.

Il secondo passaggio è quello che separa i progetti che finiscono bene dagli altri, e si chiama shadow mode, sistema in ombra.

Quando il nuovo software è abbastanza maturo, lo colleghi agli stessi PLC del vecchio, ma in sola lettura.

Il vecchio continua a governare l'impianto come ha sempre fatto; il nuovo guarda gli stessi dati in parallelo e non tocca niente.

Poi confronti: valori diversi, frequenze di aggiornamento diverse, tag che sul nuovo sistema non arrivano proprio.

Ogni discrepanza che trovi qui è una discrepanza che non troverai con la linea in marcia.

Il terzo passaggio riguarda la memoria dell'impianto.

Dopo aver migrato un modulo, metti a confronto le serie storiche prodotte dai due sistemi sullo stesso periodo di sovrapposizione.

Se il vecchio storicizzava un tag una volta al secondo, il nuovo deve fare altrettanto.

Buchi o differenze sistematiche si indagano e si risolvono prima di spegnere il vecchio modulo, mai dopo.

Piano di rientro e criteri di accettazione: cosa deve essere verificabile

Il piano di rientro merita una riga a parte, perché è quello che tutti dichiarano di avere e quasi nessuno ha provato.

Ogni passo di migrazione deve avere il suo: quali operazioni si eseguono per tornare indietro, in quanto tempo, e chi le esegue materialmente quando il telefono squilla di sabato.

Va provato in staging prima di ogni rilascio in produzione.

"Se va male torniamo al vecchio" non è un piano finché non lo hai cronometrato.

C'è poi la parte che rende tutto questo verificabile invece che opinabile: i criteri di accettazione, scritti modulo per modulo, che sono la versione software di quello che in reparto chiamano collaudo.

Non "il modulo funziona", ma qualcosa che si possa spuntare riga per riga:

• Legge tutti e 47 i tag previsti;
• Con frequenza non inferiore a 500 ms;
• Senza errori di connessione per più di 2 secondi consecutivi;
• Storicizzando i valori con timestamp accurato.

Scritti così, sono verificabili in automatico: una manciata di test di integrazione in xUnit che aprono la sessione OPC-UA, leggono i 47 tag e controllano frequenza e timestamp.

Gli stessi test girano prima sulla tua macchina contro il server di simulazione, poi in staging contro la rete di campo replicata, e quando qualcosa si rompe te lo dicono loro, non il capo reparto al telefono.

Scritti nell'altro modo, diventano una discussione tra te e il capo reparto, e quella discussione la perdi sempre.

Resta però un pezzo di impianto che nessun criterio di accettazione può ricostruire se lo perdi per strada: gli anni di dati già registrati.

Il problema dei dati storici: migrare anni di trend e allarmi

Chiedi in azienda quanto valgono i dati storici dello SCADA e nessuno sa rispondere.

Chiedi cosa succede se spariscono e la risposta arriva subito, dal responsabile qualità: sono vent'anni di prove che il processo è sempre stato sotto controllo.

I dati storici sono l'asset più prezioso e più trascurato di un impianto, e migrarli significa affrontare due problemi distinti: leggere formati proprietari spesso non documentati, e riversarli in un database time-series moderno senza alterare un timestamp.

Perderli, o alterarli, non è un'opzione.

Serve prima sapere chi verrà a chiedertene conto: se è il responsabile di produzione, un buco di dieci minuti nello storico è un fastidio; se è un ispettore, è un lotto che non puoi più difendere.

Anni o decenni di letture dei sensori, eventi di allarme, azioni degli operatori: sono la base delle analisi di performance, della manutenzione predittiva, degli audit di conformità, soprattutto nel farmaceutico, e del debug di quel problema che si ripresenta ogni tre mesi e che nessuno ha mai capito.

Il primo ostacolo è il formato, e il panorama non è incoraggiante.

Wonderware InSQL, oggi AVEVA System Platform, usa SQL Server come motore ma con uno schema tutto suo.

OSIsoft PI, oggi AVEVA PI, tiene i dati in un formato binario ottimizzato.

Citect usa file proprietari.

E nei sistemi più datati trovi database Access, o cartelle piene di CSV generati ogni notte da uno script che nessuno ha più letto.

Dove sotto c'è SQL Server, la strada è in discesa: studi lo schema, scrivi le query che tirano fuori timestamp, valore e nome del tag, e da lì costruisci gli script di importazione verso il nuovo database.

Dove il formato è chiuso, passi dalle API del sistema legacy per esportare in CSV o JSON e poi importi.

Più lento, meno elegante, ma funziona.

Sulla destinazione la scelta è tra tre mondi, e dipende da chi manterrà il sistema dopo di te.

InfluxDB è il più diffuso nel mondo IoT e SCADA aperto, ha un suo linguaggio di interrogazione, prima InfluxQL e poi Flux, client .NET ben supportati e buone prestazioni sulle interrogazioni per intervalli di tempo.

TimescaleDB è un'estensione di PostgreSQL: prestazioni da database time-series con la comodità di continuare a scrivere SQL, che in un team abituato ai gestionali vale più di qualsiasi benchmark.

SQL Server con il partizionamento è la scelta pragmatica di chi resta nell'ecosistema Microsoft e ha già le competenze in casa.

Se devi decidere in trenta secondi: InfluxDB quando il team viene dall'IoT, TimescaleDB quando scrive già SQL, SQL Server quando l'azienda è tutta Microsoft.

Nel dettaglio la scelta si chiude così:

La pratica che funziona è migrare prima gli ultimi 12 mesi, validarli con calma, e portare avanti lo storico più vecchio in sottofondo mentre il sistema nuovo è già in produzione.

Poi c'è il dettaglio che fa saltare le validazioni: i timestamp.

I sistemi legacy salvano con l'orologio del server SCADA locale, che può avere uno scostamento rispetto all'ora universale, andare alla deriva nel tempo e lasciare buchi a ogni riavvio.

Prima di importare vanno normalizzati, i buchi vanno identificati e vanno documentati come buchi di acquisizione.

Non colmarli mai con un'interpolazione: un valore inventato dentro una serie storica è una bugia che, il giorno dell'ispezione, qualcuno leggerà come un dato reale.

Nel farmaceutico e negli altri settori regolamentati questo diventa formale: serve un audit trail che dimostri che i dati migrati sono identici agli originali, con firma digitale o impronta crittografica dei due insiemi.

È un requisito FDA 21 CFR Part 11, e ignorarlo significa perdere la validazione del sistema, cioè fermare l'impianto per un motivo burocratico dopo averlo modernizzato benissimo.

Chi sa maneggiare questa roba non è un tecnico qualunque, ed è anche il motivo per cui in Italia queste persone si contano.

C'è chi passa la carriera a tenere in vita i sistemi degli altri sperando che reggano un altro anno.

E c'è chi arriva quando quei sistemi vanno sostituiti, e viene chiamato prima che l'investimento venga firmato.

La differenza non è il talento: è il metodo con cui hai costruito le tue competenze.

Quel metodo, applicato a C# e .NET, è il Corso C#.

Opportunità di carriera nella modernizzazione SCADA legacy: perché questo mercato vale

Un venerdì di qualche tempo fa, un responsabile tecnico di un'azienda del manifatturiero bresciano mi dice una frase che riassume tutto: "Non riesco a trovare nessuno che sappia fare questa cosa.

Ho alzato l'offerta due volte e ho ricevuto tre curriculum in totale."

Il mercato della modernizzazione SCADA in Italia ha un problema di offerta, non di domanda: le aziende hanno gli impianti da rifare e i budget approvati, ma non trovano sviluppatori C# disposti a entrare nel mondo industriale.

Chi ci entra oggi trova retribuzioni più alte della media a parità di anzianità e molta meno concorrenza.

Il contesto spiega perché.

L'Italia è uno dei paesi manifatturieri più importanti d'Europa: il distretto automotive del Nord, i cluster farmaceutici tra Lazio e Lombardia, il food and beverage del Nord-Est, i distretti tessili e meccanici tra Toscana ed Emilia.

Tutti hanno impianti con sistemi SCADA, e una fetta consistente di quegli impianti gira ancora su tecnologie degli anni Novanta o dei primi Duemila.

Nel frattempo, chi sapeva lavorare su quei sistemi sta uscendo dal mercato del lavoro per raggiunti limiti di età, e nessuno lo sta sostituendo.

La generazione nuova non ha mai visto VB6, non sa cosa sia Delphi e dei protocolli industriali ha sentito parlare al massimo a una fiera.

Le aziende restano in mezzo: devono modernizzare, non trovano le persone, e intanto l'impianto invecchia di un altro anno.

È in questa forbice che si infila lo sviluppatore C# che accetta di sporcarsi le mani con il codice di qualcun altro, e la barriera d'ingresso è più bassa di quanto sembri.

Non devi diventare ingegnere di automazione.

Non devi imparare a programmare i PLC.

Devi saper costruire applicazioni .NET solide, capire i concetti di base del mondo industriale, cosa è un tag, come funziona OPC-UA, cosa significa storicizzare, saper leggere il codice che c'era prima di te, e saper lavorare in un contesto dove la tolleranza al fallimento è molto più bassa rispetto allo sviluppo web.

I numeri, perché è giusto parlarne apertamente.

E dico subito da dove vengono: non da un'indagine retributiva, ma dagli annunci che girano nel 2026 per queste posizioni e dalle trattative che mi capita di seguire.

Prendile per quello che sono, una fotografia dal campo, non una statistica.

Uno sviluppatore C# junior che entra in una software house specializzata in SCADA industriali parte da 28.000-35.000 euro lordi l'anno.

Un profilo mid con 3-5 anni di esperienza, competenze WPF, OPC-UA e almeno una migrazione alle spalle si colloca tra 45.000 e 65.000 euro lordi l'anno.

Un senior o un tecnico di riferimento con esperienza documentata su impianti reali supera i 70.000 euro, e chi lavora in consulenza arriva a 100-130 euro l'ora.

Sono cifre sensibilmente più alte rispetto allo sviluppo applicativo tradizionale a parità di anni di lavoro.

La domanda si concentra in quattro settori, ognuno con una porta d'ingresso diversa:

• Farmaceutico: il più esigente su qualità e conformità, ma è anche quello che paga di più e che ha più fretta, spinto dalle normative FDA ed EMA.
• Automotive: soprattutto la filiera che fornisce i grandi costruttori, con una quantità enorme di impianti da modernizzare e budget disponibili.
• Food and beverage: impianti mediamente più piccoli ma numerosi e sparsi su tutto il territorio, il che significa lavoro vicino a casa quasi ovunque tu abiti.
• Utilities di acqua ed energia: requisiti di continuità estremi e budget pubblici che vengono stanziati con regolarità.

Il vantaggio vero, però, non sta nello stipendio di partenza.

Sta nel fatto che la barriera d'ingresso è alta non per difficoltà tecnica, ma per combinazione: serve qualcuno che scriva buon codice C#, conosca WPF, sappia leggere il VB6 di vent'anni fa senza chiamare un consulente esterno e non si spaventi davanti a una linea di produzione.

Chi mette insieme queste quattro cose diventa difficile da sostituire, e nel nostro mestiere "difficile da sostituire" è l'unica forma di sicurezza che esista davvero.

La buona notizia è che quelle quattro cose si costruiscono in un ordine preciso, e il percorso è più corto di quanto immagini.

Come formarsi per diventare lo sviluppatore SCADA che le aziende cercano

"Dovrei ricominciare da zero."

È la frase che sento più spesso quando racconto questo mercato a uno sviluppatore C# che lavora su gestionali da cinque anni.

Ed è falsa: il grosso del lavoro lo ha già fatto, semplicemente non lo sa.

Se parti da una base C# solida, il percorso verso il mondo industriale è di 12-18 mesi e passa da cinque competenze in sequenza: C# fatto bene, WPF con MVVM, OPC-UA, i database time-series e la capacità di leggere il codice legacy.

Non serve una laurea in automazione, serve costruirle nell'ordine giusto.

Si parte dal C#, e non significa conoscere ogni design pattern esistente.

Significa scrivere codice pulito, sapere come si comporta la memoria, usare async e await con cognizione di causa, che qui non è un vezzo, perché un sistema SCADA gestisce centinaia di connessioni contemporanee e un blocco nel posto sbagliato lo vedi come un grafico che si congela in sala controllo, e conoscere i principi SOLID quanto basta per applicarli senza diventarne prigioniero.

Se hai dubbi su questi fondamentali, è lì che va speso il primo mese, non altrove.

Poi viene WPF con MVVM, ed è il punto in cui molti storcono il naso perché "WPF è morto".

Nel mondo industriale desktop è lo standard di fatto per le interfacce di sala controllo su Windows, e lo resterà finché ci saranno impianti Windows, cioè per un bel po'.

Saper costruire un'interfaccia con data binding, template e trigger, e implementare MVVM per bene invece che a metà, è una competenza molto richiesta e sempre più rara tra chi è cresciuto solo sul web.

È anche il motivo per cui in questo mercato la concorrenza è così bassa: la moda è passata di là, il lavoro è rimasto qui.

Il terzo passo è OPC-UA, e ti costa meno di quanto pensi.

Non devi diventare specialista del protocollo.

Devi saper usare la libreria OPC Foundation per .NET per collegare un client a un server, leggere i nodi, iscriverti alle variazioni di valore e scrivere un valore.

Con un server OPC-UA di prova lo impari in qualche giorno di pratica vera; la comprensione più profonda del modello a nodi e delle sottoscrizioni arriva dopo, lavorandoci.

Il quarto è la parte dati: InfluxDB o TimescaleDB, come si inseriscono valori ad alta frequenza, come si interroga per intervalli di tempo, per quanto tempo si conservano i dati e come si buttano via quelli vecchi senza rimpianti.

Anche qui si impara installando un'istanza in locale e scrivendo codice, non leggendo la documentazione dall'inizio alla fine.

Il quinto è quello che nessun corso mette in programma ed è quello che ti fa assumere su un progetto di migrazione: saper leggere il codice legacy.

Non scrivere VB6, leggerlo.

Capire cosa fa una form, tirare fuori la regola di produzione nascosta dentro un timer, individuare dove il vecchio sistema parla con i PLC.

Si impara solo su codice vero, durante una migrazione o su progetti VB6 aperti trovati in rete, e chi lo sa fare entra in una stanza dove sono in pochissimi.

Messe in fila, le cinque competenze si spuntano così:

Quanto tempo serve davvero: il percorso in 12-18 mesi

Se parti da C# e vuoi arrivarci in un anno e mezzo, la sequenza che funziona è questa: tre mesi su C# avanzato e WPF con MVVM, due mesi su OPC-UA e database time-series, poi un progetto personale che simuli uno SCADA completo, interfaccia WPF, connessione a un server OPC-UA di simulazione, storicizzazione su InfluxDB.

Quel progetto su GitHub, in un colloquio, vale più di qualsiasi certificazione: dimostra che sai far funzionare le cose insieme, che è l'unica domanda che conta.

Quello che la formazione strutturata ti fa risparmiare non è tempo di studio: è tempo perso a costruire le competenze storte.

Architetture che non reggono oltre il prototipo, dipendenze che rendono il codice impossibile da testare, schemi di comunicazione OPC-UA che in laboratorio filano lisci e su un impianto vero, con centinaia di tag e una rete che ogni tanto perde colpi, si piantano.

Sono errori che da soli scopri dopo mesi, e li scopri davanti al cliente.

Con qualcuno che ha già fatto quella strada, li scopri il pomeriggio stesso, sul tuo codice.

C'è chi passa la carriera a mantenere in vita sistemi scritti da altri, sperando che reggano ancora un anno.

E c'è chi diventa la persona che quei sistemi li sostituisce, e che le aziende chiamano prima di firmare l'investimento.

La differenza non è il talento: è il metodo con cui costruisci le tue competenze e la guida che scegli per farlo.

Gli impianti di cui hai letto qui esistono davvero, molti stanno a un'ora di macchina da dove abiti, e cercano adesso.

Quella guida ha un nome: il Corso C#, dove il metodo non te lo racconto, te lo faccio costruire sul tuo codice.

Il tempo che aspetti però non torna: gli impianti invecchiano, i colleghi che sapevano vanno in pensione, e ogni anno che passa la finestra si stringe un po'.