WPF per il pannello operatore, Blazor per il dashboard del responsabile: la guida definitiva alle HMI SCADA in .NET

Un operatore di linea non è un utente qualunque.

Lavora in ambienti rumorosi, a volte indossa guanti da lavoro pesanti, guarda schermi montati a distanza e deve prendere decisioni in pochi secondi. Una valvola che si chiude in modo anomalo, un allarme di temperatura fuori soglia, un motore che raggiunge la velocità massima: ogni segnale ha un significato preciso e ogni ritardo ha un costo.

Costruire un'interfaccia per lui è completamente diverso dal costruire qualsiasi altra applicazione software. Non è questione di palette di colori o di animazioni curate. È questione di sicurezza, di produzione, di responsabilità. Un pulsante difficile da premere con i guanti, un allarme che si confonde visivamente con gli altri, un grafico che si aggiorna con mezzo secondo di ritardo: queste non sono questioni di UX nel senso tradizionale del termine, sono rischi operativi con conseguenze misurabili.

Poi c'è il responsabile di produzione. Vuole vedere i KPI dall'ufficio, dal tablet in sala riunioni, magari anche da casa durante un fermo notturno. Ha bisogno di un'interfaccia diversa, più analitica, accessibile da browser, senza dover installare niente su ogni postazione.

Due utenti diversi, due esigenze diverse, due contesti operativi opposti. Il developer .NET si trova davanti a una domanda concreta: WPF o Blazor per le HMI SCADA? E la risposta, come vedremo, non è semplice come sembra.

Nel mondo dell'automazione industriale, la scelta del framework per l'interfaccia non è mai solo tecnica. È una decisione che impatta la vita dell'impianto per anni, a volte per decenni. I pannelli operatore si installano, si configurano e poi rimangono lì, spesso senza aggiornamenti, finché la macchina stessa non viene sostituita. Sbagliare la scelta significa ritrovarsi con un'interfaccia che funziona male in produzione, con operatori frustrati, con ingegneri di processo che chiedono modifiche impossibili e con costi di manutenzione imprevisti.

Questa guida nasce da una domanda reale che i developer .NET si pongono sempre più spesso: come si costruisce correttamente un'HMI industriale nel 2026? Quali tecnologie scegliere, quando sceglierle e, soprattutto, perché.

Troverai un confronto diretto tra WPF e Blazor con casi d'uso concreti, l'architettura MVVM applicata a uno scenario SCADA reale, le librerie grafiche che reggono davvero in produzione e le opportunità di mercato per chi sa fare questo lavoro.

Cosa rende un'interfaccia HMI SCADA diversa da qualsiasi altra applicazione

Prima di confrontare WPF e Blazor, bisogna capire che tipo di interfaccia stiamo costruendo. Perché un'HMI SCADA non è solo un'applicazione con qualche dato in più. È una categoria a sé.

Il termine HMI, Human-Machine Interface, descrive letteralmente l'interfaccia tra l'operatore umano e la macchina industriale. Lo SCADA, Supervisory Control and Data Acquisition, è il sistema più ampio che raccoglie i dati, li storicizza e permette la supervisione dell'intero impianto. L'HMI è il "cruscotto" dello SCADA: quello che l'operatore vede e con cui interagisce.

Costruire un'HMI significa affrontare sfide che non esistono in nessun altro tipo di applicazione software.

La prima è l'aggiornamento ad alta frequenza. Un impianto industriale può generare decine, centinaia o migliaia di misure al secondo: temperature, pressioni, portate, velocità, stati digitali. L'HMI deve ricevere questi dati, elaborarli e aggiornarsi senza mai bloccarsi. Un freeze dell'interfaccia, anche di pochi secondi, può essere sufficiente perché un operatore non veda un allarme critico in tempo.

La seconda è la grafica simbolica di impianto. Le HMI industriali mostrano schemi P&ID (Process and Instrumentation Diagram): rappresentazioni grafiche dell'impianto dove ogni valvola, ogni pompa, ogni serbatoio e ogni tubazione è disegnata nella sua posizione reale. Questi elementi cambiano stato in tempo reale: una valvola si apre o si chiude, un serbatoio si riempie o si svuota, un motore cambia colore in base alla sua condizione. Non esistono componenti standard per questo tipo di grafica in nessun framework.

La terza è la gestione degli allarmi con priorità. Un sistema SCADA professionale ha centinaia di condizioni di allarme, classificate per severità (critico, urgente, avviso, informativo), con logiche di riconoscimento, di silenzio temporaneo e di escalation. Un operatore non può perdere un allarme critico tra una lista di avvisi di bassa priorità. L'interfaccia deve guidare la sua attenzione in modo preciso.

La quarta è la conferma esplicita dei comandi. Quando un operatore clicca su "Apri valvola V-101", l'interfaccia non esegue immediatamente il comando. Prima mostra un dialogo di conferma: "Stai per aprire la valvola V-101 sul circuito di raffreddamento. Confermi?". Questo non è una scelta di UX: è un requisito di sicurezza funzionale per molte normative di settore, compresa la IEC 62061 e la ISO 13849.

La quinta è l'audit log obbligatorio. Ogni azione dell'operatore, ogni comando inviato, ogni parametro modificato deve essere registrato in modo immutabile: chi ha fatto cosa, quando, da quale postazione, con quale valore precedente e quale nuovo. Non è una nice-to-have: in molti settori come farmaceutico e food&beverage è un requisito normativo.

L'utente finale di un'HMI SCADA non è un developer: è un operatore con decenni di esperienza su quella macchina specifica, che lavora in condizioni difficili e non ha tempo per capire un'interfaccia mal progettata.

Tenerlo presente è la differenza tra un'HMI che funziona davvero in produzione e una che viene agggirata dagli operatori entro tre mesi dalla messa in servizio.

WPF per HMI SCADA: i punti di forza e quando sceglierlo

WPF, Windows Presentation Foundation, è stato introdotto da Microsoft nel 2006 e da allora è rimasto la tecnologia di riferimento per le HMI desktop su Windows. Non per inerzia: per ragioni tecniche precise che ancora nel 2026 nessun framework alternativo ha completamente superato per il caso d'uso industriale.

Il primo punto di forza è il rendering hardware-accelerato tramite DirectX. WPF non usa GDI+ come le vecchie applicazioni Windows Forms: usa la scheda grafica per disegnare la UI. Questo significa che aggiornare migliaia di elementi grafici contemporaneamente, come un trend con 10.000 punti o uno schema di impianto con 200 elementi animati, non carica la CPU. La GPU fa il lavoro pesante.

Il secondo è il sistema di data binding con MVVM. WPF è stato progettato per il pattern MVVM. Il binding bidirezionale tra ViewModel e View, gestito dal runtime, elimina la necessità di scrivere codice per aggiornare l'interfaccia manualmente. Quando il ViewModel notifica una variazione tramite INotifyPropertyChanged, la View si aggiorna automaticamente. Per un'HMI con centinaia di tag, questo è un vantaggio architetturale enorme.

Il terzo è la flessibilità grafica. Con WPF puoi disegnare qualsiasi elemento grafico personalizzato usando DrawingVisual per le massime prestazioni o Path e Geometry per forme complesse. Una valvola che ruota, un serbatoio che si riempie con un'animazione fluida, un indicatore di livello personalizzato: tutto è realizzabile in XAML senza dipendenze esterne.

Il quarto è il supporto nativo per touchscreen. I pannelli operatore industriali moderni sono quasi tutti touch. WPF supporta i gesti multi-touch nativamente dal 2010, con API per rilevare tap, slide, pinch e rotate. Non serve nessuna libreria aggiuntiva per rendere un'HMI WPF completamente operabile via touch.

Il quinto è l'integrazione con l'ecosistema Windows. Un'HMI industriale su Windows può usare l'autenticazione integrata di Active Directory, accedere al registro di sistema per la configurazione, comunicare con altri processi via WCF o named pipes e usare le API Win32 per funzionalità di basso livello. Su WPF tutto questo è diretto e ben documentato.

Per le librerie grafiche, il panorama nel 2026 è maturo. ScottPlot è la scelta principale per i trend SCADA: gestisce milioni di punti, si aggiorna da thread secondari senza freeze della UI e ha un'API pulita. LiveCharts2 è più adatta quando la presentazione estetica conta più delle prestazioni, come nei dashboard direzionali. Syncfusion e Telerik offrono componenti industriali specifici come radial gauges, led indicators, digital displays e state machines che replicano fedelmente l'aspetto degli strumenti fisici.

WPF è la scelta giusta quando: il pannello operatore è un PC Windows dedicato, la frequenza di aggiornamento supera i 5 tag al secondo, la grafica dell'impianto è complessa e personalizzata, la connessione di rete non è garantita (l'HMI deve funzionare anche offline) e le prestazioni di rendering sono critiche.

Blazor per HMI SCADA: il web che entra in fabbrica

Blazor ha cambiato il modo di pensare alle interfacce industriali. Non sostituisce WPF per le HMI operative ad alta frequenza, ma apre uno spazio nuovo che prima richiedeva JavaScript o framework frontend separati: le dashboard di supervisione web-based per SCADA.

Esistono due varianti di Blazor con caratteristiche molto diverse per il mondo industriale. Blazor Server esegue tutta la logica applicativa sul server ASP.NET Core e comunica con il browser tramite una connessione WebSocket SignalR. La UI è aggiornata in tempo reale dal server: quando un dato cambia, il server invia il diff della UI al browser che si aggiorna. Blazor WebAssembly invece scarica l'applicazione .NET nel browser e la esegue localmente tramite WebAssembly, senza dipendenza dal server per l'elaborazione.

Per le applicazioni SCADA industriali, la scelta è quasi sempre Blazor Server. Il motivo è semplice: i dati provengono da un backend industriale (OPC UA, PLC, database time-series) che gira sul server. Con Blazor Server il servizio di lettura dati e l'aggiornamento della UI vivono nello stesso processo, eliminando una chiamata di rete. Con Blazor WebAssembly bisogna aggiungere un layer API REST o gRPC tra il browser e il backend industriale, aumentando la complessità e la latenza.

Il vantaggio principale di Blazor per le HMI industriali è l'accessibilità multi-device senza installazione. Un responsabile di produzione può aprire il browser su qualsiasi dispositivo, accedere al dashboard di supervisione e vedere lo stato dell'impianto in tempo reale. Nessuna installazione di client, nessuna configurazione di postazione, nessun aggiornamento manuale. Questo è un vantaggio enorme rispetto a WPF in scenari di supervisione distribuita.

Il limite principale di Blazor Server per le HMI è la latenza della connessione SignalR. Ogni aggiornamento UI passa per: server elabora la variazione, calcola il diff, invia il messaggio WebSocket, il browser riceve il messaggio, aggiorna il DOM. Questo ciclo tipicamente impega 50-200 millisecondi in una rete LAN aziendale. Per un responsabile che guarda i KPI ogni 5 secondi è irrilevante. Per un operatore che monitora un processo con variazioni a 10 Hz, è inaccettabile.

La regola pratica è questa: Blazor Server è adatto per aggiornamenti fino a 1-2 Hz, ovvero quando i dati si aggiornano ogni secondo o più lentamente. Sopra questa soglia, WPF è la scelta corretta.

Un altro vantaggio di Blazor è la possibilità di riutilizzare componenti e logica di business tra applicazione web e API. Un team che conosce già ASP.NET Core è operativo su Blazor Server in tempi brevi, senza dover imparare un nuovo framework frontend.

Confronto diretto WPF vs Blazor per HMI industriali: la tabella decisionale

Mettere a confronto WPF e Blazor per le HMI SCADA significa valutare una serie di criteri che dipendono dal contesto specifico. Non esiste una risposta universale: esiste la risposta giusta per ogni caso d'uso.

Frequenza di aggiornamento dei dati. WPF aggiorna la UI decine di volte al secondo senza problemi, limitato solo dalla frequenza del monitor (tipicamente 60 Hz). Blazor Server è pratico fino a 1-2 aggiornamenti al secondo per via della latenza SignalR. Vince WPF per le HMI operative, Blazor per le dashboard.

Accessibilità multi-device. WPF gira solo su Windows desktop. Blazor gira su qualsiasi browser, su qualsiasi sistema operativo, su qualsiasi dispositivo. Per la supervisione da remoto o da mobile, Blazor non ha alternative in .NET. Vince Blazor senza discussione.

Complessità grafica personalizzata. WPF permette di costruire qualsiasi elemento grafico: valvole animate, schemi di impianto interattivi, gauge radiali, display digitali. Blazor dipende da librerie JavaScript per la grafica avanzata (Chart.js, D3.js tramite interop) o da componenti commerciali come Syncfusion Blazor. Per gli schemi P&ID complessi, WPF è ancora superiore. Vince WPF per la grafica industriale.

Manutenzione e aggiornamento centralizzati. Con Blazor Server, aggiornare l'applicazione significa aggiornare il server: tutti i client ricevono automaticamente la nuova versione al prossimo accesso. Con WPF, ogni pannello operatore deve essere aggiornato individualmente, il che in un impianto con 50 postazioni è un problema operativo reale. Vince Blazor per la manutenzione.

Funzionamento offline. WPF continua a funzionare anche se la rete è assente: i dati arrivano localmente tramite OPC UA al server SCADA sulla stessa macchina o sulla rete locale. Blazor Server richiede una connessione attiva al server: se la rete cade, l'interfaccia si blocca. Vince WPF per gli scenari con connessione instabile.

Costo hardware delle postazioni. Un pannello industriale con WPF richiede Windows, almeno 4-8 GB di RAM e un processore adeguato. Un client Blazor può girare su un thin client economico, un tablet Android o un iPad: basta un browser moderno. Per installazioni con molte postazioni di supervisione, Blazor riduce significativamente il costo hardware. Vince Blazor per il costo del parco macchine.

La regola pratica che emerge da questi confronti è chiara: WPF per il pannello operatore di linea, Blazor per il dashboard manageriale e di supervisione remota. In un progetto SCADA professionale, si usano spesso entrambi.

Implementare il pattern MVVM in un HMI WPF SCADA: struttura del progetto

Il pattern MVVM, Model-View-ViewModel, non è solo una convenzione di codice in WPF: è la struttura che rende mantenibile un'HMI industriale nel tempo. Un progetto ben organizzato con MVVM permette di modificare la logica di lettura dati senza toccare l'interfaccia, e di cambiare la grafica senza toccare la logica applicativa.

La struttura a livelli di un progetto HMI WPF SCADA professionale si organizza in questo modo.

Il livello più basso è il layer di comunicazione OPC UA. Contiene il servizio che si connette al server OPC UA, sottoscrive i tag di interesse e riceve le notifiche di variazione. Questo layer è completamente indipendente dalla UI. Quando un valore cambia, pubblica un evento o chiama un callback. La libreria di riferimento è OPC Foundation .NET Standard, disponibile su NuGet.

Sopra il layer OPC UA troviamo il Model. Il Model contiene le entità del dominio industriale: la classe Tag con le sue proprietà (nome, valore corrente, unità di misura, timestamp, qualità del dato), la classe Alarm con severità e stato di riconoscimento, la classe Machine con il suo stato operativo. Il Model non sa nulla di WPF.

Il ViewModel è il cuore dell'HMI. Implementa INotifyPropertyChanged, espone proprietà bindabili alla View e contiene la logica di presentazione. Quando riceve un aggiornamento dal layer OPC UA, deve portarlo sul thread UI prima di aggiornare le proprietà: in WPF, le notifiche di PropertyChanged devono sempre venire dal thread UI.

Il modo corretto per aggiornare la UI da un thread secondario è usare Dispatcher.InvokeAsync:

// Nel ViewModel, quando arriva un dato da OPC UA su un thread secondario
private async void OnTagValueChanged(string tagName, double newValue)
{
    await Application.Current.Dispatcher.InvokeAsync(() =>
    {
        TemperaturaReattore = newValue;
        UltimoAggiornamento = DateTime.Now;
    });
}

Per la gestione degli allarmi attivi, il ViewModel espone un'ObservableCollection che la View può filtrare e ordinare tramite CollectionView. Gli allarmi critici devono sempre apparire in cima alla lista, indipendentemente dall'ordine di arrivo.

La View è lo XAML che traduce le proprietà del ViewModel in elementi visivi. Il binding in WPF è potente: puoi bindare non solo i valori, ma anche i colori, la visibilità degli elementi, le animazioni. Un indicatore che diventa rosso quando la temperatura supera la soglia è semplicemente un binding con un Converter che trasforma il valore numerico in un colore.

Per i comandi degli operatori, il ViewModel espone oggetti ICommand (tipicamente RelayCommand o AsyncRelayCommand dalla libreria CommunityToolkit.Mvvm). Il pattern Command in WPF separa la logica dal pulsante: il pulsante non sa cosa succede quando viene premuto, sa solo che deve eseguire un comando.

Una pratica fondamentale per le HMI SCADA è non bloccare mai il thread UI. Tutte le operazioni di I/O (lettura da database, invio comandi al PLC, scrittura dell'audit log) devono essere asincrone. Un thread UI bloccato per 200 millisecondi in attesa di una risposta dal PLC è un'HMI che smette di aggiornarsi, e un operatore che può perdere un segnale critico.

Grafici real-time in WPF: ScottPlot e LiveCharts2 per trend SCADA

Il grafico dei trend è probabilmente il componente più critico di un'HMI SCADA. L'operatore guarda il grafico della temperatura del reattore degli ultimi 30 minuti per capire se il processo sta andando nella direzione giusta. Il responsabile di manutenzione guarda il trend delle vibrazioni di un motore per anticipare un guasto imminente.

Il problema dei grafici real-time in WPF è il garbage collector di .NET. Un grafico che riceve 100 punti al secondo e mantiene 10 minuti di storia ha 60.000 punti da gestire. Se ogni punto è un oggetto .NET separato, la pressure sulla memoria è enorme, con conseguenti pause GC che bloccano la UI per decine di millisecondi. La soluzione è usare array circolari di tipi primitivi (double), non liste di oggetti.

ScottPlot è la libreria che risolve questo problema nel modo più diretto. Nasce esattamente per questo caso d'uso: grafici scientifici e industriali ad alta frequenza in WPF e WinForms. Internamente usa array di double pre-allocati e rendering diretto su bitmap. Il risultato è un grafico che si aggiorna a 60 Hz con 100.000 punti senza consumare CPU misurabile.

L'integrazione di ScottPlot in un progetto WPF SCADA è semplice. Il grafico si aggiorna dal thread del timer, non dal thread UI, usando il metodo Render thread-safe:

// Inizializzazione nel ViewModel
private readonly double[] _timestamps = new double[36000]; // 1 ora a 10 Hz
private readonly double[] _values = new double[36000];
private int _nextIndex = 0;

// Aggiunta punto (chiamato dal servizio OPC UA su thread secondario)
public void AggiungiMisurazione(double timestamp, double valore)
{
    _timestamps[_nextIndex % 36000] = timestamp;
    _values[_nextIndex % 36000] = valore;
    _nextIndex++;
    GraficoTemperatura.Plot.Clear();
    GraficoTemperatura.Plot.Add.Signal(_values);
    GraficoTemperatura.Refresh();
}

LiveCharts2 ha un approccio diverso. Usa un modello a oggetti più ricco (serie, punti, assi con etichette formattate) e produce grafici graficamente più raffinati, con animazioni fluide e tooltips interattivi. Il prezzo è una maggiore complessità interna e prestazioni inferiori con dataset molto grandi. LiveCharts2 è la scelta giusta per i dashboard direzionali WPF dove la presentazione conta quanto le prestazioni, e per frequenze di aggiornamento sotto i 5 Hz.

Syncfusion e Telerik offrono invece componenti diversi dai grafici di trend: radial gauges (i manometri circolari tipici delle HMI industriali), linear gauges, bullet charts, digital displays e state machines animate. Questi componenti replicano fedelmente l'aspetto degli strumenti fisici che gli operatori conoscono, riducendo il tempo di apprendimento dell'interfaccia. Il costo è una licenza commerciale.

Per scegliere tra ScottPlot e LiveCharts2 si possono seguire due criteri: se la frequenza di aggiornamento supera 5 Hz o se il dataset ha più di 10.000 punti, scegliere ScottPlot. Se la frequenza è inferiore a 5 Hz e l'estetica del grafico è importante, LiveCharts2 è la scelta migliore.

Dashboard SCADA con Blazor Server e SignalR: architettura e implementazione

La dashboard web SCADA con Blazor Server ha un'architettura a tre livelli che è elegante per chi conosce ASP.NET Core. Il servizio in background legge i dati industriali, l'Hub SignalR fa da canale di distribuzione verso i client connessi, i componenti Blazor si iscrivono agli aggiornamenti e ridisegnano la UI.

Il servizio in background è un IHostedService che gira in continuazione nella vita dell'applicazione ASP.NET Core. Legge i dati da OPC UA, da un database time-series o da un'API SCADA interna, e pubblica le variazioni sullo Hub SignalR. La frequenza di pubblicazione è configurable: per un dashboard manageriale, aggiornare ogni 2-5 secondi è più che sufficiente.

Lo Hub SignalR è il punto di distribuzione centralizzato. I client Blazor si connettono allo Hub e ricevono messaggi tipizzati in C#, senza bisogno di scrivere JavaScript. SignalR gestisce automaticamente la riconnessione in caso di interruzione di rete, con una logica di retry configurabile.

Il componente Blazor che mostra, per esempio, lo stato delle macchine e l'OEE in tempo reale implementa IAsyncDisposable per gestire correttamente la sottoscrizione allo Hub:

Il ciclo di vita corretto è: OnInitializedAsync si sottoscrive allo Hub e richiede i dati iniziali, il metodo callback aggiorna le proprietà del componente e chiama StateHasChanged() per forzare il ridisegno della UI, Dispose cancella la sottoscrizione per evitare memory leak.

Un caso d'uso tipico per questa architettura è il dashboard del responsabile di produzione: mostra lo stato di tutte le macchine della linea (verde = in produzione, giallo = in attesa, rosso = in allarme), l'OEE complessivo aggiornato in tempo reale, le ultime 10 segnalazioni di allarme e i KPI di produzione della giornata come pezzi prodotti e scarti.

Questo dashboard può essere aperto su qualsiasi browser: il responsabile di produzione lo consulta sul suo laptop in ufficio, il direttore di stabilimento lo apre sul tablet durante il giro di produzione, il responsabile della qualità lo monitora da remoto. Nessuna installazione, nessuna configurazione, solo un browser e le credenziali di accesso.

La gestione della disconnessione è un aspetto critico che molti trascurano. Quando un client Blazor Server perde la connessione al server, la sessione viene mantenuta sul server per un tempo configurabile (di default 3 minuti) in attesa della riconnessione. Durante questo tempo, le modifiche di stato vengono accodate. Se la riconnessione avviene entro il timeout, il client riceve lo stato aggiornato. Se il timeout scade, la sessione viene eliminata e il client deve fare una nuova navigazione. L'interfaccia deve comunicare chiaramente all'operatore lo stato della connessione con un indicatore visivo dedicato.

Sicurezza e gestione utenti nelle interfacce HMI SCADA

La sicurezza di un'HMI SCADA non è opzionale. In molti settori è un requisito normativo: la FDA 21 CFR Part 11 per il farmaceutico, la IEC 62443 per l'automazione industriale generale, la NERC CIP per le infrastrutture energetiche. Anche al di fuori degli obblighi normativi, un'HMI senza controllo degli accessi è un rischio operativo e di sicurezza.

Il modello di controllo accessi standard per le HMI industriali prevede almeno quattro livelli di utenza, con permessi crescenti.

L'Operatore è il livello base. Può visualizzare tutti i dati dell'impianto, riconoscere gli allarmi, eseguire i comandi standard di produzione (avvio ciclo, fine turno, scelta del prodotto). Non può modificare i parametri di processo o la configurazione del sistema.

Il Supervisore ha le stesse capacità dell'operatore più la possibilità di modificare i parametri operativi entro range predefiniti (setpoint di temperatura, velocità di linea), silenziare allarmi specifici con motivazione registrata e sbloccare situazioni di stallo nel processo.

L'Ingegnere di processo ha accesso a tutti i parametri del sistema, incluse le soglie di allarme, le ricette di produzione e la configurazione delle logiche di controllo. Questo utente può modificare il comportamento del sistema in modo significativo: ogni sua azione deve essere registrata in modo tracciabile.

L'Amministratore gestisce gli utenti, assegna i ruoli, configura il sistema di autenticazione e ha accesso ai log di audit completi. È l'unico che può creare nuovi account o modificare i permessi esistenti.

Per WPF, l'autenticazione più comune negli ambienti industriali è l'autenticazione Windows integrata tramite Active Directory. Il PC operatore è sul dominio aziendale, l'utente si autentica al login di Windows e l'HMI ottiene automaticamente le credenziali tramite WindowsIdentity. Non serve una schermata di login separata. I ruoli si mappano a gruppi AD.

Per Blazor Server, si usa ASP.NET Core Identity con autenticazione Windows integrata (se siamo su rete aziendale con AD) o con autenticazione form-based per accesso da remoto. Il middleware di autorizzazione di ASP.NET Core permette di proteggere pagine e componenti con attributi [Authorize] e policy di accesso.

L'audit log è il requisito trasversale a tutti i livelli di accesso. Ogni comando inviato alla macchina deve generare una riga di log con almeno questi campi: timestamp preciso (con fuso orario), username dell'operatore, nome della postazione, azione eseguita, identificatore dell'oggetto (tag o macchina), valore precedente, nuovo valore, esito (successo o errore). Questo log deve essere scritto su un database separato, idealmente in sola aggiunta, e non deve essere modificabile dagli utenti dell'HMI nemmeno con i massimi permessi.

Un ultimo aspetto spesso trascurato è il timeout di sessione automatico. In un impianto industriale, un operatore può essere chiamato altrove lasciando il pannello incustodito. Se il pannello rimane aperto con la sessione attiva dell'operatore, chiunque si avvicini può eseguire comandi con le sue credenziali. Il timeout di sessione con richiesta di ri-autenticazione dopo un periodo di inattività è una misura di sicurezza semplice ma fondamentale.

Integrare WPF e Blazor nello stesso progetto SCADA: architettura ibrida

La domanda pratica che i developer si pongono spesso è: posso avere entrambi? Un pannello WPF per l'operatore di linea e un dashboard Blazor per il responsabile, nello stesso progetto, con lo stesso codice di business logic?

La risposta è sì, ed è esattamente l'architettura raccomandata per i progetti SCADA professionali nel 2026.

Il segreto è separare correttamente i layer. La logica di business, cioè la lettura dei dati da OPC UA, la gestione degli allarmi, la scrittura dell'audit log e le regole di business dell'impianto, deve vivere in librerie .NET Standard indipendenti da qualsiasi framework UI. Queste librerie vengono poi consumate sia dall'applicazione WPF che dall'applicazione ASP.NET Core che ospita Blazor Server.

La struttura tipica di una soluzione di questo tipo in Visual Studio è composta da questi progetti: un progetto class library per i modelli del dominio (Tag, Alarm, Machine, AuditEntry), un progetto class library per i servizi (OpcUaService, AlarmService, AuditLogService, HistoryService), un progetto WPF che consuma questi servizi e costruisce l'HMI desktop, un progetto ASP.NET Core con Blazor Server che consuma gli stessi servizi e costruisce il dashboard web.

Con questa struttura, il codice di comunicazione OPC UA è scritto una volta sola e usato da entrambe le applicazioni. Le regole di business dell'allarme, per esempio la logica per cui un allarme di temperatura critico rimane attivo finché non viene riconosciuto dall'operatore, sono implementate una volta nel service layer e si comportano in modo identico nell'HMI WPF e nel dashboard Blazor.

Il layer di sincronizzazione tra le due interfacce può essere implementato in vari modi. Il più semplice è condividere lo stesso database come unica sorgente di verità: l'HMI WPF scrive l'azione dell'operatore nel database, il dashboard Blazor legge lo stato dal database. Più sofisticato è usare un bus di messaggi interno come i canali di System.Threading.Channels o un sistema di coda leggero, in modo che le variazioni di stato vengano propagate in tempo reale a tutti i consumer, sia l'HMI WPF che il dashboard Blazor.

Un pattern utile in questo contesto è il shared ViewModel: lo stesso ViewModel del dominio, che rappresenta per esempio lo stato di una macchina, viene usato sia dal layer WPF che dal layer Blazor. In WPF il ViewModel implementa INotifyPropertyChanged per la UI. In Blazor Server, il componente Blazor osserva le stesse proprietà e chiama StateHasChanged quando queste variano.

Questa architettura ibrida è quella che distingue i progetti SCADA professionali dagli approcci one-size-fits-all. Non è più complessa da mantenere: al contrario, riduce la duplicazione del codice e garantisce che le due interfacce mostrino sempre dati coerenti.

Sicurezza informatica nelle HMI SCADA: le minacce reali e come difendersi

Le HMI industriali sono diventate un bersaglio reale per gli attacchi informatici. Negli ultimi anni, incidenti come l'attacco alla rete elettrica ucraina del 2015 o il tentativo di avvelenamento dell'acquedotto di Oldsmar in Florida nel 2021 hanno dimostrato che le interfacce di controllo industriale, incluse le HMI, sono punti di ingresso per chi vuole causare danni fisici a infrastrutture critiche.

Il problema strutturale è che molte HMI sono state progettate in un'epoca in cui la sicurezza informatica non era una preoccupazione nel mondo OT. Erano sistemi isolati, non connessi a internet, non raggiungibili dall'esterno. Con Industry 4.0, il cloud e il monitoraggio remoto, questo isolamento è venuto meno, ma spesso le misure di sicurezza non sono state aggiornate di conseguenza.

La prima misura di sicurezza è la segmentazione di rete. La rete OT, dove vivono i PLC, i server SCADA e i pannelli HMI, deve essere fisicamente o logicamente separata dalla rete IT aziendale. Tra le due deve esistere una DMZ con firewall che filtri il traffico in modo unidirezionale: i dati possono uscire dalla rete OT verso la rete IT, ma non possono entrare dalla rete IT verso la rete OT senza controlli espliciti.

La seconda misura è l'autenticazione forte. Le HMI WPF devono usare autenticazione Windows con Active Directory, non username e password locali. Le dashboard Blazor esposte su rete IT devono usare HTTPS obbligatorio, autenticazione con certificati o MFA. Le connessioni OPC UA devono usare il Security Mode SignAndEncrypt con certificati X.509: questa modalità autentica sia il client che il server e cifra tutti i dati in transito.

La terza misura è il principio del minimo privilegio. Il servizio che legge i dati da OPC UA deve avere solo i permessi di lettura sui tag che gli servono, non l'accesso completo a tutto il server OPC UA. Il servizio che invia comandi deve avere i permessi di scrittura solo sui tag che l'HMI deve comandare. Un attacco che compromette il processo dell'HMI deve trovare il minor numero possibile di permessi con cui fare danni.

La quarta misura, spesso sottovalutata, è il processo di aggiornamento sicuro. Un pannello WPF in fabbrica non riceve mai gli aggiornamenti di Windows perché "non si tocca ciò che funziona". Nel giro di qualche anno, questo pannello accumula vulnerabilità note con exploit pubblici. La soluzione è avere un ambiente di test equivalente alla produzione, validare gli aggiornamenti in staging e avere una procedura di rollback rapida. Il costo di questo processo è molto inferiore al costo di un incidente di sicurezza su un impianto produttivo.

Il mercato delle HMI industriali in Italia: opportunità per i developer .NET

Il mercato italiano della manifattura è il secondo in Europa per dimensioni, dopo la Germania. Automotive, food&beverage, farmaceutico, petrolchimico, meccanica di precisione, utilities: questi settori gestiscono impianti con centinaia di milioni di euro di valore che dipendono da software di supervisione e controllo scritti e mantenuti da developer specializzati.

Il problema strutturale è che questi developer sono pochi. Il profilo che unisce la conoscenza di .NET e C#, il know-how dei protocolli industriali (OPC UA, Modbus, Profinet), la capacità di costruire HMI in WPF e dashboard web in Blazor e la comprensione del contesto operativo industriale è una raritas vera nel mercato del lavoro italiano.

Le offerte di lavoro per developer con queste competenze provengono da tre tipologie di aziende. I system integrator specializzati in automazione industriale, come i partner certificati Siemens o Rockwell, costruiscono soluzioni SCADA custom per i loro clienti e cercano developer .NET da inserire nei team di sviluppo software. I contratti sono tipicamente di progetto ma spesso si trasformano in rapporti di lunga durata per la manutenzione evolutiva.

Le aziende manifatturiere con ufficio tecnico interno cercano developer che possano mantenere e sviluppare i loro sistemi SCADA proprietari. Queste posizioni sono meno visibili sul mercato perché spesso non vengono pubblicizzate esternamente, ma offrono stabilità e la possibilità di diventare il punto di riferimento tecnico per tutta la produzione.

I vendor di software SCADA come Inductive Automation (Ignition), Aveva, Citect e le aziende italiane del settore come Progea cercano developer per estendere le loro piattaforme con moduli personalizzati scritti in linguaggi nativi .NET o Java.

I range di compensazione per developer .NET con competenze HMI/SCADA in Italia si posizionano significativamente sopra la media del settore software: si parla di 45.000-70.000 euro lordi annui per profili con 3-5 anni di esperienza specifica, con punte oltre i 80.000 euro per chi ha esperienza su impianti critici in settori come farmaceutico o energia.

La differenza rispetto a un developer .NET generico è la scarsità dell'offerta combinata con la criticà del ruolo. Un impianto produttivo che si ferma per un problema software SCADA costa migliaia di euro l'ora. Chi sa risolverlo, o meglio ancora prevenirlo, vale di conseguenza.

Costruire questo profilo richiede un percorso specifico. Non basta conoscere C# e WPF: bisogna capire come funziona un PLC, cosa è un tag e come si legge tramite OPC UA, come si struttura un sistema di allarme secondo le best practice ISA-18.2 e come si progetta un'HMI che un operatore con 20 anni di esperienza su quella macchina trovi intuitiva da usare.

Il punto di partenza per molti developer è costruire un progetto personale: un piccolo simulatore di PLC con un client OPC UA scritto in C#, un'HMI WPF con un grafico real-time e qualche allarme simulato, un dashboard Blazor che mostra gli stessi dati su browser. Non è necessario avere un PLC fisico: esistono simulatori OPC UA gratuiti che permettono di sviluppare e testare tutta la logica di comunicazione senza hardware industriale.

Chi ha già questa base, e vuole trasformarla in una carriera strutturata nel mondo dell'automazione industriale, ha davanti una delle opportunità più concrete e durature del mercato .NET italiano nel 2026.