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

C'è un file da qualche parte nel server. Ha un'estensione .vbp e nessuno sa più aprirlo senza installare Visual Basic 6, un ambiente di sviluppo che Microsoft ha abbandonato nel 2008. Il developer che lo ha scritto è andato in pensione. O ha cambiato azienda. O, in qualche caso, non c'è più.

Il sistema gira. Ogni mattina, gli operatori aprono il PC dedicato con Windows XP o Windows 7, e lo schermo si riempie di valori, grafici e allarmi. Tutto funziona, nel senso che non è esploso niente nell'ultimo anno. Ma quel "funziona" è il tipo di funzionamento precario su cui non si può costruire niente.

Chi eredita questo scenario, un responsabile IT, un developer chiamato in consulenza, un capo reparto che ha ricevuto il problema come un pacco regalo indesiderato, conosce bene quella sensazione: la paura di toccare qualcosa che "funziona ma nessuno capisce più". Modificare significa potenzialmente rompere. Non modificare significa aspettare il giorno in cui si rompe da solo, nel momento peggiore possibile.

Il costo reale di questa situazione non è nell'eventuale migrazione. È nel continuare a operare con un sistema che nessuno sa manutenere, che non può essere esteso, che gira su hardware e sistemi operativi obsoleti, e che tiene in ostaggio l'intera produzione dipendendo da un'unica persona ancora reperibile o, peggio, da nessuno.

Questo articolo è scritto per chi si trova in quella posizione: developer C# o responsabili tecnici che devono capire come si affronta la modernizzazione di un sistema SCADA legacy, da VB6 a .NET, senza fermare la produzione e senza accumulare nuovo debito tecnico nel tentativo di liberarsi da quello vecchio. Le strategie esistono. I pattern sono consolidati. Il mercato italiano ha bisogno urgente di professionisti che sappiano applicarli.

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

VB6 non è solo "vecchio". È una tecnologia che Microsoft ha ufficialmente cessato di supportare nel 2008. Questo significa che ogni vulnerabilità di sicurezza scoperta dopo quella data non ha mai ricevuto una patch ufficiale. Ogni dipendenza da librerie COM e ActiveX di terze parti, ampiamente usate nei progetti VB6 dell'epoca, è un punto cieco: quelle librerie non vengono aggiornate, molte non sono più distribuite, alcune non esistono più.

Ma il problema non è solo di sicurezza. È di compatibilità operativa. Windows 11 ha rimosso o limitato il supporto per alcune componenti a 32-bit e per il runtime VB6. Installare un sistema SCADA scritto in VB6 su una macchina nuova è spesso un'avventura: le dipendenze falliscono, i driver non si trovano, i componenti ActiveX per la grafica dei trend non si registrano. Il sistema che "funzionava" su quel PC del 2012 potrebbe non funzionare più su hardware acquistato oggi.

Stesso discorso per Delphi e C++/MFC: tecnologie che hanno avuto il loro momento, ma che oggi richiedono competenze sempre più rare sul mercato. Trovare un developer Delphi disponibile e qualificato nel 2026 è difficile. Trovarne uno che conosce anche lo specifico impianto SCADA che state usando è quasi impossibile.

Un'ora di fermo produzione in uno stabilimento manifatturiero di medie dimensioni, nel settore automotive o farmaceutico, costa tra 10.000 e 80.000 euro. Non è una stima: è il dato che emerge dalle analisi di rischio che le aziende fanno quando valutano gli investimenti in continuità operativa. Il settore farmaceutico italiano, con i suoi obblighi di tracciabilità FDA e GMP, ha costi di fermo ancora più alti perché ogni interruzione non documentata correttamente rischia di compromettere interi lotti di produzione.

La domanda giusta non è "costa troppo migrare?" ma "quanto costa non farlo?". Un sistema SCADA legacy ha una finestra di vita utile che si sta restringendo ogni anno. Non è questione di se diventerà un problema critico, ma di quando. E chi si prepara per tempo ha opzioni; chi aspetta l'emergenza no.

C'è anche un problema di conoscenza organizzativa. Il codice VB6 scritto da un singolo developer, senza documentazione, con naming dei tag arbitrari e logiche di business sepolte in Form_Load e Timer_Tick, è conoscenza aziendale che rischia di sparire. Quando quel developer non è più disponibile, quella conoscenza diventa inaccessibile. Non perché non esista, ma perché nessuno sa leggerla.

Come si valuta uno SCADA legacy: il primo passo prima di toccare qualcosa

Prima di scrivere una riga di C#, prima di aprire Visual Studio, prima persino di fissare un piano di progetto, serve un'attività che molti sottovalutano: l'audit del sistema esistente. Non è un'attività glamour, ma è quella che determina il successo o il fallimento di tutto ciò che viene dopo.

L'audit si divide in cinque aree distinte. La prima è l'inventario dei tag. Un tag è un punto di misura o di controllo: una temperatura, una pressione, uno stato on/off di una valvola. In un sistema SCADA legacy, i tag sono spesso definiti in file di configurazione proprietari, in database Access, o direttamente hardcodati nel codice VB6. Vanno enumerati tutti, con il loro nome, il loro tipo di dato, la frequenza di aggiornamento e il PLC o il dispositivo di campo a cui sono associati. Questa lista è la spina dorsale del nuovo sistema.

La seconda area è la mappatura dei PLC e dei protocolli. Quali PLC sono installati? Siemens S7? Allen-Bradley ControlLogix? Modicon Quantum? Ogni famiglia usa protocolli diversi: il protocollo Siemens S7 non è uguale a Modbus TCP, che non è uguale a EtherNet/IP. Il vecchio sistema come si connette a questi PLC? Usa OPC Classic (DA/HDA)? Usa driver proprietari? Questa informazione determina quanto è difficile costruire il nuovo layer di comunicazione.

La terza area è la ricognizione delle dipendenze COM e ActiveX. I progetti VB6 usano quasi universalmente componenti COM per i grafici trend (Citect, WonderWare, o componenti personalizzati), per la comunicazione seriale, per l'accesso ai database. Ogni componente COM è una dipendenza che deve essere identificata, e per ognuna bisogna decidere se esiste un equivalente moderno o se va riscritto.

La quarta area è l'analisi delle logiche di business. In un sistema VB6, la logica è spesso distribuita in modo caotico: calcoli nei form, validazioni nei timer, regole di allarme sepolte in funzioni di utility senza nome chiaro. Va estratta e documentata prima di essere riscritta. Questo passaggio è anche l'occasione per capire cosa fa davvero il sistema, distinto da cosa si pensava facesse.

La quinta area è la stima del debito tecnico. Non si tratta di dare un voto al codice legacy (il giudizio è quasi sempre lo stesso: pessimo), ma di quantificare il lavoro di migrazione in modo onesto. Quante form ci sono? Quante righe di codice attive? Quante integrazioni esterne? Questi numeri determinano la durata del progetto e permettono di scegliere la strategia giusta.

Un audit ben fatto richiede da una settimana a un mese, a seconda della complessità del sistema. È un investimento, non una perdita di tempo. Ogni ora spesa a capire il sistema legacy è un'ora risparmiata in errori di migrazione.

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

Esistono fondamentalmente tre strategie per migrare un sistema SCADA legacy. Ognuna ha i suoi contesti di applicazione, i suoi rischi e i suoi vantaggi. Scegliere quella sbagliata è uno degli errori più costosi che si può fare in un progetto di modernizzazione industriale.

La prima strategia è il cosiddetto big bang: si ferma il vecchio sistema e si avvia il nuovo in un unico momento. È l'approccio più semplice da pianificare e il più rischioso da eseguire. Funziona solo quando è possibile programmare un fermo impianto prolungato (da alcuni giorni a settimane), il nuovo sistema è stato testato in modo esaustivo in un ambiente che replica fedelmente quello produttivo, e il rischio di dover tornare al vecchio sistema è accettabile e il rollback è rapido. In pratica, il big bang è applicabile in settori dove i fermi programmati sono già previsti (revisioni annuali in stabilimenti farmaceutici, manutenzioni stagionali in certi impianti alimentari) e dove il vecchio sistema è talmente degradato da non essere più recuperabile nemmeno come fallback.

La seconda strategia è il pattern Strangler Fig, il nome viene da un tipo di fico che cresce intorno a un albero ospite fino a sostituirlo completamente, senza abbatterlo. È l'approccio raccomandato nella grande maggioranza dei casi di modernizzazione SCADA. Il principio è semplice: il nuovo sistema viene costruito affiancando il vecchio, non sostituendolo. Si inizia dai moduli meno critici o da quelli più facilmente isolabili. Il nuovo modulo viene attivato in parallelo, validato, e solo quando è stabile e verificato il vecchio modulo viene disabilitato. Il processo si ripete modulo per modulo, area per area, fino a quando il vecchio sistema è svuotato completamente.

Il pattern Strangler Fig non elimina il rischio: lo distribuisce nel tempo e lo rende gestibile. Ogni incremento è un rischio piccolo e controllato. Se qualcosa va storto su un modulo, il vecchio è ancora lì. Il rollback richiede minuti, non settimane.

La terza strategia è l'approccio incrementale puro, simile allo Strangler Fig ma meno strutturato: si aggiungono funzionalità nuove nel sistema nuovo mentre il vecchio continua a gestire le funzionalità esistenti. È utile quando il vecchio sistema non ha una separazione logica tra moduli che permette lo Strangler Fig classico, ma ha ancora margine di vita operativa. Si costruisce parallelamente, si sposta traffico gradualmente, si arriva alla sostituzione senza un momento di discontinuità netto.

In tutti e tre i casi vale una regola: il piano di rollback è obbligatorio e deve essere testato prima ancora che la migrazione inizi. Nel mondo industriale, "speriamo che funzioni" non è una strategia. Il sistema di rollback deve essere eseguibile in meno di 30 minuti, documentato passo passo, e provato in ambiente di staging.

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

Migrare da VB6 a C# non è un semplice port del codice. È una riscrittura che richiede scelte architetturali esplicite, cosa che VB6 non richiedeva affatto perché l'architettura era assente per definizione. Un progetto VB6 tipico è una collezione di Form con codice sparso, globali ovunque, nessuna separazione tra interfaccia, logica e accesso ai dati. Il nuovo sistema in C# è l'opportunità di fare le cose bene. Non solo meglio: bene per la prima volta.

Il cambiamento più importante è il passaggio da form monolitiche a MVVM con WPF. In VB6, il form era tutto: conteneva il codice che leggeva i dati, li elaborava, li mostrava e gestiva gli eventi dell'utente. In WPF con MVVM, questi ruoli sono separati in modo esplicito. La View è solo XAML: definisce l'aspetto grafico senza logica. Il ViewModel è una classe C# che espone proprietà osservabili attraverso INotifyPropertyChanged, riceve i dati dal livello di infrastruttura e li trasforma in proprietà che la View può visualizzare in binding. Il Model rappresenta le entità di dominio: un Tag, un Allarme, un Setpoint.

Questa separazione non è teorica: ha conseguenze pratiche immediate. Il ViewModel può essere testato con unit test senza aprire nessuna finestra. La View può essere modificata o sostituita senza toccare la logica. Due developer possono lavorare in parallelo su View e ViewModel senza conflitti.

Sul fronte dell'accesso ai dati, si abbandona DAO e ADO (i meccanismi di accesso ai database di VB6) in favore di Entity Framework Core o Dapper. Per i dati di configurazione e di stato, Entity Framework Core con SQLite o SQL Server è la scelta pragmatica. Per i dati time-series, ovvero le letture continue dai sensori, Dapper su TimescaleDB o una libreria client per InfluxDB è più performante.

Sul fronte della comunicazione con i PLC, si abbandona DCOM e OPC Classic in favore di OPC-UA. La libreria ufficiale OPC Foundation .NET Standard, disponibile su NuGet come OPCFoundation.NetStandard.Opc.Ua, è la base su cui costruire il layer di comunicazione. Legge tag, sottoscrive variazioni di valore, scrive setpoint. Tutto con un'interfaccia moderna, tipizzata e testabile.

La struttura consigliata del progetto .NET per uno SCADA ha tre livelli distinti. Il livello di dominio (Domain) contiene le entità come Tag, Allarme, Storico e le interfacce dei servizi. Non dipende da niente di esterno: è puro C# senza riferimenti a librerie esterne. Il livello di infrastruttura (Infrastructure) contiene le implementazioni concrete: il client OPC-UA, i repository per il database, il servizio di storicizzazione. Il livello di presentazione (Presentation) contiene la WPF application, i ViewModel e le View. Dipende dal dominio ma non dall'infrastruttura direttamente, usando le interfacce definite nel dominio e risolte tramite dependency injection.

Questa architettura a livelli è testabile, manutenibile nel tempo e sostituibile in parti. Se in futuro si vuole cambiare il database time-series, si tocca solo il livello di infrastruttura. Se si vuole aggiungere un'interfaccia web oltre all'HMI desktop, si aggiunge un nuovo progetto di presentazione senza toccare il dominio.

Come gestire il protocollo OPC Classic durante la migrazione

OPC Classic è la generazione precedente del protocollo OPC: comprende OPC DA (Data Access, per i dati in tempo reale), OPC HDA (Historical Data Access, per i dati storici) e OPC A&E (Alarms and Events). È basato su tecnologia DCOM di Windows, il che lo rende funzionale ma difficile da configurare, dipendente dalla versione di Windows, e completamente incompatibile con sistemi non-Windows o con architetture cloud.

La maggior parte dei sistemi SCADA legacy italiani usa OPC Classic come protocollo di comunicazione con i PLC. Questo pone un problema preciso durante la migrazione: come si fa a far parlare il nuovo sistema .NET (che vuole usare OPC-UA) con i PLC che espongono solo server OPC Classic?

La risposta è il wrapper OPC-UA. Si tratta di un software che si installa nella rete di campo e funge da traduttore: verso il basso, parla OPC Classic con i PLC e i server OPC esistenti; verso l'alto, espone gli stessi dati come server OPC-UA. Il nuovo sistema .NET vede solo OPC-UA e non sa niente del vecchio protocollo sottostante. I PLC non vengono toccati. La rete di campo non viene modificata. L'investimento nelle configurazioni OPC Classic esistenti viene preservato.

Esistono diverse soluzioni sul mercato per questo wrapper. Technosoftware offre soluzioni che includono sia componenti client che server, con buon supporto per OPC DA e HDA. Unified Automation è un altro fornitore con una suite completa. Prosys OPC è un'altra opzione valida, particolarmente usata in ambito accademico e in installazioni di medie dimensioni. Alcuni vendor SCADA come Kepware (di PTC) offrono soluzioni che includono gateway OPC integrati.

La scelta del wrapper dipende da tre fattori: la versione di OPC Classic usata (DA, HDA, A&E o combinazioni), il numero di tag che devono passare attraverso il gateway (le versioni free o entry-level hanno spesso limiti), e la necessità di supporto commerciale e SLA. In un contesto industriale mission-critical, un fornitore con supporto commerciale è quasi sempre preferibile a una soluzione open source senza garanzie di continuità.

C'è però uno scenario in cui il wrapper non basta: quando il vecchio server OPC Classic è installato su una macchina con Windows XP o Windows 7 che non può essere aggiornata perché ospita anche altri software legacy critici. In questo caso, il wrapper deve essere installato su una macchina separata (anche virtuale) con DCOM configurato per accedere al server OPC Classic remoto. È configurabile, ma richiede attenzione ai permessi DCOM, ai firewall e agli account di servizio.

Una nota importante: la migrazione a OPC-UA non è solo tecnica. È anche strategica. OPC-UA è il protocollo scelto dalla maggior parte dei nuovi PLC come interfaccia nativa (Siemens con S7-1500, Beckhoff, Phoenix Contact), dal mondo del cloud industriale (Azure IoT Hub, AWS IoT), e dalle normative di Industry 4.0. Passare a OPC-UA durante la migrazione SCADA significa allineare l'infrastruttura con il futuro del settore, non solo risolvere il problema presente.

Testare uno SCADA legacy senza fermare la produzione

Il testing in un contesto industriale ha vincoli che non esistono nello sviluppo software tradizionale. Non si può fare un deploy sperimentale in produzione e osservare cosa succede. Non si può accettare un tasso di errore del 2% come "normale" e correggere in corsa. Un errore in un sistema SCADA può significare una linea ferma, un allarme ignorato, o, nei casi peggiori, un rischio per la sicurezza fisica degli operatori.

Il primo strumento di testing è il simulatore PLC. Invece di connettere il nuovo sistema direttamente ai PLC reali dell'impianto, si connette a un simulatore che replica il comportamento dei PLC con valori sintetici. Siemens offre PLCSIM per i suoi S7. Per OPC-UA, esistono server OPC-UA di test come il Prosys OPC UA Simulation Server o il server demo di Unified Automation, che espongono centinaia di nodi con valori che variano in modo realistico. Questo permette di sviluppare e testare il layer di comunicazione senza toccare niente in campo.

Il secondo strumento è il test in shadow mode. Una volta che il nuovo sistema è sufficientemente maturo, lo si connette agli stessi PLC del vecchio sistema in modalità di sola lettura. Il vecchio sistema continua a funzionare normalmente, ma il nuovo sistema legge gli stessi dati in parallelo. Si confrontano i valori letti dai due sistemi per rilevare discrepanze: differenze nei valori, differenze nelle frequenze di aggiornamento, tag mancanti. Questa fase è fondamentale per validare che il nuovo layer di comunicazione sia equivalente al vecchio.

Il terzo strumento è la validazione dei dati storici. Dopo la migrazione di un modulo, si confrontano le serie storiche prodotte dal vecchio sistema e dal nuovo, per un periodo di overlapping. Se il vecchio sistema storicizzava un tag con una frequenza di un campione al secondo, il nuovo deve produrre la stessa frequenza. Se ci sono gap o differenze sistematiche, vanno investigate e risolte prima di disabilitare il vecchio modulo.

Il piano di rollback merita un paragrafo dedicato. Ogni passaggio di migrazione deve avere un rollback definito: quali step eseguire per tornare al vecchio sistema in caso di problemi, in quanto tempo, e chi è responsabile di eseguirlo. Il rollback deve essere testato in staging prima di ogni rilascio in produzione. Non è sufficiente dire "se va male torniamo al vecchio": bisogna sapere esattamente come, in quanto tempo, e verificare che funzioni.

Un approccio complementare è la definizione di acceptance criteria specifici per ogni modulo migrato. Non "il modulo funziona" ma "il modulo legge tutti e 47 i tag previsti con frequenza non inferiore a 500ms, non produce errori di connessione per più di 2 secondi consecutivi, e storicizza correttamente i valori con timestamp accurato". Questi criteri devono essere verificabili automaticamente, con test di integrazione che girano in un ambiente di staging che replica la rete di campo.

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

I dati storici di un sistema SCADA sono spesso il suo asset più prezioso e più trascurato. Anni o decenni di letture di sensori, eventi di allarme, azioni degli operatori: questi dati servono per analisi di performance, per manutenzione predittiva, per audit di conformità regolatoria (specialmente nel farmaceutico), e per debugging di problemi ricorrenti. Perderli durante una migrazione non è accettabile.

Il primo problema è il formato. I sistemi legacy usano Historian proprietari con formati non documentati: WonderWare InSQL (oggi AVEVA System Platform) usa SQL Server come backend ma con uno schema proprietario. OSIsoft PI (oggi AVEVA PI) usa un database binario ottimizzato. Citect usa file proprietari. Alcuni sistemi più datati usano database Access o addirittura file CSV generati periodicamente.

Dove esiste un backend SQL Server, la migrazione è relativamente gestibile: si analizza lo schema, si scrivono query per estrarre i dati con timestamp, valore e nome del tag, e si scrivono script di importazione verso il nuovo database time-series. Dove il formato è completamente proprietario, si usano le API del sistema legacy per esportare i dati in formato standard (CSV, JSON) prima di importarli nel nuovo sistema.

La scelta del database time-series di destinazione dipende dal contesto. InfluxDB è il più diffuso nel mondo IoT e SCADA open source: ha un linguaggio di query specifico (InfluxQL, poi Flux), client .NET ben supportati, e buone performance per query su range temporali. TimescaleDB è un'estensione di PostgreSQL che aggiunge capacità time-series: la scelta ideale per chi vuole le performance di un database time-series con la familiarità di SQL. SQL Server con partitioning è la scelta pragmatica per chi vuole restare nell'ecosistema Microsoft e ha già competenze interne su SQL Server.

La migrazione dei dati storici non è un'operazione una-tantum: è un processo che va pianificato in fasi, validato con campioni, e documentato per garantire l'integrità dei dati. Una pratica comune è migrare prima i dati più recenti (ultimi 12 mesi), validarli, e poi procedere con i dati più vecchi in background mentre il nuovo sistema è già in produzione.

Un problema specifico della migrazione di dati storici è la normalizzazione dei timestamp. I sistemi legacy spesso storicizzano i dati con timestamp del server SCADA locale, che può avere offset rispetto all'UTC, drift nel tempo, o buchi dovuti a riavvii del sistema. Prima di importare i dati nel nuovo sistema, bisogna normalizzare i timestamp, identificare i gap, e documentarli. I gap non vanno colmati con interpolazioni: vanno lasciati come tali e documentati come gap di acquisizione, non come assenza di variazione.

Nel settore farmaceutico e in altri settori regolamentati, la migrazione dei dati storici richiede anche un audit trail: documentazione che dimostri che i dati migrati sono identici ai dati originali, con firma digitale o hash dei dataset originali e di quelli migrati. Questo è un requisito FDA 21 CFR Part 11 che non può essere ignorato se si vuole mantenere la validazione del sistema.

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

L'Italia è uno dei paesi manifatturieri più importanti d'Europa. Il distretto automotive del Nord Italia, i cluster farmaceutici di Lazio e Lombardia, il food and beverage del Nord-Est, i distretti tessili e meccanici della Toscana e dell'Emilia: tutti questi settori hanno impianti con sistemi SCADA, e una percentuale significativa di questi impianti gira ancora su tecnologie degli anni '90 o dei primi anni 2000.

Il problema strutturale è che i developer che sapevano lavorare su quei sistemi stanno uscendo dal mercato del lavoro per pensionamento, e non vengono rimpiazzati. La nuova generazione di developer non conosce VB6, Delphi o i protocolli industriali. Le aziende si trovano in una posizione scomoda: devono modernizzare i loro sistemi, ma non trovano le competenze per farlo.

Questo divario crea un'opportunità concreta per un developer C# con competenze in WPF che decide di specializzarsi nel mondo industriale. Non è necessario diventare un ingegnere di automazione. Non è necessario sapere programmare i PLC. È necessario saper costruire applicazioni .NET solide, capire i concetti base dei sistemi industriali (cosa è un tag, come funziona OPC-UA, cosa si intende per storicizzazione), e saper lavorare in contesti dove la tolleranza al fallimento è molto più bassa rispetto allo sviluppo web.

I range di compensation per queste figure nel mercato italiano: un developer C# junior che entra in una software house specializzata in SCADA industriali parte da 28.000-35.000 euro. Un profilo mid con 3-5 anni di esperienza, competenze in WPF, OPC-UA e gestione di progetti di migrazione, si posiziona tra 45.000 e 65.000 euro. Un senior o un tecnico di riferimento con esperienza documentata in migrazioni su impianti reali supera i 70.000 euro, con profili che lavorano in consulenza che arrivano a 100-130 euro l'ora come freelance. Questi numeri sono significativamente più alti rispetto al developer C# puro nel settore dello sviluppo applicativo tradizionale, a parità di anzianità.

I settori con più domanda in Italia nel 2026 sono quattro. Il settore farmaceutico è il più esigente in termini di qualità e compliance, ma è anche quello che paga di più e che ha la maggiore urgenza di modernizzazione per rispettare le normative FDA e EMA. Il settore automotive (in particolare la filiera di fornitura che lavora per i grandi OEM) ha masse di impianti da modernizzare e budget relativamente disponibili. Il food and beverage ha impianti mediamente più piccoli ma numerosi e geograficamente distribuiti su tutto il territorio nazionale. Il settore delle utilities, acqua e energia, ha requisiti di continuità operativa estremi e budget pubblici che vengono stanziati con cadenza regolare per la modernizzazione delle infrastrutture.

C'è un ulteriore vantaggio competitivo per chi entra in questo settore oggi: la barriera all'ingresso è alta non per difficoltà tecnica, ma per la combinazione di competenze richiesta. Trovare un developer che sa scrivere codice C# solido, conosce WPF, capisce i sistemi industriali e non si spaventa davanti a un impianto di produzione è difficile. Chi costruisce questa combinazione oggi diventa difficilmente sostituibile.

Come formarsi per diventare il developer SCADA che le aziende cercano

La buona notizia è che il percorso per entrare in questo mercato è più accessibile di quanto sembri, se si parte da una base C# solida. Non servono anni di studio dell'automazione industriale. Servono competenze specifiche, costruite nel giusto ordine, con il giusto livello di profondità.

Il primo livello è C# solido. Non significa conoscere tutti i design pattern o avere esperienza in tutti i framework .NET. Significa saper scrivere codice pulito, capire la gestione della memoria, sapere usare async/await in modo corretto (fondamentale per le applicazioni SCADA che devono gestire centinaia di connessioni concorrenti), e conoscere i principi SOLID abbastanza da applicarli senza pedanteria. Se non si è sicuri su questi fondamentali, è il primo posto dove investire.

Il secondo livello è WPF e MVVM. WPF non è una tecnologia morta: nel mondo industriale desktop è lo standard di fatto per le interfacce HMI su Windows. Sapere costruire un'interfaccia WPF con data binding, template, trigger e il pattern MVVM implementato correttamente è una competenza molto richiesta e relativamente rara tra i developer più giovani che sono cresciuti con il web.

Il terzo livello è OPC-UA. Non è necessario diventare esperti del protocollo nel dettaglio. È necessario saper usare la libreria OPC Foundation .NET per connettere un client OPC-UA a un server, leggere nodi, sottoscrivere variazioni di valore e scrivere valori. Questo si impara in qualche giorno di pratica su un server OPC-UA di test. La comprensione concettuale del modello a nodi di OPC-UA e dei meccanismi di sottoscrizione viene con la pratica.

Il quarto livello è la conoscenza dei database time-series. InfluxDB o TimescaleDB: come si inseriscono dati ad alta frequenza, come si interroga per range temporali, come si gestisce la retention dei dati. Anche questo si impara in modo pratico, montando un'istanza locale e scrivendo codice di inserimento e query.

Il quinto livello, quello che fa la differenza in un contesto di migrazione legacy, è la conoscenza dei sistemi legacy stessi. Non bisogna saper scrivere VB6. Bisogna saper leggere codice VB6 abbastanza da capire cosa fa, estrarre le logiche di business, e identificare i punti di integrazione con i PLC. Questo si acquisisce leggendo codice legacy reale durante i progetti di migrazione, o cercando esempi di sistemi VB6 open source per fare pratica.

Il percorso ideale per chi parte da zero con C# e vuole entrare nel mercato industriale in 12-18 mesi: tre mesi su C# avanzato e WPF/MVVM, due mesi su OPC-UA e database time-series, poi un progetto personale che simuli un sistema SCADA completo (HMI con WPF, connessione a un server OPC-UA di simulazione, storicizzazione su InfluxDB). Questo progetto, con il codice su GitHub, vale più di qualsiasi certificazione.

La formazione strutturata accelera questo percorso in modo significativo. Un corso con tutor che conosce sia il mondo .NET che il mondo industriale riduce il tempo di apprendimento e, soprattutto, evita di costruire competenze nel modo sbagliato (architetture che non scalano, dipendenze che rendono il codice non testabile, pattern di comunicazione OPC-UA che funzionano in laboratorio ma non reggono su un impianto reale con centinaia di tag).